A trading platform must restrict access by jurisdiction and screen against sanctions lists. What must the architecture handle?

What it must handle

• Determination at onboarding and continuously. A customer's status can change — a jurisdiction becomes restricted, a person is added to a list — so screening at onboarding alone is insufficient and re-screening against updated lists is a continuous obligation.
• Multiple determination signals, since none is reliable alone: declared residence, document evidence, address, payment instrument origin, and network location. Network location is the weakest and the most easily circumvented, and treating it as authoritative produces both false positives for travellers and false negatives for anyone determined.
• List updates applied promptly, with the propagation time known — since the obligation runs from the list's publication, not from your ingestion.
• Matching that handles name variation: transliteration, ordering, partial matches, aliases. Matching too strictly misses; too loosely produces a review queue nobody can clear — and the queue's size is what determines whether the control operates.
• Evidence of every determination, retained, because the question asked later is what you knew and when.

The blocking behaviour that must be designed

What happens to an existing customer who becomes restricted — funds held, positions closed, withdrawal permitted to a specific destination, or frozen entirely — is a legal determination that varies by regime, and the architecture must support each outcome rather than assuming one.

A binary allow/deny is insufficient, and discovering that during an enforcement event is the wrong moment.

The false-positive cost that must be measured

A legitimate customer wrongly blocked does not complain, does not appeal, and does not return. That loss is invisible in the screening metrics and is frequently larger than the risk being managed.

Measuring it requires sampling the blocked population and reviewing — which is expensive and is the only way to know whether the matching threshold is calibrated.

The architectural placement

Enforcement at the point of action, not only at login. A restricted customer must be prevented from trading, withdrawing and depositing — each of which is a separate enforcement point — and a check at session start is stale by the time it matters.