KYC vs KYB vs KYT: What Each Check Covers in Stablecoin Payments

KYC (know your customer, the verification of an individual), KYB (know your business, the verification of a company and its owners) and KYT (know your transaction, the monitoring of payments and wallets) are three different checks. KYC and KYB run at onboarding and on refresh. KYT runs on every transaction, because a verified customer can still send a bad payment.

All three are components of an anti-money laundering (AML) program, not substitutes for it. The difference shows up when a payment stops, so this post separates them by coverage, data, failure mode and who runs which. A VASP (virtual asset service provider, the FATF term) is one of the businesses that has to run all three, and the VASP explainer covers who that is, and compliance agents covers automating the screening.

How do KYC, KYB, and KYT differ?

They answer different questions about different objects. KYC and KYB ask "who is this?" and are answered once, then refreshed. KYT asks "is this payment normal for this party?" and is answered again on every movement.

KYC, KYB and KYT side by side.

Lumx runs all three layers behind one API: the customer object carries KYC or KYB with its own statuses and webhooks, and every on-ramp and off-ramp is screened and monitored. Flagged transactions are held and handled with compliance on the usual channel, not through the customer statuses. Sumsub and Chainalysis are the vendors behind the checks.

KYC: the check on a person

KYC verifies that an individual exists, matches the documents they submitted, and does not appear on a sanctions or watchlist. The depth scales with risk: a standard-risk individual can clear an automated review, a higher-risk one gets a human reviewer and more documents.

The US rule that frames it for money services businesses is 31 CFR 1022.210: the program must include policies and controls for "verifying customer identification". The rule sets the duty and leaves the method to the institution.

KYC is the check end users meet first, so its failures are product problems: a blurry document, a name that differs between the ID and the form, or an outdated proof of address.

On Lumx, KYC runs through Sumsub. An individual submits identity data, an identity document, a liveness check and proof of address, and the customer moves through NOT_STARTED, UNDER_VERIFICATION and APPROVED, with an RFI (request for information, a hold that asks for a document before the review can continue) for a fixable problem and FINAL_REJECTION for a permanent one. The docs set the KYC Standard target at one business day. A platform whose users already verified on its own Sumsub account can reuse that verification for individuals through a share token, which saves the document upload and the liveness check but not the questionnaire.

KYB: the check on a structure

KYB verifies a company and then the people behind it. The company side is a registry exercise: legal name, tax ID, formation date, address, what it does. The hard part is ownership, because a company owned by a company owned by a fund has to be walked upward until natural persons appear, and each of them is then verified like a KYC individual.

31 CFR 1010.230(d) defines the beneficial owner of a legal entity customer in two prongs. The first is each individual who owns 25 percent or more of the equity interests, directly or indirectly. The second is a single individual with significant responsibility to control, manage or direct the company, such as an executive officer. A company with no 25 percent owner still has to name the second person. The collection is covered in what KYB is and the flow in designing a KYB onboarding flow.

On Lumx, a business customer submits company data, formation documents, regulated-activity information and proof of address, and the representative, the beneficial owners and shareholders above 25 percent each submit an identity document and proof of address as associated parties. A shareholder can sit under another shareholder, so a multi-level structure is expressed as it is. Lumx targets one business day for KYB, effective November 2026. Customers in a high-risk country tier or in a high-risk activity go through Enhanced Due Diligence, which adds a deeper review and ongoing monitoring.

KYT: the check on the money

KYT is the continuous review of payments and counterparties for patterns that do not fit the customer's profile. In a stablecoin flow it also covers wallet addresses, because the counterparty is often an address with a history and no verified owner behind it.

KYT is industry shorthand, and the two primary sources read for this post do not use the term. What they require is the substance. The US rule above makes a written, risk-based AML program mandatory. OFAC's Sanctions Compliance Guidance for the Virtual Currency Industry (October 2021) says a program should generally include sanctions list and geographic screening, and that companies may consider blockchain analytics tools, including a lookback for addresses that share a wallet with a listed one. OFAC FAQ 562, released March 19, 2018, says its digital currency address listings are "not likely to be exhaustive". That sentence is the reason a list lookup is not a KYT program.

Ongoing monitoring in practice means a re-check triggered by an event, not only a calendar date: a change of ownership, a new country or activity, an expired document or a sanctions list update.

KYT catches what onboarding cannot: a verified customer who starts receiving funds from a compromised wallet, or a business declared as software whose payouts now look like remittances.

