Transaction monitoring API: screening without the AML suite

Screening asks who you are dealing with; monitoring asks what they are doing. A customer can pass every onboarding check and still exhibit behavior that signals laundering — structured deposits under reporting thresholds, sudden volume spikes, rapid pass-through of funds, or transfers to newly risky counterparties. Transaction monitoring is the AML control that watches for those patterns across the life of the relationship.

The phrase covers two very different purchases, and this page separates them: the enterprise AML platforms that run behavioral detection and case management, and the transaction monitoring API slice — screening every transaction's counterparty programmatically before it settles — that a development team can wire in without an enterprise contract.

A monitoring system consumes transaction streams and evaluates them against detection logic: rule-based scenarios (velocity thresholds, structuring patterns, high-risk corridor transfers), statistical baselines per customer segment, and increasingly machine-learning models trained on past alerts. When logic fires, the system raises an alert into a case-management queue.

The human half is where the control succeeds or fails: analysts investigate alerts, close false positives, and escalate genuine suspicion into a suspicious activity report to the financial intelligence unit. Tuning matters — thresholds set too tight bury analysts in noise; too loose, and real activity passes unremarked.

The same control pointed at two ledgers at once: the internal one (account activity, order flow, fiat movements) and the public one (on-chain flows to and from customer wallets). The on-chain side gives crypto monitoring inputs traditional finance lacks — deposits can be evaluated by where the funds came from, withdrawals by where they go — and adds a counterparty dimension: every deposit source and withdrawal destination is an address you can check against published sanctions and crime data before settlement.

Common crypto scenarios include deposits shortly after a hack or from a flagged service, rapid in-and-out flows that use the platform as a pass-through, and repeated interaction with counterparties on sanctions or crime lists. That last category is where list data plugs directly into monitoring: a screening check on each counterparty address converts published designations into monitoring signals, and freshness matters — a counterparty designated yesterday should fire today. This is the monitoring shape exchanges run on deposits and withdrawals and DeFi front-ends run at wallet connection.

For a compliance officer at a bank, "transaction monitoring" means an enterprise AML platform: behavioral scenarios, alert queues, analyst workflows, regulatory reporting. For a developer building a crypto or payments product, the phrase usually means something narrower — a check on every transaction, programmable, fast enough to sit in the settlement path. Those are different products, and choosing the wrong one costs either months of implementation or an uncovered obligation.

If your program needs behavioral detection and case management, you are buying a platform. If what you need today is transaction monitoring for compliance with sanctions obligations — knowing whether a counterparty is designated before value moves — that slice is an API call:

How to integrate transaction monitoring APIs comes down to one placement decision: the screening slice drops inline ahead of settlement. Before releasing a withdrawal or crediting a deposit, screen the counterparty address, block on a sanctions match, and keep the JSON verdict in your audit trail. The call below checks an Ethereum address against every enabled sanctions, crime and risk list at once — "sanctioned" is true only on a government sanctions-list match, "flagged" also covers labeled crime and risk data, and each match names its list and links the official source record.

Monitoring obligations come from AML law. In the US, the Bank Secrecy Act — administered by FinCEN — requires regulated businesses, crypto exchanges included, to detect and report suspicious activity. In the EU, MiCA brings crypto-asset service providers under the bloc's AML framework, and the FATF Travel Rule adds counterparty information-sharing on transfers above a threshold. Sanctions compliance is a separate, strict-liability regime that runs through the same checkpoints — which is why counterparty screening belongs inside monitoring flows rather than beside them.

The division of labor between sanctions screening and transaction monitoring APIs is clean: screening decides whether a counterparty is permissible; monitoring decides whether activity is suspicious. Screening runs inside monitoring (checking each transaction's counterparty against the lists), and monitoring can trigger screening (re-checking a customer whose behavior changed), but neither replaces the other. The list data feeding the screening half has to stay current to be useful — CompliAPI re-ingests the OFAC SDN list every 15 minutes and refreshes the EU consolidated list and its other sources on daily or weekly cycles.