Audit-Proof Sanctions Documentation: What to Show Your Bank, Acquirer, or Auditor

Q: Is sanctions screening evidence retention a legal requirement, or just good practice?

It depends on jurisdiction and licensing status, so confirm specifics with compliance counsel — but in most payments contexts it is not purely a best-practice suggestion. In the EU, EBA/GL/2024/15 sets governance and control expectations specifically for payment service providers and crypto-asset service providers, effective from 30 December 2025. In the UK, the FCA's Financial Crime Guide sets screening expectations for payment and e-money institutions. In the US, OFAC's compliance framework and the FFIEC examination procedures used on sponsor banks both evaluate the documentation behind a screening decision, not just whether screening occurred.

Disclaimer: This article is for informational purposes only and does not constitute legal advice. Sanctions rules, list data, and bank due-diligence expectations change over time. If you have a live match or a complex scenario, involve qualified counsel and/or your bank's compliance contact. MatchAudit focuses on operationally reliable screening and evidence retention, not legal interpretation. The walkthrough example in this article uses a fictional company for illustration only.

Quick links:

Featured snippet

Audit-proof sanctions documentation is a record that shows, for every screening decision, what was screened, when and against which source, what the result was — including any matches that were reviewed and cleared, and who made and approved the final decision. For payments and fintech compliance teams, this record is what a sponsor bank, acquirer, card scheme, or regulator asks for during due diligence or a file review — not a description of your screening process in the abstract.

Key takeaways
Why "we screened them" isn't what your bank is asking for
Where these expectations actually come from
What belongs in a sanctions screening evidence pack
Step-by-step: building an audit-proof file
Documenting a decision when two screening providers disagree
Consolidating results from multiple screening providers
Reconstructing a decision after a regulator or bank request
Evidence that survives a file review vs. evidence that doesn't
What examiners and auditors actually ask for
Evidence pack checklist (copy/paste)
How MatchAudit operationalizes this
Official sources

Key takeaways

A sponsor bank or acquirer periodic review is not asking "do you screen?" — it's asking "show me the last five sanctions decisions your team made, with evidence."
"We ran a check and it came back clean" is an activity log, not evidence. Evidence includes the inputs, the source, the result, and a documented decision.
This isn't just good practice — it's what real frameworks describe. OFAC's Framework for Compliance Commitments, the Wolfsberg Group's sanctions screening guidance, the FFIEC's BSA/AML examination procedures, and the EU's newest EBA guidelines for payment and crypto-asset service providers all point to the same underlying expectation: a documented, retrievable, risk-based screening control — not just a "clear" result.
Payments and fintech teams commonly run more than one screening source (a primary provider plus manual list checks, a secondary tool after a provider migration, or parallel checks for high-risk flows). Where two sources disagree, the disagreement and how it was resolved is what a reviewer wants to see — not a single clean result with the other one deleted.
A file review works because every decision can be pulled back up months later, by subject, case, or date — not because someone remembers it.

Why "we screened them" isn't what your bank is asking for

Payments companies, PSPs, and fintechs sit inside someone else's risk appetite: a sponsor bank, an acquiring bank, a card scheme, or a banking-as-a-service partner. That relationship comes with periodic due diligence, and sanctions screening is one of the first things reviewed — usually by sampling a handful of onboarding or transaction decisions and asking for the file behind each one.

In practice, the request rarely sounds like "describe your sanctions program." It sounds much more specific:

"Pull the onboarding file for merchant X and show us the screening result."
"We flagged a wire to a counterparty in a higher-risk jurisdiction last quarter — what did your team do about it?"
"Your last account review shows a possible-match disposition marked 'cleared.' Walk us through why."

Each of those is a request for a single, specific, retrievable record — not a policy document. This is the gap that most often shows up in that moment: it isn't that screening didn't happen, it's that the evidence behind it doesn't hold together.

Where the evidence typically breaks down

The result lives somewhere that no longer exists. A screening provider dashboard that nobody exported before the account was closed, downgraded, or migrated to a new tool.
The reasoning was never written down. A reviewer cleared a possible match verbally or in a Slack thread, and the case file just shows "cleared" with no explanation.
A second check quietly overwrote the first. After a provider outage, a plan change, or a manual re-run, only the newer result survived — and nobody can show what the original screening actually returned.
Nobody can say which list version a decision was based on. Sanctions lists update continuously; a decision made against last month's list version needs to be identifiable as such.
The approval step isn't documented. The analyst who reviewed the hit is identifiable, but who approved proceeding — and when — is not.

