Onchain AML: Screening, Monitoring, and Investigations

The Discipline Behind Every Defensible Onchain AML Decision

Onchain AML is the discipline of using blockchain data to identify illicit activity, assess wallet and transaction risk, and trace suspicious funds to regulator-ready evidence. It runs on four capabilities that work as one pipeline: wallet screening, real-time transaction monitoring, explainable risk intelligence, and cross-chain investigation.

Phalcon Compliance brings KYA, KYT, alert handling, and reporting into one workflow. When a case needs deeper analysis, MetaSleuth carries the investigation across chains, bridges, mixers, and entities without breaking the evidence trail.

Try Phalcon Compliance for free · Explore MetaSleuth

Build an Onchain AML Workflow That Teams Can Act On

Explore This Crypto AML Hub

• Learn the basics: what onchain AML is and how KYA, KYT, and identity controls work together.
• Evaluate the platform: screening, monitoring, explainable scoring, APIs, pricing, and vendor trust.
• Build the program: risk assessment, deployment, alert triage, and supervisory reporting.
• Investigate illicit flows: follow funds across bridges, mixers, DEXs, and destination chains with cross-chain investigation and mixer tracing.
• Prepare for what is next: programmable compliance and DeFi controls, and cross-chain risk.

What Onchain AML Is

Onchain AML uses blockchain data to identify illicit activity, assess wallet and transaction risk, and trace suspicious funds. Traditional customer checks answer one question: who is this customer. Onchain screening answers the rest. It shows where the customer's funds came from, which entities the wallet has touched, and whether its risk has shifted since onboarding.

A customer can pass identity checks on Monday and receive sanctioned funds on Tuesday. KYA checks wallet risk before funds move. KYT watches transactions and ongoing activity after that. Travel Rule systems carry the information shared between institutions. The FATF risk-based approach explains how these controls apply to virtual assets.

In practice, a screening engine checks an address against labels and on-chain intelligence. It returns a risk result with the signals behind it. Monitoring keeps that check running after onboarding and fires an alert when the address picks up new exposure. The guides linked throughout this hub walk through the KYA and KYT workflows in detail.

Core Capabilities of an Onchain AML Platform

An onchain AML platform stands on four capabilities: address screening, transaction monitoring, explainable risk scoring, and real-time API integration. Each one answers a specific question a compliance team will face. Together they define what a platform must do before it counts as a serious onchain AML tool.

Address screening, often called KYA for Know Your Address, is the entry point. A platform takes a wallet address and checks it against a database of labeled addresses. The depth and freshness of that database decides whether the result is useful. A thin or stale label set returns empty hits on the exact addresses that matter. Coverage in the hundreds of millions, refreshed around the clock rather than on a monthly batch, is what gives an analyst something to act on at three in the morning.

Transaction monitoring, often called KYT for Know Your Transaction, extends screening to ongoing activity. An address that was low risk at onboarding can pick up illicit exposure a week later. Monitoring watches new transactions, counterparties, and exposure, and sends an alert when the risk profile shifts.

Explainable risk scoring shows why an address or transaction was flagged. Analysts review the Risk Indicators, exposure amount, and activity behind the result before they clear or escalate an alert. This cuts review time, keeps decisions consistent, and leaves a record that holds up under audit.

Real-time API integration is what lets these capabilities sit inside a firm's own onboarding or transaction flow instead of a separate browser tab. Millisecond response, batch endpoints, and webhook callbacks for ongoing exposure are the integration primitives. Without API access, screening becomes a manual step that gets skipped under pressure. With it, screening runs as a checkpoint at the moment of decision, every time.

How Phalcon Compliance Implements These Four Capabilities

Phalcon Compliance follows the same operating model used across BlockSec's compliance pages: identify risk early, read the full on-chain context, and respond through a structured workflow. Teams screen counterparties, prioritize the alerts that carry real evidence, and keep the records ready for internal review or regulatory reporting.

Phalcon Compliance combines these capabilities in one platform. It uses a continuously updated database of more than 600 million labeled addresses and over 200 signal types across 17 Risk Indicator categories. Its Behavioral Risk Engine adds activity-based signals, while Risk Exposure shows the value linked to identified risk. The API supports real-time, batch, and monitoring workflows. For practical examples, see the guides on direct and indirect exposure, reducing false positives, and KYT API integration.

Building an Onchain AML Program

Tools are only one part of an AML program. Teams also need clear rules for risk assessment, screening and monitoring, alert triage, and reporting, with audit closing the loop. A practical program has four operating stages.

