Stablecoin Compliance Stack: Travel Rule, Chain Analysis, Sanctions

Accepting card payments or sending a SWIFT wire requires compliance with financial sanctions and AML regulations that have existed for decades — documented, tooled, and well-understood. Stablecoin operations require all of the same obligations plus a compliance layer that did not exist five years ago: Travel Rule data exchange with counterpart VASPs, wallet-address sanctions screening, and on-chain transaction graph analysis.

These are not theoretical requirements. OFAC has sanctioned specific blockchain addresses. Financial regulators across the EU, UK, US, Singapore, and other jurisdictions have issued VASP licensing requirements that include Travel Rule obligations. Regulated financial institutions sending stablecoin without a compliance stack are not operating in a grey area — they are in clear violation.

This briefing covers the three components of the stablecoin compliance stack, the tools that implement each, and how they interact.

Component 1 — The FATF Travel Rule

The FATF Travel Rule (Recommendation 16, extended to virtual assets in 2019) requires Virtual Asset Service Providers to collect and transmit originator and beneficiary information for virtual asset transfers above a threshold — $1,000 USD/EUR equivalent in most implementing jurisdictions, $3,000 in the US under FinCEN’s interpretation.

The analogy to SWIFT: when a bank sends a wire transfer, it transmits originator and beneficiary information in the payment message. The Travel Rule requires VASPs to do the same for stablecoin and crypto transfers — before or concurrent with the transfer.

IVMS 101: The industry-standard data format for Travel Rule compliance. IVMS 101 (InterVASP Messaging Standard 101) specifies the data fields for originator and beneficiary: name, address, account number, national identification (where available), date and place of birth. The standard is maintained by InterVASP; most Travel Rule solution providers use it.

Travel Rule infrastructure providers:

Notabene: SaaS platform for Travel Rule compliance. Operators use Notabene to discover whether a counterparty address belongs to a known VASP (in the Notabene network), exchange IVMS 101 data with that VASP, and handle unhosted wallet transfers. Strong network coverage in Europe and Asia.

Sumsub Travel: Integrated into Sumsub’s broader KYC/AML platform. Works well for operators already using Sumsub for identity verification — the Travel Rule and KYC data share a common identity record.

TRP (Travel Rule Protocol): An open-source protocol for Travel Rule data exchange, championed by a consortium of VASPs. Technically lower cost; requires more implementation effort than SaaS providers.

Sygna: Strong in Asia-Pacific, particularly Taiwan and Southeast Asia. Built for exchanges and custodians in markets with active VASP licensing regimes.

The unhosted wallet problem: Travel Rule requires VASP-to-VASP data exchange. When a customer sends stablecoin from or to an unhosted wallet (a self-custody wallet not associated with a VASP), there is no counterpart VASP to exchange data with. Most jurisdictions require the VASP to collect identity information on the unhosted wallet owner through direct customer attestation (“this wallet belongs to me”) or by applying enhanced due diligence. The specific requirement varies by country.

Jurisdictional implementation timing: FATF issued the guidance in 2019; country-level implementation has been uneven. EU’s Transfer of Funds Regulation (TFR) extended full Travel Rule to crypto from 2024. Singapore’s MAS applies Travel Rule to all PSPs handling digital payment tokens. The US’s FinCEN has proposed Travel Rule application to crypto; the rule is not yet finalized as of 2026. Check current local implementation status for each jurisdiction you operate in.

Component 2 — Wallet Sanctions Screening

Sanctions screening in traditional payments matches counterparty names and identifiers against OFAC SDN and equivalent lists. In stablecoin operations, name matching is necessary but not sufficient — you must also screen the blockchain addresses themselves.

Why address screening is necessary: OFAC has directly sanctioned specific blockchain addresses associated with:

• Tornado Cash mixer smart contracts (August 2022) — the most significant action, creating compliance requirements for any entity receiving funds that touched Tornado Cash addresses
• Specific wallet addresses associated with Lazarus Group (DPRK state-sponsored hackers)
• Individual sanctioned persons’ known wallet addresses
• Ransomware payment addresses in specific enforcement actions

Receiving stablecoin from a sanctioned address — even unknowingly — is a sanctions violation. OFAC’s strict liability standard applies.

