OFAC Screening Integration Pattern

A reusable architectural approach for embedding sanctions screening into an application, such as a pre-payment gate, event-driven check, or batch scan.

TL;DR

TL;DR: An integration pattern is where you place the screening call in your architecture. The pre-payment gate is the strongest pattern because it blocks funds before they move rather than reviewing them afterward.

Three common patterns

A pre-payment gate screens each counterparty synchronously before any transfer is authorized, which is the tightest control. An event-driven pattern triggers a check when a payment event fires, useful for queues and async flows. A batch pattern screens a set of counterparties on a schedule, which catches historical exposure but cannot stop an individual payment in real time.

Why it matters for agent payments

An AI agent should use the pre-payment gate pattern by default. The 4-Gate Agent Payment Protocol follows this shape: SCREEN the counterparty, SCORE the risk, STOP when flagged, then STAMP the decision as evidence. Placing the check before the payment instruction means the agent never moves money to a blocked party in the first place.

Choosing a pattern

• Pre-payment gate: blocks before funds move
• Event-driven: fits async and queue flows
• Batch: for retroactive and periodic scans

Why the gate belongs in the code path

The pattern only works if the gate is in the payment path itself. A screening call that lives in a separate review queue, or that runs after settlement, does not stop funds. Placing the gate before the payment instruction means the transfer is conditional on a clean result. For agents, that means the screening call must be a hard dependency of the pay action, so a failed or skipped check blocks the payment rather than letting it proceed.