← Blog

Continuous Sanctions Monitoring: Why Onboarding-Only Fails (and How Alerts Actually Work)

Arvin Wilderink ·

Continuous sanctions monitoring is automated rescreening of your existing book of customers, vendors, and counterparties every time a sanctions list changes. Not on a Monday schedule. Not monthly. Every time OFAC, the EU, the UN, or any other authority publishes an update, which across those lists combined happens most business days.

If you only screen at onboarding, you're protected on day one and unprotected every day after. That gap is where the enforcement cases live.

This is the practitioner's guide I wanted when I started building SanctScan: what actually fires an alert, what the payload looks like, how to avoid drowning your team in false positives, and where the real compliance risk sits.

Why onboarding-only screening fails

The textbook answer is "sanctions lists change." The full answer is that three things happen to a clean customer after you onboard them:

  1. They get directly designated. OFAC adds new SDNs almost every week. A counterparty that was clean in January may appear on the list in March in response to a sanctions event (a new Russia package, an Iran escalation, a narcotics designation).
  2. Their ownership structure changes around them. The entity itself stays off the list. One of its beneficial owners becomes an SDN. Under the 50% rule, that can automatically block the entity you onboarded — without the entity ever appearing on any public list.
  3. They get added to a list you didn't originally screen. You ran OFAC at onboarding. Six weeks later, the EU designates the same person under a different program. If your ongoing monitoring only covers OFAC, you miss it.

None of these show up in your systems unless you rescreen. A static onboarding check handles zero of them.

The enforcement pattern

OFAC settlements routinely cite the absence of ongoing screening as a contributing factor. The 2019 Framework for Compliance Commitments lists "ongoing customer due diligence" and "automated screening" as essential components. When enforcement actions describe "root causes," one of the most common is some version of "the entity was screened at onboarding, was later designated, and the relationship continued because the screening did not repeat."

The fines that follow the more famous BNP Paribas–type cases tend to focus on wilful evasion. The quieter, smaller fines (five-figure to low-seven-figure) often come from this exact failure mode: good onboarding, no rescreening, and a counterparty that changed status without anyone noticing.

How often to actually rescreen

OFAC doesn't prescribe a frequency. In practice, the answer depends on two variables: how often your source lists update, and how quickly your business can act on a match.

A reasonable default by risk profile:

  • High-risk (banks, crypto exchanges, MSBs, high-value trade): rescreen daily or on list update, whichever comes first. Automated action workflows (account freeze, payment hold) wired to the alert.
  • Medium-risk (B2B SaaS, professional services, cross-border trade): rescreen within 24 hours of a list update. Alerts reviewed by a human during business hours.
  • Lower-risk (domestic SMB services, retail-only): weekly minimum, daily better. The cost of daily rescreening is now close to zero with API-based tooling, so "lower-risk" is rarely a reason to rescreen less often than daily.

The hidden rule: don't set a frequency your team can't act on. A daily rescreen that sits in an unreviewed inbox for a week is worse than a weekly rescreen reviewed within 24 hours, because the audit trail looks like negligence.

How continuous monitoring works under the hood

The mechanics of a monitoring service split into four loops:

1. Source-list ingestion

A worker polls each source list (OFAC SDN, OFAC CSL, EU Consolidated, UN Security Council, UK OFSI, Swiss SECO, Australia DFAT, Canada GAC, Japan MOF) on its own cadence. OFAC publishes XML. EU publishes its own XML. UK publishes CSV. UN publishes XML with a different schema than OFAC. Each format needs its own parser and alias-normaliser.

When a list changes, the service computes a diff — new designations, removed designations, amendments to existing entries (new aliases, updated DOB, new government IDs). The diff is what drives the rescreen, not the full list.

2. Entity enrollment

When you decide to monitor someone, you enrol them: name, DOB if individual, country, government IDs, current risk score from the last screening run. The service stores that record and indexes it for fast match queries against list deltas.

3. Delta-driven rescreening

