KYB verification is the process of confirming a business customer's identity and the people behind it: that the entity exists and is in good standing, that its name, address and tax number are right, that each owner of 25% or more and one controller are named and verified, and that none of them is on a sanctions list. At a bank it is not a single product but a chain of steps across systems the bank already runs, from the online application and document imaging to state business filings, identity verification, OFAC screening and the core banking system. Replacing that chain to add KYB verification is expensive and slow; connecting to it is not. Botminds' Business Account Opening (KYB) is built to read from every one of those systems and write to the core once, only after a deposit operations specialist has approved every field.
The product examples on this page use a fictional sample bank and customer, as they appear in the solution. The regulatory material comes from FinCEN, the Federal Reserve, GAO and the European Banking Authority.
The one write: every field Business Account Opening (KYB) will send to the core, waiting for a checker
What is KYB verification?
KYB verification answers two legal questions for a business customer, under two rules. The first, from the Customer Identification Program rule, is whether the bank can reasonably believe it knows which business this really is, a belief built from its name, physical address and taxpayer identification number, verified by documents or by non-documentary checks (31 CFR 1020.220). The second, from the beneficial ownership rule, is whether the bank has identified and verified each individual who owns 25% or more and one who controls the business (31 CFR 1010.230).
Around those two answers sit the bank's own controls: sanctions screening, a risk rating from the nature and purpose of the account, signer authority, and a written account of how every discrepancy was resolved. The KYB verification process, then, is a sequence of reads, comparisons and decisions. Software can do the reads and comparisons; the decisions belong to named people.
What KYB verification services check, and what they leave to the bank
A KYB verification service or API typically returns findings about a business or a person: a registry match, a status, an identity score, a list hit. What it cannot return is the bank's conclusion, because the rules put that on the bank. The CIP and beneficial ownership rules each allow reliance on someone else's work in only one case: another financial institution that is itself subject to an anti-money laundering program rule and regulated by a federal functional regulator, under a contract and an annual certification (31 CFR 1020.220(a)(6); 1010.230(j)). A verification vendor is not that, so the bank stays responsible for every check a vendor runs on its behalf.
That shapes how a service should fit. Its results should arrive as evidence in the bank's file, with the source and the time, beside the documents they were compared with, so the person deciding can see why a line is confirmed. A score that lands in a separate portal, to be copied into the file by hand, is a check the bank cannot show it reviewed. The same principle governs retention: the bank must keep the identifying information for five years after the account closes and the verification results, including how each discrepancy was resolved, for five years after they are made, whichever service produced them.
The stack a business account already touches
A business account at a community bank already runs through six or seven systems, and none of them is going away. GAO's study of bank compliance found the same basic workflow at banks of every size, with risk ratings assigned by bank staff, and larger banks often using automated software to help (GAO-20-574). Smaller banks run the same steps across a portal, an imaging system, a state website, an identity tool, a screening tool and a core, joined by people who rekey between them.
Read from every system, write to the core once: the stack map for Business Account Opening (KYB)
Reads, as often as needed
Business Account Opening (KYB)
Writes, once, after approval
Read from every system, write to the core once
The design rule is asymmetry. Reading is cheap and safe: an agent can pull the state's filing three times, re-read a page at higher resolution or re-run a screen without changing anything the bank relies on. Writing is expensive and permanent: a customer written to the core with a mistyped tax number or a missing owner is a customer the bank will be remediating for years. So the solution reads freely and writes once, through one path, after one approval.
In the sample case, the Boarding agent prepared fourteen fields with their sources. A deposit operations specialist approved them with the reason "All lines confirmed against the sources" at 2:41 PM, and only then did the agent write: the customer to the core at 2:44, the account at 2:45, the signature card and eight documents to imaging at 2:46, the CRM and a welcome notice from an approved template at 2:47. Every write carries the approval it rests on.
Does KYB verification integrate with core banking?
It should, through the core's existing interfaces for creating customers and accounts, and through nothing else. The questions an IT leader should ask are narrow. Which fields will it write, and can the bank see each one before it is written? Under whose credentials, and can that write path be used without a checker's approval? What happens when the core rejects a field? And can the bank switch the write off and go back to manual boarding without losing the file?
Integration questions for any KYB verification tool
- Read access only, except one path
Read from the portal, imaging, state filings, identity and screening tools; write only to the core, imaging and CRM.
- No write without a different person's approval
The maker cannot approve, and the write path cannot be called outside the approval.
- Approved fields only
The agent writes exactly the fields the checker saw, with their sources, and nothing else.
- Your vendors stay
Your identity verification, OFAC screening and e-signature providers, not a bundle that replaces them.
- Restricted results stay restricted
314(a) results and possible matches visible to the BSA officer only, never on a banker or customer view.
- A way back
If the write path is switched off, the file is complete enough for a person to board it by hand.
- Records you can export
The file, the sources, the decisions and the agent versions, for an examiner or an auditor, with personal data masked.
Behind the integration questions sit the behavioural ones: whether the tool guesses, whether it asks the owner once, whether a person reads every message. Those are in KYB automation that asks the owner once, and whether the result is worth the cost at a given bank's size is in KYB software and bank size.
How long does it take to implement KYB verification?
Longer than a demonstration suggests and shorter than a core replacement: the time goes into the bank's rules and its own past files, not into the software. A sensible plan replays the tool on closed business packets before it touches a live one, then runs it beside the bankers before it writes anything. The plan below is our illustration of that shape, not a fixed schedule; a bank's volume, its document rules and its core's interfaces will move it either way.
An illustrative plan that replaces nothing: read first, write last
- Document rules by entity type, clocks and limits as settings1 wk
- Read access; replay on a labelled set of closed packets2 wks
- Live packets read in parallel; bankers still board by hand3 wks
- Compare, fix rules, BSA officer approves1 wk
- Checker-approved writes to the core, one branch firstphased
The regulators have said for years that a pilot is not a liability. The 2018 joint statement by the Federal Reserve, FDIC, FinCEN, NCUA and OCC says a pilot should not, on its own, draw supervisory criticism, even one that ends in failure (Joint Statement on Innovative Efforts, December 3, 2018; how to run one is in a KYC onboarding software pilot). FinCEN's April 2026 proposal for the AML program rule goes further, though it is not final: an institution that experiments responsibly with new technology would face no added risk of a significant supervisory or enforcement action merely because it used that technology (91 FR 18704).
Who owns an agent's decision when no model guidance covers it?
The bank does, through its own governance, because the interagency model risk guidance now steps aside. SR 26-2, issued in April 2026 and replacing SR 11-7, leaves generative and agentic AI out of its scope because the technology is new and moving fast, and tells banks that their own risk management and governance should decide the controls for anything the guidance does not cover (Federal Reserve, SR 26-2; agentic AI for KYC reads the passage in full). A bank adopting agents for KYB verification cannot point to a model validation framework; it has to show its own.
Two other sources describe what that governance looks like. The European Banking Authority's guidelines on remote onboarding, not US law but a detailed published standard, require institutions to state which onboarding steps run entirely without people and which need a person to act (EBA/GL/2022/15). And US regulators apply the same discipline to themselves: GAO found that the regulators using AI did not let it decide on its own or treat it as their only input (GAO-25-107197).
Who changes what when KYB verification goes live without a new core
Today
Maintains an interface for every tool that wants to write to the core, and reconciles what each one wrote.
With agents
Grants read access to the systems the account already uses, and one write path to the core that fires only after a checker approves.
Still theirs: The core's data model and who may write to it.
Today
Rekeys the approved file into the core and fixes what was typed wrong.
With agents
Approves or returns every field the Boarding agent will write, each shown with its source.
Still theirs: The checker's signature on every opening.
Today
Owns the program but sees the onboarding tools only through their outputs.
With agents
Approves every change to an agent, threshold or rule after it has been tested, and sees every override by reason code.
Still theirs: Governance of the agents, which no model-risk guidance now covers.
Today
Keeps the document rules in a procedure manual that bankers interpret.
With agents
Keeps the rules as settings, proposes changes as requests, and tests them on a labelled set of past packets.
Still theirs: No authority to approve an opening.
In Business Account Opening (KYB) that governance is part of the product. Every agent has a version, a prompt revision, a threshold and a named owner. A change is proposed by the onboarding administrator, tested on a labelled set of past packets, and approved by the BSA officer before it goes live. Every time a person overrides an agent, the reason code is counted. On the fictional sample bank's governance view, 38 overrides in 30 days are broken down that way; half of them were a banker confirming a line the agent had read below its confidence threshold.
Eight agents, each with a version, a threshold and an owner
A go-live plan that replaces nothing
The plan that works for a community bank keeps every system and changes one thing at a time. Read access first, because it cannot break anything. The bank's own rules next, as settings rather than habits. Then evidence: a replay on closed packets, so the BSA officer approves the tool on the bank's files rather than a vendor's. Then a period beside the bankers, with a person still boarding by hand. Only then the write path, one branch first, with the checker's approval in front of it.
Two things should not move during that plan: the core, and the vendors the bank already trusts for identity and screening. The point of KYB verification that plugs in is that the systems of record stay the systems of record. What changes is that the file arriving at the checker is complete, cited and one click from the core. Where entity verification itself can mislead, and what a clean state filing does not prove, is in business entity verification.
Questions people ask
What is a KYB verification API?
An interface that lets the bank's software send a business or person to a data or verification provider and receive results, such as a registry match, an entity status or an identity check. It supplies evidence; the bank's process still compares it with the packet, decides and keeps the file for the retention periods the rules set.
What are KYB verification services?
Services that check a business against registries and its people against identity and sanctions sources, and return results. Under the CIP and beneficial ownership rules a bank can rely on another regulated financial institution's checks only under a contract and annual certification, so with a vendor the bank remains responsible for the outcome.
What is the KYB verification process?
Collect the entity's identifiers and documents, verify that it exists and is in good standing, identify each owner of 25% or more and one controller on a certification, verify those people, screen the entity and the people, record the nature and purpose of the account, resolve every discrepancy in writing, and approve before boarding.
Does KYB verification replace KYC?
No; it contains it. KYB verifies the business and then runs KYC on each owner, the controller and any signers. A bank's KYB process therefore uses the same identity verification tools as its personal accounts, applied to more people per file.
Do we need to replace our account opening system to add KYB verification?
Not if the tool reads from the systems you already run and writes to the core through its existing interfaces. The safer pattern keeps the portal, imaging, identity and screening vendors and the core, and adds one approved write path at the end.
Is agentic AI covered by bank model risk guidance?
No. SR 26-2, issued in April 2026, places generative and agentic AI models outside its scope and says the bank's own risk management and governance should determine the controls. A bank using agents should be able to show which steps are automated, who owns each agent and how changes are tested and approved.