Spreadsheet triage backlogged sanctions screening; fuzzy matching and Actimize case management made outcomes consistent

Overview

AML name screening produced backlogs and uneven outcomes. Alerts from one screening list were copied into spreadsheets, fuzzy matches were reviewed inconsistently, and dispositions varied by analyst. Legal and AML Operations re?worked the same names when new information surfaced, and escalations to sanctions counsel were ad hoc. Intelligex orchestrated multiple sanctions, Politically Exposed Person (PEP), and adverse media lists with tuned fuzzy matching, applied decisioning guardrails, and introduced case management with legal quality assurance. Alerts were routed with context, evidence was captured once, and escalations progressed predictably—while the bank’s screening tools, core banking, and case systems stayed in place. Controls aligned to well?known sources such as the U.S. Treasury’s OFAC SDN List, the UN Security Council Sanctions List, and industry guidance like the Wolfsberg Sanctions Screening Guidance.

Client Profile

• Industry: Regional retail and commercial banking
• Company size (range): Multi?branch footprint with centralized Financial Crime Compliance and distributed operations
• Stage: Legacy screening tool connected to core systems; alerts exported to spreadsheets; manual adjudication; limited audit trail; uneven use of PEP/adverse media
• Department owner: Legal & Compliance (Financial Crime Compliance and Sanctions)
• Other stakeholders: AML Operations, Sanctions Counsel, KYC/Onboarding, Fraud, IT/Integrations, Risk, Retail/Commercial Lines, Internal Audit

The Challenge

Backlogs built quickly. The screening engine generated alerts across onboarding, batch refresh, and payments, but triage depended on who was on shift. Analysts copied results into trackers, compared spellings by eye, and made judgment calls on transliterations, initials, and partial dates of birth. Escalations to sanctions counsel were sent via email without standardized context, so reviews restarted from scratch. The same name could be cleared by one analyst and escalated by another a day later.

List coverage and tuning were uneven. OFAC, UN, and regional lists updated on different cadences, and PEP/adverse media sources were consulted inconsistently. Fuzzy matching thresholds were set conservatively, which over?alerted common names, and there were no consistent rules for when a weak match paired with a strong secondary attribute—like a national ID—should be auto?cleared or escalated. Documentation lived in comments and spreadsheets, so repeat reviews lacked lineage.

Evidence and governance were fragmented. Case notes, screenshots, and external checks were stored in personal folders. Quality assurance sampled cases manually and found inconsistent application of the same standards. When auditors asked for a trace from alert to disposition, teams reconstructed the sequence from inboxes and dashboards rather than exporting a single record.

Why It Was Happening

Screening wasn’t connected to a governed workflow. The bank had a capable screening engine, but outputs weren’t normalized or routed through a consistent case process. Analysts moved between tools to collect attributes and made decisions without standardized reason codes. List updates did not automatically trigger re?screening with tuned thresholds, so noise persisted.

Decision rules lived in policy, not in the path of work. Guidance on transliteration, alias handling, and secondary identifiers existed, but the engine lacked guardrails to auto?route clear scenarios or to require second?level review for risky combinations. Legal review happened late, and dispositions were not versioned against the underlying lists and thresholds.

The Solution

Intelligex deployed an orchestration layer that unified multiple lists, tuned fuzzy matching, and embedded decisioning and case management with legal QA. Screening events flowed into a single queue with normalized data, risk signals, and secondary identifiers. Guardrails auto?cleared low?risk combinations, auto?escalated high?risk ones, and required human review for in?between cases. Analysts worked from a standard disposition form with reason codes, and sanctions counsel saw escalations with full context. List updates and threshold changes ran under change control, and re?screening applied automatically where applicable. Official sanctions sources such as OFAC and the UN Security Council informed coverage, and screening practices reflected guidance like the Wolfsberg Sanctions Screening Guidance.

• Integrations: Existing screening engine and third?party lists (sanctions, PEP, adverse media); case management (for example, NICE Actimize, ServiceNow, or Salesforce) for queues and evidence; core banking and onboarding (CIF/KYC) for customer attributes; payments platform for real?time screenings; identity/SSO for roles and access.
• Fuzzy matching and normalization: Tokenization and transliteration handling; adjustable thresholds by list and channel; secondary identifier weighting (date of birth, national ID, passport, address); alias and AKA consolidation; language scripts support where relevant.
• Decisioning guardrails: Auto?clear rules for weak matches with strong disconfirming attributes; auto?escalate rules for strong matches or elevated risk factors (PEP status, high?risk geographies); maker?checker for potential hits; reason codes for every disposition.
• Case management and evidence: Standardized forms; link to source hit details; captured research steps and external checks; attachment of supporting documents; audit?ready timelines with immutable logs.
• Legal QA and oversight: Sampling plans; counsel approval required for confirmed hits and list suppression; change control for thresholds and list sources; weekly review of exception trends.
• Dashboards and reporting: Queue health and aging; disposition outcomes by list and channel; false?positive patterns; escalations and approval turnaround; exportable packets for audits and regulator inquiries.
• Security and privacy: Least?privilege access; masking for sensitive identifiers in broader views; immutable logs for alert handling; retention aligned to records and regulatory expectations.

