KYB Onboarding
KYB onboarding is the regulated process of verifying a business's identity, structure, and beneficial owners before allowing it to transact on a fintech or marketplace platform. It collects incorporation records, UBO data, and tax IDs and runs sanctions screening on every party involved.
What KYB onboarding is
KYB — Know Your Business — is the regulated verification process every fintech platform runs on a business before allowing it to move money. KYB onboarding is the merchant-or-customer-facing flow that collects the inputs needed to verify the entity: incorporation documents, registered address, tax identifier, beneficial ownership data, and screening results.
KYB exists because regulators do not allow platforms to onboard businesses without knowing who ultimately owns and controls them. The output of a KYB flow is a verified business record with a risk score, an approved tier, and a record of every individual whose identity was also verified inside the business (each of whom typically completes KYC onboarding as part of the same flow).
How KYB differs from KYC
KYC onboarding verifies an individual. KYB verifies a legal entity, and behind that entity, the people who control it. The verification chain is usually: business documents → ownership structure → KYC on every controlling individual → aggregate risk score for the entity.
Because businesses come in many shapes (sole proprietor, LLC, S-corp, GmbH, Pvt Ltd), KYB flows have to branch on entity type. A sole proprietor flow looks closer to KYC. A multi-entity holding structure with foreign subsidiaries can require a dozen or more verifications before the parent is approved.
What a complete KYB flow looks like
A production KYB onboarding flow typically has these phases:
- Business identity capture. Legal name, registered address, country of incorporation, tax ID (EIN, GSTIN, VAT, ABN, etc.).
- Documentation upload. Certificate of incorporation, articles of association, business license, bank statements when required.
- Ownership decomposition. Identify every Ultimate Beneficial Owner (UBO) — usually anyone with 25%+ ownership or control. KYC each one.
- AML screening. Run sanctions, PEP, and adverse-media checks on the business and every UBO.
- Risk scoring. Combine entity type, geography, industry classification, ownership structure, and screening results into a tier.
- Tier and policy application. Map the tier to product permissions: payment limits, payout speeds, supported geographies.
Engineering decisions
Three production decisions matter most:
- State machines per UBO. Each ultimate beneficial owner is its own KYC state machine. The KYB flow is a coordinator over them.
- Document orchestration. Different vendors handle business documents (Persona Cases, Veriff KYB, Onfido Studio); orchestration logic must tolerate vendor-specific webhook shapes.
- Audit-grade history. Every document version, every screening result, and every UBO change must be retained for the retention period the regulator requires (typically 5–7 years).
A fintech development team usually owns the KYB orchestration layer in-house even when the document and screening vendors are off-the-shelf. The platform’s compliance posture lives inside that orchestration code.
Code-shape example
Modeling KYB as a parent state machine with child KYC machines:
interface KybBusiness {
id: string;
state:
| "documents_pending"
| "ubos_pending"
| "ubos_kyc_in_progress"
| "screening"
| "manual_review"
| "approved_tier_1"
| "approved_tier_2"
| "rejected";
legalName: string;
jurisdiction: string;
taxId: string;
ubos: { customerId: string; ownershipPct: number; controlRole: string }[];
documents: { type: string; url: string; uploadedAt: string }[];
riskScore?: number;
}
// Advance only when every UBO has reached a terminal KYC state.
export async function maybeAdvanceUbosKycComplete(
businessId: string,
): Promise<void> {
const b = await db.kyb.find(businessId);
if (b.state !== "ubos_kyc_in_progress") return;
const ubos = await Promise.all(
b.ubos.map((u) => db.kyc.find(u.customerId)),
);
const allDone = ubos.every((u) =>
["approved_tier_1", "approved_tier_2", "rejected"].includes(u.state),
);
if (!allDone) return;
if (ubos.some((u) => u.state === "rejected")) {
return advance(b, "rejected", { reason: "ubo_rejected" });
}
return advance(b, "screening");
}
The pattern keeps the parent flow free of vendor-specific KYC details, and the children re-use the same KYC infrastructure as individual onboarding.
How we implement it at Dashhold
Patterns we ship on every KYB engagement:
- One coordinator service, multiple vendors. Document parsing through Persona, KYC through Onfido, registry lookups through OpenCorporates and local equivalents. The coordinator is ours.
- Per-jurisdiction policy modules. US LLC, UK Ltd, India Pvt Ltd each have different document expectations. Encode each as a module with the same interface so the parent flow does not branch.
- UBO change re-verification triggers. When ownership shifts past 25%, the system flags it for re-verification automatically. This is the regulator-facing behavior auditors check first.
- Document versioning, not replacement. When a business uploads a renewed certificate, the old one is preserved with a
superseded_attimestamp. - Manual-review tooling that surfaces the structure visually. Compliance analysts get a graph view of the entity, its UBOs, their KYC states, and screening hits — not a list of fields. Decision time drops from 20 minutes to 4.
Common pitfalls
- Treating UBOs as a flat list. Multi-tier ownership (entity owns entity owns entity) is real. Model the graph, not a list.
- Allowing self-attestation alone. Some platforms let the business declare its UBOs without document proof. Most regulators do not accept this; build proof-collection in from day one.
- Static risk scores. Risk should re-score on UBO changes, transaction velocity changes, and adverse-media hits. Static scores age badly.
- Inconsistent document formats per market. Build local-format readers for at least your top three markets; otherwise compliance analysts spend hours interpreting documents.
- No re-screening cadence. Sanctions lists update daily. A monthly re-screen is the regulator’s expectation; daily is better. Build the loop early.
Where KYB sits in a fintech platform
KYB onboarding is the gateway every B2B payment platform, marketplace, or banking-as-a-service product runs on a merchant before letting them transact. It is heavier than KYC but follows the same principles: progressive verification, clear error states, structured persistence of every regulator-facing artifact.
See also
- KYC onboarding — the individual-verification companion to KYB
- AML screening — sanctions and PEP screening run inside KYB
- Payment platform — the broader system KYB gates for businesses