Table of contents

Fintech

Use Case

How to run KYB onboarding and UBO verification as one workflow

Guillaume Rigal

0 min read

Verifying a business means verifying the company, then everyone who ultimately owns it, however many that turns out to be. Here is what that does to the shape of the work.

KYB, know your business, is the entity version of KYC. You are not verifying a person, you are verifying a company: the registered entity, the people who ultimately own it, and the documents that prove both.

That sounds like KYC with more paperwork. It behaves differently, and the reason is arithmetic.

One KYC case has one subject. One KYB case has as many as the structure holds

A KYC case has a known shape before it opens. There is one person, one identity to establish and one set of documents. Your team can estimate how long it takes because every case looks broadly like the last one.

A KYB case has a company and then an open question: how many beneficial owners sit behind it. Nobody knows until the ownership chain has been walked. It might be two founders on a flat cap table. It might be a holding that owns a holding that owns a trust, with the people who actually control the business appearing three levels down and in another jurisdiction.

Each of those people then needs verifying in their own right. So a single KYB case contains an unknown number of identity checks, running in parallel, in no particular order, and the case cannot close until all of them are done.

The work scales with the shape of each customer rather than with how many of them you onboard. That is the difference everything else in this piece follows from.

One thing this difference is not about: permanence. KYC does not settle forever either. Re-KYC exists, triggered by risk tier, by watchlist movement, by an anniversary, and the KYC lifecycle carries its own monitoring tail. Both processes continue after approval. KYB differs in how many subjects each case contains and in how the structure between them can change.

The registry lookup takes minutes. The ownership chain is the work

Pulling a company register is a solved problem. Your team calls a provider, the entity comes back with its officers and its filed accounts, and that step is done. In the flow it sits between opening the case and everything that matters.

What takes the time is the part no single API returns: establishing who really controls the business when the register only shows the first layer. That means reading incorporation documents, following each corporate shareholder to its own register, often in a different country with a different disclosure threshold and a different definition of what counts as control, and deciding when the chain has been walked far enough.

Topograph and the other registry layers reach the data. The judgement about where the chain ends stays with your analyst, which is why the case has to hold the evidence for that judgement rather than just its conclusion.

Your AI agents can surface the chain, under the same controls as your analysts

This is the part of KYB that has genuinely changed. An AI agent reads incorporation documents, extracts the shareholdings, follows the corporate owners to their own filings and proposes an ownership map with the sources attached. Work that took an analyst an afternoon of tab-switching arrives as a draft.

What an AI agent does not do is own the decision. The map it proposes is evidence, and a person signs off on it, because a supervisor asking how you identified a UBO wants to see the reasoning and who accepted it.

So the AI agent runs as a step in the workflow like any other. Your team sets what it can read, what it can write, and which conclusions still need a human. Every action it takes lands in the same audit trail as your reviewers', under the same roles and permissions. An AI agent that cannot be inspected is one your regulator will ask about.

Coherence controls: when the declared activity and the register disagree

KYB has a check that KYC has no equivalent for. A person's documents either match or they do not. A company makes claims about itself, and those claims can be tested against the public record.

A merchant says it sells garden furniture. The register says the registered activity is something else. Neither fact is fraud on its own, and plenty of businesses have a registered scope that stopped describing them years ago. But the gap is a signal, and the teams that run KYB well test for it automatically rather than hoping a reviewer notices.

"We get the KBIS, get the document for shareholders, and automatically compare the declared activity against what's on the KBIS."

Maxime de Juniac, Chief Service Officer, Swan

The same comparison runs through the whole document step: what the PDF says against what your database already holds. Names, legal names, identifiers, addresses, each with a different answer for an individual and for a legal entity. It is the single most repeated piece of work in KYB, and the one that most repays being a defined step with a defined output.

Underwriting and compliance are reading the same file for different reasons

KYB serves two teams. Compliance is answering a regulatory question: is this entity who it claims to be, and do we know who stands behind it. Underwriting is answering a commercial one: what is the risk of doing business with it.

Both read the same registry data, the same ownership map and the same documents. When they do it in separate tools, the merchant gets asked for the same file twice, the two teams reach their conclusions on different snapshots of the evidence, and the decision trail splits in two.

One case with both teams on it keeps the evidence in one place and the sequence legible afterwards. It also means the merchant hears from you once.

When the ownership changes after you have approved

A verified ownership structure is accurate on the day it is verified. Then a shareholder sells, a holding restructures, a new UBO appears, and none of it announces itself to you.

So KYB carries a monitoring tail with a particular shape: your team watches the registries rather than the calendar. A filed change is the trigger, and it reopens the specific part of the case that moved rather than restarting the whole verification. A new UBO appears, so that person gets verified. The declared activity changes, so the coherence control runs again.

The KYB workflow pattern, step by step

This is the flow as it runs on Forest, from an incoming merchant to a validated file.

#

Step

Task type

What runs

1

Open merchant case

Native

The application becomes a case on your own data, routed by entity type and jurisdiction.

2

Pull company register

MCP

Your registry provider returns the entity, its officers and its filed accounts.

3

Check KYB documents

Native

Incorporation documents and proofs are compared against what your database already holds.

4

Run coherence controls

Native

Declared activity against registered activity, declared ownership against the filed record.

5

Verify beneficial owners

Native

One verification per owner the chain surfaced, running in parallel, the step closing only when all are done.

6

Notify the merchant

MCP

Requests and outcomes go out through your support tool, and the reply lands back on the case.

7

KYB validated

Native

The decision, the ownership map and the evidence behind both are written to your database.

Step 5 is the one that makes KYB what it is. Every other step has a duration you can estimate. This one has a count, and nobody knows it when the case opens.

LEVEL UP YOUR OPS GAME

Every action traced, for every human, AI agent, BPO, LLM, and workflow.

LEVEL UP YOUR OPS GAME

Every action traced, for every human, AI agent, BPO, LLM, and workflow.

LEVEL UP YOUR OPS GAME

Every action traced, for every human, AI agent, BPO, LLM, and workflow.

The operational infrastructure regulated companies grow on

Copyright ยฉ 2026 Forest

Design by Alasta & Built by Reiya Studio