UCC Search Freshness: Keep Filing Dates Separate From Retrieval Dates

Executive Summary: A UCC search received today does not make every timestamp in the response a measure of today's evidence. Cobalt's standalone UCC documentation distinguishes filing dates from timestamps attached to stored records.^[1] For a lending decision, identify which clock answers your question before deciding whether to reuse the result.

Which date answers the underwriting question?

Start with the decision the collateral reviewer needs to make. “When was this document filed?” differs from “When was this stored record updated?” Both differ from “When did our system receive this response?” Put the question beside the date rather than expecting an analyst to infer its meaning from an unlabeled timestamp.

The current UCC response schema includes filingDate and lapseDate, while the endpoint description says stored filings carry createdAt and updatedAt.^[2] These fields should retain their source meanings in your application.

What can a filing date establish?

Use a filing date to describe the event represented in the filing record. Do not relabel it “last checked.” An old filing date can appear in newly retrieved evidence; the age of the filing and the age of the observation are separate matters.

If an underwriter wants to compare events before and after an earlier loan review, filing dates may be relevant to that comparison. If the question is whether the evidence was retrieved recently enough for today's decision, the filing date alone does not answer it.

What should a local receipt time establish?

Add your own receipt timestamp when your system accepts the response. Label it as your observation time. It helps explain when the integration received the evidence, including delayed callbacks or records imported into the loan file later.

Keep it separate from every provider timestamp. A reviewer opening a file this afternoon should not have to guess whether “Updated today” refers to a state record, a stored provider record, or someone saving the application.

What does Cobalt document about stored and live UCC searches?

Cobalt's standalone /ucc endpoint allows liveData=false to request stored UCC data. The current parameter description says other values request a live search.^[3] Retain the requested mode in the evidence record so the reviewer can understand how the request was made.

For stored results, the endpoint description identifies createdAt and updatedAt as timestamps that help show when the stored filing was refreshed.^[4] Do not convert that into a promise about a filing office's publication lag or an assurance that every possible filing has reached the index.

Is a live request always the right choice?

A live request may fit a pre-funding check when the lender wants a new source retrieval. A stored result may fit another workflow if the lender's evidence policy permits it. Make that choice explicit and explain the acceptance rule to underwriting.

Neither choice removes the need to check the returned scope and completion. The endpoint documents delayed results through a retry ID or callback path.^[5] Sending the request at 10:00 is not proof that a complete response existed at 10:00.

What remains outside the timestamp?

A date does not identify the right debtor, establish the required jurisdictions, or supply an omitted filing document. Our guide to UCC data quality across state portals provides context for source differences. Use freshness as one evidence test, with identity and completeness evaluated alongside it.

How should the lending file represent the different clocks?

Create an evidence record that makes the distinction visible without requiring the underwriter to read JSON. The analyst view could show “Filing date,” “Stored record updated,” and “Received by our system,” each with its source or meaning available nearby.

Preserve the original values before transforming them for display. If a timestamp arrives without enough information to establish its timezone or units, do not guess. Retain the value and record the interpretation as unresolved until the integration contract or provider confirms it.

Use a record design such as:

• Submitted scope. Save the debtor query and requested state associated with this observation.

• Requested data mode. Save whether the request asked for stored or live UCC data, following the documented liveData parameter.^[6]

• Filing event dates. Preserve the dates attached to each filing, including their original representation.

• Provider record timestamps. Store createdAt and updatedAt when present; the documentation associates these with stored results.^[7]

• Local observation time. Record when your service received and retained the response.

• Policy evaluation. Store which freshness rule ran, what evidence it used, and whether the result was acceptable or unresolved.

What belongs in the analyst summary?

Show the information needed for the current decision. For example, a reviewer might see “Stored evidence received today; provider update date available; policy review pending.” Avoid an unsupported “Current” badge that hides which date the system used.

If several filings carry different update times, do not replace them with the newest timestamp and label the entire set fresh. Your policy may evaluate each relevant record or require a new retrieval for the set. Whichever approach you choose, document it and retain the per-record evidence.

How can a freshness rule handle unknown information?

A useful rule needs more than pass and fail. Include an unresolved state for missing, malformed, or ambiguous timestamps. Otherwise an absent date can become a default that silently satisfies the rule.

The following illustrates customer-side handling after a timestamp has been parsed and its meaning confirmed. The policy limit and date parsing are intentionally supplied by the lender's application.

def age_review(observed_at, source_updated_at, maximum_age):
    if source_updated_at is None:
        return "source_age_unknown"
    if source_updated_at > observed_at:
        return "clock_or_timestamp_review"
    age = observed_at - source_updated_at
    if age > maximum_age:
        return "refresh_or_exception_review"
    return "within_selected_age_policy"

This example does not implement a legal deadline, Cobalt service guarantee, or recommended number of days. It expresses a decision your team must define for the relevant product, transaction stage, and evidence need.

Why treat a future timestamp separately?

