What's the Difference Between KYC and KYB?

August 18, 2026 ·Mairi Kutberg ·

kyckybknow-your-customerknow-your-businessubobeneficial-ownershipamlreidasglobal-digital-identityidentity-verification

KYC (Know Your Customer) verifies a natural person — a specific human being with a name, a face, and a government-issued identity document. KYB (Know Your Business) verifies a legal entity — a company with a registration number, registered representatives, and ultimate beneficial owners. Every KYB verification eventually decomposes into KYC verifications of the natural persons behind the company. KYB is not a separate discipline from KYC — it is KYC applied recursively up the corporate ownership chain until every leaf is a verified human.

What's the Difference Between KYC and KYB?

A Vienna-based fintech's compliance lead sent us an onboarding-architecture question at a recent conversation, after their internal audit had surfaced a pattern: the platform's corporate-customer onboarding was three-times slower than its retail onboarding, generated four-times as many exception reviews, and — despite that — was still returning higher post-onboarding fraud rates than the retail flow. Their initial hypothesis was that the KYB tooling itself was insufficient. When we walked the architecture the actual pattern was different: the KYB process had been designed as a category-of-one problem separate from KYC, when in practice the failing step was always at the natural-person-verification end of the KYB chain — the ultimate beneficial owners the company was ultimately responsible for identifying. This post is that decomposition, walked through in the shape a compliance officer, onboarding-flow architect, or AMLR-implementation lead needs.

What is KYC, and what is KYB — and where does the boundary sit?

The two terms are often presented as parallel disciplines. In practice, one contains the other.

KYC (Know Your Customer) is the process of verifying a natural person's identity to a defined assurance level. The regulatory basis under AMLR Regulation (EU) 2024/1624 — applying from July 2027 — is Customer Due Diligence (CDD): the obliged entity must identify the customer, verify that identity from reliable and independent sources, and record the evidence. The NIST SP 800-63-4 Identity Assurance Level framework defines the technical bar: IAL1 (self-asserted, no verification), IAL2 (remote-verified against government documents), IAL3 (in-person or supervised remote). Most commercial KYC deployments in 2026 target IAL2 with chip-anchored proofing under ICAO Doc 9303 plus biometric face-match, walked in Do Digital Signatures Require Proof of Identity?.

KYB (Know Your Business) is the process of verifying a legal entity's identity — a company, a partnership, a trust, or any other juridical person that can be a party to a contract. The regulatory basis under AMLR Article 20 and following requires the obliged entity to verify the corporate registration (typically through a national business register), identify the persons authorised to represent the entity (directors, board members, signatories), and identify the ultimate beneficial owners (UBOs) — the natural persons who, directly or indirectly, own or control more than 25% of the entity, or otherwise exercise decisive control.

Where the two boundaries actually connect is at every UBO leaf and every registered representative. A KYB verification is not complete when the corporate registration has been retrieved; it is complete when every natural person the corporate registration ultimately points to has been individually KYC-verified. In a simple entity structure (one director who is also the sole shareholder), KYB collapses to one KYC. In a complex holding structure (a Cayman parent owning an Estonian operating company owning a UK subsidiary, controlled by a family trust with three trustees), KYB unwinds into multiple KYCs and multiple sub-KYBs at each corporate layer before reaching the natural-person leaves.

The way I typically frame this in a first conversation with compliance: KYB is not a separate discipline. It is KYC applied recursively — walk the ownership chain from the entity down to the natural persons, and every natural person in that walk gets the same KYC treatment as a retail customer would. The organisations that treat KYB as a paper-verification exercise separate from the natural-person KYC step are the ones whose onboarding leaks the most fraud.

When does a deployment need KYB in addition to KYC?

Any obliged entity that onboards corporate customers, corporate counterparties, or corporate contract signers has a KYB obligation under one or more frameworks. The specific triggers cluster in three broad categories.

Regulated financial services and fintech. AMLR Article 20 requires CDD on every business relationship. AMLD5, the Wire Transfer Regulation (EU) 2015/847, and MiCA all extend KYB obligations to payment institutions, e-money issuers, crypto-asset service providers, and virtual-asset platforms. The US equivalent — the FinCEN Customer Due Diligence Rule (31 CFR 1010.230) — imposes the same UBO-identification requirement on covered financial institutions.

Cross-border commercial contracting. A Rotterdam-based freight platform contracting with a foreign carrier has to satisfy itself that the counterparty is a real legal entity, is authorised to enter the contract, and is not on any relevant sanctions list. The KYB obligation here is contractual and audit-driven rather than direct regulatory, but the operational architecture is the same. The connection between corporate-identity verification and evidentiary weight in dispute is walked in What Happens if Someone Denies They Signed Digitally?.

