Sanctions Screening Evidence: What to Show Your Bank

A common problem in crypto banking reviews is not the absence of screening -- it is the absence of evidence that screening is systematic. A screenshot of a green checkmark or a one-line "no results found" rarely gives a bank enough information to understand what was screened, when it was screened, which data source was used, and how the result was retained.

This is not only a technology problem. It is a documentation problem. A bank reviewing a crypto client has to understand the client's controls, make a risk-based decision, and keep enough records to support that decision during a supervisory review.

This guide covers the evidence bank compliance teams commonly ask for and how to assemble a screening package without overstating what the law requires.

---

What bank compliance teams actually evaluate

Bank relationship managers often ask for "KYC documents" and "compliance documentation." The compliance team behind that request is usually evaluating something more specific: can this client demonstrate a systematic, ongoing, auditable sanctions screening process?

The word "systematic" matters. A one-time check says little about tomorrow. The word "ongoing" matters. Screening at onboarding but not at relevant transaction or data-change events may be a gap. The word "auditable" matters most. If the bank's reviewer asks "how do you know client X screens for sanctions?", the answer should be in the file.

FATF's risk-based approach for virtual assets and VASPs gives banks and supervisors a practical frame for this review: identify the risks, understand the controls, and decide whether residual risk fits the bank's risk appetite.

That question is answered by documentation, not conversation.

---

The 5 elements of a practical screening evidence package

A useful sanctions screening evidence package contains five sections. Each addresses a different concern that bank compliance teams may have when evaluating crypto company accounts. Missing one does not automatically mean denial, but it creates a follow-up question the bank will need to resolve.

1. Methodology statement

   A 2-4 page document explaining how your screening works. This covers: which sanctions regimes and data sources you screen against, which blockchain networks you monitor, how frequently sanctions data is updated in your system, and what matching logic you use (exact match, fuzzy match, phonetic matching for name screening).

   For EU PSPs and CASPs, the legal anchor is Regulation (EU) 2023/1113 and EBA/GL/2024/15, which apply from 30 December 2025 and focus on Union and national restrictive measures when performing transfers of funds and crypto-assets. They do not create a universal MiCA rule that every CASP must screen against EU, UN, OFAC, and UK lists in every case. Include OFAC, UK, UN, or other regimes where they apply to your legal footprint, counterparties, currencies, correspondent banking arrangements, or the bank's stated risk appetite.

   Your methodology should also specify screening triggers: customer onboarding, regular customer database screening, changes in sanctions data or customer due diligence data, transaction screening, and escalation when there are reasonable grounds to suspect circumvention. What banks look for: specificity. "We screen against all major sanctions lists" is not a methodology. "We screen customers and transfer parties against EU and Cyprus restrictive measures, update internal screening data immediately after a measure enters into force or changes, and add OFAC/UK screening for USD/GBP exposure and requested bank coverage" is much more useful.

2. Sample screening report

   A concrete example of what your screening output looks like -- a single screening event rendered as a document. It should include: a timestamp (date and time, with timezone), the identifier screened (wallet address, transaction hash, or entity name), which data source was checked, the list version or publication date used, the screening result, and a unique report identifier.

   The sample report demonstrates two things: that your screening produces actual documentation (not just a UI indicator), and that the documentation contains enough detail to reconstruct the screening decision later. If your screening tool returns only "sanctioned" or "not sanctioned" with no additional context, you do not have a screening report -- you have a boolean.

   What banks look for: the report should be exportable (PDF or structured data), timestamped, and ideally signed or integrity-verified so the bank can confirm it has not been altered after the fact.

3. Screening policy document

   Your internal policy governing when screening happens, who is responsible, and what occurs when a potential match is found. This is distinct from the methodology (which covers how) -- the policy covers when, who, and what then.

   A screening policy typically includes: screening triggers (onboarding, transfer or transaction events, periodic customer re-screening, ad hoc checks), escalation procedures for potential matches, the decision-making authority for true positive vs. false positive determinations, reporting to sanctions authorities and SAR/STR filing where applicable, record retention periods, and the review cycle for the policy itself.

   What banks look for: evidence that screening is not ad hoc. The policy should be board-approved or signed by senior management, dated, and version-controlled. An undated Word document does not inspire confidence.

