Unhosted Wallets, Mixers and Anonymity Technologies
A customer withdrawing virtual assets to an address they control is not, by itself, doing anything suspicious. Self-custody is a normal feature of many blockchain systems. The same is true of privacy. People and businesses can have legitimate reasons not to expose their entire financial history to every counterparty who can inspect a public ledger. The financial-crime problem begins when a bank or crypto-asset service provider can no longer explain who is using the value, where it is going, what happened to it, or why an apparently privacy-seeking transaction is consistent with the customer's profile and the institution's legal obligations.
This chapter therefore starts with an important distinction: unhosted or self-hosted does not mean illicit, and privacy technology does not equal money laundering. Those labels describe how assets are controlled or how transaction information is obscured, not the criminal purpose of a transaction. The control objective is to identify when a combination of customer context, transaction behaviour, counterparty risk, blockchain evidence and jurisdiction-specific obligations creates a material financial-crime concern.
FATF's March 2026 targeted report on stablecoins and unhosted wallets made the issue especially current. FATF highlighted increasing illicit-finance risk in peer-to-peer transactions that can take place without a regulated intermediary on the other side, while also recognising that stablecoins and virtual assets have legitimate uses. Its July 2026 targeted update again identified risks from P2P transactions through unhosted wallets as one of the areas where regulatory and control gaps remain. That is a reason for better risk-based control, not a reason to treat every self-hosted address as prohibited.
The mental model: separate custody, identity, privacy and risk
A useful operating model separates four questions that are often collapsed into one.
The first question is who controls the wallet or address? A hosted wallet is typically provided or controlled through an intermediary such as a VASP or crypto-asset service provider. A self-hosted wallet gives the user direct control of the private keys or equivalent credentials. The terminology varies between jurisdictions and industry sources. Regulation (EU) 2023/1113 uses the term "self-hosted address"; older U.S. proposals and some industry material use "unhosted wallet". For bank design, the important fact is whether there is an obliged intermediary on the other side of the transfer and, if there is, which legal entity it is.
The second question is who is the economic person behind the address? Control of a private key is not the same as beneficial ownership. A customer can control a wallet for themselves, for a company, as an employee, as a trustee, as a technical operator, or under another arrangement. Conversely, a customer may send to a third party's self-hosted wallet. A cryptographic signature or small verification transfer can be useful evidence of technical control, but it does not by itself prove who economically owns the assets or where the assets came from.
The third question is what privacy or obfuscation technique is present? A mixer or tumbler is designed to make it harder to link inputs and outputs. Collaborative transaction techniques can combine multiple users' transfers in one transaction. Privacy-enhancing assets can hide or reduce visibility of amounts, addresses or transaction relationships. Bridges can move value between chains. Decentralised exchanges can swap assets without the same account relationship as a centralised exchange. These technologies have different mechanics and risk implications. Calling all of them "mixers" weakens investigation quality.
The fourth question is what does the whole evidence picture mean? The bank should connect the customer's known profile, expected activity, source of funds, wallet relationship, transaction path, blockchain analytics, sanctions results, counterparties, geographic indicators, device or channel signals, previous alerts and any explanation supplied by the customer. Risk emerges from the combination. A single feature such as one hop from a mixer, a privacy coin, or use of a self-hosted wallet should not automatically become a final decision.
Why banks care even when they do not offer crypto custody
A bank can face these risks without operating a crypto exchange. A retail customer may fund a VASP from a current account and later receive fiat proceeds from the same or another VASP. A corporate customer may receive payments from a virtual-asset business. A private-bank client may disclose substantial crypto wealth as source of wealth. A merchant acquirer may process payments for a wallet provider. A correspondent bank may serve a respondent that in turn serves VASPs. A treasury or investment function may hold tokenised assets. The bank's exposure can therefore appear through fiat payment flows, customer due diligence, counterparty relationships or product partnerships.
The first practical risk is loss of transparency. When value moves from a regulated platform to a self-hosted wallet, the regulated institution may no longer receive identity information from another obliged institution. If the value later moves through multiple addresses, bridges or decentralised services, the bank may need blockchain evidence and customer information to reconstruct the economic story.
The second risk is criminal layering. Criminals can use self-hosted wallets as part of a sequence that includes VASPs, cross-chain bridges, mixers, decentralised protocols and repeated asset swaps. The objective may be to break the easy connection between the original theft, fraud proceeds, ransomware payment, sanctions exposure or other predicate activity and the point where the value returns to the regulated financial system.
The third risk is sanctions exposure. Sanctions authorities can designate persons, entities and, in some regimes, identify digital-currency addresses associated with sanctioned actors. A transaction that touches a mixer is not automatically a sanctions breach. The legal question is whether a prohibited person, property interest, service or activity falls within the applicable sanctions regime and the institution's jurisdictional nexus. AML suspicion and sanctions prohibition must therefore remain separate decision paths, even though the evidence may overlap.
The fourth risk is fraud and customer harm. Scam victims may be persuaded to purchase virtual assets and send them to a criminal-controlled self-hosted address. Account takeover can be followed by rapid withdrawal to an external wallet. A customer may technically authorise the transfer while being deceived about its purpose. Fraud controls, payment protection, AML monitoring and virtual-asset analytics should share relevant intelligence without assuming they are the same control.
The global standard and the local legal rule
FATF Recommendation 15 and its interpretive material bring virtual assets and VASPs into the global AML/CFT framework. FATF expects countries to identify and assess virtual-asset risks, regulate VASPs, apply preventive measures and use a risk-based approach. FATF's 2021 updated guidance specifically addressed peer-to-peer transactions, meaning transfers that can occur without a VASP or other obliged entity at both ends.
FATF does not impose one universal "unhosted wallet ban". Its guidance discusses risk indicators and potential risk mitigants. National and regional law determine which measures become binding. This distinction matters because a product team can easily copy a rule from one jurisdiction into a global decision engine and accidentally deny legitimate customers or fail to meet a different local obligation.
The European Union illustrates the need for configuration by legal entity. Regulation (EU) 2023/1113 contains specific requirements for crypto-asset transfers involving self-hosted addresses. The EBA's Travel Rule Guidelines, applicable from 30 December 2024, explain how CASPs should identify whether the other end is self-hosted and how to obtain relevant information. For transfers involving a self-hosted address at or above EUR 1,000, the EBA Guidelines describe methods for assessing whether the address is owned or controlled by the relevant customer. That is an EU requirement and implementation model; it should not be presented as a global FATF threshold.
Australia provides a different example. AUSTRAC guidance updated on 31 March 2026 says that, where an ordering institution sends value to a self-hosted virtual-asset wallet, it is not required to pass Travel Rule information to that wallet because there is no receiving institution, but it must still collect payer information and the payee's full name and verify payer information. Again, this is an Australian rule, not a universal design template.
The United States also requires care with status labels. FinCEN's 2020–2021 proposal concerning certain transactions with unhosted wallets remained a proposal rather than a general final rule that can simply be stated as current law. FinCEN's October 2023 proposal concerning international convertible virtual currency mixing is also a proposed special measure; a bank should not train staff as if the proposal itself created a blanket ban on mixing. Current U.S. BSA obligations, sanctions law and the institution's risk-based program still need to be applied using the actual rules in force.
What a mixer actually changes
A simple blockchain transfer often creates a visible link from one address to another. A mixer is intended to reduce the usefulness of that link. Different implementations do this differently. Some pool assets from many users and later send different units of the same or another asset after a delay. Some use coordinated transaction construction. Some introduce delays, variable amounts or multiple output addresses. Some operate as centralised services; others use smart contracts or decentralised mechanisms.
The financial-crime value of mixing for a criminal is not "anonymity" in an absolute sense. It is increased uncertainty. An investigator may know that illicit value entered a mixing service but have less confidence about which output contains the same economic value. The service can lengthen an investigation, make attribution harder and create more plausible alternative explanations.
That uncertainty is why a bank should not convert analytics into false precision. If a vendor says an address has "indirect exposure to a mixer", the reviewer needs to know what that means: how many hops, which path, what percentage or amount, what attribution source, what confidence level, and when the label was last refreshed. Two vendors may classify the same cluster differently because they use different heuristics and intelligence.
A historical label also matters. A service can be designated, delisted, shut down, change ownership or change behaviour. OFAC, for example, removed Tornado Cash-related designations from its SDN List on 21 March 2025. Training material that still says "Tornado Cash is sanctioned" as a timeless statement would now be wrong. The correct bank design is to preserve the sanctions-list version and decision date that applied when a transaction was assessed.
Privacy coins and privacy-enhancing technologies
Privacy-enhancing virtual assets are not all built the same way. Some obscure sender or recipient relationships. Some hide transaction amounts. Some use cryptographic techniques that prove a statement without revealing all underlying data. Some provide optional privacy while others make privacy features a core part of normal operation. The bank does not need every analyst to become a cryptographer, but it does need a risk model that understands what evidence is and is not available for a particular asset or protocol.
A privacy feature can be legitimate. Public blockchains can expose balances and transaction histories in ways that would be unacceptable in ordinary bank statements. A business may not want competitors to infer supplier payments. An individual may not want every merchant to inspect their wealth. The institution should therefore distinguish privacy by design from behaviour designed to defeat controls.
The difference may appear in context. A long-standing customer who buys a supported privacy-enhancing asset through a regulated provider, holds it, and later sells it back through the same provider presents a different evidence pattern from a newly opened account that receives scam proceeds, converts them rapidly, routes them through multiple chains and privacy services, then cashes out through unrelated VASPs. The asset label is only one part of the story.
Peer-to-peer transfers and the missing intermediary
FATF's 2026 report on stablecoins and unhosted wallets focuses heavily on the risk created when value can move directly between users without a regulated intermediary on the other side. In a VASP-to-VASP transfer, both institutions may perform customer due diligence and exchange required Travel Rule information. In a self-hosted-to-self-hosted transfer, neither side necessarily performs those institutional controls at the point of transfer.
For a bank or VASP, this creates an evidence problem rather than an automatic prohibition. The institution should know which side of the transaction it controls, what information it can reasonably obtain, which legal requirements apply, and what residual risk remains after mitigation. Measures may include enhanced customer information, wallet-control evidence where legally required or justified, blockchain analytics, source-of-funds review, transaction limits, monitoring, senior approval, or restriction of certain high-risk services.
A poor design asks one question: "Is this an unhosted wallet?" A better design asks: "What do we know about the wallet, who claims to control it, what independent evidence supports that claim, what is the transaction path, what legal rule applies, what risk indicators are present, and what action is proportionate?"
Incoming and outgoing transfers need different questions
For an outgoing transfer, the institution can often intervene before assets leave its control. It may identify the destination address, determine whether it belongs to another VASP or is self-hosted, screen relevant names and addresses, apply blockchain analytics, check customer behaviour and request additional information. Where law or policy requires a pre-transfer control, the decision must happen before broadcast.
For an incoming transfer, the assets may already have arrived on-chain before the institution can complete all analysis. The relevant control point may be before crediting the customer's available balance, before allowing onward withdrawal, or during post-event monitoring. The architecture must distinguish "received on-chain" from "made available to the customer". Treating those as the same state can make an interdiction control impossible to operate.
Return flows deserve particular attention. A customer may withdraw to a self-hosted wallet, interact with decentralised services, and later deposit assets back. The bank should not assume that an earlier wallet-control check permanently proves the provenance of all future assets from that address. Addresses can receive funds from other parties, smart contracts or bridges after the original verification.
Wallet-control evidence: what it proves and what it does not
Institutions use several methods to support a claim that a customer owns or controls a self-hosted address. Depending on the blockchain and local rules, methods can include cryptographic message signing, a small proof transaction, a screenshot combined with account evidence, device or wallet attestation, verified connection through a wallet interface, or other technical proof.
The evidence should be assessed for its actual proposition. A valid cryptographic signature may prove that the customer can use the private key corresponding to an address at a point in time. It does not prove that the customer is the sole controller, that the wallet is not shared, that the assets are beneficially owned by the customer, or that the funds are legitimate.
A small proof transaction has similar limits. It can show operational control of a wallet path, but a criminal can also control a wallet. Screenshots are weaker because they can be altered or may not prove current control. A bank should therefore avoid a single boolean field called wallet_verified. A better evidence model records the method, date, address, network, result, source, reviewer, expiry or refresh rule, and the proposition that the method is considered to establish.
Blockchain analytics: useful evidence, not an oracle
Blockchain analytics can add information that ordinary bank transaction monitoring does not have. It can identify known service clusters, sanctioned or illicit addresses, exposure to scams, darknet markets, ransomware, mixers, bridges, gambling services or other typologies. It can follow value across transparent chains and support case reconstruction.
The output is still evidence with uncertainty. Address clustering can use heuristics. Service attribution can come from public data, proprietary intelligence, law-enforcement information or behavioural inference. A label may change when new information appears. Cross-chain tracing can be incomplete. Privacy-enhancing technologies can reduce visibility. A good case record stores not only the score but the underlying indicators, provider, model or rule version, observation time and material path.
The institution also needs an explicit view of direct and indirect exposure. Direct receipt from a known sanctioned address may create a very different legal and risk question from a small amount that passed through a service many hops earlier. There is no globally valid "three-hop rule" or universal percentage threshold that makes funds clean or dirty. Thresholds are internal risk decisions unless a specific law or official rule says otherwise.
For business analysts, that means requirements should avoid vague statements such as "block high-risk wallets". They should define the event, data source, risk taxonomy, confidence, amount or exposure measure, legal-entity rule, decision owner, timeout, override path, evidence retained and customer status after the decision.
Sanctions screening and AML monitoring must remain separate
Virtual-asset controls often combine blockchain risk scoring and sanctions screening in the same user interface. That is convenient, but the legal logic must remain separate. Sanctions can require blocking, freezing, rejecting, prohibiting or reporting depending on the applicable regime and facts. AML monitoring asks whether activity may be suspicious and whether investigation or suspicious-transaction reporting is required under local law.
A mixer connection can be relevant to both disciplines without producing the same outcome. If the service or address is currently designated under an applicable sanctions regime, sanctions specialists must determine the legal effect. If it is not designated but the pattern suggests concealment of ransomware proceeds, AML investigators may still have a strong case. If the service is neither designated nor linked to suspicious behaviour beyond a weak distant exposure, an adverse customer outcome may be disproportionate.
OFAC's sanctions guidance for the virtual currency industry is useful for U.S.-nexus activity because it emphasises risk-based sanctions compliance, screening and controls suited to virtual-currency operations. But OFAC rules should not be presented as the sanctions law of every jurisdiction. A global bank needs a legal-entity and nexus matrix that routes the same blockchain evidence to the sanctions regimes actually applicable to that transaction.
Alert, case and investigation design
A good alert explains why the transaction needs human attention. It should identify the relevant transfer, wallet addresses, network, asset, amount, customer, source or destination classification, analytics indicators, sanctions results, related fiat transactions and previous relevant alerts. It should not force an investigator to reconstruct the basic event from five systems.
Triage should distinguish urgent legal or fraud intervention from ordinary enhanced review. A potential sanctions match before an outgoing transfer may require immediate hold. A suspected scam withdrawal may need rapid customer contact. A historical indirect mixer exposure on a completed transaction may support a lower-priority AML case. Queue design should reflect the time sensitivity of the risk.
Investigation then asks whether the customer's explanation and independent evidence make the activity reasonable. The analyst may examine source of funds, transaction history, wallet-control evidence, counterparties, blockchain paths, device events, VASP records, Travel Rule data, linked customers and previous cases. Where local law permits or requires it, the institution may request more information from the customer or another institution.
The case conclusion should state what was established, what remains uncertain, why the uncertainty is acceptable or unacceptable, and what action follows. Possible outcomes include closure with rationale, enhanced monitoring, customer due diligence refresh, transaction restriction, relationship review, sanctions escalation, fraud action, suspicious-transaction reporting or law-enforcement response. The available options and confidentiality rules differ by jurisdiction.
Architecture: keep identity, blockchain evidence and policy connected
The control normally spans several systems. The customer channel or custody platform captures the transfer instruction. KYC systems provide verified customer data. A counterparty-resolution service identifies whether the destination belongs to a regulated provider. A policy engine applies legal-entity and jurisdiction rules. Wallet-control tooling captures technical proof where relevant. Blockchain analytics provides path and attribution evidence. Sanctions services screen names and addresses. Transaction monitoring looks for behavioural patterns. Case management preserves investigation and decisions.
The systems should share correlation identifiers without copying sensitive data everywhere. A transfer ID should link the customer instruction, wallet address, analytics result, sanctions screening, Travel Rule record where relevant, blockchain transaction hash and case. If an investigator starts from any one of those objects, they should be able to reconstruct the same event.
Point-in-time evidence is essential. A wallet label can change after a transaction. A sanctions list can change. A vendor can update a risk score. A customer can update their profile. The bank should preserve the values and rule versions used when it made the original decision, while also allowing later intelligence to trigger a lookback review.
Customer impact and avoiding de-risking by label
Self-hosted-wallet policy can easily become a proxy for blanket de-risking. If an institution rejects every transaction with a self-hosted address, it may avoid some operational complexity but also exclude legitimate activity and potentially misapply a risk-based framework. Whether a restriction is legally permissible and commercially appropriate depends on jurisdiction, product terms, risk appetite and customer-outcome obligations.
A proportionate framework starts from evidence. Low-risk transfers with a clear customer purpose, established source of funds and no material adverse blockchain indicators may proceed with ordinary controls. Higher-risk cases may require step-up evidence or enhanced review. Activity linked to a current prohibition or a well-supported serious financial-crime concern may require restriction or legal action. The institution should be able to explain why different cases produced different outcomes.
Customer communication also matters. The bank must not tip off a customer where local AML law prohibits disclosure, but it should not use vague financial-crime language as a substitute for lawful and fair communication. Product teams need approved reason codes and customer messages for technical verification failures, unsupported wallet types, additional information requests, compliance reviews and final restrictions.
What good governance looks like
Governance begins with a policy that defines risk rather than simply naming technologies. It should state how the institution treats self-hosted wallets, P2P transfers, mixers, privacy-enhancing assets, bridges, decentralised services and high-risk VASPs, while allowing jurisdiction-specific requirements to override group defaults where necessary.
Model and vendor governance are equally important. Blockchain-analytics providers influence real customer outcomes. The bank should understand their coverage, attribution methods, confidence measures, update cycles, chain support, known limitations and change controls. A vendor score should not be treated as a regulatory rule.
Operations governance should monitor alert volumes, ageing, false-positive patterns, customer friction, escalations, restrictions, suspicious reports, sanctions actions and override decisions. Quality assurance should test whether investigators use evidence consistently. Tuning should focus on missed risk and unnecessary friction, not simply reducing alerts.
Senior governance should receive enough information to challenge risk appetite. If the bank permits self-hosted-wallet withdrawals but has no reliable capability to identify destination type, that is an exposure. If it blocks all privacy-enhancing assets but cannot explain why lower-risk legitimate activity is treated the same as known illicit exposure, that is also a governance weakness.
The practical lesson
The strongest control does not ask whether a wallet or technology is "good" or "bad". It asks what can be established about the customer, counterparty, control of the address, movement of value, source of funds, legal obligations and risk indicators at the point when a decision must be made.
For learners, the core discipline is to preserve uncertainty rather than hide it. A wallet-control proof is one fact. A blockchain label is one fact. A sanctions match is a separate legal fact to resolve. A customer explanation is evidence but not independent verification. A mixer or privacy feature increases investigative complexity but does not itself prove criminal purpose. When those facts are joined carefully, the institution can make decisions that are both more effective against financial crime and more defensible for legitimate customers.
Operational deep dive: mixers, privacy techniques and transaction-graph evidence
The base chapter established the evidence model. This deep dive examines how obfuscation appears in transaction data and why investigators should describe what they can actually see rather than rely on labels such as "mixer exposure" or "privacy risk" without context.
Mixing is a process, not one transaction shape
A centralised mixing service may accept deposits from many users, pool them operationally and return different units of the same or another asset after a delay. A smart-contract mixer can accept standardised deposits and later permit withdrawals using cryptographic proofs that make the public link between a particular deposit and withdrawal deliberately harder to establish. Collaborative transaction techniques can create a single transaction with multiple inputs and outputs so that an observer has less confidence about which input funded which output. Other services combine swaps, bridges or internal ledger movements with mixing-like behaviour.
These mechanisms matter because a monitoring rule that looks only for one known service address is fragile. A service can rotate addresses, use deposit contracts, route through intermediaries or disappear. Conversely, ordinary exchange infrastructure can also pool customer assets and create large multi-input or multi-output transactions. The investigator needs to understand the service type and transaction mechanics before interpreting the graph.
A practical analytics record should therefore retain the service category, direct or indirect relationship, observed path, amount or proportion involved, date of attribution, provider confidence, relevant addresses and the evidence source. "Mixer = yes" is not enough for a defensible case.
Exposure is not binary
Suppose a customer receives 10 units of an asset from an address. Analytics indicates that 0.2 units in the upstream cluster passed through a known mixer four transactions earlier. Another customer receives 10 units directly from a service currently identified as a mixer, minutes after funds linked to a ransomware wallet entered that service. Both cases can be described loosely as "mixer exposure", but their evidential strength is very different.
This is why hop count by itself is a poor decision rule. A first-hop relationship can still be innocent, for example when a legitimate recipient receives value from someone who previously used a privacy service. A distant relationship can still be important if the path represents deliberate peeling, repeated laundering behaviour or a uniquely attributable criminal flow. The reviewer needs amount, timing, path structure, service context and customer behaviour.
Exposure percentages also need careful interpretation. A vendor may estimate that a wallet has a certain percentage of exposure to a category based on transaction values or cluster relationships. The bank should know the methodology. A percentage calculated across lifetime wallet inflows is not the same as the percentage associated with the specific transfer under review. Requirements should state which metric is used and why it is relevant.
Common obfuscation patterns
Peel chains move portions of value through a sequence of addresses, often sending a smaller amount away at each step while the remainder continues. The pattern can be used for legitimate wallet management, but it can also help criminals create distance from an originating address.
Chain hopping moves value between different blockchain networks, often through bridges, exchanges or swap services. It can interrupt a tracing workflow if the analytics platform does not support both chains or cannot correlate the cross-chain event reliably.
Asset swapping changes one token into another. A swap is ordinary market activity, but rapid repeated swaps across multiple assets and venues can increase complexity and may matter when there is no investment or commercial explanation.
Nested services arise when one service accesses liquidity or infrastructure through another. A bank may see a VASP relationship while the underlying activity originates from customers of a less transparent service. The same idea exists in correspondent banking: the immediate counterparty is not always the end of the risk chain.
Cross-chain bridges lock, burn, mint or release value across networks depending on their technical design. They are not mixers by definition. Their risk relevance comes from the ability to move quickly between ecosystems and from varying visibility, governance and control.
Decentralised exchanges facilitate swaps using smart contracts or other decentralised arrangements. They are not automatically anonymity services. The financial-crime question is whether a person or arrangement falls within applicable legal definitions and what the transaction behaviour shows.
A good investigation names the actual pattern instead of using "obfuscation" as a catch-all explanation.
Privacy coins and reduced visibility
Some assets are designed so that ordinary public-ledger analysis reveals less information than on transparent blockchains. Depending on the protocol, techniques can obscure sender relationships, recipient addresses, transaction amounts or the linkage among them. This can reduce the effectiveness of standard address-clustering and transaction-graph methods.
Reduced visibility does not mean no controls are possible. A regulated VASP can still know its customer, record deposits and withdrawals, apply product restrictions, monitor account behaviour, screen available data, perform source-of-funds review and respond to legal requests. The limits simply shift the evidence mix away from public-chain tracing and toward customer, account, counterparty and platform data.
The institution should be explicit about unsupported evidence. If its analytics vendor cannot trace a particular privacy-enhancing asset, the system should record "coverage unavailable" rather than return a reassuring low risk score. A missing score is not a clean result. Product approval should identify which networks and assets can be monitored, what compensating controls are available, and which residual risks have been accepted.
Privacy-preserving protocols and zero-knowledge technology
Zero-knowledge proofs can allow one party to prove that a statement is true without revealing all underlying data. In financial services, that can support legitimate privacy and potentially more selective compliance disclosures. It can also make public blockchain tracing different from traditional transparent-ledger analysis.
The control response should not be "zero knowledge equals high risk". The bank should identify what is hidden, what remains visible, whether a regulated intermediary is involved, what customer information is available, and whether an auditable compliance mechanism exists. Technologies evolve quickly; policy should define required evidence outcomes rather than freeze one view of a particular protocol.
Network indicators and customer behaviour
Blockchain evidence becomes much stronger when combined with customer behaviour. Several examples illustrate the difference.
A salaried customer with modest historical crypto purchases suddenly receives multiple large fiat credits from unrelated persons, sends them to a VASP, buys stablecoins and withdraws immediately to new self-hosted addresses that later consolidate through a mixer. The suspicious picture comes from the end-to-end pattern: third-party funding, rapid conversion, unfamiliar destinations, common control indicators and subsequent obfuscation.
A software company paying international contractors may make frequent stablecoin withdrawals to self-hosted addresses. The company can provide contracts, invoices, payroll records and a coherent business explanation. Some recipients may use privacy tools after payment. The bank still assesses risk, but it should not attribute every downstream action to the corporate customer without evidence.
A long-term investor may move assets from an exchange to cold storage and later return them after several years. A new analytics label may show that a tiny historical input to the wallet had indirect mixer exposure. That fact may deserve review, but it should not erase the customer's established source of wealth, long holding period and transparent acquisition history.
Source of funds and source of wealth in crypto cases
Source-of-funds analysis asks where the specific assets in the transaction came from. Evidence can include VASP statements, trade history, bank transfers used to acquire assets, mining records, employment or business income, sale agreements, staking records, investment documentation, tax information where appropriate, and transaction hashes connecting documented events.
Source of wealth asks how the customer accumulated their overall economic position. A customer may legitimately have substantial virtual-asset wealth from early investment, employment in the sector, business activity or other sources. The bank should assess plausibility against the customer's timeline and supporting evidence rather than demand impossible proof for every historical blockchain movement.
Privacy tools make this work harder when the public transaction path is incomplete. That increases the value of contemporaneous records and independent evidence. It does not create a licence to assume illicit origin simply because the chain cannot be fully traced.
Sanctions evidence and time
Sanctions screening of virtual assets can involve names, entities, services and digital-currency addresses. Address screening is valuable where authorities publish addresses or analytics reliably associates addresses with designated actors. But designation status changes.
The Tornado Cash example is a useful lesson in point-in-time governance. OFAC designated Tornado Cash-related property in 2022 and removed the related SDN designations on 21 March 2025. A transaction assessed in 2023 and a transaction assessed in late 2026 therefore cannot be described with the same present-tense sanctions conclusion. The bank needs list history, decision timestamps and legal analysis of the facts that existed at each point.
Other mixer-related enforcement actions also need precise status. OFAC's 2022 Blender.io designation demonstrates that a mixing service can be directly targeted under sanctions, but an investigator should verify the current list rather than rely on an old training slide. The broader lesson is that technology category and designation are separate attributes.
The case narrative should expose uncertainty
A strong case note might say:
"The customer withdrew 75,000 USDC to address A, which they stated was personally controlled. Control was evidenced through the approved wallet-signing process on 4 September. Twenty-six hours later, 60,000 USDC moved from address A through bridge B to chain C. Analytics provider X, model version Y, attributed the destination cluster to a mixing service with high confidence as of 6 September. No sanctions match was identified under the regimes applicable to the booking entity at the time of review. The customer's explanation that the transfer was for long-term cold storage is inconsistent with the immediate onward bridge and mixing activity. Source of funds is documented salary and earlier investment gains, but the purpose of the onward movement remains unexplained. Enhanced review and AML investigation are therefore required."
That narrative is more useful than "high-risk mixer hit". It separates known facts, customer claims, vendor attribution, legal screening and the reason for escalation.
What not to infer
Do not infer identity from an address alone. Do not infer beneficial ownership merely because a customer can sign a message. Do not infer criminality from self-custody. Do not infer laundering from privacy technology without context. Do not infer sanctions prohibition from an AML risk score. Do not infer that absence of a vendor alert proves absence of risk.
The professional standard is to know what each data point can support and where it stops. That discipline is what makes virtual-asset investigations defensible when technology, regulation and intelligence all change faster than traditional bank product rules.
Advanced practice: policy, architecture and control delivery
This supplement converts the risk concepts into a buildable bank control. The most important design principle is that self-hosted-wallet and privacy-technology decisions should be configurable by legal entity, product, asset, network and jurisdiction. A global boolean such as allow_unhosted_wallet = false may be easy to implement, but it cannot represent different laws, customer segments, sanctions regimes, product capabilities or risk appetites.
Build a policy decision matrix
The policy layer should answer a defined sequence of questions. Which bank or VASP legal entity is serving the customer? Which product is being used? What asset and network are involved? Is the counterparty another regulated provider, a self-hosted address, an unidentified service or an unsupported destination? Which jurisdiction-specific information or wallet-control requirements apply? Are sanctions or other legal restrictions triggered? What risk indicators remain after those mandatory checks?
The result should map to controlled dispositions. A low-risk case may be allowed automatically. Another may require step-up information. A higher-risk case may be held for specialist review. A legally prohibited transaction may require a sanctions-specific outcome. A product that the institution does not support can be rejected for product-policy reasons without labelling the customer suspicious. These reason codes matter because operations, customer communication, reporting and audit all depend on knowing why the action occurred.
Rules need effective dates. EU requirements applying from 30 December 2024, Australian Travel Rule reforms in 2026, a sanctions designation, a later delisting, or an internal risk-appetite change should not overwrite history. The decision record should retain the rule version applied to the transaction.
Canonical data model
A useful transfer object should include, at minimum, customer and account identifiers; booking legal entity; asset, network and amount; fiat equivalent at the decision time where thresholds depend on value; origin and destination addresses; counterparty classification; customer-declared beneficiary or owner; wallet-control evidence; Travel Rule status where relevant; blockchain transaction hash when available; analytics provider and result; sanctions screening result; source-of-funds evidence links; decision; reviewer; timestamp; and policy version.
Do not put every field in one database merely for convenience. Identity systems remain authoritative for customer data. Blockchain systems remain authoritative for transaction hashes and addresses. Screening services retain their own evidence. The case platform can reference those records through stable identifiers and store a point-in-time decision snapshot.
Data lineage should show whether an address came from the customer instruction, a blockchain observation, a Travel Rule message or a vendor enrichment. The same text value can have different evidential meaning depending on its source.
Counterparty classification
The institution should not ask the customer to classify the destination and then accept the answer unchallenged. Technical and external evidence can help identify known VASP clusters, smart contracts or services. When the classification remains uncertain, the system can request customer information or route the case for review.
A classification should include confidence and provenance. SELF_HOSTED_CONFIRMED, VASP_CONFIRMED, SERVICE_ATTRIBUTED, and UNKNOWN are more useful than a single hosted/unhosted checkbox. A transfer may also involve a smart contract rather than a conventional wallet, so the taxonomy must allow for protocol interactions.
Classification can change. An address initially marked unknown may later be attributed to a VASP or illicit service. A significant reclassification should be capable of triggering a lookback on earlier transfers.
Wallet-control verification service
Where the applicable rule or risk framework requires evidence of wallet control, the service should support the methods approved for that network. It should record exactly what method was used and what the institution considers it to prove.
For cryptographic signing, the service needs network-specific validation, replay protection, challenge expiry and secure association with the logged-in customer session. A challenge should be unique and time-limited. The signed message must be validated against the claimed address. The service must not request the customer's private key or seed phrase.
For a proof transaction, the institution needs rules on expected amount, destination, expiry, network fees and how to distinguish the verification transfer from normal customer activity. Tiny-value proof transactions can create operational confusion if monitoring treats them as ordinary withdrawals.
Fallback evidence should be governed explicitly. If screenshots are permitted for some wallets that cannot sign messages, operations should know what accompanying evidence is needed and when specialist review is mandatory. "Manual override" should never mean "accept whatever the customer sends."
Analytics integration
An analytics response should be decomposed into useful components rather than reduced to one score. The integration should preserve categories, direct or indirect exposure, amounts, hop information where relevant, attribution confidence, source, timestamp, model or rules version and supported-chain coverage.
Timeout behaviour matters. If the analytics service is unavailable, does the transaction wait, fall back to a cached result, proceed below a defined risk threshold, or fail closed? The answer may differ between products and customer segments. The business requirement needs a deterministic degraded-mode path and an audit trail showing that degraded mode was used.
Vendor changes need regression testing. A provider can change category names, scoring methodology, address clusters or API fields. The bank should test whether those changes alter decision outcomes unexpectedly before production rollout.
Screening and monitoring choreography
Pre-execution screening should occur at the last practical point before irreversible broadcast when a legal or policy decision depends on the result. If a wallet address or beneficiary changes after screening, the control should invalidate the old result rather than allow the transfer based on stale data.
Post-event monitoring should connect on-chain activity to fiat behaviour. A customer can fund a VASP through bank transfers, move virtual assets through self-hosted wallets and later cash out at another VASP. If the bank monitors only the fiat legs independently, it may miss the joined pattern.
Case creation should preserve all contributing alerts without duplicating investigations. A sanctions alert, scam warning and blockchain-risk alert may refer to the same transfer. Case orchestration should join them under one event while maintaining separate specialist decisions where required.
Business analyst acceptance criteria
A business analyst should be able to express the control as testable outcomes. Examples include:
- When the destination is confirmed as another regulated VASP, the workflow follows the hosted-counterparty route and does not request self-hosted-wallet proof.
- When EU rules require ownership or control verification for a qualifying transfer involving a self-hosted address, the workflow cannot release the transfer until an approved verification method passes or an authorised exception is recorded.
- When the analytics provider returns
coverage unavailable, the platform must not interpret the result as low risk. - When a sanctions screening result is unresolved, the transaction follows the sanctions hold workflow rather than the ordinary AML review queue.
- When an address attribution changes materially after settlement, configurable lookback logic can identify prior affected transfers and customers.
- When the policy engine is unavailable, the product follows the approved degraded-mode rule and records the fallback version used.
- When a customer repeats failed wallet-control challenges, the event is available to fraud and financial-crime monitoring without exposing private authentication material.
Acceptance criteria should include negative cases. A legitimate customer using a self-hosted wallet should be able to complete the journey where law and policy permit it. A supported wallet that cannot use one verification method should be tested against approved alternatives. A customer should not be trapped in an endless review loop because two systems disagree about counterparty classification.
Testing strategy
Unit testing validates address formats, challenge signatures, policy thresholds and reason-code mapping. Integration testing validates KYC retrieval, analytics, sanctions screening, Travel Rule exchange, case creation and blockchain broadcast sequencing. End-to-end testing proves that a real journey cannot bypass the control through retries, changed addresses, alternate networks or race conditions.
Scenario testing should include direct exposure to a currently restricted address; indirect historical mixer exposure; a clean self-hosted cold-storage withdrawal; incoming assets from a self-hosted wallet; unsupported analytics coverage; an address reclassified after settlement; a customer using a privacy-enhancing asset; a scam victim under social engineering; a VASP misclassified as self-hosted; and a genuine self-hosted wallet incorrectly attributed to a service.
Performance testing is also financial-crime testing. If analytics and screening add unacceptable latency, product teams may create bypasses. The architecture should define service-level objectives, timeouts and safe fallback behaviour before volume arrives.
Governance and evidence
Every manual override should capture the original automated decision, the reason for override, approving role, evidence and policy basis. Overrides should be analysed for concentration by team, customer type, rule and vendor category. High override rates can show that the rule is poorly calibrated or that investigators do not trust the tooling.
Quality assurance should sample both escalated and non-escalated cases. Reviewing only suspicious cases cannot tell the bank whether legitimate privacy behaviour is being restricted unnecessarily. Missed-risk analysis and customer-impact analysis belong in the same control-health discussion.
The end state is not maximum friction. It is an evidence chain that allows the institution to explain, months later, why it believed a wallet classification, what it knew about the customer and transaction, which law and policy applied, what the analytics showed, what decision followed and whether later intelligence changed that view.
Practice close: review checklist, metrics and knowledge check
A self-hosted-wallet control is ready for production only when it can handle ordinary legitimate behaviour as confidently as it handles high-risk behaviour. The following review points are intended for compliance teams, operations, investigators, product owners, architects, developers and testers.
Investigation review checklist
Before closing or escalating a case, confirm that the investigator has identified the customer and booking legal entity, the asset and network, the relevant wallet addresses, and whether the other side is a VASP, self-hosted address, protocol or unknown service. The case should show which jurisdiction-specific rules apply rather than quoting a global policy without legal context.
Check whether wallet-control evidence was required and, if so, what method was used. State the exact proposition that the evidence supports. Do not turn technical control into an unsupported conclusion about beneficial ownership or source of funds.
Review blockchain evidence at transaction level where possible. Record direct and indirect exposure separately. Capture the material path, amount, timing, attribution confidence and analytics version. If chain coverage is incomplete, say so explicitly.
Check sanctions independently from AML risk. An analytics category called "sanctions" should lead to sanctions screening and legal resolution, not become a substitute for it. Preserve the list version and decision time.
Compare observed behaviour with the customer's expected activity and explanation. Ask what changed, whether source of funds is established, whether counterparties make sense, whether the sequence is commercially or personally plausible, and whether fraud or scam indicators are present.
The conclusion should be written as an evidence argument: facts established, facts claimed by the customer, unresolved gaps, applicable policy, decision, and any reporting or relationship action. Avoid shorthand such as "crypto high risk", "mixer = suspicious" or "wallet verified".
Control-health metrics
Management information should show more than alert counts. Useful measures include the proportion of transfers classified as VASP, self-hosted, protocol and unknown; wallet-control challenge success and failure rates; analytics coverage by supported chain; volume and value of transfers by risk outcome; alert-to-case conversion; false-positive themes; manual override rates; investigation ageing; customer abandonment caused by step-up controls; sanctions escalations; suspicious-report referrals; lookbacks triggered by re-attribution; and material vendor-data changes.
Segment metrics where differences matter. A high challenge-failure rate on one wallet type may signal a technical integration problem rather than customer misconduct, while concentrated manual releases can reveal calibration or training weaknesses.
Production change controls
Changes to blockchain analytics are control changes even when they arrive as vendor data. New chains, new attribution categories, scoring changes and cluster updates can change customer outcomes. Material changes should be tested against historical cases and known benign populations before full rollout.
Policy changes need effective dates and migration logic so new rules do not erase earlier decisions. Product launches involving new chains or privacy features should document analytics coverage, sanctions capability, Travel Rule implications where relevant, wallet-control options, case support and residual risk.
Testing examples that should exist before release
A clean self-hosted-wallet withdrawal should complete without unnecessary manual intervention. Jurisdiction-specific thresholds should invoke the correct control only for legal entities to which they apply. A confirmed VASP should not be routed into self-hosted verification, and an unknown address should not be treated as high-confidence self-hosted.
A direct current sanctions hit should stop in the correct sanctions workflow. An indirect mixer exposure should create the configured risk response without being mislabelled a legal sanctions block. A privacy-enhancing asset for which the analytics vendor has no coverage should show "coverage unavailable". A later address re-attribution should identify prior material transactions for lookback. An incoming transfer should not become withdrawable before controls that are designed to operate before availability have completed.
Testers should also try evasion. Change the destination address after screening. Retry a failed wallet-control challenge from another device. Split value around a policy threshold. Move through an unsupported chain. Use a bridge before returning value. Create multiple customers sending to the same address. Confirm that correlation and monitoring still work.
Five questions for reviewers
1. Is a self-hosted wallet inherently high risk?
No. Self-hosting describes custody or control structure. Risk depends on customer, transaction, counterparty, behaviour, legal context and evidence.
2. Does a valid wallet signature prove beneficial ownership?
No. It normally supports evidence of technical control of the relevant key or address at a point in time. Economic ownership and source of funds require separate evidence.
3. Does mixer exposure prove money laundering?
No. It can be a meaningful risk indicator, particularly when combined with other evidence, but the investigator should establish the transaction path, service context, customer purpose and surrounding facts.
4. Can a blockchain analytics score replace sanctions screening?
No. Analytics can help identify relevant exposure, but sanctions applicability is a legal decision under the regimes that apply to the institution and transaction.
5. Is there one global threshold for self-hosted-wallet verification?
No. FATF provides a global risk-based standard, while binding thresholds and procedures come from local or regional implementation. The EU has specific rules that must not be copied into every jurisdiction as if they were universal.
Final takeaway
Self-hosted wallets and privacy technologies test whether a financial institution truly understands risk-based control. The easy answer is to label unfamiliar technology dangerous. The equally weak answer is to assume public blockchains make every transaction transparent enough. The professional answer sits between those extremes: identify what the technology changes, preserve the evidence and its uncertainty, apply the correct jurisdictional rule, investigate behaviour in context, and make a proportionate decision that can be explained to compliance, audit, regulators and affected customers.
Masterclass: the privacy-seeking customer and the suspicious return flow
This case is fictional but reflects the kinds of evidence conflicts a bank or VASP can face.
A long-standing technology consultant, Maya, has banked with the institution for seven years. Her salary and consulting income are well documented. She has also bought virtual assets periodically through regulated exchanges for several years. Her customer risk rating is standard, and previous activity shows no material alerts.
Maya requests a withdrawal of the equivalent of EUR 85,000 in a stablecoin from the bank's digital-asset service to a self-hosted address. She says the wallet is a hardware wallet used for long-term custody because she does not want to leave a large balance on an exchange. The destination address is not attributed to another VASP. The booking entity is in the EU, so the product workflow applies the institution's EU self-hosted-address controls.
Stage 1: prove only what needs proving
The customer completes the approved cryptographic wallet-control challenge. The signature validates. The control record therefore supports a specific conclusion: Maya demonstrated control of the private key associated with that address at the time of the challenge.
The analyst does not write "wallet ownership proven". That would go beyond the evidence. The bank already knows Maya is the account holder and has evidence of how the virtual assets were acquired, but technical control of an address does not prove that no other person can access it or that every future asset entering the wallet will belong beneficially to Maya.
Blockchain analytics shows no material adverse exposure at the time of withdrawal. Sanctions screening is clear under the regimes relevant to the booking entity. The source of funds is consistent with documented purchases and investment gains. The withdrawal proceeds.
Stage 2: behaviour changes after withdrawal
Three days later, monitoring receives updated blockchain intelligence. Most of the withdrawn stablecoins moved from Maya's self-hosted address to a bridge, arrived on another chain, were swapped into another asset and then interacted with a privacy service. The path is not itself proof of laundering, but it is inconsistent with Maya's stated purpose of long-term cold storage.
The monitoring rule generates a case because the combination matters: recent high-value withdrawal, declared long-term storage, rapid cross-chain movement, multiple asset conversions and interaction with a privacy service. The alert does not say "money laundering confirmed". It says the expected-use explanation no longer fits observed behaviour.
Operations also discovers that the analytics provider's first result did not cover the destination chain used after the bridge. That gap is visible in the evidence record because unsupported coverage is stored explicitly rather than mapped to a zero-risk score.
Stage 3: value returns
Six weeks later, Maya deposits virtual assets worth about EUR 62,000 back to the bank from a different self-hosted address. The incoming assets have a transaction path that the analytics provider links indirectly to the same privacy service. The attribution is high confidence for the service cluster, but the provider cannot deterministically link Maya's original deposit into the service to this exact output.
This distinction matters. The investigation can say that Maya's earlier funds entered the privacy service and that later funds she controls have exposure to that service. It cannot honestly say the public blockchain proves the returned assets are the same units that entered it.
The bank holds the incoming credit from onward withdrawal under its product controls while the AML investigation is completed. This is a policy and risk action, not automatically a sanctions freeze. No current sanctions designation is identified for the service or addresses under the regimes applicable to the booking entity.
Stage 4: customer explanation
Maya explains that she used the bridge and privacy service because she did not want clients and other counterparties to trace her public wallet balance. She provides transaction records from her wallet, evidence of the bridge, and a detailed history of the assets. Her explanation is technically plausible.
The investigator therefore tests it rather than dismissing it. The account history shows that Maya has publicly disclosed one receiving address for consulting-related crypto payments. Several legitimate counterparties can indeed see transfers from that address. The privacy motivation is credible.
However, another fact emerges. Shortly before the return deposit, the wallet received a large transfer from an address associated by two independent sources with an offshore VASP that does not permit customers in Maya's country and has weak public regulatory information. Maya initially describes the transfer as "my own funds from another wallet" but cannot provide records showing how she acquired those assets.
The investigation has now changed. The main concern is no longer simply use of a privacy service. It is an unexplained third-party or offshore source combined with a privacy-obscured transaction path and an inconsistent initial explanation.
Stage 5: evidence-based disposition
The investigator documents five separate conclusions.
First, the original source of funds used for the EUR 85,000 withdrawal was reasonably established. Second, wallet control at the original withdrawal was established using the approved method. Third, the subsequent privacy activity was real but had a plausible legitimate rationale and was not, by itself, enough to establish suspicious purpose. Fourth, the return flow could not be deterministically linked to the original assets because the privacy mechanism reduced traceability. Fifth, a material portion of the returned value came from a source Maya could not adequately explain and which carried additional counterparty risk.
Under the bank's local AML procedures, the unresolved source and inconsistent explanation justify escalation for suspicious-transaction reporting consideration. The reporting decision is made under the booking entity's local law by the authorised AML function. The bank also refreshes customer due diligence and places proportionate restrictions on additional incoming virtual-asset transfers while the relationship review is completed.
The case is not closed as "mixer use". That description would be both lazy and misleading. The actual concern is unexplained value entering a customer-controlled wallet through a higher-risk counterparty, followed by activity that reduced traceability and an explanation that did not fully reconcile with independent evidence.
Why this case matters
The case demonstrates why binary rules perform badly. If the bank had prohibited every self-hosted-wallet transfer, it would have rejected a legitimate cold-storage request without ever learning anything about the later risk. If it had treated successful wallet-control verification as proof of future provenance, it would have over-trusted the return flow. If it had treated privacy-service use as automatic criminality, it would have ignored a credible privacy rationale. If it had ignored privacy exposure entirely, it might have missed the importance of the unexplained offshore inflow.
Good financial-crime control is the disciplined joining of facts. Each fact has a scope. Each source has limitations. The final decision becomes defensible because the investigation explains both what increased concern and what did not.
References and further reading
The chapter uses the following public, authoritative sources. Jurisdiction-specific material should be read with the institution's current legal and compliance interpretation because rules, designations and guidance can change.
FATF global standards and current virtual-asset risk work
FATF, Updated Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers, 28 October 2021. This remains a core explanation of how Recommendation 15 applies to virtual assets and VASPs, including peer-to-peer transactions, risk mitigation, VASP regulation and the Travel Rule. FATF notes on the publication page that later revisions to the Standards should also be considered.
https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets-2021.html
FATF, Targeted Report on Stablecoins and Unhosted Wallets: Peer-to-Peer Transactions, 3 March 2026. Used for the current discussion of P2P transfers via unhosted wallets, stablecoin misuse, cross-chain complexity and risk-based mitigation.
FATF, Seventh Targeted Update on Implementation of the FATF Standards on Virtual Assets/VASPs, 16 July 2026. Used for the current implementation context, including continuing risks from P2P transactions through unhosted wallets and uneven global implementation of Recommendation 15.
FATF, Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing, 14 September 2020. Used as a typology and indicator reference. Red flags are indicators for contextual assessment, not proof that criminal activity has occurred.
https://www.fatf-gafi.org/en/publications/Methodsandtrends/Virtual-assets-red-flag-indicators.html
FATF, Targeted Report on Regulatory Challenges from Decentralised Finance, 21 July 2026. Used to keep decentralised protocols distinct from simple wallet categories and to support a functional, risk-based treatment of DeFi arrangements.
European Union
European Union, Regulation (EU) 2023/1113 on information accompanying transfers of funds and certain crypto-assets. Used for the EU definition and legal framework for transfers involving self-hosted addresses.
https://eur-lex.europa.eu/eli/reg/2023/1113
European Banking Authority, Guidelines on information requirements in relation to transfers of funds and certain crypto-assets transfers under Regulation (EU) 2023/1113, published 4 July 2024 and applicable from 30 December 2024. Used for practical identification of self-hosted addresses and the EU requirements concerning ownership or control verification for qualifying transfers of EUR 1,000 or more.
Australia
AUSTRAC, When the travel rule doesn't apply, guidance updated 31 March 2026. Used for the Australian treatment of transfers to self-hosted virtual-asset wallets and the information that an ordering institution must still collect and verify.
United States
U.S. Treasury, Office of Foreign Assets Control, Sanctions Compliance Guidance for the Virtual Currency Industry, publication notice 15 October 2021. Used for U.S.-specific sanctions compliance principles and the need to integrate sanctions screening and risk controls into virtual-currency operations.
https://ofac.treasury.gov/recent-actions/20211015
U.S. Treasury, Office of Foreign Assets Control, Cyber-related Designation Removal; North Korea Designation Update and Removal, 21 March 2025. Used to verify that Tornado Cash-related entries were removed from the SDN List on that date and to illustrate why sanctions decisions require point-in-time list evidence.
https://ofac.treasury.gov/recent-actions/20250321
FinCEN, Proposal of Special Measure Regarding Convertible Virtual Currency Mixing, as a Class of Transactions of Primary Money Laundering Concern, 19 October 2023. Used only as a U.S. proposal and not presented as a final blanket prohibition.
FinCEN, Extension of the reopened comment period for the proposed rulemaking on certain CVC and digital-asset transactions, 26 January 2021. Used to distinguish the proposed U.S. unhosted-wallet reporting and recordkeeping framework from binding final rules.