Geo-Restriction and Sanctions
Preventing prohibited access and transactions by location or party — where the control must be enforced, evidenced and current.
Definition
Restricting service by geography or by party, to comply with sanctions, export controls, licensing terms or local law.
The two distinct problems
1. Geographic restriction. Preventing access from a location. Enforced through IP geolocation, payment instrument country, declared address and account attributes — each imperfect and each evadable.
2. Party screening. Preventing transactions with specific individuals or entities on sanctions lists. This is an identity matching problem: names are transliterated inconsistently, lists change frequently, and matching must balance false positives (blocking legitimate customers) against false negatives (a compliance breach).
They are frequently conflated, and they need different mechanisms.
The architectural requirements
Enforce at multiple points, because each signal is imperfect: at the edge for access, at registration, at transaction time, and periodically for existing customers as lists change.
Screen against current lists. Lists update frequently, and a screening service using a stale copy is a compliance failure. The refresh mechanism needs monitoring.
Rescreen existing customers, since a party can be added to a list after onboarding. This is a batch process with its own SLA.
Evidence everything. Every decision — allowed or blocked, and why, against which list version — recorded immutably. The obligation is to demonstrate the control operated, not merely to have it.
A review path for false positives, because name matching produces them in volume and a legitimate customer blocked with no route to resolution is a serious commercial problem.
Fail closed. If the screening service is unavailable, do not proceed. This is one of the few places where graceful degradation is wrong.
The practical difficulties
Geolocation is approximate and evadable. Sanctions lists vary by jurisdiction, so a global business applies several with different scopes. Rules change with little notice and sometimes take effect immediately, so the system must support rapid rule changes without a code deployment.
Failure scenarios
- Stale lists, so a newly-sanctioned party is not caught.
- Screening at onboarding only, missing subsequent additions.
- Failing open when the screening service is down.
- No evidence trail, so the control cannot be demonstrated.
- No false-positive review, blocking legitimate customers permanently.
Interview question
"Sanctions lists change weekly. What does your architecture need so that is not a compliance risk?"