Regulated non-financial sectors. NIS2 supply-chain security obligations, CRA product-supply obligations, sanctions-screening obligations under EU regulations, and sector-specific licensing regimes (healthcare, iGaming, defence) all impose corporate-identity verification requirements that a KYC-only architecture cannot satisfy. The jurisdictional variance in KYB obligations by country is walked in Digital Signature Laws by Country: What's Legal Where? — the same three-pattern framework applies to KYB regulatory obligations as to signature law.

Where I disagree with the loud vendor pitch on KYB tooling is the assumption that pulling data from a corporate registry constitutes a KYB verification. It does not. The registry pull is the first step — it establishes what the corporate registration says. The verification is the walk-back to the natural persons behind that registration. A vendor that stops at "we pulled the OpenCorporates data" is not performing KYB in the AMLR sense; they are performing corporate-registry lookup, which is a component of KYB but not the whole thing.

How does the ultimate-beneficial-ownership walk-back actually work?

Under AMLR Article 63 and following, an obliged entity must identify every natural person who ultimately owns or controls more than 25% of the corporate customer — either directly (holding the shares themselves) or indirectly (through one or more intermediate corporate layers). The walk-back has to reach every such person and produce a verifiable identity record for each.

The mechanics run as follows.

Step 1 — retrieve the corporate registration. From a national business register (Estonia's e-Business Register, the UK Companies House, the EU Business Registers Interconnection System (BRIS), or their equivalents). This produces: registration number, registered address, list of directors, share capital structure, and — in EU jurisdictions post-AMLD5 — the beneficial ownership register entry.

Step 2 — verify the registered representatives. Every director or authorised signatory listed in the registration must be KYC-verified as a natural person before they can act on behalf of the entity. This is where the KYB obligation reduces to a KYC list, one per representative.

Step 3 — walk the ownership chain. For each shareholder holding >25%, determine whether the shareholder is a natural person (leaf — KYC required) or another legal entity (branch — recursive KYB required on that entity, walking its ownership until natural-person leaves are found).

Step 4 — verify each natural-person UBO. Each leaf must be KYC-verified with the same chip-anchored + biometric assurance as a retail customer. This is the step where most KYB architectures fail — the corporate-registry walk-back is technically clean, but the natural-person verification at the leaves is bounded by whatever the platform's KYC infrastructure supports. If the KYC layer only handles domestic customers, the KYB obligation cannot be satisfied for foreign UBOs.

Step 5 — retain the evidence. All of the above becomes part of the audit-defensible customer file. Under AMLR Article 77, the retention period is at least 5 years after the end of the business relationship, extending to 10 years where national law requires. The evidence architecture that makes this retention defensible — LTV embedding, qualified timestamps, chip-anchored identity records — is walked in What Happens if Someone Denies They Signed Digitally?.

A Berlin AML compliance officer at a cross-border payment platform I reviewed onboarding architecture with last quarter had exactly the failure mode this walk-back is designed to prevent: the KYB tooling could handle the corporate-registry step efficiently for EU entities and for a handful of favourably-covered third countries, but broke down at Step 4 whenever a UBO turned out to be resident in a country the platform's KYC infrastructure did not support. The team had been logging these as "manual review pending" and processing them through a spreadsheet-based fallback workflow — until the internal audit surfaced the pattern and treated the manual-workflow entries as CDD failures. The remediation was not a better KYB registry tool; it was a KYC infrastructure that could verify natural-person UBOs from any country the ownership chain led to.

The way I usually explain this to onboarding-architecture teams: the KYB registry step is the cheap part. The natural-person KYC step at each UBO leaf is the expensive part, and it is the part that determines whether the whole KYB walk-back is actually complete. Optimising the registry tooling without upgrading the underlying KYC infrastructure produces faster corporate-registration pulls that still fail AMLR compliance at the UBO step.

What should a compliance officer check in a KYC + KYB architecture?

Six questions to put to any KYC + KYB architecture before signing off. The vendor's answers will usually surface architectural gaps that the marketing document does not.

Is the underlying KYC infrastructure IAL2-capable across every country in your customer base? If your onboarding might touch UBOs in 60 jurisdictions, your KYC layer needs to reach all 60. Chip-anchored ICAO 9303 passport-NFC covers 179 countries; document-plus-face-match handles the rest. If the KYC layer only reaches EU or "supported countries", the KYB walk-back has a systemic gap.
Does the KYB flow explicitly enumerate every UBO above the 25% threshold, or does it stop at the corporate-registry pull? AMLR compliance requires the enumeration, not just the registry data.
Is every representative signature bound to a KYC-verified natural person? A corporate signature under AMLR is legally the natural-person director's signature acting for the entity — the AdES chain has to walk back to that verified person, not just to a corporate email account or shared credential.
What happens when a UBO's identity cannot be verified? Real ownership chains produce edge cases — deceased shareholders, minors, trusts with named beneficiaries but no living trustee list. The compliance escalation path for these needs to be architected, not left as an unhandled exception.
Is the UBO evidence retention independently verifiable years later? Under AMLR Article 77, 5-10 year retention on every UBO KYC record. LTV embedding + qualified timestamps + chip-anchored identity evidence embedded per record — the same architecture that defends signatures in a dispute.
Does the KYB flow handle re-verification when ownership changes? Corporate structures change. A UBO who owned 30% at onboarding may drop to 20% (below threshold) or new UBOs may appear. The re-verification cadence and trigger events need to be specified, not left as an implicit ongoing obligation.

My take on this: most KYB deployments I have reviewed have solved the registry-pull problem and left the natural-person-KYC step as the implicit remainder. That produces an architecture that looks compliant at the tooling layer and fails at the AMLR-compliance layer whenever a real audit walks the ownership chain to a UBO the platform cannot verify. The KYB pitch says "corporate identity verification"; the AMLR obligation says "every natural person behind the corporation." Those are not the same thing.

Where IdentiGate fits

IdentiGate provides the natural-person KYC layer that anchors every leaf of the KYB walk-back — chip-anchored ICAO 9303 passport-NFC + biometric face-match covering 179 countries, plus document + face-match for every remaining jurisdiction. Our company identity product handles the KYB registry-pull step across EU (BRIS-connected) + national registries + international corporate-registry sources, and — critically — federates the two so that each KYB verification produces an audit-complete record of both the entity data and every natural-person UBO KYC leaf under it. Our authentication layer handles the ongoing re-verification cadence when ownership changes, and our evidence layer keeps the whole KYC + KYB record independently verifiable across AMLR Article 77's 5-to-10 year retention obligations.

If your onboarding architecture treats KYB as a registry-pull exercise rather than as a recursive KYC problem, and an AMLR-implementation deadline (July 2027) is on your compliance calendar, get in touch.

Sources

Legal + regulatory frameworks

Corporate registries + BRIS

Identity + assurance standards

Signature + evidence infrastructure

About the author

Mairi Kutberg is a co-founder of IdentiGate, a European identity-verification and digital-signature company building on top of chip-anchored identity-proofing (ICAO 9303 passport NFC), Advanced Electronic Signatures (eIDAS Article 26), Advanced Electronic Seals, and cross-border corporate-identity verification (KYB). She works with fintech, healthcare, logistics, HR-tech, iGaming, and cybersecurity teams whose customer or counterparty onboarding has to satisfy AMLR + national CDD + sector-specific KYB obligations without breaking against foreign UBOs the domestic KYC infrastructure cannot reach.

The words we use in digital identity are load-bearing. Use the wrong one and the listener walks confidently down the wrong road — and in identity, security, and compliance, most of our everyday words send people the wrong way. This is the eleven-point vocabulary repair kit for anyone building identity infrastructure: data vs information, trust vs proof, authentication vs identity, permission vs authority, compliance vs evidence, disclosure vs predicate. If our language keeps reaching for words that can't be measured, are we building resilience — or performing security?

You verify the passport chip — remotely, in ninety seconds, with cryptographic evidence signed by the state that issued the document. The engineering answer for a remote-hire identity check without an in-person meeting is chip-anchored NFC read plus biometric face-match against the chip photo, wrapped in an AdES record retained under a Long-Term Validity envelope. This post walks the pattern for full-time employment remote hires (distinct from gig workers and contractor-of-record engagements), the four questions the pattern actually answers, and where the picture is genuinely harder than the identity layer alone.

Multi-party document signing takes one of two shapes — sequential (party A signs, then B, then C, each signature depending on the previous one) or parallel (all parties sign the same document independently, with an aggregator collecting and combining the signatures). Both are supported cleanly by the eIDAS AdES formats (PAdES, XAdES, CAdES) but the cryptographic semantics, the timestamp coordination, and the LTV envelope requirements differ meaningfully between them. This post walks the two patterns, when to use each, and what tends to break when the pattern is chosen wrong for the workflow.