Sanctions Screening Implementation Guide: From Excel to API in 30 Days

If you're running a small crypto-asset service provider, there's a good chance your sanctions screening process started as a spreadsheet. Someone downloads the OFAC SDN list, pastes wallet addresses into Excel, and runs a VLOOKUP. It works -- until it doesn't. Until a list update gets missed. Until an analyst skips a row. Until a CySEC inspector asks for your audit trail and you hand them a .xlsx file with no timestamps.

This guide walks you through the migration from manual spreadsheet screening to automated API-based sanctions checks. Not in theory -- in practice. A 30-day roadmap with specific deliverables for each week, an evidence-friendly database schema, and the controls expected under EBA GL/2024/15, the EU Transfer of Funds Regulation, and applicable Union or national restrictive measures.

As of this 10 July 2026 refresh, EBA GL/2024/15 is already in application; its application date was 30 December 2025. The article therefore treats those guidelines as current supervisory expectations, not a future deadline.

What are the four maturity levels of sanctions screening?

Before you plan the migration, understand where you are today. Sanctions screening maturity falls into four levels. Many small CASPs start at Level 1. EBA GL/2024/15 points toward Level 3-style controls: effective screening, documented list management, trigger-based customer screening, transfer screening, and evidence of alert handling.

Level 0: No screening. Under applicable restrictive measures, a CASP must not make funds or crypto-assets available to designated persons or carry out prohibited transfers. EBA GL/2024/15 says PSPs and CASPs should have an effective screening system to identify targets of restrictive measures. No screening is a direct legal and licensing risk.

Level 1: Manual Excel checks. The most common starting point. An analyst downloads a sanctions list, pastes customer wallet addresses into a spreadsheet, and checks for matches. Problems: the list can be stale, individual checks may lack reliable timestamps, and a single typo in a wallet address can mean a missed match. If the process is OFAC-only, it also fails to address EU restrictive measures that apply to EU CASPs.

Level 2: Single-list API integration. A step up. You integrate a sanctions screening API -- often the Chainalysis free sanctions API -- into your transaction workflow. Addresses are checked automatically before transfers. The limitation is coverage and evidence: a single-list or binary response may not show which restrictive measures were checked, which list version was used, or how alerts were investigated. If you're an EU-licensed CASP, you need documented, timestamped screening records -- not just a binary check.

Level 3: Automated applicable-list screening with audit trail. The target state. Customer and transfer data is screened against applicable Union and national restrictive measures, with additional lists such as UN, OFAC SDN, or the UK Sanctions List where your legal nexus or risk policy requires them. Every check is logged with a timestamp, the list version used, and the result. Matches trigger a documented investigation workflow. This aligns with EBA GL/2024/15 and CySEC's supervisory focus on effective, tested screening systems.

What do you need before you start?

Before writing a single line of code or evaluating tools, get three things clear: which lists, which screening points, and what happens when you get a match.

Which sanctions lists -- legal minimum vs risk coverage

Do not treat "EU + UN + OFAC + UK" as a universal MiCA checklist. For an EU-licensed CASP, the legal baseline is the restrictive measures that apply to you: Union restrictive measures and any applicable national restrictive measures. Your risk assessment may then add other official lists because of customers, counterparties, jurisdictions, banking partners, or ownership.

1. EU Consolidated Financial Sanctions List -- maintained by the European Commission and used to facilitate EU asset-freeze screening. The binding legal source remains the relevant EU legal act in the Official Journal, so keep list versioning and legal-act references where your tool provides them.
2. National restrictive measures -- Member State measures that apply to your entity. In Cyprus, CySEC Circular C685 says its thematic inspections focused on UN and EU lists and also reviewed relevant U.S. and UK screening practices.
3. UN Consolidated List -- maintained by the UN Security Council. UN designations are implemented by Member States through legal measures, but direct UN screening is a common control because it helps identify timing or implementation gaps.
4. OFAC SDN List and other OFAC lists -- maintained by the U.S. Treasury. Mandatory for U.S. persons and U.S.-nexus activity; for an EU-only CASP it is a risk-based addition, not a MiCA mandate.
5. UK Sanctions List -- the current UK official source for designations. As of 28 January 2026, the OFSI Consolidated List of Asset Freeze Targets is closed and no longer updated.

CySEC Circular C685 is relevant because it sets supervisory expectations and best-practice benchmarks for regulated entities, including CASPs. It should not be read as a blanket rule that every Cyprus CASP must screen OFAC and UK lists in every case; document the legal and risk basis for each list in your policy.

Screening points: when to screen

EBA GL/2024/15 sets out trigger points and transfer-screening controls:

1. Onboarding. Screen customer information before the business relationship is established. For CASPs, include wallet addresses where they are available and relevant to the restrictive measures being screened.
2. Pre-transfer. Screen transfers of crypto-assets before making the crypto-assets available to the beneficiary. Screen all parties and relevant transfer data, including wallet addresses to the extent that official restrictive-measures lists include wallet addresses.
3. Ongoing and trigger-event screening. Screen the customer database regularly, with frequency based on your restrictive-measures exposure assessment. Trigger screening when a designation or restrictive measure changes, when CDD data changes materially, or when circumvention is suspected.

Match handling: what happens when you hit a positive

Before you automate screening, you need a documented procedure for handling matches. Regulators ask about this specifically. Your procedure should distinguish between:

• True positive: The party, address, or asset is genuinely subject to an applicable restrictive measure. Action: suspend or block the transfer, freeze or hold assets as required, notify your MLRO, and report to the relevant national authority, supervisory authority, or FIU where applicable law requires it.
• False positive: The screening flagged an address that is not actually sanctioned (e.g., partial string match, address reuse on a different chain). Action: document the investigation, record the reasoning for the false-positive determination, have a senior compliance officer or MLRO approve the override, and release the transaction.

Both outcomes should be logged. A regulator wants to see not just that you screened, but that you had a rational, documented process for acting on the results.

What does the 30-day implementation roadmap look like?

This roadmap assumes a small CASP with 1-2 developers and a compliance officer. If you have a larger team, you can compress the timeline. If you're a solo founder wearing all hats, add a buffer week.

Week 1: Policy and procedures

Do not start with code. Start with documentation. Your sanctions screening policy is the document a regulator may ask for before they look at any technology.

1. Draft your Sanctions Screening Policy. This is a standalone document (3-5 pages) that covers: which lists you screen against and why, when screening occurs, who is responsible for screening (role, not name), how matches are handled, escalation procedures, and record retention periods aligned to AML/CFT and local sanctions requirements.
2. Define your match handling SOP. A step-by-step procedure: analyst identifies match, escalates to MLRO within [timeframe], MLRO investigates and determines true/false positive, true positives are reported to the relevant authority or FIU where required, and all steps are documented in the screening log.
3. Get board or management sign-off. The policy needs to be approved at the appropriate level. For a small CASP, this is usually the director or the board. Date-stamp the approval -- regulators check this.
4. Assess your current state. Document exactly what you're doing today (even if it's Excel). This becomes your baseline for demonstrating improvement.

Week 2: Tool selection and API integration

Now you build the technical layer. Your tool selection criteria should prioritize:

• Applicable-list coverage. The tool should support the Union and national restrictive measures you have to apply. Add UN, OFAC, UK, or other lists where your legal nexus, banking partners, or risk assessment requires them.
• List update handling. The tool should identify new, updated, or lifted restrictive measures and update the internal screening dataset immediately after the change enters into force.
• Audit trail built in. Every screening should be logged automatically: timestamp, data screened, lists checked, list version, trigger, result. If you have to build the audit trail yourself, you're adding engineering and control work.
• API-first design. You need a REST API you can call from your transaction processing pipeline. A web dashboard you log into manually is Level 1 with extra steps.
• Re-screening support. The tool should support trigger-event and batch re-screening, with frequency and triggers documented in your policy.

For a detailed comparison of available tools, see our sanctions screening tools comparison. For understanding the limitations of free options, read our analysis of the Chainalysis free oracle.

Integration itself is straightforward. A typical sanctions screening API call looks like this:

# Screen a wallet address against the lists in your policy
curl -X POST \
  "https://api.example.com/v1/screen" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "0x1234...abcd",
    "chain": "ethereum",
    "lists": ["ofac_sdn", "eu_consolidated", "un_consolidated"],
    "reference_id": "txn_2026031301"
  }'

# Response (clean address)
{
  "address": "0x1234...abcd",
  "screened_at": "2026-03-13T14:30:00Z",
  "lists_checked": [
    { "name": "ofac_sdn", "version": "2026-03-12" },
    { "name": "eu_consolidated", "version": "2026-03-10" },
    { "name": "un_consolidated", "version": "2026-03-01" }
  ],
  "matches": [],
  "result": "clear"
}

# Response (sanctioned address)
{
  "address": "0xdead...beef",
  "screened_at": "2026-03-13T14:31:00Z",
  "lists_checked": [ ... ],
  "matches": [
    {
      "list": "ofac_sdn",
      "designation": "Lazarus Group",
      "category": "sanctions",
      "source_url": "https://sanctionssearch.ofac.treas.gov/..."
    }
  ],
  "result": "match"
}

The integration point in your code is simple: before processing any outbound transfer, call the screening API. If the result is "match", block the transfer and trigger your match handling SOP. If "clear", proceed. Store the full response either way.