None of this means the underlying decision was wrong. It means the decision can't currently be shown. For a bank or acquirer that has to answer for your account in its own audits, an unprovable decision is treated the same as a missing one — because from the reviewer's seat, there is no way to tell the difference between "we made a defensible call and lost the paper trail" and "we never made the call at all."

Practical takeaway: treat every sanctions decision as something that will be requested later, by someone who wasn't in the room. Build the record at decision time, not when the request arrives.

Where these expectations actually come from

It's worth being precise about this: "keep evidence, not just activity logs" isn't a stylistic preference. It is the consistent theme across the frameworks that banks, acquirers, and regulators use to judge sanctions compliance programs — including ones that apply directly to payment institutions today.

OFAC's Framework for Compliance Commitments (2019, US)

OFAC's Framework for OFAC Compliance Commitments sets out five components that OFAC — and by extension the banks that rely on OFAC's enforcement posture — expect from a sanctions compliance program: management commitment, risk assessment, internal controls, testing and auditing, and training. The "internal controls" component is where screening and recordkeeping live: OFAC explicitly evaluates whether an organization's controls, including screening and documentation, functioned as intended when it determines enforcement outcomes. A screening process without a retrievable record behind it does not satisfy that component, regardless of how accurate the underlying check was.

The Wolfsberg Group's Guidance on Sanctions Screening

The Wolfsberg Group — an association of global banks that produces widely adopted financial-crime compliance standards — publishes guidance specifically on sanctions screening controls. It covers the fundamentals of a screening programme, a risk-based approach to screening, alert generation and handling, reference data quality, and list management and lookbacks — i.e., being able to show what was screened against which list, at what point in time, and being able to re-run that check retrospectively if a list changes. This is effectively an industry definition of what "evidence" needs to contain, written by the banks that will be reviewing your file.

The FFIEC BSA/AML Examination Manual (US bank examiners)

US bank examiners use the FFIEC BSA/AML Examination Manual's OFAC section to test a bank's OFAC controls — and by extension, the controls of the payments companies and fintechs that bank sponsors. The manual directs examiners to sample transactions and accounts and evaluate the filtering criteria used, the timing of the search, and the documentation maintained evidencing the searches. That is a near-exact description of what this article calls an evidence pack: not "did you screen," but "show me the criteria, the timing, and the proof."

EBA Guidelines for payment and crypto-asset service providers (EU, in force now)

This is the most directly relevant development for EU-based payments and fintech teams. The European Banking Authority finalized two related guideline sets on restrictive-measures compliance — EBA/GL/2024/14 (governance and risk management, for financial institutions broadly) and EBA/GL/2024/15 (specifically for payment service providers and crypto-asset service providers), covering the screening systems and transaction-monitoring controls needed to prevent funds from reaching designated persons or entities. Both guideline sets became applicable on 30 December 2025. If your business is a PSP, e-money institution, or CASP operating in the EU, these guidelines are not background reading — they describe current supervisory expectations for exactly the evidence question this article covers.

The FCA's Financial Crime Guide (UK)

For UK-regulated payment and e-money institutions, the FCA's Financial Crime Guide, Chapter 7 sets out expectations for sanctions and asset-freeze controls, updated in late 2024. It expects firms to screen not only customers but counterparties and payment recipients, using screening systems appropriate to the firm's size and risk — and to be able to demonstrate that screening happened as designed.

The common thread across all five: none of them ask for a narrative description of your process. They ask whether a specific decision, on a specific subject, at a specific point in time, can be shown — with the inputs, the source, the result, and the reasoning intact.

What belongs in a sanctions screening evidence pack

A reviewer expects a consistent structure, not a narrative. At minimum, a defensible sanctions screening evidence record includes:

A) Record summary

A short business reference (case ID, onboarding ID, or transaction reference)
What the review was for (onboarding, periodic re-screen, transaction hold, change event)
Review status and final decision (e.g. "Proceed — no relevant match identified")
Created, reviewed, and (if exported) export timestamps

Example: "Case ONB-2026-0417 — onboarding review for [merchant]. Status: Approved. Decision: Proceed, no relevant match identified. Created 2026-04-17T09:12Z, reviewed 2026-04-17T10:40Z."

