Lite Mode was designed as the easiest way to check crypto wallet risk — fast, affordable, and accessible for individuals who want quick answers before interacting with an address.

Soon, we're releasing an update that improves how risk signals are interpreted in Lite Mode while keeping the experience just as simple.

The update introduces clearer risk levels, a new visual risk indicator, and consistent scoring across AMLBot modes.

“Lots of crypto users don’t need a full compliance platform — they just need a quick and reliable way to understand wallet risk. Lite Mode makes that possible. This update improves how those risk signals are interpreted while keeping the experience simple and accessible for everyday users.” Slava Demchuk, CEO of AMLBot

Three Risk Levels 

Previously, Lite Mode displayed wallet risk in a simplified format with two possible outcomes:

• Low Risk
• High Risk

While this approach worked well for quick checks, some situations required a more nuanced signal.

With the update, Lite Mode now uses three risk levels:

• Low Risk
• Medium Risk
• High Risk

This additional level helps users better understand whether a wallet represents minimal exposure, potentially suspicious activity, or clearly elevated risk.

The result is a more precise interpretation of wallet risk without adding complexity to the interface.

Understanding Risk Signals

Lite Mode continues to provide the essential signals needed for a quick wallet screening.

Each check highlights connections that may indicate different levels of exposure, including:

1) Trusted Сonnections

Examples may include interactions with:

• Exchanges
• Markets
• Recognized services

These signals often indicate normal ecosystem activity.

2) Suspicious Сonnections

These may include links to services or infrastructure that require closer attention, such as:

• Infrastructure-as-a-service providers
• Decentralized exchange contracts
• Unidentified services

These signals do not necessarily mean the wallet is malicious, but they can indicate activity worth reviewing.

3) Danger Сonnections

These are stronger risk indicators and may include exposure to:

• Sanctioned entities
• Dark market services
• Other high-risk categories

These connections are key signals used when determining higher risk scores.

Events and Entity Signals

Starting now, Lite Mode surfaces entity labels and events connected to the wallet, giving users additional context about activity patterns.

Examples now may include interactions with:

• Exchanges such as Binance, Bybit, or KuCoin
• Cross-chain bridges and DeFi services
• Trading platforms and crypto infrastructure

These insights help users understand where funds may have moved within the broader crypto ecosystem.

Consistent Risk Scoring Across AMLBot

Another important improvement is scoring consistency across the AMLBot platform.

📌 Lite Mode now uses the same risk scoring algorithms that power Pro and Pro+.

This means risk signals are now evaluated using the same underlying model across all AMLBot modes, ensuring consistent interpretation of wallet risk.

Importantly, the amount of available information in Lite Mode remains the same. The update focuses on how risk signals are presented and interpreted, not on adding new datasets.

Built for Individuals

Lite Mode continues to focus on simplicity and accessibility.

It is ideal for users who:

• Perform fewer than ±50 wallet checks per month
• Want quick wallet screening before interacting with an address
• Prefer simple signals instead of complex compliance dashboards

Lite Mode still includes one free AML Check upon registration, allowing anyone to test the platform before purchasing additional checks.

Additional checks remain available in bundles starting.

Simplicity — Now With Clearer Risk Signals

Lite Mode continues to deliver exactly what it was designed for: essential crypto risk screening without unnecessary complexity.

The new update simply makes wallet risk easier to understand and consistent across the AMLBot ecosystem.

For individuals who want a straightforward way to check crypto risks before interacting with a wallet — Lite Mode remains the easiest place to start.

Crypto scam losses reached an estimated $12 billion in 2024, and in 2025 that number climbed past $14 billion on-chain. The trend heading into 2026 is clear: crypto fraud is growing faster than the crypto market itself.

While scammers often tailor their approach to older adults and people with limited technical experience, anyone can be a victim – even high-end finance professionals. Evidently, in 2023, Shan Hanes, CEO of Heartland Tri-State Bank in Kansas and a former board member of the American Bankers Association, embezzled $47.1 million from his own bank after falling for a pig butchering scam. The patterns repeat, the mechanics evolve, and the sophistication of scams keeps rising, especially with the rise of generative AI.

This article breaks down the most common crypto scam types in 2026, the warning signs that cut across all of them, and a concrete checklist you can use before sending any funds.

Why Crypto Scams Are Increasing in 2026

Several structural factors are making 2026 a particularly dangerous year for crypto fraud.

Blockchain transactions are irreversible. Once funds leave your wallet, there's no bank to call and ask for chargeback. This makes crypto the ideal payment medium for scammers – the moment a victim sends funds, recovery becomes extremely difficult. The pseudonymous nature of wallet addresses means the person receiving your money may be impossible to identify without specialized blockchain analysis.

Then there's the AI factor. Generative AI tools have made scam operations dramatically more scalable and convincing. Chainalysis reported that AI-enabled scams generated an average of $3.2 million per operation in 2025, roughly 4.5 times the revenue of traditional fraud schemes.

The DeFi ecosystem adds another layer of risk. Smart contracts interact with user wallets in ways that most people don't fully understand. A single malicious token approval can grant a contract permission to drain an entire wallet. The speed of these transactions, often completed in minutes or even seconds, gives victims no window to react.

Social engineering ties all of these together. Modern crypto scams rely less on technical exploits and more on manipulating human decision-making – creating urgency, faking authority, and building trust over weeks or months before directing victims to fraudulent platforms.

Most Common Types of Crypto Scams

Understanding how different scam structures work makes them easier to recognize early. Most crypto fraud falls into a handful of repeating categories, each targeting a different point in the decision-making process.

Phishing and Wallet Drainer Attacks

Phishing in crypto works differently from traditional email phishing. The goal isn't usually to steal a password – it's to get you to sign a malicious transaction. Wallet drainer attacks typically appear as fake airdrop claims, NFT minting pages, or DeFi protocol interfaces. The user connects their wallet, approves what looks like a routine transaction, and unknowingly grants the contract permission to transfer all tokens of a given type.

CertiK's 2024 security report recorded over $1.05 billion in losses from phishing attacks across 296 on-chain incidents – a 331.03% increase from 2023. While wallet drainer losses dropped 83% in 2025 (to around $84 million, down from $494 million in 2024), the drainer ecosystem remains active and the attack pattern is still common.

Address poisoning is a related threat. Scammers send tiny transactions from addresses that look almost exactly like ones the victim has previously interacted with, counting on the victim to copy-paste the wrong address when making future transfers. One trader lost $50 million in USDT to this technique in a single incident in December 2025.

Fake Investment Platforms and High-yield Schemes

These scams promise fixed or guaranteed returns on crypto deposits. The platforms often look polished – professional dashboards, live trading charts, even working chat support. Some even allow small withdrawals to build confidence before locking out users once they deposit larger amounts.

The FBI reported $5.8 billion in crypto investment fraud losses in 2024, making it the largest category of cybercrime by dollar amount. High-yield investment programs remain among the top scam categories by revenue globally. The core mechanics are always the same: promise unrealistic returns that no legitimate investment can deliver, show fabricated gains in a fake dashboard, and make it progressively harder to withdraw.

The mistake users most commonly make here is treating the platform's own interface as proof of performance. A dashboard showing 200% returns means nothing if the platform controls what the dashboard displays.

Romance and Social Engineering Scams

"Pig butchering" scams are the most financially devastating category in crypto fraud. The name comes from the practice of "fattening the pig" – scammers invest weeks or months building a personal relationship with the victim before steering the conversation toward crypto investments. Revenue from these schemes grew 40% year-over-year in 2024.

The human cost goes beyond financial loss. A University of Texas study traced over $75 billion flowing from victims to crypto exchanges through pig butchering between 2020 and early 2024. The UN estimates over 200,000 people are held in forced-labor scam compounds across Southeast Asia, running these operations at industrial scale.

The investment pitch never comes first. The relationship does. By the time money enters the conversation, the victim is emotionally invested and less likely to verify independently.

Impersonation and Deepfake Scams

AI-generated deepfakes have transformed impersonation fraud. Scammers produce realistic video and audio of public figures endorsing crypto investment platforms. An 82-year-old retiree named Steve Beauchamp drained his entire retirement account – over $690,000 – after watching a deepfake video of Elon Musk endorsing a fraudulent investment platform. The scammers used AI to replace Musk's voice and lip movements in a genuine interview.

The threat extends beyond celebrity impersonation. Scammers clone the voices and likenesses of company executives, customer support agents, and even personal contacts.

A 2025 iProov study found that only 0.1% of participants correctly identified all fake media presented to them, which is why you shouldn’t trust what you see and hear without confirming identity through a separate channel. If someone on a video call asks you to send crypto, call them on a number you already have – not the one they provide. If you see a famous public figure endorsing an investment platform, check if the advertiser or the publication channel is legit. 

Fake Exchanges and Withdrawal Freezing Schemes

Some fraudulent platforms don't steal funds immediately. Instead, they operate as seemingly functional exchanges until the user tries to withdraw a meaningful amount. At that point, the platform introduces new "requirements" – tax deposits, verification fees, insurance charges, anti-money-laundering compliance fees. Each payment unlocks a new demand. The funds were never in the user's control to begin with.

The warning sign is any platform that requires additional payments to process a withdrawal. Legitimate exchanges deduct fees from the withdrawal itself – they don't ask you to give them more money to access your own funds.

Rug Pulls and Token Exit Scams

Rug pulls happen when a project's developers drain liquidity or dump their token holdings after building up a community and attracting investment. The frequency of rug pulls dropped 66% in early 2025 compared to the same period in 2024, but the financial impact per incident has grown enormously. Take the Mantra OM token collapse in April 2025, for example. The token fell from $6.35 to $0.37 after 17 wallets moved 43.6 million tokens to exchanges, and that collapse alone accounted for roughly 92% of all rug pull losses in Q1 2025.

Before investing in any token, check whether the smart contract is verified and whether liquidity is locked. If the project team can withdraw all liquidity at any time, they probably will.

Key Warning Signs of a Crypto Scam

Scam structures vary, but the red flags are remarkably consistent. These are the signals worth watching for across every type of crypto fraud:

• Guaranteed returns: No legitimate crypto investment can guarantee profits. Any platform or person promising fixed, risk-free returns is either lying or running a Ponzi structure. This is the single most reliable indicator of fraud.
• Urgency and pressure: Scammers manufacture time pressure because it prevents independent verification. Phrases like "limited spots," "offer expires tonight," or "act now before the price jumps" are psychological triggers, not investment advice. Legitimate opportunities don't disappear because you took a day to think about them.
• Requests for private keys or seed phrases: Legitimate services, exchanges, or support agents will never ask for your seed phrase or private key. Anyone who does is attempting to steal your funds. Full stop. This applies to customer support chats, social media DMs, and even people claiming to be from your wallet provider.
• Unverified or newly registered domains: Scam platforms frequently use domains registered within the past few months. Check domain age through a WHOIS lookup. Cross-reference the domain against the project's official social media channels. If the URL is slightly misspelled, treat it as hostile.
• Sudden platform restrictions on withdrawals: As described in the fake exchange section above, any platform that requires additional deposits to process withdrawals is almost certainly fraudulent. Legitimate exchanges charge withdrawal fees, but they deduct those fees from the transaction – they don't require fresh deposits.
• Untraceable or anonymous team members: Look for real names, verifiable professional histories, and LinkedIn profiles that predate the project by years. AI-generated headshots, pseudonymous founders with no prior track record, and teams with no public presence are all red flags.

If you suspect you've already been affected, see AMLBot’s guide on how to recover stolen cryptocurrency.

Crypto Scam Prevention Checklist

Before investing or sending crypto, ask yourself:

1. Have I verified the domain and company registration? Check domain age, business registration records, and whether the URL matches official sources.
2. Is the project promising unrealistic returns? If it sounds too good to be true for a volatile asset class, it probably is.
3. Have I checked independent reviews? Look beyond the project's own channels. Search for the project name combined with "scam," "complaint," or "withdrawal problems."
4. Am I being pressured to act immediately? If someone is creating urgency around a financial decision, slow down. That urgency is the manipulation.
5. Has anyone asked for my seed phrase or private key? If yes, stop communication. Immediately.
6. Did I independently confirm the person's identity? For any contact recommending an investment, verify their identity through a separate channel.
7. Have I tested with a small transaction first? Before committing significant funds to any new platform, send a minimal amount and confirm you can withdraw it without friction or additional fees.
8. Is the smart contract verified? On-chain verification through a block explorer is a minimum requirement. Unverified contracts can contain hidden functions that drain funds.
9. Do I understand where my funds are going? If you can’t explain the path your crypto takes after you send it, you probably shouldn't be sending it.
10. Would I still invest if I removed emotional pressure? Strip away the relationship, the urgency, and the social proof. If the investment doesn't stand on its own fundamentals, walk away.

What to Do If You Realize It's a Scam

If you suspect you're dealing with a fraudulent platform or person, act quickly. The faster you respond, the more options remain available.

• Stop all communication. Do not respond to further messages from the suspected scammer. Don't explain why you're stopping, and don't engage with any "recovery" offers that come from the same source.
• Secure your remaining funds. If you've shared wallet credentials or signed suspicious transactions, move your remaining assets to a new wallet immediately. Revoke any token approvals you don't recognize using a tool like revoke.cash.
• Document everything. Screenshot all conversations, transaction hashes, wallet addresses, platform URLs, and email exchanges. This information is critical if you pursue blockchain investigation or file a law enforcement report.
• Do not pay "recovery agents." The recovery scam is a second-stage fraud that targets people who've already lost money. Anyone contacting you unsolicited about recovering stolen crypto is likely running another scam. Legitimate blockchain investigation firms don't cold-message victims on social media.

When Professional Blockchain Investigation May Help

In some cases, stolen or scammed funds can be traced on the blockchain. Cryptocurrency transactions are recorded permanently, and depending on the laundering path, it's sometimes possible to follow funds to a regulated exchange where law enforcement can issue a freeze request. In practice, fund tracing and flagging is only the first step in crypto recovery, followed by other measures.

Timing matters. The faster an investigation starts, the less time scammers have to move funds through mixing services, cross-chain bridges, or non-KYC exchanges. Multi-chain laundering schemes are increasingly common – stablecoins now comprise 84% of illicit transaction volume, up from 63% in 2024, and criminals routinely chain-hop to obscure fund flows.

Not all cases are recoverable, and any professional blockchain investigation service will tell you that upfront. Complex schemes involving mixers, privacy coins, or immediate conversion through non-KYC exchanges significantly reduce recovery prospects.

When Crypto Recovery May Not Be Possible

It's worth being honest about the limits. Some situations make fund recovery extremely unlikely:

• If funds have been routed through crypto mixers or privacy-focused protocols, the on-chain trail may be broken beyond what current analysis tools can reconstruct. 
• If funds were immediately converted through a non-KYC exchange, there's no identity information for law enforcement to subpoena.
• If significant time has passed, funds have typically been moved through multiple layers of wallets, swapped across chains, and converted to fiat. Each step reduces the probability of successful tracing and recovery.

Most crypto scams in 2026 are not technically sophisticated. They are psychologically sophisticated. They exploit urgency, trust, authority, and fear of missing out – the same emotional triggers that have powered confidence games for centuries, now amplified by AI-generated voices, faces, and personalities.

The patterns repeat. Guaranteed returns, pressure to act fast, requests for private keys, platforms that take deposits easily but make withdrawals impossible. Recognizing these patterns is the single most effective defense available to any crypto user. 

Prevention is always cheaper than recovery.

-AMLBot Team

FAQ

AMLBot continues to expand its KYT Dashboard capabilities to better support compliance teams in detecting and managing transaction risks. Following the recent introduction of Real-Time Transaction Alerts, which allow businesses to detect and respond to risky individual transactions as they occur, AMLBot now introduces Behavioral Alerts as the next step in monitoring.

While transaction alerts focus on risk at the level of single transfers, behavioral alerts allow compliance teams to detect suspicious activity patterns that emerge across multiple transactions over time. This new capability helps businesses to identify attempts to bypass transaction thresholds, automate pattern detection, and improve customer-level risk visibility. 

The sections below explain why behavioral monitoring is becoming essential in crypto compliance and how this functionality operates within AMLBot’s KYT Dashboard environment.

Why Transaction-Level Monitoring Is No Longer Enough

Transaction Monitoring in crypto has traditionally focused on identifying risk at the level of individual transfers. Transactions are evaluated, exposure is assigned, and alerts are triggered when risk thresholds are exceeded. This model performs well when illicit activity is visible in individual events, such as direct interactions with sanctioned entities, exposure to darknet markets, mixer use, or large transfers from risky sources.

[TX] → Low Risk
[TX] → 🚨
[TX] → Low Risk

However, real-world laundering and fraud rarely occur through single, easily detectable events. In 2026, illicit activity is often structured specifically to avoid threshold-based detection. Funds are split into smaller transfers, distributed over time, routed through indirect exposure chains, or kept consistently below configured alert levels. Each transaction appears acceptable in isolation, yet the overall pattern of behavior reveals considerable risk exposure. 

[TX – Low Risk] [TX– Low Risk] [TX– Low Risk] → Behavioral Rule → 🚨

Compliance Teams need tools that can identify suspicious activity patterns over time rather than merely reacting to individual transactions.

From Transaction Risk to Behavioral Risk

Behavioral Monitoring moves analytical focus from transactions to customer activity patterns. Instead of asking whether a single transaction is risky, the system evaluates whether a customer behaves in a manner consistent with laundering or risk-evading techniques. 

In practice, behavioral alerts operationalize Transaction Monitoring scenarios already defined in a company’s AML and Risk Policies. These scenarios typically describe patterns such as structured deposits, repeated exposure to high-risk ecosystems, or bursts of activity inconsistent with expected customer behavior.

Traditional AML systems in banking have relied on velocity rules, structuring detection, and aggregated behavioral analysis for years. Crypto monitoring tools initially focused on address-level risk scoring. However, as regulatory expectations and compliance practices matured, regulators emphasized the need for ongoing monitoring and detection of unusual transaction patterns rather than analysis of isolated transactions. Guidance from bodies such as FATF, EU AML Frameworks, the FCA, and FinCEN requires crypto businesses to identify unusual or structured-transaction behavior and activity inconsistent with customer risk profiles.

As a result, monitoring systems evolved to incorporate behavioral logic and customizable rule engines that detect transaction patterns over time, not just individual risk events.

Behavioral Alerts in AMLBot KYT Dashboard

In AMLBot’s implementation, transactions remain the primary objects of monitoring. Customers are created automatically when transactions are added to monitoring using a Customer Identifier. Behavioral rules do not operate on wallet addresses or account entities. Instead, they evaluate transactions grouped under each customer identifier. Customers, therefore, function as aggregation containers for transaction activity rather than blockchain identity objects. Transactions belonging to the same customer may originate from any supported blockchain, and behavioral evaluation aggregates activity across chains without distinction. Rules apply globally across monitored customers, but are evaluated separately for each customer.

How Behavioral Rules Are Evaluated

Each time a new transaction enters monitoring, the system automatically checks whether the customer’s recent activity matches any behavioral rules configured by the Compliance Team. Instead of evaluating only the transaction size, the system assesses how much of the transaction is directly associated with the selected risk category. If only part of the funds is linked to risky sources, only that risky portion is counted toward the rule. This allows alerts to reflect actual exposure rather than total transfer amounts, making them easier to justify during compliance reviews. 

Behavioral rules evaluate activity within a rolling time window. For example, a one-hour rule always looks back at transactions added during the previous sixty minutes. Each time a new transaction appears, the system recalculates whether the pattern now meets alert conditions. The timing is based on when transactions enter monitoring rather than blockchain confirmation time, ensuring monitoring reflects real operational conditions.

Note: As for now, rules are checked continuously without cooldown or suppression logic. This means that if suspicious activity continues, multiple alerts may be generated within the same time period. Compliance teams should therefore tune rule thresholds carefully to balance detection sensitivity and alert volume.

Monitor Behavior, Not Just Transfers → Apply to Try Behavioral Monitoring

Example Use Case: Detecting Structured Gambling Exposure

A practical example illustrates how behavioral monitoring closes gaps in detection left by transaction-level alerts. Assume deposit monitoring thresholds for gambling exposure are configured as follows: 

Now consider a customer who performs three deposits within one hour. The first transfer contains 160 USD gambling exposure but does not trigger a transaction alert. The second transfer contains 493 USD gambling exposure and generates a Low-Risk transaction alert. The third transfer contains 378 USD gambling exposure and again produces only a Low-risk event.

When viewed individually, none of these transactions exceeds the thresholds required to trigger higher-severity alerts. Each transfer appears acceptable in isolation, and transaction-level monitoring alone would not flag this customer as risky.

However, behavioral monitoring evaluates activity cumulatively. Instead of analyzing full transaction amounts, the system aggregates only the portion of funds linked to the selected risk category. In this case, the gambling-related exposure accumulated within one hour reaches 1,031 USD.

This indicates a pattern where deposits are structured to remain below configured alert thresholds while still introducing significant exposure to risky ecosystems. To detect such behavior, a behavioral rule can be configured with the following parameters:

• Category: Gambling
• Direction: Deposit
• Alert Grade: High
• Number of Transfers: 3
• Time Period: 1 Hour
• Amount Range, USD: 100–10,000 USD

Each time a new transaction enters monitoring, the system re-evaluates recent customer activity. When the third qualifying deposit is received, the aggregated exposure within the defined time window satisfies the rule conditions, and a High-severity behavioral alert is automatically generated.

This means the alert is triggered not because a single transaction is risky, but because the customer’s behavior indicates a deliberate attempt to avoid detection through transaction splitting.

As demonstrated in the video, the alert appears immediately after the rule conditions are met, and the customer's risk level is updated accordingly, allowing compliance teams to investigate the activity without manually reconstructing transaction history.

Why Behavioral Alerts Matter for Compliance Teams

The Next Stage of KYT Monitoring

The broader trajectory of crypto compliance monitoring is moving from reactive transaction screening toward proactive behavioral risk detection. Instead of evaluating whether a transaction is risky, compliance operations focus on whether a customer’s activity pattern represents risk. 

FAQ

The modern crypto ecosystem spans hundreds of blockchains operating in parallel. Fund flows rarely remain within a single network: assets move between chains through bridges, decentralized exchanges, and wrapped token systems. Each transfer across a network boundary breaks transaction continuity. A movement that starts as ETH on Ethereum may appear on another chain as a wrapped equivalent after routing through liquidity pools and a DEX swap. For teams responsible for transaction tracing explained, these breaks create practical gaps in attribution and reconstruction.

Cross-chain analysis addresses this problem by correlating activity across separate ledgers and reconstructing multi-chain fund flows despite technical discontinuities. This article explains what causes tracing gaps, how cross-chain correlations are established in practice, and why results often carry probabilistic uncertainty.

What Is Cross-Chain Analysis

📘 Cross-chain analysis is the practice of tracing and correlating cryptocurrency transactions across multiple, separate blockchain networks. Unlike the framework described in blockchain analytics explained, which maps fund flows within a single ledger, cross-chain analysis must reconstruct movement that spans two or more independent networks, each with its own data structure, address format, and transaction model.

The distinction matters because the two disciplines operate on different assumptions. Single-chain tracing works within a single continuous ledger, with consistent address formats, referenced outputs, and full wallet history in one place. Cross-chain analysis lacks these conveniences: when assets move from Ethereum to Solana or from Bitcoin to BNB Chain, the deposit on one chain and the withdrawal on another are recorded independently, with no shared identifier linking them.

This is where the flow breaks down. Three structural factors create the discontinuity:

• Incompatible Architectures. Each blockchain uses its own address format and transaction model. Bitcoin's UTXO structure, Ethereum's account-based model, and Solana's runtime share no common schema, making direct cross-chain correlation technically non-trivial.
• Asset Conversion at Network Boundaries. When assets cross chains, their form changes: ETH becomes a wrapped equivalent, BTC becomes WBTC. The new token on the destination chain carries no on-chain reference to its origin.
• Scale of Fragmentation. The more networks involved, the harder the reconstruction. As multi-chain activity expands, cross-network correlations become increasingly complex, increasing the likelihood of attribution gaps across ledgers.

The cumulative result is an attribution gap: the analytical thread that connects a wallet to a real-world entity on one chain does not automatically extend across network boundaries. Cross-chain analysis refers to the structured methods used to re-establish that linkage across independent ledgers.

Why Cross-Chain Movement Complicates Tracing

Fund flow fragmentation is the most immediate problem. A single cross-chain transfer produces separate transaction records on independent ledgers, with no native link between them. When funds move across multiple networks in sequence, the activity exists as distributed fragments that must be aggregated and correlated to reconstruct the full path.