On every source-list update, the service rescreens only the affected entities, meaning the ones whose current match score against the delta exceeds the alert threshold. This is critical. Brute-force rescreening of every entity against every list every day doesn't scale and produces enormous noise. Delta-driven rescreening cuts both cost and false positives.

4. Alert dispatch

When a rescreen produces a material score change, an alert fires through your configured channels. Email, webhook, in-app dashboard.

What an alert actually looks like

The real product differentiation in this space is alert quality, not detection-or-not. A vague alert ("new match on OFAC for Acme Trading") is useless. Your team still has to do all the adjudication work from scratch. A good alert package contains enough context for a first-pass decision in under 90 seconds.

Here's the structured payload SanctScan sends on a webhook event:

{
  "event": "risk_score_changed",
  "entity": {
    "id": "me_abc123",
    "name": "Acme Trading Ltd",
    "dob": "1978-05-14",
    "country": "AE",
    "previous_risk_score": 15,
    "new_risk_score": 87
  },
  "match": {
    "list": "OFAC SDN",
    "list_updated_at": "2026-04-22T14:30:00Z",
    "matched_name": "Acme Trading LLC",
    "matched_aliases": ["ACME COMMERCIAL", "ACME TRADING CO"],
    "matched_identifiers": { "country": "AE" },
    "confidence": 0.91,
    "designation_program": "SDN - COUNTER-TERRORISM",
    "ofac_reference_url": "https://ofac.treasury.gov/..."
  },
  "alerted_at": "2026-04-22T14:47:00Z"
}

That's 15 seconds of context. The analyst can see the confidence, the matched aliases, the country overlap, the designation program, and a direct link to the source entry. They know whether to escalate or clear without opening a dozen tabs.

The inverse (a bare "new match" email with no confidence, no alias context, no source link) is the kind of alert people ignore after a week.

Alert fatigue is the real risk

Continuous monitoring without tuned thresholds produces hundreds of weekly alerts that are mostly false positives. After a fortnight of "review → clear → review → clear," analysts stop reading carefully. That's the moment a real match gets dismissed.

Three practical tactics:

1. Score deltas, not score absolutes. An entity that has had a confidence score of 0.65 for six months and is still 0.65 today isn't news. An entity that jumped from 0.15 to 0.87 overnight is. Alert on the delta.

2. Tiered thresholds by risk level. Pre-categorise your monitored entities by risk. High-risk gets alerted on small moves. Lower-risk gets alerted only on large jumps or confirmed matches. This is a 30-minute config change that cuts noise meaningfully.

3. Aggregate daily digests for non-critical alerts. Instead of 40 individual emails, one daily digest for medium-priority alerts keeps the signal visible without exhausting the team.

SanctScan's monitoring defaults to delta-based alerts on a per-entity risk-adjusted threshold, so the alert volume tracks real material score changes rather than every fuzzy-match wobble.

Handling an alert: the six-step flow

When an alert lands, the workflow that survives a regulatory review looks like this:

  1. Don't act immediately. An alert is not a confirmed match. Acting on it (freezing an account, blocking a payment) before adjudication creates its own liability if the match is false.
  2. Open the alert. Read the entity record, the matched list entry, the confidence, the matched aliases, secondary identifiers.
  3. Compare identifiers. Does the DOB align? Country? Government ID? Any overlap beyond the name itself?
  4. Make the determination. True positive or false positive. Document which secondary identifiers informed the call.
  5. If true positive: block the relationship, file the OFAC blocking report within ten business days if applicable, seek legal counsel for complex ownership structures. Log the entire decision chain.
  6. If false positive: document the analysis — which identifiers cleared the match, who made the call, timestamp. Save it. Regulators inspect cleared alerts during exams, and "we decided it wasn't them" without supporting evidence is a finding.

Continuous monitoring vs. batch rescreening

Some teams run a weekly or monthly batch rescreen against their entire customer base. Better than nothing, worse than continuous.

