OFAC screening for payment orchestration
An orchestrator that routes across many providers inherits sanctions risk at every routing decision.
TL;DR
TL;DR: Payment orchestration platforms that route transactions across multiple providers must screen at every routing decision point, not just at the start of the transaction.
Why every hop matters
An orchestrator can route a payment through different providers, banks, or networks based on cost and availability. Each routing decision introduces a new counterparty and jurisdiction. A screen that runs once at entry misses a blocked provider selected later in the flow.
Where to screen
- The source and destination at entry.
- Each provider before the route is chosen.
- The jurisdiction at each decision point.
- Retries and fallback paths, which change the route.
How to build it
Keep the screen fast with a single HTTP call under 100 ms, so routing logic is not slowed. sanctionsai.dev integrates with x402 and MCP and returns ALLOW for clean and BLOCK for flagged, applied through the SCREEN, SCORE, STOP, STAMP protocol.