KYC / KYB (Know Your Customer / Know Your Business)

Two checks, two different subjects

The EU sets out customer due diligence in four limbs: "identifying the customer and verifying the customer's identity on the basis of documents, data or information obtained from a reliable and independent source," identifying the beneficial owner and taking reasonable measures to verify that person's identity "including, as regards legal persons, trusts, companies, foundations and similar legal arrangements, taking reasonable measures to understand the ownership and control structure of the customer," assessing the purpose and intended nature of the relationship, and conducting ongoing monitoring.² The first limb is KYC. The second is what the market calls KYB.

The US rule puts a number on it. FinCEN's Customer Due Diligence Rule requires covered financial institutions to "identify and verify the identity of any individual who owns 25 percent or more of a legal entity, and an individual who controls the legal entity."¹ Two prongs, ownership and control, and the control prong catches the operator who holds no equity at all. A cap table alone will not satisfy it. That second prong is where onboarding cost and applicant drop-off actually live, so it belongs in the business model rather than in a compliance appendix.

Verification happens before the relationship, not after

Timing is a compliance requirement rather than a workflow preference. EU law requires that "verification of the identity of the customer and the beneficial owner take place before the establishment of a business relationship or the carrying out of the transaction."² Where an obliged entity cannot complete the checks, it "shall not carry out a transaction... establish a business relationship," and must terminate the relationship and consider filing a suspicious transaction report.²

That last clause is the one product teams miss. A failed check is not a neutral outcome you retry later. It is an event that can generate a reporting obligation, which means the onboarding flow needs an exit path that a compliance function owns, not a silent error state that a growth team A/B tests.

Where the obligation attaches in a token issuance

The obligation sits on regulated entities, not on smart contracts, and the EU widened which entities count. Regulation (EU) 2023/1113 amended the anti-money-laundering directive to insert crypto-asset service providers into the obliged-entity list.³ Its recitals explain why: before that change the directive reached only "custodial wallet providers and providers engaged in exchange services between virtual currencies and fiat currencies."³ Since the amendment, every category of service provider defined under MiCA carries obliged-entity status.

For an issuer, that reframes the question from whether to run checks to where in the stack they bite. If a regulated service provider is the customer's counterparty at mint, at redemption or at trade, that provider owes the duty and will push its requirements upstream into your issuance flow. MiCA reinforces it from the other direction: failing to have effective anti-money-laundering systems is a ground for withdrawing a service provider's authorisation.

So the design decision is placement. Gate-level enforcement runs checks only at mint and redemption through the issuer interface, which keeps the token freely transferable in between. Transfer-level enforcement makes the contract validate sender and receiver on every transfer, which is cleaner as compliance and confines the token to permissioned venues. Both are defensible. Choosing one after deployment means a contract migration.

Sanctions screening is a separate check with a harder failure mode

Identity verification and sanctions screening are not the same control, and passing one says nothing about the other. OFAC's guidance is that persons including technology companies and "administrators, exchangers, and users of digital currencies" should run "a tailored, risk-based compliance program, which generally should include sanctions list screening and other appropriate measures."⁴

Two mechanics make this harder than a name match. The 50 Percent Rule blocks entities "owned by a person on the SDN List (defined as a direct or indirect ownership interest of 50 percent or more)... regardless of whether that entity is separately named," so screening a counterparty name against the list is not sufficient without the ownership chain behind it.⁴ And OFAC "may include as identifiers on the SDN List specific digital currency addresses associated with blocked persons," which puts wallet addresses inside the screening perimeter alongside names.⁴

Sanctions exposure is also strict in a way that anti-money-laundering exposure is not. A KYC gap is a program deficiency. A sanctions hit is a blocked-property event with reporting duties attached, and the ownership arithmetic behind it is not something an identity vendor's pass or fail flag will surface for you.

Risk-based does not mean optional

The risk-based approach is often read as permission to do less. What EU law actually says is that obliged entities "may determine the extent of such measures on a risk-sensitive basis."² Extent, not existence. The measures happen; how deep they go varies with assessed risk, and the assessment itself has to be documented well enough to defend later.

In practice that means a written risk methodology before an onboarding flow is built, not after a supervisor asks. Which customer types, jurisdictions, products and delivery channels are higher risk, what enhanced measures each triggers, and who signs off on an exception. Retrofitting that reasoning onto decisions already made is the most expensive version of this work we see.

What to settle before you build the flow

Four decisions. Whether your customers are natural persons, entities or both, since KYB carries the beneficial-ownership work that dominates cost and drop-off. Where checks attach in the token lifecycle, gate-level or transfer-level, decided against the venues you need to reach. How sanctions screening runs as a separate control, covering wallet addresses and ownership chains rather than names alone. And who owns the exit path when a check fails, given the reporting duties that can follow.

One caution. Which anti-money-laundering rules apply to a specific entity, in a specific jurisdiction, for a specific product is fact-specific and belongs to your counsel and compliance function. Requirements differ materially between the EU, the US and other regimes, and they have moved more than once in the last three years. This page is reference material for design work. It is not legal advice, and it is not a recommendation to buy, sell or hold any asset.