Week 3: Testing

This is where many implementations fall short. Teams integrate the API, verify it returns results, and call it done. Testing should be more rigorous than that.

1. Test with known sanctioned records. Use records from the official lists covered by your policy. If OFAC is in scope, OFAC-published digital currency addresses are useful test cases. If EU, UN, or UK lists are in scope, use records from those sources as name/entity tests.
2. Test list divergence. Screen records that appear in one official source but not another. This catches tools that claim multi-list coverage while only checking one dataset.
3. Test edge cases. Screen addresses in different formats (checksummed vs. non-checksummed for Ethereum). Screen addresses on chains your customers actually use. Screen an address, then re-screen after a simulated list update to verify re-screening works.
4. Batch screening test. Export all customer addresses from your database and run a full batch screen. This simulates ongoing re-screening. Measure how long it takes -- if re-screening 500 addresses takes 4 hours, your re-screening process has a timing problem.
5. Match handling walkthrough. Simulate a true positive hit. Walk through your entire SOP: analyst receives alert, escalates to MLRO, MLRO investigates, tests any required reporting step, and documents the decision. Time it. Identify bottlenecks.
6. Audit trail verification. Pull up your screening logs. Verify that every test screen produced a complete audit record (timestamp, data screened, lists, versions, trigger, result). Have your compliance officer review the logs and confirm they contain the evidence your policy requires.

Week 4: Go-live, training, and verification

1. Deploy to production. Switch the screening gate from test mode to live. Ensure that blocked transfers produce clear error messages for operations staff (not just a raw API error).
2. Train your team. Every person who touches transactions needs to understand: what triggers a screening alert, what they do when they see one, who they escalate to, and where they document their actions. Keep training records so you can demonstrate coverage.
3. Verify audit trail in production. After 24-48 hours of live operation, pull the production audit logs. Verify completeness. Every in-scope transfer should have a corresponding screening record. Every screening record should have a timestamp, the lists checked, the trigger, and a result.
4. Set up re-screening automation. Configure your tool to re-screen when applicable restrictive measures are added, updated, or lifted. If your tool does not support event-driven re-screening, set a documented batch frequency based on your exposure assessment.
5. Document everything. Update your sanctions screening policy to reflect the new system. Record the go-live date, the tool selected, the API version, the lists covered. This is your "before and after" evidence for regulators.

How do you build a defensible audit trail?

The audit trail is not an afterthought -- it's the primary evidence that your screening process works. When CySEC (or any EU NCA) inspects your sanctions compliance, historical records are likely to be reviewed. If the records are incomplete, it is hard to evidence that the control operated as designed.

What each screening record should contain

• Timestamp -- when the screening was performed (UTC, ISO 8601 format)
• Data screened -- the exact wallet address, name, entity name, identifier, or transfer field
• Chain -- which blockchain (Ethereum, Bitcoin, Tron, etc.)
• Lists checked -- which sanctions lists were queried
• List version -- the publication date or version hash of each list at the time of screening
• Result -- match or no-match
• Screening trigger -- what initiated the screen (onboarding, pre-transfer, re-screening, manual)
• Reference ID -- link to the associated transaction or customer record

What each match investigation should contain

• Match details -- which list, which designation, what category
• Investigation notes -- what the analyst checked, what evidence was reviewed
• Decision -- true positive or false positive, with reasoning
• Decision maker -- who approved the determination (name, role, date)
• Escalation -- if true positive: when was the FIU notified, STR reference number
• Action taken -- transaction blocked, account frozen, funds returned, etc.

Database schema example

Here's a minimal audit-ready schema for your screening audit trail:

CREATE TABLE screening_log (
  id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  screened_at     TIMESTAMPTZ NOT NULL DEFAULT now(),
  address         TEXT NOT NULL,
  chain           TEXT NOT NULL,
  trigger_type    TEXT NOT NULL,  -- 'onboarding' | 'pre_transfer' | 'rescreen' | 'manual'
  reference_id    TEXT,            -- transaction or customer ID
  lists_checked   JSONB NOT NULL, -- [{"name":"ofac_sdn","version":"2026-03-12"}, ...]
  result          TEXT NOT NULL,  -- 'clear' | 'match'
  matches         JSONB,           -- match details if any
  api_response_id TEXT,            -- provider's response ID for traceability
  screened_by     TEXT NOT NULL   -- 'system' | operator email for manual screens
);

