Executive Summary: A completed UCC search can return fewer filings than it found. Cobalt's standalone UCC API documents a maximum of 30 returned filings and a separate uccDataCount total.[1] Before your collateral team closes a review, compare those two values and give any missing evidence a clear next step.
What does a completed UCC search actually tell you?
For an equipment-finance or working-capital lender, the useful question is whether the analyst has the evidence needed for the collateral decision. A successful search is one step toward that answer. It is not a substitute for it.
Cobalt's /ucc documentation distinguishes the number of filings found from the filing objects delivered in results. It explicitly says that a total larger than the array means additional filings exist beyond those shown.[2] Your loan origination system should preserve that distinction in the analyst's view.
Which completion should the analyst see?
Use separate labels for request completion and review completion. For example, your application could show “Search completed: 30 of 47 filings returned” while leaving the collateral task at “Additional evidence required.” The numbers in this example are illustrative; they do not describe a customer or an observed borrower.
That wording lets the analyst begin useful work on the returned records without making the unresolved portion disappear. It also tells a funding reviewer why a technical success did not close the underwriting condition.
Why not rely on a green status alone?
The endpoint's completed response contains status, statusCode, results, and uccDataCount. Those fields answer related but different questions.[3] A green transport or request status should not overwrite a separate count mismatch.
Make the missing evidence visible at the point where someone could mistake a completed search for a completed review.
This is an operating recommendation. Cobalt returns source data; your team decides what evidence its collateral policy requires and who may resolve an exception.
How should the integration compare the counts?
Start with the unmodified response. Preserve the submitted debtor name, requested state, request identity, response receipt time, total found, and actual length of the returned array. Record your calculated review state separately so a later policy change does not alter the original evidence.
The following is illustrative customer-side logic, not a Cobalt endpoint or a complete production implementation:
def count_review_state(payload):
if not payload.get("status") == "Complete":
return "search_unresolved"
results = payload.get("results")
total = payload.get("uccDataCount")
if not isinstance(results, list):
return "response_shape_review"
if isinstance(total, bool) or not isinstance(total, int):
return "count_review"
if total < len(results) or total < 0:
return "count_review"
if total > len(results):
return "additional_filings_required"
return "returned_set_reconciled"The documented count is a numeric field. Confirm its actual representation in your integration contract and adapt validation deliberately; do not silently replace a missing or malformed count with zero.[4] The example intentionally routes unexpected values to review.
What should equality mean?
Call equality “returned set reconciled,” not “no other liens.” It means the array length agrees with the reported total for this response. It does not determine whether the submitted debtor name, chosen jurisdiction, or search strategy met your team's requirements.
Keep duplicate detection separate as well. If two objects share an identifier, retain the raw array and flag the issue before deciding whether they represent duplicate delivery, related records, or a source-specific convention. Deduplicating first can hide the count comparison you intended to perform.
Our UCC search tool implementation guide covers the broader search workflow. Add this completeness decision where its result enters your collateral review, rather than treating a user-interface record count as the evidence check itself.
What should happen when the total exceeds the returned set?
Create a bounded exception task. The task should explain what is missing, what action would resolve it, who owns that action, and what the analyst may do while waiting. A generic “API issue” label is too vague for a funding queue.
For a hypothetical response reporting 47 filings with 30 objects, the task might say: “Reconcile 17 filings not included in this response before closing the required filing review.” That arithmetic identifies the evidence gap; it does not identify the unseen filings or establish their relevance.
Use a handoff checklist such as:
• Search identity. Retain the exact debtor query and requested state, which are required for a new standalone UCC search.[5]
• Observed counts. Show the reported total and returned count together, without rounding or collapsing either value.
• Retrieval owner. Assign the collateral analyst or source-retrieval team responsible for obtaining the remaining evidence.
• Required output. Specify the filing list, source search report, document copies, or explanation needed to reconcile the gap.
• Decision boundary. State which underwriting work can continue and which condition remains unresolved under your policy.
• Closure evidence. Require a source reference and reviewer note that explain how the missing portion was addressed.
Is there a documented next-page request?
The current /ucc parameter list includes the debtor query, state, retry ID, callback URL, and live-data option. It does not document a pagination parameter for fetching filings beyond the returned limit.[6] Do not build a page, offset, or cursor request by assumption.
Use the appropriate state filing office or confirm an available retrieval route with Cobalt. If no supported route can supply what the policy requires, retain the unresolved condition. An integration should not manufacture completion because it has exhausted its implemented calls.
Which alternative retrieval route fits the evidence gap?
Choose a route based on the missing evidence. A filing list, a copy of a particular document, and a certified search response are different deliverables. Specify the needed deliverable before ordering another search.
Maryland's official UCC guide, for example, describes obtaining a search response, copies of selected documents, or both. Its filing-number search instructions also explain how related filing records appear.[7] That is an example of a state-office workflow, not a promise that every state offers identical options.
When is manual retrieval reasonable?
For an occasional exception, an analyst can follow the relevant filing office's current process and attach the obtained evidence to the existing application. Preserve the original query and explain any change in scope. If the second search uses a different debtor spelling or jurisdiction, do not present the two counts as directly comparable without that explanation.
A procurement decision may be appropriate if these exceptions become frequent in your own measured queue. Middesk, for example, describes a Liens Search product intended for lender workflows.[8] Its existence is an alternative to evaluate, not evidence that it will resolve every specific gap in your file. Ask any provider to demonstrate the required search scope, returned counts, document access, and exception handling.
When do you need the filing itself?
A metadata row can identify a document that needs review. It should not be stretched into a conclusion about text you have not obtained. Cobalt's UCC example includes imageUrl, but states that fields not supplied by the state are omitted.[9]
If the decision turns on a filing's contents, the closure condition should identify the relevant document and the review performed. Our guide to accessing primary-source UCC documents provides additional context for that retrieval step. Keep document sufficiency and result-count reconciliation as separate checks.
How should you test the edge cases before rollout?
Test the decision the analyst sees, not only whether the parser accepts a response. Build fixtures with known expected outcomes and ask a collateral reviewer to read the resulting task without seeing the code.
A useful test set includes a completed empty search, a complete returned set, a truncated set, a pending request, a missing count, an inconsistent count, and a delayed callback. These are suggested acceptance cases, not a statement about their frequency in production.
What does a completed empty search mean?
Cobalt documents a successful completed response with an empty array and uccDataCount equal to zero.[10] Your test should preserve it as “no filings returned for this search,” while retaining the query and jurisdiction. It must remain distinguishable from a failed search, a missing payload, or an unsupported state.
How should delayed delivery behave?
The endpoint documents a retry ID for longer-running requests and a callback option for completed results.[11] Your test should show that the initial acknowledgment leaves the review open and that the final response runs the count check before changing the task state.
Use a second delivery of the same final result as another test. It should not create a second analyst task or replace a completed evidence note with a blank one. Establish your own correlation and duplicate-handling rules around the documented request identity.
Finally, test a late result after the application has changed. The original response still belongs to its original search. Route it to the correct application version instead of letting arrival order choose which borrower record receives the evidence.
How can operations manage the exception without stalling every file?
Define a narrow work queue for incomplete returned sets. The purpose is to show the extra evidence work, not to send every UCC search to manual review. A reconciled count can continue through the other controls your team already uses.
For an unresolved file, distinguish three practical situations. The team may have requested the remaining records and be waiting. It may have obtained them and be reviewing the contents. Or it may have learned that the current source route cannot meet the requirement. Each situation calls for a different owner and next action.
What should the handoff note contain?
Write the note so another reviewer can continue without reconstructing the integration. Include the submitted scope, the original response reference, the count mismatch, the additional source used, and the precise condition still open. If the second source returns a different count, explain why the discrepancy remains unresolved or how it was reconciled.
Avoid replacing the original response with an edited array that appears complete. Attach supplemental evidence and a separate resolution record. That preserves what each source supplied at each step and makes the analyst's reasoning visible.
Which measurements are useful?
Track your own count-mismatch rate, unresolved-task age, retrieval effort, and closure reasons. Separate “source evidence obtained” from “review closed by an authorized exception.” These are proposed operating measures, not promised product outcomes.
Review a sample of closed tasks with underwriting and engineering together. A low exception count is not enough if the interface makes missing counts look like zero. The useful result is a review state that accurately represents the evidence, including the uncomfortable cases.
What would a useful resolution look like?
Consider an illustrative renewal file where the original response returned 30 of 47 reported filings. The analyst obtains a state-office search response and associated records, then discovers that several entries belong to a similarly named business. The right closure note does not simply change 47 to 30. It identifies which evidence established the borrower match, which records were excluded, and which documents the collateral reviewer considered.
If the state-office search instead returns fewer records because the analyst used a narrower debtor name, the count difference needs explanation. Keep both submitted names and both search scopes. A smaller answer is not automatically a better answer, and a larger answer is not automatically more relevant. The reviewer needs a documented basis for accepting the resulting evidence set.
Another file may remain unresolved because the additional documents have not arrived. Give that task a next-review date and a named owner. If an authorized reviewer permits another part of underwriting to continue, record the limited action allowed and the outstanding collateral condition. Do not turn permission to continue analysis into permission to close the filing review.
These examples illustrate why a closure reason deserves its own field. “Additional records reconciled,” “Different entity confirmed,” and “Evidence still unavailable” describe different outcomes. A single completed checkbox would discard the distinction that made the count check useful in the first place.
What should you verify in a Cobalt evaluation?
Bring a permitted sample workflow that includes both an ordinary debtor search and a case where the filing volume challenges your review process. Ask to inspect the response shape, count behavior, delayed-delivery path, and available follow-up options before agreeing on an integration design.
Cobalt's current standalone UCC documentation lists specific supported states. Availability is not universal, and the endpoint is separate from the uccData option attached to a Secretary of State business search.[12] Confirm the route and jurisdiction relevant to your portfolio instead of transferring assumptions from another endpoint.
For collateral operations, the acceptance criterion should be concrete: the analyst can see what was searched, how many filings were reported, how many were returned, and what remains unresolved. For engineering, the matching criterion is that no success code can bypass the evidence checks the lender selected.
Schedule a Cobalt demo with that workflow and the jurisdictions you need. The discussion should establish how documented UCC data fits your review and where an additional evidence route is required.
.jpg){kind=small}
.png)