B) Screened subjects

Who or what was screened (legal entity, individual, UBO, director, counterparty)
Their role in the relationship (customer, beneficial owner, payment counterparty)
The identifiers used (name variants, DOB, jurisdiction, registration number where available)

Example: Subject 1 — "Acme Merchant Services Ltd," role: customer entity, jurisdiction: Ireland, registration number included. Subject 2 — "J. Novak," role: beneficial owner (31% holding), DOB and nationality included.

C) Evidence and source material

The screening report or output itself, not just a pass/fail summary
Where each piece of evidence came from — external screening provider, internal checklist, onboarding document, registry extract
Upload timestamp and, where possible, a file integrity value (e.g. a SHA-256 hash) so a file can be shown to be unaltered since it was captured

Example: "acme-merchant-screening-report.pdf — source: Provider A — uploaded 2026-04-17T09:15Z — SHA-256 recorded — status: Stored."

D) Decision and rationale

The outcome: clear, escalate, or block
If there was a possible match: what matched (name, alias, identifier), why it was or wasn't treated as a true match, and what differentiators were checked
Who reviewed the case and who approved the decision, with timestamps

Example: "Possible match: name similarity to a listed individual (85% score). Differentiators checked: DOB differs (subject born 1988, listed individual born 1963); nationality differs. Disposition: false positive, cleared. Reviewed by: [analyst]. Approved by: [compliance lead], 2026-04-17T10:40Z."

E) Audit trail

A stable case or record identifier that ties every action back together
A timeline of what happened — screened, reviewed, escalated, approved, exported
The ability to retrieve and export the full record on demand

This is the same structure behind MatchAudit's sample evidence pack: a record summary, subjects with their screening result, evidence files with source and hash, and a decision and audit timeline tied to one case.

Step-by-step: building an audit-proof file (worked example)

The sections above describe the components. This section walks through how they come together on an actual case, from the moment a subject is screened to the moment a bank asks for the file. The company and individuals below are fictional and used for illustration only.

Scenario: "Northbridge Pay," a fictional PSP, is onboarding a new merchant — an e-commerce business with one beneficial owner above the 25% disclosure threshold.

Step 1 — Capture the screening inputs before you screen

Before running any check, the reviewer records exactly what will be searched: the merchant's registered legal name plus known trading name, the beneficial owner's full name, date of birth, and nationality as declared on the KYB form. This matters because if a possible match later needs to be explained, the reviewer needs to show what was actually typed in, not just what the merchant's file says today (names get corrected, respelled, or updated later).

Example record: "Screened: 'Northbridge Retail Solutions Ltd' (legal), 'Northbridge Shop' (trading name); beneficial owner 'Elena Marchetti,' DOB 1990-03-11, Italian nationality."

Step 2 — Run the screening and preserve the full output

The team runs the check through its primary screening provider. The result — not just a summary badge, but the actual report — is saved with a timestamp and linked to the case.

Example: Provider A returns "No exact match; one low-confidence alias match (62%) on the beneficial owner's name against an unrelated listed individual with a different DOB and country." The full report PDF is attached to the case.

Step 3 — Apply a documented triage rule, not a judgment call in isolation

Rather than a reviewer deciding ad hoc, the team applies a pre-agreed rule: matches below a defined confidence threshold with a differentiating identifier (DOB, country) are treated as false positives and logged, not silently discarded.

Example: "62% confidence, DOB and country both differ from the listed individual → classified as false positive per Northbridge Pay's screening policy, threshold rule 3.2. No escalation required."

Step 4 — Write the rationale at the time of the decision, not afterward

The reviewer adds one or two sentences explaining the disposition — enough for someone with no context to understand it a year later.

Example: "Cleared. Match is name-similarity only; DOB (1990 vs. 1963) and nationality (Italian vs. listed individual's declared nationality) both differ. No further identifiers align. No escalation warranted under policy 3.2."

Step 5 — Record the approval as a distinct action