The scale of this problem is measurable: according to 2025 research, cross-chain investigations break down as follows:

• 33% involve more than three blockchains
• 27% involve more than five blockchains
• 20% span more than ten separate networks

Asset conversion at each network boundary deepens the problem. Assets do not cross chains in their native form. They are converted into representations that are technically new tokens on the destination network. ETH becomes a wrapped equivalent; BTC becomes WBTC on Ethereum or BTCB on BNB Chain. Each conversion creates a new token with its own contract address and transaction history, carrying no on-chain reference to the original asset it represents. For an investigator, this means the flow of funds cannot be traced by tracking a single asset. It must be reconstructed across multiple asset types, with their connections maintained off-chain in the bridge protocol's logic rather than in the ledger itself.

Loss of direct transaction continuity follows from both factors above. In single-chain tracing, each transaction links directly to the next through shared addresses or referenced outputs. Cross-chain transfers break this continuity at every hop. The deposit transaction on the source chain and the mint or release transaction on the destination chain are structurally independent events. They must be correlated through indirect signals, matching values, timing windows, and bridge contract event logs, rather than through any native transactional reference. This inference-based reconstruction introduces uncertainty that direct ledger tracing does not.

Attribution gaps are the cumulative analytical consequence. When an investigator establishes that a wallet cluster belongs to a known entity, that attribution is valid only on the chain where it was built. After a cross-chain transfer to a new network and a fresh address, the established identity does not follow. The destination wallet starts with no transaction history, no connection to known entities, and no behavioral profile. Each hop requires attribution to be re-established on a new network.

The Core Mechanisms Behind Cross-Chain Transfers

Cross-chain movement is not a single technology. It is a family of mechanisms, each operating differently and each creating distinct challenges for transaction tracing. Understanding how assets travel between networks is essential to understanding why reconstruction becomes complex. Three mechanisms dominate the current multi-chain landscape: blockchain bridges, decentralized exchanges, and wrapped token protocols. In practice, these are rarely used in isolation. A single fund flow may pass through all three in sequence.

Blockchain Bridges

📘 Blockchain Bridge is a protocol that enables assets to move between two networks that cannot natively communicate. The dominant architecture is the lock-and-mint model: a user deposits tokens into a smart contract on the source chain, where they are held in escrow. A set of validators or oracles monitors the deposit, confirms it meets the required conditions, and authorizes the minting of an equivalent quantity of tokens on the destination chain. To reverse the process, the minted tokens are burned, and the original assets are released from escrow.

Variations on this model address different technical constraints:

• Burn-and-mint, used by Circle's Cross-Chain Transfer Protocol for native USDC, destroys tokens on the source chain and issues new ones natively on the destination, rather than wrapping them.
• Liquidity-based bridges draw from pre-funded liquidity pools on each supported chain, enabling faster transfers by matching deposits against existing reserves rather than waiting for cross-chain message confirmation.
• Intent-based bridges, used by protocols such as Across, invert the flow entirely: users declare a desired outcome and competitive relayers fulfill the order, with settlement occurring after the fact.

Bridge protocols also differ in their trust architecture. Custodial bridges rely on an intermediary, such as a validator set, multisig group, or centralized custodian, to authorize transfers. Wrapped Bitcoin (WBTC), for example, relies on BitGo to hold the underlying BTC. Non-custodial bridges rely instead on cryptographic verification: smart contracts validate cross-chain messages using mechanisms such as Merkle proofs, light clients, or zero-knowledge proofs.

For tracing purposes, the distinction is structural. Custodial bridges may maintain off-chain records to support correlation, while non-custodial bridges rely solely on cryptographic validation and do not introduce additional identity metadata beyond what the blockchain itself records.

Decentralized Exchanges and Routing

Decentralized exchanges (DEXs) enable token swaps without a central intermediary. Most operate on an Automated Market Maker (AMM) model, executing trades against liquidity pools, smart contracts holding token reserves, without account registration or identity verification.

From a tracing perspective, the primary effect is asset transformation. A fund flow entering a DEX as ETH may exit as USDC, DAI, or another token, altering the asset profile even if the transaction remains on the same chain. Multi-step routing increases this complexity. DEX aggregators such as 1inch distribute a single swap across multiple venues and intermediate tokens to optimize execution, meaning one user transaction may internally contain multiple swaps across several liquidity pools.

Even in the absence of deliberate evasion, multi-hop routing fragments the transaction trail and changes asset types, complicating cross-network value correlation. When combined sequentially with bridging mechanisms, these processes materially increase the analytical complexity of reconstruction.

Wrapped Tokens and Asset Representation

A wrapped token is a synthetic representation of an asset from one blockchain issued on another network. It enables value from a non-compatible chain, such as Bitcoin, to circulate within a smart contract ecosystem such as Ethereum. The original asset is held in custody (by a smart contract or centralized custodian), and a corresponding token is issued at a 1:1 peg.

Common Examples:

• Wrapped Bitcoin (WBTC) – an ERC-20 token backed by BTC held by a custodian;
• Wrapped Ether (wETH) – a tokenized representation of ETH conforming to the ERC-20 standard.

Multiple wrapped variants of the same asset may exist across different chains, each with distinct custody and issuance models:

• WBTC – ERC-20 on Ethereum, custodied by BitGo;
• renBTC – formerly issued via Ren Protocol;
• tBTC – backed by a decentralized threshold network;
• BTCB – issued on BNB Chain.

The analytical challenge is structural: the wrapped token and the original asset are separate on-chain objects with no native ledger link. WBTC on Ethereum has its own contract address and transaction history, neither of which appears in the Bitcoin Ledger. The relationship between the locked BTC and circulating WBTC exists within the bridge or custodian framework rather than within either blockchain’s native data.

Correlation across this boundary depends on identifying the relevant lock, mint, or custody relationship and reconstructing the connection across ledgers. When multiple wrapped variants are involved, each representation must be evaluated independently. There is no unified cross-chain view of a single underlying asset.

Cross-Chain Tracing Techniques

Because no native link connects events across separate blockchains, cross-chain tracing relies on correlation rather than direct ledger continuity. Investigators evaluate multiple signals to determine whether activity on one network corresponds to activity on another. These signals differ in strength and reliability.

One foundational indicator is temporal proximity. Cross-chain transfers typically produce paired events: a lock or burn on the source chain and a mint or release on the destination. These occur within a constrained time window defined by bridge design and confirmation requirements. Temporal alignment narrows potential matches but does not, in itself, establish linkage.

Transaction value provides an additional signal. The amount received on the destination network generally reflects the source amount minus protocol and gas fees. Because bridge fee structures follow defined rules, expected outputs can be estimated. Alignment between the timing and the adjusted value strengthens the correlation, though the result remains probabilistic.

When bridge contracts publish structured event logs, contract-level data can support a more direct linkage. Some architectures emit cross-chain message identifiers that appear in both source and destination records, enabling stronger forms of matching. In their absence, correlation relies on indirect indicators.

Liquidity-based bridges introduce further complexity. Transfers are fulfilled from pooled reserves rather than paired deposit-withdrawal events, meaning no single on-chain transaction directly corresponds to another. In such systems, correlation depends on evaluating liquidity inflows, outflows, and rebalancing behavior over time. Conclusions are inherently statistical.

Once funds arrive on a destination network, analysis extends to identifying exit points. Subsequent transfers may lead to centralized exchanges, OTC services, or other identifiable counterparties. Because destination addresses are often newly created, behavioral context becomes relevant, including rapid onward transfers, asset conversion through decentralized routing, or dispersion across multiple wallets. When funds intersect with a Regulated Virtual Asset Service Provider (VASP), the reconstructed flow may connect to the entity's identity records.

Cross-chain tracing, therefore combines temporal, quantitative, structural, and behavioral indicators to produce an inferential reconstruction that must be interpreted within defined confidence levels.

Common Multi-Chain Laundering Patterns

Documented investigations and blockchain intelligence research have identified recurring patterns that exploit structural properties of the multi-chain environment.

Chain hopping is the foundational pattern. It involves moving assets across multiple blockchains in sequence, with each transfer generating a new address, asset format, and transaction history on a separate ledger. Each network crossing requires re-establishing attribution, increasing analytical complexity. Industry research and documented investigations identify chain hopping as a recurrent laundering typology in multi-chain cases.

Two structural variants are commonly observed. Sequential hopping moves funds linearly from one chain to another. Parallel hopping splits a balance across multiple chains simultaneously before recombination at a later stage, requiring concurrent analysis across networks.

Bridge-to-DEX Routing combines network transfer and asset conversion in close succession. Funds are bridged to a destination chain and then passed through decentralized exchange swaps. The bridge changes the network context; the swap alters the asset type. As a result, both the address trail and the asset trail are disrupted, and correlation must account for independent structural changes across chains and token formats.

Rapid network switching refers to the tempo of movement rather than its structure. Funds may traverse multiple chains within short time intervals, compressing the window available for monitoring and review. The speed of execution increases the difficulty of real-time detection and correlation across systems that operate with indexing and attribution latency.

Asset fragmentation across chains reduces transaction visibility from a tracing perspective. Instead of moving a large balance in a single transfer, funds are divided into smaller amounts and distributed across multiple networks. On any individual chain, the transactions may appear unremarkable in isolation. Reconstructing the full flow requires aggregating activity across networks and identifying common origin patterns.

In practice, these patterns frequently appear in combination. Fragmentation may precede chain hopping; bridge-to-DEX routing may follow a network transfer; rapid switching may compress the entire sequence into a short timeframe. The analytical challenge lies not in recognizing an isolated tactic, but in identifying the composite structure across chains and asset types simultaneously.

Cross-Chain Analysis vs Standard Transaction Tracing

Transaction Tracing in crypto and cross-chain analysis share the same investigative objective but operate under materially different conditions. They rely on different data environments, apply different correlation methods, and produce conclusions with different evidentiary characteristics.

Standard transaction tracing occurs within a single blockchain. Transactions reference prior outputs, addresses follow a consistent format, and wallet history is maintained in a single continuous ledger. Investigators work within a unified record that can be traversed forward or backward without crossing technical boundaries.

Cross-chain analysis operates across multiple independent ledgers that share no native interoperability. Rather than traversing a single graph, investigators correlate discrete events recorded on separate networks. The two approaches differ across several structural dimensions:

• Data Scope – single-chain tracing evaluates activity within one ledger; cross-chain analysis aggregates activity across multiple independent networks.
• Transaction Continuity – within one chain, continuity is ledger-native; across chains, relationships must be inferred.
• Address Structure – formats remain consistent within a single network; across networks, incompatible schemas require separate handling.
• Asset Identity – the asset being traced remains stable in single-chain analysis; in cross-chain movement, asset representation may change at each network boundary.
• Attribution Confidence – single-chain conclusions rely on native transaction references; cross-chain conclusions depend on the strength of multi-network correlation.
• Analytical Complexity – single-chain tracing involves linear graph traversal; cross-chain analysis requires multi-ledger reconstruction with uncertainty compounding at each hop.

The difference is therefore not only technical but probabilistic. Single-chain tracing rests on directly recorded ledger relationships. Cross-chain analysis reconstructs relationships across systems that do not natively reference one another. Each additional network boundary introduces correlation risk, and confidence levels must be assessed accordingly rather than assumed to be ledger-native.

Limitations and Analytical Challenges

Cross-chain tracing operates under structural constraints that no methodology fully eliminates. Investigators must understand not only what can be established, but also where conclusions become probabilistic rather than definitive. Regulatory guidance reflects this reality.

The Financial Action Task Force (FATF), in its Updated Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers (2023), states that jurisdictions and obliged entities must assess “the technological features that may enable anonymity or obfuscation of virtual asset transfers.” In practical terms, this includes cross-chain routing, bridge usage, and multi-network transfers that fragment transaction records. Compliance programs are therefore expected to evaluate such activity as part of ongoing monitoring, even where technical linkage is inferential rather than deterministic.

Incomplete visibility remains a primary limitation. No analytics platform monitors every active blockchain. While leading systems track dozens of networks, the broader ecosystem includes hundreds of chains, including newer Layer 2 and application-specific environments. Any fund flow that passes through an unmonitored network creates a gap that cannot be reconstructed solely through inference.

Bridge opacity introduces further constraints. Protocols vary widely in the quality of on-chain documentation they provide. Some emit structured and consistent event logs, enabling stronger correlation. Others rely on incomplete documentation, off-chain custodial records, or liquidity-pool mechanisms that do not pair deposits with specific withdrawals. In such cases, reconstruction depends on statistical inference rather than deterministic linkage.

Transaction volume creates additional complexity. High-throughput bridge protocols generate large numbers of potential candidate matches within plausible timing windows. As volume increases, the probability of false correlations rises. Revisions to previously reported illicit volume estimates over the past few years illustrate the difficulty of precise attribution at scale when cross-chain activity is incorporated into analysis.

False correlations represent the central analytical risk. Where linkage is based on timing and value alignment rather than a shared cross-chain identifier, conclusions are inherently probabilistic. Academic research on well-documented EVM-compatible bridges has shown high deposit-matching rates but lower withdrawal rates, demonstrating that, even under favorable conditions, attribution is not exact. Across heterogeneous chains or less transparent bridge architectures, confidence declines further.

Uncertainty compounds with each additional network boundary. A reconstruction spanning multiple chains aggregates the confidence level of each hop, meaning overall attribution reliability decreases as the path length increases. Cross-chain analysis, therefore, produces evidentiary conclusions that require explicit confidence assessment rather than assumption of ledger-native certainty.

When Cross-Chain Analysis Escalates to Investigation

Routine cross-chain monitoring generates risk signals, most of which resolve through standard compliance review. Escalation to formal investigation occurs when the overall structure of multi-chain activity suggests deliberate obfuscation rather than ordinary bridge or DeFi usage.

Indicators that may warrant escalation include rapid movement across multiple networks, bridge withdrawals to newly created addresses followed by immediate onward transfers, fragmentation of funds across chains, routing through high-risk protocols, or interaction with sanctioned or previously flagged entities. No single factor is determinative; escalation decisions should be based on the overall structure of cross-chain fund flows.

Once escalation is initiated, the analytical objective shifts from monitoring to structured reconstruction. The workflow centers on assembling the complete multi-chain path and correlating bridge events, asset transformations, and address clusters across all involved networks. The reconstruction must identify intermediate addresses, asset conversions, and exit points, and document the confidence level for each cross-chain linkage.

The next phase involves counterparty identification. Where funds intersect with exchanges, OTC services, or other virtual asset service providers (VASPs), those entities may become the focus of compliance inquiries or formal legal requests. At this stage, analytics transitions into the broader crypto scam fund tracing process, which integrates technical reconstruction with regulatory reporting and legal coordination.

Because cross-chain linkage is inferential rather than ledger-native, evidentiary preparation is critical. Investigative documentation should record the methodology applied, the analytical basis for each correlation, alternative interpretations considered, and the limitations affecting confidence levels. Courts and regulators increasingly scrutinize how cross-chain attribution conclusions are reached, and overstating certainty introduces material evidentiary risk.

Cross-chain investigation, therefore, requires not only technical reconstruction but disciplined documentation capable of supporting regulatory or judicial review.

Tools Used in Cross-Chain Analysis

Effective cross-chain analysis depends on infrastructure capable of ingesting heterogeneous blockchain data, correlating activity across independent ledgers, and monitoring bridge activity in real time. Three core capabilities define this tooling environment: multi-chain data aggregation, cross-network graph correlation, and bridge monitoring systems.

Multi-chain data aggregation forms the foundational layer. Transaction data from each supported network must be collected, decoded, and normalized into a unified schema before correlation can occur. While EVM-compatible chains share structural similarities, non-EVM networks require separate ingestion and normalization pipelines. The output is a consolidated multi-chain dataset that enables cross-network queries without manual reconciliation across separate explorers.

Cross-network graph correlation builds on this aggregated data. Address graphs are constructed across all monitored chains, allowing bridge deposits and corresponding withdrawals to be linked within a unified analytical environment. Once stitched together, fund flows can be traversed across network boundaries as a single reconstructed path. Entity attribution layers, including labeled exchanges, sanctioned wallets, and high-risk services, are incorporated into the graph to identify counterparty risk when fund flows reach known entities.

Platforms implementing this capability vary in coverage depth and supported networks. Commercial systems integrate multi-chain ingestion, correlation engines, and attribution databases into a single environment. Tools such as the AMLBot Tracer provide cross-network visualization of fund flows and case mapping across major blockchain ecosystems.

Bridge monitoring systems complement correlation engines by indexing lock, mint, burn, and release events as they occur. Real-time surveillance of bridge contracts enables risk scoring at the point of transfer rather than after funds have moved further downstream. These systems maintain protocol-level intelligence, including event schemas and fee structures, which support more accurate cross-chain matching.

Open-source tools and academic frameworks also contribute to the ecosystem, offering transparent methodologies for clustering and bidirectional tracing where independent verification is required.

Conclusion

The multi-chain ecosystem is no longer transitional. It is the operating structure of modern crypto markets. Assets move routinely across independent networks through bridges, decentralized exchanges, and wrapped asset protocols. Tracing that activity now requires navigating a fragmented, cross-ledger environment as a matter of course.

Cross-chain analysis has therefore become a core component of modern blockchain analytics. Monitoring a single network in isolation produces an incomplete reconstruction whenever assets cross chain boundaries. In a landscape where multi-chain routing is routine, single-chain visibility is insufficient.

Cross-chain analysis does not eliminate uncertainty, but it restores continuity. It provides a structured method for correlating activity across networks that do not natively reference one another. Without it, tracing may stop at the first bridge boundary. With it, investigators can reconstruct fund flows across the full multi-chain path and assess risk exposure across the environments where value actually moves.

In a multi-chain ecosystem, cross-chain capability is necessary for tracing that seeks to reconstruct fund flows across network boundaries.

-AMLBot Team

FAQ

Travel Rule violations are the most commonly cited infraction under the Bank Secrecy Act (BSA) — the primary US Anti-Money Laundering Law — identified by the Internal Revenue Service (IRS) during examinations of Money Services Businesses (MSBs) engaged in convertible virtual currency transmission. (Source: Kenneth A. Blanco, FinCEN Director, Blockchain Symposium, March 15, 2019) Understanding exactly what compliance requires, and where gaps typically appear, starts with the rule itself.

The United States applies the Travel Rule to crypto transfers through regulations administered by the Financial Crimes Enforcement Network (FinCEN). Crypto businesses classified as MSBs must comply with specific data collection, recordkeeping, and information transmission obligations under the Bank Secrecy Act framework.

As a result, the US Crypto Travel Rule functions as a mandatory component of AML Compliance for companies facilitating convertible virtual currency transfers, building on the broader FATF Crypto Travel Rule Framework that established the global standard later adopted and adapted by national regulators worldwide.

Legal and Regulatory Basis of the US Crypto Travel Rule

The US Crypto Travel Rule forms part of the mandatory Anti-Money Laundering obligations established under the Bank Secrecy Act (BSA) and enforced by the Financial Crimes Enforcement Network (FinCEN). These requirements are legally binding for financial institutions operating in the United States, including crypto businesses that qualify as Money Services Businesses when they transmit value on behalf of customers.

In regulatory terms, the framework operates through two connected mechanisms codified in federal law:

• Recordkeeping Rule (31 CFR §1010.410(e)). It requires financial institutions to collect and retain specified information for funds transfers of $3,000 or more.
• Travel Rule provision (31 CFR §1010.410(f)). It requires that this information accompany the transfer and be transmitted to the next financial institution involved in processing the transaction.

(Source: FinCEN and Federal Reserve Board, Joint Final Rule, January 3, 1995, codified at 31 CFR 1010.410(e) and 31 CFR 1010.410(f). Full text available via eCFR: ecfr.gov)

In practical terms, when a regulated institution executes a crypto transfer for a customer, it must:

This structure ensures transaction data remains accessible throughout the payment chain and can be obtained by regulators or law enforcement when investigating suspicious activity.

Although these rules were originally designed for traditional banking payments, FinCEN later clarified that they also apply to businesses dealing with convertible virtual currencies. In its May 9, 2019 guidance on virtual currency business models, the agency explained that no new obligations were introduced; instead, existing AML requirements already applied to crypto businesses engaged in money transmission activities.

As a result, qualifying crypto transfers are treated under US law in the same manner as traditional wire transfers for AML purposes. While US regulation uses terminology such as “convertible virtual currency” and “Money Services Business,” and international standards refer to “Virtual Assets” and “VASPs,” the operational consequence is the same: intermediaries facilitating value transfers must comply with identical AML recordkeeping and information-sharing obligations.

Who Must Comply Under US Law

Not every company operating in the crypto market automatically falls under Travel Rule obligations. Compliance depends on whether a business performs activities that qualify as money transmission under US law. This section explains how crypto businesses are classified and when regulatory obligations arise.

Crypto Businesses Classified as Money Services Businesses (MSBs)

Under FinCEN regulations, a Money Services Business (MSB) includes any entity engaged in money transmission within the United States. Money transmission generally means accepting and transmitting value that substitutes for currency on behalf of another person. In its guidance (FIN-2013-G001 and FIN-2019-G001), FinCEN clarified that this definition applies to certain activities involving Convertible Virtual Currency (CVC), even where no fiat currency is involved.

FinCEN defines CVC as virtual currency that either has an equivalent value in real currency or acts as a substitute for it. When a company accepts and transmits CVC for customers, or buys and sells CVC as a business activity, it may qualify as a money transmitter and therefore as an MSB under the Bank Secrecy Act (BSA).

The decision tree shown above is a simplified analytical flow illustrating how FinCEN’s guidance typically applies in practice. However, regulatory status is ultimately determined through a facts-and-circumstances analysis. Classification depends on what a company actually does operationally — not how it labels its services or structures its branding.

Businesses Commonly Falling within the MSB Classification Include:

Importantly, companies cannot generally avoid MSB status by describing themselves as software providers if, in substance, they accept and transmit value on behalf of users. Functional activity, not marketing language, determines regulatory treatment.

Where an entity qualifies as a Money Transmitter MSB, it becomes subject to BSA obligations, including registration, AML Program requirements, recordkeeping duties, and the Funds Transfer Recordkeeping and Travel Rule requirements under 31 CFR 1010.410(f). In this sense, Travel Rule compliance is a consequence of MSB status rather than a standalone crypto-specific obligation.

When a Crypto Company Is Considered a Money Transmitter

A crypto company is generally considered a money transmitter when it accepts and transmits value from one person or location to another on behalf of customers. The regulatory trigger is operational activity, not corporate labels or technical architecture.

In practical terms, a company may be considered a money transmitter when it:

• Accepts cryptocurrency from one customer and transfers it to another party,
• Processes payments or transfers on behalf of users,
• Controls or manages transfers involving customer funds,
• Facilitates transactions in which value is transmitted between parties via the platform.

By contrast, individuals or businesses using cryptocurrency solely to purchase goods or services for themselves are not considered MSBs. Personal or internal use of crypto does not constitute money transmission because no service is provided on behalf of third parties.

FinCEN enforcement practice shows that Travel Rule obligations are actively monitored during routine supervisory examinations. Regulatory examinations conducted through delegated examiners have repeatedly identified Travel Rule compliance failures among crypto businesses engaged in money transmission, demonstrating that these requirements are not theoretical but part of ongoing supervisory activity.

Once classified as an MSB, a crypto company becomes subject to several obligations, including:

• Registration with FinCEN as a Money Services Business;
• Implementation of a written AML Compliance Program;
• Filing of Suspicious Activity Reports (SAR) where required;
• Compliance with recordkeeping and Travel Rule requirements for qualifying transactions.

Information Requirements for Crypto Transfers

When a Money Services Business processes a transmittal of funds that reaches or exceeds $3,000, specific data collection and retention obligations arise under the Bank Secrecy Act and related regulations. In regulatory terms, a transmittal of funds is a transfer of value conducted on behalf of a customer, and once this threshold is reached, a regulated institution must obtain and retain all required information before, at, or during execution of the transaction.

For each qualifying transmittal order, the MSB must collect and retain:

• The originator’s Name and Address;
• The originator’s account number, if the transfer is conducted through an account;
• The amount of the transmittal order and the execution date;
• The identity of the recipient’s financial institution.

This information forms the core of what regulators refer to as “originator information.” In practice, originator information identifies the person initiating the transfer and the basic transaction details that allow law enforcement and AML professionals to trace value flows through the financial system.

For beneficiary information, the institution must likewise collect:

