Sanctions screening, list ingestion, matching, alert, investigation, tuning, and governance architecture

Official lists and regulatory obligations

Provides authoritative sanctions designations, changes, identifiers, programmes, and legal context.

Kind

external-network

Owner

Sanctions authorities and compliance legal team

Responsibilities

• Obtain current authoritative list data
• Interpret programme and jurisdiction scope before configuring controls

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Source authenticity
• Publication timestamp
• Jurisdiction and programme scope

Failure modes

• Source unavailable
• Malformed update
• Legal scope misunderstood

Recovery

• Retain the last verified version
• Escalate legal ambiguity before release decisions

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

List ingestion, quality, and publishing hub

Normalises authoritative records while retaining source lineage, effective time, identifiers, scripts, and change history.

Kind

data-store

Owner

Sanctions data management

Responsibilities

• Validate and version every list update
• Publish a complete, signed screening snapshot

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Completeness totals
• Schema and identifier checks
• Dual approval
• Rollback point

Failure modes

• Partial list published
• Duplicate identity merged incorrectly
• Transliteration lost

Recovery

• Stop publication
• Restore the last approved snapshot
• Correct and republish with audit history

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Screening policy and field-coverage map

Defines who and what is screened, at which lifecycle points, from which message fields, under which jurisdictional and product rules.

Kind

control

Owner

Sanctions compliance governance

Responsibilities

• Map every in-scope field to a screening attribute
• Name timing, hold, rescreen, and release policy

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Approved scope
• Message-version coverage
• No silent field omission
• Change impact assessment

Failure modes

• New message field not screened
• Wrong jurisdiction profile
• Released payment not rescreened after material change

Recovery

• Hold affected traffic
• Correct the coverage map and replay controlled test cases

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Matching and screening engine

Compares normalised party, bank, geography, vessel, goods, and narrative data with the approved list snapshot and policy.

Kind

service

Owner

Screening platform engineering

Responsibilities

• Apply deterministic normalisation and matching
• Return candidates with score, matched fields, list version, and policy version

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Authenticated configuration
• List and policy version
• Deterministic replay
• Capacity and latency limits

Failure modes

• Engine unavailable
• Configuration drift
• False negative from parsing or threshold

Recovery

• Hold or route under approved continuity policy
• Replay from retained input and versions

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Payment hold and release gate

Prevents the payment from advancing while an in-scope screening result is unresolved.

Kind

control

Owner

Payment operations and sanctions control

Responsibilities

• Bind every screening result to the exact payment version
• Release, reject, block, or escalate only with authorised evidence

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Fail-closed or approved continuity posture
• No self-release
• State and amount integrity

Failure modes

• Payment advances before screening
• Release applied to changed payment
• Duplicate release

Recovery

• Stop downstream processing
• Re-screen changed data
• Use maker-checker release

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Alert queue and case service

Creates one reviewable case with candidate, payment, party, list, policy, and matching evidence.

Kind

application

Owner

Sanctions operations

Responsibilities

• Deduplicate related candidates without hiding evidence
• Prioritise by documented risk and deadline

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Queue completeness
• Stable case key
• No unsupported auto-close

Failure modes

• Alert lost
• Duplicate cases obscure ownership
• Priority starvation

Recovery

• Rebuild from immutable screening outcomes
• Assign and age every open case

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Investigation and disposition

Compares reliable identifiers, ownership, context, and source evidence before recording a reasoned decision.

Kind

operations

Owner

Sanctions investigators and escalation teams

Responsibilities

• Eliminate or confirm using specific evidence
• Escalate unresolved ownership, control, and legal questions

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Four-eyes release where required
• Evidence citation
• Conflict and authority controls

Failure modes

• Generic disposition
• True match released
• Personal data copied outside the case

Recovery

• Reopen and contain
• Escalate to compliance and legal
• Correct downstream reporting and payment action

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Tuning, testing, governance, and audit

Measures performance above and below thresholds, approves changes, samples decisions, and proves that coverage remains effective.

Kind

operations

Owner

Sanctions governance, quality assurance, model risk, and internal audit

Responsibilities

• Test known positives, variants, and near misses
• Approve and monitor list, parser, rule, and threshold changes

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Independent validation
• Below-threshold testing
• Change rollback
• Management information

Failure modes

• Threshold suppresses true matches
• Test data does not represent production formats
• Change deployed without approval

Recovery

• Restore the last approved configuration
• Rescreen affected records
• Investigate control failure and report where required

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Authoritative list update

sanctions-sources → sanctions-list-hub

Ingest a signed or otherwise authenticated source publication.

Contract

file · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Do not publish a partial or unverifiable update.

Approved list snapshot

sanctions-list-hub → sanctions-engine