4. Historical audit log

   This is the element that is hardest to reconstruct after the fact. The audit log is proof that screening has been happening continuously -- not just on the day you prepared the evidence package. It shows a history of screening events over time: how many checks were performed, when, against which data sources, and what the outcomes were.

   There is no fixed regulatory lookback period for a bank evidence pack. A bank may ask for recent history, a longer lookback, or the period since launch depending on its risk assessment and the relationship. The format does not need to be complex -- a CSV export or summary dashboard showing screening volume by day/week, list coverage, and match rates may be enough for a first review. What matters is continuity: explain the period covered, any gaps, and whether full underlying logs are available on request.

   What banks look for: evidence of continuous operation. A log showing 10,000 screening events over 8 months, with consistent daily volume and zero unexplained gaps, is far more convincing than a log showing 50,000 events all on the same day (which looks like a bulk backfill).

5. Vendor attestation

   If you use a third-party screening provider, the bank wants to know who provides the screening, what services they provide to you, and what data sources and update commitments apply. A vendor attestation or provider documentation can confirm: the services provided, the sanctions data included, update frequency, data retention, and any relevant certifications.

   Vendor documentation does not transfer your compliance responsibility to the vendor. EBA/GL/2024/15 says the ultimate responsibility for compliance with restrictive measures remains with the PSP or CASP even when functions are outsourced. If your provider is less known, include more detail on data sources, uptime, update handling, alert workflow, and audit-log exports.

   What banks look for: that the provider documentation matches your methodology. The attestation should confirm coverage, data freshness, and -- critically -- whether the vendor provides audit-trail-grade output or only pass/fail results.

---

Point-check tools vs. evidence-grade screening

Public or free screening tools can be useful for spot checks, especially when you need a quick answer on a wallet address or name. Before relying on any tool in a bank evidence pack, check the provider's current documentation for list coverage, update frequency, export options, retention, and terms of use.

The gap is often not the point-check result itself. It is whether the check creates retained evidence that a bank can review later:

This is not about one tool being "better" than another. A point-check tool can answer a narrow screening question. A bank evidence package has to answer the documentation question: what was checked, against what source, when, by whom or by which system, what result came back, what alert handling followed, and where the record is retained.

---

Template: what a screening evidence package looks like

When assembling your evidence package for a bank, structure it as a single submission with clearly labeled sections. Here is the structure that addresses all five compliance concerns:

1. Cover letter (1 page)

Brief overview of your company, your current regulatory status (for example, MiCAR-authorised CASP, non-EU VASP, or other applicable status), and a summary of your sanctions compliance program. State which sanctions regimes you screen for and why they apply to your business.

2. Sanctions screening methodology (2-4 pages)

Lists screened, update frequency, matching logic, blockchain coverage, screening triggers. Reference your screening provider by name. Include a version number and approval date.

3. Screening policy (3-5 pages)

Internal procedures: when screening occurs, escalation matrix, reporting to sanctions authorities and SAR/STR filing where applicable, record retention aligned to your legal obligations, review cycle. Board-approved or senior-management-approved, dated, signed.

4. Sample screening reports (2-5 pages)

Two or three example reports showing: a clean result (no match), a false positive investigation (match flagged, investigated, cleared with reasoning), and optionally a demonstration of re-screening on a list update. Each report timestamped, with unique identifiers.

5. Audit log summary (1-3 pages)

Aggregate statistics for the period requested by the bank or the most recent period you can substantiate: total screening events, daily/weekly volume, list coverage per check, match rate, false positive rate, and investigation status. Present as a table or dashboard screenshot. Do not send raw log files by default -- summarize for readability, but note that full logs are available on request.

6. Vendor attestation (1-2 pages)

Letter, certificate, or provider documentation confirming: services provided, sanctions data covered, update frequency, data retention, and any relevant certifications or assurance reports.

---

Why this specific package works

The five-element structure maps to common bank due diligence questions and to the FATF guidance on VASPs. It is not a legal safe harbour and it does not guarantee account approval. It simply makes the review easier to evidence:

• Methodology answers "what do you screen, when, and against which applicable regimes"
• Sample reports answer "what does your screening output look like" -- the question compliance teams always ask but rarely formalize
• Policy document answers "governance and oversight" sections in any due diligence questionnaire
• Audit log answers "is this operating over time, not only during onboarding"
• Vendor attestation answers "what third-party service is used, and what remains your responsibility"

The EBA access-to-financial-services guidelines make clear that credit and financial institutions should manage ML/TF risks through policies, procedures, and controls rather than unsubstantiated de-risking. Your evidence package helps the bank make a documented, risk-based decision instead of guessing.

---

Common documentation gaps banks may challenge

These documentation gaps commonly create follow-up questions in bank reviews:

• Submitting a screenshot instead of a report. A browser screenshot of "No results found" is not evidence. It has no timestamp verification, no list version, no integrity guarantee, and no way for the bank to file it as a formal compliance record.
• Claiming screening without audit trail. "We use [tool name] for sanctions screening" is a statement, not evidence. If you cannot export a log showing that screening actually happened on specific dates for specific identifiers, the statement is unverifiable.
• Screening only at onboarding. A policy that only screens at customer onboarding leaves no evidence of what happens when sanctions measures change or when relevant transfers occur. For EU PSPs and CASPs, EBA/GL/2024/15 sets out regular customer database screening, event-based customer screening, and transfer screening against applicable restrictive measures.
• No match investigation process. If you have never had a potential match, and your documentation does not describe what you would do if you did, the bank has no confidence that you can handle one. Include your escalation procedure and, ideally, a sample false positive investigation.
• Undated, unsigned policy documents. A screening policy without a date, version number, or management signature looks like it was created for the bank application rather than being an operational document. Version-control your policies and have them signed by your MLRO or compliance officer.

---

Frequently asked questions

What sanctions screening documentation do banks ask for from crypto companies?

There is no universal bank format. A practical evidence package usually includes: (1) a methodology statement covering applicable sanctions regimes, data sources, update frequency, and matching logic; (2) sample screening reports that are timestamped and show the input, result, and list source; (3) a written screening policy with escalation and reporting procedures; (4) historical audit logs showing that screening is operational over time; and (5) vendor attestation or provider documentation where a third-party tool is used.

Why do bank reviews stall even when a crypto company screens for sanctions?

Reviews often stall because the applicant can state that screening happens but cannot show how it happens, when it happened, which data was checked, and how alerts are handled. A pass/fail result without a timestamp, list source, retained log, or escalation record gives the bank limited evidence for its own due diligence file.

Can I use free sanctions screening tools for bank compliance evidence?

Public or free screening tools can be useful for point checks, but bank evidence depends on the current provider documentation and on your own logging. If a tool returns only a pass/fail result, or does not retain timestamped reports and audit logs, supplement it with your own records or use a workflow that can generate exportable, retained evidence.

How far back do banks want to see sanctions screening history?

There is no fixed regulatory lookback period for a bank evidence pack. A bank may ask for recent history, a longer lookback, or the period since launch depending on its risk assessment and the relationship. The important point is continuity: explain the period covered, any gaps, and whether full underlying logs are available on request.

What is a sanctions screening methodology statement?

A methodology statement explains how your company performs sanctions screening: applicable sanctions regimes, data sources, blockchain networks, matching logic, update frequency, screening triggers, alert investigation, and record retention. For EU CASPs and PSPs, EBA/GL/2024/15 under Regulation (EU) 2023/1113 focuses on Union and national restrictive measures for transfers; OFAC, UK, UN, or other regimes should be included where they apply to your business, bank, counterparties, or legal footprint.

---

Bottom line

Sanctions screening evidence is the gap between "we checked" and "here is a retained record of what was checked, when, against which source, and how alerts were handled."

A useful evidence package -- methodology, sample reports, policy, audit log, vendor attestation -- takes effort to assemble the first time. After that, it is maintenance: keeping logs running, updating policies when your process or legal obligations change, and generating fresh reports when a bank requests them.

Start building the evidence trail before the bank asks for it. Every screening event you log now is one more data point in the audit history that a future reviewer can inspect.