Sanctions Screening and IBAN Validation: A Compliance Guide

Sanctions screening and IBAN validation are complementary compliance controls that must both be present in any payment workflow operating under EU, UK, or US regulatory jurisdiction. Sanctions screening identifies whether a counterparty is on a restricted list; IBAN validation confirms the account identifier is structurally sound and belongs to a real bank. You cannot effectively screen against sanctions lists using an invalid IBAN — and a valid IBAN from a sanctioned jurisdiction still requires a screening decision before the payment clears. This guide explains how the two controls fit together, which sanctions regimes apply to IBAN-based payments, and how to build a compliant workflow.

Why IBAN Validation Comes Before Sanctions Screening

Sanctions screening tools operate on structured data. They match counterparty names, entity identifiers, BICs, and country codes against structured lists published by OFAC, the EU, the UN, and other authorities. An IBAN that fails the MOD-97 check or contains an invalid country code cannot be resolved to a real bank or jurisdiction — the screening system has nothing to match against.

The correct order of operations:

1. Validate the IBAN structurally (format, length, MOD-97). Reject if invalid. Log the rejection reason.
2. Extract the country code and BIC from the validated IBAN. Use these as inputs to the sanctions screening step.
3. Screen the country against the restricted jurisdictions list for your operating regime (OFAC, EU, UK, UN).
4. Screen the beneficiary bank BIC against the SDN list and equivalent lists.
5. Screen the beneficiary name (if available) against entity lists.
6. Disposition: pass, block, or escalate for manual review.

The ibanchecker.cash API handles steps 1 and 2 — returning the country code, BIC, and bank name for any valid IBAN. Your sanctions screening system handles steps 3–6.

OFAC: US Sanctions and IBAN Country Prefixes

The Office of Foreign Assets Control (OFAC) administers US economic sanctions. Any payment that involves a US financial institution, US persons, or USD-denominated transactions is subject to OFAC jurisdiction — even if both payment parties are non-US entities.

Key OFAC programs relevant to IBAN-based payments:

• Iran (IFSR): Comprehensive sanctions. Iranian financial institutions are broadly sanctioned. IBAN country code IR is a high-risk signal, though Iran is not a SWIFT-connected IBAN country in practice.
• Russia (Ukraine-/Russia-related): Sectoral and entity-level sanctions on major Russian banks. Russian IBAN country code is RU — though most Russian SWIFT connectivity was severed in 2022. SWIFT messages to RU entities should be treated as presumptively blocked pending OFAC review.
• Cuba, North Korea, Syria, Venezuela: Country-level or near-comprehensive programs. Any IBAN from these jurisdictions requires OFAC analysis before processing.
• Specially Designated Nationals (SDN) list: Individual and entity-level designations that apply regardless of country. A BIC or bank name returned from IBAN validation must be checked against the SDN list.

OFAC has consistently held that knowledge of a payment's sanctions nexus is not required for liability — the strict liability standard means that even unknowing violations can result in civil penalties. Automated screening integrated with IBAN validation is the appropriate control.

EU Sanctions: Council Regulations and the IBAN Country Prefix

EU sanctions are enacted by the Council of the EU and published in the Official Journal. They apply to all EU-incorporated entities and EU-domiciled persons, regardless of transaction currency. Key regimes:

• Russia: Regulation 833/2014 and subsequent amendments (Packages 1–14 and beyond) impose comprehensive financial sanctions on major Russian banks, including prohibitions on correspondent banking and processing payments for listed entities. Bank BICs returned from IBAN validation for Russian-linked accounts must be checked against the Annex to Regulation 833/2014.
• Belarus: Country code BY. Sanctions packages parallel to Russia include major Belarusian state banks. IBAN validation for BY IBANs should trigger automatic escalation.
• Iran, Syria, North Korea, Myanmar, Venezuela: Comprehensive or near-comprehensive EU restrictive measures. Country code screening is the primary automated signal.
• Individual and entity designations: The EU Consolidated List of sanctioned individuals and entities must be checked against beneficiary names and bank names returned by IBAN validation.

