Real-time sanctions screening is the automated process of checking customers, counterparties, and transactions against government watchlists at the point of onboarding, payment initiation, or entity search. The check runs in the moment and returns a risk decision before the next step in the workflow proceeds.
The problem with slower approaches is not just speed. OFAC publishes sanctions list updates multiple times per week with no fixed schedule, and the EU’s 20th Russia package added 120 individuals and entities in a single April 2026 release. Any periodic cycle leaves a coverage window between runs.
OFAC’s strict liability standard means intent is not a defense, and penalties reach $377,700 per violation. For example, Interactive Brokers settled for $11.8 million in July 2025 after accumulating 12,367 apparent violations in a program that had sanctions screening in place throughout.
This guide explains what real-time sanctions screening requires, where programs develop exposure they cannot see, and what separates a program that holds up under examination from one that only looks compliant on paper.
Key takeaways:
- Screening the name is not enough
Sanctions obligations extend to beneficial owners, payment counterparties, vessels, and crypto wallets, not just the customer’s legal name.
- Configuration failures cause most violations
OFAC has stated directly that programs relying solely on name screening without ownership investigation will be found deficient, and its 2025 enforcement record bears that out.
- Every step in the workflow must hold
Poor normalization, misconfigured thresholds, and weak alert routing each create exposure independently, and any one failure is enough to produce a violation.
- The audit trail is half the compliance program
A correct screening result with no decision record is treated as undocumented by regulators and banking partners alike.
- Sigma360 addresses the weaknesses most programs leave unresolved
Sigma360 includes real-time list coverage, entity resolution, AI-assisted alert triage, and audit-ready decision trails in a single platform.
Real-time vs. batch sanctions screening
The difference between real-time and batch screening is when the check runs relative to the event that creates the risk.
The table below shows how each approach works and where each fits in a compliance program.
| Dimension | Real-time screening | Batch screening |
| Trigger | Event-driven (onboarding, payment, list update) | Scheduled cycle (nightly, weekly, monthly) |
| Primary use cases | Customer onboarding, payment initiation, continuous monitoring alerts | Portfolio remediation, periodic rescreening, acquisition due diligence |
| Latency | Sub-second to a few seconds | Hours to days |
| List currency | Most recent list version at time of query | Current list version at time of run |
| Alert handling | Individual alerts reviewed case by case | Bulk alert queues reviewed in priority order |
| Regulatory fit | Required for onboarding and payment-level compliance | Required as a supplementary control, not a primary one |
Both approaches belong in a mature compliance program, but batch alone is not sufficient at the points where real-time coverage is required.
What real-time sanctions screening must cover
Most sanctions compliance failures trace back to a program that was never configured to check the right things in the first place.
Screening only against a customer’s legal name misses the structures sanctioned parties routinely use to stay off the radar. A well-built program covers:
- Individuals: Customers, directors, beneficial owners, agents and authorized signatories
- Legal entities: Companies, trusts, charities, holding structures, and counterparties
- Payment parties: Originating and beneficiary banks, SWIFT/BIC codes, IBANs, and intermediary financial institutions
- Assets and identifiers: Vessels, aircraft, registration numbers, passports, crypto wallets, and known aliases
The OFAC 50 percent rule extends this further: Any entity owned 50% or more in aggregate by a sanctioned party is itself blocked, even without appearing on the SDN list by name.
Ownership structure, not list membership, determines sanctions status. OFAC made this explicit in its 2025 enforcement record, which documented $265 million in penalties across 14 enforcement actions, with OFAC stating directly that programs relying solely on name screening without ownership investigation will be found deficient.
Read more: The nuances of effective sanctions screening
Which sanctions lists require coverage
Which lists a compliance program must cover depends on where the institution operates, which currencies and payment rails it uses, and which regulators or banking partners have jurisdiction over its activity.
The core lists most regulated institutions have to cover include:
- OFAC Specially Designated Nationals (SDN) List: The primary US sanctions list, covering individuals and entities subject to asset freezes and transaction prohibitions
- OFAC non-SDN consolidated lists: Including the Sectoral Sanctions Identifications List (SSI) and the Non-SDN Chinese Military-Industrial Complex Companies List (NS-CMIC), which carry restrictions on specific debt, equity, and securities transactions
- UN Security Council consolidated sanctions list: The Baseline international standard, binding on all UN member states under Article 25 of the UN Charter
- EU consolidated financial sanctions list: Encompassing over 40 restrictive measures programs, updated whenever new designations are adopted
- UK sanctions list: The authoritative source for UK designations, maintained by the FCDO since the OFSI Consolidated List closed in January 2026
- Jurisdiction-specific lists: Including SECO (Switzerland), FINTRAC (Canada), AUSTRAC (Australia), and MAS (Singapore) for institutions with regional footprints
Each regime publishes on its own schedule. A new EU designation is not automatically mirrored by OFAC or the UK on the same day, and an institution screening against a single authority’s list carries uncovered exposure in every jurisdiction where a different regime applies.
How real-time sanctions screening works
Real-time screening is a sequence of steps that must function reliably, because a failure at any point either produces a missed match or generates an alert the compliance team cannot act on.
1. Collect and structure input data
Capture all identifying information relevant to the entity or transaction. This includes full legal name, date of birth, nationality, registered address, company registration number, ownership structure, and payment fields.
Incomplete input at this stage is one of the most direct causes of missed matches. When customer onboarding collects a legal name but skips date of birth, nationality, or ownership structure, the screening engine has less to compare against a list entry that may only be identifiable through those additional fields.
2. Normalize and prepare the data
Standardize casing, punctuation, transliteration, name order, date formats, and entity types before matching begins. A name recorded in Cyrillic, Arabic, or Chinese script must be transliterated consistently across all source systems that feed the screening engine.
Inconsistent normalization produces two problems at once: false positives from mismatched formats and false negatives from names that never get compared against the right list entry.
3. Match against sanctions data
Compare the normalized input against live list data using exact matching, approximate name matching, phonetic similarity, alias handling, date-of-birth filtering, and identifier matching. FATF Recommendation 6 and Recommendation 7 require countries to implement targeted financial sanctions without delay, and the matching step is where that obligation either holds or fails.
A matching engine configured with thresholds set too tight will miss near-matches that fall just below the cutoff. If it’s set too loose, it floods the analyst queue with low-confidence hits that obscure genuine risk. In either case, the failure only becomes visible when the program is examined.
4. Apply risk context to alerts
Use risk context, including date of birth, country of residence, ownership links, transaction corridor, and entity type, to distinguish likely true matches from low-quality false positives. An alert on a common name like Mohammed Al-Rashid carries very different risk weight for a retail client in the UK than for an entity initiating a wire transfer through a high-risk corridor.
When this step is disregarded, every alert enters the queue at equal priority, and analysts spend the same amount of time on records that pose no risk as on genuine matches.
5. Route and prioritize alerts
Direct higher-confidence matches to immediate human review, and suppress or de-prioritize repeat false positives where policy and a documented audit trail support it.
Without structured routing logic, in a high-volume program, a true match on a newly designated party can remain unreviewed for hours or days while analysts work through a backlog of suppressed false positives. This is long enough for a prohibited transaction to settle before anyone reaches the alert.
6. Document and preserve the decision
Record what was queried, which list version was checked, what matched, who reviewed the alert, and what the final outcome was.
A complete decision trail is what converts a screening result into demonstrable compliance. OFAC has made clear in enforcement proceedings that records reconstructed after the fact carry significantly less weight than those preserved at the time of the decision.
The regulatory stakes in 2026
The volume of designation activity in 2025 illustrates the pace compliance programs must match. OFAC added 1,764 persons to the SDN List across 14 enforcement actions, down from a peak of 3,135 in 2024. The activity was concentrated in high-priority programs covering Iran, China, and Russia that generate multiple list updates per week with no advance notice of timing.
This pace creates a problem OFAC’s strict liability standard does not forgive. A program that was fully compliant at last week’s refresh can be out of step by the time a new designation package lands. Even a modest volume of undetected violations in a mid-sized transaction book can produce enforcement exposure that dwarfs the cost of the controls that would have caught them.
Read more: OFAC screening software: best practices for faster, more accurate sanctions compliance
When to run sanctions screening
Sanctions risk does not enter a business only at onboarding. New designations land while customers are active, ownership structures change after a relationship is established, and payments move through correspondent banks that carry their own screening obligations.
The table below maps the points where screening must run and what each check covers.
| Screening moment | What to screen | Compliance rationale |
| Customer onboarding | Customer, directors, beneficial owners, known addresses, and associated entities | Prevents restricted parties from entering the platform before the relationship begins |
| KYC and KYB refresh | Updated customer data, new ownership information, and changed corporate structures | Catches risk that appears after initial onboarding through ownership changes or new designations |
| Payment initiation | Originator, beneficiary, intermediary bank, IBAN, SWIFT code, and transaction corridor | Stops prohibited transactions before funds are released |
| Outbound payouts and withdrawals | Recipient account details, wallet addresses, and beneficiary entity data | Reduces sanctions and evasion exposure in outgoing payment flows |
| Continuous monitoring | Full customer portfolio, beneficial owner data, and key entity identifiers | Detects list updates and new designations affecting existing relationships |
| Batch remediation | Historical files, acquired portfolios, and large customer populations | Cleans up legacy data and prepares the program for regulatory review |
From alert to decision: How compliance teams handle screening results
Regulators treat the screening result as the starting point of a review process, not the output.
When a match fires, the compliance team’s first job is to determine whether it represents a genuine hit or a false positive. That requires more than the alert itself.
The reviewer needs the full entity profile: all identifying information, the matched list record, a match strength score, contextual signals, and a record of how similar alerts on the same entity have been handled before.
Without this context, the decision rests on the match, which is never sufficient on its own.
The disposition path depends on what that review finds. Low-confidence alerts on common names should move quickly through a documented review and be closed with a recorded rationale.
High-confidence matches, or alerts with incomplete customer data, warrant escalation and, depending on the outcome, may require enhanced due diligence, a transaction block, or a regulatory report.
What both paths share is the documentation requirement. Banking partners and regulators treat the decision record as the primary evidence of program effectiveness. Its absence is read as a control weakness regardless of how accurate the underlying screening may have been.
How AI is changing real-time sanctions screening
The volume of work between a raw alert and a compliance decision is where most analyst time goes. AI changes that ratio without changing who makes the final call.
Legacy screening generates high false-positive rates because rule-based matching engines apply uniform thresholds to every alert, regardless of context.
AI-assisted match review introduces contextual scoring, weighing match confidence, entity type, geographic indicators, date-of-birth alignment, and ownership links before the alert reaches a human reviewer. The analyst sees not just that a record was flagged, but which factors the system weighed, what confidence it assigned, and why.
The FinCEN AML/CFT reform proposal reinforces why explainability is the operative requirement. Risk-based programs that direct attention toward higher-risk activity will be evaluated on effectiveness, not volume of alerts processed.
An AI recommendation that cannot be interrogated and documented carries no weight in a regulated compliance workflow, regardless of its accuracy.
Watch: Sigma360’s new GenAI innovations: transforming risk screening with AI
How Sigma360 supports real-time sanctions screening
Delayed list data, name-only matching, ownership blind spots, and alert queues that bury genuine risk are the failure patterns most sanctions programs share. Sigma360 is built around each of them, and it offers:
- Real-time list coverage: Screens against OFAC, UN, EU, the UK Sanctions List, and other major watchlists with multiple daily refreshes, so new designations are reflected before the next transaction or onboarding event
- Entity resolution: Checks beneficial ownership structures, shared directorships, nominee relationships, and indirect connections alongside the named customer, catching the exposure that name-only matching cannot reach
- Continuous monitoring: Flags affected relationships immediately through perpetual KYC when a new designation is published, rather than waiting for the next scheduled rescreen
- AI-assisted alert review: Scores each match against contextual signals through the AI Investigator Agent and generates an auditable recommendation before the alert reaches a reviewer
- Audit-ready decisions: Preserves every screening result, match record, analyst action, and override in a documented trail that holds up to regulatory examination and banking partner review
Rippling, which integrated Sigma360 to modernize its global payments compliance infrastructure, described the outcome as a sanctions program that is “faster, more accurate, data-driven and built for where Rippling is going.”
Sigma360 draws on more than 100 billion data points across 150+ corporate registries, with 99.9% platform uptime and SOC 2 Type II certification.
Request a demo to see how Sigma360 performs against your current sanctions screening infrastructure.
FAQ
What is the difference between sanctions screening and PEP screening?
Sanctions screening is a legal prohibition. If a party is on a sanctions list, the transaction is blocked. PEP screening flags individuals in public office for enhanced due diligence, which does not block a relationship but adds scrutiny to it.
Can a sanctions screening API handle real-time payment screening?
Yes, but only if the architecture is built for it. A purpose-built screening API returns results in milliseconds, while a batch-oriented tool retrofitted onto a payment rail cannot match that speed regardless of list refresh frequency.
What happens if my organization processes a transaction involving a sanctioned party?
The transaction violates OFAC’s strict liability standard, regardless of intent. The organization must block the funds, report to OFAC, and conduct an internal review.
Voluntary self-disclosure is a significant mitigating factor in any enforcement action.
Does real-time sanctions screening apply to cryptocurrency transactions?
Yes. OFAC has sanctioned crypto wallet addresses directly, and FATF guidance requires virtual asset service providers to screen senders and recipients against sanctions lists and apply the Travel Rule above threshold amounts.
How do I reduce false positives without increasing the risk of missed matches?
Contextual scoring is more effective than adjusting thresholds. Tighter thresholds miss near-matches while looser ones flood the queue. Weighing date of birth, entity type, and geographic indicators alongside name similarity lets the engine score risk rather than count string similarity.
