Executive Summary: Most underwriting teams run a lien search that covers exactly one half of the lien universe, and they usually do not know which half. A UCC search finds consensual security interests that a creditor filed on purpose; a court search finds judgment liens that a court imposed against the debtor's will. This is an implementation guide for running both, reconciling the two result sets when the names do not match, and knowing precisely what a partial answer means before you act on it.
Why Does a UCC-Only Lien Search Miss Half the Picture?
Application volume makes the gap expensive. Sixty percent of small employer firms applied for financing in the twelve months preceding the Federal Reserve's 2025 Small Business Credit Survey.[12] At that rate, a lien check with a structural blind spot is a systematic miss, not an occasional one.
A UCC search answers a narrow question well. It tells you which parties have publicly claimed a security interest in a debtor's assets by filing a financing statement with a state filing office. That is a real and useful signal, and for a merchant cash advance shop it is often the single highest-value check in the stack. But it is a search of a filing index, and a filing index only contains what somebody chose to file.
What does a UCC-1 filing actually tell you?
A UCC-1 financing statement is a notice filing. It does not prove a debt exists, prove an amount, or prove the collateral is still there. It says a secured party has put the world on notice that it claims an interest, and it fixes that party's place in the priority line. Under UCC 9-322, priority among competing secured parties generally runs to whoever filed or perfected first.[6] That is why the filing date on a UCC-1 matters more to your subordination analysis than the collateral description does.
Two mechanical facts shape how you read the index. A filed financing statement is effective for five years, and a continuation statement can only be filed within the six months before that window closes.[4] A lapsed filing disappears from the practical picture even though the underlying debt may still be outstanding. State-level Article 9 filing offices administer this directly, and New York's Department of State publishes its own Article 9 filing rules.[10] The framework is also still moving: more than half of U.S. states have adopted the 2022 UCC amendments, which revised Article 9 alongside the new Article 12.[13]
Which liens never appear in the UCC index?
Involuntary liens. Nothing about a judgment creditor's claim runs through Article 9's filing system, because the creditor never had a security agreement to perfect. Under UCC 9-317, a lien creditor whose interest arises before a security interest is perfected can take priority over that unperfected interest, which means a judgment holder is a live participant in the priority contest even though the UCC index never mentions them.[5]
Here is what a UCC-only search structurally cannot return:
• Docketed money judgments. In New York, a money judgment becomes a lien on the debtor's real property upon docketing with the county clerk, not upon any UCC filing.[7]
• Pending litigation with no judgment yet. A lawsuit that is six weeks from a summary judgment motion produces no filing-office record at all.[9]
• Federal and state tax liens. These move through separate recording systems and are not captured in Article 9 filing data.[17]
• Judgment renewals and extensions. New York judgment liens can be preserved and renewed through separate court procedures that never touch the UCC index.[14]
• Claims from a creditor who simply did not file. Perfection is optional in the sense that a lender can choose not to do it, and unsophisticated or fast-moving funders regularly do not.
• Mechanics liens and similar statutory liens. These are recorded at the county level in most states, on their own timeline.
Why Does a Court-Only Search Miss Consensual Security Interests?
The inverse failure is less discussed and just as costly. A team that has been burned by a surprise judgment sometimes overcorrects into court-record diligence and treats a clean docket as a clean collateral position. It is not.
What does a docketed judgment actually attach to?
In New York, docketing a money judgment with a county clerk creates a lien against the judgment debtor's real property in that county, and the New York County Clerk maintains a dedicated Judgment Docket and Lien Section for exactly this function.[8] The lien reaches real property interests in the county where it is docketed, and a New York judgment carries a long enforcement life that makes stale judgments materially relevant.[16]
Notice what that description does not include. It does not include receivables. It does not include inventory, equipment, or deposit accounts. For an MCA funder whose repayment depends entirely on daily card receipts, the judgment docket is silent about the exact asset class that determines whether they get paid.
Where do court records go silent?
Court records are organized around disputes, not around collateral. A borrower can carry four all-asset UCC-1 filings from four different funders, all perfected, all senior to you, and have a completely empty civil docket. Nobody sued anybody. Everybody signed a contract voluntarily. That is not a distressed borrower profile in the litigation sense, and it is a catastrophic subordination profile in the lending sense.
This is the specific pattern behind stacking. Recent bankruptcy practice materials on merchant cash advance claims describe how competing MCA positions get sorted out precisely through Article 9 lien analysis rather than litigation history.[15] If your only lien check is a docket search, stacking is invisible to you until the merchant defaults. Our breakdown of UCC filings paired with SOS status covers the entity-status half of that problem in more depth.
How Do You Normalize the Name Before You Search Anything?
Both searches are name searches. Neither one is an identifier search. That single fact causes more bad lien results than every other implementation error combined, so name normalization is step one and it is not optional.
Why does the SOS legal name have to come first?
Because the UCC filing office indexed the debtor under a legally specified name, not under whatever the merchant wrote on the application. UCC 9-503(a)(1) requires a financing statement to provide the name shown on the registered organization's most recent public organic record filed with its jurisdiction of organization.[1] That is the Secretary of State record. If you search a trade name, you are searching a string the filer was legally directed not to use.
The consequence of a mismatch is severe in both directions. A financing statement that fails to provide the debtor name correctly is seriously misleading and ineffective, subject only to a narrow safe harbor that applies when a search using the filing office's standard search logic on the correct name would still surface the record.[2] Practitioners consistently warn that this safe harbor gives thin protection, because standard search logic varies by state and small variations defeat it.[3]
So the pipeline order is fixed: pull the SOS record first, take the exact legal name off it, and use that string as the canonical key for everything downstream.
How do you build the search alias set?
One canonical name is not enough for the court search, because courts index parties by however the pleading captioned them. Build a small alias set per applicant and carry it through:
• Canonical legal name. Verbatim from the SOS record, including punctuation and the entity suffix.
• Suffix-stripped form. Same name with LLC, INC, CORP, and trailing punctuation removed, for fuzzy comparison only.
• Registered DBA and assumed names. These appear on SOS records in most states and are frequently what a plaintiff used in a caption.
• Prior legal names. Any name change reflected in the entity's filing history, since a UCC-1 filed under the old name may still be effective.
• Common truncations. Court intake systems truncate long party names, so a 60-character legal name may sit in the docket clipped at 40.
Normalize all of these the same way before comparison: uppercase, collapse internal whitespace, strip punctuation, and strip entity suffixes. Store both the raw and normalized forms. You will need the raw string for your audit trail and the normalized string for matching.
What do you do with individual guarantors?
Run them separately, and expect the entity search alone to under-report. Judgments against a principal personally do not appear under the business name, and a principal with a pattern of personal judgments is a signal worth having. Note the rule change: for an individual debtor the name sufficiency analysis under Article 9 works differently than for a registered organization, so do not reuse the entity normalization logic without adjustment.[18]
How Do You Actually Run Both Searches?
Before getting into a specific implementation, it is worth naming what the alternatives look like, because the tradeoff is not really about data quality. It is about integration shape. Unicourt and LexisNexis both offer court data at meaningful scale. PACER covers federal cases directly. CSC Global and Wolters Kluwer offer established UCC search services with wide state coverage. Manual courthouse and county-clerk searches remain ground truth for anything that has to hold up in litigation. Every one is a legitimate answer, and larger shops run several at once. Max Weisz, an MCA operator processing around 500 files a day, described his stack in exactly those terms:
"we run New York court separately and then we run Unicourt, and then we run UCC searches."
Three separate vendors, three separate result formats, three separate reconciliation problems, on every file. The argument for consolidating the UCC and court legs into one API surface is not that the data is better. It is that you write the reconciliation logic once instead of three times, and you get both legs keyed off the same SOS record.
What does the pair of calls look like?
The UCC leg is a parameter on the Secretary of State search, so a single request returns entity status and lien data together. It is billed as a separate credit from the SOS lookup, and UCC coverage currently spans roughly 10 to 11 states. The court leg is a separate endpoint, and it is asynchronous only.
# LEG 1: SOS entity record + UCC filings, one synchronous call.
# uccData=true adds the lien data. Billed as a separate credit from the SOS lookup.
# UCC coverage is roughly 10-11 states, NOT all 50.
curl --location --get 'https://apigateway.cobaltintelligence.com/v1/search' \
--data-urlencode 'searchQuery=ACME LOGISTICS GROUP LLC' \
--data-urlencode 'state=newYork' \
--data-urlencode 'uccData=true' \
--data-urlencode 'liveData=true' \
--header 'x-api-key: YOUR_API_KEY' \
--header 'Accept: application/json'
# LEG 2: Court records. Async only. callbackUrl is REQUIRED.
# jurisdiction must be newYork | miamiDade | testNewYork | testMiamiDade.
# Use the canonical legal name returned by LEG 1, not the application name.
curl --location --get 'https://apigateway.cobaltintelligence.com/courtCases' \
--data-urlencode 'businessName=ACME LOGISTICS GROUP LLC' \
--data-urlencode 'jurisdiction=newYork' \
--data-urlencode 'callbackUrl=https://underwriting.yourdomain.com/hooks/court-results' \
--header 'x-api-key: YOUR_API_KEY' \
--header 'Accept: application/json'
# LEG 2 returns an acknowledgement immediately, not results:
# {
# "status": "Completed request will be sent to callback url.",
# "statusCode": 200,
# "callbackData": {
# "requestId": "123456-asd3-4159-b5b0-hg5cyhdd",
# "callbackUrl": "https://underwriting.yourdomain.com/hooks/court-results"
# }
# }
# Results arrive at the callback in roughly 30-120 seconds.Why is the court endpoint asynchronous, and what does that force on your side?
Because the data is pulled live from the court system at request time rather than served from a cache. There is no synchronous mode and no polling endpoint. The `callbackUrl` parameter is required, and typical completion runs 30 to 120 seconds.
That has three consequences for your pipeline. First, you need a persisted request record keyed on `requestId` before you fire the call, so the callback has something to attach to. Second, your underwriting UI needs a pending state. Third, you need a timeout policy for when the callback never arrives, and "silently treat it as clean" is the wrong answer.
Use `testNewYork` and `testMiamiDade` while you are building. They exercise the full async path without consuming credits, so your integration tests can run on every commit. Our court records quickstart walks the callback handler in more detail.
"If courts are cheap enough, then it's worth it to run on every application automatically." That is Yehudah Aron at Cucumber Capital, and it is the right instinct. If you want both legs running on every file instead of only on deep-dive exceptions, start with the test jurisdictions and confirm your callback handler before you spend a credit. Talk to our team about a two-source lien workflow.
How Do You Reconcile Results That Use Different Name Formats?
The two legs return the same borrower under different strings, and reconciling them is where most implementations quietly break.
Which fields do you actually match on?
Not the name alone. The UCC leg gives you a structured debtor record with a name and an address, plus a secured party name and address. The court leg gives you plaintiff and defendant party names as captioned, plus case number, case type, court division, and filing dates. The only field genuinely common to both is a name string, and the formats differ systematically. UCC debtor names follow the SOS legal name because the statute required it. Court party names follow whatever the filing attorney typed.
Match in this order and stop at the first tier that hits:
• Tier 1, exact normalized match. Uppercase, punctuation stripped, suffix stripped, whitespace collapsed. Treat as a confirmed same-entity match.
• Tier 2, alias-set match. The court party matches a registered DBA or a prior legal name from the SOS record. Confirmed, but log which alias matched.
• Tier 3, high-similarity match with address corroboration. Name similarity above your threshold plus a matching street address or city. Route to a human.
• Tier 4, high-similarity match with no corroboration. Common in states with many similarly named entities. Route to a human and never auto-decline on it.
• Tier 5, no match. Record it explicitly as searched-and-clear, with the jurisdiction and the exact query string.
How do you record confidence without hiding it?
The failure mode to avoid is collapsing all five tiers into a boolean. If your risk model consumes `has_liens: true`, you have thrown away the distinction between a perfected all-asset UCC-1 from a known funder and a fuzzy name hit on a defendant in an unrelated contract dispute. Persist the tier, the matched string, the jurisdiction, and the timestamp on every result. Your regulator-facing audit trail needs it, and your model needs it more.
What Does a Partial Result Actually Mean?
This is the part of the implementation that gets skipped, and it is the part that creates false confidence. The UCC and court coverage footprints do not fully overlap, so for most applicants you are getting one leg, not two.
Where do the two footprints line up and where do they not?
UCC filing data covers roughly 10 to 11 states. Court records cover New York State and Miami-Dade County, Florida. Nothing else. Not nationwide, not federal, not PACER. That produces four distinct situations, and your system needs to distinguish them:
• Both legs available. New York is the clean case. UCC coverage and court coverage both apply, and a two-source result is genuinely a two-source result.
• UCC only. A borrower in a covered UCC state outside New York. You have consensual security interests and no judgment visibility.
• Court only. A Miami-Dade borrower where UCC coverage does not apply. You have judgments, drawn from the Clerk of the Court records that carry civil case files, dockets, and judgments for that county, and no lien-priority picture.[11]
• Neither. Most of the country. Your lien answer here comes from somewhere else entirely.
New York deserves the specific callout because it is the only state where SOS status, UCC filings, contractor licensing, and court records all overlap in one workflow. If you are building a demonstration of the full pattern, build it on a New York borrower. Coverage is demand-driven rather than exhaustive: Jordan Hansen has been direct in customer calls that roughly 80 percent of Cobalt's funder customers file judgments in these two places, with New York as the center of alternative lending and Miami-Dade as the second hub after a large migration of funders to South Florida during COVID.
When do you have to supplement, and with what?
Whenever the applicant's state is not in the covered set for the leg you need. That is a routing rule, not a judgment call, and it should live in code rather than in an underwriter's head. Not everyone will find the footprint sufficient, and the honest response is that some shops should route elsewhere. Lara Hodgson at RoxWrite put the objection plainly: "Most of our clients are not in New York." Cameron Kelliher at Elementix reached the same conclusion from the other direction: "We'll stay away from the court stuff then. I wish the court stuff was rounded." Both are reasonable reads of the coverage map.
Gate Rock Capital framed the value in terms of exactly where the coverage does land: "where I would pay $4 a pull is when you have the state index on court search." Peter Chong at Highwire, working construction pre-qualification, asks the two-source question directly: "are there any open liens against them? Any litigations associated to this specific contractor?" That is one question that requires both legs, and in a covered jurisdiction it resolves in a single workflow.
Supplementation paths when a leg is unavailable: a nationwide UCC vendor such as CSC Global or Wolters Kluwer for out-of-footprint states, Unicourt or LexisNexis for out-of-footprint courts, PACER for federal matters, and a county-level search where the record is not online at all. Broader jurisdictions are on the Cobalt roadmap, including a planned human-assisted queue that would run slower, roughly an hour, and has not shipped. Do not build against it today. Our state-by-state UCC coverage breakdown has the current footprint detail.
How Do You Put This Into Production Without Distorting Your Decisions?
Two implementation decisions determine whether this pattern helps or quietly misleads your team.
How should you account for credits and volume?
Both products bill at 1 credit per lookup, and `uccData=true` bills as a separate credit from the SOS lookup it rides along with. A full two-source pass on one applicant is therefore three credits: SOS, UCC, court. At 500 files a day that is a real line item, and it is why many shops run SOS on every file, UCC wherever the state is covered, and court on a triggered subset. Encode that policy deliberately rather than letting it emerge from whatever the integration happened to do first.
How do you keep an honest audit trail?
Record what you searched, not just what you found. For every application, persist the exact query string, the jurisdiction, the endpoint, the timestamp, the `requestId` for async calls, and the outcome including explicit not-covered outcomes. A record that says "court search not run, applicant state not in coverage" is a defensible artifact. A record that shows no court result at all reads, six months later, exactly like a clean search. Those are opposite facts.
Cobalt is a data source, not a decisioning engine. The pattern here gives you two independent views of encumbrance, keyed off a single verified legal name, with the gaps labeled. What you do with a Tier 3 name match or a senior all-asset filing is your credit policy, and it should stay that way.
.jpg){kind=small}
.png)