pattern

Screening Enforcement Point

also called Sanctions Control Placement, Party Screening Gate

The place in a system where a restriction is actually enforced - which must match what the obligation is about, since sanctions apply to parties and licensing restrictions apply to locations, and a control placed at the wrong layer produces errors in both directions.

sanctionsscreeninggeo-blockingkyccontrols

A platform that must exclude sanctioned parties and restricted jurisdictions usually starts with geo-IP blocking at the edge, because it is cheap, immediate and visible. It then finds that sanctioned individuals are being onboarded anyway.

The mismatch is structural, not a tuning problem. Sanctions apply to parties; geo-IP answers a question about network paths. A sanctioned individual connecting from a permitted country is prohibited and passes the check; a permitted customer travelling through a restricted country is generally not prohibited and is blocked by it. The control produces both error types simultaneously because it is measuring the wrong attribute.

Choosing the enforcement point means asking what the obligation is about, and placing the control where that attribute is known and verified.

Why it matters

The attribute determines the layer, and each layer has a different failure profile:

Obligation is about Enforce at Why
Who the party is (sanctions, politically exposed persons) Identity verification at onboarding, plus re-screening The verified identity is the attribute; it is known once and persists
Where the user is (content licensing, market restrictions) Edge, by geography Location genuinely is the attribute, and best-effort accuracy is accepted
Where money goes (payment restrictions) Settlement and payment initiation The counterparty and corridor are known only then
What the product may do in a market (feature restrictions) Application, by market configuration It is a product rule, not a security control

Placing a control at the wrong layer leaves the obligation unmet while producing a convincing dashboard, which is the worst combination: an organisation that believes it is covered.

Implementation patterns

  • Screen the verified identity, with matching that handles transliteration, aliases, name ordering and dates of birth, tuned to a false-positive volume a review team can work.
  • Re-screen the whole customer base on every list change. Designations are added and removed continuously, so a signup-only control is stale immediately; through the 2020s major lists have been updated on a near-weekly basis.
  • Hold, do not reject. Fuzzy matching produces false positives at rates that make automatic rejection unacceptable, and a human decision must be recorded either way.
  • Screen counterparties, not only customers — payees, beneficial owners, correspondent institutions. This is the gap audits most frequently find.
  • Retain evidence as records. Screening results, the list version used, and each disposition are retained records subject to the regime's retention period, not application logs that rotate away.
  • Keep geography as a supplementary signal, useful for risk scoring and for the licensing obligations where it is genuinely the right control.
  • Version the list ingestion. Knowing which list version was applied to which screening run is what makes the evidence meaningful.

Industry example

The public record here is mostly enforcement rather than engineering blogs, and the recurring finding across financial-sector penalties published since 2015 by the US Treasury's sanctions office and its European counterparts is consistent: controls existed, and they were placed where the data was convenient rather than where the obligation was. Firms have been penalised for screening customers but not payment counterparties, for screening at onboarding but never re-screening, and for systems whose matching thresholds were tuned to reduce review workload rather than to catch designations. The technology is rarely the finding; the placement and the threshold decision are.

Failure scenarios

  • Geo-IP as the primary sanctions control, admitting sanctioned parties on residential connections while blocking legitimate travelling customers.
  • Onboarding-only screening, so a customer designated after signup remains active indefinitely.
  • Threshold tuned to the review queue. Loosening matching to reduce false positives until genuine designations are missed, which is a business decision made silently by an engineer.
  • Counterparty blind spot — the customer is screened, the payee never is.
  • Evidence not retained, so the control operated and cannot be shown to have operated, which is the same outcome in an examination.
  • List ingestion failure that fails open, leaving screening running against a stale list with no alert.

Trade-offs

Identity screening costs a review function, permanently. False positives at a few percent of a large customer base is a staffed operation, and the matching threshold is a direct trade between that cost and the risk of missing a designation — a business decision that should be documented as one, because a regulator will ask who made it and on what basis.

Edge geography is cheap and weak; payment-layer controls are strong and late; identity screening is accurate and expensive. Most real designs use all three with one designated as primary, and the discipline is being clear about which is which rather than assuming that having several means being covered.

When not to use it

For a service with no verified identity and no financial relationship — an anonymous content product — there is no party to screen, and the honest options are edge geography plus payment-layer checks, or a decision not to serve certain markets at all. Building identity verification purely to enable screening changes the product and its data protection profile substantially, and that decision belongs to the business.

For low-risk consumer services, full screening machinery is disproportionate and the regime generally expects proportionality. The threshold is holding a verified identity together with a financial relationship; once both exist, the identity is the right enforcement point, and everything else is supplementary.

Interview question

Q: Your platform blocks restricted jurisdictions by geo-IP and compliance reports that sanctioned individuals are still active accounts. Diagnose the design, tell me where you would move the control, and explain what you would do about the false positives that decision creates.

What a strong answer covers: the attribute mismatch — sanctions are about parties and geo-IP is about network paths, producing errors in both directions; moving the primary control to the verified identity, which already exists at onboarding; re-screening the whole base on list updates rather than screening only new customers; a hold-and-review state because fuzzy matching makes automatic rejection unacceptable; extending screening to counterparties and beneficial owners as the usual audit gap; retaining results and list versions as records; the threshold as a documented business decision rather than an engineering default; and keeping geography as the right primary control for licensing obligations.

Quick check

Quiz: Why does geo-IP blocking fail as a sanctions control? — It measures the network path rather than the party. A sanctioned individual on a permitted connection passes, and a permitted customer travelling through a restricted country is blocked, so both error types occur at once.

Flashcard: What makes screening at onboarding insufficient on its own? — Designation lists change continuously, so a customer designated after signup stays active unless the whole base is re-screened on every list update, with the run and its list version retained as evidence.