Know your business checks after the US BOI reset

Know your business checks should now treat US beneficial-ownership evidence as a scoped source, not as a universal answer. The material change is simple: many US-formed companies are no longer expected to file beneficial ownership information into the federal reporting system, while certain foreign entities registered to do business in the United States can still have filing duties for non-US individuals. That does not end KYB. It changes what a product, risk or compliance workflow can honestly say it has verified.

A registry match can support the fact that an entity exists under a name, number and jurisdiction. It does not prove that the person completing onboarding controls the entity, that all owners have been identified, or that an old ownership declaration remains current. Current market explainers often define KYB as entity identity, ownership and risk screening, but they rarely show the data states a system should store when one source is unavailable, another is stale and a third is a customer-supplied declaration.

The implementation gap is clearest in US onboarding. If the applicant is a Delaware LLC, the system may verify formation details, status and a state identifier, then still have no current public ownership register to query. The correct result is not “owner verified” and not “owner absent”. It is a narrower finding: entity identity retrieved; federal BOI source not applicable or not available for this entity type; ownership declaration collected; evidence still subject to risk-based verification and monitoring. CompanyProof’s evidence-ledger approach is useful here because the claim, observed value, source and check time remain separate instead of being flattened into one KYB status.

The recent rule path matters because it changes a common assumption in know your business KYB design. The broad expectation that US domestic entities would populate a federal beneficial-ownership reporting source has been replaced by a narrower model. US companies and US persons are outside the reporting requirement described by the current federal materials, and previously reported information for exempt US persons is to be removed from the database. Certain foreign entities registered in a US state or Tribal jurisdiction remain in scope, but their reporting is limited and does not turn the system into a full public KYB source.

That leaves two separate questions. First, does this company have a legal existence record in the relevant state or jurisdiction? Second, who owns or controls it for the purpose of this decision? A system that asks only the first question may approve the wrong business. A system that asks the second question but records only a yes/no result will struggle when an examiner, risk reviewer or customer-support team asks why an ownership answer changed later.

The other US development points in the same direction. Current customer-due-diligence material still describes beneficial-owner identification and verification for covered financial institutions, with the familiar ownership and control structure, while later relief reduces repeated collection at each new account opening if specified conditions are met. In practice, that encourages reuse of prior evidence only when it remains reliable, confirmed and appropriate to the risk. It does not justify treating an old declaration as permanently verified.

The current competing pages answer “what is KYB?” and “what documents are collected?” reasonably well. The unanswered enterprise question is narrower: what should the system return when a source that a reviewer expected to use does not establish the fact? That question is operational, not semantic. It determines whether a case can proceed, whether a customer sees a document request and whether future monitoring knows which fact to reopen.

A practical data model should separate retrieval from verification. Retrieval means the system found a registry record, a customer declaration, an ownership chart or a submitted identity document. Verification means the system decided that a specific claim is supported for a specific purpose at a specific time. A retrieved ownership chart may support “the applicant declared these owners on this date”; it may not support “these are the complete ultimate beneficial owners under every applicable rule”.

The same distinction applies to missing and contradictory evidence. Missing means no source was available, accessible or applicable. Contradictory means two sources point to different facts, such as a declared legal name that differs from the registry name, a control person who is not a listed officer, or an ownership chart that omits an intermediate holding company. A strong know your business verification workflow should route those states differently: missing evidence may call for an attestation or alternative source; contradictory evidence calls for review and correction before the decision is relied on.

Consider a hypothetical payments platform onboarding “North River Design LLC”, a private company said to be formed in Delaware and operating from Texas. The applicant gives a legal name, a Delaware file number, an employer identification number, one manager’s identity and a cap table showing two individuals each owning 50%. The platform is not making a legal conclusion from this example; it is designing the evidence states its workflow should record.

Step one is entity resolution. The system searches the Delaware entity record using the file number and name, records the jurisdiction, issuing register, observed status, retrieval time and any state-supplied date. If the name matches but the address is a registered-agent address, the system should not treat that address as proof of operating location. It should store “registered-agent address observed” and ask for a business address evidence path if the product needs operating-location risk.