Implementation

• Discovery: Mapped screening touchpoints across onboarding, batch refresh, and payments; inventoried current lists and update cadences; sampled alerts to identify false?positive drivers; reviewed case notes, QA findings, and escalation practices; gathered Legal, AML Ops, Sanctions, IT, and Audit requirements for evidence and reporting.
• Design: Authored normalization rules and fuzzy matching thresholds by list/source and channel; defined decisioning guardrails and maker?checker criteria; standardized reason codes and case forms; planned list update handling and re?screening; outlined dashboards and exportable evidence; set change control and QA sampling plans.
• Build: Connected screening feeds to the orchestration layer; implemented tokenization and matching logic; configured auto?clear/auto?escalate rules; integrated case management with queues, forms, and audit logs; enabled SSO and role?based access; instrumented dashboards and list update monitors.
• Testing/QA: Ran in shadow mode against live alerts; compared auto?decisions to analyst outcomes; tuned thresholds and guardrails; piloted with onboarding and batch refresh before enabling payments; validated evidence capture and exports with Legal and Audit.
• Rollout: Turned on case routing with advisory decisions; enabled auto?clears for lowest?risk scenarios first; added maker?checker for escalations; expanded to real?time payments after stability; retired spreadsheets and email escalations after consistent cycles.
• Training/hand?off: Trained analysts on new queues, reason codes, and evidence standards; briefed sanctions counsel on approval workflows and list suppression; updated SOPs and runbooks; transferred ownership of thresholds, list sources, and dashboards to Financial Crime Compliance under change control.
• Human?in?the?loop review: Established weekly calibrations to review borderline cases, false positives, and new list behaviors; recorded decisions with rationale and effective dates; updated thresholds, guardrails, and training accordingly.

Results

Alerts moved through a consistent path with clear outcomes. Weak matches with disconfirming identifiers cleared automatically, risky combinations escalated predictably, and analysts focused on cases where judgment mattered. Case records contained research steps, supporting documents, and approvals, so rework fell when names resurfaced.

Oversight strengthened. Legal and QA saw the same evidence analysts used, thresholds and list sources were versioned under change control, and dashboards highlighted patterns worth tuning. Auditors received complete packets from case management rather than collations from inboxes. The bank’s screening engine and case systems remained; the change added orchestration, guardrails, and governance between them.

What Changed for the Team

• Before: Alerts were triaged in spreadsheets. After: A single case queue captured research, reason codes, and approvals.
• Before: Matching thresholds were static and over?inclusive. After: Fuzzy matching tuned by list and channel reduced noise while preserving risk sensitivity.
• Before: Escalations lacked context. After: Legal received standardized packages with secondary identifiers and research steps.
• Before: Dispositions varied by analyst. After: Guardrails and maker?checker produced consistent outcomes and audit trails.
• Before: List updates caused surprises. After: Updates ran under change control with re?screening and communication to the queue.
• Before: QA found the same issues repeatedly. After: Calibrations fed threshold and rule updates with recorded rationale.

Key Takeaways

• Unify screening outputs; normalize lists and attributes before routing alerts.
• Tune matching thoughtfully; pair fuzzy thresholds with secondary identifiers and guardrails.
• Standardize decisions; use reason codes, maker?checker, and case forms to drive consistency.
• Embed Legal early; escalate with context and capture approvals in the case record.
• Govern changes; version list sources and thresholds and align re?screening accordingly.
• Integrate, don’t replace; keep the engine and case tools—add orchestration, rules, and QA between them.

FAQ

What tools did this integrate with? The orchestration layer consumed alerts from the existing screening engine and third?party sources (sanctions, PEP, adverse media) and routed cases into the bank’s case management system (for example, NICE Actimize, ServiceNow, or Salesforce). It enriched alerts with attributes from core banking and KYC systems, enforced SSO for access, and referenced official lists such as OFAC SDN and the UN Security Council list.

How did you handle quality control and governance? Matching thresholds, guardrails, and list sources lived under Financial Crime Compliance change control with owners and effective dates. Legal approved confirmed hits and list suppression, and QA sampled dispositions on a cadence. Every alert, decision, and approval wrote to immutable logs, and dashboards surfaced exception patterns for review.

How did you roll this out without disruption? The system ran in shadow mode first, comparing advisory decisions to analyst outcomes. It then enabled auto?clears for low?risk scenarios and maker?checker for escalations, expanded by channel, and retired spreadsheets only after consistent cycles. Documentation and training updated SOPs and playbooks in step with the rollout.

How were fuzzy matching thresholds and false positives managed? Thresholds were set per list and channel and combined with secondary identifier weighting. Weekly calibrations reviewed borderline cases and false?positive drivers, and approved adjustments were versioned with rationale. Auto?clears required both low similarity and disconfirming attributes; anything else went to a human review or escalation.

How did you address privacy and retention? Access followed least?privilege roles, and sensitive identifiers were masked in broader views. Case records retained only necessary data for regulatory and audit purposes under the bank’s records schedule, with legal holds applied when required. All access and exports were logged.