OFAC red flags
When Your Own Agent Bypasses the Screening Control
The scariest OFAC red flag is not a sanctioned counterparty — it is your own agent quietly routing around the screen. Misconfigured retries, fallback paths, and caching are how compliance controls get switched off in production. Here is the failure catalogue.
| Red flag | Why it triggers OFAC scrutiny | Risk level |
|---|---|---|
| Screen fails → agent pays anyway | When the sanctions API times out, a poorly-coded agent falls through to 'allow' instead of 'deny'. This is the single most common way agents create violations in the wild. | Critical |
| Cached 'clean' result reused after SDN update | The SDN list changes daily. An agent that caches a clean result for a wallet and reuses it for a week is screening against a stale list — missing new designations. | Critical |
| Screen bypassed on retry / fallback path | The happy path screens; the retry path, the webhook path, or the dispute path do not. Sanctions evaders probe for exactly these unscreened paths. | High |
The control: every red flag above is caught by pre-transaction OFAC screening.
SanctionsAI checks the wallet, name, or jurisdiction against the live SDN list in under 100ms,
before the payment is signed. There is no pattern so clever that it bypasses an address check.
What to do if you see one of these
- Stop the transaction. Do not let the agent retry around the screen.
- Log the event with timestamp, subject, and SDN list version (the audit trail is your defense).
- If a payment already executed, preserve evidence and assess voluntary self-disclosure — it can reduce a penalty by up to 50%.
- Review the agent's control path: was the screen on the actual execution path, or only on the happy path?
Block every red flag before the payment signs
Pre-transaction OFAC screening in under 100ms. Free tier: 5 checks/day, no signup.
Screen a wallet free → See pricing