Executive Summary: Detection is the easy half. The half that decides whether a monitoring programme changes any outcome is where the alert lands, what it is attached to, and whether the person who sees it has enough context to act. A change notification sitting in a separate tool is not part of a credit process. This is a data modeling problem, and getting the model wrong is what produces the familiar result of a monitoring feed nobody reads.
Why does an alert need a home in the loan system?
Because an alert without exposure attached to it cannot be prioritized, and prioritization is the entire point.
A Secretary of State change arrives as a fact about an entity: this business's status moved, this name changed, this officer was added. What a credit team needs is a fact about a position: this borrower, with this balance outstanding, this collateral, this remaining term, and this guarantee, has had its entity status move. The second is actionable and the first is trivia, and the difference between them is a join.
That join is why a separate alerting tool underperforms even when its detection is perfect. The information needed to triage lives in the loan system, so triage happens there or it happens badly.
Three consequences follow, and they shape the whole design:
• The borrower record is the anchor. Alerts attach to a borrower, not to a notification queue.
• Exposure has to be resolvable at alert time. If the handler cannot look up the balance, a human will, which puts a manual step in front of every alert.
• History has to be queryable from the same place. The first question after any significant alert is what else has moved recently.
What is the minimum data model?
Four tables, and most loan systems can accommodate them without schema changes by using existing extension mechanisms.
A monitored entity record. One per borrower entity, holding the legal name as filed, the state of formation, the state file number, the monitoring tier, and the enrollment status. This is the bridge between your borrower key and the state's record. The file number and state pair is the most durable natural key available, because it originates with the state rather than with any vendor or internal process.
An observation record. One per completed check, holding the timestamp, the full record returned, and a reference to any evidence artifact. This is what makes comparison possible and it is also the audit trail. Do not store only the latest.
A change record. One per detected difference, holding the field, previous value, new value, severity, the state's effective date where available, and the date you detected it. Keeping the state's date separate from your detection date matters, because every statutory clock runs from the former and every service-level measurement runs from the latter.
A disposition record. One per change requiring action, holding the owner, the decision, and the closure timestamp. Without this the programme has no way to demonstrate that anything was done.
The observation table is the one most often skipped, on the reasoning that only changes matter. It is worth keeping because a monitoring programme's most common failure is silent non-coverage, and a borrower that stops being checked produces no changes, which is indistinguishable from a borrower that is stable. Only the observation record can tell those apart.
It also solves a problem that appears later and is expensive to fix retroactively. When a monitoring programme is questioned, whether in an audit, a dispute, or a post-loss review, the question is rarely "what changed." It is "what did you know, and when." Answering that requires the record as it stood on a given date, not the current record plus a list of deltas. Those are not equivalent, because a deltas-only design cannot reconstruct a state it never stored, and any gap in the change log becomes a gap in the reconstruction.
Storage cost is the usual objection and it is weak. A Secretary of State record is small, checks are infrequent relative to most operational data, and the volume for even a large portfolio at a monthly cadence is modest against anything else a loan system retains. Retention should be set against the longest reinstatement window you are exposed to rather than against a default retention policy, since Georgia's five-year cap means a period may need reconstructing years later.
One design note that makes this considerably cheaper: store the full returned record on change, and a hash plus timestamp when nothing changed. That preserves proof that a check occurred and found no difference, which is what demonstrates coverage, without storing an identical copy of the same record every cycle.
How should entity status be modeled?
Not as a copy of whatever string the state returned. That is the mistake that propagates everywhere.
State vocabularies are not standardized. "Not in good standing," "delinquent," "administratively dissolved," "revoked," and "terminated" carry different meanings in different jurisdictions, and some states use several of them for conditions others express with one. Our guide to entity status transitions covers what each label costs a lender.[1]
Store two fields, always:
• The raw status exactly as returned, including any sub-status and status detail, unmodified. This is the evidence and it must not be lossy.
• Your normalized status, drawn from a small internal vocabulary you control.
Then do all downstream logic, routing, reporting, and credit policy against the normalized field. That single discipline is what makes a future vendor change a mapping exercise instead of a rewrite, and it is what stops a state adding a new status string from silently breaking a rule somewhere.
Keep the normalized vocabulary genuinely small. Something like active, adverse-curable, adverse-terminal, and unknown covers most credit decisions. Resist adding a category for every state's terminology; the whole purpose is to collapse that variation into decisions you actually make differently.
The `unknown` value deserves to exist and to be routed. An unmapped status should raise something rather than defaulting to no change, because a status the mapping has never seen is exactly the case most likely to matter.
Where should each severity land?
Match the destination to the decision, not to the data type.
• Status and name changes to a credit action item on the borrower record. These carry clocks. Name changes especially, because a change making a financing statement seriously misleading leaves it perfecting only collateral acquired "before, or within four months after" the change unless an amendment is filed inside that window.[2] That is far shorter than most review cycles, catching it is the secured party's responsibility,[3] and the governing name is the one on the state's formation record.[4]
• Officer and people changes to a review task on the next scheduled review. Real signal, arriving late, because no filing is generated when ownership changes in a corporation or LLC.[5]
• Address and registered agent changes to borrower history only. Context, not tickets. They modify the severity of other alerts rather than generating their own.
• Anything unmapped to an exception queue with an owner. Small volume, high value.
The routing decision that matters most is which changes do not become tickets. A queue that receives everything is a queue that gets read once.
What breaks when the mapping is wrong?
Four failure modes, all quiet, which is why they persist.
Raw statuses propagate into business rules. A rule written against a specific state's exact wording works until a different state returns something similar but not identical. The rule does not error; it simply does not fire.
Detection date is used as event date. If only one date is stored, every statutory calculation runs from when you noticed rather than from when the state acted. Reinstatement windows and amendment windows both run from the state's date, and the gap between the two is often weeks.
Alerts attach to the wrong entity. Borrowers with similar names, or a borrower and its affiliate, get merged by a fuzzy match. This produces alerts on the wrong exposure, which is worse than no alert because it is acted on.
Closed accounts keep generating alerts. Nobody notices immediately because the alerts look normal, and analyst time gets spent on positions with no exposure behind them.
Want to see how Secretary of State change detection maps into an existing servicing workflow? Book a demo.
How do you model a borrower with more than one registration?
Single-entity assumptions break on the first borrower with a footprint, and the breakage is subtle enough to survive testing.
A business formed in Delaware and qualified to transact business in Texas, Florida, and Georgia has four registrations. Each has its own status, its own registered agent, its own periodic filing obligation, and its own capacity to lapse independently. Texas applies the continuous registered office requirement to registered foreign entities as well as domestic ones, and for a foreign entity the consequence of failing to maintain one is revocation of its registration to transact business rather than termination of the entity.[10]
That distinction has to survive into the data model, because the two conditions call for different responses:
• Model one monitored entity record per registration, not per borrower. A borrower has many; the join is one-to-many and collapsing it loses the state dimension entirely.
• Flag which registration is the domestic one. Entity status for existence purposes is governed by the state of formation, so that record is authoritative for whether the borrower still exists.
• Flag which registrations sit where collateral is located. A revocation in a state where you hold nothing is different from one where your position sits.
• Normalize status per registration, never per borrower. A borrower is not "delinquent"; a specific registration in a specific state is.
• Derive a borrower-level rollup separately, and treat it as a view. Useful for reporting and dangerous as a source of truth, because the rollup discards exactly the state detail that determines the response.
• Resolve statutory windows against the registration's state, not the borrower's address. Reinstatement clocks differ enough that using the wrong state produces a wrong deadline rather than an approximate one.
The sequencing point is worth knowing when tuning severity. Foreign registrations are frequently the first thing a struggling business stops paying for, because the cost repeats in every state and the immediate consequence is invisible. A lapse in a non-home state often precedes trouble in the home state by a reporting cycle or more. That makes it one of the earlier observable signals available, despite being one of the least severe on its face, and a model that only tracks the state of formation cannot see it at all.
This is also where the observation table earns its place a second time. A borrower whose Georgia qualification quietly stopped being checked will produce no Georgia alerts, and a borrower-level rollup will report the borrower as monitored. Only a per-registration observation record makes partial coverage visible.
How should the integration actually be wired?
Through whatever asynchronous pattern your systems already use rather than a new one built for this.
Cobalt's API supports polling with a `retryId` and a `callbackUrl` for results delivered on completion, and the underlying record is the same one a point-in-time lookup returns:
curl -X GET "https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Holdings%20LLC&state=TX" \
-H "x-api-key: YOUR_API_KEY"Our guide to async webhook architecture for Secretary of State lookups covers that plumbing, so it is not restated here. What is specific to this mapping problem sits above the transport:
• Write the observation before evaluating it. If the evaluation logic throws, the observation is still recorded and the borrower has not silently gone unchecked.
• Make change detection idempotent on the state's effective date plus field. Re-processing must not create duplicate action items, and retries are normal.
• Resolve exposure at write time, not at read time. Store the balance and collateral snapshot alongside the change. Reading it later gives you today's exposure rather than exposure at the moment of the event.
• Preserve the evidence reference. Cobalt's live lookups can return a timestamped, watermarked screenshot of the state website, and the change record should point at it. This matters because reinstatement can retroactively re-characterize a period, and Florida's statute preserves the rights of a party who acted in reliance on a dissolution before learning of the reinstatement.[6]
What should this system deliberately not try to do?
Scope discipline here prevents building something that overpromises.
• It should not make credit decisions. It routes facts to people with authority. Automated adverse action on a status change is how a forgotten $50 filing terminates a performing relationship, and most administrative dissolutions are curable.
• It should not attempt to explain causes. A status change does not say why. That is a phone call, and our guide to the first 24 hours after a status alert covers the sequence.
• It should not model statutory windows as a single rule. Reinstatement clocks vary sharply: Georgia caps at five years,[7] Florida has no outer limit, and Texas allows reinstatement indefinitely while limiting retroactive effect to three years.[8] Store the state of formation and resolve the window per state.
• It should not be the system of record for anything but its own observations. Exposure lives in the loan system. Entity truth lives with the state.
And the boundary that governs the whole design: the monitoring feed covers the Secretary of State record only.[9] No OFAC or other watchlist screening, no UCC filings, no court dockets, no professional licenses. Sanctions re-screening remains a customer-side workflow on its own schedule. A data model that implies otherwise will have empty tables that look like clean portfolios.[10]
.jpg){kind=small}
.png)