The four stages are the practical shape of a lifecycle that runs from risk assessment to audit, and they unfold as six steps. Risk-based assessment maps the firm's exposure. KYA screening checks every address at onboarding. KYT monitoring watches every transaction after onboarding. Alert triage puts a documented disposition on every hit. Supervisory reporting files a suspicious activity report (31 CFR 1022.320) when an exposure escalates. An independent audit checks the program still holds up. Each step feeds the next. Assessment decides where to screen. Screening and monitoring produce the alerts. Triage decides what each alert means. Reporting carries the result to a regulator. Audit closes the loop and feeds what it learns back into assessment. A program that runs this loop continuously, rather than once a year at renewal, is what regulators mean when they ask for a risk-based program.

The first stage is risk-based assessment. A firm maps its exposure across customer types, asset types, jurisdictions, and transaction patterns. It uses that map to decide where screening should be heaviest. A program that screens every customer with the same intensity wastes effort on low-risk segments and under-invests where the exposure actually sits. Risk-based assessment forces the firm to make those trade-offs explicit. Regulators expect this stage to be documented, because that documentation is what they audit when something goes wrong.

The second stage is screening and monitoring deployment. The firm wires KYA into onboarding so every new wallet is screened before the first transaction clears. It wires KYT into ongoing activity so exposures picked up after onboarding are caught. It wires the API into the firm's own systems so screening runs as a checkpoint rather than a manual step. Deployment is where the capabilities from the previous section turn practical.

The third stage is alert triage. Every screening and monitoring hit becomes an alert, and every alert needs a disposition. A program without a triage SOP drowns in alerts. A program with a triage SOP routes each alert to a defined action, documents the decision, and produces the audit trail a regulator expects. False-positive handling is a core part of triage. False-positive rates in crypto AML monitoring range widely, and the range is wide precisely because triage quality varies. A platform that exposes the why behind each score lets a triage analyst dismiss a false positive fast. A black-box score forces the analyst to investigate from scratch, and that is where the cost piles up.

The fourth stage is supervisory reporting. When an alert escalates to a real exposure, the program needs to produce a report a regulator can read. It needs a filing a financial intelligence unit can act on, and an evidence pack a law-enforcement handoff can use. The reporting stage is where the program either holds up or falls apart. A program that screens diligently but reports poorly is not much better than one that does not screen at all.

DeFi teams use the same four stages, but deployment looks different. Screening may run at a smart-contract interaction point or a front-end gateway. Monitoring must keep pace with activity that moves in minutes. The guide to building an onchain AML program covers implementation for exchanges and DeFi teams.

Investigation and Forensics

Screening and monitoring identify risk. Investigation follows the funds. When an exploit has already happened or a sanctions designation hits an address, investigators need to see where the assets moved and who received them.

Cross-chain tracing matters because illicit funds rarely stay on one network. Assets can move through a bridge, a mixer, and a decentralized exchange before they reach a new address on another chain. A single-chain view loses the trail at the bridge. A cross-chain investigation picks up at the destination transaction and keeps the fund flow connected.

The investigation response is to follow funds across every hop without losing the thread. A serious tool seeds a starting address once and follows it through the bridge. It picks up the destination-chain activity in the same workspace and continues through the mixer or the DEX swap. The full path renders as one connected graph. An investigator working that graph spends time analyzing the path instead of reassembling it. The alternative is to export an address at every bridge, open a second tool on the destination chain, and stitch the fragments together by hand. That path is slow, lossy at every seam, and hard to defend.

Investigators also need to handle mixers, privacy tools, DEX swaps, and repeated chain hops. These techniques are often used together to hide the source and destination of funds. For the full workflow, see the guides on choosing a cross-chain investigation tool and tracing stolen crypto through a mixer.

The fund-tracing SOP that sits underneath the cross-chain discipline has a stable shape, even though the addresses and chains change every case. An investigator starts from a known point of compromise, seeds it as the source, and follows the funds forward rather than backward, because forward tracing rides the actual flow of stolen money. Each hop is recorded as a node with its address, chain, asset, amount, timestamp, and the labeled-entity context behind it. When the path crosses a bridge or enters a mixer, the trace continues on the destination chain or on the post-mix outputs. It does not stop at the obfuscation event. The path is rebuilt as one connected graph rather than a series of disconnected screenshots. Every claim the investigator makes about where the funds went has to be reproducible from that graph. A path an investigator cannot reproduce is a path a defense will challenge.

MetaSleuth is BlockSec's crypto tracking and investigation platform. It traces fund flows across DeFi protocols, mixers, bridges, and multiple chains in one workspace. It also uses the same address intelligence as Phalcon Compliance, so investigators see entity and risk context as they follow a case.

An investigation also needs a clear evidence package. Record the fund path, timestamps, transaction hashes, entity context, and sources behind each conclusion. That gives an exchange, regulator, or law-enforcement team enough to review the case and act on it. The guide to tracing stolen crypto through a mixer covers the full process.

