Why the Same Crypto Wallet Gets Different AML Results Across Platforms

A user checks one Ethereum address using two different blockchain analytics tools. Platform A shows Low Risk. Platform B shows Medium Risk with mixer exposure flagged. The user then sends funds from that same wallet to an exchange — and the exchange places the deposit under manual review. The blockchain is one. The address is one. The transaction history is one. So who is wrong?

Possibly no one.

Blockchain analytics systems read the same public ledger, but an AML result includes far more than raw transaction history. Between the blockchain and the final result sit entity attribution, wallet clustering, historical intelligence, exposure methodology, risk taxonomy, score weighting, data freshness, customer context, and internal policy. Each of these layers can differ between providers, between platforms, and even between two checks on the same platform performed at different times. The central thesis: blockchain facts can be objective while AML risk assessments remain provider- and policy-dependent.

Three types of disagreement should not be confused. Tool vs. Tool — two analytics providers show different risk results for the same address. Same tool, different time — the result from one platform changed between two screenings. AML tool vs. exchange decision — an external check shows Low Risk, but the exchange still places the deposit under review. These are different situations with different causes.

This article explains where exactly between raw blockchain data and a final AML result the divergence appears — and what users and compliance teams should do when results conflict.

First, Make Sure You Are Comparing the Same Result

Users often say "two AML checks disagree" when they are actually comparing different analytical objects.

Wallet screening evaluates the broader history and exposure of a wallet address — its full transaction record, counterparties, and accumulated risk profile. Transaction screening evaluates a specific movement of funds — where those particular funds came from, the direction, amount, source, destination, and transaction-specific exposure. Entity attribution answers a different question entirely: what service, cluster, or entity is this address associated with? Sanctions screening checks whether the address or entity is directly designated or has relevant sanctions exposure. An overall risk score is a summary of several analytical signals. And a platform compliance decision — accept, review, request information, restrict, or reject — is based on the analytics result plus the platform's own policy and customer context.

This means that a wallet showing Medium Risk and a transaction from that wallet showing Low Risk is not necessarily a contradiction. Similarly, an AML tool returning Low Risk and an exchange placing the deposit under Manual Review are not two risk scores — they are two different types of output from two different systems with different inputs.

The Five Layers Between Blockchain Data and an AML Result

Layer 1 — Blockchain Data

At the lowest level, providers can see the same objective facts: transaction hashes, addresses, amounts, blocks, token transfers, smart contract events, timestamps, and transaction direction. For mature, well-supported chains, the divergence usually does not arise because one provider sees a different blockchain. But differences can emerge in supported chains (one provider may not cover a specific network), internal traces (how deeply contract calls are decoded), token decoding (how token-transfer events are parsed), cross-chain correlation (whether bridge transfers are linked across chains), indexing speed (how quickly new transactions are processed), and handling of account abstraction or complex contract execution. Raw blockchain data is only the starting layer.

Layer 2 — Address Clustering and Entity Attribution

Two systems can answer the question "who is behind this address?" differently. Provider A may identify Address X as belonging to Exchange Y, while Provider B shows Address X as Unknown. Or Provider A may attribute an address to a mixer cluster while Provider B classifies the same address as DeFi infrastructure. The reasons include different clustering heuristics, different service deposit-address databases, different OSINT sources, different proprietary investigations, different partner data, different cluster boundaries, different attribution confidence requirements, and timing — one provider may have confirmed an entity that another has not yet identified. The key distinction: address data is public; entity attribution is analytical intelligence built on top of it.

Layer 3 — Exposure Methodology

Even when providers agree on an entity label, they can assess the connection between a wallet and that entity differently. Variables include direct versus indirect exposure, number of hops, percentage of funds, absolute amount, inbound versus outbound exposure, historical versus recent exposure, source versus destination, transaction-specific versus whole-wallet exposure, treatment of service wallets, treatment of commingled funds, and treatment of DEXs, bridges, and other shared infrastructure.

An example: a wallet received $100,000. Of that, $500 can be linked several hops back to a mixer. Provider A may surface this as measurable indirect mixer exposure. Provider B may treat it as low-materiality distant exposure. Both may agree on the blockchain path but apply different exposure methodology — and arrive at different risk conclusions.

Layer 4 — Risk Categories and Scoring Rules

Providers can use different category names, combine categories differently, assign different weights, distinguish or combine scams, fraud, and stolen funds, classify some services as trusted, neutral, suspicious, or high-risk, weight direct exposure more heavily, weight recent activity more heavily, or apply category-specific rules. This means the same exposure breakdown can produce different overall scores. System A may see 2% mixer exposure, weight the category strongly, and return High Risk. System B may see the same 2% exposure but apply distance and amount reductions, arriving at Medium Risk. The underlying blockchain facts are identical — the scoring interpretation is not. Published documentation from at least one major analytics provider shows a model in which the overall risk score is aggregated from triggered risk rules, and repeated screenings can change the score as rules and data are updated. This is a useful illustration of why the final score is a calculated analytical output — not a native blockchain field.

Layer 5 — The Platform's Own Risk Policy

This is the layer users most frequently confuse with the analytics provider's output. An exchange or crypto business can choose its own alert thresholds, automatically accept low-risk transactions, manually review medium-risk transactions, apply zero or very low tolerance to sanctions, treat mixers differently from other risk categories, introduce transaction-value thresholds, use customer risk ratings, consider geography, consider account behavior, and require source-of-funds documentation for particular amounts or patterns. This means that even two exchanges using the same analytics provider can make different decisions about the same deposit. FATF standards are explicitly risk-based — firms apply proportionate controls according to identified risk, and the standard does not require every institution to make identical decisions in every situation.

