Ongoing Monitoring

The Sanctions Screening API supports ongoing screening workflows via the lastScreenDate field on the Case object.

What is Ongoing Monitoring and Screening?

Ongoing monitoring — also referred to as continuous or recurring screening — is the practice of re-screening a portfolio of individuals or entities against sanctions lists on a scheduled basis after an initial screening.

Sanctions lists change frequently — individuals and entities are added, removed, and updated on a continuous basis. A customer who was clear at onboarding may appear on a sanctions list at any point thereafter. Ongoing screening ensures that your organization detects these changes as they occur.

Regulatory Requirement

Ongoing sanctions screening is required by a combination of global and national Anti-Money Laundering (AML) regulations and frameworks. In the United States, this obligation is defined by the Bank Secrecy Act (BSA) and Office of Foreign Assets Control (OFAC) regulations. Globally, the Financial Action Task Force (FATF) Recommendations establish ongoing monitoring as a foundational requirement for compliance programs.

Specific screening frequency will depend on your organization’s risk profile, jurisdiction and applicable regulations.

Consult your compliance team
The appropriate screening frequency for your organization depends on your regulatory environment, risk profile, and the nature of your customer relationships.

Configure Ongoing Monitoring with the OFAC-API

The Sanctions Screening API supports ongoing monitoring workflows. Cases can be submitted in batches of up to 500 per request, making it straightforward to re-screen large portfolios on a scheduled basis, and each case can be configured to be screened against only the sanctions data delta since the previous check.

Avoiding Duplicate Hits with `lastScreenDate`

A common challenge in ongoing screening is managing duplicate alerts — matches that have already been reviewed and cleared in a prior screening run. Without a mechanism to distinguish new or updated sanctions records from ones already evaluated, every scheduled run produces results that overlap significantly with the previous one.

The lastScreenDate field on the Case object addresses duplicate hits. When provided, the API evaluates only sanctions records that have been added or updated after that date, skipping records that were already present during the case’s last screening run.

How to use it:

Store the timestamp of each case’s most recent screening run in your system.
On each subsequent run, include that timestamp as lastScreenDate in the case request.
The API returns only matches against sanctions data that is new or changed since that date.
On a confirmed match, your team reviews and clears it as appropriate.
Update the stored lastScreenDate for that case to the current run timestamp.

Example — ongoing screening request


{
    "apiKey": "your-api-key",
    "sources": ["SDN", "NONSDN", "EU"],
    "cases": [
        {
            "id": "customer-001",
            "name": "Jane Smith",
            "lastScreenDate": "2025-12-30T00:00:00"
        },
        {
            "id": "customer-002",
            "name": "John Doe",
            "lastScreenDate": "2025-12-30T00:00:00"
        }
    ]
}

Omitting lastScreenDate performs a full screen
If lastScreenDate is not provided, the API evaluates the case against the full sanctions dataset. This is appropriate for initial onboarding screens. For ongoing runs, always supply lastScreenDate to avoid re-surfacing previously reviewed matches.

For full details on the lastScreenDate field and all other case parameters, see the API Request documentation.