OFAC screening implementation patterns

Common screening patterns include a pre-payment gate, middleware, event-driven checks, and a sidecar service.

TL;DR

TL;DR: Screen with a pre-payment gate for blocking checks, middleware for centralized control, event-driven checks for async flows, or a sidecar for existing services.

Pre-payment gate

The pre-payment gate is the simplest pattern. Right before funds move, call the screening API and branch: clean proceeds, flagged blocks. Because the call returns in under 100 ms, it fits inline without a noticeable delay, and it gives a hard stop at the exact moment it matters.

Middleware and sidecar

Middleware centralizes screening for a team. A shared layer intercepts payments and applies the check uniformly, which is useful when several services each move money. A sidecar achieves the same for an existing service you cannot easily modify, running the check alongside and logging the result. Both reuse one primitive: a single HTTP call returning ALLOW or BLOCK against the 19,218 SDN names and 947 OFAC-listed crypto wallets.

Event-driven

Event-driven screening fits asynchronous flows. When a payment event is emitted, a handler screens it and, if flagged, halts or queues the transaction for review. This decouples screening from the payment path but must still complete before settlement. Log every decision so the audit trail survives regardless of pattern.

Choosing a pattern

Match the pattern to the payment architecture. Blocking money? Use a pre-payment gate. Many services? Use middleware. Async flows? Use event-driven checks. An existing service you cannot change? Use a sidecar. All four share one screening primitive, so the pattern is a wiring decision, not a new integration.