Executive Summary: KYB BOI compliance automation helps lenders separate two things that are easy to confuse: the federal beneficial ownership information (BOI) filing registry run by FinCEN, and a lender's own know-your-business due diligence on the entities and people it funds. As of June 2026, an interim final rule has narrowed who must file BOI with FinCEN, so all U.S.-formed reporting companies and their beneficial owners are exempt from that filing, while only foreign reporting companies registered to do business in the United States remain subject to it.[1][2] That change does not remove a lender's separate duty to identify and verify beneficial owners under customer due diligence and its own risk policy.
What is the difference between FinCEN BOI filing and lender KYB due diligence?
What did the 2025 interim final rule actually change?
The Corporate Transparency Act created a registry: certain entities report beneficial ownership information to FinCEN. In March 2025, FinCEN issued an interim final rule that revised the definition of reporting company to mean only entities formed under foreign law and registered to do business in a U.S. state or tribal jurisdiction.[1] Entities created in the United States, previously called domestic reporting companies, and their beneficial owners are exempt from the BOI filing requirement.[2] Foreign reporting companies still file, but they do not report U.S. persons as beneficial owners, and U.S. persons do not report for those entities.[3]
Why does a lender still need beneficial ownership data?
The BOI registry and a lender's due diligence are different controls with different legal bases. The narrowed FinCEN filing mandate does not change a covered financial institution's customer due diligence obligation, which includes identifying and verifying the beneficial owners of legal entity customers under 31 CFR 1010.230.[4] A lender also has its own credit and fraud reasons to know who owns and controls a borrower, independent of any federal registry.
Why does beneficial ownership matter for underwriting and risk?
What does ownership tell a risk team?
Knowing the people behind an entity changes how a file is scored. A single owner who controls several thinly capitalized entities is a different risk than a diversified ownership group. Ownership data also connects an application to prior defaults, sanctions exposure, and litigation history that an entity-only check would miss.
How does ownership connect to sanctions and fraud screening?
Screening the business name alone is not enough. A clean entity can be controlled by a sanctioned or high-risk individual. Beneficial ownership data lets a lender screen the natural persons behind the business, which is why ownership and sanctions screening are usually built together.[9] This pairing sits inside a broader BSA and AML program rather than standing alone.[8]
The registry mandate for U.S. companies narrowed, but the underwriting question did not. A lender still has to answer who owns this business, who controls it, and whether those people change the risk before money moves.
What is KYB BOI compliance automation in practice?
What does automation replace?
KYB BOI compliance automation replaces manual portal lookups, screenshots, and spreadsheets with structured data pulled through an API and stored with the loan file. The goal is not to file anything with FinCEN on the lender's behalf. The goal is to assemble the entity and ownership picture a risk team needs to make and document a decision.
What should an automated KYB flow capture?
A practical flow gathers entity and ownership signals in a repeatable sequence:
• Legal entity confirmation. Verify the business exists and is active at the Secretary of State before anything else.
• Registered agent and officers. Capture the people named in public filings as a starting point for ownership and control.
• TIN and EIN matching. Confirm the tax identity ties to the verified entity.
• Sanctions screening. Screen the entity and the identified persons against current watchlists.
• Adverse signals. Pull UCC filings, judgments, and litigation where coverage exists to add context.
• Decision record. Store the raw response, the parsed flags, and the reason a file passed, conditioned, or declined.
These elements give underwriting a defensible file without forcing an analyst to reopen five separate state and federal websites.
How does Cobalt fit into a KYB stack?
What data does Cobalt actually provide?
Cobalt Intelligence is a data source, not a decisioning engine. It returns real-time Secretary of State business verification and related public-record data through an API, which an underwriting or compliance system then routes against the lender's own policy. Cobalt does not set risk thresholds, render an approve or decline decision, or file BOI reports with FinCEN. Those choices stay with the lender.
What does a verification call look like?
A single request returns the entity record an analyst would otherwise pull by hand from a state portal. Officers and registered-agent fields in that record give the team a starting point for identifying the people behind the business, which the lender then screens and documents under its own due diligence policy.
curl --location 'https://apigateway.cobaltintelligence.com/v1/search?searchQuery=Acme%20Holdings%20LLC&state=delaware&liveData=true' \
--header 'x-api-key: YOUR_API_KEY' \
--header 'Accept: application/json'The response carries entity status, filing details, and officer or agent data where the state discloses it. Engineering stores the raw payload so a future examiner can see exactly what was checked and when.
Which KYB data elements map to which sources?
How should a team plan coverage?
Beneficial ownership data does not come from one place. Public Secretary of State filings often name officers and registered agents but do not always disclose true equity owners, so a lender combines sources and documents the gaps. The table below maps common KYB elements to a source and the automation path.
| KYB data element | Primary source | Automation path |
|---|---|---|
| Entity existence and status | Secretary of State | Cobalt SOS search API |
| Officers and registered agent | Secretary of State filings | Cobalt SOS search API where state discloses |
| Tax identity match | TIN and EIN records | Cobalt verification request |
| Sanctions exposure | OFAC and watchlists | Cobalt OFAC screening |
| Secured-debt and stacking signals | UCC filings | Cobalt UCC data where supported |
| True equity owners below officer level | Borrower attestation and documents | Manual collection, stored with file |
Where are the coverage caveats?
Public filings do not always reveal the full ownership chain. Many states name officers and agents rather than equity owners, layered holding structures can hide ultimate ownership, and UCC and court coverage varies by jurisdiction. An honest workflow treats borrower attestation plus documents as the fallback for ownership that public data cannot confirm, and it never treats a missing field as a clean result.
How should compliance and engineering divide the work?
What does compliance own?
Compliance owns the policy. That includes the ownership threshold the lender uses, how persons are screened, what triggers enhanced review, the escalation path for a possible match, and the retention schedule for evidence. The 25 percent equity threshold and the control-prong concept in the CDD rule are a common reference point, but the lender sets its own documented standard.[4] Customer identification program requirements sit alongside this under 31 CFR 1010.220.[5]
What does engineering own?
Engineering owns the pipeline. That means calling the verification and screening APIs at the right point in the funnel, parsing responses into flags the loan origination system can route, storing raw payloads as evidence, and surfacing exceptions in a queue instead of letting them clear silently. The split keeps decisions with compliance and plumbing with engineering.
What implementation steps should a lender follow?
What belongs in the first production version?
A first version should stay narrow and auditable rather than broad and fragile:
• Define the policy first. Write the ownership threshold, screening rules, and escalation path before any code.
• Verify the entity at intake. Confirm existence and status before deeper checks run.
• Identify the people. Capture officers and agents from filings, then collect attested owners the public record does not show.
• Screen entity and persons. Run sanctions screening on both, with documented match handling.
• Route exceptions. Send unclear ownership, possible matches, or unsupported jurisdictions to manual review.
• Store the evidence. Keep raw responses, parsed flags, timestamps, and the decision reason for every file.
How should a team confirm the current BOI status?
Because the rule changed in 2025 and a final rule may follow, a team should confirm the current filing scope against FinCEN and the Federal Register rather than relying on memory, then apply due diligence on top regardless of filing scope.[7][1] The CTA statute itself remains in force and defines reporting company and beneficial owner, so the underlying framework still matters even as filing scope narrows.[6] For sanctions context that pairs with ownership data, lenders building this layer often start from a broader screening program.[10]
.jpg){kind=small}
.png)