Publish a complete versioned screening snapshot.

Contract

file · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Keep the previous approved snapshot active until the new one is proven complete.

Policy and field map

sanctions-policy → sanctions-engine

Apply the approved scope, fields, timing, rules, and thresholds.

Contract

control · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Reject unknown message versions or route them to a controlled hold.

Payment screening request

sanctions-payment-gate → sanctions-engine

Screen the exact payment and party version before release.

Contract

message · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Hold under policy when no conclusive result is available.

Screening outcome

sanctions-engine → sanctions-payment-gate

Return clear, alert, unavailable, or error with versions and correlation.

Contract

control · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Never turn timeout or error into clear.

Candidate alert

sanctions-engine → sanctions-alerts

Create a durable case for every reviewable candidate.

Contract

event · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Replay safely from retained outcomes after queue failure.

Investigation assignment

sanctions-alerts → sanctions-investigation

Assign complete candidate and payment evidence.

Contract

operator · operator

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Escalate ageing and missing evidence.

Authorised disposition

sanctions-investigation → sanctions-payment-gate

Release, reject, block, or escalate the exact held version.

Contract

control · operator

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Reject a disposition from an unauthorised role or for changed data.

Approved configuration change

sanctions-assurance → sanctions-policy

Publish tested rule, parser, and threshold changes.

Contract

control · operator

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Rollback changes that fail production or below-threshold monitoring.

Outcome and performance evidence

sanctions-engine → sanctions-assurance

Measure coverage, latency, alert volume, and threshold behaviour.

Contract

event · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Keep sensitive data minimised and access controlled.

List update to payment release

Follow the evidence chain that lets a held payment advance—or keeps it stopped.

1. Receive an official update — Source version received. The list hub records the authority, publication, and source version.
2. Publish a complete snapshot — List snapshot approved. Quality and completeness controls pass before the engine receives the list.
3. Apply approved scope — Policy version active. The field map says exactly which payment data reaches which screening attribute.
4. Hold and screen — Payment held for control. The payment cannot advance while the control has no conclusive outcome.
5. Create a candidate — Alert created. The engine records matched fields, score, list version, and policy version.
6. Record a reasoned disposition — Decision authorised. The investigator cites the identifiers and evidence that support release or escalation.
7. Apply the decision once — Released, rejected, blocked, or escalated. The gate applies the decision only to the unchanged payment version.

List update is incomplete

Completeness totals fail during a new official-list update.

Last confirmed state

The previous approved list snapshot remains active.

Settlement

No settlement state changes because of the failed publication.

Funds and entries

Payments follow the approved continuity posture.

Next owner

Sanctions data management

Safe action

Do not publish the partial list; retain and disclose the last verified version.

Evidence required

• Source checksum
• Record totals
• Rejected rows
• Previous snapshot

Recovery

• Correct ingestion
• Re-run quality checks
• Publish under dual approval
• Assess any exposure window

Screening engine is unavailable

A payment cannot obtain a conclusive screening outcome.

Last confirmed state

Payment reached the screening gate.

Settlement

Settlement has not been authorised by this architecture.

Funds and entries

Funds may remain reserved or unposted under product rules.

Next owner

Payment and sanctions operations

Safe action

Use the approved fail-closed or formally documented continuity posture; never convert error to clear.

Evidence required

• Payment version
• Engine health
• Continuity decision
• Queue position

Recovery

• Restore or invoke approved alternative control
• Screen the same payment version
• Release only on a conclusive authorised result

Below-threshold test finds a true match

Independent testing finds a relevant target that the live threshold suppressed.

Last confirmed state

A control weakness is evidenced.

Settlement

Past settlement states vary and must be investigated.

Funds and entries

Affected payments require trace and legal assessment; no blanket reversal is implied.

Next owner

Sanctions compliance leadership

Safe action

Contain the configuration, identify the affected population, rescreen, investigate, and meet reporting duties.

Evidence required

• Test case
• Configuration version
• Affected population
• Payment and disposition history

Recovery

• Restore an approved setting
• Rescreen scoped records
• Investigate and report
• Validate the corrective change

What happens when screening is unavailable?

• Fail closed — Prevents unscreened release but needs queue, liquidity, customer, and service-continuity treatment.
• Approved compensating control — May preserve critical service but must be specifically authorised, evidenced, limited, and reviewed.

Never default an error to clear. Document authority, scope, duration, evidence, and retrospective screening for any continuity posture.

Who may change matching thresholds?

• Controlled central authority — Makes approval and audit clearer but needs market and language-specific evidence.
• Local operations — Can react quickly but risks uncontrolled divergence and suppressed true matches.

Use risk-based, tested, versioned, independently reviewed changes with below-threshold monitoring and rollback.