---
title: "Stablecoin payout compliance: KYC, KYB, sanctions screening and the Travel Rule (2026)"
seoTitle: "Stablecoin payout compliance: KYC, KYB, Travel Rule"
description: "Responsibility matrix, pre-launch checklist and data template for stablecoin payout compliance: who owns KYC, KYB, screening and the Travel Rule."
date: "2026-10-21"
updated: "2026-10-21"
category: "compliance"
author: "BlindPay Team"
faq:
  - q: "Is KYC required for every payout?"
    a: "On BlindPay, every payment flows through a customer that has completed KYC, so the sender or receiving customer must be verified before a payout runs. Individuals use KYC Standard or Enhanced and businesses use KYB Standard. Rules differ by country and rail, and counsel should confirm what your program needs. This is general information, not legal advice."
  - q: "What is the Travel Rule?"
    a: "The Travel Rule applies FATF Recommendation 16, a wire transfer rule, to virtual asset transfers. The sending provider must collect and pass on originator and beneficiary information, such as names and account or wallet addresses, to the receiving provider. Thresholds and extra fields differ by country, so check the rule that applies to each corridor you serve."
  - q: "Who is responsible for sanctions screening?"
    a: "Responsibility is shared. BlindPay includes sanctions screening in its payout and payin API, but your business still owns its own compliance program, its customer risk decisions and the accuracy of the data it submits. Keep your own records of what you collected and when, since a regulator can ask you directly."
  - q: "Does a non-custodial model change my obligations?"
    a: "Not automatically. Non-custodial describes who controls funds, not whether a business has AML, sanctions or licensing duties. Depending on your flow and jurisdiction you may still owe customer due diligence, screening and reporting. Ask counsel how your specific payout flow is treated in each country where you operate."
  - q: "What happens when a compliance check fails?"
    a: "A rejected customer cannot transact, and BlindPay recommends creating a new customer with corrected data rather than editing a rejected one. A payout flagged for review goes on_hold, and BlindPay may send a request for information. Holds can last up to 30 days, and a timeout without a decision fails the payout. A failed payout is not refunded automatically, so contact support."
  - q: "How long does onboarding verification take?"
    a: "On BlindPay production instances, KYC Standard is typically automated in about 60 seconds. KYC Enhanced for high-risk countries and KYB Standard for businesses need manual review, usually 3 hours to 1 business day. Development instances auto-approve customers, so test the rejected and review paths deliberately rather than assuming production will feel the same."
---

A compliant stablecoin payout verifies the customer (KYC for people, KYB for businesses), screens against sanctions lists, and passes originator and beneficiary information under the Travel Rule. BlindPay includes these checks in its payout and pay-in API: your platform collects the data and BlindPay verifies it. You still own your program and your records.

This guide gives you the practical pieces as of October 2026: a responsibility matrix, a pre-launch checklist and a data-collection template. For the product, see [what a stablecoin payouts API is](/resources/more/what-is-a-stablecoin-payouts-api). It builds on pages that explain each control in depth, and it does not repeat them.

**Key takeaways**

- Every BlindPay payment flows through a customer that has completed KYC. The API user collects the data, and BlindPay verifies it.
- KYB, sanctions screening and Travel Rule compliance are part of the payout and pay-in API.
- Responsibility is shared. Your business owns its program, its risk decisions and the accuracy of submitted data.
- KYC Standard takes about 60 seconds when automated. KYC Enhanced and KYB Standard take 3 hours to 1 business day.
- Data needs vary by recipient type and corridor, so check current requirements before each launch.

## What does each control do?

KYC and KYB prove who a party is. Sanctions screening checks that party against restricted lists. The Travel Rule moves identity data with the transfer. Three controls, three different questions.

| Control | Question it answers | Applies to |
| --- | --- | --- |
| KYC | Who is this person? | Individual customers |
| KYB | Who is this business and who owns it? | Business customers and their owners |
| Sanctions screening | Is this party or wallet on a restricted list? | Customers, recipients, wallet addresses |
| Travel Rule | Does originator and beneficiary data travel with the transfer? | Transfers above the local threshold |

