Executive Summary: Most monitoring programs fail at the same point. Not at data collection, which works, and not at detection, which also works, but at the moment an alert reaches a human who has no rule telling them what to do with it. An undifferentiated stream of change notifications produces a queue nobody clears, and a queue nobody clears is functionally identical to no monitoring at all. Triage is the part that makes the rest worth paying for.
Why do change alerts fail without a severity model?
Because Secretary of State changes vary enormously in consequence, and an alert stream that treats them equally destroys the information that distinguishes them.
Consider two notifications arriving the same morning. One says a borrower's registered office address changed. The other says the entity's status moved to administratively dissolved. The first is very likely a commercial registered agent updating its own address across every entity it represents, which is a filing the agent itself may make.[1] The second means the state has terminated the entity's good standing and a statutory reinstatement clock is now running.[2]
Delivered identically, both consume the same review time. Since the low-consequence type is far more common, the queue fills with items that resolve to nothing. The predictable outcome is that the team stops reading carefully, and the one alert that mattered gets closed with the same reflex as the forty that did not.
This is why severity classification is not a presentation preference. It is the mechanism that keeps the high-consequence tail readable.
• Volume is dominated by low-consequence changes. Address and agent updates move far more often than status.
• Consequence is concentrated in a few field types. Status and existence changes carry nearly all the downside.
• Blanket alerting inverts attention. The most common items get the most review time.
• Alert fatigue is a silent failure. Nothing breaks, no error appears, and the program quietly stops working.
• Suppression is not the same as ignoring. A change can be logged as context without generating a ticket.
What should map to Critical?
Reserve the top tier for changes where the entity's legal existence or standing has moved, because those are the ones with statutory clocks attached.
Changes that belong here:
• Status moves to administratively dissolved, revoked, or terminated. The entity has lost good standing. In Texas this can follow from failing to maintain a registered agent and registered office.[1]
• Entity name changes. This is the sleeper. A name change can render a financing statement seriously misleading, after which the filing perfects only collateral acquired "before, or within four months after" the change unless an amendment is filed in that window.[3] Four months is the shortest clock in the entire category, and catching it is the secured party's responsibility rather than the debtor's.[4]
• Reinstatement after dissolution. Often good news, and it still requires attention. Reinstatement typically relates back to the dissolution date, so the legal characterization of the intervening period changes.[5]
• Foreign registration revoked in a state where collateral sits. The entity survives, but its authorization to transact business in that state does not.[1]
The defining test for this tier: does the change start a clock, or change the entity's legal capacity? If yes, it is Critical regardless of how routine the underlying cause turns out to be.
That last clause is the one teams argue about, and it is worth defending. The overwhelming majority of administrative dissolutions have mundane causes: a missed annual report, an unpaid franchise fee, a registered agent who resigned over an unpaid invoice. It is tempting to conclude that because the cause is usually trivial, the alert should sit lower in the model.
The reason to resist is that severity should track consequence rather than likely cause. A dissolution triggered by a forgotten $50 filing has exactly the same legal effect as one triggered by genuine insolvency: the entity has lost good standing, a reinstatement clock is running, and the state's characterization of the entity's existence during the gap is now unsettled. The cause determines how the situation resolves. The consequence determines how quickly someone has to look at it, and only the second belongs in a severity model.
Tiering by expected cause also produces a specific and damaging failure. It works correctly almost every time, which builds confidence, and then fails precisely on the rare case where the trivial-looking event was not trivial. Models that are right ninety-five percent of the time and catastrophically wrong in the remaining five are worse than models that are conservative throughout, because the confidence they earn is spent exactly when it should not be.
Name changes are the most under-triaged item in this category. They read as administrative, they often accompany ordinary rebranding, and they carry a four-month deadline that no other Secretary of State change comes close to matching.
What belongs in the middle tier?
Changes that alter the picture without starting a clock. These warrant review on a defined timeline rather than immediate action.
• Officer, director, member, or manager changes. Real signal, arriving late. Because the state records no filing when ownership changes in a corporation or LLC, this information refreshes on the periodic report rather than on the event.[6] Treat as reconciliation against the roster captured at underwriting.
• Principal or mailing address changes. Interesting when the destination is unusual, unremarkable otherwise.
• Registered agent resignation with no replacement filed. A defined statutory window is running: the appointment terminates "on the 31st day after the date the secretary of state receives notice."[1] If unresolved, this escalates to Critical.
• Periodic report filed late but filed. The obligation was met after a lapse. Worth logging as a pattern rather than acting on.
• Entity type or governance structure amendments. Uncommon, and usually deliberate.
The distinguishing feature of this tier is that a few days of delay costs nothing. That is exactly what makes a defined review cycle appropriate and immediate escalation wasteful.
What should be logged rather than alerted?
The bottom tier is where most of the volume lives, and moving it out of the queue is the single most effective triage decision available.
• Registered office address changes driven by the agent. Detectable because many unrelated entities converge on the same new address in a narrow window. Suppress the pattern, keep the record.
• Formatting and normalization differences. "Street" to "St," ZIP+4 replacing a five-digit ZIP, an added suite number. These are string deltas, not changes.
• Registered agent provider switches with a replacement on file. The obligation is continuously satisfied. Nothing happened.
• Periodic report filed on time. Confirmation the entity is behaving normally. Valuable as history, worthless as an alert.
Logged changes should remain queryable, because their value is contextual. When a Critical alert arrives, the question immediately becomes what else has moved recently, and that question is only answerable if the low-tier changes were retained rather than discarded.
Want to see how severity-classified Secretary of State change detection fits into a monitoring workflow? Book a demo.
How should a lender build this from nothing?
Most teams introducing entity monitoring make the same sequencing error: they turn on detection across the whole portfolio, discover the volume, and then try to design triage while the queue is already overflowing. Building the classification before the firehose is considerably easier.
A sequence that works:
Start with a subset, not the portfolio. Take the fifty or hundred largest secured exposures and monitor only those. The volume is manageable, the exposures justify attention, and the first weeks of alerts tell you the actual mix of change types in your book rather than a mix someone assumed.
Log everything, alert on nothing, for one cycle. Run detection with no routing at all for the first month and simply record what arrives. This produces the base rates that the entire triage design depends on: how many address changes, how many agent events, how many status changes. Designing tiers without those numbers is guesswork, and the numbers vary by portfolio composition more than most people expect.
Build suppression before routing. Identify the agent mass-event pattern in your own data first. Until that is filtered, every downstream volume estimate is wrong and every tier looks busier than it is.
Then route the top tier only. Turn on Critical routing before Major. If the top tier is quiet and accurate, the team trusts it, and that trust is what makes the tier work when something real arrives. Adding Major later into a system with credibility is straightforward; recovering credibility after launching with a noisy top tier is not.
Widen coverage last. Extend to the rest of the portfolio once the classification is calibrated. Coverage is the easy part and the part most teams do first, which is why so many programs end up with wide coverage and an unread queue.
The reason this ordering matters is that triage quality determines whether monitoring produces action, and coverage determines only whether it produces alerts. A narrow program with reliable routing outperforms a complete program nobody reads, and it can be widened. The reverse is much harder to fix, because the failure is cultural rather than technical: once a queue is known to be noise, people stop opening it, and turning that around takes longer than building the system did.
One more sequencing note. Decide the disposition rules before the first Critical alert arrives, not during it. The moment a genuine dissolution notice lands is the worst possible time to be debating who owns it, what the escalation path is, and whether legal needs to be involved. Those decisions are cheap to make in advance and expensive to make under time pressure with a statutory clock running.
How should severity translate into an actual workflow?
A severity label with no routing attached is just a colored badge. The classification has to bind to an owner, a deadline, and a defined action.
A workable structure:
• Critical routes to a named owner with a same-day acknowledgment requirement. Not a queue. A person. Queues absorb urgency.
• Critical involving a name change triggers a UCC review automatically. Because the four-month window runs from the change rather than from your discovery of it,[3] and because formation-side amendments are what break lien-side filings.[7]
• Major enters a review cycle with a defined clearance target. Days, not hours, and with an expectation that the queue reaches zero.
• Minor writes to borrower history with no ticket. Available on query, absent from the queue.
• Any Critical shortens that borrower's monitoring interval automatically. Entity problems cluster in time, so a borrower that has just moved deserves closer attention until it stops moving.
• Combinations escalate a tier. Three Minor changes in one window is a restructuring pattern, not three pieces of noise.
That last rule matters more than it appears. Individually unremarkable changes carry real information when they co-occur, and a triage design that only ever evaluates changes one at a time will systematically miss the pattern that matters most.
What does the underlying classification actually give you?
Being precise about the tool's boundary keeps the workflow design honest.
Business Monitoring re-checks a borrower's Secretary of State record on a cadence you configure, from daily up to every 30 days, and reports what changed against the previous check.[8] Changes are detected across the record's field categories and classified by severity, which is what makes the tiering above implementable rather than something you would have to build from raw record diffs. Each completed check costs 1 credit from the shared pool.
What remains your work:
• Scope is the Secretary of State record only. No OFAC or other watchlist screening, no UCC filings, no court dockets, no licenses. Sanctions re-screening stays a customer-side workflow on a customer-side schedule.
• Severity is generic, your policy is not. A name change is high-consequence for a secured lender and much less so for an unsecured one. Map the supplied classification onto your own tiers rather than adopting it unchanged.
• Agent mass-event suppression is portfolio-level. Recognizing that many unrelated borrowers moved to one address requires seeing your whole book, which is a pattern in your data rather than a property of any single record.
• Routing, ownership, and escalation are yours. The classification tells you how consequential a change is. It cannot tell you who should look at it.
The record itself 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"How do you know the triage model is working?
Measure the queue, not the alerts. Three numbers are enough.
Clearance rate. The share of alerts actually reviewed and closed within their tier's target. If Major alerts are not reaching zero, the tier is too broad and items belong in the log rather than the queue.
False positive rate by tier. The share of alerts resolving to no action. High rates in Minor are expected and fine. High rates in Critical mean the tier is miscalibrated and the top of the model is losing credibility, which is the most damaging failure available.
Time from state filing to lender action. The number that actually matters, because it spans both cadence and triage. A one-day detection latency followed by a three-week queue delay is a three-week program. This is the metric to hold against the four-month UCC window, and it is the one most programs never compute.
The pattern worth avoiding: adding data sources while the existing queue goes uncleared. More detection into an unreviewed queue produces more unreviewed items, not more safety. Fix the triage first, then widen the inputs. For the specific changes carrying the sharpest consequences, our guides to entity status transitions and the administrative dissolution reinstatement window set out what each tier is protecting against.[9] Reinstatement windows themselves vary widely by state, from a five-year cap in Georgia to no outer limit in Florida.[10]
.jpg){kind=small}
.png)