Batch screening lets your organisation submit many customer records at once and have Elucidate automatically check each one against sanctions and PEP (Politically Exposed Person) watchlists. Instead of looking people up one at a time, your customer records flow in as a batch, are screened on arrival, and any matches are surfaced for your team to review.
You review the results on the Customers page, reached via Screening > Customers.
What gets screened
For every customer record in a batch, Elucidate screens the identity information that matters for sanctions checks:
| What is screened | Description |
|---|---|
| Customer name | The name on the record (shown as User name) is checked as a full name. On the built-in index, longer names are also tried as a first + last combination, so a match is not missed when a middle name is present; the OpenSanctions engine scores the full name as one entity. |
| AML Info entries | Each tagged entry on the record is checked individually, in the way its tag calls for (most tags are names; others are screened as countries, bank identifiers, vessels, aircraft, crypto wallets or free text). Entries whose tag is unknown or marked not to be screened are skipped. |
These values are matched against the sanctions and PEP sources your institution has enabled, including OpenSanctions where it is switched on.
The other details on a record — gender, date of birth, ID type and issuing locations, the customer number, and the transaction date — are stored with the customer for reference but are not screened against watchlists.
How names are matched
Customer records are screened against the lists ticked in the Cust column of the External Screening settings, which can differ from the lists ticked for transactions (Tx), and a customer name is scored as one whole entity: your exact or fuzzy setting applies to the lists maintained by Elucidate, while for lists delivered through OpenSanctions the OpenSanctions engine makes the match decision with its own similarity scoring, which tolerates spelling variants whatever the setting. In short:
- Each name is broken into its individual words (tokens) and checked against the indexed watchlist names.
- Exact matching requires the name to appear verbatim, while Fuzzy matching also catches small spelling variations (for example Qaddafi matching Gaddafi, a single-character difference). The tolerance is tight and scales with word length, so wider transliteration variants are not caught, and neither engine converts between alphabets, so a Cyrillic name is matched against Cyrillic list spellings only. Which one applies depends on your institution's screening configuration.
- Every match carries a confidence score, so stronger matches stand out from weaker, partial ones when you review them.
For a full explanation of field types, tokenization, exact vs fuzzy matching, and how the match score is calculated, see the Manual Screening & matching guide (available with the Screening product).
When screening runs
Records are identified by their customer number. When the same customer number is submitted again, Elucidate compares the incoming record with what it already holds and only re-screens when something relevant has actually changed. This keeps your alert queue focused on genuine changes and avoids duplicate work.
| Situation | What happens |
|---|---|
| A new customer record arrives | The record is screened in full. |
| The name, watchlist entries, or other identity details change | The whole record is screened again, so every value is re-checked against the current lists. |
| A watchlist entry is left out of a re-submission | Treated as a change: the entry is removed from the record (the submitted list always replaces the stored one in full) and the record is re-screened, so a hit tied only to the removed entry clears with it. Only entries with a recognised screening tag are checked. |
| The record is re-submitted with no changes | Screening is skipped — the result would be identical to the previous check. |
| Only the transaction date changes | The updated date is saved, but the record is not re-screened, because who is being screened has not changed. |
In short: new or changed records are screened; unchanged re-submissions are not.
This covers what happens the moment records arrive. Separately, Elucidate also re-checks the customers you already hold whenever the sanctions lists themselves change — described next.
Scheduled screening for sanctions list changes
Sanctions and PEP watchlists change constantly: new people and organisations are added, and existing entries are updated. Because of this, a customer who matched nothing yesterday can become a match the moment a newly listed party is added — even though nothing about their record has changed.
To catch this, Elucidate automatically re-screens your customer records several times a day (every six hours), without anyone needing to re-submit them.
To keep each run fast and your alert queue focused, it does not re-check every customer against the entire watchlist each time. Instead it screens against the delta — only the sanctions and watchlist entries that were added or updated since the previous run:
| What is checked | Every customer record your institution holds. |
| What it is checked against | Only the watchlist and OpenSanctions entries that are new or have changed since the previous run — not the entire list. For OpenSanctions lists, "since the previous run" means since the OpenSanctions release the previous run screened against, so an entry that reached the screening index after that run is never skipped. Records already marked Sanctioned are the exception: see below. |
| Your institution's Custom Watchlists (blocklist and whitelist entries) | Applied in full on every run, delta or not — they are not tracked by list changes the way sanctions and PEP lists are, so every customer is always checked against your current blocklist and whitelist entries, not only against the ones that changed. |
| Records already marked Sanctioned | Checked again against all of your enabled lists in full on every run, because the changes alone cannot show an entry being removed from a list. |
| A list enabled after the previous run | The next run screens every customer against all of your enabled lists in full, not only the new one. From then on all lists are screened for changes again. |
| Why only the changes | If a customer only matches entries that have not changed, they were already screened against those entries before, so there is nothing new to find. Concentrating on what changed surfaces genuinely new matches quickly and avoids repeating earlier work. |
The scheduled check uses the same lists (the Cust column), matching settings and scoring as screening on submission, so a match it finds is the same kind of match a submission would have produced. If no list is ticked in the Cust column, customers are not screened at all, on submission or on schedule.
When a scheduled run finds a new match — for example, a customer who now matches a freshly listed sanctioned entity — it raises a customer screening ticket for a customer who was not already flagged, so your team is alerted and can investigate. A customer already marked Sanctioned keeps the existing ticket: the new match is recorded on the record and in its Audit Log, and the ticket is updated with it — reopened first, if your team had already closed it. Matches you have already reviewed and dismissed are not raised again, unless the underlying watchlist entry has since changed. If a record that was cleared earlier matches again, the scheduled run updates its existing ticket rather than raising a second one.
When a scheduled run finds that a record marked Sanctioned no longer matches anything, it sets the record back to Not sanctioned without anyone re-submitting it. Typical reasons: the sanctioned entity was removed from the list, every match on the record was whitelisted, or the list it matched was unticked in the Cust column. The run records the change in the record's Audit Log. If your core banking webhook is configured, Elucidate notifies it and, once that delivery succeeds, closes the customer screening ticket as Automatically Closed, so your team can tell it apart from a ticket an analyst closed — no one needs to action it; while delivery fails the ticket stays open and the next run retries. Without a webhook the ticket is not closed automatically. A record that still matches at least one entry stays Sanctioned.
If a Sanctioned record matches several entries and only some of them clear — for example one of two matching entities is removed from a list while the other still matches — the record stays Sanctioned, but the ticket and the Sanction Information section are updated to drop just the matches that no longer apply, rather than only clearing once every match is gone.
Dismissed and confirmed matches
When your team closes a customer screening ticket as False Positive or No Action Required, that specific match is remembered: if the record is screened again and the exact same watchlist entry still matches, it is not raised again and the ticket is not reopened for it. If the underlying watchlist entry is later updated (for example, more identifying details are added), the match is treated as new again and can resurface, since it is no longer the same thing your team dismissed.
Closing a ticket as Resolved or Escalated Externally instead confirms the match: it keeps showing in Sanction Information as an active hit, but an update to the watchlist entry behind it alone does not reopen the ticket — only a genuinely new, different match does that.
A record that has a closed ticket and then matches a new or different entity is raised again: the existing ticket is reopened rather than a second one being created, so your team sees both the earlier context and the new match in one place.
Telling your core banking system
If your core banking system integration has a status webhook configured, Elucidate notifies it every time a customer's screening review is resolved — either by your team closing the compliance ticket, or automatically when a scheduled run clears the record. It is never sent when a hit is first raised, only once its outcome is settled, and a partial resolution (the record still matches something else) does not trigger it either. The notification carries whether the customer is now Sanctioned and, if so, the current matches, plus who resolved it and how. The exact event name and payload are documented in your API integration guide, under "Customer Screening Webhook".
Closing a customer screening ticket with False Positive, No Action Required, Issue Resolved or Escalated Externally reports the outcome to your core banking system before the close is saved: the review is applied only once the webhook has accepted it. If a notification cannot be delivered, nothing about the record changes on Elucidate's side until it is: the ticket stays open and the error is shown — close it again to retry — and an automatic clear is retried by the next scheduled run. An institution without a configured webhook can close these tickets only as Other, which leaves the customer's screening status unchanged.
Reviewing the results
Open the Customers page to see all customer records. The list holds two kinds of record — Uploaded records submitted for batch screening and parties From transactions, built from the screened payments — and shows for each the Source, Customer # / Account #, Name, Client type, Country, Sanctioned (Yes/No), Webhook delivery status, Last transaction and Created. Narrow it with the Source menu, the Customer # / Account # and Name boxes, the Sanctioned menu (uploaded records only, since parties from transactions carry no sanctioned flag) and the Created date range, then click Search; Reset filters clears them. Export downloads the filtered list as CSV (10,000 records at most) and Refresh reloads it; Per page offers 10 to 100 rows, 25 by default.
Open an uploaded record with the magnifying glass icon to see exactly what matched (for a party from transactions the icon opens its party page instead):
- A Sanctioned / Not sanctioned badge at the top gives you the record's status at a glance. Next to it, a Delivered, Pending or Error badge shows the state of the last core-banking notification, and a Webhook Delivery Log card lists the attempts.
- The Customer info fields and the AML Info table (tag and name per entry) show what was submitted. The values that caused a match are highlighted and tagged with a Hit marker — so you can immediately see which name or watchlist entry triggered the alert, rather than guessing.
- The Sanction Information section lists the details of each match, grouped by the screened tag and value: each hit's Source list (for example OFAC or an EU list), Type, match Score, Listed on date and External ID.
- A View screening ticket link opens the customer screening ticket raised for this record, whenever one exists — even if an analyst has already closed it.
- The Audit Log section shows what happened to the record over time. Entries are labelled Scheduled re-screen when they come from a scheduled run, which leaves an entry only when it found a match or cleared the record, or Manual edit when the record was edited through EFI rather than resubmitted. Changes sent through the API's update call (
PUT /customer-data/{customer_id}) appear as ordinary submissions. It shows each screening on submission (including one that ran with no matches), when the record was marked sanctioned, when the flag was cleared because a re-submission, an edit or a scheduled run found nothing (listing the values that no longer match), and when the ticket was raised or updated.
Alerts from batch screening
The first time a customer record is found to match a sanctions or watchlist entry, Elucidate raises a customer screening ticket so your team can investigate. If the same record is submitted again without changes, no duplicate ticket is created — you will only be alerted again if the record changes and a new match is found.
From there, the ticket follows the same review workflow as other customer screening alerts: you can assign it, add comments, categorise it, and resolve it once your investigation is complete.