A KYB (know your business, the verification of a company and its owners) onboarding flow is the sequence a platform puts a business customer through before that customer can move money: collect the company, verify the people behind it, decide how much scrutiny it deserves, and keep the record current. Designed well it takes a day or two. Designed as a document upload page bolted onto a signup form, it takes weeks and loses customers who were never going to be a problem.
This guide is about designing that flow inside your own product, not about what KYB is, which is covered in the KYB explainer. It covers the order of collection, verifying owners, the states to build, risk tiering, what makes onboarding slow, how to test it, and when this is not your job at all.
Know which obligation you are discharging
Before designing screens, be clear about who is obliged to do this and why, because it determines what you can accept and what you cannot skip.
If your platform holds or moves customer funds through a provider, the provider carries the obligation and you are collecting on its behalf under an arrangement that should be written down. If your platform is itself authorized, the obligation is yours directly. In Brazil the framework for virtual asset service providers is Law 14.478 of December 21, 2022, and the underlying duty to identify clients and keep those records current comes from the anti-money-laundering law, Law 9.613 of March 3, 1998. What a VASP (virtual asset service provider, the FATF term) is, and when a business becomes one, is worth settling before you write the first screen, and the VASP explainer draws that line.
The practical version: whoever carries the obligation sets the standard, and your flow implements that standard rather than a lighter one you prefer.
Collect in the order that reduces round trips
The slowest onboarding is not the one with the most fields. It is the one that asks for documents one at a time, each request costing a day of waiting.
Ask the structural question first. Is this a simple company with individual shareholders, or is there a holding company, a fund, or a trust in the chain? The answer changes the entire document list, and asking it up front lets you show the right list once.
Then the company itself. Legal name, registration number, registered address, the incorporation document, and the operating details: what the business does, which countries it operates in, expected volumes and the purpose of the account.
Then the people. Identity documents and verification for the individuals the rules require, which is not the same as the people who signed up.
Then the extras that depend on the answers above. Ownership charts, fund registers, letters from a fund manager, licences for regulated activities.
Showing the full list for the structure the applicant describes, on day one, is the single change that most shortens onboarding. It costs you one extra question at the start.
Verify the people the rules point at, not the people in the room
Every regime asks for the individuals behind the company, with two prongs that people routinely conflate.
Under the United States rule at 31 CFR 1010.230, a financial institution identifies each individual who, directly or indirectly, owns 25 percent or more of the equity interests of a legal entity customer, plus a single individual with significant responsibility to control, manage or direct it, such as a chief executive, a chief financial officer, a managing member or a general partner. The rule also says that where a trust holds 25 percent or more, the beneficial owner for this purpose is the trustee. In the European Union, Directive (EU) 2015/849 treats a holding of more than 25 percent as an indication of ownership today, and Regulation (EU) 2024/1624, which applies from July 10, 2027, moves the threshold to 25 percent or more.
Two consequences for your design. There may be zero individuals on the ownership prong and there is always one on the control prong, so a form that requires at least one owner will block legitimate widely held companies. And indirect ownership means you cannot collect a flat list of shareholders, you need the chain, which is why the structural question belongs at the start.
Build the states, not the screens
An onboarding flow is a state machine, and the states are what your support team lives in.
Not started. The customer exists and verification has not begun. Usually because a document is missing, and your interface should say which.
In review. Submitted and being checked. Give a realistic expectation here rather than a spinner.
Information requested. The checker needs something specific. This is the state that decides your onboarding time: if the request reaches the customer in an hour with a plain description of what is needed, it costs a day; if it sits in an inbox, it costs a week.
Approved. Usable, with whatever limits the risk tier implies.
Rejected. Distinguish a permanent rejection from a fixable one, and say which it is. A customer who can fix something and is told only that they failed will call you, and they are right to.
Each state needs an event your system reacts to, a screen your customer sees, and a note your support team can read. The integration mechanics behind that are in the API integration guide.
Tier the risk instead of treating everyone alike
Not every business customer needs the same depth, and pretending otherwise punishes the ordinary ones.
A domestic company with a common business type, modest expected volumes and a simple ownership chain is the base case. A company with a complex structure, a higher-risk sector, cross-border flows into several countries, or ownership in a jurisdiction that requires extra scrutiny sits higher, and higher means more documents, more verification and usually a human decision.
Tiering has to be written down before it is applied, because a tier decided case by case is not a policy, it is a mood. Which countries you can serve at all is a separate and prior question, and ours is published on the supported countries page.
The number that changed how I think about this came out of a review we did of our own queue. I had assumed our slow onboardings were the complicated ones, the funds and the holding structures, and when we actually measured where the days went, most of the elapsed time was not verification at all. It was waiting for the customer to answer a message, and the messages we sent were generic requests for more information that a person had to interpret before they could act. We rewrote them to name the document, say who had to sign it, and give an example, and the same queue with the same checks got materially faster without anybody changing a policy. My takeaway is that onboarding time is mostly a writing problem wearing a compliance costume.
What actually makes onboarding slow
Documents requested one at a time. Each round trip is a day, and four round trips is a lost week.
Requests a human cannot act on. "Additional documentation required" is not a request. Name the document, the signer and the format.
Nobody owning the queue. A case with no owner ages. Someone should be looking at the oldest one every morning.
Collecting what you will not check. Fields nobody reads add friction and give the customer a false impression of what matters.
No expiry policy. Records go stale, and the obligation is to keep them current rather than to have collected them once. Decide the refresh cadence when you design the flow, not two years later.
Test the flow before real customers meet it
A good provider lets you force each outcome in sandbox rather than waiting for a real rejection. Ours uses sentinel values in the tax ID field, documented with the verification flow, so you can make a customer come back as not started, as needing documents, or as permanently rejected, with the webhooks firing as they would in production.
Walk your own flow as a customer with a deliberately awkward structure, a holding company and a fund, and count the round trips. That number is your onboarding time, and it is the one to improve.
When this is not your job
When your provider onboards your customers directly. Some arrangements have the customer contract with the provider, which moves both the obligation and the queue away from you, and changes your job to handing over clean data.
When you have no customers yet. Designing a tiering policy for a customer base you have not met produces a policy you will rewrite.
When the answer is that you cannot serve them. If a business sits outside the countries or sectors you support, the useful outcome is a fast and clear no rather than a long and polite maybe.
Onboarding on Lumx
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
On the global payments API, a business customer is an object you create, with associated parties for the individuals the rules require, documents attached to whichever party they belong to, and a verification you start when the set is complete. Every status change emits an event, a request for information carries what is being asked for, and a rejection distinguishes the permanent kind from the fixable kind. Verification of associated parties can be retried in isolation, so one person's failed check does not restart the whole company's onboarding.
Verified on September 25, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Jonathan Cosens Photography on Unsplash.
Who has to be verified when onboarding a business?
The company itself, the individuals who own 25 percent or more of it directly or indirectly, and at least one individual who controls or manages it. The people who happen to be signing up are only relevant if they fall into one of those groups, and a company with no single 25 percent owner still has a control person to identify.
How long should business onboarding take?
One to three days for a simple company with a clean structure and complete documents, and one to three weeks when there is a holding company or a fund in the chain. Most of the difference is waiting for documents rather than checking them.
Can I onboard a customer before they are verified?
You can create the customer and collect data, and you cannot let them move money. A useful design lets someone explore the product while verification runs, with the money functions visibly locked and the reason stated.
How often do we have to refresh what we collected?
The obligation is to keep customer records current rather than to have collected them once. Set a refresh cadence by risk tier when you design the flow, and trigger an out-of-cycle refresh when something material changes, such as a new owner or a change in the business activity.