The deeper explanations already exist: [KYC vs KYB vs KYT](/resources/more/kyc-vs-kyb-vs-kyt), [the Travel Rule for stablecoin off-ramps](/resources/more/travel-rule-stablecoin-off-ramps), [how wallet screening works](/resources/more/how-wallet-screening-works-stablecoin-payments) and [how often to rescreen](/resources/more/ongoing-sanctions-screening-how-often-to-rescreen). Read them for the mechanics. This page is about assigning work and shipping.

## What does FATF Recommendation 16 require?

It requires the sending provider to obtain and pass on originator and beneficiary information with a transfer. FATF applies this wire transfer rule to virtual asset transfers, and the data set grows above a threshold.

FATF's [updated guidance on virtual assets](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets-2021.html) (October 2021) explains how virtual asset service providers should obtain, hold and transmit this information, with a de minimis threshold of USD/EUR 1,000 available to countries. FATF's [June 2025 update on Recommendation 16](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/update-Recommendation-16-payment-transparency-june-2025.html) covers payment transparency more broadly. The common data fields:

| Data | Below the threshold | At or above the threshold |
| --- | --- | --- |
| Originator name | Yes | Yes |
| Originator account or wallet address | Yes | Yes |
| Originator address, national ID number, customer ID, or date and place of birth | No | Yes |
| Beneficiary name | Yes | Yes |
| Beneficiary account or wallet address | Yes | Yes |

Each country sets its own threshold and fields, so treat this table as the FATF baseline, not a local rule. FATF's [seventh targeted update on virtual assets](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/targeted-updated-virtualassets-vasps-2026.html) (July 2026) found that 91 of 109 surveyed jurisdictions had passed Travel Rule legislation, but only 40 percent of them had taken supervisory or enforcement action. A counterparty's country being "covered" tells you less than it seems.

## Who does what? A responsibility matrix

Three parties share the work: your business (the platform), BlindPay (the provider) and the recipient. The matrix shows the default split for a BlindPay payout flow.

| Task | Your business | BlindPay | Recipient |
| --- | --- | --- | --- |
| Collect customer KYC or KYB data and documents | Owns | Provides the API and field requirements | Supplies the information |
| Verify identity and business ownership | Reviews outcome, acts on status | Verifies (automated or manual) | Responds to requests |
| Choose customer risk appetite and onboarding rules | Owns | Applies its own program and country restrictions | None |
| Sanctions screening in the payment flow | Keeps your own program and records | Included in the payout and pay-in API | None |
| Travel Rule data on the transfer | Submits accurate originator and beneficiary data | Included in the API flow | Beneficiary details must be correct |
| Beneficiary bank account details | Collects and submits | Validates required fields per rail | Confirms accuracy |
| Answer requests for information on a hold | Responds within the window | Reviews and decides | Provides documents through you |
| Ongoing monitoring and reporting duties of your own | Owns | Monitors transactions on its platform | None |
| Record keeping | Keeps your own copy | Keeps its own records | None |

Two rules of thumb. First, the provider's checks do not replace your program, because your regulator will ask you. Second, collecting data is your job even where verifying it is the provider's. [Who owns what in on-ramp compliance](/resources/more/crypto-on-ramp-compliance-who-owns-what) shows the same split in another flow.

## What should the pre-launch compliance checklist cover?

Twelve items, in order. Do them before you send a real payout, not after the first hold.

1. **Define your customer types.** List which recipients are individuals and which are businesses, and in which countries.
2. **Confirm country eligibility.** Check the [supported countries](/docs/kb/supported-countries) list and prohibited activities. Customers from high-risk countries always need Enhanced KYC.
3. **Map data collection.** Use the template below for each recipient type and corridor.
4. **Build document upload.** Use the upload endpoint, and the document analysis endpoint to catch poor files early.
5. **Handle every KYC status.** Plan for `verifying`, `approved`, `rejected`, `pending_review` and `compliance_request`.
6. **Subscribe to `customer.update` webhooks.** Do not poll for verification results.
7. **Decide your rejection path.** BlindPay recommends creating a new customer with corrected fields instead of editing a rejected one.
8. **Prepare for holds.** Payouts can land `on_hold` for review. Decide who answers a request for information and how fast.
9. **Write your recipient-relationship rules.** Third-party bank accounts are allowed, and `recipient_relationship` changes what documents SWIFT payouts need.
10. **Set up records.** Keep what you collected, when, and the status history.
11. **Test the failure paths on a development instance.** Customers auto-approve there, and setting the first name or legal name to `Fail` forces a rejection.
12. **Get written sign-off.** Have counsel or your compliance officer approve the program for each corridor.

