The term sanctions lists is used for public lists of people, companies, and organisations that are subject to restrictions or financial sanctions. They matter at onboarding, in supplier reviews, and during ongoing follow-up when teams need to decide whether a match really belongs to the party being reviewed and what should happen next. Record source + timestamp + rationale + policy version + owner role for every material outcome.

Quick answer

• Sanctions lists are used when a new customer, supplier, or counterparty needs to be checked, and when existing relationships are reviewed again.
• Keep the search input, the list that was checked, how the match was assessed, and who owned the decision so the review can be replayed later.
• A common mistake is treating a name hit as a final answer before checking whether it belongs to the right person or company.
• Clear sanctions-screening records make it easier to escalate the right cases quickly and explain later why a hit was dismissed or followed up.

Records to keep (for traceable control)

• Search input and identity details: Show which names, dates, or company details were actually used in the check — Store as: Search log with timestamp
• List source and jurisdiction: Explain whether the check covered EU, OFAC, UN, or another relevant list — Store as: Source row with list and version
• Match assessment and rationale: Explain why the result was considered true, false, or unclear — Store as: Review note with rationale field
• Decision and escalation outcome: Show whether the case was stopped, followed up, or routed onward — Store as: Decision row with status and action
• Responsible role and decision date: Show who owned the outcome and when it was taken — Store as: Owner field with date

Definition and scope

Sanctions lists are used to identify whether a person, company, or organisation is subject to restrictions that affect whether you can or should do business with that party. In operational terms, that means teams need to compare the right identity data against the right lists and then assess whether the result truly belongs to the party being reviewed.

That makes the topic broader than the search itself. A sanctions-lists control includes input data, matching, assessment, and documentation. If those parts do not stay connected, it becomes hard to show later why a hit led to a stop, why it was dismissed as a false positive, or why the case was routed for deeper review.

For many teams, scale is also part of the issue. Manual lookups may work at low volume, but once onboarding and follow-up need to move faster, the organisation needs the same logic, the same sources, and the same evidence structure every time.

Why it matters

Sanctions lists shape which relationships you can start, which counterparties require deeper review, and when an existing relationship needs to be reopened. This applies not only to customers but also to suppliers, partners, and other entities that need to be checked before an agreement continues or a transaction goes ahead.

Weak records create avoidable remediation work. If a later reviewer cannot see which list was checked, which identity details were used, or why a match was dismissed, the organisation ends up relying on memory instead of evidence.

It also affects follow-up over time. A party that did not return a hit at onboarding can appear on a list later. That means the same review logic needs to run again when new risk facts arrive, without forcing the team to rebuild the case from zero.

How matches should be assessed

A sanctions-list result is not automatically a final decision. Teams first need to assess whether the search really belongs to the right person or the right company. Name similarity alone is rarely enough, especially when the input lacks unique identifiers or when transliterations and alternate spellings are involved.

That means input quality matters. Full names, dates of birth, company names, and other known attributes make it easier to decide whether a match is relevant or should be dismissed as a false positive. The weaker the input, the more manual context the team needs before moving forward.

Once the match has been assessed, the outcome needs to be documented. Teams should be able to show whether the case was stopped, escalated, or cleared to proceed, and why. That is the difference between a technical match and a traceable risk decision.

Common pitfalls

• Name hits are treated as final answers even though the input is too weak to determine whether the result belongs to the right party.
• List checks are recorded, but the jurisdiction or list version used is missing from the case file.
• False positives are dismissed without a clear rationale, which makes later review difficult.
• Onboarding checks are completed once, but the same relationship is not reviewed again when sanctions status may have changed later.
• Decisions and ownership are stored in a different system from the screening evidence, making the outcome hard to replay.

These failures are usually operational rather than theoretical. The issue is rarely whether teams know sanctions lists must be checked. The issue is whether the control, the judgement, and the documentation actually stay together in the same review flow.

A process for sanctions lists

1) Collect enough identity data

Set out which names, dates, company details, or other attributes need to be present before a sanctions check is considered strong enough. This reduces the number of unnecessary false positives caused by weak input.

2) Check against the right lists

Define which lists and jurisdictions should be part of your standard control. That makes it possible to show whether EU, OFAC, UN, or other relevant checks were actually included in each material case.

3) Keep the match separate from the decision

Separate the technical result from the final assessment. That makes it clear when a case needs more verification and when the match has enough context to justify a stop, escalation, or approval.

4) Follow up when status changes

Sanctions-list checks are not only a start-of-relationship activity. If an existing counterparty later receives changed status, the same relationship should be reopened with the earlier evidence, the new result, and the new rationale in one traceable record.

Roaring field guide

• Define which identity inputs are required before a sanctions check is considered reliable enough to move forward.
• Store search input, list source, assessment, and decision rationale so the outcome can be replayed later.
• Keep the technical match separate from the risk decision so a hit does not silently become the final answer.
• Route hits with enough context to the right team or process when a case needs manual assessment.
• Re-check existing relationships when sanctions status changes instead of relying on a one-off onboarding lookup.

How Roaring can help

• The sanctions-lists service can check people and companies against multiple international lists in one flow and reduce the need for manual lookups.
• Integration Suite can bring identity data, screening steps, and decision inputs into existing onboarding or supplier-review workflows.
• Lookup can act as the entry path for teams that want to test data, run one-off manual checks, or understand information needs before building an integration.
• Monitoring and webhooks can support follow-up when an existing customer or counterparty receives changed sanctions status after onboarding.