UBO software identifies a business customer's ultimate beneficial owners, the individuals who own or control it through however many companies stand in between, and records how it reached each one. In a US bank that means finding everyone at 25% or more and one controller under FinCEN's Customer Due Diligence Rule, verifying who they are, and keeping the evidence. Most of that is routine. The hard part, the part where hand processes and simple tools fail, is turning operating agreements, member registers and cap tables into a chain of stakes and computing each person's effective share correctly. Botminds' Beneficial Ownership Verification gives that job to one agent, the Ownership Builder, and puts a second agent and a person behind it. Examining that one agent is the fastest way to judge any UBO software, ours included.
What the ownership chain reader produces: a tree with every step of the math
Each figure on an arrow opens the passage it came from, such as Schedule A or section 3.1 of an operating agreement. The two computations on the right were made separately, on two different models.
What UBO software has to do, and which part is hard
Five jobs make up the work, and they are not equally difficult. Collect the customer's certification and documents. Read the documents into stakes and roles. Chain the stakes into a tree and compute each person's effective share. Verify each person's identity and screen people and entities. Decide, record and keep the evidence. The first and fourth are well served by existing systems: client portals collect documents, and identity and sanctions services check people. The last is a person's job by rule and by sense.
The second and third are where errors live. The certification asks the customer to name its owners, and FinCEN conceded in 2016 that the person signing often cannot know first-hand who holds a stake through intermediate companies or nominee arrangements (81 FR 29398). The bank may rely on the form unless it knows better, and what it knows is mostly in the documents. Software that cannot read them is a filing cabinet with a chart tool attached.
Some of these defendants allegedly used the assets of the company to acquire shell companies, while other defendants are alleged to have further obscured the ownership of these companies through complex legal structures involving other shell companies.
FinCEN, final Customer Due Diligence rule, May 11, 2016
How does UBO software work? Two families, and why only one helps a US bank much
UBO software works in one of two ways: it looks owners up in registries and data sets, or it reads them out of the customer's documents. Lookup tools query corporate registries and commercial databases for directors, shareholders and group structures. Where a jurisdiction keeps a beneficial ownership register, they can be fast and broad. Document readers start from what the customer gave the bank and build the structure from it, citing each stake.
For US companies the lookup family has lost its main federal source. Since FinCEN exempted US companies from reporting their owners in 2025, made final in August 2026 (91 FR 52508), there is no federal register of US-company owners to look up, and bank access to FinCEN's database always required the company's consent. A lookup still helps with existence, officers and foreign parents. For the question the certification answers, who owns 25% of a US limited liability company, the evidence is usually the company's own operating agreement.
Two kinds of UBO software, judged on a US limited liability company
Registry and data lookup: Corporate registries and commercial data sets.
Document-reading agents: The customer’s operating agreements, registers, cap tables and trust deeds.
Registry and data lookup: Rarely listed: no federal owner register since 2025, and state records vary in what they show.
Document-reading agents: Read from the documents the bank already collects or asks for.
Registry and data lookup: Only as deep as the data goes; often stops at the first foreign or private holder.
Document-reading agents: As deep as the documents go; each layer needs its own agreement.
Registry and data lookup: A search result and a timestamp.
Document-reading agents: The passage and page behind every stake, and the arithmetic.
Registry and data lookup: Foreign parents, listed groups, sanctions and adverse-media screening.
Document-reading agents: Private US entities, layered LLCs, disagreements between the form and the papers.
Inside the Ownership Builder agent: what it takes in, what it produces, what it never does
The Ownership Builder agent builds the tree and computes each person's effective ownership through every layer. It multiplies along each path, adds the paths, solves loops exactly rather than cutting them, and writes the working out so a reviewer can redo it. It does not read the documents itself: a Document Reader agent has already extracted each stake with its exact passage and page, and has marked any missing page as missing instead of guessing. Separation matters here. An agent that both reads and computes can hide a misread inside a sum; two agents with written hand-offs leave a trail.
The Ownership Builder agent, as a specification
Takes in
- Every stake and officer designation the Document Reader agent extracted, each with its passage and page
- The customer’s certification, as signed
- The bank’s settings: the ownership line, the tolerance, loops solved rather than cut
Produces
- The ownership tree, every layer, with a source on every arrow
- Each person’s effective ownership with the multiplication written out
- Who crosses the line, who does not, and why, in a sentence
Hands to
- The Ownership Checker agent, which recomputes on a different model without seeing these numbers
- The Structure Risk agent, for loops, nominee signs, trusts and bearer shares
- The KYC analyst, who decides
Never
- Rounds before the last step
- Settles a holder on its own computation
- Signs, corrects or replaces the customer’s certification
On the sample file the agent read ten stakes held by six holders across three layers. Its result for Marisol Ortega, the owner the certification left out, is a single line: 18% direct + 60% × 15% via Ortega Family Holdings = 27.0%. Every number in that line opens its source; the 60% comes from section 3.1 of the holding company's own operating agreement. The method is the one FinCEN's FAQ B.13 uses, and the one the EU's anti-money laundering regulation writes into law from July 2027 (Article 52); the arithmetic itself is set out in how to calculate beneficial ownership percentage.
Can AI read an operating agreement?
It can find and extract what an operating agreement says about ownership, if it is held to citing where it found each figure, and that condition is the whole test. Ownership hides in different places: a member schedule in percentages, a unit register in counts that must be divided by units outstanding, a capital account table, an amendment that admits a new member two years later. A reader that returns "Marisol Ortega: 18%" without a page cannot be checked; one that returns "18%, Schedule A, page 14, as amended 3 March" can.
Regulators describe AI in identity work as normal and supervised. Treasury reported in 2024 that AI is widely used for anti-money laundering compliance, identity verification under the Bank Secrecy Act among the uses (Treasury, AI in financial services, 2024). GAO found that the regulators themselves never let AI decide alone or serve as their only input (GAO-25-107197; AI in enhanced due diligence draws the same line for reviewers). A bank evaluating UBO software can hold it to the same standard: the agent reads and proposes, a person decides, and nothing the agent says is unsupported by a passage.
Why a second computation, on a different model
Because the most dangerous error in this work is a plausible number. A misread unit count or a stale cap table produces a percentage that looks right. In Beneficial Ownership Verification an Ownership Checker agent recomputes every holder from the documents on a different model, and compares its answer with the Builder's only after its own is written. If any holder differs by more than 0.05 percentage points, the file is held for an analyst with both workings and the passages that differ. The target is that every legal-entity file has two independent computations that agree before any owner is settled.
A sample case shows why. At Arbor & Vine Restaurants, a fictional sample customer, the Builder put Colm Rafferty at 25.0% from the operating agreement and the Checker at 24.6% from a cap table dated 1 September, which did not show units issued to him on 28 August. Neither agent was wrong about its document; the documents disagreed. Which one governs, or whether to ask the customer, is a judgment, and the solution leaves it to the analyst, who records a reason and has it approved by QC.
The certification queue: where the agents agree, and where they hold a file for a person
Where the agent stops, and the person starts
The chain reader proposes a tree; it does not settle an owner, sign or amend a certification, or decide that a customer is a risk. Those limits are written into each agent in the solution. The full pipeline below shows where each agent's work ends and a person's begins. The rule itself draws the line: the customer identifies its owners, the person opening the account certifies them, and the bank verifies identities and notices what calls the form into question (31 CFR 1010.230(b)).
From certification to recorded decision: seven agents, three people
Agent
Document Reader agentExtracts each stake and officer designation from the certification and documents, with its passage and page.
Never: infers a stake that is not written
Agent
Ownership Builder agentBuilds the tree and writes out each person’s effective ownership.
Never: settles a holder on its own
Agent
Ownership Checker agentRecomputes every holder on a different model, then compares.
Never: sees the Builder’s numbers before writing its own
Agent
Structure Risk and Identity agentsFlag loops, nominee signs, trusts and bearer shares; verify identities and screen against OFAC.
Never: decides risk or clears a potential OFAC match
Agent
Relief and Outreach agentsDetermine whether re-verification is owed for an existing customer; draft any corrected-certification request.
Never: sends anything without QC approval
A person decides
KYC analystDecides the governing document, records the decision and its reason code.
A person decides
QC reviewer and BSA officerQC approves each decision and request; the BSA officer approves thresholds and procedure.
Who governs an agent like this? Your own model risk practice
The interagency model risk guidance does not cover it, so the bank's own governance must. SR 26-2, issued in April 2026 to replace SR 11-7 and SR 21-8, leaves generative and agentic AI outside its scope and tells each banking organization to set the controls for such tools through its own risk management and governance (SR 26-2; agentic AI for KYC reads the passage in full). For a chain reader that means the same questions a validator would ask of any tool that produces numbers people rely on: what are its inputs, how is its output checked, how are versions controlled, and how is an override recorded.
The design choices that make that governance practical are concrete. Prompts and models are versioned, so a decision can be tied to the configuration that produced it. Every human override carries a reason code. Two computations on two models give a standing measure of agreement that a validator can sample. And the agents' limits are configuration, not hope: the Builder cannot settle a holder because the system will not let a single computation settle one.
What to look for in UBO software: questions for the demonstration
Ask to see each answer on one of your own past files, not the vendor's sample. A layered LLC your team already reviewed, with the reviewer's chart held back, is the cleanest test, and how to run that comparison is set out in beneficial ownership chart tool vs spreadsheet vs registry.
Eight questions to put to any UBO software
- Where does each owner come from?
A registry, a data set or a document? For a US LLC, the answer should usually be a document.
- Does every stake cite its passage and page?
If a reviewer cannot open the source of a number, the number cannot be relied on.
- Is the multiplication written out?
18% + 60% × 15% = 27.0%, not just 27%. Ask how loops are handled.
- Who checks the arithmetic, and when?
A second independent computation before the account opens, or QC sampling afterwards?
- What happens when two documents disagree?
The tool should hold the file and show both, not pick one silently.
- What can the software never do?
Sign, settle an owner, clear a sanctions match, send to a customer: ask where those limits are enforced.
- Can you see the file as it stood on the day the account opened?
Examiners and auditors ask for the past, not today’s version.
- How does it handle FinCEN’s 2026 relief?
A determination for each existing customer’s new account, with a reason and a person behind it.
Where Beneficial Ownership Verification fits among UBO software, and where it does not
It fits a bank that collects entity documents at opening and wants every certification compared with them, with the arithmetic shown and a person deciding. Its agents read the certification, operating agreements, member registers, cap tables, trust agreements and registry extracts; it works alongside the client lifecycle system, the core banking system, the identity verification service and the OFAC screening service the bank already runs.
It is not a registry, a sanctions-list vendor or an adverse-media service, and it cannot find an owner who appears in no document the bank holds. It does not decide the bank's ownership line or its use of FinCEN's relief; those are settings the BSA officer approves. And it is not a substitute for asking: when a structure stops at a holding company whose own agreement is missing, the right output is a request to the customer, which the solution drafts and QC approves. What a missed owner costs, and how to weigh that against the price of software, is the subject of beneficial ownership software and what a missed owner costs.
Questions people ask
What does UBO mean in KYC?
UBO stands for ultimate beneficial owner: the natural person who ultimately owns or controls a customer, however many companies stand in between. The US rule says "beneficial owner", and FinCEN expects the customer to name the real people at the top of the chain, never nominees or front men (FAQ B.8).
What is a UBO check?
A UBO check identifies a customer's beneficial owners and verifies who they are. In a US bank it covers each person with 25% or more, directly or indirectly, and one controller, each verified with name, date of birth, address and an identification number.
Is UBO software required by regulators?
No. The rule requires written procedures "reasonably designed to identify and verify" beneficial owners, not any tool. Software is a way to apply those procedures consistently; the bank remains responsible for the result.
Can UBO software pull owners from FinCEN's BOI database?
Not for US companies. They no longer report to FinCEN, bank access always needed the company's consent, and FinCEN is deleting information it believes US persons provided. For foreign parents, other jurisdictions' registers may help.
Does UBO software replace the KYC analyst?
It should not. The rule's reliance test turns on what the bank knows, and deciding what a contradiction means, which document governs, or when to ask the customer is judgment. Good software removes the reading and arithmetic so the analyst's time goes on those decisions.
How do you test UBO software before buying it?
Run it on a sample of your own past certifications and entity documents, with your reviewers' conclusions held back, and count what it finds that you found, what it finds that you missed, and what it misses. Ask to see the source of every stake on screen.