Batch (weekly)Continuous
Time-to-detectionUp to 7 daysHours
Infra loadPeriodic spikeSteady, delta-only
Alert volumeBursty (dozens on Monday)Smoothed (a few per day)
Audit trailWeekly log dumpsPer-event records
Covers 50% rule updatesOnly on batch dayNear-immediate

The operational win of continuous monitoring isn't just faster detection. It's that alerts are spread over time, giving your team bandwidth to review each one carefully rather than triaging a Monday backlog.

Monitoring limits by plan

PlanMonitored entitiesAlert channelsRescreen cadence
Free0 (ad-hoc only)
Solo ($19)25EmailDaily
Starter ($39)150Email + webhookHourly
Growth ($149)1,000Email + webhook + custom routing15-minute
EnterpriseUnlimitedEmail + webhook + SIEM integrationsConfigurable

See /pricing for current tiers.

Frequently asked questions

How quickly does monitoring detect a new sanctions designation?

SanctScan polls each source list on its own cadence (OFAC within hours of publication, others depending on how the source publishes). Once a list update is ingested, affected entities are rescreened immediately and alerts fire within minutes of the list being processed.

Can I monitor entities I didn't originally screen through SanctScan?

Yes. You can enrol entities via the dashboard or API regardless of screening origin. Many customers onboard their existing customer base at implementation — bulk-import CSV or enrol individually through the monitoring endpoint.

What happens if a monitored entity is removed from a sanctions list?

The rescreen detects the removal, the entity's risk score drops, and an optional "designation removed" event fires. This matters because continuing to block a no-longer-sanctioned party exposes you to civil claims. Unblocking is a decision that needs its own audit trail.

Does monitoring catch 50% rule changes?

Partly. SanctScan screens disclosed beneficial owners when you provide them and re-runs the owner screen on every list update. If an owner becomes sanctioned, the entity's score reflects that exposure. What monitoring cannot do is discover new ownership structures you haven't disclosed — ownership intelligence is a separate problem (and a separate vendor category).

What global lists does monitoring cover?

Default coverage: OFAC SDN and CSL, EU Consolidated, UN Security Council, UK OFSI, Swiss SECO, Australia DFAT, Canada GAC, Japan MOF. Every plan covers every list — there's no per-list surcharge. See /check for the full source list.

Is continuous monitoring required by OFAC?

OFAC doesn't prescribe a specific cadence, but the 2019 Framework for Compliance Commitments explicitly lists "ongoing customer due diligence" and "automated screening" as essential components. In practice, a one-time onboarding screen without ongoing monitoring is increasingly treated as inadequate by examiners.

How do webhook alerts differ from email alerts?

Webhooks deliver a structured JSON payload to an endpoint you control. That lets you automate downstream actions: create a ticket in your compliance case system, post to a Slack channel, pause the customer's account, kick off an internal workflow. Email is fine for small compliance teams reviewing alerts manually; webhooks are the right choice if you want to wire monitoring into existing operations infrastructure.

Will continuous monitoring generate a lot of false positives?

Tuned poorly, yes. Tuned well, no. The key settings are delta-based alerting (not absolute scores), risk-tiered thresholds per entity, and optional digesting for medium-priority alerts. The alert volume you should expect depends heavily on the risk profile of your monitored book — concentrated high-risk portfolios fire more often than diversified low-risk ones. SanctScan's defaults aim for a manageable signal-to-noise ratio rather than fixed alert quotas.

Bottom line

Onboarding-only screening isn't sanctions compliance. It's a point-in-time snapshot that ages out within weeks. Continuous monitoring is what closes the gap between a designation landing on an OFAC list and your team knowing about it.

The mechanics are solvable. The discipline around alert adjudication, reading each one carefully, documenting the decision, keeping false-positive rates manageable, is what separates a compliance program from compliance theatre.

If you want to see monitoring in action, screen a name for free. Continuous monitoring starts on the Solo plan at $19/month, which covers 25 monitored entities with daily rescreening and email alerts — enough to wire up the workflow end-to-end before you scale.

Cookie Preferences

We use cookies to analyze site traffic and improve your experience. You can choose to accept or decline non-essential cookies.