The case is routed to a second reviewer (or the compliance lead, depending on the firm's policy) for approval — a distinct, timestamped action from the initial review, even if the same conclusion is reached.

Example: "Approved by [compliance lead], 2026-04-17T10:40Z. Approval note: 'Agree with analyst disposition, no further action.'"

Step 6 — Store it under one stable reference, not scattered files

Everything above — the inputs, the screening report, the triage note, the rationale, and the approval — is attached to a single case reference (e.g. ONB-2026-0417), not spread across an email thread, a spreadsheet row, and a provider dashboard.

Step 7 — When the request arrives, export — don't reconstruct

Eight months later, Northbridge Pay's sponsor bank runs its annual review and asks for the onboarding file on this exact merchant. Because every step above was attached to case ONB-2026-0417 from day one, producing the file is an export, not an investigation: the reviewer pulls the case by merchant name or case ID and generates a reviewer-readable PDF showing steps 1 through 5 in order.

This is the difference an evidence-first workflow makes: the work of building the file happens once, at decision time. Everything after that — a bank review, an internal audit, a regulator request — is retrieval, not reconstruction, not a manual assembly job the week the request lands.

Documenting a decision when two screening providers disagree

This is the situation most sanctions screening tooling isn't built for, and it comes up more often in payments and fintech than teams expect: a provider migration, a parallel check for a high-risk flow, or a manual list lookup that returns a different result than the primary tool.

The instinct is to keep the "clean" result and move on. That's the wrong instinct for an evidence file, for two reasons: a reviewer who later finds the discrepancy in a data export will ask why it was resolved silently, and the reasoning that resolved it — the part that actually shows compliance judgment — is exactly what gets lost.

Worked example: two providers, two different answers

Continuing the Northbridge Pay scenario: six months after onboarding, a routine re-screening cycle runs the same beneficial owner, Elena Marchetti, through both the primary provider (Provider A) and a secondary tool the compliance team recently added for higher-risk re-screens (Provider B).

Provider A returns: no match.
Provider B returns: a 74% confidence match against a name on a regional sanctions list, with a matching country but no DOB provided by the list source.

A workable approach, step by step:

Keep both results as separate evidence items, tied to the same subject and the same case — not overwritten, not merged into one summary line. Example: "Provider A result: no match, screened 2026-10-03. Provider B result: 74% match, list [X], screened 2026-10-03. Both retained."
Record what each source actually returned, including which fields matched and any confidence or match score provided. Example: "Provider B match based on name similarity and country of residence; no DOB, passport, or registration number available from the list entry to confirm or rule out."
Investigate the gap before writing the rationale. In this example, the reviewer requests additional identifying information (date of birth, passport number) from the merchant's onboarding file and compares it against any available detail on the listed entry.
Write a short reviewer rationale explaining which result the final decision relied on, and why. Example: "Provider B's match lacked DOB for confirmation. Cross-checked against onboarding KYC file: subject's passport number and DOB do not correspond to any public detail associated with the listed entry. Treated as a false positive; documented per policy 3.4 (partial-identifier matches require corroboration from onboarding records before clearance)."
Record the approval the same way you would for a single-source decision — ideally from a senior reviewer given the higher ambiguity.

Practical takeaway: two sources disagreeing is not a problem to hide. It's a normal input to a documented decision, and documenting it properly is stronger evidence than a single unchallenged "clear."

Consolidating results from multiple screening providers

Payments and fintech teams end up running more than one screening source for reasons that have nothing to do with sloppy process:

A provider migration in progress, with old and new results both live for a transition period
A primary sanctions/PEP provider plus a separate adverse-media or watchlist tool
Regional or list-specific checks layered on top of a global provider
Manual checks used as a stopgap during an outage or contract gap

The risk isn't running multiple sources — it's that results end up scattered across dashboards, spreadsheets, and inboxes with no shared reference. When a bank or auditor asks for a file, someone has to reconstruct it from memory of where each piece lives.

A workable model, step by step

Assign one case ID or subject reference that every source's result attaches to, regardless of which tool produced it — before the first screening event, not retroactively.
Keep the source name on every piece of evidence (which provider, which dataset, or "manual check") rather than presenting results as if they came from one system.
Do not delete historical results when you switch or add a provider. An auditor reviewing a decision from before the switch needs to see what was actually screened and returned at that time — not what your current provider would return today.
If you're migrating providers, plan the evidence migration alongside the technical one. Export the outgoing provider's historical results before the contract ends, and attach them to the same case references your new provider will use going forward, so historical cases stay retrievable under one scheme rather than splitting into "before the switch" and "after the switch" archives that don't talk to each other.
Periodically confirm you can actually retrieve a pre-migration case. The test isn't whether the export exists somewhere — it's whether a reviewer unfamiliar with the migration can find it in under a few minutes.

This is the same underlying need as documenting a provider disagreement (above): a shared case record that multiple sources can attach evidence to, without one overwriting another.

Reconstructing a decision after a regulator or bank request

A file review or regulator request rarely arrives with much notice, and it rarely targets a decision from last week. It's usually a sample pulled from months or years of activity: "show us the sanctions screening file for this customer's onboarding in [month]."

What determines whether that request is a five-minute export or a multi-day scramble is whether decisions were made retrievable at the time they happened, not reconstructed afterward.

What the request actually looks like, step by step

The request specifies a subject, case, or time window — rarely "send everything." E.g., "provide the sanctions screening evidence for [merchant] related to the account opened in April 2026."
Someone has to locate the case. If case references are consistent and searchable by subject name or ID, this takes minutes. If evidence lives across email, a provider trial account, and a spreadsheet, this takes days — and some of it may no longer be retrievable at all.
The full record is assembled, ideally already structured (inputs, source, result, rationale, approvals) rather than built from scratch.
The file is exported in a reviewer-readable format — not a raw data dump, and not a screenshot with no context. A reviewer needs to be able to read it without a walkthrough call.
The response is delivered inside the requester's timeframe, which is often measured in days for a periodic review, and can be much shorter for a regulator inquiry.

Trigger	What's requested	What you need to produce it
Bank/acquirer periodic due diligence	Sample of recent onboarding or transaction decisions	Case-level record: subjects, sources, result, decision, approval
Regulator inquiry into a specific relationship	Full history of decisions for one subject	All screening events for that subject, in order, with rationale
Internal audit / file review	Statistically sampled cases across a period	Consistent record structure across cases, exportable in bulk
Partner or acquirer onboarding of your business	Evidence your program produces defensible records	A representative sample export (e.g. a sample evidence pack)
Provider migration lookback	A case screened under a since-retired provider	Historical evidence retained and linked to the same case reference (see "Consolidating results from multiple screening providers" above)

Practical takeaway: the test of an audit-proof program isn't whether today's decisions look clean. It's whether a decision from ten months ago can be reconstructed as easily as one from this morning.

Evidence that survives a file review vs. evidence that doesn't

Situation	Fails a file review	Survives a file review
Screening result	A screenshot of a "clear" badge, no report attached	The full screening report, source-labeled and timestamped
Possible match	"Cleared — not the same person" with no supporting detail	Which fields matched, which differentiators were checked, and why the match was ruled out
Two providers disagree	Only the clean result is kept; the flagged one is discarded	Both results retained, source-labeled, with a documented rationale for the final decision
Approval	Reviewer's name only, no distinct approval step	Reviewer and approver identified separately, both timestamped
Case retrieval	"Let me check with the analyst who handled this"	Retrievable by subject, case ID, or date in minutes
Provider switch	Historical provider's results deleted or inaccessible after migration	Historical results retained and linked to the same case reference
List version	No record of which list/dataset version was checked	Source and, where available, dataset version or "last updated" timestamp recorded

What examiners and auditors actually ask for

1) What should a sanctions screening evidence pack include for a bank or acquirer review?

