Executive Summary: Every lender running business verification at volume is already using cached registry data, whether or not anyone has decided to. A nightly enrichment job, a vendor's stored copy, a result your own system saved eleven weeks ago and still displays on the underwriting screen: all three are cache. The question worth answering is which fields in a Secretary of State record decay fast enough to corrupt a specific decision, and which decisions are tolerant enough to run on a copy. Those two questions have different answers for status, registered agent, officers, and address, and treating them as one policy is how a funded deal ends up secured against an entity that lost its charter in March. This post is about decay mechanics. It covers what goes stale in an SOS record, how fast, what the state's own filing calendar sets as the maximum possible age of each field, and which credit and compliance decisions each staleness class breaks. For the separate question of how a vendor's copy drifts from the state's copy versus how the state's copy drifts from reality, our SOS API data coverage by state checklist treats freshness as a two-layer property and scores vendors on it. For the provider comparison against a historical-data aggregator, Cobalt Intelligence versus Dun and Bradstreet on real-time and historical data already covers that ground and this post does not repeat it.
What Actually Goes Stale in a Secretary of State Record?
An SOS response is not one fact with one age. It is a bundle of fields, each written into the state's database by a different filing event on a different clock. Treating the whole record as "fresh as of" a single timestamp is the error underneath most staleness incidents, because the timestamp describes when you retrieved the record, not when any individual field was last true.
Four field groups carry almost all the decision risk, and a fifth is worth naming precisely because it carries none.
• Registration status. Active, delinquent, forfeited, administratively dissolved, revoked, withdrawn. This is the field most decisions switch on and the field with the most complex change mechanics, because it moves on tax and filing calendars rather than on anything the business does commercially.
• Registered agent. Name and address of the party authorized to accept service of process. Changes on entity action, at any time, with no periodic prompt in most states.
• Officers and directors. Names, titles, and addresses of governing persons. In most states this field is written only when an annual or biennial report is filed, which caps how current it can possibly be.
• Principal and mailing address. Where the business actually operates and where it receives correspondence. Changes commercially, gets reported to the state late or never.
• Filing date and entity type. Effectively immutable after formation. These do not decay and should not drive any cache policy.
The last item matters because it shows the shape of the problem. If your time-in-business calculation reads `filingDate`, a six-month-old cached record serves it perfectly. If your funding gate reads `status`, the same record may be worthless. The same cache is both safe and dangerous depending on which field the decision touches.
Why Does the State's Filing Calendar Cap How Fresh a Field Can Be?
Because a state registry is a filing system rather than an observation system, and it only knows what somebody filed. The National Association of Secretaries of State describes member offices as handling "the registration of domestic and/or foreign corporations (profit and non-profit)" and notes that "Fees vary from state to state."[1] There is no continuous feed from business reality into a state database. There is a form, a due date, and a penalty.
That means every field written by a periodic report has a statutory maximum age, and you can compute it from the state's calendar without any vendor data at all. Delaware tells the public directly that "Current officers and directors for Delaware corporations can be found on the most recent annual report."[2] Delaware annual reports for domestic corporations "are due annually on or before March 1st."[3] Combine those two sentences and the conclusion is arithmetic: in Delaware, the officer list you retrieve in February can lawfully describe the officers as of the prior March, and nothing about a live API call changes that. Live retrieval gets you the state's current record. It cannot get you a fact the state was never told.
New York sets the cap wider still. Corporations file under "Section 408 of the Business Corporation Law" every two years, and the statement is what updates "the name and business address of its chief executive officer" and "the street address of its principal executive office."[4] A New York CEO field therefore has a statutory ceiling of roughly twenty-four months, and the Department of State is candid about the practical result, observing that "Many companies move their location and neglect to notify the New York Department of State."[4]
Cadence varies enough across states that a single national assumption will be wrong somewhere. Cogency Global's review of state filing requirements records Alaska on "biennial reports," California on an "annual basis for most corporations and on a biennial basis for LLCs," Massachusetts requiring corporations "to file within 2.5 months after the end of their fiscal year and LLCs by their anniversary date," and Washington on "annual reports due by the end of their anniversary month."[5] A per-field, per-state maximum-age table is a half day of work and it permanently ends the argument about whether officer data is current.
How Fast Does Each Staleness Class Actually Decay?
Maximum age is the ceiling. Observed change rate is what you actually plan against, and the two are different numbers.
Start with the underlying commercial churn, because that sets the floor on how often any field can move. The SBA Office of Advocacy reports that "In 2022, 1.4 million business establishments opened for the first time, and about 1.2 million establishments closed permanently," and that across 1994 to 2021 "the five-year survival rate was 49.2 percent."[6] Roughly half of new employer establishments do not reach five years. A portfolio of small-business borrowers is therefore a population in which a meaningful fraction of entities undergo a status-relevant event inside any twelve-month window, and a cache refreshed monthly will be describing some of them incorrectly at any given moment.
Establishment closure is not the same event as registration status change, and the gap between them is itself a source of staleness. A business can stop operating and remain Active in the registry for a full tax cycle, because nothing removes it until a filing deadline passes and an enforcement clock runs.
Why Does a Status Change Arrive in Steps Rather Than All at Once?
Status decay is sequenced, not instantaneous, and that sequence is where cached data does its quietest damage. Texas publishes the escalation explicitly: the Comptroller sends "File Now" courtesy reminders, then issues "Form 05-211, Texas Notice of Intent to Forfeit Right to Transact Business," then "Form 05-212, Texas Notice of Forfeiture of Right to Transact Business," then "Form 05-213, Texas Notice of Forfeiture of Registration."[7]
Read that as a timeline rather than a procedure. An entity that missed its report is, for a period of weeks, still Active in the public record while already inside the forfeiture pipeline. A live pull during that window returns Active and is correct. A cached record returns Active and is also correct. Neither tells you the entity is one notice away from losing the right to transact business. This is the limit of status as a signal, and it is a limit real-time retrieval does not solve.
California attaches its own consequence to the same kind of lapse, warning that failure to file the required Statement of Information "may result in penalties being assessed by the Franchise Tax Board and suspension or forfeiture."[8] Delaware attaches a financial one, where failure to file the annual report and pay franchise tax "will result in a penalty of $200.00 plus 1.5% interest per month on tax and penalty."[3]
What Is the Observed Decay Rate for Agent, Officer, and Address?
Registered agent and address changes are event-driven with no periodic prompt, which makes them the hardest class to reason about. California's guidance is the clearest statement of the mechanism, and also of its weakness: "any time there are information changes in between statutory filing periods, an updated statement should be filed."[8] The obligation is real and the compliance is voluntary in practice, which is precisely why New York reports that companies move and neglect to notify it.[4]
The honest position on rates is that Cobalt does not publish per-field change frequencies by state, and no vendor's published figure would substitute for yours anyway, because change rates are a property of your borrower population rather than of the registry. A subprime MCA book turns over faster than an equipment-finance book. The measurement is straightforward: sample two hundred entities from your own portfolio, pull them live, diff every field against your stored copy, record the age of each stored record, and you have your own decay curve per field within a day. Our guide to benchmarking business verification match rates covers the test-set construction that makes a sample like this defensible.
Which Lending Decisions Does Each Staleness Class Corrupt?
Mapping fields to decisions is the part most teams skip, and it is the part that turns an abstract freshness debate into a policy anyone can enforce.
• Stale status corrupts the funding decision. Advancing against an entity that has been administratively dissolved or has forfeited its right to transact business changes who you can sue and what the borrower's counterparties can do. Texas is explicit that forfeiture is a real loss of transacting rights, not a bookkeeping flag.[7]
• Stale registered agent corrupts collections and legal remedy. The agent is the service-of-process address. New York frames the practical consequence of an outdated one as the risk of a "default judgement" when process cannot be served properly.[4] That risk runs in both directions once you are the party trying to serve.
• Stale officers corrupt fraud screening and beneficial-ownership work. Officer data is what you cross-reference against the application, and the NCUA examiner guidance requires institutions to perform "ongoing monitoring to identify and report suspicious transactions and, on a risk basis, to maintain and update member information."[9] A year-old officer list is a weak input to a control that is supposed to be ongoing.
• Stale address corrupts location-based pricing and site verification. If your model prices state risk or your operations team verifies premises, an address the state has not been told about is a silent failure rather than a loud one.
• Stale status also corrupts lien strategy, on a much tighter clock. This one deserves its own treatment.
Why Is the Lien-Filing Clock Tighter Than Any Other?
Because secured-party priority is decided by filing order, and the filing office is allowed a lag. Under the Uniform Commercial Code, conflicting perfected security interests "rank according to priority in time of filing or perfection," dating from "the earlier of the time a filing covering the collateral is first made or the security interest or agricultural lien is first perfected."[10] The filing office, meanwhile, must index a record "not later than two business days after the filing office receives the record in question."[11]
Those two provisions together define a gap that no data vendor can close. A competing financing statement filed yesterday may not be searchable today, so even a perfectly live search can miss a senior interest that already exists. Add a stale cache on top of that structural gap and the exposure compounds from two business days to whatever your refresh interval is. Financing statements also lapse: a filed statement "is effective for a period of five years after the date of filing," after which the security interest "becomes unperfected, unless the security interest is perfected otherwise."[12] A five-year-old lien in your records may no longer encumber anything, which is a staleness error in the opposite direction and one that costs you deals rather than dollars.
A cache that is wrong about a dissolved entity costs you a loss. A cache that is wrong about a lapsed lien costs you a decline. Most teams only instrument the first one.
Our published guide to how lenders verify UCC filings and state registrations automatically covers the combined workflow, and this post stays on the freshness half of it.
When Is Cached Registry Data the Right Answer?
Cache is correct wherever the cost of being wrong is a wasted step rather than a booked loss, and wherever volume makes live retrieval economically or operationally impractical.
Cobalt's SOS Search exposes the choice directly. With `liveData=false` the response returns in under a second from a copy refreshed monthly. With `liveData=true` the lookup runs against the state source and takes ten to one hundred eighty seconds depending on the state. The cached mode's monthly refresh is the limitation to design around: worst case, a cached record can be roughly thirty days behind the state's own record, which is acceptable for triage and unacceptable for a funding gate.
Four workflows where cached data is the better engineering choice.
• Prequalification and lead triage. You are deciding whether to spend an underwriter's attention, not whether to move money. A thirty-day-old Active flag is sufficient evidence to continue the conversation.
• Batch enrichment of an inbound file. Ten thousand applications overnight cannot each wait ten to one hundred eighty seconds. Cache the sweep, then escalate only the records that fail a rule.
• Name and entity-ID resolution. Matching an applicant string to a legal entity uses `title`, `sosId`, `entityType`, and `filingDate`, all of which are stable. Resolving identity from cache and verifying status live is the correct split.
• Portfolio-wide reporting and dashboards. Aggregate counts do not change materially on a thirty-day lag, and running live pulls to populate a chart is a poor use of credits.
• Anything driven by immutable fields. Time in business, state of formation, and entity structure do not decay, so paying for freshness on them buys nothing.
When Is a Live Pull Non-Negotiable?
Live retrieval earns its latency wherever the output of the call is the last thing standing between your capital and an entity you cannot verify again before the money moves.
• Immediately before funding. This is the decision the whole product exists to protect. Pull live, and pull it close to the disbursement event rather than at application intake.
• Before filing or amending a lien. The two-business-day indexing window is already working against you.[11] Do not add cache latency to a structural gap.
• On any high-value advance. Set a dollar threshold in policy and make live verification mandatory above it, regardless of how recently the record was cached.
• When the cached record shows anything other than a clean Active status. A cached non-Active result is a reason to re-verify, never a reason to decline outright, since the entity may have cured.
• When you need audit-grade evidence. Cobalt's `screenshot=true` parameter returns a timestamped image of the state page at the moment of verification, which is the artifact an examiner or a litigator asks for. Those screenshot URLs are valid for three to thirty days, so download and store them in your own system of record rather than referencing the URL later.
A note on Delaware, because it is the state where the live-versus-cached tradeoff has a direct cost attached. Delaware's own online service charges $10 for an option that "will return a screen displaying the current status of the entity you requested which can be printed" and $20 for a status option that returns "the status, the last 5 filings, franchise tax assessment, total authorized shares (if applicable), and tax due."[13] That is a state fee, passed through at cost rather than marked up. Worth knowing before you build a policy that pulls Delaware live on every touch: Delaware also tells users that its Entity Status product "is not a good standing certificate, certified by the Secretary of State."[2] If your credit agreement requires a certified certificate, no API tier substitutes for the certificate itself.
How Do You Build a Waterfall That Uses Both Correctly?
The pattern that works is cache-first for resolution, live for decision, with the escalation rule written in policy rather than left to whoever is on shift.
Step one resolves the entity from cache in under a second.
curl --location 'https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Corp&state=delaware&liveData=false' \
--header 'x-api-key: Your_API_Key' \
--header 'Accept: application/json'Step two escalates to a live pull with an audit artifact when the decision requires it.
curl --location 'https://apigateway.cobaltintelligence.com/v1/search?sosId=1234567&state=delaware&liveData=true&screenshot=true' \
--header 'x-api-key: Your_API_Key' \
--header 'Accept: application/json'Two implementation details decide whether this holds up in production. First, escalate on `sosId` rather than `searchQuery` once the cache has resolved it, because entity-ID lookup is the more precise of the four supported search methods and removes name-match variance from the step that matters. Second, plan for the slow states. Oregon live lookups can take up to five minutes, which exceeds most synchronous request timeouts, so the API returns a `retryId` for polling and accepts a `callbackUrl` for asynchronous delivery. Our sibling post on automating filing status updates via API covers point-in-time recheck patterns, and the async webhook architecture for SOS lookups covers the callback plumbing in detail.
One more design rule: store the retrieval timestamp and the mode alongside every result. A record in your database that does not record whether it came from a live pull or a cached one is a record you cannot make a freshness decision about later, and rebuilding that provenance after the fact is not possible.
How Should You Audit Your Own Staleness Exposure?
Most teams discover their exposure during a loss review. The cheaper path is a scheduled audit against the fields, not against the vendor.
• Inventory every stored SOS field and the decision that reads it. If a field is not read by any rule, stop storing it. If it is read by a funding rule, it needs a freshness policy.
• Compute the statutory maximum age per state for every periodic-report field. Delaware's March 1 corporate deadline and New York's biennial Section 408 statement are the two anchors worth starting from.[3][4]
• Measure your own observed change rate. Sample, pull live, diff, record. Repeat quarterly and watch whether the curve moves with your origination mix.
• Set a maximum tolerated age per decision, in writing. Prequal might tolerate thirty days. Funding might tolerate an hour. Lien filing tolerates the live call and nothing else.
• Instrument the failures in both directions. Count how often a cached Active turned out to be non-Active on live re-pull, and also how often a cached non-Active turned out to have cured. The second number is your false-decline cost and it is usually unmeasured.
Whether the escalation runs against a bought API or something built internally changes the cost curve but not the decay mechanics, and the build-versus-buy cost comparison for SOS APIs works through that side. The SOS API field reference documents which fields the response carries, and the pre-purchase testing checklist covers how to verify a vendor's live and cached behavior before you sign. For the wider selection question, our pillar guide to the top Secretary of State API solutions for verifying businesses compares the providers.
The framing that survives contact with production is narrow. Cached data is a claim about what the state said last month. Live data is a claim about what the state says now. Neither is a claim about what is true, because the state itself only knows what was filed, and the filing calendar is the ceiling on how current any of it can be. Design for that ceiling and the cache-versus-live question becomes a per-field policy rather than a standing argument.
.jpg){kind=small}
.png)