The tainted funds challenge: Blockchain addresses transact with each other, creating a directed graph of fund flows. Funds that passed through a sanctioned address in a prior transaction may technically originate from that address in a chain analysis sense. Chain analysis tools score transactions based on the proportion of funds traceable to high-risk addresses — the “taint” metric. Most compliance programmes use a risk threshold (e.g., direct exposure to sanctioned addresses = block; indirect exposure with <1% taint = allow with monitoring; indirect exposure 1–10% = enhanced review).

Screening timing: Unlike traditional payment screening (where name matching often happens pre-payment), wallet address screening happens pre-transaction against the counterparty address, and post-transaction against incoming funds. The practical implementation: screen outgoing transactions before broadcasting to the blockchain; screen incoming transactions at the point of confirmation or receipt into your custody.

OFAC reporting: If a transaction is blocked because the counterparty address matches an OFAC designation, report to OFAC within 10 business days. Maintain records of blocked transactions in the compliance file.

Component 3 — Chain Analysis

Chain analysis is the forensic investigation and risk-scoring of on-chain transactions using graph analysis techniques. Where sanctions screening asks “is this specific address on a list?”, chain analysis asks “where do these funds come from, and what risk does their origin history represent?”

How it works: Chain analysis platforms (Chainalysis, TRM Labs, Elliptic) maintain databases that:

• Associate blockchain addresses with known entities (exchanges, mixers, DeFi protocols, darknet markets, ransomware wallets)
• Score the risk of a transaction based on the proportion of funds traceable to each category
• Provide alert triggers when a transaction score exceeds defined thresholds

A Chainalysis KYT (Know Your Transaction) API call returns a risk score, the entities in the transaction graph, and the proportion of funds associated with each risk category. A “high risk” score triggers a compliance review; a “severe” score triggers an automatic block.

Real-time vs batch screening: Real-time screening intercepts transactions before they complete in your system (not before blockchain confirmation — that is irreversible). Batch screening reviews historical transactions against updated risk data — new entity attributions can change a transaction’s risk score retroactively as more information becomes available.

The investigation workflow: When a transaction triggers a high risk score, a compliance analyst reviews the Chainalysis Reactor or TRM Forensics graph to understand the specific fund path and entity attribution. The analyst determines whether the risk is:

• Direct exposure (funds came directly from a flagged entity → escalate to block and report)
• Indirect exposure (funds passed through multiple hops, partially attributable → risk decision based on taint percentage and entity type)
• False positive (the flagged entity is low-risk in context, e.g., a large exchange’s address appearing in the graph)

The decision is documented in the case management system. The outcome — allow, block, request enhanced due diligence, file SAR — is recorded with the analyst’s rationale.

Building a Defensible Programme

A defensible stablecoin compliance programme has the same five components as a traditional sanctions programme, plus the three stablecoin-specific layers:

Identity (KYC/KYB): Know who the counterparty is before a stablecoin transaction. The identity is the anchor for both Travel Rule data exchange and for resolving chain analysis alerts.

Wallet attribution: Link wallet addresses to known counterparties in your system. Where counterparties use multiple wallet addresses, attribute all known addresses to their identity record.

Pre-transaction screening: Before sending stablecoin, screen the recipient address against sanctions lists, exchange Travel Rule data if the recipient is a VASP, and check chain analysis risk score.

Post-transaction monitoring: Screen incoming stablecoin against chain analysis risk scores at the point of receipt. For high-value incoming transactions, request chain analysis on the sending address history.

Documentation and audit trail: Every screening decision — cleared, blocked, escalated — must be documented. Include: transaction details, screening results, analyst decision, and rationale. The audit trail is what converts a compliance programme from a checkbox exercise to a defensible position in an enforcement inquiry.

Incident response plan: Pre-defined procedure for: (1) receiving funds from a sanctioned address, (2) discovering a prior transaction was linked to a newly sanctioned address, (3) receiving a chain analysis alert above threshold.

The operational difference from traditional payments compliance: the tooling is newer, the legal frameworks are less settled, and the forensic capability (chain analysis) has no direct equivalent in bank AML. Start with Chainalysis KYT or TRM as your real-time screening API, Notabene or Sumsub for Travel Rule, and the OFAC sanctions screening framework you are already maintaining — stablecoin compliance adds chain address screening on top, not a replacement for the existing foundation.