The objection that should worry you
Start with the strongest case against this whole argument, because compliance officers have heard it before and it usually wins the room.
Screening lists change daily; transactions happen in milliseconds; adverse-media feeds update on no fixed schedule at all. You cannot poll everything continuously without drowning the desk in noise. Batch screening exists precisely because someone worked out the decision-relevant rate already — end of day is enough for most books, and real-time screening for correspondent banking already runs where it needs to. This is a solved allocation problem, not a sampling theorem waiting to be discovered.
That objection is not naive. It is the working assumption of every compliance technology stack built in the last twenty years, and it gets a great deal right. Batch cycles exist because someone did, in fact, reason about rate versus cost. The claim here is not that this reasoning was absent. It is that the reasoning was applied once, to build a rate into the architecture, and then stopped being reasoning and became a fixture — a number nobody revisits because revisiting it is not anyone's job.
What Nyquist actually says, applied to a name
Harry Nyquist's 1928 result, sharpened by Kotelnikov and Shannon, says that a signal with no frequency component above B can be reconstructed exactly from samples taken at any rate above 2B. Below that rate, the missing frequencies do not disappear. They fold down and reappear disguised as low-frequency content — aliasing — and the reconstructed signal is smooth, internally consistent, and wrong in a way that nothing in the sampled data can reveal.
Translate that into a sanctions list. The list itself is a signal with a bandwidth: it changes at some rate, driven by designations, delistings and spelling variants added after enforcement actions. OFAC's SDN list has had days with dozens of amendments; most days it has none. If a screening rule is compiled against a snapshot and run against live transaction flow for a quarter before the reference data refreshes, the effective sampling rate on that list, from the point of view of the screening engine, is roughly four times a year. Any name added, removed or respelled in between is invisible to every transaction screened in that window. The screening report at month-end will show a clean book. It will be smooth, plausible, and wrong, and the wrongness leaves no trace inside the report itself — exactly the aliasing signature. The failure surfaces later, in an enforcement letter that cites a designation dated ninety days earlier and a payment cleared eighty-nine days after that.
Where the objection survives
The objection's strongest component is the appeal to decision bandwidth: most decisions don't need waveform-perfect reconstruction, only an adequate state estimate, and there is real cost — false positives, alert fatigue, infrastructure spend — to sampling faster than a decision requires. This is correct and it should not be argued away.
Retail transaction monitoring genuinely does not need microsecond intake on a sanctions list that changes a handful of times a month. A retail book screened nightly against a list that itself updates once a day is sampling above its own Nyquist rate — comfortably, even. Nobody should build real-time list polling for a book whose transaction velocity and counterparty set barely move week to week. That would be the misreading the theorem itself warns against: oversampling relative to a badly-understood bandwidth is not caution, it is waste dressed as diligence, and it produces its own version of false confidence — a compliance officer who believes volume of checking equals adequacy of checking.
The second strand of the objection also lands partially: adverse-media feeds are not a clean bandlimited signal in any textbook sense. Coverage is sparse, event-driven, and the "rate" of the underlying signal — reputational risk materialising into a court filing or a regulatory notice — is not something you can specify in hertz. A compliance officer could reasonably argue that clever, threshold-triggered escalation, checking harder only when a name crosses a risk score, defeats the naive demand for constant high-rate polling. Event-triggered sampling schemes in control theory prove exactly this: you can stabilise a system while sampling only when an error bound is crossed, and you do not need to watch continuously to do it.
Where it doesn't
Event-triggered sampling still needs something watching continuously to detect the event. That is the part the objection quietly omits, and it is the part that matters here. A threshold-based adverse-media escalation only works if the base feed being monitored for the threshold crossing is itself live. If the adverse-media check runs on the same quarterly refresh cycle as the sanctions list, there is no mechanism left to detect the event that was meant to trigger the escalation. The saving comes from choosing when to act, never from choosing not to observe.
The same gap appears with rule changes themselves, which is the failure mode this domain produces most often and complains about least. A screening rule is written against a regulatory reading current at the time it is deployed — say, a rule encoding "step 2 secondary sanctions apply to entities 50% or more owned by a designated party." Ownership thresholds, aggregation guidance and general licences change; the rule logic, once compiled into the screening engine, does not change with them unless someone rewrites it. The rule can run correctly, exactly as specified, against every transaction for a quarter, and be compliant with a regulatory position that stopped being current in week three. Nothing in the screening output distinguishes "correctly applying current guidance" from "correctly applying superseded guidance." That is aliasing at the level of the rule itself, not just the reference data it consults.
| stream | typical update tempo | typical rule/reference refresh | consequence when mismatched |
|---|---|---|---|
| sanctions lists (SDN, OFSI, EU consolidated) | daily, irregular within the day | quarterly batch common | designations invisible for up to 90 days |
| adverse media | event-driven, unscheduled | ad hoc, often manual review triggers | reputational hit surfaces after settlement, not before |
| transaction flow | continuous, sub-second in payments rails | screening runs nightly or per-batch | fast-moving structuring pattern reconstructed as a slow drift |
| rule/policy logic | changes on regulatory action, weeks to months | deployed once, revisited on audit finding | rule compliant with a superseded reading of the regulation |
The narrower claim that holds
None of this licenses "screen everything, always, at maximum rate." That version of the argument is the misreading the theorem itself forbids: adequacy is always relative to a bandwidth, and a rate chosen without reference to a measured bandwidth is not rigour, it is theatre. The claim that survives is narrower and less comfortable to implement, because it removes a fixed point compliance architecture has relied on: intake rate cannot be decided once, at build time, and then trusted. It has to be a parameter attached to each stream, set against that stream's actual rate of change, and revised when that rate changes — with a record of what rate was in force when a given screening decision was made.
That record is the part missing from most compliance stacks today, and it is the part that turns aliasing from an invisible risk into a statable one. If the screening engine can say "this transaction was cleared against SDN list version dated 14 March, refreshed quarterly, next refresh 14 June," a compliance officer inherits a fact they can act on: everything screened in that window carries a known resolution limit, and any designation issued inside it is a known gap, not a discovered one. Without that provenance, the gap is discovered only when an examiner or a correspondent bank finds it, at which point it is no longer a sampling question. It is a finding.
This is the sense in which the third position on this axis — every stream still running, sampled at a rate chosen for that stream and recorded against every belief it produces — is not one more upgrade in a sequence of upgrades. It is the point at which the unresolvable question, "how fast, on which feed, at what confidence," stops being hidden inside the architecture and becomes something a compliance officer can actually be asked, and can actually answer.