A timestamp later than local receipt deserves investigation before it becomes negative age and passes automatically. Check units, timezone handling, parsing, and clock assumptions. Keep the original value available so support can identify the cause without reproducing a borrower search unnecessarily.

What if no provider timestamp is available?

Record source age as unknown. A local receipt time still tells you when your system obtained the response, but it cannot fill a missing source-update field. Decide whether another source retrieval, a provider clarification, or an authorized evidence exception is appropriate.

Cobalt notes that fields not provided by the state may be omitted from a UCC filing response.^[8] An integration should therefore have a deliberate missing-field path instead of presenting absence as evidence of freshness.

How would this work in a real lending review?

Consider an illustrative equipment-finance application reviewed on a Wednesday. The response arrives that morning, a filing is dated months earlier, and a stored-record update timestamp points to an earlier observation. These are invented workflow facts for the example, not a Cobalt customer case.

The analyst's question is whether the evidence meets the lender's pre-funding requirement. The months-old filing date does not automatically make the evidence unusable. Equally, Wednesday's local receipt does not automatically prove a new filing-office retrieval occurred that morning.

What should the analyst compare?

First, confirm the submitted debtor and jurisdiction. Next, inspect the requested mode and the available provider timestamps. Then apply the lender's relevant acceptance policy, recording which evidence supports the result.

If policy requires another retrieval, keep the earlier response and link the new request to the same review. Once the later response arrives, compare the relevant evidence and document the disposition. Do not delete the earlier snapshot simply because it no longer supports the current decision.

What if the second request is still running?

Leave the freshness task unresolved until the required evidence arrives or an authorized reviewer records another permitted route. Cobalt's UCC examples distinguish an incomplete response containing a retry ID from a completed filing response.^[9]

Your interface can show useful progress without overstating it: “New search requested,” “Awaiting result,” and “Evidence ready for review” are different states. That wording makes the next action clearer than replacing every stage with “Updated.”

A timestamp is useful only when the reviewer knows what happened at that time.

How should you test date handling before deployment?

Test with synthetic fixtures that exercise the meaning of the dates, not just their syntax. Include an old filing in a recent stored record, a recent local receipt with no source timestamp, several records with different update times, and a response that arrives after the application has already moved to another review stage.

For each fixture, define the analyst-facing sentence your application should display. Ask an underwriter to explain what the sentence proves and what remains unknown. If the answer exceeds the evidence, revise the label before tuning the code.

Which technical mistakes deserve dedicated tests?

Check seconds-versus-milliseconds conversion where relevant, timezone boundaries, missing offsets, invalid strings, null values, and future dates. Use the actual response contract for parsing rather than assuming all fields share a format. Verify that exporting and reopening the evidence does not change its displayed meaning.

Test daylight-saving and date-only handling if your application converts timestamps into local dates. A display transformation should not silently move a filing event to another day or make a policy boundary depend on the reviewer's browser settings.

Should the result count affect the freshness decision?

Keep count reconciliation separate. Cobalt's standalone UCC API returns up to 30 filings and reports the total found in uccDataCount.^[10] Fresh timestamps on the delivered records cannot establish the state of records that were not included.

A good acceptance test therefore includes a response with recent timestamps but more filings reported than returned. The date check may pass for the inspected records while the overall evidence review remains open for completeness. That is a useful distinction, not a contradictory result.

How should operations choose between reuse and new retrieval?

Define the policy at the decision level. An initial prospect screen, a collateral review before funding, and a loan renewal may have different evidence needs. Do not impose one age label across all three merely because they use the same API integration.

Document the trigger for a new search, the person who can accept an exception, and the evidence required to close it. An exception record should say why the available evidence was accepted for that specific purpose. It should not rename older source evidence as newly retrieved.

What should a repeatable review note say?

Use a short note with four parts: the decision being supported, the dates considered, the policy applied, and the unresolved limitation or final disposition. Link the actual response and any supplemental source record. This gives the next reviewer a way to understand the reasoning without rerunning the search simply to reconstruct the file.

When obtaining source-office evidence, specify what you need. Maryland's UCC guide distinguishes search responses and document copies; those deliverables support different review questions.^[11] A newly obtained copy can establish what you retrieved without changing the document's original filing date.

Track how often your own files need a new retrieval and why. Distinguish age-policy exceptions from missing timestamps, incomplete delivery, and identity problems. That separation helps you address the actual workflow issue instead of attributing every delayed review to “stale data.”

What should you bring to a Cobalt evaluation?

Bring the jurisdictions, review stages, and evidence-age questions your lending process actually uses. Ask to inspect stored and live request behavior, available timestamp fields, delayed responses, and the handling of missing values. Confirm the relevant state is currently supported rather than assuming nationwide standalone UCC coverage.^[12]

The UCC API resource for lenders can help frame the broader integration. For this evaluation, keep the acceptance test narrow: can your reviewer tell when a filing event occurred, when the available record was updated, and when your application received it?

Schedule a Cobalt demo with that test. The goal is an evidence view and review policy that use the documented timestamps accurately, with an explicit path when a clock is missing or cannot answer the question.