A compliance map for programs that run stablecoin cards and payouts together: KYC, KYB, monitoring, sanctions, Travel Rule, and records, split by owner.
A program that runs stablecoin cards and stablecoin payouts has two compliance stacks, not one. The card leg follows card network and issuing bank rules. The payout leg follows money transmission, virtual asset, and Travel Rule rules. Each provider owns its leg, and your company owns the gaps between them, plus its own customer risk decisions.
This page is a map, not a checklist for one provider. It shows which duty sits where when a company spends from stablecoin balances on a card and also sends stablecoin-funded payouts to bank accounts. For the card side alone, read stablecoin card issuing compliance. For the basics of the product, start with what stablecoin card issuing is.
This is general information, not legal advice. Confirm your obligations with counsel in each country where you operate.
Key takeaways
It has to cover five control areas across two legs. The card leg covers cardholders and card transactions. The payout leg covers senders, recipients, wallets, and bank transfers.
Some quick definitions first:
The two legs touch at the funding wallet. Stablecoins that sit behind the card balance are the same stablecoins a payout draws on, so a gap in one leg shows up in the other.
Each provider owns the duties for the transactions it executes, and your company owns everything about its own customers that neither provider sees. The table below is the usual split. Contracts can move duties around, so check yours.
| Duty | Issuing bank and program manager | Payout provider | Your company |
|---|---|---|---|
| KYC on individuals | Every cardholder, before the card is issued | Every individual sender it pays out for | Your own users, if you onboard them first |
| KYB on businesses | Companies in a corporate card program | Companies that send payouts | Your business customers and their owners |
| Transaction monitoring | Card authorizations, clearing, disputes | Payout and payin activity, wallet flows | Patterns across both, tied to your customer |
| Sanctions screening | Cardholders, merchants per network rules | Senders, recipients, wallet addresses | Your customer base, on every list update |
| Travel Rule | Not on card authorizations | Transfers above the local threshold | Correct sender and recipient data |
| Record keeping | Card and cardholder records | Transfer, quote, and screening records | A single customer file linking both |
| Reporting suspicious activity | Card activity, to its regulator | Payout activity, to its regulator | Escalating what you see to both |
Read the last column carefully. Your company sits in the middle and is the only party that sees the whole customer.
Each provider runs its own check, and you supply the data both times. A cardholder verified by the issuer is not automatically verified by the payout provider, unless your contracts set up a reliance arrangement.
On the card side, the issuer needs cardholder identification even when the wallet behind the card is permissionless. neobankbeat's explainer puts it plainly: "The wallet may be permissionless; the plastic isn't." Do stablecoin cards require KYC? covers what cardholders are asked for.
On the payout side, the provider verifies whoever is sending money. For a company that means KYB: registration, business activity, ownership, and source of funds. What is KYB lists the usual documents.
The practical step is to collect once and map twice:
Each provider monitors its own leg, and only you can monitor across them. The card program sees spend at merchants. The payout provider sees transfers to bank accounts. A pattern that crosses both, such as a card loaded and then drained by payouts to many new recipients, is visible only in your data.
Useful cross-leg signals to watch:
For the payout side, real-time transaction monitoring for stablecoin payments covers rule design, and transaction monitoring red flags lists patterns worth alerting on.
Screen people, companies, and wallet addresses, and screen again whenever lists change. Card programs screen cardholders by default. Stablecoin flows add a second target: the wallet address.
OFAC's 2021 sanctions guidance for the virtual currency industry describes a risk-based program for companies in this space. In a combined program, that means:
How wallet screening works explains the address side, and how often to rescreen covers ongoing screening.
The Travel Rule applies when funds or virtual assets move between regulated providers. It does not apply to a card authorization, which runs under card network rules instead.
In the US, the funds transfer recordkeeping and travel rule sits in 31 CFR 1010.410, with a $3,000 threshold. Globally, FATF updated Recommendation 16 on payment transparency in June 2025. In a combined program, the moments that trigger it are:
| Event | Travel Rule in scope? | Who sends the data |
|---|---|---|
| Cardholder pays a merchant | No, card network rules apply | Issuer, under network rules |
| Stablecoins move from an exchange to the card wallet | Often, between regulated providers | The sending provider |
| Payout from stablecoins to a recipient's bank | Yes, above the local threshold | The payout provider, with your data |
| Recipient sends funds back | Depends on the route | The provider that executes it |
The data has to be right before the transfer starts. Wrong or missing originator details are the most common reason a payout gets held. Travel Rule holds, returns, and rejections walks through what happens next.
Keep one customer file that links both legs. Each provider keeps its own records, but an examiner or a bank partner will ask you to reconstruct a customer's full activity, and that is hard when data sits in two dashboards.
At minimum, store:
Retention periods differ by country and record type. Ask counsel for the exact periods in each market.
The regulatory frame on top of these duties changes by market. The card leg is licensed where the card is issued. The stablecoin leg is often regulated where the customer lives. One program can sit under several regimes.
BlindPay runs the payout and collection leg, with KYC, KYB, and sanctions screening built into the same API flow. In the table above, it sits in the payout provider column, next to whichever issuer runs the card program.
From the BlindPay docs, customers are verified through the API before they can send payouts, and businesses go through KYB with documents listed in the KYB documents guide. Payouts run over Pix, SPEI, ACH, RTP, SEPA, and SWIFT (POBO/COBO), with UETR tracking and MT103 confirmations on SWIFT. Each payout starts from a live quote, which gives you a quote ID to store on the customer file next to the card transaction IDs.
BlindPay operates as a non-custodial payment processor for payout flows from customer-controlled wallets: you authorize the exact amount and BlindPay executes that single transaction. That keeps the payout leg separate from the card balance in your records, which is what an examiner wants to see.
Draw your own version of the who-owns-what table before you sign the second contract. Then:
When the payout column is ready to fill in, run a test payout from a free development instance with the payout quickstart, and keep the quote and payout IDs it returns as your first record.
The evidence examiners expect from automated risk monitoring: a 10-item evidence table, good vs poor practice, SAR timelines, RFIs, and a 30-day plan.
Blockchain payments are legal for businesses in the US, EU, UK, Brazil, and Mexico, under different rules. What each country regulates, as of October 2026.
Why a stablecoin card purchase can be a taxable disposal, how the US, UK, Germany, Spain, the Netherlands, and Brazil differ, and which records to keep.