When a platform moves from referring merchants to owning the payment relationship, it inherits a job it never had before: deciding who gets to process, and standing behind that decision. That job is underwriting, and the identity checks underneath it are KYB. Most platforms discover the weight of it only after they have approved a merchant who should not have been approved.
This is the third step of the embedded payments implementation roadmap, and it is where you inherit obligations you did not have as a referral partner. Here is what underwriting and KYB actually involve once you own them, why they are a control function and not a form, and how to run them without turning boarding into a wall.
KYB (know your business) is verifying that a merchant is a real, legitimate business and who controls it. Underwriting is the broader risk decision: whether to approve them, at what exposure and with what monitoring. When you move up from referral to a managed or full payfac model, both become your responsibility. You are now accountable for who you board, and the card networks and your sponsor bank hold you to it.
What is KYB, and how is it different from KYC?
KYC (know your customer) verifies individual people. KYB verifies businesses: legal entity, ownership, beneficial owners and that the business is what it claims to be. Payments boarding needs both, because you are verifying the company and the people who control it. KYB is the part platforms tend to underestimate, because a business identity is messier to confirm than a person's.
What does a platform actually own when it underwrites?
Three things. The approval decision, whether this merchant can process and at what limits. The ongoing monitoring, because risk is not a one-time check at boarding. And the liability, because if an approved merchant runs fraud or racks up chargebacks, the exposure flows up to you and your sponsor bank. Underwriting is not paperwork you clear once. It is a control you run continuously. It is one of the main reasons the decision to move up from a referral model is a business-model call, not a technical one.
Why underwriting is a boarding-conversion problem, not just a risk problem
Every underwriting requirement is also a boarding step, and every boarding step is a chance to lose the merchant. Ask for too much too early and you kill activation. Ask for too little and you approve risk you will pay for later. The craft is collecting the minimum needed to make a sound decision, staged so the merchant is not hit with everything at once. This is where risk and growth are in direct tension, and where most platforms get the balance wrong in one direction or the other. It is the same tension that runs through the whole merchant onboarding flow.
How to run underwriting without a wall
Pre-fill what you already know, because you often hold more merchant data than a standalone processor would. Tier your requirements to risk, so a low-risk, low-volume merchant is not underwritten like a high-risk one. Automate the clear-cut approvals and route only the edge cases to a human. And decide your risk appetite up front, in writing, so boarding is applying a policy rather than making a judgment call every time.
Where platforms get it wrong
Treating KYB as a checkbox at signup and never revisiting it. Approving on thin verification to hit an activation number, then absorbing the chargebacks. Building underwriting as a one-time gate with no monitoring behind it. And under-staffing the function, because the integration looked finished and nobody scoped the operation that runs after it. The underwriting obligations you take on also shape your compliance footprint, which grows with how much of the payments stack you own under the referral versus payfac decision.
Underwriting is a control function, not a form. You are not collecting documents, you are deciding who gets to process and standing behind it, continuously.
For help setting your underwriting policy and boarding flow before you are accountable for either, see the advisory engagement, or work the full sequence from the implementation roadmap.