UK Sanctions: OFSI and Post-Brexit Regime

Since Brexit, the UK operates its own sanctions regime under the Sanctions and Anti-Money Laundering Act 2018, administered by the Office of Financial Sanctions Implementation (OFSI). The UK generally mirrors EU and US sanctions programs but maintains its own Consolidated List.

UK-incorporated entities and UK-domiciled persons must screen against the OFSI Consolidated List in addition to any applicable OFAC or EU lists. The same IBAN-first workflow applies: validate the IBAN, extract country and BIC, screen against OFSI list, screen beneficiary name.

High-Risk Country Codes: IBAN Prefix as a Screening Signal

IBAN validation extracts the two-letter country code as part of the structural parse. This country code is a first-pass screening signal. The following country codes carry elevated risk under one or more major sanctions regimes and should trigger automatic escalation to a compliance review queue:

• RU — Russia (EU, UK, US)
• BY — Belarus (EU, UK, US)
• IR — Iran (EU, UK, US)
• SY — Syria (EU, UK, US)
• KP — North Korea (EU, UK, US, UN)
• CU — Cuba (US)
• VE — Venezuela (US)
• MM — Myanmar (EU, UK)
• LY — Libya (UN arms embargo, partial)
• SD — Sudan (US Darfur program)

This list is illustrative, not exhaustive. Sanctions regimes change frequently — automated country-code screening should reference a dynamically updated list from a sanctions data provider (WorldCheck, Dow Jones, Refinitiv, ComplyAdvantage) rather than a hardcoded list. The IBAN country code provides the trigger; the sanctions data provider provides the current risk determination.

BIC-Level Screening

The bank identifier embedded in the IBAN corresponds to a BIC (Bank Identifier Code). The BIC identifies the specific financial institution at the beneficiary end of the payment. Sanctioned financial institutions are listed in sanctions schedules by BIC or by legal entity name.

When IBAN validation returns a BIC, that BIC should be:

• Checked against the SDN Annex (OFAC) for financial institution designations
• Checked against Regulation 833/2014 Annex IV (EU) for Russian bank listings
• Checked against the OFSI Consolidated List (UK)
• Checked against your sanctions data provider's structured list for all applicable regimes

The ibanchecker.cash API returns the BIC alongside the IBAN validation result. Pass this BIC directly to your sanctions screening system as the financial institution identifier.

AML Workflow Integration

A compliant AML payment workflow that integrates IBAN validation and sanctions screening:

1. Payment instruction received: IBAN and beneficiary name extracted from payment instruction.
2. IBAN validation: POST to /api/v1/validate. Extract country code, BIC, bank name. If invalid: reject with structured error code, log, alert.
3. Country screening: Country code checked against restricted jurisdictions list. If hit: block payment, generate Suspicious Activity Report (SAR) draft, alert compliance officer.
4. BIC screening: BIC checked against SDN and equivalent lists. If hit: block payment, generate SAR draft.
5. Beneficiary name screening: Name checked against entity lists using fuzzy matching. If hit or near-hit: escalate to manual review.
6. Transaction monitoring: Amount, frequency, and counterparty combination checked against AML typologies. Flags routed to the transaction monitoring queue.
7. Payment released or blocked: Pass proceeds; block or escalate escalates to compliance review with full audit trail.

Record-Keeping and Audit Requirements

Under FATF Recommendation 11 and EU AMLD implementing regulations, PSPs must retain records of:

• All payment instructions, including the IBAN and beneficiary name as submitted
• The result of each IBAN validation, including the timestamp and the validation service version
• The result of each sanctions screening check, including which lists were checked and the version of those lists
• Any escalations, blocks, or SAR filings triggered by the screening workflow

Records must be retained for at least five years (EU AMLD) or ten years in some jurisdictions. Validation and screening results should be stored with transaction records, not purged after payment completion.

Last updated: June 2026