KYC vs. KYB: What Every Fintech Needs to Know Before Launch

This is written for founders, product leads and operators making onboarding decisions before a product ships — the point at which those decisions are still cheap to change. It covers what each process actually requires, why KYB is the harder half, the sequencing mistake that forces a lot of fintechs to rebuild onboarding inside their first year, and the five decisions worth settling before anyone writes onboarding code.

What each one actually establishes

KYC — Know Your Customer — establishes that a natural person is who they claim to be, that they do not appear on a sanctions list or in adverse media, and that their expected activity is consistent with the profile they have given you. The mechanics are well-trodden: a government identity document, a liveness or selfie match against it, an address or tax-identifier check, and a screening pass against sanctions, politically-exposed-person and watchlist databases.

KYB — Know Your Business — establishes the same things about a legal entity: that the company exists, that it is registered and in good standing, what it actually does for revenue, and — the part that carries most of the operational weight — which natural persons ultimately own or control it. Those people are the ultimate beneficial owners, and once you have identified them, each of them needs to go through something that looks a lot like KYC. That is the structural point most product plans miss: KYB is not an alternative to KYC. KYB contains an unknown number of KYCs, and you do not know how many until you have unpicked the ownership structure.

In the United States, the requirement to identify beneficial owners of legal-entity customers is set out in FinCEN's Customer Due Diligence Final Rule, which uses a 25% ownership threshold plus one individual with significant control. The EU's anti-money-laundering directives land in a similar place with local variation, and most other regimes have converged on something close. The threshold is not the interesting part. What the threshold implies about your data model is.

Why KYB is the harder half

Ownership is a tree, not a field. A business applies as, say, a trading company registered in one country. Sixty percent of it is held by a holding company in a second country. That holding company is 45% owned by an investment vehicle in a third, and the rest is split between two individuals below the threshold. You cannot stop at the first layer — you have to walk down until you reach natural persons whose effective ownership crosses your threshold, multiplying percentages as you go. Three layers is ordinary. Five is not rare. And the moment a trust, a nominee arrangement or a bearer-share structure appears in the chain, the automated path ends and a human has to make a judgment call.

Registry quality is wildly uneven. Some jurisdictions publish structured, current, free company data with an API. Others publish scanned PDFs, charge per lookup, update once a year, or do not record ownership at all — only directors. Any vendor claiming global KYB coverage is really claiming good coverage in a set of markets and best-effort document collection everywhere else. Ask which markets are which before you sign, because that list determines which customers you can onboard in minutes and which will take two weeks.

The document set is not standardized. A certificate of incorporation, a certificate of good standing, a board resolution authorizing an individual to open the account, a recent registry extract, an ownership chart — these have different names, different formats and different validity windows in every country, and in several of them the "official" version arrives only by post. Your onboarding UI has to handle a document type it has never seen before without dead-ending the applicant.

There is always a human in the loop. Even with strong automation, a meaningful share of business applications will land in manual review. That is not a failure of the system; it is the system working. What matters is whether you have designed for it — a queue, a reviewer, a decision-recording standard, an SLA the sales team can quote — or whether manual review is an unplanned interruption that lands on whoever is least busy.

The sequencing mistake that forces a rebuild

The common pattern is to ship a consumer-shaped onboarding first, because the first customers are individuals and KYC is the tractable half. Then the first business customers arrive, and the data model turns out to have no concept of an entity that has owners who are themselves subjects of verification. There is no way to represent a person acting on behalf of a company. Verification state is stored as a boolean on a user row rather than as evidence with a timestamp. Nothing can re-run when ownership changes, because nothing models ownership. The result is an onboarding rebuild in the first year, usually under time pressure from a partner bank.

You do not need to build KYB before launch if you are launching consumer-only. You do need a data model that will not fight you when KYB arrives. Four things are worth getting right on day one even if the business flow is a year away:

• A party model that represents both people and entities — one abstraction with a type, not a users table and, later, a bolted-on companies table.
• Relationships as first-class edges between parties, each carrying a type (owner, director, authorized signatory) and, where relevant, a percentage. Ownership chains are graph queries; they are miserable to retrofit onto foreign keys.
• Verification stored as time-stamped evidence events against a party — what was checked, by which provider, against which source, with what result, and when. Auditors and partner banks ask for the trail, not the current status.
• A re-verification trigger. Both KYC and KYB are ongoing obligations, not one-time gates. If your model cannot express "this evidence expires" or "this party's status changed," periodic review becomes a spreadsheet exercise.

Five decisions to settle before you write onboarding code

These are policy and product decisions, not engineering ones, and they are the reason this work belongs in strategy rather than in a vendor evaluation spreadsheet. Every one of them is cheap to decide now and expensive to reverse after launch.

