Sanctions lists change weekly. What does your architecture need so that is not a compliance risk?

What is being tested

Whether you handle the temporal dimension — lists change, and customers screened last year may now be listed.

What the architecture needs

1. Automated list ingestion with monitoring. Lists refresh frequently and from several jurisdictions. A screening service running against a stale copy is a compliance failure, and the refresh mechanism itself needs alerting — a silent ingestion failure is the worst case, because screening appears to be working.

2. Rescreening of the existing customer base. A party can be added to a list after onboarding. Screening only at onboarding leaves a growing population unscreened, which is the most common gap.

This is a batch process with its own SLA and its own monitoring.

3. Screening at multiple points, because each signal is imperfect: at registration, at transaction time, and periodically thereafter.

4. Evidence, immutably recorded. Every decision — allowed or blocked, against which list version, at what time, with what match score. The obligation is to demonstrate the control operated, not merely to have it, and that evidence must be produced on request.

5. Fail closed. If the screening service is unavailable, do not proceed. One of the few places where graceful degradation is wrong, and it must be a deliberate decision rather than a default.

6. A false-positive review path. Name matching produces them in volume — transliteration, common names, partial matches — and a legitimate customer blocked with no route to resolution is a serious commercial problem. This needs a workflow, a team and an SLA.

7. Rules changeable without a code deployment. Sanctions can take effect immediately, so the system must support rapid rule changes through configuration.

The distinction worth making

Geographic restriction (preventing access from a location) and party screening (preventing transactions with listed entities) are different problems needing different mechanisms, and they are frequently conflated.

Geolocation is approximate and evadable; screening is an identity-matching problem with a false-positive/false-negative trade-off. Enforce both, at multiple points, and do not assume one covers the other.