Most teams meet KYB at the worst possible moment: integration is done, the demo went well, someone says "let's go live," and only then does the word "onboarding" turn out to mean something. The verification was always going to happen. The surprise is self-inflicted, and it is avoidable.
KYB — know your business — is how a payment provider establishes who it is providing infrastructure to before that infrastructure starts moving real money. It is the business-side counterpart to KYC: where KYC verifies a person, KYB verifies a company and the people who control it. It is not a badge you earn, not a certificate the provider issues on your behalf, and not a setting you toggle in the API. It is a process. Treat it like one and it stops being a wall.
What KYB is actually for
Strip away the acronym and KYB answers three questions about the entity asking to accept payments:
- Is the business real? That the company exists, is registered, and is what it claims to be.
- Who controls it? Tracing ownership through any holding structure to the natural persons who ultimately own or direct it — the beneficial owners — and verifying those individuals.
- Is it permitted to do this? That the activity and the regions involved are within scope for moving value through the rail.
The reason this is verification and not a fixed form is that a company can be a thin layer of paperwork over an unknown owner. The whole point is to look through the paperwork to the people, so that a business onboarded to accept crypto is a real operation run by identifiable humans rather than an anonymous conduit. That is also why the depth scales with risk: a straightforward online store and a higher-risk, multi-jurisdiction operation are not assessed the same way, and pretending otherwise with a universal checklist would be dishonest.
This is why I won't hand you a document list. The specifics — what evidence, how deep, which jurisdictions in play — are settled in the onboarding conversation, where someone can actually look at your particular case. Any blog post that promises you the exact set of documents is either wrong or describing one provider's snapshot that won't survive contact with your situation.
The mistake that costs you a launch week
Here is the assumption that bites: that KYB and your engineering work happen in sequence, and the build waits behind the paperwork.
It doesn't, and designing as if it does is how teams lose a week.
A sandbox API key talks to the same REST API as production. Every invoice and payout you create with it is test data — no real funds move on-chain — but the request shapes, the responses, and the webhook events are the real ones. So you can build the entire integration while KYB is in progress: create invoices, render checkout, wire up single and mass payouts, and — the part most teams underweight — get your webhook signature verification correct against real event payloads. None of that needs a verified business behind it.
What KYB gates is the live key. Until verification is complete, a live key cannot settle an actual deposit or release an actual payout. That gate is the entire point of verifying the business up front — it is the line between test data and real value, not the line between you and starting.
So the sequence that works is boring and fast: build against the sandbox now, run KYB in parallel, swap the key when both are ready. Going live becomes a credential swap, not a rebuild. The same endpoints and the same request bodies you tested start carrying real balances the moment the live key is in play. Teams that internalize this stop treating KYB as a blocker and start treating it as a background process — which is what it is.
Be precise about the language
Compliance copy rots when the words get loose, so this matters more than it sounds.
Completing KYB does not make your business "licensed" or "regulated," and it does not make the provider those things either. Those are regulatory statuses with specific legal meaning. KYB is a verification step — something a provider does, not a status it holds. A provider that has run KYB on you has checked who you are; it has not conferred a regulatory standing on either party, and it shouldn't claim to. If a payment provider's marketing blurs that line, read it as a warning, not a feature.
The same precision applies to where responsibility sits. KYB does not absorb your own obligations. Whether your activity is permitted where you operate, what you must report, and whether you need a license you must hold — those remain yours. A provider verifies the business and keeps an accurate, attributable record of money movement; it does not substitute for advice from someone qualified to give it. The honest division of labor is: the provider runs the plumbing and keeps the receipts, and you stay accountable for whether the business those receipts describe is lawful for you to run.
Where KYB sits in the bigger picture
KYB is the front door, but it isn't the whole house. It happens at onboarding — and it isn't strictly one-and-done; a provider typically refreshes the picture when something material changes, like ownership or what the business does. Once you're live, the relevant control shifts to AML awareness: money movement through your account is watched for the patterns that warrant attention, and the actions that move funds run through scoped permissions and operator approval, recorded as they go. That audit trail on outbound money — who drafted a payout, who approved it, when — is exactly what an AML or internal reviewer expects to find.
If you want the full shape of how this fits together — KYB at onboarding, AML awareness in operation, the travel rule as a concept rather than a certification, and which activities are out of scope — the compliance FAQ is the page that lays it out. And if you are about to start onboarding and want a clearer picture of what verification establishes and why it runs alongside your build, what you need for KYB onboarding is the direct answer.
The short version
If you take one thing from this: KYB is the expected, upfront step of any serious payment relationship, not friction invented to slow you down. Build against the sandbox immediately, run verification in parallel, and don't let "we still have to do onboarding" become the reason your launch slips.
And keep the words honest. KYB is a process you complete, AML is a posture you maintain, and "licensed" and "regulated" are statuses nobody on this side of the conversation should be handing out. None of this is legal advice — where a question turns on what is lawful for your specific business, the answers come from the onboarding conversation, where the details can actually be assessed, and from your own counsel.