Continuous Sanctions Monitoring: Why One-Time Screening Is Not Enough

Most fintechs understand that they need to screen customers against sanctions lists at onboarding. Far fewer understand that screening at onboarding is only the beginning. Sanctions lists change constantly. A customer who was clean when they signed up last month might appear on the OFAC SDN list tomorrow. If you are only screening at onboarding, you are building a compliance program with a blind spot.

This article explains why continuous sanctions monitoring is essential, how it differs from batch re-screening, and how to implement it using webhooks and automated alerts.

The problem with one-time screening

Screening a customer once — at signup, before their first transaction, or during initial KYC — catches entities that are already sanctioned. It does not catch entities that become sanctioned after they become your customer. This is not a theoretical risk. It is a regular occurrence.

In 2022, after Russia's invasion of Ukraine, OFAC added thousands of new entities to the SDN list over the course of weeks. Companies that only screened at onboarding discovered that existing customers — some who had been active for years — were now sanctioned. The same pattern repeats with every geopolitical crisis, terrorism designation, and corruption scandal.

OFAC explicitly expects financial institutions to re-screen their existing customer base when sanctions lists are updated. In their published guidance, OFAC states that institutions should have policies and procedures in place to identify and interdict transactions involving newly designated parties. This means ongoing monitoring is not optional — it is a regulatory expectation.

Batch re-screening: the baseline approach

Batch re-screening is the most common approach to ongoing compliance. You export your customer database, run it through a screening API in batches, and review any new matches. Most fintechs do this weekly or monthly.

Batch re-screening has advantages. It is simple to implement — a cron job and a loop over your customer database is enough. It is predictable — you know exactly when screening happens and can plan compliance team capacity around it. And it is comprehensive — every customer gets checked against the full updated list.

But batch re-screening has a critical weakness: timing. If OFAC adds a sanctioned entity on Tuesday and your next batch job runs on Sunday, that entity can transact on your platform for five days before you detect the match. For a payment processor handling millions in daily volume, five days is an eternity. For a crypto exchange, it could mean processing withdrawals for a newly sanctioned wallet address.

The gap is worse than it appears. Sanctions designations often happen in response to real-time events — a terrorist attack, a weapons test, a coup. Regulators expect institutions to act quickly. A five-day delay between designation and detection does not look like diligence; it looks like a compliance failure.

Continuous monitoring: how it works

Continuous monitoring solves the timing problem by inverting the workflow. Instead of you checking the sanctions lists on a schedule, the screening provider checks your registered customers against every list update in real time.

Here is how the flow works:

1. Register names. When a customer signs up and passes initial screening, you register their name with the screening provider's monitoring service. This tells the provider to watch for future matches against this name.
2. List updates. The provider monitors official sanctions sources (OFAC, UN, EU, UK) and ingests updates as they are published — typically within hours.
3. Automatic checking. When a list update contains new entries, the provider automatically checks all registered names against the new entries. This happens in the background without any action from you.
4. Webhook alert. If a registered name matches a newly added sanctions entry, the provider sends a POST request to your webhook endpoint with the match details, confidence score, and source list.
5. Take action. Your webhook handler receives the alert, freezes the affected account, blocks pending transactions, and notifies your compliance team for review.

The entire cycle from list update to account freeze can happen in minutes rather than days. This is the difference between catching a sanctioned entity before they move funds and discovering the violation during your next audit.

How fast do sanctions lists actually change?

To understand why continuous monitoring matters, you need to understand how fast sanctions lists change. Here is the update frequency for the major lists:

During the 2022 Russia-Ukraine crisis, OFAC published multiple updates per day for weeks. Each update added dozens or hundreds of new entities. Companies with weekly batch jobs were perpetually behind. Companies with continuous monitoring were alerted within hours.

Batch vs continuous: a practical comparison

Most mature compliance programs use both. Batch re-screening provides a comprehensive check against the full list on a schedule. Continuous monitoring fills the gaps between batch runs. Together, they provide defense in depth.

