A compliance officer at a VASP opens a queue item at 11:42 AM. A new deposit arrived from a wallet that touched a sanctions-designated address nineteen days ago. The decision clock is running. The question on screen is deceptively simple: what data does the screening system actually need to clear or block this address?
The honest answer surprises teams coming from traditional finance. A crypto AML address check does not begin by collecting identity documents, beneficial-ownership charts, or business-registration files. It begins with one string, the wallet address, and it ends with a risk verdict built from on-chain evidence. This article walks through the single input required, the data the screening engine assembles underneath, the optional context that sharpens accuracy, and the output structure that flows back to the compliance desk.
A Blockchain Address Is the Only Input
Traditional anti-money-laundering workloads are document-heavy. Analysts request passports, utility bills, corporate registries, and source-of-funds attestations before a file can advance. On-chain screening flips that order. The wallet address is the entire input: a 0x-prefixed string on Ethereum, a base58 string on Tron, or an EVM-compatible address on chains like BNB Smart Chain and Arbitrum.
That single string is enough because the blockchain is a public ledger. Every transfer the address has made, every contract it has touched, and every cluster of related wallets it belongs to are observable without any private cooperation from the wallet owner. The screening provider resolves the address against a pre-built label graph and returns a verdict in milliseconds, not in a multi-day back-and-forth over email.
This is also where crypto compliance diverges from identity verification. KYC confirms that a human or entity is who they claim to be at onboarding. KYA, Know Your Address, screens the blockchain address for transaction history and risk exposure. The two layers are complementary, not substitutes, and only one of them is address-driven.
The Screening System Assembles the Risk Picture Underneath
The compliance team submits one address and inherits the entire pre-computed risk graph. No one is expected to crawl the chain, run their own clustering, or maintain a sanctions diff. How the engine turns that single address into a risk verdict, through label matching, indicator hits, and exposure scoring, is detailed in our Crypto Address Risk Screening guide. The point here is what the team submits and what flows back.
Label freshness is where weak screening quietly fails. OFAC can designate a digital-currency address in a morning update, and an address that looked clean at midnight can be high-risk by noon. An engine that refreshes its label set on a continuous cycle closes that exposure window, while a weekly batch job leaves the platform blind for days.
What flows back is a risk verdict, a risk category list, and a recommended action, structured for a defensible decision rather than a wall of raw transactions.
Optional Context That Improves Screening Accuracy
The address is mandatory. A handful of optional fields sharpen the verdict without changing the workflow.
-
Chain or network identifier. Specifying whether the address lives on Ethereum, Tron, BNB Chain, or another supported EVM chain prevents the engine from conflating identical-looking strings across networks. Bitcoin and EVM addresses use different formats, but a chain hint still removes ambiguity for cross-chain deposits.
-
Transaction hash. Useful when the check runs in KYT mode, where the engine evaluates a specific transfer rather than the address in isolation. The hash pins the verdict to one observable movement of funds.
-
Business-scenario tag. Whether the address is being screened for an inbound deposit, an outbound withdrawal, or a consolidation into a hot wallet changes how the risk level should be interpreted. A high-risk inbound deposit can be quarantined; the same level on an outbound withdrawal may trigger a hold.
None of these fields are required to get a verdict. They are tuning parameters that help the engine return a score calibrated to the actual exposure the platform faces at that moment. A screening API that accepts the address and surfaces optional fields keeps the integration simple for a first deployment and grows with the compliance program.
Output Structure: What Flows Back to the Compliance Desk
The data the compliance team sees in return is structured for a defensible decision, not a wall of raw transactions.
A standard response object contains three core fields. A risk level places the address into one of six configurable tiers: Critical, High, Medium, Low, Informational, or No Risk. A risk category list enumerates which risk indicators triggered the assessment—for example, sanctions, mixer, or Attack. A decision recommendation maps the level to an action the platform's policy defines: Allow, Review, or Block. Each risk level's meaning is set by the organization to match its internal compliance policy and risk appetite.
| Output field | Purpose on the compliance desk | Audit value |
|---|---|---|
| Risk level (6 tiers) | Route to analyst or auto-decision | Configurable policy record |
| Risk categories | Justify hold or escalation | Specific risk indicators cited |
| Decision recommendation | Trigger Allow / Review / Block workflow | Documented recommended action |
The decision recommendation is advisory. The platform's own risk policy decides whether a Medium score on an inbound deposit routes to manual review or auto-clears with monitoring. What the response guarantees is that every verdict is reproducible: the same address, screened at the same timestamp, returns the same score and category list. That reproducibility is what makes the output usable as examination evidence when a regulator asks why a given transaction was allowed. It also aligns the check with the risk-based approach that underpins the FATF Recommendations for virtual assets and VASPs.
The response is also exportable. Most production deployments write the verdict, timestamp, address, and category list to a compliance log so the platform can reconstruct the screening history for any address over its lifetime. This turns each check from a point-in-time decision into a longitudinal record.
For a broader view of how address screening fits into the full AML compliance program for exchanges and VASPs, see Crypto AML Compliance. On the operational side, Crypto Wallet Screening covers how the input address flows through the screening pipeline.
→ Book a Phalcon Compliance demo and run a live AML address check on a wallet: Book a demo
FAQ
What is the difference between data needed for an AML address check and data needed for KYC?
An AML address check needs one wallet address. The screening engine assembles the risk picture from on-chain history, labels, and counterparty exposure. Identity verification, by contrast, confirms the human or entity behind an account and requires documents. The two are complementary layers, and only the address check is address-driven.
Can I screen an address without any customer information?
Yes. Because the blockchain is a public ledger, the address alone is sufficient input. The screening provider resolves it against a pre-built label graph and returns a risk level. No customer name, document, or self-attestation is required to receive one.
How often should the label data behind the check be refreshed?
Continuous refresh is the safe baseline. Sanctions designations and security incidents land on unpredictable schedules, and an address that screens clean today may be high-risk tomorrow. A weekly batch cycle leaves exposure windows of days; a continuous refresh cycle closes them.
Does the response include a recommended action, or only a risk level?
Both. The response contains a risk level from one of six configurable tiers (Critical, High, Medium, Low, Informational, or No Risk), the specific risk categories that triggered the assessment, and a decision recommendation mapped to Allow, Review, or Block. The platform's own policy determines the final action, but the recommendation gives the analyst a consistent starting point.
What format should the address be in?
The native format for its chain. A 0x-prefixed hex string on Ethereum and EVM chains, a base58 string on Tron, or the chain-native format on Bitcoin. Supplying a chain or network identifier alongside the address removes any ambiguity for cross-chain screening.
