Seller onboarding is where compliance and growth collide. The product team wants a seller selling within minutes. The risk team wants every owner verified before a single dollar moves. Treat that as a binary and you lose either way: a hard wall in front of every seller bleeds conversion, and a wide-open door invites the money laundering and fraud that gets a platform's payments partner to terminate the relationship.
The fix is to stop thinking of onboarding as one wall and start thinking of it as a gate with stages. Collect what you legally must, but time each check against what the seller is actually allowed to do. Most sellers should be able to list, sell, and even take payments before they have finished proving everything.
This module sits between the merchant-of-record decision (module 3) and the platform ledger (module 5). Who is the merchant of record determines whose name the regulator and card networks see, which in turn determines who owns the KYB obligation. Get that settled first, then build the gate.
Why the gate exists at all
When your platform moves money on behalf of sellers, you inherit obligations under anti-money-laundering law. In the US, the relevant baseline is FinCEN's Customer Due Diligence (CDD) rule, which requires covered financial institutions to identify and verify a legal entity customer's beneficial owners.
Two prongs matter. The ownership prong requires identifying each individual who owns 25 percent or more of the entity. The control prong requires identifying one individual with significant managerial control, regardless of ownership percentage. A single-owner LLC produces one name under both prongs. A company with four equal partners at 25 percent each plus a hired CEO can produce five.
Note a recent change. On February 13, 2026, FinCEN issued exceptive relief (FIN-2026-R001) that removed the requirement to re-verify beneficial owners every time an existing customer opens a new account. You still verify at first account opening, when you have reason to doubt prior information, and as your risk-based procedures demand. The first onboarding still carries the full weight, so the gate matters as much as ever.
Card network rules add a parallel layer. Visa and Mastercard require platforms acting as payment facilitators to underwrite and monitor their sub-merchants, which is why your acquirer or payments provider pushes KYB requirements down to you whether or not you wanted them.
KYC and KYB are not the same gate
KYC (Know Your Customer) verifies individual people: the beneficial owners and the control person. You collect name, date of birth, address, and a government identifier, then verify against ID documents and databases.
KYB (Know Your Business) verifies the entity itself: legal name, registration number, formation jurisdiction, and operating status. You confirm the business is real, registered, and not on a sanctions or watchlist, then map its ownership structure to find the people KYC then checks.
A sole proprietor collapses both into roughly one identity. A multi-layer entity, where an LLC is owned by a holding company owned by a trust, forces you to pierce each layer until you reach natural persons. Your onboarding flow has to handle both without forcing the sole proprietor through the corporate maze.
Designing the gate: stage checks against capabilities
The principle that keeps conversion alive is capability gating. Do not block the whole account until everything is verified. Block specific capabilities until the check that legally protects that specific capability is complete.
A workable staging for a US seller looks like this.
Stage one: account creation
Collect email, business name, and country. Run a lightweight watchlist screen on the business name. Let the seller build their listing or storefront immediately. Nothing here moves money, so nothing here needs the full file.
Stage two: accept payments
Before the seller can take a customer payment, collect the entity registration details and the control person's identity, and verify them. This is the point where money starts flowing toward the platform, so this is where KYB and the control-prong KYC must clear.
Stage three: receive payouts
Before money leaves the platform to the seller's bank, complete the remaining beneficial ownership KYC on any 25-percent-or-greater owners, plus bank account verification. Payout is the highest-risk leg because it is where laundered funds would exit, so it carries the heaviest check.
This staging maps cleanly onto how a provider like Stripe Connect exposes the work. Stripe's Account object carries a requirements hash that sorts outstanding items into currently_due, eventually_due, and past_due, and it gates the charges_enabled and payouts_enabled flags on whether the relevant requirements are satisfied. You drive your UI off those buckets: show the seller only what is currently_due for the capability they are trying to unlock, and hold the rest until they need it.
A worked example
Take a home-goods seller, a two-owner LLC, joining your marketplace.
At sign-up, they enter the business name and start uploading product photos within two minutes. No verification has run beyond a name screen, and they are already getting value.
When they request the ability to accept payments, the flow asks for the LLC's state registration number and the managing member's ID. Both verify automatically against registry and identity data. The seller is now charges_enabled and can sell, perhaps 10 minutes into the relationship.
The second owner, who holds 40 percent, is only prompted when the seller adds a payout bank account. At that point your flow collects and verifies the second owner's identity because the 25 percent threshold pulls them into scope. The seller completes it because they want their money, not because a wall stopped them on day one.
The same flow degrades gracefully. If the registry check fails, the requirement reappears in your equivalent of currently_due with an error, you ask for one document, and you do not invalidate the rest of the verified file.
What kills conversion, and what does not
The conversion killer is almost never the existence of checks. It is asking for everything at once, asking for it before the seller has felt any value, and asking for documents you could have verified silently against data.
A few habits help in practice. Verify against data first and fall back to document upload only on failure, because most sellers clear data checks instantly. Persist partial progress so a seller who drops off mid-file resumes rather than restarts. Surface a single clear next action rather than a wall of fields, which is exactly what consuming a currently_due-style bucket gives you for free.
Takeaway
Seller onboarding is a legal gate you cannot remove, but you control its shape. Verify the entity and its beneficial owners because the CDD rule and the card networks require it, and verify them well at first onboarding because that is when the obligation bites hardest. Then stage each check against the capability it protects, so the sole proprietor sells in minutes and the multi-owner entity only faces its full file when it reaches for a payout. A gate that opens in stages protects the platform and keeps the seller moving. A wall does neither.