Executive Summary: The data layer vs decision layer question decides who can explain a decline six months later. A Secretary of State record is a set of facts about a filing: a status value, a filing date, an officer list when the state's record carries one, and a score for how well the record matched the search. A verdict about the borrower is a policy decision the lender answers for, to declined applicants and to bank partners, so the lender should build it from those fields in house rather than buy it as a score from the vendor that supplies them.
What Is the Difference Between a Data Layer and a Decision Layer?
What does the data layer return?
The data layer answers one question: what does the state record say right now, and how confident is the vendor that it found the right record? For a Secretary of State lookup that means the legal name, the state's own status value with a normalized version beside it, the filing date, the entity type, the registered agent, officers when the record lists them, the addresses on file, an optional screenshot, in some states a link to the source page, and a match score with a list of possible alternatives.[1] Cobalt's public feature-support spreadsheet marks, state by state, which fields come back.[2] Cobalt's help center documents the response conditions at this layer: a business found, a lookup still running, an empty result set, and a fallback to recent cached data when the live search fails.[3] Each is an observation, not an instruction.
What does the decision layer own?
The decision layer turns observations into a disposition: approve, decline, hold for review, or request a document. It owns the threshold on the match score, the status values that count as passing, the minimum time in business, the branches for a missing officer list and an empty result set, and the reason codes on a decline notice. Regulation B defines a creditor as "a person who, in the ordinary course of business, regularly participates in a credit decision, including setting the terms of the credit,"[4] so the lender issuing a commercial decline is the creditor answering for the decision no matter which vendor supplied the inputs.
Why do vendors blur the line?
A single number that says the business is safe removes the work of writing rules, which makes a bundled verdict easy to sell. Nothing here claims those scores are wrong. The argument is narrower: accountability for using a score does not transfer with the subscription, and a lender that cannot see the method cannot explain the outcome. A match score answers a different question. What confidence scoring means in the Cobalt Intelligence API describes it as the likelihood of a business name match, which says nothing about how risky the borrower is.
Why Is a Status Field a Fact and Not a Decision?
How do California, Texas, and Delaware disagree on what status means?
Active is not a national standard. California's Secretary of State publishes separate definitions for Active, SOS Suspended, FTB Suspended, SOS/FTB Suspended, Dissolved, Surrender, Merged Out, and Converted-Out, and a suspension can originate with the Secretary of State for a missed Statement of Information or with the Franchise Tax Board for a tax failure.[5] Texas forfeits an entity under the Tax Code when it fails to file a franchise tax report or pay franchise taxes.[6] Delaware's online status service returns an entity's status and, on a fuller request, recent filings and the franchise tax assessment, but not document images or officer and director names.[7]
A normalized status value maps those vocabularies onto one scale, but a mapping is not a judgment. In Cobalt's own measurement on September 11, 2026, described below, one New Jersey lookup returned the state status "Active/Owes Current Year AR" with a normalized status of Active. Whether that entity, or an FTB-suspended California LLC, is a decline, a hold, or a document request depends on the product, the ticket size, and the lender's appetite, not on the vendor that normalized the field.
What should the rule say when the officer list is empty?
Cobalt's feature-support spreadsheet marks officers for 35 of its 52 jurisdictions, Florida among them, and leaves 17 unmarked, Idaho among them.[2] Cobalt's own measurement on September 11, 2026 is one day's observation beside it: three large national companies searched by name in all 50 states and the District of Columbia, 153 probes, each with a 180-second ceiling. Officers came back from 32 of the 51 on at least one probe, from all three Florida probes and none of Idaho's three. The two sources disagree in four states: New Jersey is unmarked, yet one New Jersey probe returned officers, while Illinois, Kentucky, and New Hampshire are marked and returned none that day. One day and three well-formed names show what a state can return, not what it never returns, and the results are not a service expectation.
An empty list means different things in the two kinds of state, so key the branch to the spreadsheet, not to one day's results. From a marked state such as Florida, an empty list raises a question about the record; from an unmarked state such as Idaho, it may reflect only what the lookup returns. A lender-owned rule can say: where the spreadsheet marks officers, require a guarantor match; where it does not, route to a document request unless officers come back anyway. Recheck the marks against live responses in the states you lend in. A vendor score that treats every empty list alike hides that difference inside a number.
Why is an empty result set not a decline?
Cobalt's documented responses give three meanings for a completed lookup with no results: nothing matched in the cache, the state does not support the search type, such as a person search, or no record matched the exact name, in which case the response can offer alternatives.[3] A cache miss means only that the entity is not in the cache, not that it does not exist at the state, and the help center suggests a live lookup when certainty matters.[8] When cached data stands in for a live search, the API reference documents an optional top-level message field, present on a live request only when the lookup fails or the state is down for maintenance and recent data exists; it lists more than one wording, so branch on its presence, not its text.[1] The help center calls the note part of a messages array and points to createdAt and updatedAt for recency,[9] but the API reference ties those timestamps to requests with liveData set to false,[1] and the spreadsheet marks them for 26 of 52 jurisdictions,[2] so a cached record with no timestamp has unknown age and needs its own branch. A verdict layer that collapses not found into fail decides before the lender has seen which condition applied.
Who Is Accountable When a Vendor Score Drives the Decline?
What does the 2026 model risk guidance say about vendor models?
On April 17, 2026, the Federal Reserve, the OCC, and the FDIC issued revised model risk management guidance that supersedes SR 11-7.[10] It defines a model as a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates, and it excludes deterministic rule-based processes with no such theory behind them.[10] A vendor risk score built on statistical methods fits that definition. A lender's rule that declines when status is not Active, or when the filing date is under 24 months old, does not.
On vendor products, the guidance says a banking organization may not receive the underlying code, data, or methodology, and the principles of model risk management remain applicable anyway.[10]
Sound practice includes developing an understanding of the vendor model, including its conceptual soundness, design, development data, and performance.
That sentence, from the revised guidance,[10] is the cost of buying a score. Two limits keep it in proportion. The guidance states that it does not set enforceable standards or prescriptive requirements and that non-compliance will not result in supervisory criticism, though its first footnote adds that "supervisory action may result for any violations of law or unsafe or unsound practices stemming from insufficient management of model risk."[10] It is expected to be most relevant to banking organizations with over 30 billion dollars in total assets.[10] It reaches a non-bank lender, if at all, through a bank partner: the 2023 interagency third-party guidance says a banking organization's use of third parties does not diminish its responsibility to operate safely and soundly and comply with applicable laws, to the same extent as if it did the work in house.[11]
How do adverse action rules reach a business lender?
Regulation B requires that a statement of reasons for adverse action be specific and indicate the principal reasons, and it states that a claim the action was based on the creditor's internal standards or policies, or that the applicant failed to achieve a qualifying score on the creditor's scoring system, is insufficient.[12] The CFPB withdrew its 2022 circular on adverse action notices for credit decisions based on complex algorithms in May 2025,[13] but the specific-reasons requirement remains in the current text of Regulation B.[12] A notice that cites a vendor cutoff is what Regulation B calls insufficient. A notice that cites a franchise-tax forfeiture on a specific date and a policy requiring active standing gives a specific principal reason, and only a lender that kept the field and the rule can write it.
Business credit applicants get notices too, with mechanics split at one million dollars in gross revenues.[12] Section 1002.9(a)(3)(ii) puts trade credit, credit incident to a factoring agreement, and other similar types of business credit on the track for businesses above that line, where written reasons come only if the applicant asks for them in writing within 60 days of being notified of the action.[12] Whether a merchant cash advance structured as a purchase of receivables is credit under Regulation B at all is a question this piece does not settle.
What does a bank partner or examiner expect you to show?
FinCEN's customer due diligence rule lists four core requirements for covered institutions: identify and verify customers, identify and verify the beneficial owners of companies opening accounts, understand the nature and purpose of customer relationships to develop customer risk profiles, and conduct ongoing monitoring.[14] The rule covers banks and certain other financial institutions, not non-bank lenders, but when a sponsor bank is the lender of record, the borrower is the bank's customer. The risk profile is the bank's work product, so be ready to give it the inputs, the logic, and the person or system that applied them. A vendor score supplies none of the three on its own. On vendor security, request the vendor's current attestation documents and read them.
What Are the Ways to Get From a Record to a Decision?
What do manual review and a bundled verdict each trade away?
Manual review keeps the decision in house and, at low volume, is hard to beat on explainability. It fails on consistency and evidence: two analysts read the same California suspension differently, the note does not capture the page as it appeared, and time per file grows with volume. A platform that returns the record plus a pass flag or score is the fastest path to a working workflow and may be the right first step for a lender with no risk engineering capacity. The trade is control. The threshold lives in the vendor's configuration, reason codes use the vendor's vocabulary, model changes arrive on the vendor's schedule, and if the platform is also the system of record, switching vendors means re-deriving every historical disposition.
What does it take to own the rules layer?
The third path buys the record, its provenance, and a match score, and puts the rules in the lender's own decision engine or loan origination system. Its cost is work that needs named owners. Cobalt's 2026 hub guide to business verification APIs for alternative lenders splits it three ways: risk owns the thresholds, such as which match score declines a file and which entity statuses pass; compliance owns the audit trail and the ability to reconstruct any decision for an examiner; engineering owns latency and uptime handling. At a small lender two people may hold all three duties, but each duty needs a name.
The first version is mostly writing and plumbing. The risk owner writes the policy: each rule, the field it reads, its pass, review, and decline values, and its unavailable branch, starting from how analysts decide today. Engineering stores each provider response with its retrieval time and screenshot file, keeps rules as versioned configuration with a change log, and builds a replay path for stored payloads. Each version runs against past files with known outcomes before it goes live. After launch the work is smaller but permanent: sample each band, map new state status strings, and review reason codes when a rule changes. It needs no data science team, only an owner with the authority to change a threshold without waiting on a vendor.
What Did Two Buyers Say They Wanted From the Data Layer?
What did a prospect's reviewer ask for?
On a demo call, a prospect's reviewer said the prospect did not need the data vendor to make its decisions, only to supply reliable public-record data. The reviewer looks past the status to the filing history.
What did a second prospect decline to pay for?
On a separate call, a second prospect said it wanted Secretary of State data it could run through its own checks. It said it did not need a vendor's score and did not want to pay for one.
What do the two cases have in common?
Both are prospects, not customers, and neither outcome is known. Each already owns a decision process, its own rules in one case and its own checks in the other, and each said explicitly what it did not want from the vendor: decisions in one case, scoring in the other. Cobalt's product boundary draws the same line from the vendor side: Cobalt provides the record, the match score, and the screenshots, and the customer builds the rules, the thresholds, and the risk models.
How Should a Lender Build a Decision Layer on Top of the Record?
Which fields feed which rules?
List each provider field you will consume and the rule it feeds. Status and normalized status feed the standing rule. Time in business reads normalizedFilingDate and falls back to the raw filingDate.[1] Officers feed guarantor matching, keyed to the states the spreadsheet marks. The confidence level and the alternatives feed the identity rule. The name fields feed the name rule. Cobalt's help center says the response includes the legal business name, any assumed or DBA names, and a "Search Input Hit" field that shows the string that triggered the match.[15] The public API reference lists title, the assumedBusinessNames array, and searchResultTitle, which appears only when the name in the state's search results, such as a DBA, differs from the legal name on the details page.[1] Check live responses for your states to see which field carries the matched string, then let the rule treat a DBA match differently from a legal-name match. The stored screenshot feeds the evidence rule. The spreadsheet marks screenshotUrl for all 52 jurisdictions but the source url for only 19,[2] so treat the url as a state-dependent extra, and branch on screenshotSucceeded, because the API reference says screenshots are not yet available in all states.[1] The response status, the top-level message, and the timestamps feed the freshness rule. Anything the state does not return gets an explicit unavailable branch, not a silent default.
How should thresholds be set, versioned, and tuned?
Cobalt's help center gives typical guidance for the confidence level: 0.80 and above auto-accept, 0.60 to 0.79 review, and below 0.60 usually reject unless other signals, such as the address, are strong.[16] Adopt a starting band, then own it. Record the threshold in a versioned policy, sample cases from each band on a schedule, and move the lines based on the false accepts and false holds you observe, tuning the accept and decline lines together. The companion article on confidence scoring for KYB decisioning works through a tiered routing structure and a quarterly tuning review.
What should the decision record look like?
Store the provider observation and the lender's decision as two linked objects, never as one overwritten row. The illustration below is a lender-owned record for a fictional business; field names inside the result block come from Cobalt's documented response, and every other name is the lender's.
{
"decision_record_id": "dec-2026-000481",
"provider_observation": {
"retrieved_at": "2026-09-24T14:02:11Z",
"result": {
"title": "EXAMPLE FREIGHT LLC",
"status": "Active/Owes Current Year AR",
"normalizedStatus": "Active",
"filingDate": "06-14-2021",
"normalizedFilingDate": "2021-06-14T00:00:00.000Z",
"confidenceLevel": 0.93,
"officers": [{ "name": "JANE EXAMPLE", "title": "Managing Member" }],
"screenshotSucceeded": true
},
"screenshot_file": "evidence/dec-2026-000481/sos.png"
},
"lender_rules": {
"policy_version": "kyb-rules-v14",
"standing_rule": { "pass_values": ["Active"], "review_if_status_mentions": ["Owes"], "result": "review" },
"time_in_business_rule": { "reads": "normalizedFilingDate", "fallback": "filingDate", "minimum_months": 24, "observed_months": 63, "result": "pass" },
"identity_rule": { "auto_accept_at": 0.85, "review_floor": 0.60, "result": "pass" },
"guarantor_rule": { "officers_returned": true, "guarantor_found": true, "result": "pass" }
},
"disposition": "manual_review",
"review_reasons": ["state status shows the current-year annual report as owed"]
}Keep the result block exactly as received, with the time you retrieved it, and store the screenshot file in your own system. The API reference calls the screenshot link "a short lived URL",[1] and the help center says document links are valid for 3 days by default and can be extended up to 30 days on request.[17] The rules block is what lets you answer an examiner, a bank partner, or a declined applicant.
How Do You Know the Decision Layer Is Really Yours?
Which tests does a risk lead run?
Run these before buying anything new.
• Explain a decline. Write last month's decline reason as one sentence naming a state field value and a policy rule. If it needs a vendor score, the reason is not yours.
• Change a threshold. Move the auto-accept line from 0.80 to 0.85 in a test environment today. If that takes a vendor ticket or a contract amendment, the threshold is the vendor's.
• Replay a decision. Rerun a payload stored six months ago through today's rules and through the rules in force then. If you cannot produce both results, the policy is not versioned.
• Name the missing field. For each state you lend in, state what your rule does when officers are absent, when the result set is empty, and when the response fell back to cache. If all three get the same answer, the branch does not exist.
• Switch vendors on paper. Map every rule to the provider field it consumes and check whether a second vendor's payload could feed it. A rule that consumes a vendor-specific score cannot move.
What does a failing answer look like?
One failure pattern is a rules engine that looks lender-owned but contains a single rule: if the vendor flag is pass, proceed. Another is a policy document that describes thresholds nobody can find in the system, so the written policy and the running rules have drifted apart. Both are cheaper to fix before a bank partner or an examiner finds them.
Where Does Cobalt Intelligence Fit, and Where Does It Stop?
A lender that owns its rules needs a data layer whose fields are exact enough to write rules against and whose limits are stated plainly enough to write the unavailable branches. Hold any primary-source vendor to that standard, including Cobalt. The guide on how to evaluate business verification vendors by their limitations shows how to turn each stated limit into a test, a routing rule, a fallback, and an owner.
What does the Secretary of State API return?
Cobalt's Secretary of State API searches a state's registry by business name, entity ID, or, in states that support it, a person's name, live by default or from cache on request.[1] For ID search the sources disagree: the API reference lists sosId as a general input,[1] but the feature-support spreadsheet marks ID search for only Florida and Mississippi,[2] so test it in your states before a rule depends on it. Each candidate carries a confidence level from 0.0 to 1.0, and close names return up to about ten alternatives.[18] The Top 34 questions about the Secretary of State API cover the retrieval mechanics, including what the confidence level measures and how the API handles slow states.
What does Cobalt not do?
Cobalt is a data source, not a decisioning engine. It does not decide whether a status passes, set your threshold, or score the borrower. Its documented limits, covered above, belong in your unavailable branches: the spreadsheet marks officers and the source url for only some states, Delaware's status service returns no document images or officer names, screenshot links expire, and a cached record may carry no timestamp. Response time varies too. In the September 11, 2026 measurement, the 110 live lookups that returned a record took a median of about 14.8 seconds and as long as 170.27 seconds, and 21 of 153 probes did not finish inside the 180-second ceiling. Find Related Businesses, which Cobalt launched in beta in February 2026,[19] matches a result's agent and officer names against other entities in Cobalt's database,[1] so its output is a signal for a rule to weigh, not a finding.
How should a team review its workflow before integrating?
Write the rule set first, with a branch for every limit above, then test the data layer against it. The sandbox evaluation checklist for testing an SOS API before buying covers the asynchronous path, screenshot expiry, and error paths. When the rules exist and the branches are named, schedule a workflow review with Cobalt to map each rule to the field that feeds it and confirm which states need a document-request branch.
.jpg){kind=small}
.png)