Implementing webhook-based monitoring

Setting up continuous monitoring requires three components: registration, a webhook endpoint, and a handler that takes action on alerts.

Step 1: Register names for monitoring

When a customer passes initial screening, register their name with the monitoring service. With Verifex, this is typically done through a monitoring registration endpoint or automatically when you enable monitoring for your account.

# Register a customer for continuous monitoring
POST /v1/monitor/register
{
  "name": "Aleksandr Petrov",
  "type": "person",
  "customer_id": "cust_12345",
  "lists": ["ofac_sdn", "un_consolidated", "eu_consolidated", "uk_hmt"]
}

The registration includes the name, entity type, your internal customer ID (so you can map alerts back to your system), and which lists to monitor against.

Step 2: Create a webhook endpoint

Your webhook endpoint receives POST requests when a match is detected. Here is a basic implementation in Node.js:

app.post("/webhooks/sanctions-alert", async (req, res) => {
  const alert = req.body;

  // Verify webhook signature (provider-specific)
  if (!verifyWebhookSignature(req)) {
    return res.status(401).json({ error: "Invalid signature" });
  }

  // Log the alert for audit
  await auditLog.create({
    type: "sanctions_alert",
    customer_id: alert.customer_id,
    matched_name: alert.matched_name,
    source_list: alert.source_list,
    confidence: alert.confidence,
    list_version: alert.list_version,
  });

  // Freeze the account immediately
  await freezeCustomerAccount(alert.customer_id);

  // Block pending transactions
  await blockPendingTransactions(alert.customer_id);

  // Notify compliance team
  await notifyComplianceTeam(alert);

  res.status(200).json({ received: true });
});

The handler should be idempotent — if the same alert is sent twice (due to retry logic), the second invocation should not cause problems. Always verify webhook signatures to prevent spoofing.

Step 3: Handle the alert

When an alert arrives, time is critical. Your handler should:

• Freeze the account immediately. Do not wait for human review. A newly sanctioned customer should not be able to initiate new transactions while you investigate.
• Block pending transactions. If the customer has pending withdrawals, transfers, or payments, hold them.
• Log everything. Record the alert details, the action taken, the timestamp, and who was notified. This is your audit trail.
• Notify compliance. Send an alert to your compliance team with the match details so they can begin investigation.
• Document the decision. Once the compliance team reviews the match, document whether it was confirmed, ruled a false positive, or requires escalation.

Regulatory expectations for ongoing monitoring

Regulators across jurisdictions expect ongoing sanctions monitoring. Here is what the major frameworks require:

• OFAC (U.S.): Expects institutions to have policies for interdicting transactions involving newly designated parties. The OFAC Compliance Framework specifically calls for "timely updates to the sanctions screening tool."
• FATF Recommendation 11: Requires financial institutions to conduct ongoing due diligence, including screening against updated sanctions lists.
• EBA/GL/2024/14 (EU): Mandates that screening systems be updated promptly when sanctions lists change and that institutions have procedures for acting on new matches.
• FinCEN: Expects money services businesses to implement risk-based procedures for ongoing monitoring, including sanctions list updates.

The common thread: screening at onboarding is table stakes. Ongoing monitoring is where regulators distinguish mature compliance programs from checkbox exercises.

Getting started

If you are currently relying only on onboarding screening, here is the fastest path to adding continuous monitoring:

1. Audit your current screening frequency. If it is only at onboarding, you have a gap.
2. Implement batch re-screening as a baseline — a weekly cron job is better than nothing.
3. Add continuous monitoring via webhooks for your highest-risk customer segments.
4. Document your monitoring policy, including response times and escalation procedures.
5. Test your webhook handler with simulated alerts to ensure it handles edge cases.

Verifex supports both batch screening and continuous monitoring. You can start with batch re-screening and add webhook-based monitoring when your compliance program matures. For more on building a complete compliance pipeline, read our AML compliance pipeline guide.