A screening system generates a possible match against a customer, supplier, beneficiary or payment party. A second reviewer needs to understand why it was cleared or escalated. A screenshot is not enough.
The record should show what triggered the alert, which identifiers were compared, what remained uncertain, who authorised the outcome and what happened next.
This guide begins where the practical sanctions-screening guide reaches a candidate result. It presents an operational model, not a universal legal checklist. The applicable regime and facts determine legal analysis, reporting and final action.
A sanctions alert is an investigation trigger, not a legal conclusion
A screening alert reflects configured matching or rule logic. It identifies a candidate that needs attention; it does not, by itself, establish that the screened person or entity is the designated target.
OFAC FAQ 48 explains that interdiction software may flag transactions that are not actually associated with sanctions targets and recommends initial analysis and additional research. OFSI's UK Financial Sanctions General Guidance likewise distinguishes a name match from a target match.
Terms such as alert, potential match, target match, ownership finding and legal prohibition should not be used as though they describe the same conclusion. An opening case note should state the subject and data screened, candidate, source, trigger and time, then identify what remains open: identity, ownership, transaction nexus, an applicable prohibition, an exception or licence, or the required action.
Keep the stages of a sanctions investigation separate
The stages connect, but one does not prove the next. Strong identity similarities can still require a separate assessment of ownership, programme scope or transaction treatment.
- 1Capture the alert
Retain the trigger, screened subject, input, candidate, source and screening time.
- 2Compare identity
Test the available identifiers against the complete official designation record.
- 3Assess context
Review ownership, control, relationships or transaction facts where they are relevant.
- 4Frame the legal question
Identify the applicable regime, programme, restriction, exception or licence question.
- 5Authorise the outcome
Route the facts to the accountable reviewer and record the approved action.
- 6Retain the evidence
Keep the rationale, sources, approvals, action and any reporting or reopening instruction.
Capture screening and alert provenance
Record the party screened, trigger, exact input, identifiers supplied, authority or list where known, candidate record, source-record reference and timestamp. Whether screening originates through a portal, API, batch or configured monitoring, preserve the delivery route. The guide to API vs. batch sanctions screening explains those models in a supplier context.
Resolve identity using the fuller record
Compare available information with the complete official list entry, not the matching name alone. OFAC's name-match guidance identifies attributes such as full name, address, nationality, passport or tax identifiers, place and date of birth, former names and aliases as potentially relevant.
Document similarities, conflicts and missing information. If a decisive field is unavailable, record what was requested and why the case can or cannot proceed. A match score is not proof of identity.
Assess ownership, control and relationship context where relevant
An unlisted entity can raise a separate ownership or control question, but the tests differ. OFAC's 50 Percent Rule guidance addresses aggregate direct or indirect ownership by blocked persons, while OFAC FAQ 398 makes clear that the rule concerns ownership rather than control alone. UK guidance applies its own ownership and control framework. EU analysis begins with the applicable legal act and current interpretation; the European Commission's Regulation 269/2014 opinion describes a fact-specific determination in that programme context.
Record the ownership chain, percentages, control facts, sources and dates actually considered. Do not present one worldwide threshold or use an AML beneficial-ownership threshold as a substitute for sanctions analysis. See sanctions ownership and control for the jurisdictional distinctions.
Frame the applicable sanctions question
Identity and ownership findings are inputs to the legal assessment. The record should identify the jurisdiction, programme, activity or transaction in question and any relevant prohibition, authorization, exception or licence. If the issue is escalated, state the question sent to the authorised reviewer rather than recording a vague note such as “sent to compliance.”
Record the authorised action
Operational outcomes can include clearance, requesting information, escalation or a policy-defined internal hold. Record freezing, blocking, rejecting or reporting only where the applicable regime and facts support them.
Under OFAC rules, blocking and rejection are different treatments. OFAC's blocking and rejecting guidance also explains that not every OFAC programme involves blocking. An internal workflow hold is not automatically an OFAC block or a UK or EU asset freeze.
What to record in a sanctions-alert investigation
The most useful case record allows another reviewer to reconstruct the decision without relying on the original analyst's memory. The following fields form a practical control model; they are not a universal statutory form.
| Evidence category | What to record | What it allows a reviewer to establish |
|---|---|---|
| Case provenance | Case or alert ID, trigger, customer, supplier or transaction reference, screening time and assigned reviewer | Which event and record the investigation concerns |
| Screening input | Exact name or entity name, identifiers supplied and relevant related-party role | What data entered the control |
| Screening source | Authority, list or programme where known, candidate identifier, source timestamp or retained version | What the input was compared against |
| Candidate record | Candidate name, aliases and relevant official identifiers | The baseline for comparison |
| Attribute comparison | Similarities and conflicts across names, dates, nationality, address, registration details and IDs | Why identity was cleared, supported or left unresolved |
| Missing information | Unavailable, conflicting or stale fields and attempts to obtain them | Which uncertainty remains and how it was handled |
| Relationship context | Account, supplier, beneficiary, intermediary or transaction role using the data available | How the party connects to the business event |
| Ownership or control | Ownership chain, percentages, controller facts, sources and dates where relevant | Which regime-specific ownership question was assessed |
| Findings and rationale | Supporting and contradicting facts, source references and unresolved points | How the reviewer moved from evidence to disposition |
| Applicable-regime question | Jurisdiction, programme, legal issue, guidance, licence or advice reference where applicable | Why identity resolution did not itself decide legal treatment |
| Interim state | Whether the workflow continued, paused or escalated, who authorised that state and why | How operational risk was controlled during review |
| Decision and approval | Disposition, decision-maker, approver, escalation and timestamps | Who was accountable for the outcome |
| Action and reporting | The authorised operational or legal action; authority, report reference and artifact where reporting occurred | What happened after the decision |
| Retained evidence | Source extracts, attachments, correspondence, legal or licensing records and relevant system history | Whether the case can be reproduced later |
| Governance metadata | Procedure or policy version, QA status and reopening or monitoring instruction | Which operating control governed the case |
Screenshots can support a record, but can omit the input, source version, reviewer activity or outcome. Keep evidence proportionate. A clear conflict may need a concise rationale; complex ownership or payment context may require more sources and approvals. A generic “false positive” or “cleared” label is not enough.
Document why the alert was cleared, escalated or left unresolved
A small set of operational dispositions can keep case language precise without pretending to decide the law too early.
Non-match or cleared identity
State the decisive conflicts showing that the screened subject is not the designated target. A name may be similar while date of birth, nationality and passport details materially conflict. Record the candidate, source and facts supporting clearance; “false positive” alone does not explain the decision.
Credible or confirmed identity requiring sanctions assessment
Record the identifying basis, then route the programme, ownership, legal nexus, prohibition, authorization and action questions to the authority named by policy. Show who made the determination and what supported it. A confirmed identity is not an automatic instruction to block every transaction.
Unresolved
State what remains missing or contradictory, who owns the escalation, the current operational state and what is needed. Record the next step and review point.
Where configured records remain in scope, a later source or profile change may warrant reopening or reassessment. Supplier-specific triggers are covered in when to rescreen suppliers.
Adapt the record to customer, supplier and payment alerts
The case structure can stay consistent while the relevant context changes.
For a customer alert, retain the customer or account identifiers, relationship state, information available at the time and relevant ownership context. Connect the alert to the correct record.
For a supplier or third-party alert, add the contracting entity, supplied corporate information, relevant owners or controllers, the party's role and the approval or payment context. The guide to supplier and third-party sanctions screening covers the wider relationship and lifecycle; the supplier screening checklist covers procurement gates and evidence.
For a payment alert, preserve the payer, payee, beneficiary, intermediary and available transaction data, plus its stage and operational status. The relevant evidence and treatment depend on the programme, transaction and facts.
31 CFR §501.603 addresses reports concerning blocked property, while 31 CFR §501.604 addresses rejected transactions. These U.S.-specific requirements illustrate context that can matter after legal action; they are not a global template.
Escalation, reporting and retention depend on scope
Escalation is normally part of policy and governance unless a specific legal rule provides otherwise. Name the owner, question and supporting facts. “Escalated” alone is not a reviewable investigation.
Reporting duties also vary. Current OFAC rules set specific reporting requirements for blocked property and rejected transactions, including a ten-business-day deadline within their respective scope. OFSI guidance describes reporting obligations that depend on the applicable rules and, for some duties, whether an organisation is a relevant firm. Do not assume that every alert must be reported or that one deadline applies globally.
Retention must follow the applicable jurisdiction, sector, licence, legal requirements and internal policy. As a scoped U.S. example, 31 CFR §501.601 currently requires full and accurate records for transactions subject to the OFAC chapter to be available for at least ten years, with separate wording for blocked-property records. That is not a universal sanctions-investigation retention period.
Governance should also distinguish legal obligation from control design. The Council of the EU's Best Practices for restrictive measures describes itself as non-exhaustive and non-binding and distinguishes legal obligations from recommended practice. An organisation may choose additional review fields, workflow holds, approvals and QA steps, but should label them as policy controls rather than universal law.
Frequently asked questions
Does a sanctions alert mean someone is sanctioned?
No. OFAC and OFSI both distinguish an initial potential or name match from a resolved target determination. Compare the available subject information with the fuller official record and investigate material similarities, conflicts and gaps.
What information should be recorded when clearing an alert?
Record the candidate, identifiers compared, decisive differences, sources, rationale, reviewer, timestamp and outcome. This is a practical control derived from official match-resolution guidance, not a universal statutory form.
What if the name and date of birth both match?
Do not prescribe an automatic outcome. Obtain and compare additional identifiers where available and escalate unresolved or strong similarities under the applicable procedure. State which information is still missing.
When should ownership or control be investigated?
Investigate it where an entity or relationship creates a relevant question under the applicable regime. U.S., UK and EU approaches differ. Record the facts and sources used rather than applying one global formula.
Does a potential payment match have to be blocked?
Not as a universal rule. OFAC distinguishes blocking from rejecting, and not every OFAC programme involves blocking. Other jurisdictions have their own frameworks. The applicable regime, transaction and facts determine the required action.
Is placing a transaction on hold the same as freezing or blocking it?
No universal equivalence should be claimed. A workflow hold can be an internal control pending investigation. A legal freeze or block arises only when the governing legal conditions apply.
Does every sanctions alert have to be reported?
No universal rule applies. OFAC has specific rules for blocked property and rejected transactions. UK reporting duties depend on the applicable rules and scope, including defined obligations for relevant firms.
How long should investigation records be retained?
Follow the applicable jurisdiction, sector, licence and legal requirements plus the organisation's retention policy. OFAC's current ten-year provision applies within its defined U.S. scope; it is not a global standard.
Connect the signal, reasoning and outcome
A reviewable case moves from the original screening signal to the identifying facts, relevant ownership or transaction context, applicable legal question, analyst reasoning, escalation, authorised outcome and retained evidence.
Checklynx can support sanctions screening using supplied customer, third-party and ownership context; route potential matches through Case Management; preserve rationale and supporting records through Audit Trail & Evidence; and export the retained case evidence and report artifacts needed to prepare downstream Regulatory Reporting. Policy interpretation, escalation, the decision to report and final approval remain with the customer's compliance function.
CONTROLLED SANCTIONS ALERT REVIEW
Keep each sanctions alert connected to its evidence and outcome
See how Checklynx can support sanctions screening, controlled case review, rationale, evidence and configured ongoing monitoring.
Official sources
- OFAC: Assessing OFAC Name Matches
- OFAC FAQ 48: responding to an interdiction alert
- OFAC: Blocking and Rejecting Transactions
- OFAC: Entities Owned by Blocked Persons and the 50 Percent Rule
- OFAC FAQ 398: ownership versus control
- 31 CFR §501.601: Records and recordkeeping requirements
- 31 CFR §501.603: Reports concerning blocked property
- 31 CFR §501.604: Reports of rejected transactions
- OFSI: UK Financial Sanctions General Guidance
- Council of the EU: Best Practices for the effective implementation of restrictive measures
- Council Regulation (EU) No 269/2014: consolidated text
- European Commission opinion on Article 2(2) of Regulation 269/2014