How Two Tools Can Disagree Without One of Them Being "Wrong"

Consider one hypothetical wallet. The blockchain facts: the wallet received most of its funds from a recognized exchange; months ago it received a small indirect flow connected to scam proceeds; recently it interacted with a DEX; one counterparty has only recently been attributed to a risky service.

1. Platform A recognizes the exchange, does not yet attribute the newer risky counterparty, treats the DEX as neutral infrastructure, and considers the distant scam exposure low-materiality. Result: Low Risk.
2. Platform B has the newer counterparty attribution, detects the same scam path, includes indirect exposure more aggressively, and considers the combined signals material. Result: Medium Risk.
3. Exchange C receives the same transfer. Its underlying provider may show Medium Risk. The customer deposit is large. Internal policy routes any scam exposure above a defined criteria to manual review. Result: Deposit Under Review.

All three outcomes can be internally consistent — because they answer different questions with different intelligence, different thresholds, and different policy frameworks.

Same platform, different date. A result can also change on the same platform even when no fraud occurred. The wallet may have completed new transactions. A new cluster attribution may have appeared. Sanctions information may have changed. The provider may have expanded a known entity cluster. A previously unidentified hack or scam address may have become known. Or the methodology or risk rules may have been updated.

Which Differences Actually Matter?

Differences That May Be Mostly Cosmetic

Some disagreements look dramatic but may be largely presentational. One platform says "Scam" while another says "Fraud." One uses a 0–100 scale while another uses 0–10. One says "Medium" while another says "Moderate." One separates DEX exposure while another includes it under DeFi. The visualization differs but the underlying entity, transaction path, risk category meaning, and exposure directness may be broadly equivalent.

The principle: compare the evidence beneath the score before comparing the score itself.

Differences That Require Real Review

Material disagreement exists when one tool shows direct sanctions exposure and another does not, when one identifies a scam or hack source and another sees Unknown, when providers attribute the address to entirely different entities, when one identifies direct exposure while another shows only distant indirect exposure, when one screening reconstructs cross-chain provenance that another does not, when one result contains recent risk intelligence absent from the other, or when one treats an address as shared service infrastructure while another treats it as a customer-controlled entity.

In these cases, the resolution is not averaging scores. It requires examining the underlying transaction hashes, paths, entity sources, directness, amounts, timestamps, attribution confidence, and customer or counterparty evidence. If the standard screening result is insufficient, deeper transaction tracing may be needed — AMLBot's blockchain tracing tool can help reconstruct the actual fund flow when materially conflicting attribution requires verification beyond headline scores. AMLBot's automated tool for tracing stolen crypto transactions offers a simplified entry point — paste a transaction ID, and the system maps the visible money trail across wallets, bridges, and supported blockchains, producing a visual fund-flow map that is easy to read, analyze, and share.

What to Do When AML Results Conflict

For Individuals

If two AML checks return different results, start by confirming the same address and blockchain were checked. Confirm whether both are wallet checks or one is transaction-specific. Check the date and time of each report. Ignore the headline score initially — compare the actual risk categories. Look at direct versus indirect exposure. Compare named entities if available. Check whether the result is based on incoming or outgoing activity. Keep both reports and the relevant TxIDs. And remember that if the funds are being sent to an exchange, the exchange will apply its own screening and policy regardless of an external AML check. If the contradiction involves a major category — sanctions, stolen funds, scam, hack, or ransomware — do not simply choose the more favorable result. Investigate the discrepancy before making a significant transaction. An independent wallet AML check can help inspect risk categories and exposure before sending funds — though no external check guarantees that an exchange will reach the same conclusion.

For Compliance Teams

Do not build a vendor-disagreement process around the question: "Which score wins?" Use the question: "Which underlying fact changes our decision?"

The review should establish whether the same analytical object was checked (address vs. transaction vs. entity vs. customer), whether the timestamps are comparable, whether the attribution agrees or conflicts, whether the exposure path is the same (directness, direction, amounts, hops), whether the category meanings are equivalent once provider taxonomies are normalized, whether the same decision threshold applies once the provider result is separated from company policy, whether the disagreement is material enough to change the approval or escalation outcome, whether the finding can be independently verified through blockchain path inspection, public sanctions sources, customer evidence, or deeper tracing, and how the resolution is documented.

The goal is not perfect numerical consistency across providers. It is an internal risk framework that can survive provider changes — built around evidence and policy rather than encoded around one vendor's numeric score.

Conclusion

One wallet can receive different AML results because blockchain analytics operates in layers: blockchain record → clustering → attribution → exposure → scoring → platform decision.

Raw transactions can be identical. What differs is what entity those transactions are connected to, how far exposure is followed, how risk categories are defined, how much each signal matters, when intelligence was last updated, and what action a particular business takes.

Different results are not automatically evidence that AML screening is unreliable. They are a reason to look below the headline score and understand what each system actually found.

For users, the priority is categories, paths, and dates. For businesses, the priority is building decisions around evidence and internal risk policy rather than around one provider's number. The blockchain supplies the facts. Analytics platforms interpret the relationships around those facts. Compliance policy decides what to do with them.