Middesk Continuous Monitoring vs Cobalt Business Monitoring: What Each Alerts On

Executive Summary: These two products are compared as though they do the same thing at different prices. They do not. Middesk's monitoring covers five categories of business change. Cobalt's Business Monitoring, launched July 31, 2026, covers one. That difference decides the comparison for most buyers before price, cadence, or delivery model enters the conversation, and it points in Middesk's favour on breadth. What follows is an alert-type-by-alert-type comparison drawn from both vendors' published documentation.

What does each product actually monitor?

The scope difference is the whole comparison, so it goes first.

Middesk's documentation describes monitoring across Secretary of State registrations, TIN registrations, watchlist hits, bankruptcies, and UCC liens. Their overview states that when a business is enrolled, "Middesk automatically tracks and alerts you to important changes like bankruptcy filings, registration updates, and lien activity."^[1] Dedicated pages cover each category, including lien monitoring described as tracking "new and terminated UCC liens for subscribed businesses."^[2]

Cobalt's Business Monitoring re-checks the Secretary of State record on a schedule and reports what changed against the previous check.^[3] Its scope is the Secretary of State record only. It does not monitor watchlists, bankruptcies, UCC filings, court records, or professional licenses.

Stated plainly: if you need one product to watch sanctions screening, bankruptcy, and lien activity alongside entity status, Cobalt's Business Monitoring does not do that and Middesk's does. That is not a close call and it is worth saying before anything else.

The scope difference is also easy to misjudge in the other direction, which is worth guarding against. Breadth in a monitoring product is valuable only for the categories you are not already covering. A lender running sanctions screening through a dedicated compliance platform, pulling UCC data on a separate schedule, and receiving bankruptcy notifications from an existing source does not gain four capabilities by buying a bundle. It gains one, the Secretary of State layer, and inherits three parallel alert streams duplicating systems already in place. Duplicate alerts are not free: they consume the same analyst attention as genuine ones and they erode confidence in the queue.

So the honest way to read the table is not as a score. It is as a checklist to run against your existing stack. Every row where you already have coverage is a row where breadth adds cost rather than protection, and every row where you do not is a genuine gap that a single-category product will not close.

There is one more asymmetry buried in the table. The four categories Cobalt does not monitor are ones where the underlying data sits outside the Secretary of State record entirely, which means no amount of Secretary of State monitoring will ever reach them. That is a permanent boundary of the product rather than a roadmap gap, and Cobalt's own documentation for its OFAC endpoint was updated specifically to say that Business Monitoring does not close the sanctions re-screening gap. A buyer planning around that boundary is planning correctly.

Where the two overlap, what does each send?

Inside Secretary of State monitoring, the products converge on coverage and diverge on delivery.

Middesk publishes granular per-field webhook events. Their documentation lists `address.created`, `address.deleted`, `name.created`, `name.deleted`, `person.created`, `person.deleted`, `registration.created`, and `registration.updated`, describing the SOS monitor as providing "granular events that make it easy to subscribe to specific types of changes."^[4] For status changes specifically, their guidance is to "subscribe to the `registration.created` and `registration.updated` events" and to "detect a change to any field on an existing registration."^[5] The `registration.updated` payload carries a `previous_attributes` object, so the delta arrives with the event rather than being reconstructed on the customer side.

Cobalt classifies detected changes by severity across the record's field categories, so a status change routes differently from an address update rather than arriving as one undifferentiated stream.^[3]

Both are reasonable designs and they suit different teams:

• Per-field event subscription suits an engineering team that wants to bind specific handlers to specific change types and is willing to build the severity logic itself.

• Severity classification suits a credit or portfolio team that wants triage decided before the alert arrives and does not want to encode which fields matter.

• Neither eliminates the triage problem. Both push the routing, ownership, and escalation decisions onto the customer.

• Both surface the same underlying record. The Secretary of State filing is public in either case.

What does each publish about cadence?

This is a documentation difference rather than a capability claim, and it is worth being careful about.

Cobalt publishes a configurable re-check interval from 1 to 30 days, and a cost of 1 credit per completed check drawn from the same shared pool as the rest of its API suite.^[3]

Middesk's published monitoring documentation describes an event-driven webhook model. As of this writing it does not publish a check frequency, and enrollment is gated behind sales contact rather than a published price.^[1]

Do not read that as Middesk checking less often. It means the interval is not documented publicly, so a buyer who needs a specific cadence commitment has to ask for one. For a lender working to a defined clock, that is a real procurement question rather than a product deficiency.

A vendor comparison that reports what one party publishes and infers the rest is not a comparison. Where Middesk does not publish a figure, the honest statement is that it is not published, not that it is worse.

Why does cadence matter enough to ask about?

Because secured lenders are subject to a clock that is shorter than most monitoring defaults.

If a debtor's name changes so that a filed financing statement becomes seriously misleading, the filing perfects collateral acquired "before, or within four months after" the change and stops perfecting later acquisitions unless an amendment is filed inside that window.^[6] Four months is the constraint, and it runs from the change rather than from your discovery of it.

Both products detect name changes. Middesk exposes `name.created` and `name.deleted` events explicitly.^[4] Cobalt treats name changes as a tracked field category. What matters for this specific clock is how quickly a change surfaces and whether your workflow acts on it, which is why the cadence question is worth putting to any vendor in this category rather than assuming it.

Want to see how Cobalt's Secretary of State change detection fits your monitoring workflow? Book a demo.

What does the integration work actually look like for each?

The two models place the engineering effort in different places, and that is worth understanding before a build estimate is written.

