Sanctions, Travel Rule and Payment Screening. Understand party and payment screening, information requirements, holds, false positives, escalation and audit evidence.
Block 13 · Chapter 64 of 75
Sanctions screening and the FINTRAC travel rule are often implemented in the same payment stack, but they are not the same obligation.
The travel rule requires prescribed originator and beneficiary information to accompany covered electronic funds transfers. It is fundamentally an information-carriage obligation. Sanctions controls ask whether a payment, account, person, entity, ship, property interest or transaction is subject to a legal prohibition, restriction, freezing requirement or disclosure obligation under the applicable Canadian sanctions framework. A payment can contain perfect travel-rule data and still be prohibited. A payment can also fail travel-rule data requirements without involving a sanctioned party.
In Canada, sanctions can arise under legislation and regulations including the United Nations Act, the Special Economic Measures Act and the Justice for Victims of Corrupt Foreign Officials Act, alongside Criminal Code terrorist-property obligations. Global Affairs Canada's Consolidated Canadian Autonomous Sanctions List is an important operational resource, but Global Affairs Canada explicitly states that the consolidated list is provided for administrative convenience and does not itself have force of law. The relevant regulation remains authoritative.
FINTRAC's guidance updated 1 October 2025 states that the Listed Person or Entity Property Report replaces the Terrorist Property Report and reflects enhanced reporting obligations for terrorist and sanctioned property. Reporting entities may have obligations both under sanctions legislation and under the PCMLTFA framework. Where there are reasonable grounds to suspect sanctions evasion, suspicious transaction reporting may also apply.
This chapter connects the legal concepts to bank operations: payment capture, party data, screening, list management, travel-rule completeness, match handling, payment holds, false positives, escalation, release/reject decisions, listed-property reporting, STR considerations, ISO 20022 data and audit evidence.
Reading and status key. [Regulatory rule] means a requirement or scope stated in Canadian legislation, regulation or FINTRAC guidance. [System/scheme fact] means a current Payments Canada or Interac system/rule statement. [Bank implementation] means an illustrative control design, not a universal legal requirement. [Fictional example] labels a teaching scenario. RTR status at the 2026-10-05 audit baseline: the Real-Time Rail is forthcoming, with Payments Canada describing a Q4 2026 launch and industry solution-assurance testing; the RTR examples below are therefore planned/design-state, not claims of current production processing.
What you should be able to do after this chapter
After working through this chapter, you should be able to:
- distinguish sanctions screening from AML transaction monitoring and fraud detection;
- explain the role and limitation of the Consolidated Canadian Autonomous Sanctions List;
- identify major Canadian sanctions-law sources at a functional level;
- explain the difference between a listed person/entity and a politically exposed person;
- explain the FINTRAC travel rule for covered EFTs;
- identify required originator and beneficiary information;
- explain reasonable measures when required travel-rule data is missing;
- design pre-release party and payment screening;
- distinguish true matches, false positives, possible matches and data-quality failures;
- explain why screening should use the richest available party data;
- understand listed-person/entity property reporting and its immediate reporting character;
- explain sanctions-evasion STR considerations;
- distinguish a legal prohibition from a bank-risk decision;
- design screening evidence, list-version control and audit trails;
- test sanctions/travel-rule controls across domestic and cross-border payments.
Chapter navigator
- Canada's sanctions framework in payment operations
- Lists, regulations and legal source hierarchy
- The FINTRAC travel rule
- Payment data needed for screening
- Where screening belongs in the payment lifecycle
- Match handling, false positives and escalation
- Sanctioned property and reporting obligations
- Sanctions evasion and transaction monitoring
- ISO 20022, data quality and audit evidence
- Implementation, governance and testing
- Practical payment-screening scenarios
- Key takeaways and authoritative references
1. Canada's sanctions framework in payment operations
A sanctions control is not merely a name-matching engine.
The bank must understand:
- applicable legal regime;
- prohibited activity;
- listed or designated person/entity;
- ownership/control or property relationship;
- transaction type;
- geographic restrictions;
- licences/permits/exceptions where applicable;
- disclosure/reporting duties.
Major legal sources
Operational teams commonly encounter:
- United Nations Act regulations;
- Special Economic Measures Act regulations;
- Justice for Victims of Corrupt Foreign Officials Act regulations;
- Criminal Code terrorist-property obligations.
Each regulation can have different prohibitions.
Do not implement one generic rule:
name on list = reject every transaction.
The applicable regulation and facts determine the legal treatment.
Sanctions versus AML
Sanctions:
- can create prohibitions regardless of suspicion;
- can require property reporting/disclosure;
- may apply to specific listed persons, entities, countries, sectors, activities or goods.
AML:
- risk-based monitoring;
- reasonable-grounds-to-suspect threshold for STR;
- broader money-laundering/terrorist-financing/sanctions-evasion context.
A sanctioned-party match may create AML/STR considerations, but the sanctions obligation exists independently.
Sanctions versus fraud
A sanctioned beneficiary can be genuine and fully authorized by the customer.
Fraud decision:
- customer really wants to pay.
Sanctions decision:
- is payment legally permitted?
Both must pass.
2. Lists, regulations and legal source hierarchy
Consolidated Canadian Autonomous Sanctions List
Global Affairs Canada publishes a consolidated list covering persons, entities and ships listed under autonomous sanctions regulations made under SEMA and JVCFOA.
It is useful for screening because it consolidates names, aliases and related data.
But Global Affairs Canada states:
- the list is for administrative convenience;
- it is not a regulation;
- it does not have force of law;
- the relevant sanctions regulation must be consulted to determine the actual prohibitions.
This is a critical design principle.
UN sanctions
UN Security Council listings implemented under Canadian regulations can create separate obligations.
A complete program should not assume the autonomous consolidated list includes every applicable UN obligation.
Terrorist entities
Criminal Code listed terrorist entities are another source relevant to terrorist-property controls.
PEP is not sanctions
A foreign politically exposed person can also be sanctioned, but PEP status alone is not a sanctions listing.
PEP control:
- AML due diligence and risk treatment.
Sanctions:
- legal prohibitions/restrictions according to applicable law.
Do not route every PEP hit to sanctions operations as if it were a listed-person match.
List freshness
Sanctions lists and regulations change frequently.
Operational controls need:
- update frequency;
- effective timestamp;
- version;
- source;
- ingestion validation;
- rollback;
- emergency update.
Global Affairs Canada's consolidated list page itself warns that regulations may be updated frequently and that the consolidated version may not always be the most current legal source.
Historical reproducibility
For any payment, the bank should be able to prove:
- which list/regulation version was used;
- when screening occurred;
- input data;
- matching result;
- disposition;
- reviewer.
This matters when a person is added to or removed from a list later.
3. The FINTRAC travel rule
FINTRAC describes the travel rule as the requirement for prescribed information to be included with covered EFTs and virtual-currency transfers.
For EFTs, the guidance applies to:
- international EFTs;
- EFTs within Canada sent via SWIFT MT-103 or equivalent.
[Regulatory scope boundary] FINTRAC's EFT definition excludes transfers carried out by direct deposit or pre-authorized debit (and cheque imaging/presentment). Do not label every AFT, PAD or Interac movement as a travel-rule transfer; classify the actual message and transaction against the current PCMLTFA/PCMLTFR definition and FINTRAC guidance. Sanctions screening and other AML/fraud controls can still apply to those products.
Required EFT travel-rule information
FINTRAC guidance lists:
- originator name;
- originator address;
- originator account number or other reference number, if any;
- beneficiary name;
- beneficiary address;
- beneficiary account number or other reference number, if applicable.
Initiator
Covered reporting entities must include the travel-rule information when they initiate an EFT for which an EFT record must be kept.
Intermediary/final recipient
They must take reasonable measures to ensure required information is included when they receive a covered EFT, as intermediary or final recipient.
Information cannot simply be removed
FINTRAC guidance states that information received under the travel rule cannot be removed from the transfer.
This is important in translation and truncation design.
Missing information
FINTRAC compliance-program guidance requires written risk-based policies and procedures to determine:
- whether to suspend or reject an EFT/VC transfer when required travel-rule information is missing and cannot be obtained through reasonable measures;
- what follow-up measures to take.
This is not a universal automatic-reject rule.
Travel rule versus FINTRAC EFTR
Travel rule threshold/context and EFTR reporting are related but distinct.
An EFT may:
- need travel-rule information;
- need an EFT record;
- not meet CAD 10,000 EFTR threshold.
Travel rule and ISO 20022
ISO 20022 provides structured fields for:
- debtor;
- creditor;
- agents;
- accounts;
- addresses.
But XML richness does not guarantee compliance. The sending bank must populate the required information correctly and preserve it.
4. Payment data needed for screening
Sanctions screening quality depends on input data.
Individual
Useful fields:
- full name;
- aliases;
- date of birth;
- nationality;
- address;
- passport/ID where available and permitted;
- account.
Entity
- legal name;
- aliases/trading names;
- jurisdiction;
- address;
- registration number;
- ownership/control information where relevant.
Payment data
- originator;
- beneficiary;
- financial institutions/agents;
- remittance;
- country;
- purpose;
- vessel/ship information where relevant to trade flows.
Why name-only screening is weak
"Alex Kim" may match many people.
A screening engine should use additional identifiers to distinguish:
- true match;
- false positive;
- insufficient data.
Structured addresses
Structured payment data can improve:
- country identification;
- transliteration;
- entity resolution;
- false-positive reduction.
But more fields also require better data governance.
Transliteration
Names can appear in:
- Latin script;
- Cyrillic;
- Arabic;
- alternative transliterations.
Screening systems should use validated matching methods and alias data.
Ownership/control
A payment to an entity not itself named may still require sanctions analysis if ownership/control or another regulation-specific provision applies.
Do not encode an oversimplified universal ownership threshold unless Canadian legal advice and the applicable regulation support it.
5. Where screening belongs in the payment lifecycle
Screening must run before the bank releases a payment that it may be legally prohibited from processing.
Outgoing
customer instruction
→ data validation
→ sanctions screening
→ AML/fraud/other controls
→ release.
Incoming
network receive
→ screening
→ legal disposition
→ posting/availability.
Cross-border
Screen:
- customer;
- beneficiary;
- banks/agents;
- relevant countries;
- remittance/other parties according to policy.
Intermediaries may screen again.
Batch files
Do not hold thousands of clean payroll items because one item is a possible sanctions match unless policy/rule design requires the whole file to be held.
Architect item-level disposition where feasible:
- clean items proceed;
- matched item held;
- file totals/reconciliation remain accurate.
Real-time payments
Real-time fraud expectations do not override sanctions.
The bank must meet latency while retaining a legally sound screening process.
This may require:
- optimized list engine;
- cached list;
- structured data;
- automated false-positive handling for known safe matches;
- clear failover.
On-us payments
No external rail does not mean no sanctions risk.
A transfer between two customers of the same bank can still involve a listed party.
6. Match handling, false positives and escalation
A screening result should have controlled states.
The hit-handling diagram above turns those states into an operating path: tune for precision, document every disposition, and escalate on evidence rather than instinct.
Example:
- NO_MATCH;
- POSSIBLE_MATCH;
- TRUE_MATCH;
- FALSE_POSITIVE;
- DATA_INSUFFICIENT;
- LEGAL_REVIEW.
Possible match
Do not tell the customer "you are sanctioned."
A possible match means the engine found similarity requiring review.
Analyst review
Compare:
- name;
- DOB;
- nationality;
- address;
- entity details;
- aliases;
- list source;
- regulation.
False positive
Document:
- why not the listed person/entity;
- identifiers used;
- reviewer;
- date/list version.
Reusable false-positive logic must be governed. A whitelist that suppresses future true matches is dangerous.
True match
Escalate to sanctions/legal/compliance according to procedure.
Actions depend on:
- applicable law/regulation;
- property/control;
- transaction;
- available exceptions/licences;
- reporting obligations.
Payment state
A sanctions case should show:
- payment not released;
- held;
- rejected/cancelled where appropriate;
- property blocked/frozen where legally required;
- report submitted.
Do not describe every sanction-related action as "reject."
Customer communication
Use approved language.
The bank may be restricted in what it can disclose. Customer service should not improvise legal explanations.
7. Sanctioned property and reporting obligations
FINTRAC's current Listed Person or Entity Property Report replaced the previous terrorist-property reporting form and reflects expanded sanctioned-property reporting.
Trigger
FINTRAC guidance states reporting entities must submit a Listed Person or Entity Property Report if required to make a disclosure under:
- Criminal Code section 83.1;
- relevant orders/regulations under the United Nations Act;
- relevant SEMA requirements;
- JVCFOA subsection 7(2).
Timing
The FINTRAC report is required immediately when the underlying disclosure obligation applies.
This differs from:
- STR "as soon as practicable";
- EFTR five-business-day deadline.
Property can exist without transaction
A listed-property report can be required because property exists in the institution's possession/control even if no new payment was attempted.
Examples:
- bank account;
- prepaid account;
- securities;
- monetary instrument;
- virtual currency.
STR can also apply
If a transaction or attempted transaction reaches reasonable grounds to suspect sanctions evasion, an STR may also be required.
The reports serve different purposes.
Other disclosures
Sanctions/property obligations can include disclosure to agencies such as RCMP or CSIS under the applicable legislation. Operations must follow the current legal procedure.
8. Sanctions evasion and transaction monitoring
Sanctions evasion involves attempts to circumvent prohibitions.
Potential characteristics:
- use of intermediaries;
- newly formed entities;
- unusual routing;
- trade/payment mismatch;
- rapid change of beneficiary;
- opaque ownership;
- transactions involving high-risk jurisdictions;
- attempts to strip identifying data.
No single indicator proves evasion.
FINTRAC STR
Current FINTRAC guidance requires STR reporting where reasonable grounds to suspect a transaction or attempted transaction is related to sanctions evasion.
Ministerial directives
FINTRAC also publishes current ministerial directives and transaction restrictions. As of 2026, directives include Russia, Iran and DPRK-related requirements.
These are separate from ordinary screening and need controlled implementation.
Transaction monitoring after screening
A party can pass name screening while activity still suggests evasion.
This is why sanctions compliance includes:
- list screening;
- ownership/control analysis;
- transaction monitoring;
- geography;
- customer due diligence;
- escalation.
9. ISO 20022, data quality and audit evidence
ISO 20022 can improve screening when structured data is populated correctly.
Party structure
Separate:
- debtor;
- ultimate debtor;
- creditor;
- ultimate creditor;
- agents;
- addresses.
This reduces ambiguity compared with free text.
Screening representation
Best practice is to screen the richest authoritative representation before destructive mapping/truncation.
If a downstream rail requires a leaner format:
- preserve original;
- log mapping;
- record which representation was screened.
UETR
For applicable wire/CBPR+ flows, UETR gives a durable payment reference.
Sanctions case:
- UETR;
- payment ID;
- list version;
- match;
- disposition.
Evidence record
Store:
- timestamp;
- list source/version;
- screened fields;
- matching algorithm/version;
- score;
- analyst;
- decision;
- legal rationale;
- report reference where applicable.
Re-screening
Banks may re-screen:
- at onboarding;
- periodically;
- when lists change;
- before payment;
- incoming payment.
Policies should state when.
10. Implementation, governance and testing
List ingestion
Test:
- source authentication;
- file completeness;
- XML/CSV parse;
- effective version;
- duplicates;
- alias loading;
- failure alert.
Matching engine
Test:
- exact;
- transliteration;
- reordered names;
- punctuation;
- aliases;
- entity names;
- DOB mismatch;
- address mismatch.
Travel-rule tests
Test:
- complete originator/beneficiary;
- missing originator address;
- missing beneficiary address;
- missing reference/account;
- intermediary receives incomplete transfer;
- unable to obtain missing data.
Expected result must follow risk-based policies.
Payment integration
Test:
- hold before release;
- false-positive release;
- true-match escalation;
- timeout;
- screening-engine outage;
- duplicate message;
- incoming posting.
Governance
Separate:
- list owner;
- screening-model owner;
- sanctions/legal decision;
- payment operations;
- regulatory reporting.
Change control
Sanctions change rapidly.
Emergency list update needs:
- dual control;
- timestamp;
- ingestion validation;
- post-update monitoring.
Metrics
Track:
- screened volume;
- possible matches;
- false-positive rate;
- true matches;
- average review time;
- aged holds;
- list-update latency;
- travel-rule incomplete rate;
- reporting timeliness.
Screening architecture: list, entity and transaction layers
A bank-grade sanctions solution needs more than one matching step.
Layer 1 — customer and account screening
At onboarding and refresh:
- customer;
- beneficial owners/controllers as applicable;
- directors/authorized signers according to policy;
- related parties.
Purpose:
- identify existing relationship risk;
- establish customer status before transactions.
Layer 2 — payment party screening
At transaction time:
- originator;
- beneficiary;
- agents/intermediaries;
- ultimate parties where present;
- other structured parties relevant to the payment.
Purpose:
- detect prohibited/listed parties in the actual payment.
Layer 3 — geography and payment context
Evaluate:
- country;
- bank;
- routing;
- sector;
- transaction purpose;
- goods/services where available and relevant;
- vessel/ship data for trade flows.
Purpose:
- identify regulation-specific restrictions not captured by a simple name list.
Layer 4 — transaction monitoring
Look for potential evasion:
- indirect routing;
- repeated counterparties;
- newly formed intermediaries;
- unusual jurisdiction changes;
- stripped/changed information;
- opaque ownership.
This can generate a compliance case even when list screening finds no direct match.
Layer 5 — legal disposition
Compliance/legal determines:
- prohibited;
- permitted;
- licence/permit required or applicable;
- false positive;
- more information required.
Do not let a matching engine make the legal interpretation.
Sanctions source hierarchy and list governance
Source inventory
Maintain authoritative sources including:
- regulations under SEMA;
- JVCFOA regulations;
- UN Act implementing regulations;
- Criminal Code terrorist entity/property sources;
- Global Affairs administrative consolidated lists;
- internal legal interpretations/permits where applicable.
Administrative list versus law
The consolidated autonomous list is valuable for machine ingestion, but the legal basis belongs to the regulation.
Case evidence should store:
- list record;
- regulation;
- schedule/item;
- listing date;
- applicable prohibitions reviewed.
Ingestion controls
For each list update:
- download from trusted source;
- verify file/transport;
- parse;
- count records;
- compare additions/removals;
- validate aliases/identifiers;
- publish to screening engine;
- record effective timestamp;
- monitor processing.
Failed update
If an expected list update fails:
- alert;
- prevent silent use of stale data under policy;
- invoke continuity procedure;
- record affected screening window.
Emergency update
A major listing event may require:
- expedited ingestion;
- re-screening customer base;
- review of pending payments;
- retrospective transaction review according to policy.
The procedure should be tested before geopolitical events force improvisation.
Name-matching mechanics for banking professionals
Screening algorithms can use:
- exact match;
- normalized match;
- phonetic;
- fuzzy edit distance;
- token reordering;
- alias;
- transliteration.
Normalization
Examples:
- punctuation;
- case;
- titles;
- corporate suffixes.
But over-normalization can create false matches.
"ABC Holdings Ltd" and "ABC Holdings" may be comparable.
Removing too much structure from all names can make unrelated entities appear identical.
Thresholds
A lower match threshold:
- more sensitivity;
- more false positives.
A higher threshold:
- fewer alerts;
- potential misses.
Threshold governance should consider:
- list type;
- data richness;
- customer/transaction type;
- legal risk.
Secondary identifiers
Use:
- date of birth;
- nationality;
- address;
- passport;
- registration number;
- IMO number for ships;
- aliases.
A common name with conflicting DOB can support false-positive resolution.
Missing data
Missing DOB does not mean "not a match."
Disposition may be:
- insufficient data;
- request more information;
- legal review.
Screening points by payment rail
AFT/payroll
Domestic batch can still require sanctions controls under bank policy/legal analysis.
Challenge:
- one file, many beneficiaries.
Architecture:
- item screening;
- hold affected items where legally/operationally appropriate;
- preserve file totals and status.
PAD
Parties include:
A sanctioned party issue may arise even though the payment is a pull debit.
Interac
Fast processing requires:
- current list in low-latency service;
- reliable party identifiers available from service/channel;
- clear failure policy.
Do not assume "domestic Canadian" equals no sanctions concern.
[System/scheme fact + bank implementation] Interac's official business material describes participant-dependent limits, bank-grade authentication/encryption, risk detection and ISO 20022/remittance capabilities. Those are not a substitute for the bank's sanctions control. Interac e-Transfer is not a SWIFT MT-103; travel-rule applicability must still be classified under the current FINTRAC scope rather than inferred from the product name.
Lynx wire
Typically richer bank/customer data.
Screen:
- originator;
- beneficiary;
- agents;
- remittance where policy;
- geography.
Run before final settlement.
Cross-border
More parties and jurisdictions increase:
- list hit possibilities;
- sectoral/country restrictions;
- ownership issues;
- intermediary complexity.
RTR
[Planned system/design state — not current production] As of 2026-10-05, Payments Canada describes RTR as launching in Q4 2026 and reports industry solution-assurance testing. The intended 24/7/365 exchange, clearing and settlement model, participant access and instant-funds experience must not be written as an already-live Canadian capability. A participating bank's future design must integrate sanctions before payment release/posting according to its obligations.
RTR fraud services, when available under the future system design, will not replace sanctions screening.
Implementation boundary: what the payment hub must prove
[Bank implementation] The following is a control-design checklist, not a claim that every Canadian institution uses the same stack:
| Layer | Evidence to retain | Control questions |
|---|
| Channels and authentication | channel, customer/device/session authentication result, approver and instruction ID | Was the payment authenticated before capture, and is the authenticated instruction bound to the screened data? |
| Hub, messages and files | API/file/message type, schema validation, original and mapped ISO 20022/legacy payloads, data hash | Were originator, beneficiary, ultimate parties and agents mapped correctly before screening; did repair or truncation trigger re-screening? |
| Routing and network | BIC/CACPA or other route, intermediary chain, network reference/UETR/PCRN where applicable | Were route, agent and country controls applied before external release, and can the bank distinguish a payment message from settlement? |
| Cutoffs and queues | receipt time, value date, cutoff/calendar, hold age and queue state | Did a sanctions hold prevent release even when a cutoff was approaching; was customer/value-date impact recorded? |
| Clearing, settlement and liquidity | rail/system status, participant or settlement-agent identity, settlement-account evidence and ledger entries | For Lynx, was the payment sent through a direct participant with the required Bank of Canada settlement account/collateral model; for future RTR, is the planned direct-account or settlement-agent model documented? |
| Posting, reconciliation and exceptions | customer posting/availability, GL and suspense entries, network acknowledgements, returns/recalls and case ID | Can every released or held item reconcile from instruction to network result, settlement, customer ledger and report; are returns/refunds screened as new value movements where applicable? |
[System/scheme fact] Lynx is the live Canadian high-value RTGS system: Payments Canada describes participant FIs, Swift messaging, Bank of Canada settlement accounts, collateral, Monday–Friday operation excluding statutory holidays, ISO 20022 support and irrevocable finality. [Planned system fact] RTR has a different future operating model; do not reuse Lynx cutoffs, participant assumptions or live-settlement claims for RTR.
Travel-rule implementation in a payment hub
The travel rule is best treated as a data-quality gate with policy-controlled outcomes.
Outgoing
- identify covered transfer;
- collect originator info;
- collect beneficiary info;
- validate required data;
- transmit with payment;
- preserve exact sent representation.
Incoming
- identify covered transfer;
- validate required travel-rule fields;
- if missing, apply reasonable measures;
- follow risk-based suspend/reject/follow-up policy;
- preserve received data and outcome.
Intermediary
An intermediary should preserve travel-rule information received.
Transformation between formats must not strip required information.
Missing data workflow
Example states:
- COMPLETE;
- INCOMPLETE;
- INFORMATION_REQUESTED;
- SUSPENDED;
- REJECTED;
- RELEASED_AFTER_REMEDIATION.
Reason and evidence should be stored.
Travel-rule and sanctions order
A bank may need both:
- travel-rule data completeness;
- sanctions screening.
The richer data can improve sanctions matching.
But do not insert fictitious values such as "UNKNOWN STREET" merely to make a schema valid if that undermines the regulatory obligation.
False-positive management in depth
False positives are not harmless because they:
- delay customer value;
- create operations cost;
- may cause missed value dates.
But pressure to reduce alerts cannot justify unsafe suppression.
Case evidence
For a false positive:
- screened name;
- matched listed name;
- list source;
- secondary identifiers;
- mismatch reason;
- analyst;
- approval;
- date.
Reusable suppression
A well-designed suppression may key on:
- customer ID plus list entry ID;
- verified DOB mismatch;
- verified registration number mismatch.
Avoid global:
Expiry
A suppression may need re-evaluation after:
- list entry changes;
- customer data changes;
- expiry;
- new information.
Quality review
Sample false positives periodically to confirm:
- analyst accuracy;
- suppression logic;
- data quality.
True-match and legal-decision workflow
A possible true match is a legal/compliance event.
Freeze versus reject
Depending on obligation, required action can involve:
- freeze property;
- prohibit dealing;
- block transaction;
- reject/return;
- disclose/report;
- seek licence/permit.
Do not reduce all to "payment rejected."
Existing account
If a customer becomes listed:
- relationship/property obligations can exist even without a new payment.
Screening only at transaction time is insufficient.
Incoming payment
If incoming funds involve a sanctioned person:
- receiving bank needs approved legal procedure;
- simply returning the payment may itself be prohibited depending on law.
Escalate rather than automate.
Licence/permit
Where customer claims authorization:
- verify authenticity;
- scope;
- amount;
- parties;
- expiry;
- conditions.
Record it against the case/payment.
Listed Person or Entity Property reporting workflow
Trigger handling
When the institution determines it is required to make a disclosure under the relevant sanctions/terrorist-property legislation:
- initiate statutory disclosure process;
- submit FINTRAC Listed Person or Entity Property Report immediately as required;
- preserve property/relationship evidence.
Property record
Include:
- person/entity;
- account/property;
- value;
- currency;
- location/control;
- identifying information;
- legal/list basis;
- actions taken.
No transaction required
The reporting event can come from:
- existing account balance;
- securities;
- other property.
Do not design LP/EP reporting only as a payment transaction output.
Parallel STR assessment
If an attempted/completed transaction suggests sanctions evasion:
- AML applies RGS test;
- file STR if threshold met.
LP/EP report and STR can both be appropriate.
Sanctions-evasion typologies
Intermediary substitution
Customer shifts trade/payment through a new third country immediately after sanctions.
Not automatically evasion; investigate context.
Entity layering
Multiple companies with common ownership, address or director obscure listed connection.
Entity-resolution/ownership analysis is important.
Payment-message stripping
Party data removed or altered before sending.
Controls:
- compare source instruction to outbound message;
- log mapping;
- investigate unexplained deletions.
Split payments
Value divided among several intermediaries.
Threshold splitting is not the central sanctions issue; the pattern may indicate concealment.
Goods/trade mismatch
Payment purpose and customer activity do not align.
Trade finance/sanctions teams may need invoice/shipping context.
Screening operations and service levels
Queues
Separate:
- customer onboarding;
- outgoing payment;
- incoming payment;
- list re-screening;
- ownership/legal review.
Payment queues have tighter SLA.
Priority
High priority:
- near cutoff/value date;
- high value;
- real-time payment;
- legal deadline.
Priority should not lower review quality.
Follow-the-sun
Global bank:
- 24/7 payment screening;
- regional legal expertise;
- handover.
Use common case IDs and evidence.
Escalation
Level 1:
Level 2:
Level 3:
- probable true match/complex ownership.
Legal:
- regulation interpretation/licence.
Screening-engine resilience
Availability
If sanctions service unavailable, product policy should state:
- hold/stop new payments;
- alternate approved engine;
- contingency.
Do not silently bypass.
Cached lists
Caching can improve resilience but needs:
- current version;
- expiry;
- integrity.
Recovery
After outage:
- identify payments not screened;
- determine whether any were processed under authorized contingency;
- re-screen/review as policy requires.
Monitoring
- uptime;
- latency;
- stale list age;
- ingestion failures;
- alert rate.
ISO 20022 and screening data preservation
Structured parties
ISO 20022 separates:
- debtor;
- creditor;
- ultimate parties;
- agents.
Screen each party according to policy/obligation rather than concatenating into one text line.
Address
Hybrid/structured address data can support:
- country;
- city;
- street;
- postal.
But incomplete or incorrectly mapped addresses can produce false reassurance.
Remittance
Screening remittance can create many false positives for ordinary words/names.
Configure according to risk and legal policy.
Translating to legacy
If rich MX becomes lean legacy:
- screen rich source first;
- preserve original;
- log truncation;
- ensure receiving obligations still met.
Sanctions evidence model
For every held/alerted payment:
Payment
- ID/UETR;
- amount;
- parties;
- route.
Screening
- timestamp;
- engine version;
- list version;
- fields.
Match
- candidate list entry;
- score;
- identifiers.
Decision
- false/true/needs info;
- reviewer;
- rationale.
Legal action
- freeze/block/reject/release;
- regulation;
- licence.
Reporting
- statutory disclosure;
- FINTRAC LP/EP report;
- STR if applicable.
This is the audit chain.
Sanctions and travel-rule business requirements
Requirement example — outgoing payment
Before external release, every in-scope payment must receive a completed sanctions disposition based on the current approved list package and applicable party fields. A POSSIBLE_MATCH must prevent release until an authorized disposition exists.
Requirement example — travel rule
For a covered transfer, the payment service must validate required originator and beneficiary information before transmission. Missing information must enter the configured reasonable-measures workflow and cannot be populated with fabricated placeholders.
Requirement example — list update
The sanctions platform must record the source and effective timestamp of each deployed list package and alert operations if the production package exceeds the approved freshness threshold.
Requirement example — evidence
The case system must link the exact list entry and regulatory source used in a sanctions decision to the payment and preserve the analyst's rationale.
Comprehensive sanctions test pack
- exact listed individual;
- common-name false positive;
- alias;
- transliteration;
- entity registration mismatch;
- listed ship/IMO where relevant;
- existing customer newly listed;
- travel-rule complete;
- missing originator address;
- missing beneficiary address;
- incoming incomplete transfer;
- screening outage;
- stale list;
- valid permit/licence case;
- batch one-item match;
- cross-border intermediary match;
- payment after list update;
- sanctioned-property account with no payment.
Assert:
- payment state;
- list version;
- disposition;
- legal escalation;
- reports;
- evidence.
Ownership, control and indirect dealing analysis
Sanctions risk is broader than direct name matching.
Direct listing
Easy case:
beneficiary exactly matches a listed entity with corroborating identifiers.
Ownership/control
A non-listed entity may require legal analysis because it is owned or controlled by or acting on behalf of a listed person under the applicable regulation.
Do not hard-code a foreign jurisdiction's ownership threshold as a universal Canadian rule.
Indirect dealing
Potential risk can involve:
- subsidiary;
- parent;
- intermediary;
- nominee;
- agent;
- family/associate;
- intermediary bank.
Global Affairs Canada's essential-information guidance specifically recommends considering direct and indirect associations.
Evidence
For complex ownership:
- corporate registry;
- customer KYC/beneficial ownership;
- reliable external information;
- legal analysis.
Store source/date.
Country and sector restrictions
Canadian sanctions can include restrictions beyond listed persons.
Depending on regulation:
- financial services;
- debt/equity;
- goods/technology;
- shipping;
- imports/exports;
- geographic regions.
A pure name-screening engine cannot cover every prohibition.
Payment purpose
For trade-related payments, compliance may need:
- invoice;
- goods;
- HS/export control context handled by appropriate teams;
- counterparty;
- route.
Payment systems should support case attachment/linkage, not make bank tellers interpret trade sanctions law.
Sanctions case state model
Suggested states:
- ALERT;
- POSSIBLE_MATCH;
- INFORMATION_REQUIRED;
- LEGAL_REVIEW;
- FALSE_POSITIVE;
- TRUE_MATCH;
- LICENSE_REVIEW;
- ACTION_REQUIRED;
- REPORTED;
- CLOSED.
Payment state remains separate:
- CREATED;
- HELD;
- RELEASED;
- SETTLED;
- RETURNED.
A case can remain open after a payment was prevented.
Travel-rule data governance
Originator master
Fields should come from authoritative KYC/customer data where applicable.
Do not let customer retype legal identity every payment if the bank already has verified data, unless product/regulation requires capture.
Beneficiary
Customer supplies data.
Validate:
- mandatory fields;
- country;
- account/reference.
Address quality
Travel-rule obligation requires address data for covered EFTs as specified by FINTRAC.
Data quality controls:
- no placeholder strings;
- valid country;
- reasonable field structure.
Data changes
If operations repairs a beneficiary field:
- preserve original;
- record corrected value;
- reason;
- operator.
The sent payment and report should reflect controlled values.
Screening latency and payment cutoffs
Wire
A screening case can cause value-date risk.
Product should communicate:
- payment subject to compliance review;
- cutoff may be missed.
Do not release to meet cutoff before compliance disposition.
Real time
Fraud/instant-payment SLA does not supersede sanctions.
Architecture needs:
- low latency list service;
- automated false-positive memory;
- resilient infrastructure.
Batch
Screen early enough before file cutoff to resolve matches.
Late screening causes mass holds.
False-positive economics
False positives create:
- analyst cost;
- payment delay;
- customer calls;
- missed value date.
Improve with:
- structured data;
- aliases;
- secondary identifiers;
- customer-specific suppression with governance.
Do not reduce by simply raising match threshold without validation.
False-positive library
Store:
- customer/list pair;
- decisive identifier;
- approval;
- expiry/review trigger.
When list entry data changes, invalidate/review affected suppressions.
Payment repair and sanctions
A rejected/malformed payment may be repaired.
Re-screen when critical party data changes:
- beneficiary name;
- account;
- agent;
- country;
- remittance where screened.
Do not assume original sanctions clearance applies to a materially changed instruction.
Sanctions and refunds/returns
A return payment can itself involve a sanctioned party.
Do not automate:
"sanctions hit → return funds to sender"
without legal procedure. Returning property may be a prohibited dealing.
Returns/refunds need screening and legal disposition.
Property inventory and account controls
When a listed-property obligation applies, institution may need to identify:
- accounts;
- deposits;
- securities;
- payment balances;
- virtual currency;
- other property.
This requires enterprise customer/property search, not only payment screening.
Periodic reporting/disclosure
Applicable sanctions/terrorist-property regimes can impose recurring or immediate disclosure requirements. Procedures must follow exact current law.
Regulatory change management
Trigger
- new sanctions package;
- new listing;
- amended prohibition;
- new FINTRAC guidance;
- new ministerial directive.
Impact
Assess:
- lists;
- screening fields;
- customers;
- products;
- geographies;
- ownership rules;
- reporting.
Deploy
- legal interpretation;
- rule/config;
- test;
- approval;
- effective time.
Retrospective review
If law/list effective time precedes deployment due operational timing, compliance decides whether retrospective review is required.
Sanctions operations handover
A 24/7 team needs structured handover:
- open payment holds;
- true-match cases;
- legal questions;
- approaching cutoffs;
- list update;
- incidents.
Each case:
- owner;
- next action;
- due time.
Avoid unmanaged spreadsheets.
Screening data-quality dashboard
Track:
- missing DOB on customers where available;
- incomplete address;
- country-code errors;
- beneficiary free-text;
- transliteration issues;
- duplicate customer records.
Data quality improves both:
- hit detection;
- false-positive reduction.
Screening model validation
Validate:
- benchmark listed names;
- aliases;
- transliteration;
- common names;
- corporate names;
- ships where relevant.
Measure:
- sensitivity;
- false-positive rate.
Changes to algorithm/threshold require governance like other material compliance controls.
[Fictional example] Cross-border correspondent scenario
Canadian Bank A sends for customer to Bank C through intermediary Bank B.
Screening responsibilities at A may include:
- customer/originator;
- beneficiary;
- B/C;
- countries;
- remittance/other parties per policy.
Bank B and C may run their own screening.
If B requests repair:
- change must be controlled;
- material party changes re-screened;
- UETR/reference preserved.
Business analyst requirements for screening cases
Case disposition
A payment in POSSIBLE_MATCH state must not be externally released until a user with the appropriate sanctions role records an approved disposition or an approved automated false-positive rule resolves it.
List version
Every screening decision must retain the production list-package identifier and screening-engine version used at decision time.
Travel rule
Incoming covered EFTs missing required originator/beneficiary information must enter the configured reasonable-measures workflow and record the follow-up outcome.
Return
A payment return that creates a new transfer of value must pass applicable sanctions controls; the system must not treat "return" as exempt from screening.
Sanctions control assurance checklist
- authoritative legal sources identified;
- list ingestion monitored;
- customer re-screening strategy;
- payment party screening;
- country/sector controls;
- ownership/control escalation;
- travel-rule completeness;
- false-positive governance;
- listed-property reporting;
- sanctions-evasion STR referral;
- outage/fallback;
- evidence;
- testing.
A mature sanctions program can explain not only which name matched, but which legal obligation applied and why the payment/property action was appropriate.
Payment-screening investigation standards
A good sanctions case is reproducible.
Case header
- payment ID/UETR;
- customer;
- amount/currency;
- direction;
- channel/rail;
- payment state.
Match evidence
- screened text;
- candidate listed party;
- list source/version;
- alias;
- secondary identifiers;
- score.
Analysis
- similarities;
- differences;
- customer KYC;
- ownership/control context;
- applicable regulation.
Disposition
- false positive;
- true match;
- information required;
- legal review.
Action
- release;
- hold;
- freeze/block/prohibit as applicable;
- report/disclose.
Reviewer
- user;
- timestamp;
- approval.
Customer onboarding sanctions screening
New relationship
Screen before activation according to bank program.
Potential match:
- do not silently onboard;
- investigate identity.
Existing customer list update
If customer becomes listed:
- immediately invoke legal/sanctions procedure;
- identify property/accounts;
- identify pending payments;
- assess reporting.
Beneficial ownership
Customer entity may not be named directly.
Sanctions program should have access to ownership/control information maintained by KYC and a procedure for indirect-risk analysis.
Payment party mapping errors
A sanctions engine can only screen what the payment mapper labels correctly.
Example:
ultimate creditor accidentally mapped into remittance instead of party field.
Consequences:
- party may not be screened by party logic;
- evidence inaccurate.
Test ISO mappings with sanctions use cases, not only schema validation.
Real-time screening acceptance criteria
For an instant payment:
- list version current;
- party data complete enough;
- screening response within approved latency;
- possible match prevents release;
- timeout follows contingency;
- decision bound to exact payment.
Late response race
If timeout policy says HOLD:
- gateway must not send when screening reply arrives later unless orchestration revalidates state.
This is a classic distributed-system defect.
Sanctions list-update reconciliation
After deployment:
- previous count;
- new count;
- additions;
- removals;
- modified aliases/identifiers.
Validate:
- engine loaded expected version.
Re-screen population
According to policy:
- customers;
- beneficial owners;
- open cases;
- pending payments.
Record completion.
Payment screening and privacy
Sanctions screening uses sensitive personal information.
Controls:
- least privilege;
- secure lists/case data;
- audit analyst access;
- retention.
Do not distribute full customer/list match spreadsheets by email.
Screening outsourcing
If vendor provides matching engine:
bank still owns:
- legal scope;
- thresholds;
- data sent;
- disposition;
- list freshness;
- oversight.
Contract should address:
- updates;
- availability;
- data protection;
- incident;
- model changes.
Vendor model update
Require:
- release notes;
- impact test;
- benchmark comparison.
A vendor changing fuzzy algorithm can alter false positives and misses materially.
Sanctions incident example
Production screening list failed to update after new regulation.
Incident response:
- identify stale period;
- load correct list;
- identify payments/customers screened during gap;
- retrospective re-screen;
- escalate matches;
- assess reporting/legal impact;
- remediate monitoring.
"List is current now" is not sufficient closure.
Customer communication edge cases
Possible match
Say:
"Your payment is under compliance review."
Avoid:
"You are on a sanctions list."
Additional information
Request factual identifiers where permitted:
- full legal name;
- DOB;
- entity registration.
Do not tell customer which answer would clear a specific listed party.
True match
Use approved legal/compliance wording.
Front line should not negotiate sanctions law.
Screening metrics interpretation
A sudden fall in alerts can mean:
- better data;
- threshold too high;
- list ingestion failure;
- volume decline.
A sudden rise can mean:
- new list;
- bad data;
- model change.
Metrics need change context.
Periodic control testing
Sample:
- released false positives;
- true hits;
- low-score non-alerts;
- list updates;
- travel-rule exceptions.
Independent challenge should verify both:
- effectiveness;
- customer impact.
Final sanctions/travel-rule readiness checklist
- legal sources current;
- autonomous + UN/terrorist sources understood;
- customer screening;
- payment screening;
- ownership/control escalation;
- list ingestion;
- travel-rule data;
- reasonable-measures workflow;
- false-positive governance;
- listed-property reporting;
- STR sanctions-evasion referral;
- outage procedure;
- evidence;
- metrics;
- test pack.
Sanctions compliance is effective when the bank can trace from legal source to exact payment action.
Sanctions screening completeness reconciliation
A sanctions platform should prove every in-scope payment was screened.
Population control
For each payment:
- payment ID;
- screening request;
- screening response;
- final disposition;
- release timestamp.
Break:
payment released with no valid screening disposition.
This is a high-severity control exception.
Batch
For a 1,000-item file:
- 1,000 item dispositions where item-level screening required;
- held items reconciled;
- released item count/value reconciled.
Real time
Monitor:
- payment count;
- screening calls;
- timeouts;
- fallbacks.
A drop in screening-call volume while payments remain stable can indicate integration failure.
List package control record
For each production package:
- package ID;
- source versions;
- downloaded time;
- deployed time;
- record count;
- checksum/hash if used;
- approver;
- validation result.
This enables historical proof.
[Fictional example] Ownership/control case study
Customer wants to pay Company Z.
Company Z is not named on list.
KYC/external research shows ownership chain:
Z → Parent Y → listed Person X.
Operations cannot determine legal prohibition from a simple match.
Process:
- hold;
- collect ownership evidence;
- sanctions/legal review applicable regulation;
- decide;
- record.
The lesson: name screening detects direct identity; ownership analysis determines some indirect legal risks.
[Fictional example] Sectoral restriction case study
Beneficiary itself is not listed, but transaction involves a sector/activity restricted by an applicable regulation.
Required data may include:
- goods/service;
- financing type;
- maturity;
- geography.
A list engine alone will not detect it.
Product and trade/compliance systems need a policy control.
Travel-rule exception handling metrics
Track:
- incoming incomplete covered EFTs;
- information successfully obtained;
- suspended;
- rejected;
- released after remediation;
- repeat sending institutions.
A recurring counterparty sending incomplete data may require escalation.
Reasonable measures evidence
Store:
- request date;
- channel;
- requested fields;
- response;
- final action.
"Missing travel rule" without evidence of reasonable measures is incomplete.
Sanctions payment repair restrictions
Operations sometimes repair:
- bank identifier;
- address;
- beneficiary spelling.
If screened fields materially change:
System should automatically invalidate prior disposition when configured critical fields change.
Prevent post-clear change
A user should not be able to:
- obtain CLEAR;
- edit beneficiary;
- release.
Bind disposition to data hash/version.
Screening of bank/agent parties
Cross-border messages can contain:
- debtor agent;
- intermediary agents;
- creditor agent.
Policy should define which are screened and how.
A correspondent relationship does not mean every agent is automatically safe for all sanctions purposes.
Reference-data enrichment
Screening platform may enrich:
- BIC to bank name/country;
- country codes;
- customer IDs.
Enrichment must be:
- sourced;
- versioned;
- not replace original.
Wrong BIC-country mapping can distort sanctions controls.
Sanctions case aging
Payment holds are time-sensitive.
Track:
- opened;
- last action;
- awaiting customer;
- awaiting legal;
- cutoff/value date;
- age.
Escalate aged cases.
But speed should not force unsafe false-positive clearance.
Quality assurance of false positives
Reviewer samples:
- high-score false positives;
- repeat suppressions;
- common-name cases;
- high-risk geography.
Check:
- secondary identifiers really distinguish;
- rationale sufficient;
- suppression appropriately scoped.
Sanctions risk assessment for new product
Example: new instant international payment product.
Assess:
- countries;
- parties available;
- screening latency;
- ownership data;
- travel-rule data;
- failure policy;
- return process;
- reporting.
A product with millisecond UX but inadequate party data may not be operationally compliant.
Screening outage tabletop
Scenario:
production list engine unavailable 45 minutes.
Decide before event:
- which products stop;
- alternate engine;
- in-flight handling;
- queued payments;
- customer message;
- post-recovery re-screen.
After:
- reconcile every payment during window;
- prove approved disposition.
Listed-property reporting evidence
For LP/EP report:
- property type/value;
- listed person/entity;
- legal/list source;
- date institution determined;
- statutory disclosure;
- FINTRAC submission;
- acknowledgment.
Because reporting is immediate, workflow should not share a five-day EFTR queue.
Screening operations desk design
Analyst UI should show:
- customer/payment;
- candidate list;
- secondary identifiers;
- regulation link;
- prior false-positive history;
- payment cutoff.
Avoid forcing analysts to search public websites manually for every routine match, while still providing authoritative source access.
Final sanctions control principle
Screening has three distinct correctness tests:
- coverage — did every required party/payment get screened?
- matching — did the engine identify plausible candidates?
- legal disposition — did an authorized function apply the correct obligation?
Passing one does not prove the other two.
Screening and settlement reconciliation
Compliance screening and payment settlement should reconcile through one identity chain.
Outgoing
payment ID
→ screening decision
→ release
→ network reference/UETR
→ settlement.
A sanctions case should never be detached from the payment it held.
Incoming
network reference
→ screening
→ legal disposition
→ posting/hold.
Break examples
Settled payment with no screening record
Critical control breach; investigate release path.
Screening CLEAR but payment never released
Operational, not sanctions failure.
Possible match closed false positive after cutoff
Customer/value-date impact should be captured even though sanctions result was correct.
List-update impact report
After each material update, produce:
- records added/removed;
- customers matched;
- pending payments matched;
- cases opened;
- suppressions invalidated;
- completion time.
This proves update effectiveness.
Sanctions case SLA versus legal quality
Set internal targets for:
- first review;
- customer information request;
- legal escalation.
But never auto-release solely because an SLA expired.
An aged case is a management issue, not permission to bypass legal review.
Screening test-data library
Maintain controlled test identities:
- exact listed;
- alias;
- transliteration;
- common-name false positive;
- entity;
- ship;
- ownership escalation.
Run after:
- engine upgrade;
- threshold change;
- list parser change.
Travel-rule completeness audit
Sample outbound/incoming covered EFTs and compare:
- customer/KYC source;
- message sent/received;
- stored record;
- compliance disposition.
Check that required information was neither lost nor fabricated during mapping.
Sanctions rule documentation
For each automated rule:
- legal/policy basis;
- scope;
- fields;
- decision;
- owner;
- test.
"Compliance asked for it" is not sufficient design documentation.
Final operational principle
A sanctions control must be able to prove:
- what information the bank possessed;
- what it screened;
- against which legal/list context;
- before which payment event;
- who decided;
- what action followed.
That is the difference between a match engine and a sanctions-control system.
Sanctions screening design review checklist
Legal scope
- applicable Canadian regimes identified;
- autonomous/UN/terrorist-property sources;
- country/sector restrictions;
- ownership/control escalation.
Data
- customer;
- beneficiary;
- agents;
- address/country;
- aliases/identifiers;
- travel-rule fields.
Screening
- list freshness;
- algorithm/version;
- threshold;
- pre-release integration.
Disposition
- false-positive procedure;
- legal review;
- licences/permits;
- payment/property action.
Reporting
- statutory disclosure;
- FINTRAC Listed Person or Entity Property Report;
- sanctions-evasion STR assessment.
Resilience
- list update failure;
- engine outage;
- queue;
- reconciliation.
Evidence
- list package;
- candidate;
- analyst;
- regulation;
- payment action.
[Fictional example] Case study — customer newly listed during payment day
09:00: payment created but held for later release.
10:00: list update deployed; customer becomes a confirmed listed person under applicable regulation.
10:15: batch release begins.
A correct design:
- re-screens or invalidates prior clearance according to policy;
- prevents automatic release;
- identifies customer property/accounts;
- invokes sanctions/legal procedure;
- handles disclosures/reporting.
A weak design:
- relies on screening done when payment was created before list update.
This illustrates why clearance needs a validity model.
[Fictional example] Case study — false positive with poor data
Incoming wire beneficiary name resembles listed person.
Payment has no DOB; address incomplete.
Analyst cannot safely clear based only on "probably different."
Workflow:
- seek additional reliable identifiers through approved process;
- retain hold;
- assess cutoff/customer impact;
- record evidence.
Data insufficiency is a valid case state.
Screening coverage control
Daily control:
number of externally released in-scope payments
versus
payments with valid sanctions disposition.
Expected difference = zero unless an explicitly approved contingency population exists and is reconciled.
Investigate any exception immediately.
Travel-rule plus sanctions integration example
Outgoing covered international EFT:
- retrieve verified originator information;
- collect beneficiary;
- validate travel-rule completeness;
- screen full parties;
- resolve matches;
- transmit without stripping required data;
- preserve sent message.
One data pipeline can support both obligations while keeping the legal decisions distinct.
Final screening mental model
Ask five questions:
- Who/what must be screened?
- Against which current legal/list sources?
- Before what payment/property event?
- Who has authority to disposition the match?
- What reporting or disclosure follows?
This prevents sanctions compliance from degenerating into a black-box name-score.
Sanctions operations readiness review
Before production, select:
- a clean payment;
- a common-name false positive;
- a probable true match;
- an incomplete travel-rule transfer;
- an existing customer newly listed.
For each, prove the exact source/list version, payment hold/release behavior, analyst authority, reporting path and retained evidence.
Legal-source freshness
Operations should have direct access to the applicable regulation or authoritative source from the case, not only a vendor's normalized list record. This is especially important when prohibitions vary by regulation or when list data changes rapidly.
Screening population reconciliation
At each reporting interval, unexplained released payments without a valid screening outcome should be treated as a control failure, even when no known sanctioned party is involved. Coverage is itself a control objective.
Screening-field design and data hierarchy
A screening platform should know which value is authoritative.
Customer legal name
Source:
Payment channel may display a nickname, but screening should use legal/approved customer identity according to policy.
Beneficiary name
Source:
- payment instruction/beneficiary master.
If beneficiary master contains:
- nickname;
- legal name;
- bank account holder name;
store them distinctly.
Agent name
Derive from:
- BIC/directory;
- message data.
Do not replace original message with enrichment; preserve both.
Country
Possible sources:
- customer address;
- beneficiary address;
- bank country;
- transaction route.
They are not interchangeable.
A payment can have a Canadian beneficiary with a foreign bank, or vice versa.
Screening data precedence
When sources disagree, define controlled precedence.
Example:
customer master legal name differs from free-text originator field.
The bank may need to:
- screen both;
- repair data;
- investigate.
Do not silently choose whichever gives fewer matches.
List-entry lifecycle
A listed party can be:
- added;
- amended;
- alias added;
- removed.
Screening system should process each event.
Removal
Removing a listing does not mean deleting historical evidence.
Keep:
- past list version;
- past cases;
- decisions under the law then in force.
Modified identifiers
An alias/DOB update can invalidate a prior false-positive rationale.
Trigger re-evaluation according to policy.
Payment hold accounting and customer status
A sanctions hold should not corrupt the customer ledger.
Possible design:
- customer funds reserved;
- payment status COMPLIANCE_HOLD;
- no external release.
If ultimately cleared:
If legally blocked/frozen:
- follow approved legal/accounting process.
Do not show "failed" while compliance review is active if that would misstate the state.
Incoming payment screening and posting
For incoming value:
- receive message;
- identify parties;
- screen;
- determine legal disposition;
- post/hold according to approved process;
- report/disclose where required.
If the payment settles at a system level before customer posting, operations must distinguish:
- interbank settlement;
- customer funds availability;
- sanctions action.
This distinction is particularly important for irreversible/high-speed rails.
Screening of non-name data
Depending on policy/legal risk, screening can consider:
- vessel IMO;
- entity registration;
- address;
- country;
- BIC;
- goods/sector context.
These are not all "names," so the data model should support typed screening attributes.
Sanctions evidence retention after release
False-positive cases matter because a later audit may ask why a payment was released.
Retain:
- candidate list entry;
- secondary identifiers;
- decision;
- reviewer;
- list version.
Do not delete false-positive evidence merely because payment completed successfully.
Screening operational capacity
Estimate:
- normal alerts/day;
- peak after major listing event;
- average handling time;
- legal escalations.
A large sanctions package can create a sudden re-screening surge.
Plan:
- additional staffing;
- prioritized payment queue;
- customer communication;
- no reduction in legal quality.
Sanctions implementation anti-patterns
Name screening only
Misses country/sector/ownership issues.
Vendor score = legal decision
Matching is not legal analysis.
Global whitelist
Can suppress future true matches.
Return every hit
Return itself may be prohibited.
Screen after payment
Too late for preventative control on final rails.
Use stale list during outage with no procedure
Creates unmeasured legal risk.
Strip rich data before screening
Reduces match quality.
Avoiding these patterns is as important as tuning the fuzzy-match algorithm.
Sanctions release-control acceptance criteria
Before production approval, demonstrate:
- a clean payment receives current-list clearance and releases once;
- a possible match cannot reach the external gateway;
- a false-positive disposition releases only the exact screened payment data;
- a true-match case invokes the approved legal action and reporting workflow;
- a screening timeout follows the documented contingency;
- a list update invalidates/re-evaluates affected pending decisions as designed;
- an incoming incomplete travel-rule transfer enters the reasonable-measures workflow;
- a returned/refund payment is screened as a new movement where applicable;
- every released in-scope payment can be reconciled to a valid screening decision.
Operations evidence
For each test retain:
- payment reference;
- party data;
- list package;
- candidate;
- disposition;
- user/automated rule;
- gateway result;
- regulatory report where applicable.
Customer-impact verification
Check:
- possible-match status wording is accurate;
- false positives are released without unnecessary duplicate instructions;
- held payments do not appear completed;
- no customer-facing message discloses sensitive sanctions-case reasoning beyond approved wording.
This final acceptance step proves the screening control in the actual payment journey rather than only inside the sanctions engine.
11. Practical payment-screening scenarios
[Fictional example] Scenario 1 — common-name false positive
A Canadian customer sends CAD 5,000 to "Mohamed Ali" abroad.
Name match is high.
Analyst compares:
- DOB;
- address;
- nationality;
- beneficiary bank data;
- list identifiers.
The beneficiary is not the listed person.
Record false-positive rationale and release.
[Fictional example] Scenario 2 — list changes after onboarding
A corporate customer was clean at onboarding. A beneficial owner is later listed.
The list update triggers re-screening.
Compliance evaluates:
- entity relationship;
- applicable regulation;
- property;
- payment restrictions;
- disclosure/reporting obligations.
The bank does not wait for the next customer payment to notice.
[Fictional example] Scenario 3 — missing travel-rule address
An incoming covered EFT arrives without beneficiary address.
The bank:
- applies reasonable measures;
- follows risk-based travel-rule procedure;
- determines suspend/reject/follow-up according to policy.
It does not silently insert a placeholder address.
[Fictional example] Scenario 4 — sanctioned-property account
The bank identifies property it has reason to believe is owned/controlled by a listed person under an applicable regime.
The case may require:
- legal restriction/freeze treatment;
- statutory disclosure;
- immediate Listed Person or Entity Property Report to FINTRAC;
- STR analysis if a transaction/attempt suggests sanctions evasion.
[Fictional example] Scenario 5 — ISO mapping truncation
A payment arrives with full structured party data. A legacy downstream mapper strips part of an address before screening.
This is a control defect: the bank screened less information than it possessed.
Correct design screens the rich record and logs any downstream truncation separately.
12. Key takeaways and authoritative references
Key takeaways
- Sanctions, travel rule, AML and fraud are separate controls.
- The Consolidated Canadian Autonomous Sanctions List is an operational resource, not the law itself.
- The applicable regulation determines the prohibition.
- The travel rule is an information-carriage obligation for covered EFTs.
- Missing travel-rule data requires reasonable measures and risk-based procedures.
- Screening should happen before release/posting where the bank can still prevent prohibited activity.
- A possible name match is not a confirmed sanctions hit.
- Listed-property reporting can be triggered without a transaction.
- Listed Person or Entity Property Reports can be immediately required.
- STR obligations can also arise for suspected sanctions evasion.
- ISO 20022 improves screening only when rich data is preserved and used.
- List/version evidence must be reproducible.
Authoritative references
Sanctions change frequently. The applicable legislation, regulation, licence/permit, official listing and current legal advice govern live decisions.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.