Sanctions compliance: screening, match verification, and decision logging
Sanctions compliance means proving that your institution does not do business with sanctioned individuals or entities. TruvaLI extends screening to onboarding, transaction execution, and continuous re-screening as lists change, logging every match with its justification.
Sanctions compliance ensures that an institution does not enter into business relationships or conduct transactions with individuals and entities subject to national and international sanctions. This obligation is not a one-time check: the existing customer base must be re-screened every time a list changes.
When does screening run?
| Stage | What is screened | Why |
|---|---|---|
| Customer onboarding | Individuals, companies, and UBOs in the ownership chain | Sanctions must be detected before establishing a relationship |
| Transaction execution | Sender, recipient, and intermediary parties, if any | Payments must not be sent to a sanctioned party |
| List updates | Entire existing customer base | A clean customer yesterday may be sanctioned today |
| Periodic review | Customers selected based on risk classification | Documenting the freshness of records |
Screening during transactions must run without interrupting the payment flow. How this is set up is explained on the payment screening page.
How is a match verified?
Name similarity alone cannot justify a decision. Secondary information in the record tests the match: aliases, Cyrillic and Arabic transliterations, date and year of birth, ID and passport numbers, nationality, country, and city. In a sanctions or adverse media match, the individual's photo is retrieved from the source and displayed with a confidence score.
The validity dates of the record are also checked: alerts generated by lifted sanctions steal the team's time from real matches. Every record is stored alongside the issuing authority and its country, answering the question of which regime a match originates from.
How are lists kept up to date?
A screening process is only as good as the freshness of its underlying data. Three methods work in tandem.
The official source itself is monitored. For countries not covered by off-the-shelf lists, the source itself is defined: a national sanctions announcement, a parliamentary member list, or a cabinet page. The page is scraped at defined intervals, sub-links are discovered, and the resulting records enter screening with their source links.
Adverse media feeds are polled. Keywords, languages, and countries are defined; news feeds are regularly polled, and relevant publications are queued for review. Records are not created automatically: a human decides which news article turns into a record.
Regulatory bulletins are read. A bulletin, decision text, or PDF list is uploaded; the text is parsed, and the individuals and entities within are converted into structured records.
Institutions can also build their own lists. Details are available on the custom screening lists and sanctions, PEP, and adverse media screening pages.
Why are false matches so expensive?
The cost of sanctions screening lies not in missed matches, but in the volume of false matches. A common name screened without verification signals generates hundreds of alerts, forcing the team to search for the real match within this pile. Having verification signals in the record is therefore not a luxury, but a matter of capacity.
Where the threshold is set is the institution's decision and is written as a rule. How many alerts a new threshold will generate on historical traffic can be previewed using rule simulation.
What happens after a match?
A match opens a case. The case is stored with its justification, evidence, and decision chain: who reviewed it, what information they looked at, what decision they made, and who approved it. The decision is written to an immutable audit trail. The entire workflow is detailed on the alert and case management page.
If a notification is required, the case is converted into a report. The regulatory reporting page explains this step.
Common questions
- When does sanctions screening run?
- During customer onboarding, at the moment of transaction, across the entire existing customer base when lists change, and during periodic reviews based on risk classification.
- How is a match verified?
- Aliases and transliterations, date of birth, ID and passport numbers, nationality, and city information are evaluated together. The photo is retrieved from the source and displayed with a confidence score, and the validity date of the record is also checked.
- Do lifted sanctions generate alerts?
- No. The validity dates of the record are read, and a lifted decision does not generate an alert.
- Can you see which authority a match originates from?
- Yes. Every record is stored with the issuing authority and its country, and the source link is also preserved.
- Can an institution add its own sanctions list?
- Yes. Through official source definitions, feed polling, or document uploads, the institution's own lists enter the same screening workflow.
- How is the burden of false matches reduced?
- Since verification signals are stored in the record, name similarity alone does not generate alerts. Where the threshold is set is written as a rule, and how many alerts a new threshold will generate on historical traffic is previewed via simulation.
- How does the process proceed after a match?
- A match opens a case. The review, decision, and approval chain is logged with its justification and written to an immutable audit trail. If a notification is required, the case is converted into a report.
- Does screening data leave the institution?
- Not in an on-premise deployment. Lists, screening, and decisions all remain entirely within the institution's own infrastructure.