At minimum: the subject screened (with identifiers used), the source and timestamp of each screening result, the reviewer's decision and written rationale, who approved the decision, and a stable reference or case ID that ties the record to the underlying business relationship. Supporting files (screening reports, registry extracts, ownership documents) should be attached with upload timestamps and, where possible, a file integrity hash.

2) How do we document a sanctions decision when two screening providers disagree?

Keep both results as separate evidence items tied to the same subject and case, rather than overwriting one with the other. Record which provider flagged what, on which fields, and then write a short reviewer rationale explaining which result the final decision relied on and why. The disagreement itself, and the reasoning that resolved it, is what an examiner is checking for — not a single "clean" result.

3) What do examiners and auditors actually ask for in a sanctions file review?

In practice, reviewers ask for four things: what was screened (exact names/identifiers), when it was screened and against which source or list version, what the result was including any matches that were investigated and cleared, and who made and approved the final decision. Screenshots or a "no hit" note without that context are usually treated as insufficient. The FFIEC's BSA/AML examination procedures describe this directly: examiners sample transactions and evaluate the filtering criteria used, the timing of the search, and the documentation maintained evidencing the searches.

4) How do you reconstruct a sanctions screening decision after a regulator request?

You need every decision retrievable by subject, case, or date without depending on one person's memory or inbox. That means the original screening inputs, results, reviewer notes, and approvals are stored together under a stable reference from the start, so a case from months or years earlier can be pulled and exported on demand.

