What kind of stablecoin this guide is actually about
This guide concerns issuer-backed, fiat-referenced stablecoins specifically, tokens where a legal entity issues the coin, holds backing assets, and processes redemption, the pattern USDT and USDC both follow. That scoping isn't arbitrary: the lifecycle mapped below, issuance, backing, redemption, and issuer intervention, only exists where an issuer sits at the centre of the arrangement. Algorithmic stablecoins that hold price through supply adjustments rather than a backing pool, or crypto-collateralised arrangements run through autonomous smart contracts with no redeeming issuer, don't have the same structural anchor points, so this analysis doesn't transfer to them without separate treatment.
Structurally, an issuer-backed stablecoin creates a real tension. Issuance, backing, redemption, and a meaningful degree of intervention capability, freezing, blacklisting, burning, concentrate around one identifiable entity. But once a stablecoin is in circulation, it can move through self-hosted wallets, peer-to-peer transfers, and decentralised infrastructure without that issuer, or any other obliged entity, participating in every hop.
That tension creates an investigation problem, not a lawless transfer environment. The Financial Action Task Force is explicit that peer-to-peer transfers between unhosted wallets aren't explicitly subject to AML/CFT controls under its Standards, because those obligations sit with intermediaries rather than individuals, not that participants or funds sit outside every form of regulated reach. Sanctions obligations, for instance, still apply regardless of who is transacting, and an issuer retains a genuine, if reactive, ability to freeze or burn tokens even after they've left regulated custody.
The practical question for an investigator is where visibility actually disappears and where it comes back. It's high at an originating exchange, narrows once funds sit in a self-hosted wallet, can disappear almost entirely across a peer-to-peer transfer or a cross-chain bridge, and then reappears, sometimes only partially, once funds reach a fiat off-ramp or the issuer's own redemption process. Mapping that lifecycle stage by stage is what the rest of this guide does.
Work through the lifecycle map, then the four risk patterns, then the two operational modules and the Travel Rule continuity map. Work each scenario before reading ahead, make your call, and read why, both for the right answer and every wrong one. The knowledge check pulls the same material from new angles.
Where visibility disappears, and where it comes back
Seven stages, from the exchange that first issues or sells the stablecoin to the practitioner, through to the issuer's own redemption process. Each stage is tagged for what kind of regulated visibility actually exists there, not what a reader might assume from the stage's name alone.
Four patterns, four cards
Each pattern below sits at a specific point in the lifecycle map above. Learn to recognise them before the scenarios test them.
A P2P transfer between unhosted wallets looks like any other blockchain transaction on its face. What's different is that no VASP, custodian, or intermediary sits anywhere in the transaction's counterparties, which is precisely what takes it outside FATF's AML/CFT/CPF framework in the first place.
A wallet several hops removed from any Travel Rule-covered wallet looks, on a single-transaction view, no different from one hop away. FATF is explicit this pattern is further aggravated cross-border, given near-instant settlement to addresses outside the originating jurisdiction.
Cross-chain activity looks like routine interoperability, the same feature that makes stablecoins useful for legitimate cross-border transfers. FATF's own risk indicators flag rapid, repeated bridging or wrapping across multiple chains in a short window, at high cumulative value, with no evident economic rationale.
FATF states plainly that interoperability may weaken a key control available to issuers, the ability to freeze or blacklist assets, where a centrally issued stablecoin circulates on another blockchain as a newly created wrapped version of the original.
Your VASP's off-ramp desk receives a large stablecoin deposit for conversion to fiat. On-chain review shows the depositing wallet received the funds from an unhosted wallet, which itself received them from another unhosted wallet three hops earlier. None of those hops trace back to any VASP-controlled address you can identify.
Stablecoin transaction monitoring indicators
FATF's March 2026 report publishes a categorised list of risk indicators for stablecoin activity in its own Annex A. Selected indicators are reproduced below by category, with FATF's own qualifying language preserved; this is not the full list, consult the primary report directly when building a live monitoring scenario.
Unusual transaction-related indicators
- Rapid cross-border movements of stablecoins inconsistent with customer profile.
- Transfer of large value of stablecoins, especially where recently converted from other virtual assets, to multiple beneficiaries with no apparent connection to the sender, within a limited time frame.
- Multiple large-value transactions in stablecoins in favour of newly opened or previously inactive accounts.
- Purchase of stablecoins issued under a multi-jurisdictional scheme in one jurisdiction, with a redemption request filed with a co-issuer in another jurisdiction, absent any valid economic rationale.
Anonymity-related indicators
- Stablecoin transfers involving unhosted wallets that are multiple hops away from Travel Rule-covered wallets.
- An unhosted wallet suddenly activated after a long period of inactivity, completing multiple cross-chain transactions in a short period, then going inactive again.
- Movement of funds between different blockchains using stablecoins to complicate tracing and exploit gaps in blockchain analytics tools.
- Progressively bridging stablecoins across chains (for example, one chain to a second and then a third) and wrapping or unwrapping the stablecoin prior to off-ramp, inserting additional contracts and router hops that degrade traceability.
TF and PF-related indicators
- Numerous donations to frequently changing wallets that nonetheless share artefacts such as QR codes, domains, or change addresses, with funds routed through DEX routers and bridges before reconverging for cash-out.
- Use of cross-chain bridges to traverse analytics and policy gaps between networks and service providers, accessing global liquidity and off-ramping through non-compliant venues that lack effective screening.
A licensed Major Payment Institution conducting cross-border money transfer and digital payment token services reviewed two wallets it held and found indirect exposure to a wallet linked to terrorism financing. The institution used blockchain analytics tools to review high-risk transactions one hop away, which surfaced the exposure: the two wallets had received stablecoin USDT from an external wallet, which had itself received USDT on Tron from a wallet with a nexus to terrorism financing. That external wallet had already been blacklisted by the stablecoin issuer from transacting to or from it, likely due to its direct nexus to a sanctioned address.
Law enforcement asks a stablecoin issuer to freeze funds tied to a wallet address. The address holds not the issuer's native token, but a wrapped representation of it, created after the token was bridged from the issuer's native chain to a second blockchain.
Questions to ask before assuming a freeze will work
Source: FATF's Recommended Actions call on jurisdictions to prioritise robust technical capabilities among supervisors and law enforcement, including expertise in smart contract functionalities and cross-chain transaction mechanics. Separately, FATF states that interoperability across chains may weaken an issuer's freeze or blacklist control where the original token circulates elsewhere as a newly created wrapped version.
Application: the questions below are FinCrimeRadar's own practitioner decomposition of that combined risk, not a checklist FATF itself publishes field by field. They translate FATF's general warning into the specific facts an investigator needs to establish for a given wallet or transaction.
Circle's own Bridged USDC Standard documentation shows this is a control question, not an existence question. A standard-compliant bridged USDC contract is built from the same FiatToken source code as native USDC and is expected to be code-identical to it from deployment, meaning it already carries the Owner, Pauser, Blacklister, and MasterMinter role structure, freeze and blacklist mechanism included, from day one. What Circle's optional upgrade changes is not whether that mechanism exists but who controls it: the upgrade transfers those roles to a Circle-owned address, using a role-transfer function the bridge is required to expose. Before any such upgrade, those roles typically sit with the bridge operator or another third party, not with Circle and not with nobody. That is a materially different, arguably harder, risk picture than "no freeze mechanism yet": the capability usually already exists, under control an investigator hasn't yet identified or verified. This is a Circle/USDC-specific illustration, drawn from Circle's own Bridged USDC Standard and token design documentation; Tether's own bridging mechanics haven't been separately verified here and shouldn't be assumed identical.
- Is this the issuer's native token, or a bridged or wrapped representation of it?
- Which contract address, and on which chain, actually holds the funds in question?
- If bridged, who controls the bridge, and is that controller identifiable at all?
- Does the issuer's freeze or blacklist mechanism reach this specific representation, or only the native-chain token?
- Can the wrapped representation be burned, and does burning it affect the locked underlying token?
- Where is the underlying native-chain token actually locked while the wrapped version circulates?
Treat "can the issuer freeze this" as a question with a different answer for every chain and representation a token appears on, not a single yes or no about the issuer generally.
What belongs in a stablecoin SAR
FATF does not prescribe a stablecoin-specific SAR content template; the fields below are FinCrimeRadar's own operational recommendation, built from standard SAR narrative practice applied to the visibility-gap analysis above. Treat this as practitioner guidance, not a cited regulatory requirement.
- Every wallet address involved at each hop you were able to trace, hosted and unhosted alike.
- The chain, or chains, and contract address, or addresses, involved, distinguishing native token from any bridged or wrapped representation.
- Hop-count and estimated distance from the nearest identifiable Travel Rule-covered wallet.
- Whether bridging or wrapping occurred, and to which chain, per the token topology questions above.
- Which FATF Annex A-style indicator, or indicators, the activity triggered, using the indicator's own category and language.
- Whether the issuer was contacted about a freeze request, and the outcome.
- The identity of the off-ramp VASP, if the funds reached one, and what CDD it was able to perform given the upstream visibility gap.
Where information continuity exists, and where it breaks
The Travel Rule obligation, under FATF Recommendation 15's Interpretive Note applying Recommendation 16 to VASPs, attaches specifically to a VA transfer, or related message operation, between a VASP and another obliged entity, not to every point an obliged entity happens to touch the funds. The map below shows exactly which hop types carry that continuity and which don't, and is explicit about the difference between the Travel Rule specifically and the broader CDD/AML obligations that also apply to obliged entities.
| Transfer type | Continuity | Why |
|---|---|---|
| VASP → VASP | Continuous, in principle | Both parties are obliged entities conducting exchange or transfer activity as a business, so the Travel Rule obligation applies on both ends. That describes the applicable legal obligation, not a guarantee that the required originator and beneficiary information was actually captured, transmitted, and reconciled correctly in a given case. |
| VASP → unhosted wallet | One-sided | The sending VASP must still collect required originator and beneficiary information, but that record can't be manufactured for the unhosted counterparty. |
| Unhosted → unhosted (P2P) | Breaks entirely | No regulated intermediary participates; the transaction falls outside AML/CFT/CPF obligations at this hop. FATF itself notes an exception for requirements tied to implementing targeted financial sanctions, which apply regardless of who is transacting, so this is a gap in AML/CFT obligations specifically, not every regulated obligation. |
| Unhosted → VASP (receiving) | Reappears, incomplete | The receiving VASP is an obliged entity and applies its own CDD to its own customer, the person who controls the receiving wallet, not to the unhosted wallet's upstream history directly. Visibility into a multi-layered upstream history is limited, and no obliged entity existed to file an STR at the gap hops behind it. |
| Bridge → another blockchain | Depends on control and activity | Continuity depends on a two-part test, not control alone: the bridge needs an identifiable operator with control or sufficient influence who is also providing or actively facilitating VASP services to meet FATF's VASP definition. Absent that combination, there may genuinely be no VASP here. |
| DEX interaction | Depends on control and activity | Same two-part DeFi test: creators, owners or operators need both control or sufficient influence and to be providing or actively facilitating VASP services to meet the VASP definition; many arrangements are decentralised in name only, so this needs checking case by case. |
| Fiat off-ramp | CDD reappears | Converting to fiat is itself exchange activity, bringing the operator within FATF's VASP or FI classification and triggering standard CDD/AML obligations. The Travel Rule itself attaches specifically to a VA transfer between a VASP and another obliged entity, not to the act of converting to fiat, so it doesn't automatically reappear here just because a conversion happens. |
| Issuer redemption | Reappears, plus control | The issuer is directly a VASP or FI where it performs exchange or redemption activity itself. Separately, and not as a consequence of that classification, it retains a smart-contract freeze capability for centralised tokens like USDT or USDC, a distinct technical control point. |
As of FATF's July 2026 Seventh Targeted Update, 83% of surveyed jurisdictions (91 of 109) had passed legislation implementing the Travel Rule at all, and of those, 60% (55 of 91) had not yet issued findings, directives, or taken enforcement or supervisory action on Travel Rule compliance. The continuity gaps mapped above exist on top of that uneven implementation picture, not instead of it; a "VASP → VASP" row that should carry full continuity in principle may still not, depending on which two jurisdictions are actually involved.
FAQ
Does the Travel Rule apply once a stablecoin moves to an unhosted wallet?
Is a peer-to-peer stablecoin transfer illegal?
Can a stablecoin issuer always freeze tokens no matter which chain they're on?
Does FATF expect investigators to build new technical skills for this?
At a glance
Four patterns, the risk that makes each one look routine, the signal that gives it away, and the response that fits.
Mapping the gap is the job, not declaring one.
Every stage in the lifecycle above has a specific, checkable answer for who's watching and who isn't. The investigator's job is to locate exactly where a given transfer sits on that map, not to treat the whole category of stablecoin P2P activity as either fully visible or entirely lawless. FinCrimeRadar's screening tool checks sanctions, PEP, and adverse media exposure for the entities that do sit inside regulated reach, free, no signup required.