On Lumx, every on-ramp and off-ramp carries a required purpose code and is screened before it executes, in both directions. Chainalysis KYT covers the blockchain side only, for every kind of wallet, including funds received from an external address. The fiat legs are monitored with Lumx's own systems under the oversight of the banking partners, and the rules are internal compliance policy. A flagged transaction is held for review. Compliance reviews the hold and, if it is not a false positive, contacts the customer on the usual channel for the relationship between sender and receiver, the purpose and the expected outcome. The 24-hour window to answer applies to every transaction, and without an answer the transaction may be refunded to the sender.

Where the Travel Rule sits between them

The Travel Rule is neither a fourth check nor a variant of KYT. It moves the identity data that KYC and KYB produced along with the transfer. FATF applies its Recommendation 16, the wire transfer rule, to transfers of virtual assets (revised in June 2025): the sending and receiving institutions obtain and hold originator and beneficiary information and pass it on. The thresholds and data fields are set country by country.

So the order is: KYC or KYB creates the verified identity, the Travel Rule carries it with the transfer, and KYT checks the transfer itself. The rule in its US wording and the country-by-country variation are in guidelines for the Travel Rule, and the AML context around it is in the AML guide for stablecoin fintechs.

Lumx says its flows are aligned with the Travel Rule. It screens every transaction before it runs, in both directions, and requires a purpose code on each one, which is the field banking partners and correspondent banks use for their own screening and reporting. Blockchain destination addresses are planned to become destinations in the API, like fiat destination accounts, with no date yet.

Who runs which check when you integrate a provider?

Responsibility follows the license and the relationship, not the label on the check. A provider that verifies your customers adds a layer; it does not remove the obligations your own license or bank partner puts on you.

An illustrative split between a platform and a payments provider, by obligation. It is a starting frame, not a rule: your license and bank partner decide the real one.

The last row is the one platforms miss. A provider can only screen what it can see, so every party in a flow has to be a verified customer, which is why Lumx's nested payments rule prohibits pooling funds for undisclosed third parties.

I recommend that a platform name one person, with a deputy, as the owner of every request for information before it goes live, and write that name next to the 24-hour window for answering a flagged transaction in its runbook. The three checks fail in different places. A KYC or KYB problem shows up as a customer who is stuck. A KYT hold shows up as a payment that has stopped, and it has a clock on it. I would also not build a second monitoring layer on top of the provider's unless the platform's own license requires one, because two layers produce two answers about the same payment and nobody on the support team can say which one is right.

On Lumx, each customer a platform creates is onboarded as its own customer, then verified and monitored, and the platform collects the data through the API. Lumx's nested payments rule applies the same logic: every transaction ties to an onboarded customer acting on their own behalf, and a marketplace onboards each seller as a customer instead of pooling buyer funds in one account. Which countries can be onboarded, and which sit in the high-risk or restricted tiers, is on the supported countries page.

When the three-way split is the wrong frame

When the real question is the program, not the check. A written AML program, a named compliance owner and a record-keeping routine sit above the three, and buying a provider does not write the program for you.

When a team uses KYT to mean a sanctions list lookup. A list match is one input, and OFAC says its address listings are not exhaustive.

When the business is a VASP itself. It carries its own duties on top of the provider's checks.

What the three checks look like on Lumx

Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.

On the global payments API, the checks show up as states a platform can read and events it can subscribe to. A customer in RFI triggers a customer.rfi webhook whose payload names the documents and the reason, so the platform can tell its user what to fix. Named virtual accounts wait in AWAITING_ONBOARDING until the customer is approved and can move to RFI when compliance needs more to provision them. Flagged transactions are handled on the compliance channel above, not through these states. How a payout destination is classed as the payer's own or someone else's is in first-party and third-party payouts.

Methodology and sources

Every norm and page below was read on November 1, 2026.

• 31 CFR 1022.210, anti-money laundering programs for money services businesses, paragraph (d)(1)(i)(A), as served by Cornell LII and confirmed against the eCFR text.

• 31 CFR 1010.230, paragraph (d), beneficial owner of a legal entity customer.

• OFAC FAQ 562, on digital currency addresses on the SDN List, released March 19, 2018.

• OFAC, Sanctions Compliance Guidance for the Virtual Currency Industry (October 2021), read in full as a PDF.

• FATF Recommendation 16, revised in June 2025, linked to the official FATF page, which answered a bot wall here, so its date comes from a Japanese FSA page.

• Lumx identity verification, request for information, KYC reuse, nested payments and prohibited activities, for what Lumx collects, how states change and what is held.

Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.

Cover photo: Michael Crededio on Unsplash.