Executive Summary: A portfolio sweep is a one-time, full-population recheck of every borrower's Secretary of State registration, run against a deadline and producing a decision list rather than a dashboard. Lenders reach for one at three moments: the annual credit review, diligence on a portfolio they are about to buy, and the audit that follows a fraud loss. The engineering is not difficult. What breaks sweeps is a batch design that assumes uniform response times, a credit budget that ignores state pass-through fees, and an exception queue nobody sized before launch.
When does a full-portfolio registration sweep beat leaving the work to monitoring?
A sweep and a monitoring subscription answer different questions. Monitoring reports what changed since the last check on the accounts you enrolled. A sweep reports the current state of every account, including the ones nobody enrolled, the ones bought from a seller whose diligence you did not run, and the ones predating today's policy.
Which three sweeps actually get funded?
Each has a different owner, deadline, and tolerance for exceptions.
• The annual or periodic credit review. The credit committee needs a current registration picture across the book on a fixed date. Cogency Global describes the underlying step plainly: obtaining a good standing certificate "to confirm that the borrower is properly formed and registered in the states where it conducts business."[1] A sweep is that step at portfolio scale.
• Acquisition diligence on a purchased book. The OCC is direct that this population deserves more work than a one-off purchase: "Due diligence on bulk loan purchases generally warrants further credit analysis than discrete loan purchase transactions."[2] An independent loan review published in April 2026 makes the same point from the buyer's side, listing "missing files, improperly recorded mortgages, lapses in UCC filings, or inadequate collateral insurance" among gaps that "can each compromise the bank's position," and worth finding before closing.[3]
• The post-incident audit. After a loss traced to a dissolved or misidentified entity, the board asks how many more are in the book. That question has one honest answer, which is a full-population recheck. Nothing narrower survives the follow-up about the accounts you chose not to check.
Why does a sweep expire the moment it finishes?
Because a registration status is authoritative on the day you read it and carries no warranty for any day after. A sweep produces a snapshot with a known timestamp, which is what an annual review or a purchase agreement needs, and what a live portfolio outgrows within weeks.
That decay is not speculative. Under UCC Article 9, a debtor name change that makes a filed financing statement seriously misleading leaves the statement ineffective for collateral acquired "more than four months after the filed financing statement became seriously misleading, unless an amendment to the financing statement which renders the financing statement not seriously misleading is filed within four months."[4] A sweep that surfaces a name change three months after the fact leaves you one month of runway. An annual sweep will sometimes surface it after the window has closed. The sweep is therefore the beginning of a coverage decision, and the tiering section below covers where the output goes next.
How do you scope a sweep before spending the first credit?
Scoping is where sweeps are won, because a lookup against a bad input costs the same credit as a good one and returns something an analyst has to read.
What does the portfolio list need to contain?
The input file, not the API, determines how much of the sweep lands cleanly.
• Legal name as filed, separated from the DBA. Origination systems frequently store the trading name in the legal name field. Sweeping trading names produces a large low-confidence pile that looks like a vendor accuracy problem and is an intake problem.
• State, and the right one. The registration state is the state of formation or qualification, often not the mailing address state. Records missing a state code cannot be swept and belong in a pre-sweep remediation list.
• The state entity identifier wherever your file holds it. Searching by `sosId` is the most precise of the four supported search methods and removes an entire class of match ambiguity. Any account verified at origination should carry it, and an account that does not is a record-keeping finding worth reporting alongside the sweep results.
• A deduplicated entity list rather than a loan list. One obligor with four facilities is one lookup. Portfolios routinely sweep the same entity three or four times because the extract ran at the loan level.
• An explicit exclusion list with reasons. Accounts paid off, below a materiality threshold, or inside an active workout should be excluded deliberately and recorded as excluded. Silent omissions are the finding an examiner lands on.
Deduplicating and checking those fields before the first API call removes a meaningful share of the raw extract and converts another share into remediation tickets. That hour costs nothing and returns more than any other in the exercise.
How is this different from a bulk EIN pass?
The two run on different identifiers and are usually sequenced rather than merged. Tax identity verification at volume, including its own staging, logging, and exception routing, is covered in our guide to bulk-verifying 10,000 EINs via API, and this article does not restate that pipeline.[5] The distinction that matters for scoping: an EIN pass tells you the tax identity matches the name on file, and a registration sweep tells you the chartering state still recognizes the entity. A portfolio can fail either one independently.
Why does per-state latency variance decide the batch design rather than total volume?
This is the design error that turns a two-day sweep into a two-week one, and it is invisible in testing because test samples skew toward fast states.
Live Secretary of State lookups take 10 to 180 seconds depending on the state. Most return in 10 to 30 seconds. Delaware takes 15 to 30 seconds. Oregon can take up to five minutes. A sweep written as a synchronous loop with a uniform timeout will complete most of the book and quietly time out the slow tail, which is worse than a slower sweep because the missing records look like completed ones unless you reconcile counts at the end.
How should the batch be partitioned?
By state first, volume second. Group the deduplicated list into state buckets, run the fast-state buckets synchronously at whatever concurrency your integration supports, and route the slow states through the asynchronous path from the start rather than retrofitting it after the first stall.
For a slow state, pass a callback 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&screenshot=true&callbackUrl=https://yoursite.com/webhook' \
--header 'x-api-key: Your_API_Key' \
--header 'Accept: application/json'The polling alternative uses the `retryId` returned on the initial response, presented on subsequent calls until `status` reads `complete`. The receiving side of that pattern, including validation and replay handling, is covered in our guide to async webhook architecture for SOS lookups, so this article stays on the batch side.
Two habits make the partition work. Start the slow-state buckets first so they run alongside everything else, since the slow tail sets the completion date. And track per-state completion counts against per-state input counts rather than one global progress number, because a global percentage hides a state that returned nothing at all.
What retry behavior keeps a sweep from stalling?
Standard distributed practice, applied without improvisation. AWS prescriptive guidance recommends exponential backoff when "services frequently throttle the request to prevent overload, resulting in a 429 Too many requests exception," and is explicit about the precondition: "Operations should be idempotent when you use the retry with backoff pattern. Otherwise, partial updates might corrupt the system state."[6] The same guidance recommends failing fast on non-transient errors rather than retrying into a wall.
A lookup is a read, and RFC 9110 defines a method as idempotent "if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request."[7] Retries are therefore safe at the protocol level. Your write side needs the care: deduplicate stored results on the `requestId` returned with every response, or a retried call after a partial failure writes the same entity twice and inflates your exception counts.
Use the `test` parameter, which accepts `complete`, `incomplete`, `failed`, `retryIdInvalid`, and `badRequest`, to build the failure branches before the sweep runs. A sweep is the wrong time to discover how your code handles a timeout, because the accounts producing odd responses are disproportionately the ones you most need to see.
How do you budget credits and pass-through fees for a portfolio sweep?
Cost is set by the deduplicated entity count, the live-versus-cached split, and a small number of states that charge fees the API passes through at cost. Each completed lookup is 1 credit, so the budget question is how many entities you resolved during scoping rather than how many loans you hold.
Where does a cached-first waterfall save money, and where does it mislead you?
Cached mode returns in under a second against data refreshed monthly. Live mode returns in 10 to 180 seconds against the state's current record. The recommended waterfall checks cache first and follows with a live lookup where there is no match or the data looks stale.
For a sweep, that pattern needs a qualifier. Cached results suit the fields that change slowly and the pre-pass that tells you which entities exist at all. They are wrong as the recorded answer on the `status` field, because a monthly refresh cannot see a change that happened after it ran, and status is the field the sweep exists to read. Use the cache to triage and price the run, and record live results for anything reaching the committee report. Both modes are compared field by field in our analysis of real-time SOS data versus cached registry data.
Which states need a separate budget line?
Two, and both are state-imposed rather than vendor charges.
Delaware entity status requires a paid request from the state. The Division of Corporations sells a $10 tier returning current status and a $20 tier adding the last five filings, franchise tax assessment, total authorized shares, and tax due.[8] That fee is passed through at cost. On a book with heavy Delaware concentration, which describes most portfolios holding institutional borrowers, this line can exceed the credit line for those accounts, and it is the most common budget surprise in a first sweep. New Jersey status data is restricted by statute and carries a small fee on the same basis. Price both during scoping, since the state distribution you built for batch partitioning already gives you the counts.
What belongs in the exception queue, and how do you keep it from swallowing the sweep?
Exceptions are the sweep. Clean results confirm what the file already said. Every hour of analyst value sits in the pile that did not resolve, and a queue that mixes unlike things gets triaged badly.
Which exception classes need separate handling?
Six, and they route to different people.
• No result returned. An empty response is not proof of nonexistence. Name variations, an incorrect state on file, a very recent filing, or an entity searchable only by identifier all produce it. Route to name-and-state remediation before anyone treats it as a risk signal.
• Multiple plausible matches. The response returns up to 10 close matches in `possibleAlternatives` when the exact match is uncertain. That is a resolution task for someone holding the loan file, not a credit decision.
• Confidence below the auto-accept band. Every result carries a confidence score from 0.0 to 1.0. Scores of 0.8 and above are commonly auto-accepted, 0.5 to 0.79 flagged for human review, and below 0.5 treated as probably a different entity. Set and record those thresholds before the sweep, because moving them afterward to shrink the queue reads badly in a file.
• Status transition away from active. The genuine finding, and the smallest pile. Route directly to the relationship owner with the state record link attached.
• Legal name mismatch against the file. For secured exposure this starts the four-month UCC clock described earlier and should escalate ahead of a status change, since the remedy has a deadline.
• Timeouts and incomplete responses. Unknown, not negative. A timeout on a slow state says nothing about the borrower, and a queue mixing timeouts with dissolutions trains analysts to discount both.
Only two of those six are credit findings. The other four are data quality work, and labeling them correctly on day one keeps the credit committee's attention on the accounts that deserve it.
How do you size analyst capacity before launch?
Run a pilot of a few hundred entities drawn to match the portfolio's state distribution rather than a convenience sample, measure the exception rate per class, and multiply. A pilot skewed toward your two largest states understates the queue, since states with sparser published data generate exceptions at a different rate. That variance is inventoried in our SOS API data coverage by state checklist.
How does sweep output feed borrower tiering for ongoing monitoring?
A sweep that ends in a spreadsheet has produced a compliance artifact. A sweep that ends in a tiering decision has produced a policy.
The output already carries the tiering inputs: current status, state, entity age from `filingDate`, registered agent, and whether the record resolved cleanly. Combined with exposure and product type from your own systems, that supports a defensible three-tier split. Accounts that resolved cleanly, sit in states with predictable filing calendars, and carry modest exposure need a scheduled recheck rather than continuous coverage. Accounts with secured collateral, large exposure, or a name or agent change need something tighter, because the UCC clock runs from the borrower's action and not from your discovery of it. Accounts that failed to resolve stay in remediation, and should not pass silently into a monitoring population that assumes a clean baseline.
The sweep is the only moment you will ever have a verified status on every account at the same timestamp. Deciding coverage tiers from that snapshot is cheap. Deciding them a year later from a stale file is guesswork with a spreadsheet attached.
What is the calendar argument for tiering by state?
Filing deadlines are public, fixed, and unevenly distributed, which means a recheck placed shortly after a state's deadline extracts far more than the same recheck placed at random. Florida requires 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."[9] Delaware domestic corporation annual reports and franchise taxes are due "on or before March 1st," with failure producing "a penalty of $200.00 plus 1.5% interest per month on tax and penalty."[10]
The calendar also moves. Pennsylvania shifted from decennial to annual reporting beginning in 2025, with administrative dissolution as the consequence of nonfiling, and Washington made email addresses a filing requirement effective January 20, 2026, with noncompliant filings subject to rejection.[11] A tiering schedule built on last year's deadlines misses both.
Where does the sweep hand off to change detection?
At the point where the answer needs to arrive without anyone asking. A sweep is a pull you initiate, own, and pay for on a date you choose. Continuous coverage inverts that, and Business Monitoring for Secretary of State change detection is the right starting point for the tiers where a scheduled sweep is too coarse.[12] For choosing which accounts justify that treatment, our sibling analysis on which borrowers need continuous SOS monitoring works through the population question, and how to automate filing status updates via API covers the scheduled recheck pattern that sits between a sweep and full monitoring.
The supervisory backdrop supports the same shape. FinCEN's February 2026 order narrowed beneficial ownership collection at account opening while preserving the duty to conduct ongoing monitoring to "maintain and update customer information, including information regarding the beneficial owner(s) of legal entity customers."[13] The federal banking agencies' May 3, 2024 community bank guide frames third-party oversight as banks needing "to appropriately identify, assess, monitor, and control these risks."[14] A sweep evidences a point in time. A tier evidences a policy.
What can a portfolio sweep not tell you?
Naming the limits is what separates a sweep result that gets trusted from one that gets quietly discounted after its first surprise.
• It cannot tell you why a status changed. Administrative causes and financial distress present identically in a status field. A filing rejected over a missing email address and a business in collapse both read as a lapse.
• It cannot normalize away state vocabulary on its own reading. New York records a nonfiling entity as "past due in the filing of its Biennial Statement," which "may prevent the corporation or LLC from completing certain business transactions."[15] California frames the same failure as one that "may result in penalties being assessed by the Franchise Tax Board and suspension or forfeiture."[16] Florida calls it administrative dissolution. The API returns a normalized status alongside the raw state value so comparison runs against one vocabulary, and the raw value still needs to reach the analyst reading the exception.
• It cannot fill in officer data the state does not publish. Officer availability varies by state. An empty officers array is frequently a disclosure policy rather than a fact about the company, and a model penalizing that empty array penalizes every borrower in a non-disclosing state.
• Screenshot evidence expires. Screenshot URLs are valid for 3 to 30 days, so a sweep storing links rather than downloaded images produces a loan file full of dead references at the moment someone asks for proof.
• Cached mode cannot see a post-refresh change. Monthly refresh is fine for triage and wrong for the recorded status.
• Scope is the Secretary of State record. No sanctions screening, no court dockets, no professional licenses. UCC filing data is available on the same call through `uccData=true`, and the rest are separate workflows on their own schedules. Where the registration check sits relative to those layers is covered in our overview of what Cobalt Intelligence offers and the best KYB APIs for lending risk assessment breakdown.
That last point is the one most often misread at procurement. A sweep gives you a current registration picture across the book. It is a data source feeding your decisioning, and the decision stays yours.
What does an auditable sweep record look like?
A sweep nobody can reconstruct has operational value and no evidentiary value. The difference is a handful of stored fields per entity.
{
"requestId": "abc123-def456",
"status": "complete",
"results": [
{
"title": "ACME CORPORATION",
"filingDate": "2015-03-15",
"status": "Active",
"entityType": "Corporation",
"stateOfFormation": "Delaware",
"sosUrl": "https://icis.corp.delaware.gov/ecorp/...",
"screenshotUrl": "https://screenshots.cobaltintelligence.com/..."
}
]
}Store the response rather than a conclusion drawn from it: the `requestId` for log correlation on the API side, your own call timestamp, the raw and normalized `status`, the `sosUrl` pointing at the state's record, and the downloaded screenshot image where you requested one. Add the two fields the API cannot give you, which are the exception class you assigned and the analyst who cleared it.
The committee report is short. Population swept and population excluded with reasons, results by status, exception counts by class with aging, the accounts that moved to a tighter tier, and the remediation list of records that could not be swept for missing data. That last section is usually the most valuable output of a first sweep and the one most often left out, because it describes the state of your own records rather than your borrowers'.
Build-versus-buy sits underneath all of this, and a sweep is where it gets answered honestly: scheduling and batching are solved problems in any stack, while 50 registry integrations, their individual failure modes, and the normalization layer that keeps your comparison logic to one rule rather than 51 are not. That arithmetic is worked through in our SOS API versus building in-house cost comparison, and the provider landscape is compared in the pillar guide to top Secretary of State API solutions for verifying businesses. For reading the status values a sweep returns, state definition pages such as Alabama entity status definitions hold that ground.
A first sweep almost always finds fewer dissolved borrowers than the board expects and more unusable records than operations expects. The second finding is the one that changes how the next year runs.
.jpg){kind=small}
.png)