When Screening Alerts Don't Stop Payments

The UK's Office of Financial Sanctions Implementation fined Citibank's London branch £4.7 million for processing 970 payments worth £19.72 million that breached financial sanctions. The penalty revealed a pattern many institutions will recognize: screening systems generated alerts, but those alerts didn't translate into effective payment blocks. A name variation between "PAO Sovcomflot" and "Sovcomflot" allowed 328 transactions worth £5.4 million to pass through. Another 242 payments totaling £5.9 million cleared because 24 accounts weren't restricted promptly after screening identified a designated Russian individual.

This isn't about screening technology failing to detect matches. It's about the gap between detection and action, where alerts sit in backlogs, manual processes create delays, and payment systems operate independently from screening decisions.

Assess Your Current Framework

Before you rebuild your sanctions control framework, inventory what you're working with:

Your current screening configuration:

• Which name-matching algorithm does your system use (exact match, fuzzy logic, phonetic)?
• Does it screen variations automatically (abbreviations, legal entity suffixes, transliterations)?
• What identifier types does it check beyond names (BICs, LEIs, registration numbers)?

Your alert workflow:

• How long does an alert sit before initial review?
• Who has authority to escalate, clear, or restrict?
• What triggers an immediate account freeze versus a pending investigation?

Your payment processing architecture:

• Can payments process while an alert is under review?
• If correspondent banks change after initial screening, does the payment re-screen?
• Do internal charges (fees, interest) bypass screening on restricted accounts?

Your KYC-to-screening data flow:

• Where does your screening system pull customer names from?
• When KYC updates a legal entity name, how long until screening reflects the change?
• Do you maintain a mapping between customer record names and all known variations?

You'll also need access to your sanctions list management system and the authority to modify alert escalation procedures and payment hold rules.

Step-by-Step Implementation

Configure Multi-Variant Name Screening

Start with the Sovcomflot problem: your customer record says "PAO Sovcomflot," but the OFSI list says "Sovcomflot." Your screening system must check both.

Build a name normalization layer that generates searchable variants for every customer and every designated person:

• Strip legal entity suffixes (PAO, JSC, PJSC, Ltd, Inc)
• Create transliteration variants for non-Latin scripts
• Generate common abbreviations
• Store all variants in your screening index

Test this by running your current customer base against historical sanctions lists using only core entity names, no suffixes. Any customer that matches a designated person when you remove "PAO" or "OJSC" represents a gap your current system would miss.

Link Identifiers to Entity Records

Names alone aren't sufficient. The OFSI case showed that Bank Identification Codes weren't adequately incorporated into screening data, allowing designated correspondent banks to slip through.

For every customer and every designated person in your screening system:

• Add all known BICs, SWIFTs, LEIs, tax IDs, and registration numbers
• Screen payment messages for these identifiers, not just names
• When a new identifier appears in payment data, trigger a screening check even if the name already cleared

Configure your system to flag any payment where a BIC in the correspondent bank field matches a designated entity's known identifiers.

Implement Immediate Restrictive Actions

The 242 payments that cleared after screening identified a designated individual show what happens when alerts don't trigger immediate holds.

Redesign your alert workflow:

• Tier 1 (Freezing Without Delay): Direct name match or identifier match on a Targeted Financial Sanctions list. Payment holds automatically. Account restricted from all debits. Alert routes to your sanctions team lead within one hour.
• Tier 2 (Manual Review Required): Fuzzy match or ownership/control relationship flagged. Payment holds pending investigation. Review required within four hours during business hours.
• Tier 3 (Enhanced Due Diligence): Weak match or indirect relationship. Payment may proceed, but alert must be documented and cleared within 24 hours.

Build this logic into your payment processing system, not just your screening tool. A screening alert that doesn't interface with payment controls is just documentation.

Screen Payment Chains Dynamically

OFSI found that correspondent banks could be added after initial screening without re-screening the complete payment chain. That's a structural gap.

Configure your payment system to:

• Re-screen the entire payment message whenever any field changes (originator, beneficiary, intermediary banks)
• Block submission of a payment instruction if any party in the chain hasn't cleared screening
• Log every screening decision with a timestamp and the complete payment data at the time of screening

If your core banking system allows post-screening modifications, you need middleware that intercepts changes and forces re-validation.

Close the KYC-to-Screening Loop

Name variations often originate in KYC. Your customer onboarding team records "PAO Sovcomflot" because that's what the incorporation documents say. Your screening team searches for "Sovcomflot" because that's what OFSI published.

Establish a process where:

• Every KYC record includes a "screening name" field, the normalized version your system will search
• When KYC updates a customer's legal name, the screening team reviews and updates all associated variants
• Quarterly, run a reconciliation report showing any customer whose KYC legal name differs from their screening name by more than a suffix or abbreviation

This won't eliminate all mismatches, but it surfaces the gaps before a designated person shows up on a list.

Validation: How to Verify It Works

Run these tests monthly:

Historical Replay Test: Take the last 90 days of payments. Re-screen them against today's sanctions lists using your new multi-variant logic. Any payment that would now be blocked but wasn't at the time indicates a gap your old system missed. Investigate whether the gap was a name variation, an identifier, or a payment chain change.

Alert-to-Action Timing: Measure the hours between alert generation and account restriction for every Tier 1 alert. Your target: 100% of Tier 1 alerts result in account restrictions within one hour. If you're not hitting that, your workflow has a bottleneck.

Payment Chain Modification Test: Submit a test payment through your staging environment. After initial screening, modify the correspondent bank field to a known designated entity's BIC. The system should reject the payment. If it doesn't, your re-screening logic isn't working.

Maintenance and Ongoing Tasks

Weekly:

• Review all Tier 1 alerts that resulted in account restrictions. Confirm that payments were blocked before any transactions cleared.
• Audit any payments where a correspondent bank was added or modified post-screening. Verify re-screening occurred.

Monthly:

• Run the historical replay test described above.
• Review KYC name updates and confirm screening names were updated in parallel.

Quarterly:

• Test your name normalization logic against new designations. OFSI, OFAC, and the EU publish entities with varied naming conventions. Run each new designation through your variant generator and confirm it would match your customer records if that entity were in your portfolio.
• Audit a sample of cleared alerts. For any alert marked "no match," manually review whether a name variation or identifier could have created a false negative.

Annually:

• Engage an independent reviewer to test your screening system's coverage of name variations, identifiers, and payment chain modifications.

The Citibank case cost £4.7 million because alerts didn't become actions. Your screening system can be technically accurate and still fail if the path from detection to restriction has manual steps, backlogs, or system gaps. Build the controls so that when screening finds a match, payments stop immediately.