UCC data reveals loan stacking in MCA portfolios by showing whether the applicant already has active secured-party claims against the same business assets, accounts receivable, inventory, or future payment streams. For an MCA funder, the useful signal is not just “UCC filing exists.” The useful signal is the pattern: number of active filings, filing recency, secured-party names, collateral overlap, and whether multiple funders appear to be claiming the same revenue stream.
That distinction matters because UCC priority is not a vibe check. Article 9 priority generally ranks conflicting perfected security interests by time of filing or perfection, so an underwriter who funds behind earlier blanket liens may have little practical recovery value if the merchant defaults.1 In a fast MCA shop, UCC data should become a routing layer inside underwriting: clear, review, subordinate, or decline.
Why does loan stacking create a UCC data problem for MCA funders?
Loan stacking creates a UCC data problem because the same borrower can disclose one advance, hide another, and apply for a third while several secured parties already have filings against the business. The application file may look current, but the public record may show a different capital stack.
What does “stacking” mean in an MCA portfolio?
In MCA underwriting, stacking usually means the merchant has taken multiple advances at once or in rapid succession. Each advance may carry daily or weekly withdrawals, a purchase of future receivables, a personal guaranty, and in many cases a UCC filing. The Federal Reserve notes that some small businesses turn to nonbank lenders when they need funds quickly, and the Small Business Credit Survey includes merchant cash advances in its financing application categories.2 Speed helps merchants, but it also compresses the diligence window for funders.
Why is self-reported debt not enough?
Self-reported debt schedules are useful, but they are not a control. A merchant under cash pressure may omit a recent advance, misunderstand what counts as a financing obligation, or submit an application before a new filing appears in ordinary credit data. UCC filings give underwriters a second source: a public record of secured claims tied to the legal debtor name.
For MCA risk teams, the UCC record is not a final decision. It is the evidence that tells the underwriter whether the applicant's story matches the public lien trail.
What UCC fields matter most for stacking detection?
The most useful fields are debtor name, secured party, filing date, filing status, collateral description, amendments, continuations, and termination records. A UCC financing statement exists to give notice that a secured party claims an interest in a debtor's collateral, and state filing systems use that public record to establish priority in default or bankruptcy settings.3
Which fields separate a normal lien from a stacking signal?
- Secured party names. Multiple known MCA or revenue-based finance providers against one debtor indicate a different risk profile than one bank lien from a long-term facility.
- Filing recency. Two or three filings inside a short window can signal that the merchant is cycling through capital providers faster than cash flow can support.
- Collateral language. Broad language around accounts, proceeds, receivables, inventory, or all assets is more relevant to MCA exposure than a narrow equipment lien.
- Debtor-name fit. UCC search quality depends on the legal debtor name. Article 9 debtor-name rules make the registered organization's public organic record load-bearing for filed-name accuracy.4
- Continuation and termination status. A five-year-old filing may be irrelevant if terminated, still relevant if continued, or misleading if the debt was paid but the termination was never filed.
Why is collateral description the operator-grade field?
A simple filing count treats a bank equipment loan and an MCA receivables claim as equal. They are not equal for underwriting. An equipment lender may have a narrow claim on titled equipment. An MCA funder may have broader language around accounts receivable or future receipts. If the applicant already pledged the same receivable stream, the new funder is not just behind another creditor. It may be funding into a payment waterfall that is already overcrowded.
How should MCA underwriters read the pattern, not just the filing count?
A high filing count is a warning, but it is not the whole analysis. The stronger pattern is unique secured parties plus recent dates plus overlapping collateral. That gives the risk team a defensible reason to route the file to manual review or decline.
What does a practical stacking score look like?
| UCC pattern | Likely meaning | Recommended underwriting route |
|---|---|---|
| No active UCC filings found in supported states | No public secured-party signal in available UCC data | Continue normal credit, bank, and fraud review |
| One older bank or equipment lien | Potentially ordinary secured debt | Review collateral description and payoff status |
| Two active filings from finance companies | Possible existing debt stack | Manual review, request payoff letters or debt schedule proof |
| Three or more recent filings from MCA-style funders | Strong stacking signal | Escalate or decline based on policy |
| Multiple all-assets or receivables claims | Collateral overlap and priority conflict | Require senior approval before funding |
Where should the threshold live?
The threshold should live in credit policy, not in a vendor's marketing copy. A lender might allow one older non-MCA filing but route two recent receivables claims to review. Another lender might decline any applicant with three active MCA-style secured parties. The important point is that UCC data gives the policy something concrete to evaluate.
How does Cobalt return UCC data inside the underwriting workflow?
Cobalt's UCC Filing Data API is delivered through the Secretary of State search endpoint by adding the `uccData=true` parameter. The same request that verifies the business can also return UCC filing data for supported states, including filing details, secured party information, debtor information, collateral descriptions, filing dates, and file numbers. Cobalt's product documentation states current UCC coverage is 11 states and that data freshness depends on the source state's filing database update frequency.
What does the request look like?
curl --location 'https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Corp&state=delaware&uccData=true&liveData=true' \
--header 'x-api-key: Your_API_Key' \
--header 'Accept: application/json'The response can include standard entity data plus UCC filings, which lets the lender evaluate status, entity match, lien data, and collateral context in the same underwriting packet.
What should engineering teams map into the LOS?
- Entity match confidence. Do not run stacking rules against a weak entity match without human review.
- UCC filing count. Count active filings, but do not stop there.
- Unique secured parties. Count distinct finance providers and normalize known funder names.
- Filing date bands. Flag filings inside 30, 60, and 90-day windows.
- Collateral keywords. Flag accounts, receivables, proceeds, inventory, all assets, and after-acquired property.
- Status and lifecycle fields. Separate active, amended, continued, lapsed, and terminated records where available.
What are the limits of UCC data for MCA stacking analysis?
UCC data is useful because it is public, structured enough to automate, and tied to secured-party behavior. It is limited because it does not show every obligation, every cash-flow burden, every bank debit, or every private settlement. Treat it as one risk layer, not the whole underwriting model.
What does UCC data not tell you?
- It does not prove the current balance. A filing may remain active after partial repayment or after payoff if no termination was filed.
- It does not capture unsecured advances. If no secured interest was filed, the UCC record may be silent.
- It does not include all liens. Tax liens and certain federal or county-level records may require separate sources.
- It does not replace cash-flow review. Bank statement analysis, processor data, and NSF trends still determine repayment capacity.
- It does not decide policy. Cobalt returns data. The lender defines the rule, threshold, and final decisioning logic.
Why should the limitation be stated in the credit memo?
Stating the limitation makes the review defensible. A credit memo can say: “UCC data in supported states showed two active secured parties with receivables-related collateral language. Applicant debt schedule disclosed one. File routed to manual review.” That is stronger than saying: “possible stacking.”
How should UCC stacking checks fit with KYB, OFAC, TIN, and court data?
UCC data should sit after entity verification and before final credit routing. The legal name from the Secretary of State record should drive the UCC search. Then the same file can use OFAC, TIN/EIN verification, and court records to build a broader risk packet. FinCEN's Customer Due Diligence rule is one reason regulated and bank-partnered workflows care about documenting who was checked, what source was used, and when the verification occurred.5
What is the recommended sequence?
- Step 1: Verify the entity. Confirm legal name, formation state, status, and available officers or registered agent data.
- Step 2: Retrieve UCC data. Search with the verified legal name and supported state coverage.
- Step 3: Score stacking patterns. Apply filing count, unique secured parties, recency, collateral language, and lifecycle status.
- Step 4: Check identity and sanctions data. Use TIN/EIN verification and OFAC screening where required by policy.
- Step 5: Pull court or judgment data where available. Use this for legal distress signals that UCC filings do not show.
- Step 6: Route the file. Clear, manual review, decline, or request documentation based on documented policy thresholds.
How does third-party risk affect the vendor choice?
If an MCA funder works with bank partners, warehouse providers, or regulated counterparties, the data provider may become part of the third-party risk file. The 2023 interagency guidance issued by the OCC, Federal Reserve, and FDIC applies to banking organizations' third-party relationships and emphasizes risk management across the relationship life cycle.6 For the lender, that means the UCC vendor should be able to explain data source, timestamps, coverage, failure handling, and audit evidence.
How should a lender test UCC stacking detection before using it in production?
The best test is a parallel run on historical files. Pull a sample that includes known clean borrowers, known stacked borrowers, businesses with bank liens, businesses with equipment liens, and files where the legal name changed. Run the automated UCC workflow against the sample, then compare it to the manual file record.
What should the test measure?
- Entity match accuracy. Did the API find the right legal debtor, or a similar-name business?
- UCC completeness. Did it return the filings the manual process found in supported states?
- Stacking precision. Did it separate ordinary secured debt from MCA-style receivables claims?
- False positive rate. How many clean files were routed to unnecessary review?
- False negative rate. How many known stacked files were missed?
- Latency and failure behavior. What happens when a state source is slow, unavailable, or returns ambiguous results?
- Audit packet quality. Does each file show source, timestamp, lookup inputs, and result status?
What pass/fail rules should the pilot use?
Use policy-specific thresholds. For example: 95 percent or better correct entity matching, 90 percent or better agreement with manual UCC findings in supported states, no missed known stacking cases in the sample, and documented manual review for every ambiguous match. The exact numbers should come from the lender's risk appetite, but the pilot should be numeric.
What should the underwriter do when the UCC data shows possible stacking?
The underwriter should not treat one UCC hit as automatic fraud. The right response is to reconcile the UCC pattern with the application, debt schedule, bank statements, payoff letters, and borrower explanation.
What questions should underwriting ask?
- Did the applicant disclose every secured party shown in the UCC record? A mismatch should pause the file.
- Are the recent filings tied to current balances? Request payoff letters or settlement documentation.
- Does collateral language overlap with the proposed advance? Receivables and all-assets language deserve closer review.
- Do bank statements show daily debits to funders? The public lien trail should match cash-flow behavior.
- Is there a clean subordination or payoff path? If not, the new position may be economically weak.
What should the final credit note say?
A useful credit note names the facts, not the suspicion. Example: “UCC search returned three active filings in supported states. Two secured parties appear to be nonbank funders. Two filings were created inside the last 90 days. Collateral descriptions include receivables and all assets. Applicant disclosed one existing advance. Routed to senior review.”
Bottom line: UCC data does not eliminate underwriting judgment. It gives risk, underwriting, and engineering teams a structured way to detect stacking patterns before the deal is funded.
Related Cobalt reading: UCC Filing API: Complete Resource for Lenders, How Lenders Verify UCC Filings and State Registrations Automatically, and Business Verification APIs for Lenders.












.png)