AML (Anti-Money Laundering) is not just a compliance team; it is a software component that sits in the critical path of money movement. An AML engine evaluates every transaction request against a set of rules (scenarios) to assign a risk score. The architectural challenge is performing this evaluation with low latency (<100ms) to avoid slowing down point-of-sale or checkout experiences.
Blocking (Pre-Tx) vs. Flagging (Post-Tx)
Synchronous Blocking (Sanctions/Blacklists): Must happen before the money moves. The system checks the sender/receiver against OFAC lists. If matched, the API returns 403 Forbidden.
Asynchronous Flagging (Behavioral): Complex rules (e.g., "Structuring" - multiple transactions just below $10k) are computationally expensive. These run asynchronously post-transaction. If triggered, they create a Case for an analyst (SAR - Suspicious Activity Report), but do not stop the initial payment.
Velocity Checks and Aggregators
A common AML rule is "No more than $5k in 24 hours."
The Counter Problem: Querying the main SQL ledger for SUM(amount) WHERE date > now() - 24h is too slow for high scale.
Redis Implementation: Use a sliding window counter in Redis. Every transaction increments the key user:123:daily_volume. If the new value > limit, reject. This is O(1) complexity.
