Executive Summary: Most lending teams that want to automate filing status updates do not actually want continuous surveillance. They want a scheduled job that re-reads a borrower's Secretary of State record, compares it to what the file already says, and writes the difference somewhere a human will see it. That is a point-in-time recheck pattern, and it is a smaller engineering problem than it looks, provided you get the scheduling triggers, the async handling, and the status normalization right. This guide covers those three things and is explicit about where the pattern stops working.
What is a filing status update, and why does the value decay so fast?
A filing status is the state's current answer to one question: is this entity in good standing with the office that chartered it. The answer is authoritative on the day you ask and carries no warranty about any day after that.
Cogency Global puts the limitation plainly in its guidance on good standing certificates: "A Good Standing Certificate reflects the records of the filing office on the day that it was issued. Status can sometimes change unexpectedly."[1] That is why transactional practice still uses bring-down verification on closing day rather than relying on a certificate pulled two weeks earlier. Automating filing status updates is the programmatic version of the same instinct.
What decays, and on whose schedule?
The decay is not uniform across the record, which matters because it determines what a recheck can and cannot surface.
• Status fields change on state action. Administrative dissolution, revocation, suspension, and tax forfeiture post when the state acts, not when the business does anything.
• Report-driven fields change on a filing cycle. Officer, manager, and address data refresh when the next periodic report is filed, so checking those fields more often than the cycle produces no new information.
• Deadline-driven changes are predictable to the day. Florida corporations must deliver the annual report "by 5 p.m. Eastern Time on the third Friday in September of each year," and administrative dissolution for failure to file "must occur on the fourth Friday in September of each year."[2]
• Some states now require faster updates than the annual cycle. Connecticut, effective January 1, 2025, requires that "key information must be corrected when it changes, rather than waiting until the next reporting year."[3]
• Penalty accrual starts immediately. Delaware domestic corporation annual reports and franchise taxes are due "on or before March 1st," and failure "will result in a penalty of $200.00 plus 1.5% interest per month on tax and penalty."[4]
Why is this a workflow question rather than a data question?
Because the information was public and correct the entire time nobody was reading it. A borrower that lost good standing in October is not a data-quality failure at your vendor. It is a scheduling gap in your operation. Cogency Global describes the broader direction of travel as states moving away from treating annual reports as "static checkpoints required to maintain good standing" and toward active registry maintenance with faster update duties.[3] Registries are getting more current. Lender files generally are not.
Why is a single origination check no longer defensible for secured exposure?
Because at least one statutory clock runs shorter than most portfolios' review cycle, and it runs from the borrower's action rather than from your discovery of it.
Under UCC Article 9, when a debtor name change makes a filed financing statement seriously misleading, that statement "is not effective to perfect a security interest in collateral acquired by the debtor more than four months after the filed financing statement becomes seriously misleading, unless an amendment to the financing statement which renders the financing statement not seriously misleading is filed within four months."[5] NCS Credit is direct about where the burden falls: "Creditors need to exercise diligence in monitoring debtors for changes of their name and address."[6]
Four months is the constraint that sets a floor on recheck frequency for secured lending. Our sibling analysis on how often to re-check a Secretary of State record works through the interval arithmetic in detail, including why a cadence of exactly four months does not protect you.[14]
What does the supervisory expectation look like?
Two threads pull in different directions here. On beneficial ownership, FinCEN issued an order on February 13, 2026 that removed the requirement to identify and verify beneficial owners at every new account opening, while preserving the obligation to re-verify when facts suggest existing information is unreliable and to continue risk-based ongoing due diligence.[7] The relief is real and it is narrow. Nothing in it lowers the bar on noticing that an entity's registration lapsed.
On third-party oversight, the federal banking agencies published a community bank guide on May 3, 2024 as a companion to the 2023 interagency guidance, framing the expectation as banks appropriately identifying, assessing, monitoring, and controlling third-party risks across the relationship life cycle.[8] If your entity data arrives through an API, the recheck job is part of how you evidence that oversight.
The examiner question is rarely "did you verify this borrower." It is "when did you last verify this borrower, and can you show me the response you acted on." A recheck job answers the second question. An origination-only check answers neither.
What does a point-in-time recheck actually return?
Before designing scheduling, it is worth being concrete about the payload, because half the design decisions follow from the field list.
A Cobalt Secretary of State lookup is a single GET against the search endpoint. The same call that runs at origination is the call that runs on recheck, which is the property that makes the whole pattern cheap to build.
curl --location 'https://apigateway.cobaltintelligence.com/v1/search?sosId=0803214561&state=texas&liveData=true&screenshot=true' \
--header 'x-api-key: Your_API_Key' \
--header 'Accept: application/json'The response carries the fields a recheck comparison runs against:
{
"status": "complete",
"statusCode": 200,
"requestId": "abc123-def456",
"results": [
{
"title": "ACME CORPORATION",
"filingDate": "2015-03-15",
"status": "Active",
"entityType": "Corporation",
"stateOfFormation": "Delaware",
"registeredAgent": {
"name": "CT Corporation System",
"address": "1209 Orange St, Wilmington, DE 19801"
},
"sosUrl": "https://icis.corp.delaware.gov/ecorp/...",
"screenshotUrl": "https://screenshots.cobaltintelligence.com/..."
}
],
"possibleAlternatives": []
}Which fields belong in the comparison set?
Not all of them, and choosing badly is the most common reason recheck jobs get switched off after a month.
• `status` is the field the job exists for. Any transition away from the state's active value is a decision event.
• `title` matters for secured lenders specifically. A legal name change is what starts the four-month UCC amendment clock described above.
• `registeredAgent` is a leading indicator. Agent resignation frequently precedes a lapse rather than following it.
• `filingDate` should never change. If it does, you are almost certainly comparing two different entities, which is a match-quality failure rather than a status change.
• `officers` deserves care. Officer data availability varies by state, and a field the state stopped publishing looks identical to a field where the officers departed.
• `physicalAddress` and `mailingAddress` are noisy. Useful in aggregate, poor as individual alert triggers.
Why search by entity ID rather than name on recheck?
Because on the second and every subsequent lookup you already have the state's own identifier, and using it removes the entire class of match-quality problems. The endpoint accepts `sosId` directly, which is the most precise of the four supported search methods. Name search remains the right choice at origination, where you have an application and not yet an identifier, and the `possibleAlternatives` array exists precisely because exact name matching across 50 registries is unreliable. Once you have resolved the entity once, stop re-resolving it.
How do you build a recheck job that survives contact with 50 state registries?
This is where most in-house implementations get expensive, and the reason is that state systems have wildly different response characteristics.
Live lookups take 10 to 180 seconds depending on the state. Most states return in 10 to 30 seconds. Oregon can take up to five minutes. Delaware takes 15 to 30 seconds. Any recheck job written on the assumption of a fast synchronous response will time out somewhere in the tail and quietly drop those borrowers from coverage, which is worse than not running the job at all because the coverage gap is invisible.
How should the job handle long-running states?
The endpoint offers two paths, and a batch recheck job should use both.
For a callback, pass a `callbackUrl` and let the result arrive when the state responds:
curl --location 'https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Holdings%20LLC&state=oregon&liveData=true&callbackUrl=https://yoursite.com/webhook' \
--header 'x-api-key: Your_API_Key'For polling, the initial response carries a `retryId` that you present on subsequent calls until `status` returns `complete`. The mechanics of receiving and validating asynchronous results, including signature handling and replay behavior, are covered in our guide to async webhook architecture for SOS lookups, so this article will not restate them.
What retry behavior is correct?
Standard distributed systems practice applies, and it is worth following rather than inventing. AWS prescriptive guidance describes exponential backoff as the pattern for transient failures and is specific about the precondition: "Operations should be idempotent when you use the retry with backoff pattern. Otherwise, partial updates might corrupt the system state."[9] The same guidance recommends failing fast on non-transient errors rather than retrying into a wall.
A recheck lookup is a read, and HTTP defines GET as idempotent in RFC 9110 section 9.2.2, meaning repeated identical requests carry the same intended effect as one.[10] That makes retries safe at the protocol level. What is not automatically safe is your side of the write: if the job records a status change and then retries after a partial failure, you can emit the same alert twice. Deduplicate on `requestId`, which the API returns on every response and which also serves as the log key for regulatory defense.
How do you develop against this without burning credits?
Use the `test` parameter, which accepts `complete`, `incomplete`, `failed`, `retryIdInvalid`, and `badRequest`. Build the failure branches first. A recheck job that only handles the happy path is a job that silently stops covering the borrowers most likely to be in trouble, since distressed entities are disproportionately the ones producing odd registry responses.
When should a recheck fire, and what should trigger it?
Schedule alone is the weakest design. It is also the one most teams ship, because a cron expression requires no product thinking.
Three trigger classes are worth combining, and the cost profile makes combining them easy: each lookup is 1 credit from the same pool as the rest of the API suite, so trigger design is about analyst attention rather than data spend.
• Calendar triggers tied to the borrower's state. A check placed shortly after a state's filing deadline extracts far more than the same check placed at random. Florida's fourth Friday in September is a known date. Delaware's March 1 is a known date.[2][4]
• Money-movement triggers. Verify immediately before a material advance on a revolving facility. The verification is worth most at the moment the money moves, not at the moment the calendar turns.
• Document triggers. Any borrower-supplied document naming the entity differently than your file is a name-change signal and should force a lookup rather than a ticket.
• Portfolio-event triggers. Missed payment, NSF, or covenant breach should escalate the entity check, because entity-level and payment-level distress cluster.
• Renewal and refinance triggers. Treat a renewal as a new origination for verification purposes rather than inheriting the prior file's status field.
Where does point-in-time recheck stop and change detection begin?
At the point where you want to be told about a change rather than go looking for one. A recheck job is a pull: you decide when to ask, and you own the comparison, the storage of prior state, and the alerting logic. Continuous change detection inverts that. If what you need is a maintained baseline that is rechecked on an interval you configure and reports what changed against the previous check with changes classified by severity, that is a different product surface, and Business Monitoring for Secretary of State change detection is the right starting point rather than a scheduled job you maintain.[13] For choosing which borrowers justify that treatment, see which borrowers need continuous SOS monitoring.
Point-in-time rechecks are the right pattern when the trigger is yours, the population is event-driven, and you already have somewhere to put the result. They are the wrong pattern when you are trying to reconstruct continuous coverage out of a tight cron interval.
How do you compare status values across 50 different registries?
This is the part that quietly consumes the engineering budget on in-house builds, and it is unglamorous enough that it rarely appears in the original estimate.
States do not agree on vocabulary. New York records a non-filing corporation or LLC as "past due in the filing of its Biennial Statement," and any certificate of status obtained from the Department of State "will reflect that the corporation or LLC is past due," which "may prevent the corporation or LLC from completing certain business transactions."[11] California frames the same failure as an assessment matter: failure to file the Statement of Information "may result in penalties being assessed by the Franchise Tax Board and suspension or forfeiture."[12] Florida calls the endpoint administrative dissolution.[2]
Three registries, three vocabularies, one underlying condition: the entity stopped meeting a periodic obligation. A recheck job that string-compares raw state values will either alert on cosmetic wording differences or miss real transitions, and both failure modes get the job disabled.
What does normalization actually buy you?
The API returns a normalized status alongside the raw state value, which means the comparison logic runs against a stable vocabulary while the raw value stays available for the file. That is the difference between one comparison rule and 51 of them. For interpretation workflow across states, see our forthcoming cluster guide on reading registration statuses across states via API, and for the meaning of individual state status codes, our state definition pages such as Alabama entity status definitions own that ground in detail.
Does a status change always mean what you think it means?
No, and this is worth building into the alert copy rather than leaving to the analyst. Washington began requiring email addresses in key contact sections of business filings effective January 20, 2026, and "filings that omit required electronic contact information may be rejected."[3] A rejected filing produces a status consequence that has nothing to do with the borrower's solvency. Administrative changes and financial distress present identically in a status field, and the delta tells you what changed rather than why.
What are the real limits of automating filing status updates?
Stating these up front is not modesty. It is the difference between a recheck job that gets trusted and one that gets quietly bypassed after its first surprise.
• Delaware status checks carry a state-imposed pass-through fee of $10 or $20 per lookup depending on the status tier. The Division of Corporations sells a $10 tier returning current status and a $20 tier adding the last five filings, franchise tax assessment, and tax due.[15] That is a state fee rather than a Cobalt surcharge, passed through at cost, and it makes high-frequency Delaware rechecking a deliberate budget decision rather than a default.
• New Jersey status data is restricted by statute and requires a small fee.
• Oregon can take up to five minutes on a live lookup, which means any recheck batch including Oregon borrowers must be built asynchronously rather than retrofitted later.
• Officer data availability varies by state. The API returns what the state publishes, so an empty officers array is frequently a state policy fact rather than a corporate one.
• Screenshot URLs are valid for 3 to 30 days. For audit purposes you must download and store the image in your own system of record. A link in a loan file will eventually resolve to nothing.
• Cached mode refreshes monthly. Running a recheck with `liveData=false` returns in under a second and is appropriate for pre-screening, but it cannot detect a change that happened after the last refresh. Recheck jobs that exist to catch changes should run live.
• Scope is the Secretary of State record. No OFAC screening, no court dockets, no professional licenses. UCC filing data is available on the same call via `uccData=true`, but sanctions and litigation re-screening remain separate workflows on separate schedules.
The last point is the one most often misunderstood at procurement. Automating filing status updates gives you a current registration picture. It is a data source feeding your decisioning, not the decision. Where the SOS check sits relative to the rest of the stack is covered in our overview of what Cobalt Intelligence offers and in the best KYB APIs for lending risk assessment breakdown.
What does an audit-ready recheck record need to contain?
A recheck that nobody can reconstruct six months later has operational value and no evidentiary value, and the gap between the two is a handful of fields.
Store the response, not a summary of it: the `requestId` for API-side log correlation, the timestamp of your call rather than the state page's, the normalized and raw `status` values, the `sosUrl` pointing at the state's own record, and the downloaded screenshot image if you requested one. The screenshot is watermarked with the date and time of verification and carries no Cobalt branding, which is what makes it usable as proof that verification happened at the moment of decision.
How does this connect to the build-versus-buy question?
The recheck job itself is not the expensive part. Scheduling is a solved problem in every stack. The expense sits in the 50 registry integrations behind it, their individual failure modes, their format changes, and the normalization layer that keeps your comparison logic to one rule instead of 51. Our SOS API versus building in-house cost comparison works through that arithmetic, and the pillar guide to top Secretary of State API solutions for verifying businesses compares the providers that offer it. For teams starting further back, how to verify business registration status via API covers the first lookup.
The summary a risk lead can act on: automate the recheck at the trigger points where money is at risk, use entity ID rather than name after the first resolution, build the async path before you need it, normalize before you compare, and store the response rather than a conclusion drawn from it.
.jpg){kind=small}
.png)