Field note

Sanctions screening as code: one policy, a different actuator per rail

The payment is final in under a second and your sanctions analyst is still opening the alert. On an instant rail there is no review window, so the screen has to clear or stop the payment in code, inside the latency budget. The policy model can be common across rails. The action on a hit cannot, because RTP, the card networks, and SEPA Instant each demand a different commit semantic.

Jun 15, 2026 · Navin Agrawal · Payments · 3 min read

Sanctions screening as code: one policy, a different actuator per rail

Visual brief

Visual brief

Sanctions screening as code: one policy, a different actuator per rail

As of June 2026

The payment is final in under a second. Your sanctions analyst is still opening the alert. On an instant rail there is no queue and no review window, so the screen has to clear or stop the payment in code, inside the rail's latency budget.

So build it like code: one screening policy, versioned and tested, with the action on a hit behind a strategy interface. The policy model can be common across rails. The lists, the match thresholds, and what a hit actually does are not, because a hit has to compile into whatever the rail allows.

Same verdict, different commit semantics

On TCH RTP and FedNow you screen per transaction, and a hit holds rather than blocks. The receiving institution accepts the message but not the funds and takes time to review, which on FedNow can stretch into the next business day as a matter of practice. Once the payment is final, clawing it back is a request the receiver can refuse. On Mastercard Send and Visa Direct the topology flips to the front: the originating institution screens the transfer before it is submitted to the network, and declines on a hit. Same sanctions verdict, a different point of control.

SEPA Instant inverts the whole thing

Article 5d of the EU Instant Payments Regulation makes screening the individual transaction during execution illegal. Instead you screen the customer base against the EU lists at least daily and immediately on every list update, stamp a clean flag, and the payment path becomes a single lookup. Same policy intent, a completely different topology.

RTP and FedNow

Hold

screen per transaction - a hit holds the funds for review rather than blocking the message at the network.

Send and Visa Direct

Decline

the originating institution screens the transfer before submission to the network and declines on a hit.

SEPA Instant

Article 5d

transaction screening is barred - you screen the customer base daily and the payment path becomes one lookup.

One sanctions policy, a different actuator per rail (as of June 2026): on TCH RTP and FedNow you screen per transaction and a hit holds the funds for review rather than blocking the message; on Mastercard Send and Visa Direct the originating institution screens before submission to the network and declines on a hit; on SEPA Instant, Article 5d of the EU Instant Payments Regulation bars transaction screening during execution so you screen the customer base daily and stamp a clean flag, turning the payment path into one lookup; and the lesson is that hardcoding FedNow's hold makes you non-compliant on SEPA the day you turn it on.
One versioned policy, three different actuators. The verdict is shared. The commit semantics are not.
Sanctions screening as code is one policy that compiles to a different actuator per rail. Hardcode FedNow's hold and you are non-compliant on SEPA the day you turn it on.

Was this useful?

Choose once.

Filed under

Payments
Share
Back to Field Notes

Related Posts

View All Posts »
Under a second is the right answer to the wrong question

Under a second is the right answer to the wrong question

At an AWS Bedrock AgentCore Payments session the question was what happens at a thousand transactions a second, and the answer was settlement in under a second. Both are true and they answer different questions. The right frame for one payment crossing a trust boundary is the wrong frame for a million events a day inside one agent fleet, where the chain fee stacks up before anything else does.

Spend limits are not delegated payment authority

Spend limits are not delegated payment authority

An invoice agent hits a transient timeout, retries, and two payments clear to the same vendor. The model calls it success. Ops calls it a week of cleanup. Spend limits and roles are a speed bump. Real delegated authority is a delegation object, policy on every attempt, ledger-bound idempotency, and an instant kill switch.

The hard part of payments is access, not the API

The hard part of payments is access, not the API

A payroll rollout taught me the friction is never the integration. It is funding caps, routing permissions, and what can clear directly versus what has to detour through a sponsor bank. That is why the Fed's new payment-account RFI matters - access is becoming a design decision, not just a policy one.

Instant rails: the reality behind the marketing

Instant rails: the reality behind the marketing

RTP cleared $246 billion in 2024 and the headlines said instant payments had arrived. The average transaction sizes tell a quieter story - this is high-value institutional money on a faster rail, not the consumer revolution that was promised.