• The beneficiary’s Name and Address;
• The beneficiary’s account number, when applicable;
• Any other specific identifier of the recipient that is received with the transmittal order.

Collecting both originator and beneficiary information forms part of the institution’s core responsibility as an MSB. Where information is passed from one regulated institution to another, each covered institution is responsible for retaining and transmitting the required data in accordance with the Travel Rule’s obligations.

The $3,000 threshold represents the point at which the full data collection and transmission obligations are triggered. Transfers below this level do not automatically trigger the full Travel Rule transmission requirements, but MSBs must still retain transaction data as part of their overall AML compliance and recordkeeping duties.

Source: Federal Register, NPRM October 27, 2020 + FFIEC BSA/AML Manual, Funds Transfers Recordkeeping

The regulations do not mandate a specific method for collecting or verifying this information, leaving MSBs flexibility in implementation. However, the rule does not permit the use of coded names or pseudonyms that obscure customer identity. Abbreviated names or trade names may be acceptable when used in a manner consistent with the institution’s legal recordkeeping and verification practices.

Source: Federal Register Notice, November 28, 2003 — Expiration of CIF Exception

In December 2020, FinCEN proposed requirements for banks and MSBs to verify customer identity and report transactions involving unhosted wallets (RIN 1506-AB47). This proposal was officially withdrawn in August 2024. A separate October 2020 NPRM proposing to lower the Travel Rule threshold from $3,000 to $250 for cross-border transactions has not been finalized and remains under consideration. Neither proposal forms part of the Travel Rule obligations that apply today.

Source: Unhosted wallets NPRM (Withdrawn): Treasury.Gov Press Release + Consumer Financial Services Law Monitor — Withdrawal Notice. Threshold NPRM (Still Pending): Federal Register, October 27, 2020

Recordkeeping and Transmission Obligations

Once a crypto business qualifies as an MSB and a transfer triggers Travel Rule obligations, compliance is not limited to collecting customer data. The regulations also require MSBs to retain specified records and, when another financial institution is involved, transmit required information so it can “travel” through the payment chain.

Recordkeeping Requirements

For covered transmittal orders, a financial institution must retain either the original or a microfilm, other copy, or electronic record of the required information. The rules are format-neutral, but the record must remain accessible for regulatory examination.

Record retention is generally aligned with the BSA recordkeeping standard for funds transfer records, and institutions are expected to retain these records for 5 years.

Records must also be organized to allow efficient retrieval. At a minimum, information must be retrievable by reference to the originator’s name, and where the originator is an established customer using an account for funds transfers, records must also be retrievable by account number.

Importantly, recordkeeping is an independent obligation. Even if operational or technical issues prevent successful transmission to the next institution, the originating MSB must still retain a complete record of the information it was required to obtain and maintain.

Transmission Obligations Between Crypto MSBs

Where a transfer involves more than one financial institution, the Travel Rule requires the originator’s bank or transmittor’s financial institution to include required information in the payment or transmittal order sent to the next financial institution in the chain.

Intermediary institutions also have continuing obligations: to the extent required information is received, an intermediary financial institution must pass it forward to the next institution in the payment chain, preserving continuity of identifying information across the transfer process.

MSBs remain responsible for the completeness and quality of the information they collect from their own customers and introduce into the transfer process. The regulations do not prescribe a single verification method, but they are designed to prevent identity obfuscation and ensure that required information is not replaced with coded names or pseudonyms.

FinCEN has not mandated a specific technical protocol for information exchange between crypto MSBs. As a result, market participants have developed interoperable approaches and data standards to support compliance (for example, IVMS 101 as a common data model and industry networks for exchanging Travel Rule information).

Operational Challenges in Travel Rule Compliance

Implementing Travel Rule obligations presents practical operational challenges for crypto businesses subject to US AML compliance requirements. The main difficulty lies in integrating Travel Rule processes into existing AML monitoring systems while preserving transaction speed and operational efficiency. In practice, MSBs must ensure that transactions reaching regulatory thresholds are correctly identified, that required customer information is collected at the appropriate stage, and that necessary information can be securely transmitted to counterparty institutions.

Identifying transaction counterparties remains one of the most complex operational tasks. Unlike traditional banking, where standardized identifiers enable routing between institutions, the crypto ecosystem lacks universally adopted mechanisms for counterparty identification. When processing outbound transfers, an MSB must determine whether the receiving address belongs to another regulated institution or to a self-hosted wallet and, if another institution is involved, how the required information should be transmitted securely.

Although industry initiatives and technical standards have emerged to facilitate Travel Rule data exchange, interoperability challenges persist. Institutions often rely on different technical solutions, making automated information exchange difficult when counterparties operate on incompatible systems. As a result, transfers may require manual intervention or additional verification, increasing operational workload and sometimes slowing transaction execution.

Regulatory risk further amplifies these operational difficulties. Non-compliance can expose crypto businesses to enforcement action not only from federal authorities but also from state regulators, who increasingly scrutinize AML compliance programs. Enforcement actions in recent years demonstrate that failures in key compliance areas can result in significant financial penalties and supervisory consequences, particularly where deficiencies involve:

• Customer Due Diligence,
• Transaction Monitoring,
• Or improper handling and transmission of required data.

Technical errors in data collection and transmission also remain common sources of compliance risk. Institutions frequently encounter challenges due to inconsistent name formatting, differences in address verification, or incompatible character sets across systems. Such mismatches may delay, reject, or process transfers without complete information, creating compliance gaps even when institutions attempt to meet regulatory expectations.

Operational uncertainty also persists when transactions involve self-hosted wallets. In these situations, institutions may be unable to confirm whether a counterparty is another regulated entity, often requiring additional internal controls or enhanced due diligence procedures that slow transaction processing and increase compliance costs. Many of these operational frictions reflect broader industry-wide Crypto Travel Rule Implementation Challenges, particularly where regulatory expectations intersect with evolving technical infrastructure.

Practical Compliance Priorities for US Crypto Businesses

Crypto businesses subject to the US Crypto Travel Rule must translate regulatory requirements into consistent operational practices. In practical terms, compliance depends less on isolated technical solutions and more on the strength of internal controls, procedural discipline, and readiness to demonstrate compliance efforts during regulatory examinations.

A first priority is ensuring proper MSB registration and regulatory status assessment. Businesses must regularly evaluate whether their activities constitute money transmission under US law and confirm that they meet and maintain their registration obligations with FinCEN. Failure to register or maintain registration can itself become grounds for enforcement action.

A second priority is maintaining a written AML compliance program tailored to crypto-specific risk exposure. Programs must reflect the nature of the company’s products, customer base, transaction flows, and geographic exposure rather than relying on generic templates developed for traditional financial institutions.

Operational compliance also requires systems and procedures capable of identifying transactions that trigger Travel Rule obligations and ensuring required customer data is collected before transfers are executed. Monitoring systems must support timely reporting of suspicious activity and enable compliance teams to intervene when transactions present elevated risk.

Documentation readiness represents another critical compliance element. Institutions should maintain records demonstrating not only successful compliance actions but also efforts undertaken when required information cannot be obtained or transmitted due to technical or counterparty limitations. Maintaining evidence of compliance attempts can become essential during supervisory reviews or enforcement investigations.

Effective compliance also depends on staff training and procedural consistency. Employees responsible for processing transactions must understand: when customer information must be collected, what information must be retained and transmitted, and how to document exceptions or operational failures.

Regular training updates help ensure that compliance procedures remain consistently applied as operational practices and regulatory interpretations evolve.

Finally, crypto businesses relying on external service providers must maintain oversight of outsourced compliance functions. Even where technology vendors support data exchange or monitoring processes, responsibility for compliance remains with the regulated institution. Firms must therefore implement oversight and verification procedures to ensure outsourced systems operate in line with regulatory expectations.

The US Crypto Travel Rule In The Broader Global Context

The US Crypto Travel Rule operates as part of a broader global movement to apply Travel Rule principles to virtual asset transfers. Many jurisdictions are incorporating similar requirements into domestic regulation at different speeds and through different legal mechanisms, but the underlying objective remains consistent: regulated intermediaries must collect and transmit originator and beneficiary information to reduce money laundering and terrorist financing risks in digital asset markets.

As a result, the US model represents one regional implementation among several emerging frameworks worldwide, including approaches now being adopted across Europe and Asia. Businesses operating internationally increasingly encounter multiple regulatory environments, including the EU's implementation of the Travel Rule, as countries continue to adapt global standards to their domestic legal systems.

Conclusion

The US Crypto Travel Rule is a mandatory element of US AML compliance for crypto businesses classified as Money Services Businesses. Through FinCEN’s administration of Bank Secrecy Act obligations, qualifying crypto transfers are subject to defined requirements for collecting originator and beneficiary information, retaining records, and transmitting required data to other financial institutions when applicable. The $3,000 threshold (or its equivalent in convertible virtual currency) serves as the operational trigger for these Travel Rule and recordkeeping duties.

Correct implementation requires more than policy statements. Crypto MSBs must maintain controls that identify covered transfers, capture required customer data at the right point in the transaction flow, and support reliable information transmission and record retention. Because Travel Rule compliance is routinely examined and enforcement actions can involve significant civil penalties, potential criminal exposure in serious cases, and state-level licensing consequences, firms should treat documentation readiness and consistent operational execution as core compliance priorities.

FAQ

A blockchain ledger records every transaction, but it never tells you who is behind an address. It shows that 0x7a3f… sent 14.2 ETH to 0xb8c1…, yet reveals nothing about whether those strings belong to an individual, an exchange, or a sanctioned mixer. Multiply this by the billion-plus addresses across major networks, and the problem becomes clear: raw transaction data without interpretation is just noise.

This is where wallet and entity identification comes in — the process of grouping related addresses into clusters and attributing them to known services or risk categories. Without this layer, blockchain analytics can map fund flows but cannot explain who participates or what risk they carry.

Why Wallets Do Not Equal Entities

A common misconception in blockchain analysis is treating a single address as a single user. The relationship between addresses and the services that control them is far more complex.

Consider Binance, which serves over 250 million registered users. Each user receives at least one unique deposit address per blockchain. Add hot wallets, cold storage, and internal transfer addresses, and a single exchange may control hundreds of millions of addresses. On-chain clustering research identified a major U.S. exchange's Bitcoin cluster at roughly 22+ million addresses — the largest single entity on the network.

On the other end, one person might use multiple wallets across different blockchains or generate fresh addresses for each transaction. The address is a technical artifact. The entity is what gives it meaning.

Address vs. Controlled Infrastructure

Think of how a major exchange operates on-chain. When you deposit Bitcoin, you send funds to a unique address generated for you. But that address is not "yours" — it belongs to the exchange's infrastructure. The exchange sweeps deposits into consolidated hot wallets, which feed cold storage. Withdrawals flow from a different set of wallets entirely.

📘 Hot Wallet — an online wallet used for day-to-day operations like withdrawals. Cold Wallet — offline storage securing the majority of funds.

This pattern — address rotation, deposit sweeping, internal consolidation — is standard across custodial services. The visible addresses change constantly, but the controlling entity remains the same.

Why This Matters for Analysis

Without entity context, a blockchain investigator sees only a web of addresses exchanging value:

So, wallet and entity identification is the foundation that makes tracing actionable and compliance meaningful.

What Is Wallet Clustering?

Wallet Clustering groups multiple blockchain addresses likely controlled by the same user or service into a single analytical unit, transforming the flat address-level view into an entity map.

The concept is straightforward: if you can determine that address A, address B, and address C are all controlled by the same party, you treat them as one entity. The challenge lies in making that determination reliably across billions of addresses.

Conceptual Clustering Logic

Clustering relies on observable patterns in how addresses interact on-chain. The foundational insight — first noted in the 2008 Bitcoin Whitepaper and formalized by Meiklejohn et al. in 2013 — is that transaction structure reveals control relationships.

In Bitcoin's UTXO Model, when multiple input addresses appear in the same transaction, it typically means a single entity controls all of them, because constructing that transaction required access to every input's private key. This behavioral signal, the common-input-ownership heuristic, remains the backbone of Bitcoin clustering.

Beyond input analysis, clustering uses change address detection, wallet software fingerprinting, and temporal behavior analysis. For Ethereum's account-based model, heuristics differ: analysts look at deposit address reuse, airdrop claim behavior, and token approval sequences.

Importantly, clustering does not reveal real-world identity. It identifies relationships between addresses and groups them into logical units. Attribution — connecting a cluster to a service or risk category — is a separate step.

Clustering in the Context of Transaction Tracing

Clustering and tracing are complementary layers. Transaction Tracing follows fund movement from one address to another. Clustering structures the participants along that path.

Imagine tracing 50 BTC from a ransomware payment. Without clustering, you see funds split across dozens of addresses. With clustering, you recognize that 30 of those addresses belong to the same mixing service — and the final destination is a cluster tagged as a known exchange.

From Wallet Clusters to Entity Identification

Once addresses are grouped into clusters, the next step is entity tagging — assigning a label indicating what type of service the cluster represents. A cluster is a set of related addresses; an entity is a cluster with attribution.

Entity categories include centralized exchanges, custodians, DeFi protocols, mixers, darknet marketplaces, sanctioned services, and known threat actors.

Tagging draws on multiple intelligence sources: direct interaction with services, open-source intelligence, law enforcement data sharing, and pattern matching. Leading providers maintain databases mapping over a billion addresses to tens of thousands of real-world entities.

How Entity Tagging Supports Risk Assessment

Entity identification transforms raw blockchain data into actionable risk intelligence. Counterparty risk depends on entity context: a transaction with a regulated exchange carries different risk than one with a ransomware-linked mixer.

Sanctions exposure requires knowing whether any entity in a transaction chain appears on OFAC, EU, or UN lists. The U.S. Treasury's sanctioning of Tornado Cash in 2022 — which had processed over $7 billion, including funds laundered by the Lazarus Group — showed how entity attribution drives regulatory action.

Cross-Chain Attribution Challenges

Entity tagging grows more complex when assets move across blockchains. A user might swap ETH for BTC through a cross-chain bridge, creating a new address on a different network. The entity remains the same, but the on-chain trail breaks.

📘 Cross-Chain Bridge — a protocol enabling asset transfers between different blockchains by locking tokens on one chain and issuing equivalent tokens on another.

Over $7 billion in illicit cryptocurrency has been laundered via cross-chain methods. Major analytics providers have invested heavily — attributing hundreds of millions of cross-chain swaps and tracking dozens of bridges — but cross-chain analysis remains one of the hardest problems in blockchain forensics.

Entity Identification in Scam Investigations

In fraud investigations, entity identification often makes the difference between a dead-end address list and an actionable case. Scam operations rarely use a single wallet — they build infrastructure: collection addresses, consolidation wallets, layering addresses, and off-ramp wallets interacting with exchanges.

The Ronin Bridge hack of March 2022 illustrates this. After $620 million was stolen, blockchain intelligence firms traced funds through dozens of intermediary addresses. Entity tagging revealed that laundering patterns matched behavioral signatures previously attributed to the Lazarus Group — leading to OFAC sanctioning the attacker's wallet and the first-ever seizure of DPRK-stolen cryptocurrency.

Identifying Infrastructure Behind Fraud

If multiple fraud campaigns share deposit addresses at the same exchange cluster or use the same mixer for laundering, the investigation shifts from tracking incidents to mapping an operation. This is where wallet and entity identification intersects with Crypto Scam Fund Tracing.

For investigators tracing stolen assets, AMLBot Tracer provides entity attribution across multiple blockchains — mapping fund flows from theft to off-ramp destination.

Entity Identification and AML Monitoring

For compliance teams at exchanges and financial institutions, entity identification is not a one-time exercise — it is continuous monitoring embedded into every transaction workflow.

Every incoming and outgoing transaction is screened against an entity database. If a deposit originates from a cluster tagged as a high-risk mixer, an alert triggers. If a withdrawal destination is linked to a sanctioned entity, the transaction is blocked.

The FATF's Guidance on Virtual Assets and VASPs (2021) requires service providers to identify counterparties and apply enhanced due diligence for high-risk entities. The FATF itself acknowledges that no proven method exists to identify counterparty VASPs from wallet addresses alone — which is why entity databases play a critical role.

Limitations of Entity Identification

No attribution system is perfect. The "Ghost Clusters" Study (USENIX Security 2025) tested a major provider's data against ground-truth records from seized illicit services. Accuracy ranged from 25% for a mixer to 95% for a darknet marketplace. False positive rates were below 0.5% — analytics rarely misattribute an address, but frequently miss addresses that belong to an entity.

False positives, while rare, carry real consequences. A legitimate user incorrectly clustered with a high-risk entity may find their accounts frozen.

Rapid wallet rotation poses an ongoing challenge. Sophisticated actors generate new addresses for every transaction. Privacy-enhancing technologies — CoinJoin (where multiple users combine transactions), Taproot, and zero-knowledge proofs — add further complexity.

Cross-chain fragmentation compounds these difficulties. When entities operate across dozens of blockchains, maintaining attribution requires correlating activity across different networks — a problem that remains partially unsolved.

The Role of Entity Identification in Modern Blockchain Analysis

Every layer of blockchain analysis depends on entity identification. Transaction tracing without attribution produces a graph of addresses. With entity identification, that graph becomes a map of participants — each carrying risk context that shapes how the investigation proceeds. Investigations without entity context chase addresses. With it, analysts build cases: linking scam infrastructure to known threat actors, identifying off-ramp points, and providing evidence for asset freezing.

AML Monitoring without counterparty identification is compliance theater. Entity attribution transforms it into a risk management function that distinguishes between benign and suspicious activity in real time. Wallet and entity identification is what turns blockchain data from an opaque ledger into an intelligence layer. It is not the final step in an investigation — but it is the step that makes every other step possible.

-AMLBot Team

FAQ

When you look up a wallet on a block explorer, you can see individual transactions — amounts, addresses, timestamps. But that's not the same as understanding where money actually came from or where it ended up. Transaction tracing goes further. It reconstructs the full movement of funds across multiple addresses and transactions, turning raw blockchain data into a coherent fund flow map. This matters because illicit actors rarely move money directly from point A to point B. They route it through chains of wallets, split it, merge it, and mix it with other funds to obscure its origin. 

This article focuses on the mechanics of tracing works — rather than compliance frameworks or legal procedures —the actual process of following crypto from entry to exit.

What Transaction Tracing Actually Means

It's 2013, and a federal agent is staring at a screen full of Bitcoin addresses. He knows Mt. Gox, then the world's largest crypto exchange, is hemorrhaging money. He knows funds are moving. But the blockchain explorer just shows him a wall of hashes — and no story. That gap between seeing transactions and understanding money movement is exactly what transaction tracing was built to close.

Blockchain Analysis isn't one thing. It's a whole spectrum. At the basic end, you've got wallet screening: you take an address, run it through a database, and get back a simple verdict — clean or flagged. One step up is transaction review: you zoom in on a single transfer and ask who sent what to whom, and why that particular transaction looks suspicious. But neither of those tells you the full story. That's where tracing comes in.

When an investigator does a full trace, they're not looking at one address or one transaction. They're rebuilding the entire journey of a sum of money — from the moment it hit the blockchain, through every wallet it passed through, to the point where someone finally tried to cash out.

The old financial crime principle — Follow the Money — translates almost perfectly to crypto. In fact, in some ways it works even better here. Unlike a wire transfer that can be buried in banking records, every on-chain transaction is public, permanent, and timestamped. The difference between screening and tracing comes down to one word: scope. Screening gives you a snapshot of one address. Tracing gives you the full "movie" — entry point, every scene in between, and the exit.

The Core Mechanics of Transaction Tracing

Identifying the Starting Point

Every trace has to start somewhere. In practice, that starting point is almost always a specific wallet address connected to a known event — a fraud report, a ransomware payment, a sanctions list hit, or an alert from a monitoring system that flagged something unusual. The quality of that anchor matters more than people realize. A clearly identified suspicious address gives investigators a solid foundation. A vague or unverified starting point can send an entire investigation sideways from step one. What usually ends up as the entry anchor? Addresses caught directly in a theft or scam. Wallets that received funds from a sanctioned entity. Addresses that suddenly lit up with large deposits from multiple unrelated sources. Wallets that victims reported after losing money to a Phishing Attack or Fake Exchange.

Following Transaction Chains

Here's where the actual detective work begins. From the anchor address, an analyst traces every wallet that received funds from it — then every wallet that received funds from those wallets — and so on. The result is a transaction graph: a map where wallets are nodes and transactions are the edges connecting them.

Each transaction in that graph carries four pieces of information: the sending address, the receiving address, the amount, and the timestamp. That last one matters more than you'd think. Time-based sequencing — understanding not just where money went but how fast and in what order — is often what reveals intent.

The catch is that funds almost never travel in a straight line. Multi-hop transfers are the norm. Illicit actors route money through intermediary wallets — sometimes dozens, sometimes hundreds — specifically to exhaust investigators who are following manually. Automated tools handle this by recursively mapping every outgoing transfer from every newly discovered address, building out the graph until the funds either reach a known entity (like an exchange) or simply go cold.

Detecting Consolidation and Layering Patterns

Analysts learn to recognize structural patterns that indicate deliberate obfuscation. Consolidation happens when funds from many different addresses flow into a single wallet, often a sign that an actor is aggregating proceeds before a final cash-out. Peeling Chains work in the opposite direction: a large sum moves through a long sequence of wallets, with a small amount "peeled off" at each step to a different address, gradually shrinking the main balance. Rapid Splitting divides a single balance into multiple smaller amounts and sends them simultaneously to dozens of addresses, thereby fragmenting the trail. Layering Behavior refers to the broader strategy of adding unnecessary complexity to fund movements—multiple hops, frequent denomination changes, and unnecessary intermediate wallets, specifically to obscure the funds' origin.

Identifying Exit Points

The goal of tracing is to determine where funds left the blockchain ecosystem or reached a point at which identity verification is possible. These are called exit points.

The most significant are centralized exchanges, where users complete identity verification. When a trace leads to an exchange deposit address, investigators know the funds were converted by an identified account holder. Other common exit points include crypto ATMs, OTC Trading Desks, P2P Marketplaces, and merchant payment services.

One increasingly important route involves cross-chain movement—moving funds via bridges or decentralized exchanges that connect different blockchains. This adds significant complexity because the fund flow crosses technical boundaries between entirely different systems. The mechanics of this are explored in cross-chain transaction analysis.

Common Laundering Patterns Observed in Transaction Tracing

There are many ways illicit fund flows try to break a clean trace — some create real distance, others create noise, and some simply overwhelm the graph until the signal gets buried. Below, we’ll take a closer look at a few of the most common patterns analysts encounter in transaction tracing, and unpack why each one makes fund flow reconstruction harder even when everything remains visible on-chain.

Chain Hopping

So, imagine you're tracing a wallet on Ethereum. You've followed the funds through a dozen intermediary addresses, and the trail is clear. Then the money hits a bridge contract and vanishes. On the other side of that bridge, on a completely different blockchain, new funds appear. Same value, different network, different address format, no shared transaction ID connecting the two. To understand why chain hopping works so well, you first need to understand a basic fact about how blockchains are built: they don't talk to each other natively. Ethereum doesn't know what's happening on BNB Chain. BNB Chain doesn't know what's happening on TRON. Each network maintains its own ledger, its own address format, its own transaction structure. There is no shared database that connects them. This means that when funds move from one chain to another, nothing on either blockchain records that movement as a single event. What gets recorded instead are two separate, unrelated-looking transactions — a deposit on the source chain, and a withdrawal on the destination chain. Linking them requires either specialized cross-chain analytics tools or the internal records of the bridge protocol itself, which is a private database nobody can subpoena without knowing who runs it.

A bridge is a smart contract, or a set of smart contracts, that coordinates asset movement between two blockchains. The mechanics vary by protocol, but the general flow looks like this. A user sends funds to the bridge contract on the source chain. The contract locks those funds — they sit there, held by the protocol. The bridge then monitors both chains simultaneously, detects the incoming deposit, and triggers a corresponding action on the destination chain: either minting new wrapped tokens, releasing pre-held reserves, or creating an equivalent balance. The user receives funds on the destination chain from what appears to be the bridge's own wallet, not from the original sender. That last part is key. On the destination chain, the transaction shows the bridge's address as the sender. The original source wallet is nowhere in the picture. Unless you know to look for the corresponding bridge deposit on the source chain, and you have a tool capable of matching them, the connection is invisible.

Let's make this concrete with the classic Chain-Hopping. (Picture 1)