5) Do we need to keep evidence from every screening provider we've used?

Yes, for any subject or case where a provider's result contributed to a decision. If you switch providers or run parallel checks, retain the historical evidence rather than deleting it — an auditor reviewing an older decision needs to see what was actually screened and returned at that time, not what your current provider would return today.

6) Is sanctions screening evidence retention a legal requirement, or just good practice?

It depends on your jurisdiction and licensing status, so this is a question for your compliance counsel — but it is not purely a best-practice suggestion in most payments contexts. In the EU, EBA/GL/2024/15 sets governance and control expectations specifically for payment service providers and crypto-asset service providers, effective from 30 December 2025. In the UK, the FCA's Financial Crime Guide sets screening expectations for payment and e-money institutions. In the US, OFAC's enforcement framework and the FFIEC examination procedures used on sponsor banks both evaluate the documentation behind a screening decision, not just whether screening occurred.

7) What's the difference between an "evidence pack" and a normal screening report?

A screening report shows what one tool returned for one search. An evidence pack ties that report — and any others, from any other source — to the subjects involved, the reviewer's written rationale, the approval, and an audit trail, all under one retrievable case reference. The report is an input to the evidence pack, not a substitute for it.

Evidence pack checklist (copy/paste)

Minimum viable audit-proof record, per screening decision:

[ ] Case ID / business reference assigned at the time of the decision
[ ] Subject(s) screened, with role and identifiers used
[ ] Screening source(s) recorded (provider name, dataset, or "manual check")
[ ] Full result retained (not just pass/fail), including any matches reviewed
[ ] If multiple sources were used: each result kept as separate evidence,
    with a rationale for the final decision
[ ] Reviewer and approver identified, with timestamps
[ ] Supporting files attached with upload timestamp and, where possible,
    a file integrity hash
[ ] Record retrievable by subject, case, or date without manual reconstruction
[ ] Export produces a reviewer-readable file, not a raw data dump

How MatchAudit operationalizes this

Most screening tools can tell you whether a check ran. They are not built to answer the questions in this article — what was screened, from where, reviewed by whom, and retrievable how. That's a different product surface, and it's the one MatchAudit is built around:

Screening Evidence Hub holds the case-level record described throughout this article: source material from external screening providers, involved subjects, reviewer notes, decision context, audit events, and file integrity metadata — all attached to one case, retrievable by subject or reference.
Multiple providers, one case. Because the Evidence Hub stores source material as discrete evidence items rather than overwriting a single "result" field, a second provider's output — or a manual re-screen — becomes additional evidence attached to the existing case, exactly as described in the provider-disagreement walkthrough above.
Cases & Review is where the reviewer rationale and approval steps live, separate from the initial screening action — so "who reviewed" and "who approved" are always distinguishable, matching what examiners are trained to look for.
Evidence Pack export turns a case into the reviewer-readable file a bank, acquirer, or auditor actually asks for, instead of a manual assembly job the week the request lands.

It doesn't replace your screening provider, and it isn't a second-opinion engine — it's the vendor-neutral layer that keeps whatever your providers return, and whatever your reviewers decided, in one defensible record.

See it on a real case

Start free: run a screening and see what the resulting evidence record looks like.
See a sample evidence pack: review the sample evidence pack structure with your compliance lead before your next bank or acquirer review.
Check pricing: see plans if you're ready to move beyond ad-hoc screenshots.

Official sources

OFAC, A Framework for OFAC Compliance Commitments: ofac.treasury.gov
Wolfsberg Group, Guidance on Sanctions Screening: wolfsberg-group.org
FFIEC BSA/AML Examination Manual, Office of Foreign Assets Control section: bsaaml.ffiec.gov
European Banking Authority, Guidelines on internal policies, procedures and controls to ensure the implementation of Union and national restrictive measures (EBA/GL/2024/14 and EBA/GL/2024/15): eba.europa.eu
FCA Handbook, Financial Crime Guide, Chapter 7 — Sanctions, asset freezes and proliferation financing: handbook.fca.org.uk