## What data do you collect per recipient type? A template

Collect these fields at onboarding. The list is a starting point from BlindPay's [KYC requirements](/docs/kb/kyc), [KYB documents](/docs/kb/kyb-documents) and [bank accounts](/docs/bank-accounts) docs. **Check current requirements per corridor** before you rely on it.

| Recipient type | Customer fields | Documents | Bank account compliance fields |
| --- | --- | --- | --- |
| Individual, standard-risk country (KYC Standard) | First and last name, date of birth, email, country, full address, tax ID | ID document front (type: passport, ID card or driver's license), selfie. Back of ID and proof of address are optional | None on Pix, SPEI, SEPA and similar rails |
| Individual, high-risk country (KYC Enhanced) | Everything above, plus purpose of transactions | Proof of address, source of funds document and file, selfie | As above |
| Business (KYB Standard) | Legal name, tax ID, formation date, email, address, website, at least 1 owner (UBO or controlling person) | Incorporation document, proof of ownership, proof of address. Each owner: ID, selfie, proof of address | As above |
| Recipient on ACH, wire, RTP or SWIFT | Beneficiary name, address, `recipient_relationship` | SWIFT to a third party: documents after the payout is created | NAICS `business_industry` for business accounts. Local `tax_id` and `phone_number` for certain beneficiary countries |

Useful details from the docs: business owners with a US country must also send an SSN or ITIN type matching their tax ID, `tax_id` for US residents is always the SSN, and proof of business address must be dated within 90 days. [The bank accounts docs](/docs/bank-accounts#compliance-fields-for-ach-wire-rtp-and-swift) list the countries that trigger the extra fields.

## What happens when a check fails or a payout is held?

The customer or payout stops, and you get a status and often a request for information. Plan the human side as carefully as the API side.

A rejected customer cannot transact. Triggers for a hold include first-time withdrawals, unusual activity, large amounts relative to history, and screening matches. BlindPay's [on-hold docs](/docs/kb/on-hold-transactions) say compliance reviews each flagged transaction and may send an RFI covering the relationship between sender and customer, the purpose and the expected outcome. Holds can take up to 30 days, and a timeout without a decision fails the transaction. A `failed` payout is not refunded automatically, so contact support@blindpay.com. [Source of funds for off-ramps](/resources/more/source-of-funds-crypto-off-ramps) helps you prepare documents in advance.

## Does non-custodial change your obligations?

Not by itself. BlindPay's payout flow runs from customer-controlled wallets, and non-custodial describes control of funds, not the existence of AML or sanctions duties. US regulators judge wallet cases on facts such as who has total independent control over the value, in FinCEN's [2019 guidance](https://www.fincen.gov/resources/statutes-regulations/guidance/application-fincens-regulations-certain-business-models). OFAC's [sanctions compliance guidance for the virtual currency industry](https://ofac.treasury.gov/media/913571/download?inline) expects risk-based screening of customers and wallet addresses. Ask counsel how your flow is treated in each country.

## Methodology and sources

External sources: [FATF updated guidance on virtual assets (2021)](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets-2021.html), [FATF Recommendation 16 update (June 2025)](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/update-Recommendation-16-payment-transparency-june-2025.html), [FATF seventh targeted update on virtual assets (July 2026)](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/targeted-updated-virtualassets-vasps-2026.html), [FinCEN FIN-2019-G001](https://www.fincen.gov/resources/statutes-regulations/guidance/application-fincens-regulations-certain-business-models) and [OFAC virtual currency guidance](https://ofac.treasury.gov/media/913571/download?inline). BlindPay facts come from the [KYC](/docs/kb/kyc), [KYB documents](/docs/kb/kyb-documents), [bank accounts](/docs/bank-accounts), [cut-off times](/docs/kb/cut-off-times) and [on-hold transactions](/docs/kb/on-hold-transactions) docs, checked in October 2026. BlindPay publishes this article.

## What to do next

See compliance in the API flow: create a customer on a free development instance, force a rejection with a name of `Fail`, and watch the `customer.update` webhook. Then map your own recipient types to the template above. For cost, read [stablecoin payout API pricing](/resources/more/stablecoin-payout-api-pricing).

*This article is general information, not legal advice.*