fraud agent re-screened cleared transactions after cache invalidation bug

TL;DR

Screening results are facts with a lifetime, and they belong in durable storage, not only in a cache. When the cache is invalidated, an agent whose only record was cached will treat every cleared transaction as never screened and re-screen the world, burning API quota and sometimes re-flagging payees on newer list data mid cycle. Persist each screening outcome with the transaction id, the list version used, and the timestamp. On cache loss the agent rebuilds the cache from the store, and rescreening happens only for transactions whose list version is genuinely superseded, on a schedule compliance approves.

fraud agent re-screened cleared transactions after cache invalidation bug

Use this when

• A cache deploy or flush triggers mass re-screening of old transactions.
• Cleared payees get flagged again with no list change in between.
• Screening API usage spikes after infrastructure events.

Not for this skill when

• A sanctions list update landed. Rescreening against the new version is required; plan it as a batch, not a storm.
• Transactions were never durably recorded at all. Build the store first; caching is secondary.

Steps

1. Confirm the mechanism: correlate the re-screen start time with a cache invalidation or deploy event in your infrastructure logs. Verify: the two timestamps align, proving the trigger.
2. Persist screening outcomes durably: transaction id, result, matched list version, screener version, and timestamp, written at decision time. Verify: a sampled cleared transaction shows its full screening record in the store.
3. Change the agent read path to check the durable store on cache miss before calling the screening API, and backfill the cache from the store. Verify: with the cache cleared in staging, cleared transactions produce zero new screening calls.
4. Define the only rescreen triggers explicitly: a new list version, a material payee data change, or a scheduled periodic review, each logged with its reason. Verify: every rescreen in logs carries one of the approved reasons.
5. Rate limit any rescreen wave with a queue so even a legitimate list update rescreen cannot exhaust vendor quota in an hour. Verify: a simulated full rescreen runs inside quota in the plan.

Variant phrasings

agent rescreened everything after cache clear

Cache event phrasing.

cleared transactions flagged again no list change

Reflag phrasing.

screening results should persist not cache only

Design phrasing.

Compatibility: Any agent screening flow using Redis or an in memory cache in front of a database, with OFAC or commercial screening APIs. The pattern is standard cache aside with a durable source of truth.

Why it happens

Caches are allowed to forget; compliance records are not. When the screening outcome lives only in the cache, cache maintenance becomes a correctness event. Agents amplify the damage because they react instantly and at scale, converting a routine flush into thousands of API calls and a wave of confusing re-reviews before a human even sees the deploy notification.

Edge cases / pitfalls

• Store the list version with every outcome. A cleared result against version 12 must not masquerade as a clearance against version 13.
• Backfills from the store must still respect data retention rules. Old screening records may need archival, not deletion.
• If the durable store and cache disagree, the store wins, and the disagreement itself should be logged and investigated.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fShkz739706JuNxmb2rZGQ