Step two is ownership and control. Because a broad US federal BOI source is not available as a default ownership feed for this domestic entity, the workflow asks for an ownership declaration, a formation or operating document where appropriate, and identity evidence for the natural persons who meet the platform’s threshold or control rule. The result is not simply “UBO passed”. It is a bundle of claim-level findings: declared owners collected, identity evidence checked, entity record matched, source unavailable noted, and one or more review triggers set.

Step three is monitoring. If the company later changes its state status, appoints a different manager, updates its ownership declaration, opens a higher-risk product or triggers adverse-media escalation, the system should reopen only the affected claims. A fresh registry retrieval may solve status. It may not solve ownership. A renewed owner attestation may solve a declaration date. It may not solve a contradiction between a control person and a submitted resolution.

The checklist below is deliberately narrower than a broad supplier due-diligence checklist. It is for teams implementing KYB evidence handling in onboarding, account review, embedded finance, marketplaces or procurement systems. Vendor due diligence can also mean M&A seller diligence; that is a different workflow, with different documents and a wider commercial review. Here the focus is counterparty identity, ownership evidence and ongoing review.

• Define the legal-entity claim before collecting documents: name, jurisdiction, registration number, legal form, status and the role the entity will play in the relationship.
• Store source scope beside each field: registry identity, customer declaration, beneficial-ownership register, identity document, board authority, tax record, sanctions result or internal review.
• Use explicit availability states: supported, contradicted, not found, source unavailable, not applicable, customer-declared, reviewer-approved and stale. Avoid using null or a pass flag for all of them.
• Separate US domestic companies from foreign entities registered to do business in the United States. The filing logic and the evidence available from federal BOI materials are not the same.
• Set a beneficial-ownership refresh rule that is risk-based and event-based: new account, product expansion, ownership-change notice, contradictory data, adverse-media escalation or periodic review date.

A good KYB workflow should make uncertainty visible without blocking every low-risk case. The table below turns common evidence states into product actions. It also avoids an old design mistake: asking for more documents whenever a source is quiet. Sometimes the correct action is a narrower verdict and a retained limitation, not another upload screen.

• Registry record matched, ownership source unavailable: proceed only if the product’s risk rule permits customer-declared ownership; store the unavailable source state and set a refresh trigger.
• Registry record matched, ownership declaration conflicts with officer or control evidence: pause the case for review, because the issue is contradiction rather than missing information.
• Foreign entity registered in a US jurisdiction: check whether the narrowed filing rule is relevant, but do not assume a complete owner set will be available from that path.
• Existing customer opens another account: reuse prior beneficial-owner evidence only where the customer confirms it remains accurate and no risk trigger calls reliability into question.
• Applicant cannot evidence authority to act: keep the company identity result separate from the authority result; a real company can still be represented by the wrong person.

The timeline shows why KYB systems should now be built around evidence states rather than a single onboarding result. Each milestone narrows or clarifies one part of the evidence chain: who must collect ownership information, who can access it, when repeated collection is avoidable and when a federal reporting source cannot be assumed for US domestic companies.

Start with the claim inventory. List the exact facts your product uses: legal name, registration number, status, operating address, control person, beneficial owners, sanctions result, financial standing and authority to act. For each fact, define the acceptable sources, the retrieval date, the source date if supplied, the verification rule, the review owner and the event that makes the fact stale.

Then make the exception states visible in the user journey. A compliance analyst needs to know whether ownership was missing, contradicted, customer-declared or outside a source’s scope. A product manager needs to know which of those states can pass at low risk and which must stop the flow. An engineer needs stable enumerations, not prose notes buried in a case file.

Finally, test the workflow with awkward cases before launch: a US domestic LLC with no public owners, a foreign company registered in a US state, a customer whose trading name differs from its legal name, a holding-company chain with no natural person above the threshold, and a procurement supplier whose risk review is not the same as an M&A seller diligence exercise. The test should prove that your KYB know your business implementation can explain the decision, not merely return a status.