OFAC Screening Caching

Storing screening results for repeat counterparties to reduce API calls and latency. Requires careful cache invalidation on SDN list updates.

TL;DR

TL;DR: Screening caching stores a prior result so a repeat counterparty is not re-screened on every call, which cuts cost and latency. It is only safe if the cache is invalidated whenever the underlying SDN data changes.

How caching helps

Many agents pay the same counterparties repeatedly, such as a recurring vendor or a frequent service. Re-screening the same wallet or name on every transaction adds calls and, at volume, cost. A cache keyed by the counterparty returns the stored result instantly, so clean counterparties move through without a network round trip.

The invalidation problem

The SDN List changes as names and wallets are added or removed. If a cache holds a clean result from before a counterparty was added to the list, every subsequent transaction will wrongly pass. The cache must be invalidated, not just on a fixed timer, but whenever the source list data updates.

A safe approach

• Key the cache by the exact counterparty identifier and the list version it was screened against.
• Invalidate entries when the underlying data refreshes.
• Never cache blocked results in a way that lets a payment retry past them.

sanctionsai.dev syncs its list data hourly, so a cache tied to the data version can stay current without re-screening every transaction.