AML Screening at Scale: FIU-IND Compliance for Deposit Flows

TL;DR — India's Financial Intelligence Unit (FIU-IND) flagged 15 crypto platforms for anti-money-laundering (AML) lapses. This guide shows how to screen deposit addresses in real time across 20+ chains using GET /aml/addresses/{address}, and how to gate crediting on the result so flagged funds never post to a user balance.

The problem

On 9 September 2026, India's Financial Intelligence Unit flagged 15 crypto platforms for AML compliance gaps, according to CoinDesk. The reporting covers the enforcement. It does not cover the part a backend engineer actually owns: what happens between a deposit landing on-chain and that balance appearing in a user account.

If you build the deposit pipeline at an exchange, payment service provider (PSP), or custody platform, this is your problem. A user sends USDT on Tron or ETH on Ethereum to an address you control. Your indexer sees it. Your instinct is to credit fast. But FIU-IND, and the Financial Action Task Force (FATF) Travel Rule that informs its expectations, require you to know whether that inbound address is tied to sanctions, mixers, or known theft before you treat the funds as clean. Doing that check once, on Bitcoin only, is not enough. Deposits arrive on every chain you support.

What you need

• A Crypto APIs account and API key. The free crypto api tier requires no credit card and is enough to test the screening flow.
• Deposit detection. Use blockchain events webhooks to fire on incoming transfers instead of polling. Response times are under 100ms.
• A blocking gate in your crediting logic. The screening call must run before the balance update commits, not after. This is the part teams get wrong.
• A policy for what a hit means. Freeze, manual review, or reject — decided by compliance, not hardcoded by whoever wrote the handler.
• Honest expectation: screening returns a risk signal, not a legal verdict. You still own the review workflow behind it.

The screening itself is a single call. For deposit detection and address monitoring patterns, see our guide on monitoring blockchain addresses with webhooks.

How it works

The flow has three steps. A webhook tells you a deposit arrived. You screen the sending address. You credit only if the result clears your policy.

Screening runs through the Verify Address product on one endpoint: GET /aml/addresses/{address}. You pass the address that sent the deposit. The same endpoint serves EVM chains, UTXO chains, Solana, XRP, and more, so you do not branch your compliance code per chain.

curl -X GET \
  "https://rest.cryptoapis.io/aml/addresses/0x742d35Cc6634C0532925a3b844Bc454e4438f44e" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_API_KEY"

The response returns a risk assessment for the address. Rather than guess at exact field names, treat the returned risk classification as the value your gate reads. Map its severity to your own policy tiers — for example, a high-risk classification routes to freeze, a medium one routes to manual review, and a clean result allows the credit to proceed.

To screen a specific inbound transaction instead of just the address, use GET /aml/transactions/{blockchain}/{transactionHash}. This is useful when a single address has mixed history and you want the risk tied to the exact transfer you are about to credit.

curl -X GET \
  "https://rest.cryptoapis.io/aml/transactions/ethereum/0x3f8b...c21a" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_API_KEY"

Wire it together like this. Your blockchain events callback fires address-coins-transactions-confirmed or address-tokens-transactions-confirmed. In the handler, extract the sender, call GET /aml/addresses/{address}, and only then decide whether to write the credit. If your platform also validates deposit address format before onboarding, POST /utils/evm/{blockchain}/{network}/validate-address and its UTXO and XRP equivalents confirm the string is well-formed before you screen it.

What to watch for

Screen the counterparty, not your own address. The flagged risk you care about is the origin of the funds. Passing your own deposit address into the AML call tells you nothing about the sender.

Do not credit before the result returns. If your handler is asynchronous and the balance write races ahead of the screening call, you have credited funds you were required to hold. Make the screening call a blocking dependency of the credit, and default to hold on timeout rather than default to credit.

Confirmation depth matters. Screening an address on an unconfirmed transaction is fine for early signal, but base the crediting decision on a confirmed event. Use address-tokens-transactions-confirmed-each-confirmation if your risk policy needs a specific confirmation count for large deposits.

Rate limits apply per plan. High-volume deposit traffic — especially token transfers on Tron and Ethereum during peak hours — can exceed a lower tier. Check pricing before you point production traffic at it, and cache screening results per address within your review window so you do not re-screen the same counterparty on every deposit.

Screening is a signal, not a filing. FIU-IND expects a documented process. Log every screening call, its result, and the crediting decision it drove. That audit trail is what an examiner asks for. Privacy-layer transfers complicate this — see our note on the Starknet STRK20 privacy layer for where shielded transfers break address-level monitoring.

For teams operating across jurisdictions, the same pattern maps to EU rules — our write-up on AML address screening across 17 chains before you credit a deposit covers the multi-chain gate in more detail.

The Verify Address product gives you one screening call across 20+ chains, so a deposit on Tron, Ethereum, Bitcoin, or Solana passes through the same compliance gate. Start on the free tier, wire it into your deposit handler, and review the full products range to add event webhooks and address validation around it.