Middesk's model is push. You stand up a webhook endpoint, subscribe to the events you care about, and handle each one as it arrives. Their documented pattern for status changes is to receive `registration.updated` and inspect the `previous_attributes` object to see which field moved:^[5]

@app.route('/monitoring_webhook', methods=['POST'])
def monitoring_webhook():
    event = request.get_json()
    if event['type'] == 'registration.updated':
        reg = event['data']['object']
        if 'status' in reg.get('previous_attributes', {}):
            handle_status_change(reg['business_id'], reg['status'])
    return '', 200

Cobalt's model is pull on a schedule you configure, over the same search endpoint used for point-in-time verification:

curl -X GET "https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Holdings%20LLC&state=TX" \
  -H "x-api-key: YOUR_API_KEY"

The practical differences that follow from that split:

• Push requires a public endpoint and its operational burden. Signature verification, retry handling, idempotency, and an availability commitment, because a missed delivery is a missed alert.

• Pull requires a scheduler and state storage. You decide when to check and you keep the previous record to compare against, which is work push hands you for free.

• Push gives you the delta. `previous_attributes` tells you what changed without you having stored anything.

• Pull gives you control of timing. You decide the interval rather than inheriting an undocumented one, which matters when a specific clock binds you.

• Both need the same triage layer. Neither model decides who reviews what.

Neither is simpler in the abstract. Push is less work if you already run webhook infrastructure and more work if you do not. Pull is less work if you already run scheduled jobs against borrower records, which most servicing teams do. Estimating this honestly against your existing architecture is more useful than accepting either vendor's characterization of integration effort.

One asymmetry does favour pull for evidentiary purposes. Because a scheduled check is a request you initiated at a time you chose, the record it returns is straightforwardly attributable to a moment you can name. Push events arrive when the vendor sends them, which is fine operationally and slightly less tidy when the question later becomes what you knew on a specific date.

Which should a lender choose?

The decision follows from what else is already in the stack, not from which product is better.

Choose Middesk's monitoring if you want a single vendor covering entity status, watchlists, bankruptcy, and liens, and you would otherwise be integrating several sources to get there. Consolidation has real operational value and their documented scope genuinely delivers it.

Choose Cobalt's Business Monitoring if the Secretary of State layer is the gap and the rest is already covered. Many lenders already run sanctions screening through a compliance platform, already pull UCC data, and already monitor bankruptcy through another source. For those teams, buying a bundle to obtain the SOS component means paying for four capabilities they have and duplicating alerts they already receive.

Run both if the SOS layer needs a different depth than a bundled product provides. This is less unusual than it sounds, because entity status is the field most lenders act on most often.

Three factors that should carry weight and often do not:

• Whether you need audit evidence, not just notification. Cobalt's live Secretary of State lookups can return a timestamped, watermarked screenshot of the state website. Middesk's `registration.created` payload includes a `source` URL pointing at the state search page.^[5] Both are real artifacts; a dated screenshot and a source link are not equivalent when the question is what a record said on a particular day.

• Whether your team wants to build triage or consume it. Per-field events versus severity classification is a build-versus-buy decision on the routing layer.

• What you already pay for. Overlapping alerts have a cost in review time even when the incremental data cost is small.

What does neither product do?

Worth stating, because a monitoring purchase is often made on the assumption that it closes a gap it cannot close.

Neither detects ownership changes in corporations or LLCs, because no filing is generated when they happen. Texas states directly that "there is no filing requirement with the secretary of state when there is an ownership change" for either entity type.^[7] Officer and people monitoring, which both products offer, surfaces governance changes on the next periodic report rather than equity transfers as they occur. Since the March 2025 FinCEN interim final rule exempted US-formed entities from beneficial ownership reporting, there is no federal registry filling that gap either.

Neither interprets what a change means for your borrower. Both report that something moved. Whether a status change reflects a forgotten $50 filing or genuine distress is a phone call, and whether it constitutes a covenant breach is your loan documents.

Neither clears your alert queue. Detection without triage produces a backlog nobody reads, which costs money and delivers nothing.

Coverage claims should be checked for both. Cobalt's Business Monitoring state coverage is not yet published, and Middesk does not publish a monitoring coverage count either. Ask both.

How should a buyer actually evaluate this?

Five questions, answerable in a single call with either vendor.

• What is the maximum interval between checks, contractually? Not the typical interval. The worst case, because that is what your clock has to survive.

• What is the latency between a state filing appearing and an alert reaching us? Detection frequency and delivery lag are different numbers and both matter.

• Which states are covered for monitoring specifically? Coverage for point-in-time lookup and coverage for monitoring are not necessarily the same set.

• What evidence is produced per check, and how long is it retained? This is the question that separates a notification from an audit record.

• What does the alert volume look like on a portfolio like ours? Ask specifically how registered agent mass-updates are handled, since a commercial agent relocating can move a large block of records at once and generate alerts on borrowers where nothing happened.

For the broader vendor comparison beyond monitoring, our Cobalt and Middesk provider comparison covers the full product surface, and our SOS data comparison for lenders covers the underlying data layer.^[8] Neither of those predates the Business Monitoring launch, which is why monitoring is treated separately here. For what the alerts mean once they arrive, our guide to entity status transitions covers the downstream consequences.^[9]

The summary a buyer can act on: Middesk monitors more categories, Cobalt publishes more about how its Secretary of State monitoring runs and costs, and the right choice depends on which gaps are already filled in your stack. Anyone telling you one of these products simply beats the other has not read both sets of documentation.^[10]