The standard for what counts as credible evidence has moved with the asset class. A court that acts on a fraud charge needs more than a graph. It needs a package a financial intelligence unit, an exchange compliance team, and eventually a trier of fact can all read and verify. That package has a recognizable shape across serious investigations. It carries the source address and the origin event that started the trace. It records every material hop with its chain, asset, and timestamp. It attaches the labeled-entity context behind each address the funds passed through. It marks the moment of exit, whether into fiat at an exchange, into a mixer, or into a fresh self-custody wallet. It closes with a reproducible visualization that lets a reviewer walk the path end to end without taking the investigator's word for any link. Provenance is the load-bearing element. Every data point in the pack has to trace back to a verifiable on-chain record, and every inference has to be derivable from that record rather than asserted. An evidence pack that withstands independent review is what turns an onchain trace into an actionable case. A trace without that pack is, at best, a lead.

Built for Real Crypto Compliance Workflows

The workflow should fit the operating model. It should not force every team into the same control design. The dedicated guides in this hub show how to adapt the common screening, analysis, and response model to each environment.

Choosing and Trusting an Onchain AML Provider

A firm building an onchain AML program eventually faces a vendor decision. The decision is hard because the category is opaque, the claims sound similar, and the cost of a wrong choice lands months later when a regulator asks why a screening failed. Provider selection runs on three axes: pricing elasticity, independently verifiable effectiveness, and vendor legitimacy. None of the three is optional.

Pricing is the first factor. Teams should be able to test screening before they commit to a large annual contract, and move to a plan that matches their volume. Phalcon Compliance offers a Free tier, pay-as-you-go Screening Packages, Essential, Scale, and Enterprise plans. Screening Packages run on PAYG credit starting at $95 for the 50-screening pack, with per-unit cost between $1.10 and $1.90 depending on pack size. The pricing guide for small VASPs explains the published tiers and when pay-as-you-go or a subscription fits better.

Independently verifiable effectiveness is the second axis, and it is the one where most vendor claims collapse. Every provider promises accurate screening, low false positives, and fresh coverage. Few expose the evidence needed to verify any of those claims. Explainable scoring is the test. A provider that exposes the Risk Indicator IDs behind each score, quantifies the exposure, and lets an analyst reproduce the decision is a provider whose effectiveness can be checked. A provider that returns only a score, with no breakdown, is asking the firm to trust it on faith. The detailed checklist for independently verifying an onchain AML tool's effectiveness is covered in a separate guide. The point is that effectiveness is a property an analyst can check, not a promise a vendor makes.

Vendor legitimacy is the third axis. A firm that hands its compliance screening to a vendor is handing it the evidence a regulator will eventually audit. That vendor needs verifiable credentials, published work, a track record on real cases, and a business that will still exist in two years. The deep-dive on assessing whether a provider is legitimate is covered in a separate guide. The point is that legitimacy is verifiable. A firm that skips the verification is buying risk rather than coverage.

Where Onchain AML Goes Next

Onchain AML keeps changing in three areas.

The first is the DeFi regulatory frontier. Regulators are still working out how to apply obligations built for centralized intermediaries to protocols that have no intermediary. The Travel Rule is the clearest example. It was written for identified intermediaries. Applying it to a transaction between two self-custody wallets is a category problem, not an implementation detail. As jurisdictions push more of Recommendation 15 into national law, the program backbone described earlier will have to fit protocols that have no compliance budget and no patience for added latency.

The second is cross-chain laundering as a systemic threat. Chain-hopping is already the default laundering method, and as bridge volume grows the surface a single-chain tool can cover keeps shrinking. The FATF has flagged cross-chain and cross-service flows as a structural money-laundering channel that no single jurisdiction or single-chain view can capture, which is why the investigation side is converging on unbroken cross-chain tracing.

The third is programmable compliance. The current model returns a score and a human acts on it. The next model exposes the evidence programmatically and lets the firm's own systems route, escalate, or block on that evidence, with a human kept in the loop for the high-stakes calls. API access, explainable risk scoring, and real-time monitoring are the three prerequisites. A platform that has all three is already most of the way there.

Regulation, cross-chain laundering, and workflow automation will keep shaping how teams manage crypto risk. Teams that put screening, monitoring, investigation, and reporting in place now will be better prepared as requirements change.

The next step for a team evaluating onchain AML is concrete. Assess the platform against the four capabilities, the four program stages, and the three selection axes laid out above. Assess Phalcon Compliance for Onchain AML against that framework rather than against a sales deck. Or explore MetaSleuth cross-chain tracing on a real address and judge whether the trace holds up against the funds you are chasing.