1. Which customers you will refuse. Risk appetite comes first — a written list of jurisdictions, industries and ownership structures you will not onboard, agreed before commercial pressure arrives. Teams that skip this step end up making the decision case by case, in a sales meeting, about a customer already in the pipeline. That is the worst possible time and the worst possible room.

2. Where verification sits in the journey. Verifying everything up front is the safest and most costly option in abandonment terms. Progressive verification — open a limited account, then verify further at a value or activity threshold — usually converts far better, but only if your product genuinely has a low-risk starting state and your regulator or partner bank accepts the staging. This is a joint product-and-compliance decision, and it is the single biggest lever you have over how many applicants you lose.

3. How much manual review you can actually staff. Work backwards from headcount. If one reviewer handles a realistic number of cases per day and you expect a given share of applications to fall out of automation, the arithmetic tells you your true onboarding capacity — and often that the answer is to narrow the launch market rather than to hire.

4. Data residency and retention. Identity documents and biometric templates are among the most sensitive data you will ever hold, they are subject to retention minimums under AML rules and deletion rights under privacy law at the same time, and where they are stored is frequently constrained by jurisdiction. Deciding this after choosing a vendor means discovering the constraint at contract stage.

5. Vendor, build, or orchestration. Almost nobody should build document forensics or sanctions screening in-house. Almost everybody underestimates what remains: the case management, the decision policy, the audit trail, the fallbacks when a provider is down or has no coverage in a market. An orchestration layer that lets you route by geography and swap providers without a re-integration is usually the right shape — but it is only worth its complexity if you have already answered the first four questions.

What this costs you at the top of the journey

Every verification step removes some share of applicants, and the ones you lose are not distributed randomly. A determined bad actor will complete a fourteen-field form and upload three documents. A legitimate small-business owner doing this on a phone, in the evening, between other jobs, frequently will not. Friction filters out the people you wanted more efficiently than the people you were trying to stop — which is precisely why the placement decision in point 2 above matters more than the choice of vendor.

The practical response is instrumentation. Most onboarding flows are measured only at the ends: applications started, accounts approved. That tells you that you have a problem and nothing about where it is. Measuring every stage separately — form started, documents submitted, automated check returned, manual review entered, decision issued — is what turns an abandonment number into a fixable one.

The discipline transfers across verticals. In our work with a private university in Istanbul, the qualification journey ran roughly 1.2 million clicks to about 5,000 enquiries to around 2,000 on-campus visits — a multi-stage narrowing where each stage added a real commitment cost for the applicant. The value was not in the totals; it was that each stage was measured on its own, so it was possible to say which step was losing people and act on that rather than on a single blended number. A verification journey has exactly this shape, with higher stakes attached to each drop-off. Designing that measurement in from the start is part of our fintech strategy, product and business model consulting, and it is far easier to build in than to retrofit.

A pre-launch readiness check

Six questions worth being able to answer before a product goes live. The right-hand column is what a genuinely ready answer sounds like — vague answers here are the reliable predictor of a difficult first compliance review.

Frequently asked questions

Do we need KYB if all our business customers are small local companies?

Usually yes, though the work is much lighter. A single-owner local company still needs the entity verified and the owner identified — but there is no ownership chain to walk, the registry is one you can integrate with properly, and most cases clear automatically. The mistake is assuming the same will hold when the first customer with a foreign parent applies, and having built a flow that cannot express that case at all.

Can one vendor cover both KYC and KYB globally?

One vendor can cover both in a set of markets. "Global" in this category almost always means excellent registry coverage in some jurisdictions, thinner data in others, and manual document collection beyond that. Ask for the coverage list by country and by data type, and ask specifically whether ownership data is returned or only entity existence — those are very different products sold under the same label.

Should verification happen before or after a business starts transacting?

Entity verification and screening of the person opening the account should complete before any transacting. Full beneficial-ownership resolution can sometimes be staged against activity or value thresholds, if your regulator or partner bank agrees the staging in advance. Deciding this unilaterally because it improves your numbers is one of the more common ways a fintech fails its first review.

Is this different for crypto and Web3 products?

The obligations are broadly the same and in several respects heavier, with additional expectations around transaction monitoring and counterparty risk. The material difference is that a wallet address is not an identity, so the mapping between verified party and on-chain activity has to be an explicit part of the design rather than an assumption. Teams that treat compliance as something to be added after a token launch generally find the retrofit costs more than the original build.

The bottom line

KYC and KYB are not two sizes of the same process. KYC verifies a person; KYB verifies an entity and then hands you an unknown number of people to verify, using data of wildly varying quality. The teams that handle this well are rarely the ones with the best vendor — they are the ones that decided their risk appetite, their verification placement, their review capacity and their data model before writing code, and treated the vendor choice as an implementation detail downstream of those decisions. If you are approaching a launch and are not confident about where your onboarding stands against the six questions above, a structured review of the flow is a cheap way to find out now rather than three weeks before go-live.