1. ETH to BNB Chain. The actor sends ETH to a bridge contract on Ethereum. The bridge locks the ETH and releases an equivalent amount on BNB Chain, either as wrapped ETH or converted to BNB through an automated swap. Both Ethereum and BNB Chain use the same address format (they're both EVM-compatible, starting with 0x), which looks deceptively similar, but they are entirely separate ledgers. The transaction hash on Ethereum and the transaction hash on BNB Chain share no common identifier whatsoever. At this point, a standard Ethereum tracing tool loses the thread completely. It can see the funds hitting the bridge contract. It cannot see what happened next, because "next" happened on a different blockchain the tool doesn't monitor.
2. BNB to TRON. Now on BNB Chain, the actor uses another bridge, or a cross-chain DEX aggregator, to move funds to TRON. Here the address format changes completely. TRON addresses start with a capital T and use a different encoding standard (Base58Check) compared to EVM's hexadecimal format. A BNB Chain analytics tool tracking 0x7f4e... has no way to automatically know that TQn9Y... on TRON is the next step in the same fund flow. The technical identifiers are structurally incompatible.
3. TRON to Bitcoin. This is where the format change becomes most dramatic. Bitcoin uses a completely different cryptographic model, UTXO-based, compared to the account-based model of EVM chains and TRON. Bitcoin addresses look nothing like EVM or TRON addresses. There is no smart contract layer to interact with. A cross-chain protocol like THORChain handles this conversion by running nodes on both chains simultaneously, matching deposits and payouts through its own internal liquidity pools. The result on the Bitcoin side is a transaction originating from THORChain's own Bitcoin wallet, with no traceable link to the TRON address that initiated the swap.

After three hops, the money has crossed three entirely different technical environments, changed address formats twice, and passed through at least three different bridge or swap protocols, each of which records only its own piece of the puzzle. So, to reconstruct the full path, an investigator needs data from all three source chains simultaneously, knowledge of which bridge protocols were used and at roughly what time, and a tool capable of matching deposits and withdrawals across chains using amount, timing, and behavioral correlation rather than shared transaction IDs.

Most Blockchain Analytics platforms were built chain by chain. Ethereum support came first, then Bitcoin, then BNB Chain, and so on. Each chain got its own database, its own address clustering, its own risk scoring. The interfaces often reflect this architecture — you open a separate view for each network, run separate searches, and manually compare what you find. For single-chain investigations this is fine. For chain hopping, it's a blind spot. Every bridge crossing requires the analyst to manually switch contexts, identify the corresponding transaction on the destination chain, and carry the thread forward — a process that can take hours per hop, and that becomes practically impossible at scale when a single laundering operation crosses five or six chains before reaching an exit. Modern cross-chain analytics tools address this by maintaining a unified graph across all monitored blockchains, using automated bridge-matching algorithms that correlate deposits and withdrawals by amount, timing, and protocol behavior. Instead of separate silos, they treat the entire multi-chain ecosystem as one connected network — which is exactly how the funds are actually moving.

Address Poisoning

Address Poisoning (Picture 2) creates confusion rather than distance, as attackers generate addresses whose first and last characters match addresses their victims use regularly, then send dust transactions to poison the history.

If the victim copies an address from their transaction list, they might paste the attacker's lookalike instead, sending funds somewhere unexpected and causing the trail to fork in a direction nobody anticipated—an effect we discussed in detail in our case study on how a poisoning scheme netted over $50K and was traced and recovered in our Honey Trap article.

Asset Fragmentation

Asset Fragmentation (Picture 3)— large sums broken into hundreds of pieces distributed simultaneously. The graph explodes in size and manual tracing becomes impossible.

For example, imagine you’re tracing a suspicious wallet and the story looks manageable: one sender, one receiver, a few hops, a clear path. Then, in a single block everything changes. The funds don’t move forward as one stream anymore. They split into dozens or hundreds of tiny outbound transfers, fired off almost simultaneously to fresh addresses that have no history. If you’re looking at a transaction graph, this is the moment the graph stops being a line and turns into a burst.

To understand why fragmentation works, you need one basic idea about blockchain tracing: most fund flow analysis depends on continuity. Even when funds hop across multiple wallets, there’s usually a readable chain — A → B → C → D — where each hop can be linked by time, amount, and relationship to the previous step. Fragmentation breaks that continuity on purpose. Instead of one “next step,” there are suddenly a hundred “next steps,” and each one looks plausible in isolation but overwhelming as a set. The trail doesn’t disappear, it multiplies.

Mechanically, fragmentation is simple: a large sum is divided into many smaller outputs that go to many different addresses. On account-based chains, this often appears as a sequence of outbound transfers. On UTXO-based chains like Bitcoin, it can appear as a single transaction that creates a large number of outputs at once. The effect is similar across models: one source becomes many destinations. The analyst no longer has to “follow the money”, they have to follow money everywhere.

1. The first challenge is scale. Tracing tools and explorers can show you the list of outgoing transfers, but your brain (and your time) become the bottleneck. If a wallet sends 300 transfers, you now have 300 threads to validate. Which ones are meaningful? Which are decoys? Which lead to an exit point? And which are just churn that never leaves the actor’s control? Even if you sample, you risk missing the one thread that matters — the branch that reaches an exchange deposit, a bridge, or a service that provides liquidity.
2. The second challenge is that fragmentation is rarely a “final” step. It is usually the beginning of a second phase: consolidation. After the funds are scattered, many of those small pieces later reconverge — not back into the original wallet, but into aggregation wallets that look unrelated at first glance. That reconvergence can happen gradually or in bursts, and it can happen through intermediary wallets that exist only long enough to forward funds once. In graph terms, the actor intentionally forces the analyst to handle both extremes: first an explosion (one-to-many), then a foggy recombination (many-to-one) — and both are hard to interpret without automation.
3. The third challenge is attribution noise. When you see hundreds of fresh addresses receiving tiny pieces, you’re not just dealing with more nodes — you’re dealing with weaker signals. Individual transfers may be too small to trigger risk thresholds, too common to look special, and too numerous to review manually. The pattern itself is the signal, but only if you can see it as a pattern. This is where transaction graph analysis becomes essential: you’re not trying to understand one transfer, you’re trying to understand the structure of the flow — branching degree, timing clusters, repeated re-use of intermediaries, and the “shape” of how funds disperse and later reassemble.

In practice, fragmentation turns a straightforward tracing task into a prioritization problem. Analysts have to identify which branches matter by looking for markers like: repeated destination behaviors, interactions with known services, clustering hints that suggest common control, or the emergence of entry and exit points among the chaos. Without that filtering, manual tracing becomes less “investigation” and more “endless clicking.” You can spend hours mapping branches that lead nowhere while the meaningful thread exits the system in the background.

That’s why fragmentation is so effective operationally. It doesn’t rely on hiding transactions — everything is visible on-chain. Instead, it weaponizes transparency by creating too much of it. The ledger is open, the data is there, and the trail exists — but it exists in a form that overwhelms human review. The outcome is not a dead end, but a maze: the funds are still traceable in theory, yet in practice the investigation stalls unless you can reconstruct the fund flow at scale, apply clustering logic, and reduce the explosion into a manageable set of candidate paths.

By 2026, these patterns have become more varied and more combinable — the same operation may chain-hop, fragment, and then consolidate again before reaching an exit. The clearest way to understand how they work in practice is through real-world case studies, and new variants continue to appear as the ecosystem evolves; for deeper breakdowns, you can explore our Investigations & Case Studies section.

Transaction Tracing vs Blockchain Forensics

These two terms are often used interchangeably, but they describe different scopes of work.

Transaction Tracing is the technical layer. It produces a fund flow map: a documented reconstruction of how assets moved from address to address. It finds the suspicious patterns, identifies the entry and exit points, and establishes connections between wallets. This is the core analytical work — the part that answers what happened.

Blockchain Forensics wraps around that with everything needed to use those findings in court. Rigorous methodology documentation. Chain of custody for evidence. Findings packaged to meet legal admissibility standards. Expert testimony, if it gets that far.

Put simply: tracing tells you the story. Forensics gets that story in front of a judge.

Most cases start as internal compliance reviews. An alert comes in, an analyst runs a trace, and either the risk is resolved or it isn't. When the trace reveals real exposure — sanctions hits, confirmed fraud proceeds, ransomware payments — it escalates into something more formal. That's when you're in cryptocurrency investigations territory, with tighter procedures and higher stakes.

Practical Limitations of Transaction Tracing

It would be misleading to talk about how powerful tracing is without being honest about where it breaks down.

These are the most common structural limitations encountered in modern blockchain investigations. In practice, tracing complexity can increase further depending on jurisdictional opacity, off-chain settlement mechanisms, custodial layering, and the availability of legal cooperation.

When Transaction Tracing Becomes an Investigation

The transition from monitoring to investigation follows a predictable escalation logic.

A transaction monitoring system generates an alert — perhaps a deposit from a wallet with direct exposure to a sanctioned address, or a pattern matching a known layering typology. That alert goes to a compliance analyst for review. When the review deepens concern rather than resolving it — when the fund flow analysis reveals real connections to illicit activity — the case escalates.

The evidence is compiled into documentation. Depending on the findings, the case may trigger a Suspicious Activity Report filing or be referred to law enforcement with supporting analysis. The on-chain evidence forms the factual backbone of that escalation. If asset recovery is a goal, the process begins here, too, with tracing documentation support in crypto asset recovery and investigation.

Technologies Behind Modern Transaction Tracing

The techniques described above would be impossible to apply at scale without purpose-built infrastructure.

(а) Graph Databases are the foundation. Blockchain data is inherently a graph — addresses connected by transactions — and these databases are optimized for exactly the kind of path-finding and pattern-detection queries that tracing requires.

(b) Clustering Heuristics consolidate billions of individual addresses into manageable entity representations. The most fundamental is the common-input-ownership heuristic: when multiple addresses appear together as inputs in a single Bitcoin transaction, they almost certainly belong to the same entity. Change address detection, deposit forwarding patterns, and behavioral fingerprinting add additional grouping layers.

(c) Risk Scoring Models automate the initial assessment by applying hundreds of rules simultaneously—evaluating counterparty history, fund-flow origins, service-type exposure, and transaction behavior—to generate ratings that prioritize which cases require human review.

(d) Entity Attribution Systems link blockchain addresses to known real-world actors: exchanges, mixing services, darknet markets, and sanctioned organizations. The larger and more accurate the attribution database, the faster a trace can reach a meaningful conclusion.

For example, Tracer Tool applies these layers — graph analysis, clustering, risk scoring, and entity attribution — in an integrated environment designed for both compliance teams and investigators.

FAQ

AMLBot KYT solution has expanded its blockchain coverage to include Hyperliquid, a high-performance decentralized exchange that operates its own Layer 1 Blockchain. This addition addresses a critical compliance gap: while Hyperliquid's trading volume and total value locked continue scaling, comprehensive blockchain intelligence coverage for the network's settlement layer remains limited.

 "HyperCore is where economic settlement happens, billions in perpetual futures trading, spot market activity, and fund transfers. HyperEVM applications access this liquidity rather than creating an independent settlement. Tools that monitor only HyperEVM provide visibility into the decentralized application layer but remain blind to the settlement layer, where real AML risk resides. For compliance teams, this distinction is not a technical detail. It determines whether you actually have coverage or just a checkbox," explains Viacheslav Demchuk, CEO of AMLBot.

AMLBot's Hyperliquid implementation addresses this coverage gap by indexing HyperCore, the settlement layer where perpetual futures trading, spot markets, and USDC deposit/withdrawal activity actually occur. This approach required technical decisions specific to Hyperliquid's design that differ fundamentally from traditional blockchain analysis approaches, but it ensures that Compliance Monitoring captures the transaction flows that generate real AML risk.

Unlike networks where every execution layer must be indexed separately, Hyperliquid's dual-chain architecture enables complete transaction visibility through selective indexing. This article examines the technical rationale behind AMLBot's Hyperliquid labeling architecture and explains why monitoring HyperCore alone provides comprehensive AML coverage.

What Is Hyperliquid?

Hyperliquid is a high-performance decentralized exchange operating on its own Layer 1 Blockchain, specializing in perpetual futures and spot trading. Launched in 2023, the platform has grown to become one of the largest decentralized derivatives exchanges by trading volume, processing up to 30 billion dollars in daily transactions.

Unlike traditional decentralized exchanges that run on Ethereum or other general-purpose blockchains, Hyperliquid operates its own purpose-built infrastructure optimized for high-frequency trading. The network achieves transaction finality in 0.2 seconds and can process approximately 200,000 orders per second, performance characteristics that attract professional traders and institutional market participants.

The platform primarily facilitates perpetual futures contracts, which are derivative instruments allowing traders to speculate on cryptocurrency prices with leverage. Spot trading for direct cryptocurrency purchases is also available. USDC serves as the primary collateral and settlement currency, with all deposits, withdrawals, and trading settlements denominated in this stablecoin.

Hyperliquid has experienced adoption growth throughout 2025, with total value locked increasing from hundreds of millions to billions of dollars. The platform attracts retail traders seeking decentralized alternatives to centralized exchanges, institutional market makers providing liquidity, and professional traders drawn to the platform's performance characteristics and fully on-chain order book transparency.

This growth and increasing institutional participation have elevated Hyperliquid's compliance significance. As trading volume scales and the platform attracts more sophisticated users, it also becomes a potential vector for illicit finance activities. Money launderers may attempt to exploit high-volume trading environments to obscure fund origins. Sanctioned entities could seek access to decentralized trading platforms that lack traditional KYC requirements. The high-leverage perpetual futures markets create opportunities for market manipulation schemes requiring surveillance.

For financial institutions, cryptocurrency exchanges, and compliance teams, Hyperliquid represents an emerging blind spot in Blockchain Transaction Monitoring.

Understanding Hyperliquid's Dual Architecture

Hyperliquid operates through two integrated components: HyperCore and HyperEVM, both secured by the same HyperBFT consensus mechanism. Understanding this dual architecture is essential to understanding why HyperCore-focused monitoring delivers comprehensive AML coverage.

HyperCore functions as a high-performance trading engine implemented directly at the blockchain level, maintaining a fully on-chain central limit order book without hidden off-chain matching layers. As the official Hyperliquid documentation describes, "HyperCore includes fully onchain perpetual futures and spot order books. Every order, cancel, trade, and liquidation happens transparently with one-block finality."

HyperEVM provides an Ethereum-compatible smart contract environment where developers can build custom applications, but it is not a separate chain; rather, it is an extension of Hyperliquid that shares the same consensus. The network processes around 200,000 orders per second with transaction finality averaging 0.2 seconds, creating significant throughput that traditional AML monitoring approaches struggle to handle efficiently. 

Architectural Relationship: Settlement vs Application Layer

The key distinction for compliance monitoring lies in understanding how these layers interact:

As the Hyperliquid Technical Documentation explains: "A theme of the HyperEVM is to abstract away the deep liquidity on HyperCore as a building block for arbitrary user applications." This means HyperEVM applications don't create independent settlements. They access HyperCore's existing liquidity through system precompiles and contracts.

The architectural separation between trading logic (HyperCore) and smart contract execution (HyperEVM) has direct implications for compliance monitoring. HyperCore handles all trading activities, staking, native multisigs, and core exchange functionality, while HyperEVM handles the smart contract environment. This division creates distinct economic activity zones with different risk profiles.

Why AMLBot Indexes HyperCore Only

AMLBot's decision to index HyperCore exclusively, rather than both execution layers, is driven by the concentration of economic activity, not by technical limitations. This architectural choice addresses a reality: the vast majority of Hyperliquid's economically significant transactions and AML risk occur on HyperCore, not HyperEVM.

HyperCore functions as the settlement layer for Hyperliquid's trading infrastructure. All perpetual futures positions settle on HyperCore, representing the network's core use case as a decentralized derivatives exchange. Spot trading occurs on HyperCore's on-chain order book, which features deep liquidity and high-frequency market-making. USDC deposits via the Arbitrum bridge and withdrawals—the primary mechanisms for moving value into and out of the ecosystem—transact on HyperCore. Native token staking that secures the network operates on HyperCore. These activities generate the transaction flows that compliance teams must monitor to detect suspicious patterns, sanction violations, and illicit fund movements.

Hyperliquid processes up to $30 billion in daily trading volume, virtually all of which flows through HyperCore's perpetual and spot markets rather than HyperEVM smart contracts. This separation exists because HyperCore is purpose-built for high-performance trading, with 200,000 orders per second throughput and 0.2-second finality, while HyperEVM serves as an application layer for developers building on this infrastructure.

HyperEVM's role in the ecosystem is fundamentally different from HyperCore's. Rather than creating an independent economic settlement, HyperEVM applications access HyperCore's liquidity as a building block. Smart contracts on HyperEVM interact with perpetual and spot markets on HyperCore through system precompiles, meaning that the economic substance of HyperEVM activity ultimately references HyperCore settlement. A decentralized application on HyperEVM that facilitates trading accesses HyperCore's order book, rather than creating parallel settlement infrastructure.

Industry analysis confirms this architectural relationship. As Galaxy Digital Research noted in their July 2025 analysis, activity on HyperEVM "remains modest compared to HyperCore" despite steady growth in the smart contract ecosystem. HyperEVM continues to develop in the alpha stage with a gradual feature rollout, while HyperCore handles the network's production trading volume.

From an AML risk perspective, this means that monitoring HyperCore captures the settlement layer, where economic transfers occur, while monitoring only HyperEVM captures application-layer contract interactions, which represent only a fraction of transaction volume. For compliance teams, the distinction matters because risk assessment requires visibility into actual fund movements, not just smart contract events that reference those movements.

This architectural choice allows AMLBot to deliver complete compliance monitoring with optimal resource allocation. Rather than indexing both chains and filtering out duplicate or derivative transactions, AMLBot focuses computational resources on where actual value transfer occurs. 

Current Implementation: Arbitrum Bridge Monitoring

Hyperliquid's bridge architecture creates an observable chokepoint for value entering or exiting the ecosystem via the Arbitrum Bridge. Understanding this gateway mechanism is critical to AML Monitoring, as it provides complete transaction visibility for Arbitrum-based flows. 

Bridge Mechanism Flow

The bridge between Hyperliquid and Arbitrum requires users to send native USDC to the bridge contract, which credits the account in HyperCore in less than 1 minute with a minimum deposit of 5 USDC. Deposits are signed by validators and credited once more than two-thirds of staking power has been signed. Withdrawals on Hyperliquid require only a user wallet signature, with no Arbitrum transaction; validators handle the withdrawal entirely, and funds arrive in 3-4 minutes. USDC is the dominant settlement currency in Hyperliquid. The bridge handles USDC exclusively for native deposits; perpetual futures use USDC as collateral; spot markets predominantly quote against USDC pairs; and fee structures are denominated in USDC. This single-asset dominance means that monitoring USDC flows through the Arbitrum bridge captures the vast majority of economic activity entering or exiting Hyperliquid via this route.

AMLBot provides comprehensive monitoring for deposits and withdrawals via the Arbitrum-Hyperliquid bridge. This enables complete source-of-funds verification for Arbitrum-based flows, including: -

1. Originating Ethereum Address before Arbitrum Bridge 
2. Complete Transaction Path on Ethereum  
3. Arbitrum Bridge Contract Interaction 
4. HyperCore Settlement and Subsequent Trading Activity

Note: Protocol Evolution (December 2025): Hyperliquid introduced Circle's Cross-Chain Transfer Protocol (CCTP) support in December 2025, enabling deposits from multiple CCTP-enabled chains including Ethereum, Polygon, Base, Avalanche, and Optimism. This represents a natural evolution of the network's gateway architecture alongside the existing Arbitrum bridge. AMLBot currently monitors deposits and withdrawals via the Arbitrum Bridge only.

Address Model and AML Labeling Compatibility

Hyperliquid's address architecture enables direct integration with existing Ethereum-based AML labeling infrastructure. This compatibility is a critical technical advantage that dramatically reduces implementation complexity.

Ethereum-Compatible Address Format

HyperCore addresses follow Ethereum's address format, using standard 20-byte hexadecimal addresses compatible with EVM wallets. The same address operates identically across HyperCore and HyperEVM, with no separate derivation or mapping required.

Example Address Usage:

This compatibility extends beyond superficial formatting. Wallet software that supports Ethereum—MetaMask, Hardware Wallets, and Custodial Solutions—functions natively on Hyperliquid without modification. Users sign transactions using the same private keys across both chains. Address ownership verification uses the same cryptographic schemes, and transaction signing follows Ethereum's EIP-712 typed data standard.

AML Labeling Integration

For AML labeling systems, this architectural decision eliminates an entire class of technical challenges:

Direct Label Application:

Existing address clustering algorithms developed for Ethereum apply directly to Hyperliquid without modification. Attribution databases linking addresses to entities require no separate Hyperliquid-specific entries. Behavioral analysis models trained on Ethereum transaction patterns can be applied to HyperCore activity analysis. Cross-chain investigation workflows can seamlessly track the same address across Ethereum, Arbitrum, and Hyperliquid.

When AMLBot encounters a Hyperliquid address that matches a labeled Ethereum address in its database, the attribution applies immediately. If an address previously identified as belonging to a sanctioned entity or mixer service appears in HyperCore transactions, the risk signal propagates without requiring separate verification. This address model compatibility dramatically reduces the implementation complexity typically associated with adding new blockchain support.

Transaction Types Under AMLBot Surveillance

AMLBot's Hyperliquid implementation monitors three distinct transaction categories that collectively provide complete economic visibility:

1. Deposits from Arbitrum to HyperCore represent the primary value ingress vector. Users deposit USDC from their Ethereum wallets into the bridge contract on Arbitrum, and Hyperliquid validators monitor these deposits via RPC and update Hyperliquid's internal state accordingly. AMLBot captures the originating Arbitrum address, deposit amount, destination HyperCore address, and timestamp for compliance correlation. These transactions establish the initial funding source for subsequent on-chain activity.
2. Transfers within HyperCore constitute the primary transaction category by volume. These include spot asset transfers between addresses, USDC transfers for collateral management or settlement, position transfers in certain protocol-supported scenarios, and native token movements for staking or governance. Internal transfers reveal the economic relationships between addresses, fund flows between trading strategies and parties, payment patterns that may indicate commercial relationships, and accumulation or distribution behaviors relevant to market manipulation detection.
3. Withdrawals from HyperCore to Arbitrum complete the transaction lifecycle. Users initiate withdrawals on Hyperliquid via a UI action; validators sign the withdrawal in a two-phase protocol, and funds are released to the specified Arbitrum address once sufficient validator signatures are collected. AMLBot tracks the withdrawing HyperCore address, the destination Arbitrum address for cross-chain correlation, the withdrawal amount and timing, and validator signature patterns that may indicate irregular processing.

This three-category model provides comprehensive coverage by capturing all economically significant events. Value cannot be entered without a deposit transaction. Activity within the ecosystem generates transfer records. Exit from the ecosystem requires a withdrawal. The simplified transaction model reduces false positives compared to blockchains, where dozens of transaction types create classification challenges.

Why This Matters for Crypto Businesses

The architectural approach AMLBot employs for Hyperliquid blockchain analysis provides specific operational advantages for compliance teams handling Hyperliquid exposure.

1. Teams benefit from focused architecture. AMLBot's HyperCore indexing covers all material economic activity—perpetual futures trading, spot markets, and internal transfers representing billions in daily settlement. This reduces operational complexity compared to monitoring multiple execution layers.
2. Organizations using blockchain intelligence tools that monitor only HyperEVM may technically have Hyperliquid USDC deposits and withdrawals listed in their vendor capabilities, but they lack visibility into the settlement layer where the vast majority of the network's economic activity occurs. When a customer deposits funds from a Hyperliquid address, those funds almost certainly originated from HyperCore perpetual trading or spot markets—activity that HyperEVM-only monitoring cannot detect. HyperCore coverage ensures compliance teams can actually assess the risk of incoming transactions rather than simply checking a box that Hyperliquid is "supported."
3. When a suspicious transaction is detected, investigators work with a limited set of transaction types rather than navigating complex DeFi protocol interactions. The gateway architecture means investigators can trace funds to their Arbitrum origin or destination, connecting Hyperliquid activity to broader Ethereum ecosystem intelligence.
4. Existing Ethereum address labels apply directly without requiring Hyperliquid-specific attribution work. Compliance teams can leverage their existing counterparty databases and sanctions screening lists without building parallel infrastructure.
5. By focusing monitoring resources on HyperCore, where settlement occurs, compliance teams avoid processing overhead from application-layer events that do not represent actual economic transfers. This optimization becomes critical as trading volumes scale.

The current limitation is that AMLBot does not index HyperEVM smart contract activity. For most compliance use cases, this represents acceptable coverage because economic settlement happens on HyperCore. However, as HyperEVM ecosystem applications mature and begin handling material value independently, compliance teams should anticipate expanding monitoring scope. Organizations with specific HyperEVM exposure may need supplementary monitoring, though HyperCore coverage captures the vast majority of AML-relevant activity. Importantly, the inverse is not true, organizations that monitor only HyperEVM face compliance gaps in their Hyperliquid coverage.

Hyperliquid Compliance Coverage in the Market

The Hyperliquid blockchain analysis market remains in early stages of development, with coverage that varies in comprehensiveness. While select blockchain intelligence providers have begun implementing Hyperliquid support, not all coverage approaches address the same compliance needs.

A critical distinction exists between providers that index HyperEVM versus those that index HyperCore. Some blockchain intelligence tools have added support for HyperEVM, the smart contract execution layer, positioning HyperEVM within Hyperliquid's coverage. However, this approach creates a fundamental coverage gap: HyperEVM functions as an application layer that accesses HyperCore's liquidity rather than serving as an independent settlement layer. For compliance teams, this means that monitoring HyperEVM alone captures application-layer smart contract interactions but misses perpetual futures trading, spot market activity, and USDC deposit/withdrawal flows that constitute the vast majority of actual economic settlement.

From a risk management perspective, this matters significantly. When an exchange receives a deposit from a Hyperliquid address, that value almost certainly originated from HyperCore trading activity, not HyperEVM Smart Contracts. When investigators trace illicit funds moving through Hyperliquid, the transaction trail will flow through HyperCore perpetual positions and spot markets, not HyperEVM applications. When compliance teams assess wallet risk for a Hyperliquid address, the material exposure comes from HyperCore trading volume, measured in billions per day, not from HyperEVM contract interactions.

AMLBot's HyperCore-focused architecture directly addresses this coverage gap. Rather than monitoring the application layer, where smart contracts operate, the platform indexes the settlement layer, where economic transfers occur. Combined with gateway monitoring at entry and exit points, this approach provides visibility into the transaction flows that generate real AML risk. Organizations using blockchain intelligence tools that cover only HyperEVM may believe they have Hyperliquid compliance coverage while remaining blind to the settlement layer, where most economic activity occurs.

The architectural approach matters beyond the scope of coverage. HyperCore transactions reveal trading patterns, fund flows, and economic relationships that compliance teams need to detect suspicious activity. Monitoring where billions in daily volume settle provides materially different intelligence than monitoring application-layer contract events. As Hyperliquid adoption continues to grow among institutional traders and the network attracts the attention of illicit actors, comprehensive coverage of the settlement layer is critical.

Note on Gateway Evolution: This analysis focuses on settlement layer monitoring (HyperCore vs HyperEVM). Gateway monitoring considerations, including Hyperliquid's recent CCTP multi-chain support, are addressed in the Gateway Architecture section above.

Get Access to Hyperliquid KYT Monitoring

Contact Us:
🔗 Support Team
🔗 LinkedIn

FAQ

Intro

This report is based on the analysis of 2,500+ real crypto crime investigations conducted by AMLBot across 2025-2026, covering fraud, theft, hacks, and post-incident tracing cases across multiple blockchains and services. Rather than focusing on isolated incidents or public breach disclosures, the study examines how crypto attacks actually unfold in practice — from the initial attack vector to post-incident fund movement, freezing, and recovery attempts.

To download the full report, fill out the form below 👇

It is important to note that dataset is built on real post-incident investigations. In most cases, individuals and businesses approached AMLBot after an incident had already occurred. These cases were investigated using Tracer, as the primary on-chain investigation tool, allowing analysts to reconstruct fund movement, identify laundering patterns, and understand how attacks evolved after the initial breach.

Report Preview

What Happens to Stolen Funds After an Attack

• ≈75% freeze success rate in cases where stolen funds were still held on attacker-controlled wallets at the time the investigation began
• freezing actions consistently precede recovery, serving as the primary mechanism for loss containment
• double-digit recovery rates observed in categories such as Device Compromise, Protocol Exploits, OTC Scams, and Impersonation, particularly when stolen assets intersect with centralized platforms or cooperative service providers
• recovery likelihood increases in high-value cases, where issuers, exchanges, and counterparties prioritize fast intervention, illustrating that timely investigative action and ecosystem cooperation remain critical factors in determining how stolen cryptocurrency can be recovered.

Сrypto Attack Vectors Observed in Real Investigations

This section outlines the primary attack vectors identified across AMLBot’s internal investigation cases. The initial point of compromise defines each vector. This approach reflects how incidents unfold operationally and aligns with the human-factor thesis that underpins this report. Where relevant, links to previously published AMLBot case studies are included to provide concrete, real-world illustrations of these mechanisms. 

Investment Scams and Pig Butchering

Investment Scams represent the largest category by case count in AMLBot’s dataset. These schemes rely on false profitability signals (fabricated dashboards, staged withdrawals, or social proof) to gradually extract increasing deposits from victims.

A particularly damaging subset is Pig Butchering, where a prolonged trust-building phase precedes the financial scam. Victims are engaged through social platforms or messaging apps, often over weeks or months, before being introduced to a fraudulent investment opportunity. A detailed operational breakdown of such schemes is documented in AMLBot’s investigation into Pig-Butchering Crypto Scams.

Because losses accumulate slowly and appear legitimate during early stages, victims typically recognize the fraud late, reducing the likelihood of timely freezes or recovery. This behavioral pattern is further explored in AMLBot’s analysis of how emotional manipulation precedes financial loss.

Phishing, Impersonation, and Chat-Based Scams

Phishing remains one of the most common entry points across crypto-related incidents. However, in practice, many cases extend beyond simple malicious links or fake domains.

In a growing number of investigations, the defining vector is Impersonation. Attackers posing as exchanges, compliance teams, law enforcement, employers, or trusted counterparties. These scams rely on urgency, authority, and conversational pressure rather than technical deception alone.

Chat- and Voice-Based Impersonation (via Telegram, Discord, WhatsApp, Zoom, or Phone Calls) has become particularly prominent in 2025, reflecting a shift toward more interactive and psychologically tailored attacks.

While individual losses in these categories are often smaller than in Investment scams, their frequency and scalability make them a persistent operational risk for both individuals and businesses.

Device Compromise and Private-Key Exposure

Device Compromise cases consistently produce some of the highest median losses in AMLBot’s dataset. These incidents typically originate from phishing-delivered malware, fake software updates, compromised installers, or remote-access tools. Once installed, attackers gain access to wallets, signing sessions, password managers, or two-factor authentication mechanisms.

At that point, loss escalation is rapid. Unlike Investment scams, where funds are extracted over time, device compromise typically results in near-immediate draining of all accessible assets.

Address Poisoning and Operational Errors

Address Poisoning exploits a subtle yet critical operational weakness: reliance on transaction history to reuse addresses. Attackers generate addresses visually similar to legitimate counterparties and send small “dust” transactions to the victim. When the victim later copies an address from their transaction history, funds are inadvertently sent to the attacker-controlled wallet. While Address Poisoning accounts for a relatively small share of total cases, losses can be substantial, particularly in corporate or treasury contexts where a single transfer may involve six- or seven-figure sums.

Fake Job and Recruitment Scams

Job-related scams target victims through fake Web3 recruitment offers, freelance tasks, or “trial assignments.” Victims may be asked to install tools, sign transactions, provide credentials, or even unknowingly launder funds as part of supposed onboarding tasks.

These scams are particularly effective against early-career professionals and freelancers seeking entry into the crypto industry. Although median losses are typically lower than in investment scams, job scams frequently serve as initial access vectors that later escalate into device compromise or impersonation-based fraud.

CEX Breaches and High-Impact Incidents

Centralized Exchange breaches and protocol-level hacks are often perceived as purely technical incidents. However, AMLBot’s investigative data shows that many such cases involve human-enabled entry points, including credential theft, insider manipulation, or social engineering of employees. In the dataset, the “CEX Breach” category is influenced by a few mega-events, including a single outlier that dominates total loss figures. This underscores the importance of separating frequency analysis from impact analysis.

Data-Driven Analysis of Crypto Crime Patterns

With these attack vectors defined, the following sections examine how they manifest quantitatively across AMLBot’s Investigation Cases. The charts and figures that follow are not intended to rank “most common scams” in isolation. Instead, they are used to demonstrating:

• how attack frequency differs from financial impact,
• how loss distributions vary by vector,
• and how the evolution of crypto crime across 2024–2025 reinforces the central conclusion of this report:

сrypto crime has matured from exploiting code to exploiting people.

Figure 1 shows the distribution of AMLBot investigation cases by dominant attack category.

Investment Scams account for the largest share of cases, followed by Phishing and Device compromise. Together, these three categories represent a substantial portion of total incident volume. Pig-Butchering Scams, Chat-Based Impersonation, and OTC fraud form a second tier of frequently observed attack types. In contrast, categories such as CEX Breaches, Wrench Attacks, and Ransom/Extortion appear far less often.

Importantly, this distribution reflects case frequency, not financial severity. High visibility in this chart does not necessarily correspond to the largest financial impact, a distinction explored in subsequent figures.

Figure 2 presents the share of total investigation cases by month across 2024–2025.

Case volume rises noticeably during the first half of 2024, followed by a prolonged plateau rather than a reversal. Throughout late 2024, monthly volumes remain consistently elevated. In early 2025, a temporary dip is observed, followed by renewed activity through spring and summer. 

The data indicates a transition into a sustained operational phase of crypto-related fraud and theft, rather than a short-lived spike. The absence of a return to early-2023 baselines suggests structural persistence rather than event-driven volatility. 

This stacked view breaks down monthly case volume by category, illustrating how different attack vectors contribute over time. 

Early 2024 is dominated by Investment Scams and Phishing. As the year progresses, Device Compromise remains consistently present, while OTC Scams and Address Poisoning introduce steady background activity with occasional spikes. In 2025, chat-based and voice impersonation scenarios became more prominent within the overall mix.

A single dominant category does not drive the plateau observed in Figure 2, but by the simultaneous persistence of multiple attack vectors, each contributing moderate but sustained volumes.

This figure compares total financial losses by category on a logarithmic scale. CEX Breaches dominate total losses, despite representing a small fraction of overall cases. This result is driven primarily by a small number of extreme outliers, including one mega-event that disproportionately skews aggregate totals. Investment Scams, Impersonation, Phishing, and Device Compromise also contribute significant cumulative losses.

Note: Aggregate loss figures are highly sensitive to rare, high-impact incidents. As a result, total losses should not be interpreted without reference to frequency and distribution metrics.

Figure 5 illustrates the distribution of loss amounts per case across categories, highlighting medians, variability, and tail risk.

Device Compromise and Investment Scams show higher median losses and wide dispersion, indicating that once access is obtained or trust is established, losses can escalate fast. OTC Scams and Address Poisoning appear less frequently but exhibit notable outliers, particularly in operational or treasury-related contexts. Phishing, Chat Scams, Fake Jobs, and Fake Airdrops generally show lower median losses but remain highly recurrent.

Note: This figure differentiates typical loss exposure from tail risk. Categories with moderate frequency but broad distributions pose disproportionate risk to organizations with concentrated asset flows.

This time-series view presents monthly losses per category on a logarithmic scale. Loss patterns are characterized by high volatility, with extended periods of relatively moderate activity punctuated by sudden spikes. These spikes frequently correspond to isolated, high-value incidents rather than broad-based increases across categories.

Crypto loss dynamics are shaped less by gradual trends and more by episodic shocks. Risk assessments based on averages may therefore underestimate exposure to sudden, high-impact events. Taken together, the figures demonstrate a consistent pattern:

• High-frequency categories primarily exploit trust, urgency, and social pressure.
• High-impact categories often involve access compromise, operational errors, or insider-enabled pathways.
• Even incidents commonly labeled as “technical” frequently originate from human manipulation.

What Happens After the Attack

Once an incident is confirmed, the investigative focus shifts from detection to reconstruction and intervention. At this stage, outcomes are shaped less by how the attack occurred and more by how quickly fund movements can be identified, traced, and escalated.

Recovery Outcomes

Across categories, recovery outcomes correlate with time-to-detection. Early identification and freezing actions materially improve the likelihood of limiting losses, particularly in higher-value cases involving stablecoins or centralized intermediaries, forming the foundation for practical steps to recover stolen cryptocurrency.

By contrast, delayed recognition, common in Emotional Investment Scams and long-running Impersonation Schemes, reduces recovery potential, as funds are often fragmented across multiple wallets or routed through laundering paths before an investigation begins.

Freezing consistently emerges as the first and most decisive intervention step. In a significant share of cases, stolen funds were frozen before being moved further downstream. Larger thefts show even higher freeze rates, reflecting prioritization by exchanges and stablecoin issuers when high-value alerts are raised.

Importantly, when funds remained on attacker-controlled wallets at the time an investigation began, freezing actions were successful in approximately 75% of such cases, resulting in partial containment of losses. This figure does not imply full recovery, but it demonstrates that timely intervention can materially alter outcomes before laundering is completed.

Recovery, while less frequent than freezing, remains possible. Several categories, including Device Compromise, Protocol Exploits, OTC Scams, and Impersonation — show double-digit recovery rates, particularly when stolen assets touch centralized platforms or cooperative service providers.

Post-Incident Investigation and Tracing

In AMLBot’s post-incident crypto investigations, AMLBot Tracer is used as the primary tool during this post-incident phase to reconstruct fund movements: mapping transaction paths, visualizing entity relationships, and identifying how attackers attempt to fragment, reroute, or extract stolen assets across chains and services. This post-incident window frequently determines whether losses can be contained or become irreversible. The ability to contextualize on-chain activity, attribute flows to known clusters, and escalate findings to counterparties directly influences whether freezing and recovery actions remain viable.

A practical illustration of this process can be seen in an Address Poisoning Сase investigated by AMLBot, where a victim lost approximately $50,000 after copying a spoofed address. Using Tracer, investigators were able to map the outbound transactions, identify consolidation points, and link the attacker’s wallet to known infrastructure. This attribution enabled timely coordination with counterparties, ultimately resulting in in a partial recovery of assets.

Final Summary and Strategic Takeaways

This analysis of AMLBot’s internal investigation cases from 2024 to 2025 highlights a shift in how crypto-related crime unfolds in practice. While technical exploits and protocol failures continue to attract the most public attention, they account for only a minority of investigation cases. The majority of incidents originate earlier in the attack chain — at the human, operational, and access-control layers.

The data demonstrates a clear divergence between incident frequency and financial impact. High-frequency categories such as Investment Scams and Phishing dominate case volume but do not always produce the largest losses per incident. Conversely, low-frequency categories, including Centralized Exchange Breaches, Access Compromise, and Operational Errors, generate disproportionate financial damage due to rare but extreme outlier events.

Importantly, incidents often labeled as “technical” rarely emerge in isolation. In many high-impact cases, technical exploitation is preceded by human manipulation, credential exposure, or procedural shortcuts. Blockchain infrastructure serves as the execution and settlement layer, but human behavior increasingly defines the true attack surface.

Across categories, recovery outcomes correlate strongly with timing. Early detection and freezing actions materially improve the likelihood of limiting losses, particularly in high-value cases involving stablecoins or centralized intermediaries. Delayed recognition, common in Emotional Investment Scams and long-term Impersonation scenarios, reduces the potential for recovery.

Taken together, the findings suggest that effective crypto risk management in 2026 cannot rely solely on code audits, protocol security, or on-chain monitoring. Organizations and individuals must address the operational reality of modern crypto crime: access management, transaction verification discipline, employee awareness, and incident response speed are now as critical as technical controls.

As crypto crime continues to professionalize, prevention and mitigation efforts must evolve accordingly — shifting focus from purely technical defenses to integrated human, operational, and investigative safeguards.

“Most of the serious crypto losses we investigate don’t start with broken code. They start with a human mistake that attackers know exactly how to exploit.” — Vasily Vidmanov, Chief Operating Officer, AMLBot

The Crypto Travel Rule is no longer a distant regulatory concept. In an increasing number of jurisdictions, it is an enforceable obligation, and virtual asset service providers are expected to demonstrate compliance in practice, not merely in policy documents. Yet the gap between regulatory intent and day-to-day operations remains wide, and for many businesses, it is widening.

While the regulatory obligation itself is well understood in the industry, the operational reality of implementing it is far more complex than the policy language suggests. The challenge today lies not in understanding the rule, but in adapting it to the technical and operational realities of crypto infrastructure, where transaction execution, counterparty identification, and compliance data exchange operate under conditions fundamentally different from traditional financial networks.

What that foundational framework does not capture is where implementation actually breaks down. The challenges are not concentrated in any single point of failure. They are distributed across technical architecture, jurisdictional fragmentation, counterparty relationships, data protection obligations, and regulatory evolution, each layer compounding the others. This article examines those challenges in detail, from the perspective of the businesses that must navigate them.

Note: None of this information should be considered as legal, tax, or investment advice. While we’ve done our best to ensure this information is accurate at the time of publication, laws and practices may change, so please double-check it.  

Why Crypto Travel Rule Implementation Is More Complex Than It Appears

It would be reasonable to assume that a rule of this kind, essentially a data-sharing obligation, sits at the less demanding end of the compliance spectrum. The requirements appear bounded and manageable, creating the perception that implementation should be operationally straightforward, because businesses assume they only need to:

In practice, that assumption does not hold up under real-world operations.

Why Compliance Looks Straightforward on Paper

At the regulatory level, the obligation appears structurally similar to existing AML requirements, suggesting it can be integrated into existing compliance processes without major operational disruption. Each of these expectations appears to map onto compliance processes that businesses already operate. VASPs already operate core AML processes, including:

• Customer Due Diligence (CDD).
• Transaction Recordkeeping.
• Sanctions and Watchlist Screening.

Viewed through this lens, Travel Rule compliance for crypto businesses looks like a manageable extension of processes that firms already operate. This perception is not unreasonable, but it is incomplete. It treats compliance as a matter of internal controls, which it is, but only partially. The Travel Rule is also an interoperability obligation, and that is where the comparison with other AML requirements breaks down.

Why Implementation Breaks Down in Real Operations

Unlike KYC or Sanctions Screening, which a VASP can implement and control entirely within its own systems, crypto Travel Rule implementation requires coordination with external counterparties over whom the VASP has no authority. The originating VASP must coordinate compliance data exchange with the receiving VASP as part of the transfer process. The receiving VASP must be capable of accepting, processing, and responding to that data. If either side is unable or unwilling to fulfill its function, the process fails, regardless of how robust the originating VASP's internal controls are.

This dependency structure creates operational fragility that does not exist in most other compliance contexts. A VASP may invest heavily in its own systems and processes and still fail to comply because its counterparty lacks the infrastructure required to complete the exchange. And because the ecosystem is still maturing, asymmetries in technical readiness are the norm rather than the exception.

Policy Compliance vs Technical and Operational Compliance

A further distinction often overlooked is between policy compliance and operational compliance. A VASP can have a comprehensive Travel Rule Policy with documented procedures, assigned responsibilities, and escalation paths, yet remain operationally fragile if the underlying systems do not function as the policy assumes. Policy compliance remains largely within a VASP's control. Operational compliance instead depends on factors such as:

These are not merely internal control problems but systemic issues that manifest as operational risk, affecting even businesses making genuine, good-faith efforts to comply.

Fragmented Global Adoption of the Crypto Travel Rule

One of the most consequential features of the current regulatory landscape is that there is no single, uniform implementation of the Travel Rule. The FATF Recommendations provide a global framework, but they do not create a single enforcement regime applied uniformly across jurisdictions. Each jurisdiction that has adopted the Travel Rule has implemented it through its own domestic legal framework, following its own timeline and introducing local variations. The practical consequence is that a business operating across multiple jurisdictions is not navigating one rule but an overlapping set of requirements that differ in ways that matter operationally, undermining the expectation of a single, uniform standard.

Why the Travel Rule Does Not Operate as a Single Global Regime

The FATF Framework is built on the principle of mutual adoption. If every jurisdiction implements the same standard, the resulting network is consistent and interoperable. That principle has not been realized. Implementation rates remain uneven, enforcement timelines are staggered, and the scope of entities covered varies significantly from one regulatory regime to another.

In practice, this means that a transfer between a VASP in one jurisdiction and a VASP in another may be subject to different, and potentially conflicting, obligations on each side of the transaction. The originating VASP must comply with its domestic rules. The receiving VASP operates under its own jurisdiction's requirements. Neither set of rules was written with the other in mind. Fragmented Travel Rule implementation is therefore not a temporary gap that will resolve itself as more countries adopt the framework. It is a structural feature of how international financial regulation operates.

How Differing Timelines, Thresholds, and Scopes Create Friction

In practice, regulatory divergence appears not only in enforcement timing but also in several operational parameters that directly affect how businesses process transfers. Among the parameters that vary most consequentially between jurisdictions are:

Even small differences in threshold values create disproportionate operational complexity. A transfer that triggers the obligation in one jurisdiction may fall below the threshold in another, which means the same transaction type requires different treatment depending on the direction of the transfer. When multiplied across dozens of jurisdictions, compliance can no longer be reduced to a single standardized process. Each market segment requires its own mapping of requirements, and that mapping must be maintained as regulations evolve.

Why Cross-Border Crypto Businesses Face Higher Compliance Risk

For businesses whose transaction flows are concentrated in a single jurisdiction, the complexity, while real, is manageable. The requirements are defined, the regulatory authority is identifiable, and enforcement expectations are relatively stable. For businesses with significant cross-border crypto transfers, the picture is fundamentally different.

These businesses are exposed simultaneously to multiple regulatory regimes, each of which may impose inconsistent compliance obligations. Travel Rule cross-border compliance requires not just understanding each regime individually, but understanding how they interact, where they conflict, where one jurisdiction's requirements are more demanding, and what happens when a counterparty in another jurisdiction is unable to meet data exchange expectations. The risk is not only non-compliance but also the compounded uncertainty of operating in a landscape where the rules are genuinely ambiguous.

Lack of a Universal Technical Standard for Travel Rule Compliance

The FATF Recommendations specify what categories of information must accompany a transfer, but do not prescribe how that information must be technically transmitted or processed. They do not specify how that data must be formatted, transmitted, or verified.  This gap between content requirements and technical implementation has produced a fragmented ecosystem in which VASPs fulfill the same regulatory obligation using systems that differ in:

• Data Structure and Formatting Approaches.
• Transmission Mechanisms.
• Verification Workflows.

The absence of a universal technical standard has direct consequences for Travel Rule interoperability. When two VASPs communicate to exchange Travel Rule data, they must align on several technical and operational elements, including:

• A Compatible Data Format.
• A Reliable Method of Transmission.
• A Process for Verifying Exchanged Information.

In the absence of a mandated standard, such coordination must be negotiated between counterparties, often requiring additional integration work before data exchange becomes operationally reliable. The result is a market where interoperability depends on whether independently developed systems used by counterparties are capable of exchanging data in a compatible manner.

Travel Rule technical challenges of this kind are not problems that any individual VASP can solve unilaterally. A VASP can invest heavily in its own infrastructure and still be unable to complete a Travel Rule data exchange if its counterparty operates on systems that cannot reliably communicate with it. This is a structural market failure, not an individual compliance failure, but the regulatory burden falls on individual businesses regardless. VASP interoperability is therefore not simply a technical preference; it is a precondition for compliance.

Interoperability Challenges Between VASPs

Even where VASPs operate within the same jurisdiction and under the same technical framework, the practical exchange of Travel Rule data is rarely seamless. The market is composed of participants with widely different compliance maturity levels, technical infrastructure, and operational capacity, meaning the overall reliability of compliance data exchange ultimately depends on the least prepared participant in the transaction chain.

Consider the asymmetry in a typical transfer scenario: a well-resourced, compliance-mature exchange initiating a transfer to a smaller VASP that has recently come into scope for the Travel Rule. 

In practice, asymmetry often appears as follows. The originating VASP may: operate automated data transmission, maintain a complete audit trail, process compliance checks in near real time.

The receiving VASP, by contrast, may: rely on largely manual compliance workflows, respond to data requests with delays measured in days rather than seconds, fail to respond at all.

This asymmetry creates a specific operational problem: the originating VASP cannot complete its compliance obligations without the receiving VASP's cooperation, but it has no mechanism to compel that cooperation. It can delay or refuse the transfer, but this creates its own regulatory and commercial friction. It can proceed without the complete data exchange, but this exposes it to the risk of non-compliance. Neither option is satisfactory, and neither is an edge case. At current rates of market adoption, this scenario is routine.

The on-chain and off-chain gap adds a further layer of complexity. Blockchain transactions are executed on-chain in a matter of seconds or minutes. Travel Rule data exchange happens off-chain, through a separate messaging infrastructure. The two processes are not natively synchronized. Ensuring that off-chain compliance processes keep pace with on-chain execution, without creating unacceptable transaction delays, represents a technical and operational challenge that crypto infrastructure was not originally designed to address. VASP interoperability requires bridging that structural gap at scale.

Cross-Border Data Sharing and Privacy Constraints

Travel Rule data sharing does not occur in a regulatory vacuum. The information that VASPs are required to transmit typically includes data that directly identifies transaction participants, which qualifies as personal data under virtually all data protection frameworks worldwide. This means that once a VASP collects and transmits Travel Rule data, it becomes subject simultaneously to AML obligations requiring the exchange and data protection rules governing how personal data must be handled.

Why Travel Rule Data Immediately Falls Under Privacy Regulation

Most data protection frameworks define personal data broadly as any information relating to an identified or identifiable individual. Travel Rule data satisfies this definition by design. Its entire purpose is to identify the parties to a transaction. The data collected and transmitted under Travel Rule compliance obligations is, therefore, almost without exception, subject to data protection law.

This does not mean that Travel Rule data sharing is impermissible. AML obligations can constitute a legal basis for processing personal data, but this does not remove the obligation to comply with data protection requirements. Those requirements include obligations around data minimization, purpose limitation, storage restriction, and security, all of which interact with how Travel Rule data is collected, transmitted, and retained.

The Conflict Between Travel Rule Obligations and Data Protection Laws

The conflict between AML obligations and data protection requirements is most acute in the context of cross-border data transfers. Travel Rule and data protection obligations do not simply coexist in cross-border transactions. They can directly contradict each other.

An originating VASP in a jurisdiction with strict data localization requirements may be obligated to transmit data to a receiving VASP in a jurisdiction that does not provide equivalent data protection. Conversely, a receiving VASP operating under a framework that restricts the retention of personal data may be unable to maintain the records that its own Travel Rule obligations require. These conflicts are not hypothetical but arise predictably when two regulatory frameworks with different objectives are applied to the same transaction.

The GDPR provides a useful reference point for understanding how these restrictions apply in practice. Its requirements on cross-border data transfers, particularly the restrictions on transfers to third countries, apply to Travel Rule data in the same way they apply to any other transfer of personal data. 

Storage, Transmission, and Access Requirements Across Jurisdictions

Beyond the question of cross-border transfers, data protection frameworks impose requirements on storage duration, access controls, and deletion that interact with Travel Rule retention obligations in unpredictable ways. AML frameworks typically require records to be retained for defined periods, commonly five years, to support supervisory access and law enforcement requests. Data protection frameworks simultaneously impose obligations to delete data once the purpose for processing has been fulfilled and to restrict access on a need-to-know basis.

Managing these competing obligations requires careful design of systems and operational processes. A VASP must retain Travel Rule data long enough to satisfy AML requirements, but not longer than data protection law permits. It must make the data accessible to regulators and law enforcement when required, but restrict access for other purposes. And it must do this across multiple jurisdictions, each of which may have different retention periods, different access rules, and different enforcement expectations. Travel Rule data sharing at scale, therefore, demands a compliance architecture that addresses both regulatory regimes simultaneously.

Unhosted Wallets and Limited Control Over Counterparties

The Travel Rule was designed around a VASP-to-VASP transaction model: an originating VASP transmits data to a receiving VASP, which verifies and retains it. This model has a built-in assumption: there is always an identifiable institutional counterparty on both sides of the transaction. That assumption does not hold when one side of the transaction is an unhosted wallet.

In transactions involving unhosted wallets, assets are controlled directly by users rather than through a VASP intermediary. There is no institution to receive and process Travel Rule data. There is no entity that can verify the beneficiary's information, maintain records, or respond to supervisory requests. The symmetric structure on which the Travel Rule is premised simply does not exist. Travel Rule unhosted wallets, therefore, create a compliance gap because the standard VASP-to-VASP exchange model no longer applies.

This creates a structural dilemma for businesses that process transfers to or from unhosted wallets, exposing them simultaneously to risks of over-compliance, where transactions are restricted beyond regulatory intent, and under-compliance, where obligations cannot be fully satisfied due to the absence of a counterparty. The originating VASP may be required to collect and transmit beneficiary information, but there is no institutional recipient. It may be required to verify the beneficiary’s ownership of the wallet, yet the transaction structure offers no reliable institutional counterparty through which this verification can occur. And it may be required to demonstrate that it has met its Travel Rule obligations, but the absence of a counterparty makes that demonstration inherently incomplete.

Unhosted wallets' Travel Rule compliance requirements vary by jurisdiction. Some jurisdictions require Enhanced Due Diligence (EDD) for all transfers above a threshold that involve unhosted wallets. Others apply the standard Travel Rule framework and leave businesses to manage the gap. Some are still developing their approach. The result is a compliance landscape in which the same transaction type is treated differently depending on where the originating VASP is located, compounding the fragmentation that already exists at the jurisdictional level. The structural problem is not a policy failure but a consequence of applying an institutional compliance model to a system designed to enable peer-to-peer value transfer without institutional intermediaries.

Compliance Responsibility vs Operational Control

Of all the challenges examined in this article, the gap between compliance responsibility and operational control is perhaps the most consequential. It is also the one that is most frequently underestimated at the policy level.

Why Compliance Responsibility Remains With the Crypto Business

Regulatory frameworks consistently place compliance responsibility on the VASP. It is the entity that is licensed, supervised, and subject to enforcement. If Travel Rule data is not transmitted, not verified, or not retained, the VASP is accountable, not its counterparty, not its technology provider, not the standard-setting body that failed to specify a universal protocol.

Travel Rule compliance responsibility typically rests with the originating VASP regardless of whether the counterparty cooperates. This is the foundation of the rule's logic: a VASP should not be able to evade compliance simply by selecting counterparties that are unwilling or unable to participate. But the corollary, which is rarely articulated directly, is that VASPs are expected to achieve compliance outcomes in conditions that they cannot fully control.

Why Technical Control Over Counterparties Is Inherently Limited

In practice, a VASP's ability to ensure Travel Rule compliance depends substantially on factors outside its systems and direct operational control. It cannot compel a counterparty VASP to upgrade its infrastructure. It cannot dictate the format in which data is transmitted and received. It cannot guarantee that its counterparty's compliance team will process Travel Rule data within the time window required for the transaction.

In traditional correspondent banking, this problem is addressed through bilateral agreements between institutions that have vetted each other through a due diligence process. The relationship is established before any transaction occurs, and the terms of the relationship include compliance expectations. In the crypto ecosystem, transactions can occur between VASPs that have never previously interacted, using addresses that are identified in real time and without any pre-existing relationship. The infrastructure required for pre-transaction counterparty vetting at the scale and speed demanded by crypto operations does not yet exist uniformly across the market.

The Gap Between Regulatory Expectations and Real-World Control

This gap between regulatory expectations of compliance and the operational reality of limited control is where Travel Rule compliance for crypto businesses becomes most acute. It is not a gap that can be closed simply by improving internal processes. A VASP that has invested in the most comprehensive travel rule implementation available can still face situations in which compliance is impossible because the counterparty is not technically capable of completing the data exchange.

Some regulatory authorities are beginning to acknowledge this tension. Some enforcement frameworks distinguish between VASPs that have made good-faith efforts to comply, including attempting to initiate data exchanges, documenting failed attempts, and applying risk-based mitigations and those that have made no effort at all. This distinction is meaningful, but it does not resolve the underlying structural problem. It merely creates a tiered enforcement landscape in which businesses must demonstrate due diligence for failures that were not, in any meaningful sense, within their control.

The risk implications are significant. A VASP that cannot complete a Travel Rule data exchange faces a binary choice: decline the transaction, with the customer experience and commercial consequences that entail, or proceed and accept the compliance risk. Neither option is cost-free. And neither option exists because of any failure on the part of the VASP. It exists because the architecture of the compliance obligation does not match the architecture of the market it is being applied to. This represents the core structural challenge of Travel Rule implementation: a misalignment between accountability and control, with compliance risk concentrated on the party least able to resolve the underlying problem.

Operational and Cost Burden for Crypto Businesses

The compliance challenges described in this article do not exist in isolation. Each one has direct operational consequences, introducing additional workflows, staff involvement, infrastructure requirements, and friction into processes that businesses depend on to operate efficiently.

Customer onboarding is one area where the effects are most visible. Travel Rule implementation requirements do not end at the point where a customer passes KYC. The business must also be able to associate that customer's transactions with travel rule data exchanges, incoming and outgoing, and ensure that the data is correctly attributed, stored, and retrievable. For businesses with high transaction volumes, this creates a sustained operational burden rather than a temporary adjustment.

Transaction processing is another affected area. Where Travel Rule data exchange cannot be completed before a transaction is processed, the business must maintain and manage a queue of pending compliance tasks alongside live transaction flows. Errors, timeouts, and data mismatches frequently require manual review and resolution. Over time, the accumulation of these edge cases creates a compliance backlog that must be actively managed, and that creates its own audit trail obligations.

The engineering load is also substantial. Integrating Travel Rule functionality into existing systems requires ongoing maintenance as requirements evolve, as counterparty connectivity changes, and as data format standards are updated. This is not a one-time integration effort. It becomes a recurring operational commitment that competes with other development priorities and must be sustained even as regulatory expectations continue to evolve.

User experience is an additional dimension. Transaction delays introduced by Travel Rule data exchange requirements are perceptible to users. Requests for additional identification information triggered by unhosted wallet interactions or counterparty verification failures can create friction that affects customer satisfaction and retention. Travel Rule compliance challenges, therefore, create operational consequences that extend beyond the compliance function itself.

Why Travel Rule Implementation Remains a Moving Target

Even businesses that have successfully navigated the initial challenges of Travel Rule implementation cannot treat compliance as a completed task. The regulatory landscape is not static.

FATF conducts regular reviews of its Recommendations and issues updated guidance that reflects evolving risks and emerging compliance gaps. National regulators transpose and update their Travel Rule frameworks in response to both FATF guidance and domestic enforcement experience. Thresholds may be revised, definitions refined, and the scope of entities covered expanded over time. Each update requires businesses to reassess their compliance architecture and, in many cases, to modify systems and processes that were built around an earlier version of the requirements.

Enforcement practices also evolve independently of formal regulatory updates. Regulators gain experience with the rule in practice and form views about what good compliance looks like. The standards applied in supervisory examinations and enforcement actions may be more demanding than the formal regulatory text suggests. Businesses that benchmarked their compliance posture against the regulatory minimum at the time of implementation may later find that the standard is insufficient as enforcement practices mature.

A specific driver of ongoing evolution is the continuing development of Travel Rule frameworks in major jurisdictions. The EU's Markets in Crypto-Assets (MiCA) regulation and accompanying Transfer of Funds Regulation introduce a comprehensive framework for crypto-asset service providers that is already reshaping compliance expectations across the bloc. In the US, regulatory development continues across multiple agencies with overlapping jurisdiction. The next articles in this series address these jurisdiction-specific frameworks and how businesses operating in those markets must navigate them, examining EU and US Travel Rule requirements in detail.

Conclusion

The challenges explored in this article are systemic. They are not the product of inadequate effort on the part of the businesses that encounter them. They arise from a fundamental tension between the design of the Travel Rule, built on assumptions of institutional intermediation, bilateral coordination, and jurisdictional uniformity, and the architecture of the crypto ecosystem, which is distributed, fast-moving, and structurally resistant to the kind of pre-transaction coordination that the rule presupposes.

Jurisdictional fragmentation, the absence of universal technical standards, the inherent limitations of counterparty control, the interaction with data protection law, the structural problems posed by unhosted wallets, and the continuously evolving regulatory landscape are not problems that any single business can solve unilaterally. They reflect ecosystem-wide constraints that individual businesses must navigate rather than resolve, requiring firms to continuously adapt their compliance architectures to evolving regulatory and market realities.

These challenges are best understood as structural features of the compliance environment rather than individual compliance failures. Understanding where the gaps exist, how they interact, and why they persist is the necessary foundation for building compliance programs that are genuinely resilient programs capable of functioning effectively even in conditions of incomplete counterparty cooperation, evolving regulatory expectations, and unresolved technical fragmentation. The emergence of specialized approaches to Travel Rule compliance reflects these realities, representing a practical response for businesses operating in a complex and still-developing regulatory environment.

-AMLBot Team

Follow AMLBot:
🔗 Website
🔗 Telegram
🔗 Support Team
🔗 LinkedIn

FAQ

The financial regulatory landscape of the European Union has undergone a transformation with the introduction of the new Anti-Money Laundering (AML) package, specifically targeting the sector of digital assets. Central to this transformation is the implementation of the EU Crypto Travel Rule, codified under Regulation (EU) 2023/1113, also known as the Transfer of Funds Regulation (TFR).

This regulation marks a shift from the previous directive-based approach to a harmonized, directly applicable framework that ensures the traceability of crypto-asset transfers across all twenty-seven Member States. By requiring that information on the originator and beneficiary "travels" with each transaction, the Union aims to eliminate the pseudonymity that has historically made crypto-assets attractive for illicit financial flows.

What Is the EU Crypto Travel Rule?

The EU Crypto Travel Rule is the Union’s specific legal answer to the challenges posed by the adoption of virtual assets and the potential for their misuse in money laundering and terrorist financing.

Legally embodied in Regulation (EU) 2023/1113, it serves as a "recast" of the earlier 2015 regulation which applied strictly to traditional funds like banknotes and electronic money. The expansion of this mandate to include "certain crypto-assets" represents the EU's commitment to the principle of "same activity, same risk, same rules," ensuring that the technological medium of a transfer does not exempt it from the transparency standards expected in the broader financial system.

Unlike the Recommendations issued by the Financial Action Task Force (FATF), which provide a non-binding framework for nations to adapt, the TFR is a "binding regulation." This distinction is critical for any compliance officer or legal counsel; as a regulation, it is directly applicable in every Member State without the need for national transposition into local law. This direct applicability effectively creates a single EU standard, preventing "regulatory arbitrage" where firms might seek to operate from jurisdictions with more lenient interpretations of AML directives.   

The core mechanism of the rule is the mandatory collection and transmission of identity data. When a transfer occurs, the originating service provider must ensure that specific details about the sender accompany the transaction to the beneficiary's service provider. This is not merely a record-keeping exercise but a real-time transparency requirement intended to provide law enforcement and financial intelligence units (FIUs) with a clear "paper trail" on the blockchain. The regulation explicitly states that the soundness and stability of the financial system could be jeopardized if criminals are able to disguise the origin of proceeds through anonymous virtual asset transfers. 

Who Must Comply: CASPs Under EU Law

Identifying the scope of the regulation requires an understanding of the legal entities defined under the broader European digital asset framework.

The TFR applies to "Crypto-Asset Service Providers" (CASPs), a term that is inextricably linked to the Markets in Crypto-Assets (MiCA) Regulation (EU) 2023/1114.

What Qualifies as a Crypto-Asset Service Provider

According to Article 3(1) of MiCA, a CASP is any legal person or undertaking whose professional business is providing one or more crypto-asset services to clients. The definition is purposefully broad to capture the full spectrum of the modern crypto-economy. While basic exchange and custody are the most common services, the EU definition encompasses several categories that go beyond the traditional FATF baseline. For a detailed analysis of the licensing landscape, businesses should consult the expert guide on how MiCA defines crypto-asset service providers to ensure their specific business model is appropriately categorized.

Under MiCA, and by extension the Travel Rule, the following activities fall under the regulated definition of a CASP:

In the European Union, the net is cast much wider than what you might see in other parts of the world. It isn’t just about the big-name exchanges, the regulation is designed to capture almost anyone who handles crypto-assets professionally.

If your business provides Custody and Administration, meaning you’re the one safeguarding private keys or client assets, you’re essentially a digital vault and definitely a CASP. Then there are the Trading Platforms and Exchanges. Whether you’re helping people swap Bitcoin for Euros (fiat-to-crypto) or just trading one token for another (crypto-to-crypto), the EU sees you as a vital link in the chain that needs to be transparent.

What’s interesting is that the EU includes services that are often considered "ancillary" elsewhere. For instance, Providing Advice or Portfolio Management—basically telling people what to buy or managing their "bags" for them—now puts you firmly in the regulated zone.This is part of the EU's "gold-plating" strategy, where they’ve gone beyond international minimums to ensure that crypto-advisors are held to the same high standards as traditional financial planners.

Finally, we have the "movers and shakers": Execution of Orders, Placing, Reception and Transmission of Orders, and Transfer Services. In plain English, if your platform is the one making sure a trade actually happens or is responsible for moving those assets from Point A to Point B, you are on the hook for the Travel Rule.

For crypto businesses, this means you can’t just be a "tech layer" anymore. If you touch the transaction or the decision-making process, you're a regulated financial entity with specific data-sharing duties.

CASPs vs VASPs — Terminology Differences

In the global regulatory arena, the Financial Action Task Force uses the term "Virtual Asset Service Provider" (VASP). While many industry participants use VASP and CASP interchangeably in informal settings, the legal distinction is vital for compliance in Europe. VASP is the global, standards-based term, whereas CASP is the specific, legally defined entity under EU law.   

The EU's CASP designation is significantly more comprehensive than the FATF's VASP definition. For example, the FATF definition does not explicitly cover "Advice" or "Portfolio Management" in the same prescriptive manner as MiCA. Furthermore, the move to a CASP framework represents a transition from simple "registration" (common under the old national regimes like France's PSAN) to "authorization" (a full license). Entities operating in the EU that previously held VASP status under national laws must transition to the MiCA CASP authorization by July 1, 2026, or risk severe administrative penalties, including the cessation of their activities.

Key Travel Rule Obligations for CASPs

The TFR imposes a dual responsibility on CASPs depending on their role in the transaction chain. An entity may act as the "Originating CASP" (sending the transfer) or the "Beneficiary CASP" (receiving the transfer), and in some instances, as an "Intermediary CASP".   

Required Originator and Beneficiary Information

Articles 14, 15, and 16 of Regulation (EU) 2023/1113 specify the precise data fields that must accompany every crypto-asset transfer. The regulation differentiates between transfers where all service providers are established within the Union and those involving a party outside the EU.   

For a standard transfer, the following information must be collected and transmitted:

1. Originator (Sender) Information:
   • Full Name (Natural or Legal Person).   
   • Distributed Ledger (Wallet) address and/or the crypto-asset account number.   
   • One of the Following: residential address, official personal document number, customer identification number, or date and place of birth.   
   • The Legal Entity Identifier (LEI) of the originator, where available.   
2. Beneficiary (Recipient) Information:
   • Full Name.   
   • Distributed ledger address and/or account number.   
   • The LEI of the beneficiary, where available.   

Responsibility for Data Accuracy and Transmission

The Originating CASP bears the primary burden of verification. Before initiating the transfer, it must verify the accuracy of the originator’s information based on documents or data obtained from reliable and independent sources, essentially fulfilling the KYC requirements of the AML framework. This information must be transmitted to the Beneficiary CASP "securely" and "simultaneously or concurrently" with the transfer on the blockchain.   

The Beneficiary CASP, upon receiving the transfer, must implement effective risk-based procedures to detect if the required information is missing or incomplete. If the incoming data is deficient, the Beneficiary CASP must decide—based on the assessed risk—whether to execute, reject, return, or suspend the transfer. Furthermore, repeated failures by a counterparty to provide required information must be reported to the relevant national authority and may necessitate the termination of the business relationship with that non-compliant counterparty.

Thresholds and Scope of Application in the EU

Perhaps the most significant divergence from international norms is the EU's decision regarding transaction thresholds. While the FATF recommends a $1,000 threshold below which data requirements are less stringent, the European Union has adopted a "Zero-Threshold" policy for transfers between CASPs.   

This means that for every crypto-asset transfer facilitated by a CASP in the EU—regardless of whether the amount is ten euros or ten thousand euros—the Travel Rule obligations apply in full. The rationale for this strict stance is that the inherent nature of crypto-assets allows for "smurfing"—breaking down large transactions into many small ones to evade detection. By removing the threshold, the EU closes a loophole that has traditionally been exploited by illicit actors.   

There is one limited exception: for transfers where all service providers involved in the chain are established within the Union, the transmitted information may be restricted to the account numbers or unique transaction identifiers, provided the full information can be made available to authorities within three working days upon request. This "reduced information" rule is designed to facilitate efficiency within the single market while maintaining the capability for full investigative transparency.   

Travel Rule and Unhosted Wallets

The interaction between regulated CASPs and "unhosted wallets" (also known as self-hosted or private wallets) represents a complex regulatory frontier. An unhosted wallet is one where the user maintains sole control over the private keys.

When Unhosted Wallet Transactions Trigger Obligations

The TFR imposes mandates on CASPs when they are involved in a transaction with an unhosted address. When an EU CASP initiates a transfer to or receives one from an unhosted wallet, it must collect and hold information about both the originator and the beneficiary.

Risk-Based Controls for Interactions With Unhosted Wallets

The TFR introduces a mandatory verification step for transfers involving unhosted wallets when the amount exceeds €1,000. In these cases, the CASP must verify whether its customer actually owns or controls the unhosted address.

According to the EBA Guidelines (EBA/GL/2024/11), acceptable technical verification methods include:

• Cryptographic Signature: The customer signs a unique message using the private key.
• Micro-transaction (Satoshi Test): The customer sends a small, predefined amount from the unhosted wallet to the CASP.
• Digital Signature: Utilizing qualified electronic certificates under EU law.

If the transaction is below the €1,000 threshold, the CASP must still collect the data but is not legally mandated to perform technical verification unless there is a suspicion of money laundering.

How the EU Approach Goes Beyond the FATF Standard

The European Union's implementation of the Travel Rule imposes requirements that go significantly beyond the FATF minimums:

1. Zero-Threshold Policy. Data is required for all transfers between CASPs, unlike the FATF's $1,000 "de minimis" threshold.
2. Prescriptive Unhosted Wallet Verification. The EU mandate for technical verification at the €1,000 level is much more stringent than the general "risk-based approach" suggested by the FATF.
3. Directly Applicable Regulation. By choosing a Regulation (TFR) over a Directive, the EU ensures a unified "Single Rulebook" across all Member States.

Travel Rule vs Other EU AML Obligations

The Travel Rule is one of three essential pillars that form the EU's regulatory perimeter for crypto-assets.

Travel Rule, AMLR, and KYC — Different but Connected Duties

These three frameworks apply in parallel to form a comprehensive "compliance contour":

• MiCA (Markets in Crypto-Assets). Governs the entities. It covers licensing, capital reserves, and governance.
• TFR (Travel Rule). Governs the transactions. It focuses on real-time identity data transmission during transfers.
• AMLR (Anti-Money Laundering Regulation). Governs the risks. It covers broad Customer Due Diligence (CDD) and ongoing monitoring.

These obligations work together: a CASP uses KYC (under AMLR) to identify a client at onboarding. Then, when that client sends a transfer, the CASP uses TFR protocols to share that verified identity.

What EU CASPs Should Focus on From a Compliance Perspective

CASPs must ensure that their internal compliance processes support the accurate collection, verification, and timely transmission of required originator and beneficiary information in accordance with EU regulatory obligations. Supervisory authorities expect compliance procedures to function consistently across all applicable crypto transfers, including those involving higher-risk scenarios. From a regulatory perspective, CASPs should focus on ensuring that Travel Rule obligations are consistently fulfilled across all relevant crypto transfers. Key compliance priorities include:

(a) Ensuring accurate collection and transmission of originator and beneficiary information in line with Transfer of Funds Regulation requirements.

(b) Maintaining procedures that allow timely and reliable information exchange between service providers when transfers occur.

(c) Applying appropriate compliance controls and transaction monitoring processes in line with EU AML obligations, particularly for higher-risk scenarios.

Failure to comply can lead to administrative fines, license revocation, and criminal charges against executives for systemic AML failures.

Conclusion

The implementation of the EU Crypto Travel Rule establishes a global benchmark for transparency. For CASPs, compliance is a core operational requirement linked to their MiCA authorization. As the Union moves toward the 2026 unified AML framework under the supervision of the AMLA, the ability to seamlessly transmit and verify transaction data will determine the longevity of crypto businesses in the EU market.

Note: None of this information should be considered as legal, tax, or investment advice. While we’ve done our best to ensure this information is accurate at the time of publication, laws and practices may change, so please double-check it.  

FAQ

Date: February 3, 2026
Incident Type: Smart-Contract Exploit (Unlimited Approval)
Total Losses: ~$13,500,000+

In late January 2026, the DeFi ecosystem was rocked by a series of linked exploits targeting Aperture Finance and 0xswapnet. Despite serving different niches, both protocols fell victim to the same critical architectural flaw: the improper handling of unlimited token approvals.

The AMLBot team, utilizing our blockchain analytics tool Tracer, has conducted a comprehensive forensic analysis of the fund flows. Our findings reveal a sophisticated laundering operation and a direct link to the notorious Li.Fi attacker network.

Aperture Hack: On-Chain Tracing Connects Exploit to https://t.co/ipnSUAr103 Attacker Network⁰
Both @ApertureFinance and @0xswapnet contracts were exploited due to unlimited token approvals. So far, only Aperture Finance has publicly acknowledged the vulnerability and has already… pic.twitter.com/l8hDnivvOj

— AMLBot (@AMLBotHQ) January 27, 2026

The Anatomy of the Exploit

The breach centered on an "arbitrary call" vulnerability. Attackers manipulated contract functions to trigger unauthorized transferFrom operations. Essentially, any user who had previously granted these protocols "infinite approval" for their tokens had their balances siphoned directly into the attacker’s control.

While Aperture Finance has proactively acknowledged the vulnerability and initiated on-chain communication with the perpetrator, the scale of the drain across both platforms remains significant.

On-Chain Overview via AMLBot Tracer

Using Tracer, we mapped the primary flow of stolen assets, beginning with the attacker's main hub on the Base network:

Main Attacker Address: 0x6cAad74121bF602e71386505A4687f310e0D833e

Phase 1: Consolidation and Conversion

The attacker successfully extracted approximately $13 million in various assets:

• ~$3M USDC remains untouched on the original Base address, likely due to liquidity monitoring or potential freezing risks.
• The remaining alt-assets were swiftly swapped into ETH.
• Currently, ~540 ETH is being held at the primary entry point.

Phase 2: Cross-Chain Laundering Pattern

The perpetrator employed a professional-grade laundering route to obfuscate the paper trail. Funds were moved from Base to Ethereum Mainnet using high-throughput bridging protocols: Relay Protocol/ Superbridge.

Once the funds reached Ethereum, they were dispersed across a network of fresh intermediary wallets. Interestingly, these wallets are currently dormant, though they have become targets for address poisoning attempts by third-party scammers hoping to capitalize on the high balances.

The "Copycat" and the Li.Fi Connection

Our clustering analysis identified a second, distinct wave of activity occurring hours after the initial exploit. This "copycat" attacker focused on Aperture Finance specifically, holding funds at:

• 0xe3E73f1E6acE2B27891D41369919e8F57129e8eA (~$3.2M)
• 0x5FF8645BbC6c8B4390aA228A3e8bf08240F333b4 (~$15K)

Our tracing shows that the second address was funded via Tornado Cash over a year ago. Most importantly, our database links this specific wallet cluster to the Li.Fi Protocol / Jumper Exchange attacker.

This suggests that the Aperture exploit was not just a one-off hit but was picked up by a sophisticated threat actor group that specializes in "infinite approval" vulnerabilities.

What This Means

This incident serves as a reminder of the "toxic legacy" of infinite approvals. Even if a protocol is audited or reputable, a single unvalidated low-level call can turn a user's approval into a backdoor for drainers. AMLBot continues to monitor all associated wallets.

-AMLBot Team

Follow AMLBot:
🔗 Website
🔗 Telegram
🔗 Support Team
🔗 LinkedIn

AMLR is now in force and is reshaping how crypto businesses in Europe approach KYC obligations. This article explains why AMLR does not “add KYC from scratch,” but reorganizes existing EU AML requirements into a single, stricter EU regulation — shifting KYC compliance from a one-time onboarding check to a continuous, risk based process tied to customer identity, transaction activity, and ongoing monitoring. It also clarifies how the Travel Rule reinforces traceability expectations and why governance controls and accountability have become central to meeting regulatory expectations under the EU AML framework.

Intro: In 2026, the European Union’s new Anti-Money Laundering Regulation (AMLR) officially came into force, heralding a unified EU AML Framework that reshapes how crypto businesses approach Know Your Customer (KYC) compliance. Unlike previous rules, which varied by country under different EU directives, AMLR creates a single EU standard for Anti-Money Laundering (AML) and Countering Terrorist Financing (CTF). 

This means KYC obligations for crypto businesses are now defined at the EU level, bringing consistency and transparency across all member states. The practical enforcement and supervisory expectations under AMLR are still developing, but crypto firms in Europe are already adapting to AMLR as the new normal for compliance. 

This article, written from a legal perspective but in clear terms for any reader, explores how AMLR changes KYC duties for crypto service providers – not by introducing KYC from scratch, but by strengthening and reorganizing it as a continuous, risk-driven process within a unified European framework. We’ll see how KYC compliance under AMLR moves from one-off identity checks to ongoing monitoring, ties customer identity to actual transactions (including the Travel Rule for fund transfers), and raises the bar on governance and accountability. Rather than offering a checklist or product pitch, the goal is to provide crypto businesses with context on the regulatory landscape and the regulatory expectations set by AMLR.

Note: None of this information should be considered as legal, tax, or investment advice. While we’ve done our best to ensure this information is accurate at the time of publication, laws and practices may change, so please double-check it.  

AMLR and the EU AML Framework — Where KYC Fits Today

AMLR is a centerpiece of the EU’s recent AML Package (2024–2026), which overhauls Europe’s approach to fighting financial crime. The package includes: a new EU AML Authority (AMLA) to oversee and coordinate supervision; an updated Transfer of Funds Regulation for crypto traceability; and AMLR – a single, directly applicable regulation that compiles all private-sector AML/CFT obligations. 

In this new setup, KYC obligations take on a central role. All rules previously set out in national laws under AML directives (such as Customer Due Diligence requirements from the 4th and 5th AML Directives) are now consolidated into AMLR as common EU AML/CFT rules. This directly applicable regulation harmonizes and clarifies expectations for “obliged entities”, ensuring a consistent baseline for KYC compliance across Europe. 

Put simply, KYC – the duty to identify customers, verify their identities, monitor transactions, and report suspicions – is no longer just guided by EU directives interpreted differently across countries. Instead, AMLR embeds KYC into a unified EU framework with clear, binding rules for all member states.

Under AMLR, crypto-asset service providers (CASPs) – which include cryptocurrency exchanges, custodial wallet providers, and other crypto businesses – are explicitly listed as obliged entities for the first time in an EU regulation. 

Previously, the EU’s 5th AML Directive had already brought certain crypto services under AML rules via national laws, but approaches differed by country. Now that AMLR is in force, the role of KYC in the EU AML framework is firmly established: it is a core obligation applied uniformly to banks, fintech companies, and crypto providers alike. This change reflects the EU’s policy that the crypto sector should no longer operate on the fringes of AML compliance, but instead be fully integrated into the EU AML regime. AMLR’s adoption in mid-2024 and phased implementation through 2025–2026 means that as of 2026, KYC is part and parcel of doing crypto business in Europe’s single market, backed by EU law and overseen by EU and national authorities.

From Fragmented Rules to a Unified AMLR Approach

Prior to AMLR, EU KYC requirements were set out in directives (like 4AMLD and 5AMLD), which each member state transposed into its own national laws. While the overall objectives were shared, this led to fragmentation – different countries imposed slightly different KYC procedures, interpretations, and thresholds. 

For crypto firms operating across borders, onboarding, and verification rules could vary from one EU jurisdiction to another. This layered compliance created uncertainty and opportunities for regulatory arbitrage, where bad actors could exploit the weakest link. Now, AMLR replaces that disconnected system with one regulation that applies uniformly across all EU countries, effectively creating a single rulebook for AML/KYC. The EU regulation “exhaustively harmonizes” the rules, closing loopholes and eliminating divergent national approaches. 

In practice, this means the core KYC obligations – Customer Identification, Due Diligence, Record-Keeping, Ongoing Monitoring – are defined the same way for all crypto businesses in Europe, whether they operate in France, Germany, or any other member state.

The approach under AMLR reduces compliance inconsistency. Crypto exchanges and other VASPs (Virtual Asset Service Providers, as defined by FATF globally) no longer have to navigate a confusing set of national KYC rules. Instead, they follow a single EU-wide standard. 

As the EU Council noted, the new regulation will be applied more consistently and better enforced across the EU. For example, under AMLR, all CASPs must verify customers and report suspicious activity; a crypto business cannot avoid strict KYC by choosing a member state with laxer implementation, because AMLR is directly applicable. The outcome is a more coordinated AML framework where criminals “will have no space left” to exploit gaps between countries. In essence, AMLR has transformed KYC in Europe from a patchwork of local practices into a cohesive, EU-supervised process, marking a new era of unified compliance for the crypto industry.

How AMLR Changes the Structure of KYC Obligations

AMLR fundamentally reshapes KYC implementation, moving from a formality at onboarding to a continuous, risk-based process woven into business operations. Under earlier regimes, many crypto companies treated KYC as a one-time event: collect ID documents when registering a new customer, perform basic checks, and then consider the obligation fulfilled unless something obvious triggered a review. AMLR turns that approach on its head. It reconceives KYC as an ongoing obligation that lasts throughout the customer relationship, with intensity proportional to risk. So, compliance in 2026 is about continuously Knowing Your Customer – updating information, monitoring behavior, and reassessing risk as circumstances change. 

In this section, we break down three key ways AMLR changes KYC obligations: by enforcing KYC as a continuous risk-based process, by tightening the link between customer identity and customer activity, and by incorporating the Travel Rule to enhance transparency of crypto transactions.

KYC as a Continuous, Risk-Based Process

Risk-Based KYC is at the heart of AMLR. This means crypto businesses must calibrate their KYC measures to the assessed risk of each customer and service – applying more powerful due diligence for higher-risk cases and simpler steps for lower-risk ones. Crucially, AMLR embeds the idea that KYC is not a one-off task at onboarding, but an ongoing process that requires regular review. 

The regulation explicitly requires:

“conducting ongoing monitoring of the business relationship,” including scrutiny of transactions over time, “to ensure that the transactions being conducted are consistent with the [company]’s knowledge of the customer, [their] business and risk profile”. 

In other words, compliance teams must continuously evaluate whether a customer’s account activity aligns with the information they have about that customer. If a normally low-volume retail customer suddenly starts moving large sums of crypto, the business must notice and react – that could mean updating the customer’s risk rating, requesting additional information, or filing a suspicious transaction report.

To facilitate this, AMLR mandates that customer data and documentation be kept up to date. Companies are obliged to periodically refresh and verify the information they hold on customers, rather than simply archive it after onboarding. According to the regulation, during ongoing monitoring,

“obliged entities shall ensure that the relevant documents, data, or information of the customer are kept up to date.” 

This might involve asking customers to reconfirm identity details or provide new proof of address after a certain period, especially for higher-risk accounts.

Additionally, AMLR embraces dynamic risk management:

“Business relationships are likely to evolve as the customer’s circumstances and activities change over time… obliged entities should [periodically] review information from their customers, in accordance with the risk-based approach. Such reviews should also be triggered by changes in relevant circumstances… when facts indicate a potential change in the risk profile or identification details of the customer.” 

In practice, this means that a change (e.g., a client’s name change, a spike in transaction volume, or news that the client is being investigated for fraud) should prompt the crypto business to promptly update the client's KYC and risk assessment. 

So, this continuous KYC approach requires internal systems. Crypto businesses need to integrate Identity Verification, Transaction Monitoring, and Risk Scoring to generate alerts when deviations from the norm occur. 

Instead of a static KYC file gathering dust, AMLR envisions KYC as a living customer profile that is constantly refined. Importantly, being risk-based does not mean being lax – the regulation stresses that the risk-based approach is “not an unduly permissive option” but rather a disciplined, evidence-driven method to effectively target the highest risks. Supervisors will expect crypto companies to demonstrate that their KYC measures are commensurate with the risks identified. 

Stronger Link Between Customer Identity and Activity

Another structural change AMLR brings is a much tighter link between WHO the customer is (their verified identity and profile) and what the customer DOES (their transactions and usage of the service). 

In the past, some crypto providers approached KYC as merely collecting a passport or ID from the user and then considering their job done unless something went wrong.

AMLR makes clear that knowing the customer’s identity is only the first step – that knowledge must inform ongoing scrutiny of the customer’s activities. The regulation requires that customer identity information and customer activity be linked for monitoring. Specifically, businesses must watch the customer’s transactions in light of the customer’s known profile to detect inconsistencies. AMLR’s text mandates:

“ongoing monitoring of the business relationship, including scrutiny of transactions… to ensure that the transactions being conducted are consistent with the obliged entity’s knowledge of the customer, the business, and risk profile, including, where necessary, the source of funds.” This effectively operationalizes the old adage “Know Your Customer, and Know Your Customer’s Transactions.”

For crypto businesses, this means KYC isn’t just about verifying a user’s name and ID once. It means continually asking: Does this transaction make sense for this customer? If, for example, a customer identified as a small investor suddenly receives a large amount of crypto from dozens of wallets, a well-implemented AMLR program would flag this as unusual. The firm would then be expected to investigate – perhaps requesting information on the source of those funds or the purpose of the transactions – and determine if it’s legitimate or suspicious. Under AMLR, customer identity data (like name, birthdate, identity documents, proof of address, business type, etc.) must be meaningfully linked to transaction monitoring. The regulation even emphasizes understanding the nature and purpose of the customer’s business or relationship, so that the compliance team has context for what types of transactions to expect.

By strengthening the identity-activity link, AMLR essentially merges what is sometimes called KYC (knowing who your customer is) with what some dub KYT – “Know Your Transactions” or understanding the customer’s transaction behavior. Crypto firms are expected not only to collect customer identity information but also to use it in risk-monitoring algorithms and reviews. 

For instance, if a customer told the exchange during onboarding that they plan to trade at most €5,000 per month, and later they start transacting €50,000 per week, the discrepancy should trigger action. It also implies a feedback loop: if monitoring uncovers new information (say, the customer is actually engaged in a business that they initially didn’t disclose), the firm should update the customer’s profile and potentially re-verify certain customer identity details or apply enhanced due diligence. AMLR therefore creates a more holistic KYC framework, where identity verification, risk profiling, and transaction oversight inform each other within a unified process for AML compliance obligations.

The Role of the Travel Rule in AMLR-Driven KYC

No discussion of AMLR and crypto KYC is complete without mentioning the Travel Rule. 

The Travel Rule refers to requirements for financial institutions to include and exchange identifying information about the sender and receiver in payment transfers – a concept long applied to bank wires and now extended to crypto-asset transfers. 

In the EU context, the Travel Rule for crypto was implemented through an update of the Transfer of Funds Regulation (TFR), which was part of the same legislative package as AMLR. While technically a separate regulation, the Travel Rule’s implementation works hand-in-hand with AMLR to reinforce KYC obligations. Under the new rules, crypto-asset service providers must collect and make available certain information about the originator and beneficiary of each crypto transfer. This means whenever a customer of a crypto exchange sends crypto to an external wallet or receives crypto, the service provider is obligated to attach identifying information (such as names, account numbers, customer ID, etc.) to that transfer and share it with the receiving or sending institution, just as banks do for wire transfers.

The Travel Rule externalizes KYC. It forces crypto businesses to utilize their KYC data at the transaction level, ensuring that identity information “travels” with the funds. 

Practically, for a crypto exchange, this means that if Alice wants to send 1 Bitcoin from her account to Bob’s account at another exchange, Alice’s exchange must transmit Alice’s identifying info (and possibly Bob’s info, depending on the situation) along with the transaction, and Bob’s exchange must verify and retain that info. To comply, crypto businesses need systems to tie verified customer identities to both incoming and outgoing transfers and to securely communicate that data to other institutions or authorities. This increases the importance of upfront identity verification and ongoing data management. 

AMLR and associated regulations “ensure crypto-asset transfers are traceable so that it is easier to identify potentially suspicious transactions and block them,” aligning the EU with the “most demanding international standards” in this area.

From a KYC perspective, the Travel Rule means that knowing your customer is not enough. You also have to know the counterparties involved in your customer’s crypto transactions. If a customer is sending crypto to a self-hosted wallet (their own private wallet), AMLR requires exchanges to take risk-based measures, which could include verifying that the wallet is owned by the customer or even prohibiting transfers to high-risk unhosted wallets. If the transfer is to another exchange, both sides share KYC details. 

The Travel Rule thus cements the integration of KYC into transaction processing: identity data isn’t just collected and stored in a silo; it actively accompanies transactions and enables traceability. 

Globally, this reflects FATF Recommendation 16, and FATF has made clear that VASPs “need to… obtain, hold and securely transmit originator and beneficiary information when making transfers.” 

By embedding the Travel Rule, AMLR forces crypto businesses to extend their KYC programs beyond their own customer base to the wider network of transfers. This elevates compliance obligations, as firms must invest in information-sharing technologies and protocols and ensure data accuracy. 

What AMLR Means for Crypto Businesses Operating in Europe

For crypto businesses operating in Europe, AMLR’s entry into force signals a new compliance reality. The regulation’s impact is broad, affecting who is covered, what internal controls are needed, and how accountability is enforced. In essence, AMLR brings crypto businesses into line with the standards long applied to traditional financial institutions. Companies that provide crypto-related services in the EU (or to EU customers) now face uniform KYC obligations that are more demanding in their continuity and depth. 

This has operational implications: firms must update policies, upgrade compliance infrastructure, and possibly adjust their customer experience to meet the stricter requirements. Below, we outline two major practical dimensions of AMLR’s impact on crypto companies: the scope of which businesses and activities are affected, and the heightened expectations around internal governance, controls, and accountability in AML/KYC compliance.

Scope – Which Crypto Businesses Are Affected

AMLR’s scope encompasses a wide range of crypto-asset services, effectively covering “most of the crypto sector” as obliged entities under EU AML/CFT rules. If you are a business involved in exchanging crypto-assets for fiat or other crypto, operating a crypto trading platform, providing custodial wallet services, facilitating crypto payments, or otherwise intermediating crypto transactions for customers, you are directly subject to AMLR’s KYC and AML obligations. 

The regulation applies to all crypto-asset service providers (CASPs) as defined in the EU (a definition closely aligned with the FATF’s “VASPs” concept). This includes: cryptocurrency exchanges (centralized or decentralized providers, if they are entities), crypto ATM operators, brokers and dealers, providers of crypto transfer or remittance services, custodians of crypto wallets or private keys, and even certain NFT or metaverse-related service providers if they fall into the regulated categories. 

In short, ANY crypto business that falls under the EU’s Markets in Crypto-Assets (MiCA) categories or provides services analogous to regulated financial services will fall under AMLR’s remit for KYC. There are very few exceptions. Only truly peer-to-peer, non-custodial arrangements that involve no intermediary escape the obligations, and even those are indirectly impacted because regulated firms must treat dealings with unhosted wallets cautiously.

Crucially, being within scope means these crypto businesses must apply customer due diligence measures just like banks and other financial institutions. As the EU Council summarized, “All crypto-asset service providers will need to apply due diligence with regard to their customers. This means they will have to verify facts and information about their customers, as well as report any suspicions to an FIU.”

In practice, upon onboarding a new customer, a crypto firm must identify and verify the customer’s identity, determine the purpose of the business relationship, and assess the customer’s risk profile. They must also screen the customer against sanctions and politically exposed person (PEP) lists. These steps were already standard under the 5AMLD for exchanges and wallets, but AMLR solidifies them and extends them uniformly across the EU. Moreover, whenever a customer’s activity hits certain triggers – for example, a transaction above a threshold or a suspicion of money laundering – the company must perform appropriate due diligence (identifying the parties of a large transaction, asking for the source of funds, etc.). Even occasional customers (e.g., one-off crypto swaps above €1000) are subject to KYC under AMLR.

It’s worth noting that AMLR’s scope also includes some businesses that might not have been strictly covered or consistently treated under prior national regimes. For instance, crypto mining pool operators who intermediate payments, certain decentralized finance (DeFi) platforms if they have a legal entity providing services, and crypto gaming or betting platforms with cash-out functionality could all be pulled into compliance obligations if they meet the definitions. VASPs operating outside the EU but serving EU customers will also need to pay attention – they may need to register or appoint EU-based compliance, as member state laws implementing AMLR could require foreign operators to establish a presence or cooperate with EU authorities. 

Governance, Controls, and Accountability

AMLR not only dictates what crypto businesses must do regarding KYC, but also raises the bar for how they implement it internally. The regulation places strong emphasis on governance, internal controls, and senior management's accountability for compliance. 

Under AMLR, crypto companies must ensure they have a strong compliance infrastructure, including clear internal policies and procedures for AML/KYC, ongoing employee training programs, independent audit functions to test AML systems, and active oversight by the company’s leadership. In fact, AMLR requires that an AML Compliance Officer or function be appointed at the management level of the company. 

For example, a crypto exchange should designate a qualified person in its senior management (e.g., a Chief Compliance Officer on the board or reporting to the board) responsible for implementing AMLR requirements and accountable to regulators. 

Furthermore, AMLR mandates that compliance functions be given adequate resources and authority. The regulation states that obliged entities must provide their compliance function with “adequate resources, including staff and technology, in proportion to the size, nature, and risks of the entity”. For a fast-growing crypto platform, this could mean hiring more compliance analysts and investigators, investing in stronger KYC/AML software, and ensuring the compliance team has unfettered access to customer data and transaction records. 

Simply put, governance controls under AMLR need to be commensurate with the complexity of the business. A small crypto payment startup will not be expected to have a 50-person compliance department, but it must at least appoint responsible personnel and put in place the necessary controls. A large exchange serving millions of users will be expected to have a much more elaborate compliance program. AMLR also encourages a strong “compliance culture” at crypto firms, where management cannot plead ignorance if things go wrong. There are clear expectations that management be aware of AML risks and support mitigation measures. Failures in KYC obligations can lead to significant penalties, and under AMLR, these penalties are being harmonized and strengthened across the EU to ensure they’re dissuasive.

Key compliance obligations on crypto businesses include conducting an enterprise-wide money laundering risk assessment, implementing group-wide AML policies, and establishing internal reporting systems for suspicious activity. Companies must keep detailed records of all KYC information and transactions for at least five years, so they can be provided to regulators or Financial Intelligence Units (FIUs) upon request. 

AMLR also makes it easier for regulators to impose personal liability on individuals responsible for compliance when there is willful blindness or gross negligence. This underscores that compliance is a serious corporate responsibility. Crypto businesses will need to foster collaboration between their compliance departments and product/engineering teams to ensure that controls are effectively integrated into their platforms.

How AMLR Aligns EU KYC with Global Expectations

It’s important to view AMLR not as an isolated European quirk, but as part of a broader global trend toward stricter AML/KYC standards for crypto. The Financial Action Task Force (FATF), which sets international AML norms, updated its standards in 2019 to explicitly cover crypto assets and VASPs, urging all countries to impose KYC, record-keeping, and the Travel Rule on crypto service providers. AMLR is essentially the EU’s way of implementing these standards comprehensively and enforceably across member states. By doing so, the EU has vaulted itself to the forefront of crypto AML regulation – in many respects, EU AML requirements on crypto now meet or exceed those in other major jurisdictions. 

For example, the Travel Rule that the FATF expects globally is fully implemented in the EU (with a low threshold of EUR 1000 for crypto transfers, and even lower for some risk scenarios), whereas some countries are still catching up. EU regulators are also promoting the concept of ongoing, risk-based KYC, which mirrors FATF’s core Recommendations 10 and 1 (Customer Due Diligence and Risk-Based Approach).

From the perspective of crypto businesses, this means the KYC obligations they face under AMLR are broadly consistent with global expectations and, in some cases, even set a high bar that could serve as a model. These changes complement broader crypto KYC requirements that apply to virtual asset service providers across different jurisdictions.

For instance, customer identity verification is a baseline everywhere – whether a crypto exchange is in the EU, the US, or Asia, it’s now standard to verify users' identities. What AMLR does is ensure that in the EU, this practice is non-negotiable and standardized, whereas previously, one country might have been strict and another more lax. 

Similarly, the notion of ongoing monitoring and suspicious transaction reporting is a global one – FinCEN in the US, FINTRAC in Canada, MAS in Singapore, etc., all expect crypto firms to monitor and report suspicious activity. AMLR aligns with these expectations but also pushes them further by mandating unified EU-level supervision (through the upcoming AMLA) to ensure these rules are applied consistently.

The global alignment also means that EU-based crypto businesses will find it easier to demonstrate compliance in multiple jurisdictions. If you comply with AMLR, you’re likely meeting or exceeding the AML/KYC requirements of most countries. This could simplify cross-border operations in the long run. It also contributes to a level playing field internationally – the EU’s move pressures other markets to tighten their crypto KYC rules to avoid becoming havens. FATF has noted that many countries have yet to effectively regulate VASPs, and it continues to call for action. By having AMLR in force, the EU can credibly say it’s implementing the FATF recommendations in full. The AML framework built by AMLR thus stands as part of Europe’s fulfillment of international standards, much like its earlier AML directives did for banks.

Finally, aligning with global standards also protects EU crypto businesses from being perceived as high risk by international partners. Banks and institutions in other countries might be more willing to do business with EU-licensed crypto firms, knowing that they are subject to rigorous EU AML rules. This can help crypto businesses in Europe integrate with traditional finance because their compliance credentials are stronger. 

To be sure, AMLR is not a panacea – effective implementation and supervision are key, and those will evolve in the coming years – but it firmly puts the EU on the map as a jurisdiction with some of the most comprehensive KYC compliance requirements for crypto. In doing so, it contributes to the global effort to mitigate money laundering and terrorist financing risks in the crypto space, aiming for a future in which illicit actors find it increasingly difficult to abuse crypto markets worldwide. These changes complement broader crypto KYC requirements in line with FATF Guidelines and other countries’ regulations, positioning the EU as a leader in setting regulatory expectations for the crypto industry worldwide.

Practical Implications for KYC Operations Under AMLR

With AMLR reshaping the rules, what does this mean on the ground for a crypto exchange or wallet provider? In practical terms, crypto businesses will need to adapt their day-to-day KYC operations to meet the new standards. It’s about enhancing and scaling existing ones, and embedding compliance more deeply into operational workflows. 

Two critical areas stand out: data quality and consistency, and the use of technology and third-party support to manage the increased compliance workload. High-quality data is the lifeblood of effective KYC – if customer information is inaccurate or outdated, even the best monitoring systems will fail. And given the volume of transactions and users many crypto firms handle, leveraging advanced technology and specialized service providers, such as AMLBot, is often essential to efficiently fulfill KYC obligations under AMLR. Let’s explore each of these areas.

Data Quality, Consistency, and Ongoing Updates

One immediate implication of AMLR’s continuous KYC mandate is that crypto businesses must prioritize the quality and currency of their customer data. It’s no longer sufficient to collect a passport photo during signup and file it away; firms need to ensure this information remains accurate and up to date. For instance, if a customer’s ID expires or their surname changes due to marriage, the business should have a process to update the records. Under AMLR’s ongoing due diligence requirements, companies are expected to periodically review customer information and refresh verification when necessary. This may involve sending customers periodic reminders to update their KYC details or re-verifying their identities after a certain period, especially for higher-risk customers. Data consistency across systems is also vital. Many crypto businesses have multiple platforms or databases. Ensuring that a customer’s identity and risk profile are consistent in all systems – so that, for example, a flagged high-risk status in the compliance database also reflects in the user profile that customer support sees – is an important internal control. AMLR effectively pushes companies toward an integrated view of the customer.

Additionally, ongoing monitoring obligations mean crypto companies should continuously update their picture of each customer. Every transaction or interaction could yield new data – perhaps a new address the customer withdraws to, or a new linked bank account for deposits. Firms should incorporate these data points into the KYC file and risk assessment. If a customer suddenly provides an address in a different country, this could affect jurisdictional risk and tax reporting, which the compliance team should note. AMLR’s risk-based approach suggests that the frequency of data updates can itself be risk-based: low-risk customers might be asked to confirm their details once every few years, whereas high-risk customers or those involved in large volumes might be reviewed annually or more frequently. In all cases, though, data quality is paramount – poor quality data (typos, incomplete fields, lack of verification) can lead to compliance breaches. Therefore, many crypto businesses under AMLR are investing in improving KYC data collection during onboarding.

Technology and Third-Party Support

Complying with AMLR’s stringent KYC and monitoring requirements can be resource-intensive, especially for crypto startups or those experiencing rapid growth. The good news is that technology and specialized service providers can significantly help meet these compliance obligations. In fact, most crypto businesses will find that automation and third-party solutions are indispensable to keep up with the volume and complexity of KYC checks mandated under AMLR. 

For example, identity verification, which may involve checking government IDs, verifying liveness (e.g., selfie checks), and cross-referencing databases, can be streamlined with digital KYC providers that offer API-based services. These providers can often perform verification in seconds using machine learning, far faster and potentially more accurately than manual review. As AMLR defines new KYC expectations, many crypto businesses rely on specialized KYC Service Providers to support identity verification and compliance processes. By outsourcing or using SaaS tools for the heavy lifting of document authentication, biometric matching, and even sanction/PEP screening, crypto firms can achieve a higher standard of compliance without reinventing the wheel in-house.

Another area where technology is crucial is transaction monitoring and blockchain analytics. Under AMLR, crypto companies must not only monitor fiat transactions but also monitor blockchain activity for signs of illicit activity or higher risk. Advanced blockchain analytics tools can trace cryptocurrency flows and flag addresses associated with hacks, sanctions, or money laundering. These tools often come from third-party providers specializing in crypto compliance. They continuously update their database of risky addresses. Using these tools, a compliance officer can be alerted if, say, a customer receives crypto from an address that is linked to a sanctioned exchange – at which point the business can freeze funds or escalate the case. 

Third-party support can also extend to areas like ongoing customer due diligence. Some crypto businesses engage external firms to enhance due diligence for high-risk customers. While the ultimate responsibility remains with the crypto company, AMLR allows reliance on third parties for certain aspects of CDD under strict conditions, and many firms use this to their advantage to leverage expertise. It’s important, however, that any third-party service or tool is vetted and that the crypto business understands the limitations. Regulators will hold the crypto company accountable if the tech fails or if a third party misses something critical. Therefore, due diligence on vendors and regular audits of their performance are themselves part of good governance.

Finally, technology can help with record-keeping and reporting, which are integral to KYC operations. Many firms are implementing centralized compliance dashboards that track KYC status for each customer and log all actions taken. This not only helps internal coordination but also makes it easier to demonstrate compliance to regulators during inspections. Governance controls in AMLR require companies to provide regulators with evidence of their compliance efforts. A robust compliance IT system can generate reports showing, for instance, that 98% of the customer base has up-to-date KYC info, or listing all the enhanced due diligence measures taken for high-risk clients.

In summary, leveraging RegTech solutions and expert providers is increasingly the norm for crypto KYC. Manual processes simply cannot scale to meet AMLR’s expectations in a timely manner. The cost of these solutions can be high, but they are investments in sustainable compliance. Not only do they help avoid regulatory sanctions, but they also enable a smoother user experience. 

How AMLR Builds on Existing KYC Concepts

To understand how AMLR changes KYC obligations, it is important to first define KYC in the context of crypto businesses. In essence, Know Your Customer (KYC) is not a new concept introduced by AMLR; it has been a foundational element of AML regulation for decades, and it already applied to crypto services under the EU’s previous directives (notably 5AMLD, which, since 2020, required EU crypto exchanges and custodial wallet providers to conduct KYC). What AMLR does is build on these existing KYC concepts and reinforce them within a more robust framework. The fundamental pillars of KYC remain the same: customer identification and verification, due diligence (including understanding the purpose of the relationship and, if applicable, the beneficial owner behind a client), and ongoing monitoring of the customer’s transactions and risk profile. AMLR strengthens these pillars by making the rules more detailed, uniform, and enforceable across the EU.

One way to view AMLR is as an evolution from a directive-based regime to a regulation-based regime. The KYC principles under prior EU law (and global standards) – such as verifying a customer’s identity using reliable documents or data, identifying the real person behind accounts (beneficial owners), assessing risk levels, and monitoring for suspicious activity – all carry over into AMLR. However, AMLR codifies them with more granularity and removes the wiggle room that allowed divergent national practices. For example, under previous directives, what constituted “simplified due diligence” for lower-risk cases was somewhat open to interpretation by each country. AMLR now provides clearer criteria, stating that any simplified measures must still respect the overall risk-based approach and cannot omit core requirements (such as identifying the customer). Another example: under 5AMLD, crypto exchanges had to be licensed/registered and apply KYC, but some member states might have had varying thresholds or verification methods. Under AMLR, all CASPs must apply identification measures to essentially all customers, and thresholds are consistent across the EU.

In short, AMLR stands on the shoulders of existing KYC practice, but elevates it. It doesn’t ask crypto businesses to do something fundamentally different from the KYC they might already know; it asks them to do it better, more consistently, and under uniform rules. 

Conclusion

The introduction of the EU’s AMLR marks a turning point for crypto KYC requirements in Europe. As of 2026, we are in a new reality where KYC is not just a formality at account opening, but a continuous, risk-managed obligation that crypto businesses must diligently uphold. AMLR has effectively reshaped KYC obligations by unifying them under a single rulebook, making them more risk-based, ongoing, and closely tied to actual transaction activity. For crypto businesses in Europe – from exchanges and payment providers to custody services – this means compliance is now a core function that demands significant attention and resources. 

The regulation has reshaped existing KYC obligations rather than creating new ones: it builds on the familiar pillars of customer identification, background checks, and transaction monitoring, but enforces them with unprecedented consistency and rigor across the EU.

In practical terms, companies that adapt to AMLR will likely develop stronger compliance programs: high-quality customer data management, integrated monitoring systems, and clearly accountable compliance leadership. Those that fail to meet the regulatory expectations risk penalties and reputational damage, as European regulators (and the upcoming AML Authority) are poised to take a much more hands-on supervisory role. It’s also important to note that AMLR is not static – while the regulatory text sets the framework, detailed technical standards and guidelines will continue to emerge, and supervisory practices will mature over time. Crypto businesses should therefore view AMLR compliance as an evolving process and stay engaged with regulatory developments.

From a broader perspective, AMLR’s changes tie KYC into the EU’s comprehensive strategy to combat financial crime and bring crypto fully into the regulated financial fold. Ongoing monitoring, traceability of crypto transactions, and cross-border cooperation all contribute to a safer financial system. For legitimate crypto businesses, complying with these higher standards can ultimately be beneficial. It can enhance customer trust and make it easier to work with banking partners and institutional clients who require strong compliance hygiene. In conclusion, AMLR has already begun to reshape the landscape of crypto compliance in Europe. Crypto companies that understand and embrace this – treating compliance as an integral part of their governance and service delivery – will be well-positioned to thrive in the new era of regulated crypto finance, where the EU framework demands both innovation and responsibility in equal measure.

-AMLBot Team

Follow AMLBot:
🔗 Website
🔗 Telegram
🔗 Support Team
🔗 LinkedIn

TL;DR: A second wave of the SHA1-Hulud worm compromised Trust Wallet’s browser extension, leading to the theft of mnemonic phrases and over $7.3 million in crypto losses. The attackers exploited infected NPM Packages, deployed a malicious extension update, and laundered funds through cross-chain bridges, swap services, and centralized exchanges.

This article breaks down how the attack worked, where the funds went, and what the on-chain patterns show.

What Happened?

In November 2025, blockchain security researchers identified a second iteration of the SHA1-Hulud Worm — a supply-chain attack targeting NPM Packages. After execution, the malware scanned the NPM Packages the victim had access to and injected malicious code that allowed it to self-replicate. As the infection spread, more than 700 packages were compromised, impacting thousands of developers. During this process, the attackers gained access to sensitive credentials, including Trust Wallet’s browser extension source code and the Chrome Web Store API Key. With that key in hand, they were able to upload a malicious version of the Trust Wallet Browser Extension, released as version 2.68.

@TrustWallet users lost over $7.3 million in a second layer of SHA1-Hulud worm attack. “He who controls the spice controls the universe” – Trust Wallet hackers’ server responded to an HTTP query. So did the threat actor indeed had plans within plans within plans as in Herbert’s… pic.twitter.com/xuKp018poB

— AMLBot (@AMLBotHQ) January 9, 2026

How the Wallets Were Drained

According to SlowMist’s analysis, the malicious extension operated quietly in the background. Once installed, it iterated through all wallets stored inside the browser extension, extracted mnemonic seed phrases in plaintext, and transmitted them to an attacker-controlled server at api.metrics-trustwallet[.]com.

At that point, no additional exploit was needed. With full access to the seed phrases, the attackers could reconstruct wallets at will and drain funds directly. It was a full private key compromise — the most severe category of wallet security breach.

Following the Money: Ethereum Flows

On Ethereum, the attackers operated through at least ten primary addresses. From those addresses, funds were moved in a deliberately fragmented way. A total of 76 ETH was sent to FixedFloat in multiple uneven batches, while a separate transfer of 25 ETH was routed to another address where the funds remain dormant.

In parallel, large stablecoin and ETH flows were directed to ChangeNOW. Specifically, 442,470 USDT and 279.3 ETH were transferred to the service, consistent with patterns observed in other recent laundering operations. Rather than consolidating funds, the attackers split and staggered transactions, preparing them for cross-chain movement.

Cross-Chain Laundering via Bridges

As in many modern crypto hacks, cross-chain bridges played a central role in obfuscation. Significant amounts of ETH, USDC, and USDT were bridged out of Ethereum, primarily through Relay.link, with additional routing through 0x Protocol and the Onchain Labs DEX Router, which is affiliated with OKX.

After crossing chains, the assets were swapped into Solana. In total, the attackers accumulated 15,550 SOL, which was then distributed across three Solana addresses. From there, 12,280 SOL was moved through several intermediary wallets, while 3,270 SOL remains inactive on a separate address, suggesting either operational delays or intentional long-term storage.

Centralized Exchanges Were Used — Repeatedly

One of the most revealing aspects of this case is the attackers’ direct use of centralized exchanges. On Ethereum alone, 200 ETH was deposited almost immediately into exchange-controlled addresses, with 100 ETH sent to KuCoin and another 100 ETH to HTX.

A closer look at the KuCoin deposit address showed that it had been active weeks before the hack and continued receiving funds weeks afterward. This suggests that the attacker reused an existing, operational account rather than creating a one-off deposit address for laundering. The HTX address, by contrast, was not reused after the incident, although it had received USDT deposits prior to the attack, indicating that it may have been pre-positioned.

Bitcoin Tracing Shows the Same Playbook

Tracing the Bitcoin flows revealed a nearly identical laundering strategy. Most BTC was routed through instant swap services such as ChangeNOW and FixedFloat, mirroring the Ethereum behavior. Some BTC was transferred cross-chain to Solana and remains parked on receiving addresses, while another portion was deliberately left dormant on native Bitcoin wallets. In addition, 7.5 BTC was sent directly to a KuCoin deposit address.

The repetition across chains makes the intent clear: the attackers relied on a consistent, well-tested laundering stack rather than improvising per asset.

This incident goes beyond Trust Wallet as a single product failure. It highlights how supply-chain attacks remain one of the most underestimated risks in crypto, especially when browser extensions are involved. Once a seed phrase is exposed, all downstream security assumptions collapse, regardless of how robust the underlying blockchain infrastructure may be.

The case also demonstrates how modern attackers blend decentralized tools with centralized infrastructure. Cross-chain bridges, instant exchangers, and centralized exchanges are not used in isolation but as complementary components of a single laundering workflow.

Why Early Detection Matters

Once funds are fragmented, bridged, swapped, and distributed across multiple chains, recovery becomes exponentially more difficult. Every additional hop reduces visibility and increases response time.

This is why early detection is critical. Tools like AMLBot Tracer are designed to surface abnormal transaction behavior before assets become irreversibly dispersed. By identifying suspicious flows, interactions with instant exchangers, and exposure to centralized exchange deposit addresses at an early stage, investigators gain a narrow but crucial window for action.

Modern crypto crime almost always leaves traces on-chain. The difference between attribution and disappearance often comes down to how quickly those traces are identified and acted upon.

-AMLBot Team

Connect with AMLBot:
🔗 Website
🔗 Telegram AML Bot
🔗 AMLBot Support Team
🔗 AMLBot LinkedIn

Stablecoin Freezes 2023–2025: Data Analysis of USDT vs USDC

A data-backed analysis of stablecoin freezes across 2023–2025, comparing USDT and USDC enforcement, frozen funds, and on-chain activity.

AMLBot BlogAMLBot Team

Breaking Down the Nobitex Hack: Timeline, Impact, and Key Takeaways

Nobitex’s Role in Iran’s Crypto Ecosystem Founded in 2017 by CEO Amirhosein Rad, Nobitex has grown into Iran’s largest cryptocurrency exchange. It serves as a critical hub for Iranian crypto users, handling the majority of the country’s digital asset trading activity. Nobitex claimed to process 70%

AMLBot BlogAMLBot Team

$20M Lost After Hyperliquid Trade: AMLBot On-Chain Analysis

A whale lost $20M+ after a private-key leak post-trade on Hyperliquid. AMLBot tracked the theft on-chain and confirmed a user-side compromise.

AMLBot BlogAMLBot Team

🚨 Joint Intel Strike — DeepCode × AMLBot Trace “1688shuju,” a Darknet Seller of Verified Exchange Numbers

DeepCode & AMLBot expose “1688shuju” selling exchange-linked phone numbers. Onchain tracing links funds to an OKX deposit.

AMLBot BlogAMLBot Team

AMLBot has entered into a Memorandum of Collaboration with the Department for Combating Cybercrime (DC3) of the Ministry of Internal Affairs of the Republic of Kazakhstan, the national law-enforcement authority responsible for investigating organized cybercrime and financial crime.

The growth of digital assets has transformed criminal behavior: funds move faster, cross borders instantly, and disappear across blockchains unless investigators have the tools and expertise to react in real time. For police units, this creates a practical challenge. The volume, speed, and technical complexity of crypto investigations are now beyond the capacity of traditional investigative methods.

Together, the objective is to help investigators identify illicit activity, trace the money, and strengthen the fight against crime involving cryptocurrency.

“Law-enforcement agencies have the mandate and authority to act. What they need is faster access to blockchain expertise. That is where cooperation makes sense: DC3 leads investigations, and our role is to provide the analytical capabilities that help them follow the money.”— Vasily Vidmanov, COO, AMLBot

Why This Matters for Law Enforcement

Fraud, laundering of criminal proceeds, ransomware cashouts, and organized cybercrime now routinely involve cryptocurrencies. Tracing these funds is possible. But only with the right analytics capabilities.

The latest FATF Guidance on Virtual Asset Recovery (November 2025) highlights a growing skills gap across jurisdictions. FATF encourages authorities to either develop internal blockchain investigation capabilities or bring in external specialists, and notes that the recovery success rate justifies such investment. FATF also encourages emerging public-private partnership models designed for “real-time crypto crime response”, where analytical providers help agencies move quickly from detection to disruption.

This cooperation between AMLBot and the Department for Combating Cybercrime (DC3) of the Ministry of Internal Affairs of the Republic of Kazakhstan reflects that model in practice. For DC3, it means access to:

• Blockchain analytics expertise for asset-tracing;
• Advisory support during complex investigations;
• Training and upskilling for investigators;
• Structured collaboration with a specialist technology provider.

Rather than replacing law-enforcement capability, this partnership augments it, filling a capability gap that criminals have relied on for years.

Why This Matters for AMLBot

For AMLBot, this cooperation is not a commercial program. It is an opportunity to apply our technology in real-world investigative environments and contribute to public-interest outcomes. Law-enforcement partnerships are earned, not claimed. Agencies collaborate only with providers that demonstrate operational maturity, responsible data practices, and credible investigative value. This memorandum is a signal of trust: our tooling and expertise meet a standard that national agencies consider reliable.

It also reinforces AMLBot’s mission:

• Helping institutions respond to crypto-enabled threats;
• Supporting asset recovery where possible;
• Promoting transparent, lawful use of blockchain technologies.

So, the memorandum creates a framework for coordinated action. Expert exchanges, investigator training, joint discussions, and technical cooperation are provided when a case requires additional analytical depth. These interactions help DC3 respond more quickly to new types of crime and get ready for future cases involving digital assets.

This is part of a broader global trend. Law-enforcement agencies in multiple regions are beginning to integrate blockchain expertise into investigative workflows. The more capabilities they build, the more difficult it becomes for illicit actors to hide.

About the Department for Combating Cybercrime (DC3) of the Ministry of Internal Affairs of the Republic of Kazakhstan

The Department for Combating Cybercrime (DC3) is a specialized law-enforcement unit within the Ministry of Internal Affairs of the Republic of Kazakhstan, responsible for investigating cybercrime, technology-enabled fraud, and other forms of digital and financial crime.

DC3 plays a central role in addressing complex cyber threats affecting individuals, businesses, and public institutions. Its mandate covers the detection, investigation, and prevention of crimes involving digital infrastructure, online fraud schemes, and the misuse of emerging technologies, including cryptocurrencies.

In recent years, the department has been actively involved in high-impact operations targeting organized cybercrime groups, transnational fraud networks, and technology-driven criminal schemes. DC3 also participates in international cooperation efforts and knowledge-sharing initiatives aimed at strengthening cross-border responses to cybercrime and improving investigative practices in the digital domain.

Operating as part of Kazakhstan’s national law-enforcement framework, DC3 contributes to broader efforts to protect citizens, safeguard the financial system, and enhance the country’s resilience to evolving cyber threats.

About AMLBot

The full-fledged crypto compliance solution that protects businesses and users from malicious assets and actors.

AMLBot works closely with compliance teams, financial institutions, and investigation units worldwide. Beyond this memorandum, AMLBot has supported law enforcement and government agencies in multiple jurisdictions by providing blockchain analytics expertise, advisory input, and professional training within non-commercial frameworks. Recent cooperation has included interactions with cybercrime and financial investigation units in India, Thailand, Georgia, and the Czech Republic, among others.

FATF’s recent guidance is clear. Recovering virtual assets requires more than a legal mandate. It requires the right tools, operational readiness, and investigator training. AMLBot develops solutions that help law-enforcement teams, compliance officers, and fraud units respond to crypto-enabled crime with speed and clarity:

● AMLBot Tracer — Case-Mapping and Fund Flow Visualization
Designed for investigative work, Tracer allows analysts to follow transactions across chains, cluster related entities, and identify risk exposure. This helps teams understand where funds originated, where they moved, and which actors may require escalation.

● Transaction Monitoring (AML) and Alerts — For Ongoing Visibility
For agencies and institutions working with repeated inflows, AMLBot supports ongoing monitoring and configurable alerts, helping detect unusual movement patterns before funds exit traceable networks.

● KYC/KYB Verification — Tools to Verify Identities and Businesses Properly
Our identity-verification tool help businesses confirm who they are dealing with, reduce impersonation and fraud risk, and prevent sanctioned or high-risk actors from entering financial ecosystems.

● Training and Investigative Support — Closing the Capability Gap
We provide structured education programs for investigators and compliance professionals, helping them read blockchain data, recognize risk signals, and apply recovery tactics responsibly. This directly addresses the skills gap highlighted in the FATF Guidance.

“Our goal is simple. Give law-enforcement teams the tools that make it easier to spot suspicious activity, protect people’s assets, and keep their institutions safe when crypto is involved. ” — Vasily Vidmanov, COO, AMLBot

-AMLBot Team

Connect with AMLBot:
🔗 Website
🔗 Telegram AML Bot
🔗 AMLBot Support Team
🔗 AMLBot LinkedIn
🔗 Our Blog

Exciting News from AMLBot — Sawasdee Thailand! 🇹🇭

We’re excited to announce the opening of our official Office in Thailand – a strategic milestone in AMLBot’s expansion across Southeast Asia. Our new Thailand Office will serve as a dedicated support center for crypto users and businesses in the region, bringing our core tools and expertise even closer

AMLBot BlogAMLBot Team

AMLBot Becomes An Official Member Of INATBA

Introduction In the ever-changing landscape of the blockchain and cryptocurrency space, staying ahead of the curve requires forging strong alliances and seeking opportunities for collaboration. Recognizing this, AMLBot is constantly striving to enhance its comprehensive compliance offerings aimed at protecting businesses and end users from potential risks and malicious elements.

AMLBot BlogAMLBot Team

AMLBot Team Attends EU Crypto Regulation Round Table

Introduction With the application of the Markets in Crypto Assets (MiCA) on the horizon, the atmosphere within the crypto industry is rife with anticipation. This significant development has spurred far-reaching discussions among law firms, blockchain entities, and regulators, all eager to fully grasp the implications of this new legislation. At

AMLBot BlogAMLBot Team