CREATE TABLE match_investigation (
  id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  screening_id    UUID REFERENCES screening_log(id),
  opened_at       TIMESTAMPTZ NOT NULL DEFAULT now(),
  closed_at       TIMESTAMPTZ,
  investigator    TEXT NOT NULL,  -- analyst name/email
  notes           TEXT NOT NULL,  -- investigation narrative
  determination   TEXT NOT NULL,  -- 'true_positive' | 'false_positive'
  approved_by     TEXT NOT NULL,  -- MLRO or senior compliance officer
  approved_at     TIMESTAMPTZ,
  action_taken    TEXT NOT NULL,  -- 'blocked' | 'frozen' | 'released' | 'reported'
  str_reference   TEXT             -- STR filing reference if reported to FIU
);

-- Index for re-screening: quickly find all addresses to re-check
CREATE INDEX idx_screening_address ON screening_log(address);
CREATE INDEX idx_screening_result ON screening_log(result);
CREATE INDEX idx_screening_date ON screening_log(screened_at);

What are the five common mistakes that fail audits?

These are the patterns we see repeatedly in small CASPs preparing for their first regulatory inspection. Each one can become an audit finding if the policy, control, or evidence is missing.

How do you maintain compliance after go-live?

Implementation is not a one-time project. Sanctions screening is an ongoing operational process. After your 30-day implementation:

• Monitor list update ingestion. Verify that your tool is actually pulling updates for every list in your policy. Set alerts for failed ingestion, stale datasets, or provider errors.
• Review audit logs on a documented schedule. Pull a sample of screening records and verify completeness. Monthly review is a practical starting point for many small CASPs, but set the frequency based on exposure.
• Review the screening system at least annually. EBA GL/2024/15 expects at least annual review and immediate review if there are grounds for concern. Test settings and scenarios at a frequency based on your exposure assessment.
• Update your policy. When sanctions lists are added, regulatory guidance changes, or your screening tool is upgraded, update the policy document. Version-control it.
• Retain records under your AML/CFT and sanctions policy. EU AMLD record retention is generally five years for CDD and transaction records after the business relationship or occasional transaction ends. Treat screening logs as part of your evidence set and check local retention rules before deleting them.

EBA GL/2024/15 expects PSPs and CASPs to identify new, updated, or lifted restrictive measures and update their internal screening dataset immediately after the change enters into force.

-- EBA Guidelines on Internal Policies, Procedures and Controls (GL/2024/15), Section 4.1.2

Frequently asked questions

What sanctions lists does an EU-licensed CASP need to screen against?

Screen against applicable Union and national restrictive measures. For an EU CASP, that means EU restrictive measures and any applicable national measures. UN, OFAC SDN, and the UK Sanctions List may also be in scope because of local law, business exposure, customer geography, or internal risk policy. There is no universal MiCA mandate that every EU CASP must screen EU, UN, OFAC, and UK lists in every case.

Can I use Excel spreadsheets for sanctions screening?

Technically yes, but it creates significant compliance risk. Excel-based screening often lacks reliable timestamps, automatic re-screening triggers, access controls, and list-version evidence. EBA GL/2024/15 expects effective screening, documented policies, alert investigation records, and regular system review. A spreadsheet process needs substantial supplementary controls to evidence that standard.

How often must I re-screen existing customers against sanctions lists?

EBA GL/2024/15 expects regular customer database screening with frequency set by your restrictive-measures exposure assessment. It also expects trigger-event screening when a designation or restrictive measure changes, at onboarding, after significant CDD changes, or when circumvention is suspected. Event-driven re-screening is the cleanest implementation pattern; a batch-only approach should have a documented frequency and rationale.

What does a sanctions screening audit trail need to contain?

A defensible record should include: timestamp (UTC), the address, name, entity, or transfer data screened, which lists or datasets were checked, the list version or publication date, the screening result, and the trigger (onboarding, pre-transfer, re-screen, manual). For matches, keep investigation notes, the decision, who approved it, the action taken, and any required reporting reference.

How long does it take to implement automated sanctions screening?

A realistic timeline for a small CASP is 30 days. Week 1: document your sanctions screening policy and procedures. Week 2: select a tool and integrate the API. Week 3: test with known sanctioned addresses, edge cases, and batch screening. Week 4: go live, train staff, and verify audit trail completeness. The API integration itself can be done in a day -- the policy work and testing take the remaining time.

Bottom line

Migrating from Excel to automated sanctions screening is not primarily a technical project -- it's an operational one. The API integration is the easy part. The hard part is the policy documentation, the match handling procedures, the testing discipline, and the audit trail architecture. But all of it is achievable in 30 days for a small CASP with focused effort.

The regulatory direction is clear: the TFR gives the EBA a restrictive-measures mandate for CASP transfers, and EBA GL/2024/15 expects controls to be operational, not just written into a policy. CASPs still running manual spreadsheet checks need strong supplementary controls to evidence list coverage, trigger-event screening, alert handling, and audit trails. The 30-day plan in this guide gets you to an automated, documented process that is much easier to defend under inspection.

Start with the policy. The code follows.