AML Screening Across Chains When Compliance Filters Go Per-Chain

AML Screening Across Chains When Compliance Filters Go Per-Chain

Crypto APIs Team

Aug 21, 2026 • 5 min

TL;DR — Arbitrum's Elara upgrade adds optional, per-chain compliance filters, which means a custodian integrating several networks still needs one screening layer that works everywhere. With a single GET /aml/addresses/{address} call across 17 chains, you can screen a deposit address for sanctions and illicit-source exposure before you credit a customer, whether or not the underlying chain ships its own filter.

The problem

On February 2025, Arbitrum activated Elara, adding optional compliance filters for dedicated chains, as reported by The Defiant. The direction is clear: chains are starting to offer built-in screening at the protocol level. The catch is in two words from the announcement itself: optional and per-chain.

If you run a custody service, an exchange, or a payment service provider (PSP), you do not integrate one chain. You integrate several. A deposit lands on Arbitrum today and on Ethereum, Polygon, or Bitcoin tomorrow. Some of those chains will offer a native filter. Most will not. Even where a filter exists, its coverage, list sources, and update cadence are set by that chain, not by you, and not by your regulator.

Compliance obligations do not respect chain boundaries. Under the Financial Action Task Force (FATF) Travel Rule and the European Union's Markets in Crypto-Assets (MiCA) regulation, the obligation to screen counterparties sits with your business regardless of which network the funds arrived on. A patchwork of per-chain filters cannot satisfy a single audit trail. You need one screening decision, applied consistently, across every asset you credit.

What you need

Three things. First, coverage across every chain you support, not just the ones with native filters. Second, entity attribution, so a hit tells you what the address is linked to, not only that it is risky. Third, a single request shape, so your deposit pipeline runs the same check whether the funds came from Arbitrum or Bitcoin.

The Verify Address product runs Anti-Money Laundering (AML) and sanctions screening across more than 17 chains through one endpoint. The same call works on a chain that ships its own Elara-style filter and on one that never will. That is the point: your integration does not fork per chain.

How it works

Screening a deposit address is a single GET request. You pass the address and receive a risk assessment with attribution. Here is the call against the AML endpoint:

GET /aml/addresses/0x9f2c...d41a HTTP/1.1
Host: rest.cryptoapis.io
Content-Type: application/json
x-api-key: YOUR_API_KEY

The response returns a risk assessment for the address, including an overall risk score and the categories of activity attributed to it. Rather than reproduce field names that may differ from your account's schema, the practical structure is this: a numeric risk score, a risk level, and a breakdown of attributed entity types such as exchanges, mixers, sanctioned entities, darknet markets, or scam-linked clusters. Your deposit logic reads the score and the categories, then decides whether to credit, hold, or reject.

A typical decision flow in a deposit pipeline:

// pseudocode for a deposit handler
const assessment = await getAmlAssessment(depositAddress);

if (assessment.riskScore >= HOLD_THRESHOLD) {
  queueForManualReview(deposit);
} else if (assessment.categories.includes("sanctions")) {
  rejectAndReport(deposit);
} else {
  creditCustomer(deposit);
}

Because the endpoint is chain-agnostic in shape, the same handler serves an Arbitrum deposit and a Bitcoin deposit. When Elara or a similar per-chain filter is active, treat it as an additional signal upstream, not as your compliance layer. Your record of the screening decision stays in one place.

You can also screen at the transaction level with GET /aml/transactions/{blockchain}/{transactionHash} when you need to assess a specific inbound transfer rather than a standing address. That is useful when the same address shows mixed history and you care about the provenance of the exact funds you are about to credit.

For teams that credit deposits in near real time, pair screening with Blockchain Events webhooks. Subscribe to confirmed incoming transfers, and on each callback run the AML check before releasing the balance. Crypto APIs delivers webhook callbacks in under 100 milliseconds, so the screening step does not become the bottleneck in your credit flow.

What to watch for

Be honest about what a risk score is. It is a probabilistic assessment based on known attribution and clustering, not a legal verdict. A low score means no known links to flagged entities at the time of the query. It does not prove funds are clean. A high score tells you the address has exposure to a flagged category; it does not, on its own, prove your customer committed a crime.

Three concrete limits. First, attribution is only as current as the underlying data. A newly created address used by a bad actor may return low risk until it is clustered. Screen at deposit time, and consider re-screening on material events. Second, exposure is not the same as direct involvement. An address two hops from a sanctioned cluster carries different weight than one that received funds directly. Read the categories, not just the number. Third, a native chain filter such as Elara's applies its own list and its own logic. It may pass an address your policy would hold, or the reverse. Do not assume a chain-level filter matches your obligations under MiCA or your local regulator.

Set thresholds that reflect your risk appetite and your jurisdiction, then log every decision. Regulators examining your controls want to see a consistent, documented process, not a per-chain guess. A single screening call across every chain gives you that consistency. If you also need to reconstruct an address history for review, GET /addresses-historical/evm/{blockchain}/{network}/{address}/transactions returns the transaction record you can attach to a case file.

Per-chain compliance filters are a useful addition, but they are optional and inconsistent by design. Verify Address gives you one AML and sanctions screening call across 17-plus chains with entity attribution, so your deposit pipeline makes the same decision everywhere, filter or no filter. Start on the free tier, no credit card required, and wire the check into your credit flow before your next chain integration.

Infrastructure optimized for growth

100+

Networks Supported

25ms

Avg Processing Time

25,000+ rq/s

Enterprise-ready

100+ TB

of Big Data

Related articles

Share