This page shows the full details of a single screening request — the transaction message that was screened, what each screening module found, and tools to take action. You reach it by clicking the magnifying glass icon on any row in the All Transactions list.

Screening info and risk score

The left panel summarizes the screening outcome:

Module results

The right panel lists every screening module that ran against this transaction. Each row shows whether the module raised a Block (hard flag) or Warning (soft flag).

Click a module name (shown in blue) to open its detailed run information — this reveals the specific data points, sanctions list matches, or risk indicators that led to the flag.

Taking action

The action buttons on the right side determine the final outcome for this transaction. Expand the Help - Decision Actions section for a quick reference:

After accepting or rejecting, you are automatically returned to the transactions list.

Opening a case for a request

Click Case management to raise a ticket for this transaction. The button is shown only while the request has no ticket; once one exists, the ticket panel described in the next section takes its place. Tickets are raised from a screening request (or from the Case Management list), not from a report theme.

The dialog opens as New Ticket (or New Signal, depending on your menu layout) with the title set to the transaction identifier and, when the message could be parsed, the description filled with a summary of the transaction: amount, date, both parties with their address, institution ID and account, and the message text. Edit either before saving.

The category is not chosen in the dialog. EFI sets it from the screening module that raised the block, or from the first warning if nothing was blocked.

After Create, the ticket is linked to this request and shown on the page in place of the button. It also appears in the Case Management list like any other ticket.

Whitelisting a hit from a module's run information needs a ticket to attach the entry to. If the request has none yet, this same dialog opens first; the whitelist dialog follows as soon as the ticket is created.

The ticket panel on the request page

Once a request has a ticket, the ticket is shown on the request page below the message and any linked monitoring alerts. It is the same ticket you can open from Case Management, presented without the title, category and label controls of the standalone ticket page, and with one field the standalone page does not have: Progress.

The Details card shows the ticket number after its heading when one has been assigned. Click the pencil icon next to a field to change it.

• Progress: how far the investigation has come, as a percentage. Drag the slider between 0 and 100. This field exists only on this panel.
• Time remaining: counts down to the due date. Shows Set due date while none is set.
• Priority: low, normal or high. Shows Set priority while none is set.
• Status: Close asks for a close reason and closes the ticket; Reopen puts a closed ticket back to Open.
• Whitelist: Add name to whitelist, on screening tickets only. See Whitelisting a screened name.
• Close Reason and Resolution Time: shown once the ticket is closed. The reason can be changed later with its pencil icon. Resolution time appears only for reasons that resolve the ticket, not for tickets closed automatically, merged, or parked for monitoring.
• Assigned to: one or more users; unassigned until someone is set.
• Article Count, Created By and Last updated are for information. When the ticket was raised by someone outside the owning institution, Created By adds "from" that institution (or "from Elucidate").

To the left of the card, the ticket Description can be edited in markdown, and the Files card lists attachments with their upload time, size and type. Click a file name to download it; the trash icon removes it. New files go in through the upload area, by click or drag and drop.

Comments take markdown; Cmd+Enter (Ctrl+Enter on Windows) submits. You can edit your own comments with the pencil icon next to your name. Latest activities records every change with who made it and when. Where a change replaced text, Show previous version displays the earlier content with the differences highlighted; Hide previous version collapses it again.

Editing Progress, Time remaining, Priority and Assigned to, and whitelisting a name, require the remediation-write permission (see Case management permissions) and a ticket owned by your institution. Closing or reopening the ticket, editing the description and removing attachments only require the ticket to be owned by your institution. Comments and file uploads are always available.

Message info

The lower section displays the raw SWIFT message (MT103, MT202, MT700, etc.) exactly as it was submitted for screening. This is the original payment instruction that was parsed and checked against the screening modules.

Linked monitoring alerts

If transaction monitoring is enabled and this transaction triggered monitoring alerts, they appear in a Linked Monitoring Alerts table below the message. Each alert shows the module that created it, its status (Open or Resolved), and creation date. Click any alert row to navigate to its ticket for further investigation.

Logs and audit trail

Click Logs at the bottom to expand a detailed log of what each screening module did during processing — useful for debugging or auditing screening decisions.

Click Download logs at the top to download a full audit report for this screening request as a file.

Supplementary data

Some transactions carry extra structured detail that isn't in the original SWIFT message — for example the parties, goods, and codes taken from a commercial invoice or transport document, including AML-tagged fields. When that detail is submitted against a request, it appears in a Supplementary data section, and EFI screens each submission on its own and shows an Allow or Block decision for it.

Supplementary data has no configuration of its own — it is screened using the modules you have already set up in your screening flow. Every submitted value — each field, and every AML-tagged value — is run through those modules, so supplementary screening always reflects the same lists, categories, and match settings you configured there. Update a module and supplementary screening changes with it; see Building the screening flow for what each module does.

AML-tagged values are screened in the way that suits each tag — a party name as a name, a country code as a country, a bank identifier as a BIC, a vessel identifier as a vessel, or as free text — and tags not meant to be screened are skipped.

Any hit is listed as an alert on the submission, labelled by the kind of match so you can see what drove the outcome. A submission is Blocked if any actionable alert remains after whitelisting; otherwise it is Allowed. As with the request itself, the submission keeps a full log of every value checked and every match found, so the decision is auditable.

MT799 requests are always decided by a user

An MT799 message always comes with supplementary data, and there is no way to know how many documents will follow — more can arrive at any time. EFI therefore never decides an MT799 by itself. The message is screened and error-checked on arrival, but no system decision is issued: the request stays open, accepting supplementary data, until someone on your team decides it.

A blocking alert moves it to your queue, but does not close it. If the MT799 message itself is blocked, or any supplementary submission comes back Blocked, the request moves to the pending-user-decision state so it surfaces for review. It is still open and still accepts more supplementary data. Once escalated it stays escalated — a later clean submission does not move it back, and a second blocking submission changes nothing.

Your decision is what closes it. Accepting or rejecting the request completes it and sends the outcome (and any webhook to your systems) to your systems. Nothing is reported before that point, so your systems receive exactly one outcome per MT799, reflecting the decision your team actually made.

Two consequences worth knowing:

• Deciding is final. Once a request is completed it no longer accepts supplementary data — a later submission against it is rejected. If you are still expecting documents, decide only when you have everything you need.
• An open request waits indefinitely. If no supplementary data ever arrives and nobody decides, the request stays in progress. Use the Pending user decision status filter, and the awaiting docs marker on in-progress rows, to find requests that are waiting on you.

If a supplementary submission fails to screen because of a processing error, the request goes to ERROR and is reported straight away — a failure is not a compliance decision, so it does not wait for a user.

The Screening Matching Algorithm

This section explains, in detail, how EFI decides whether a transaction matches a sanctions, PEP, or watchlist record. It covers the kinds of matching — name, free text, countries, and vessel — and every setting that influences the outcome. Understanding this is the key to tuning your screening so that genuine risks are caught while everyday transactions flow through without unnecessary alerts.

What a screening request checks

When a transaction is submitted, EFI reads the payment message (MT103, MT202, MT700, etc.) and extracts a set of fields. Each field can be screened independently, and each is only screened if you have switched it on in your screening configuration:

Each enabled field is compared against the watchlists you have selected (see Configuration below). A field can produce zero, one, or many hits. Hits then pass through your whitelist (false-positive suppression, including stop words) and blocklist (your own internal list) before EFI reaches a final decision.

Where records come from

EFI matches against two record sources:

• Watchlist index — the built-in sanctions and PEP lists (UN, EU, OFAC, HMT, SECO, DFAT, METI, NST, national sanctions, PEP lists, and UN country lists).
• OpenSanctions — an additional, continuously-updated global sanctions dataset. This source is only queried for institutions that have OpenSanctions enabled, and it adds a second, independent name-matching engine on top of the built-in lists.

Supported message types and what EFI extracts

EFI screens SWIFT FIN MT messages, ISO 20022 MX (pacs) messages, and its own internal transaction format. EFI picks the parser from the declared message type — and if the SWIFT header inside the message declares a different type than the request, the header wins. Each parser reads only the fields that its message type actually carries and maps them onto the common fields in the table above; anything a message doesn't contain is simply left empty and not screened.

The tables below show, per message type, which of those screenable fields EFI populates. (Amount, currency and dates are also parsed for display, but are never screened.)

Payments and institution transfers

Free-format messages (MT n99)

MT199, MT299, MT499, MT599, MT799, MT999 all share one parser. These are free-format messages that carry no structured party or institution fields — only references and a free-form :79: narrative. EFI therefore extracts:

• the :79: narrative, screened as free text; and
• the two messaging-endpoint BICs taken from the message's SWIFT envelope headers — the sending institution (basic header, block 1) and the receiving institution (application header, block 2) — mapped to Originator FI ID / Beneficiary FI ID and screened as BICs. (For output messages the two endpoints are swapped, so the true sender and receiver are still the ones screened.)

Because a free-format message has no other bank fields, these envelope endpoints are the only institution identifiers available, so a sanctioned sending or receiving bank (for example a Russian correspondent BIC) is now caught here rather than passing through unscreened.

MT799 is always decided by a user. Because an MT799 always arrives with supplementary data and more can keep arriving, EFI screens and error-checks the message but never issues a system decision — the request stays open until someone on your team decides it. See MT799 requests are always decided by a user above.

Trade finance — documentary credits and guarantees (MT7xx)

Internal format

Elucidate transaction (elucidate_tx) is a JSON representation used for transactions that don't arrive as SWIFT/ISO messages. Its fields are provided directly and screened using the same field table above.

Match type: exact vs. fuzzy

The single most important setting is match_type, which applies to name and free-text matching:

• Exact — the screened value must match the record term letter-for-letter (after lower-casing). JOHN SMITH matches only john smith. Use this when your data is clean and you want the fewest possible alerts.
• Fuzzy — the screened value matches even with small spelling differences, typos, or transliteration variants. This is the recommended default for sanctions screening, because names are frequently mis-spelled or transliterated: Gaddafi and Qaddafi differ by a single character and match each other. Fuzziness has limits, though. A shorter variant such as Kadafi is two edits away and is not caught, so genuinely divergent transliterations still need their own list entry.

Fuzzy matching uses edit distance (the number of single-character insertions, deletions, or substitutions needed to turn one word into another). EFI scales the tolerance to the length of the word so that short words are matched strictly and long words more leniently:

This length-based tolerance governs the built-in watchlist, and also re-checks OpenSanctions hits on free-text, vessel and country values. It does not apply to OpenSanctions name matching, where the engine scores the name as a whole entity and EFI trusts that decision directly. See How a name is scored.

Punctuation and word boundaries

Every value EFI searches — a party name, a free-text narrative, an address, or shipping text — is compared to watchlist records word by word, and a match requires each word of the searched value to line up with a word of the record. Financial messages, however, routinely join two words with punctuation and no space between them: a SWIFT :79: line reading END BUYER:ROSNEFT, or a structured party field like SMITH/JONES.

Read literally, BUYER:ROSNEFT is a single "word" that matches no sanctioned entity — so the sanctioned name ROSNEFT would be missed. To prevent this, before searching, EFI splits every value on any punctuation or symbol (: / - . , ( ) + _ and the like) and screens the resulting words in addition to the original value. BUYER:ROSNEFT is therefore searched as BUYER, ROSNEFT, and BUYER:ROSNEFT, so the hit on ROSNEFT is caught.

This runs in EFI's shared search layer, so it applies to structured fields — names, country codes, BICs — on the built-in watchlist engine, and to OpenSanctions for country and vessel screening. Name matching against OpenSanctions is the exception: it sends the whole name as one entity (see Match on name), so it is not split this way. Values with no internal punctuation are searched unchanged, so it adds coverage without altering everyday matching. Free-text fields are handled by the windowing above instead: the text is split on the same punctuation before windows are built, and a glued buyer such as END BUYER:ROSNEFT in a :79: narrative is caught by the labelled-value rule.

Match on name

Name matching applies to the originator and beneficiary (and intermediaries).

Which name is used

The setting use_name_from_transaction controls which name EFI screens:

• On — the name written in the transaction/payment narrative is used.
• Off — the name registered against the sending/receiving account (BIC + account number) is used instead.

How a name is scored

1. Built-in watchlist — the name is compared to every record on your selected lists using exact or fuzzy matching as configured. Each hit receives a match score shown as a percentage. This percentage is relative to the strongest hit in that search — the best match is anchored near 100% and others are scored against it — so treat it as a ranking signal rather than an absolute probability.
2. OpenSanctions — the whole name is sent as a single entity (as both a Person and a Company) to the OpenSanctions engine, which scores it and returns only the candidates it judges a match. Unlike free-text screening, the name is not first broken into individual words, so a name that arrives with extra address text — for example SULFATE EXTRACTION CO LTD, CHIYODA-KU, TOKYO, JAPAN — is compared as one name and no longer produces spurious hits on generic words such as CO, LTD or KU.

Alphabets on the lists. The official sources record names in several alphabets, including Cyrillic, Arabic, Han, Greek, Hebrew and Korean alongside Latin, and coverage varies from record to record. The built-in watchlist compares values in the alphabet they arrive in, so a romanized name is matched against romanized list spellings. Cross-script matching is handled only by the second engine below, and only for name fields. On your own custom watchlists, add each script you expect to see as a separate entry.

How the name-matching engine scores a name

Name matching runs in two stages. First a fast search retrieves candidate records that could plausibly match, tuned for recall; then each candidate is scored against the searched name and given a value between 0 and 1. The scorer is rule-based and explainable — every match records why it scored as it did — and works across languages and scripts, so a name can match across Latin, Cyrillic and Arabic transliterations.

What the score is built from:

• Name comparison — the dominant signal. Names are compared token by token using exact (literal) matches and fuzzy edit-distance matches, with curated multi-lingual reference data that understands how names are constructed in different cultures and links spellings of the same name across languages and scripts. Distinctive family names count for more than common given names. This comparison is not phonetic: names are not reduced to a "sounds-like" code, because such codes are hard to justify to a reviewer and produce nothing usable for non-alphabetic scripts.
• Aliases — matching a record's known alias also counts, with less weight than its primary name.
• Corroborating identifiers — a shared strong identifier (tax or registration number, LEI, BIC, and the like) all but confirms a match.
• Contradicting attributes lower the score — a clear country, date-of-birth, or gender mismatch pulls the score down.

The match decision. The combined 0–1 score is compared against a calibrated threshold (stricter settings raise the bar). Records at or above it are treated as matches and kept; everything below is discarded. Because the name is scored as a whole entity, EFI trusts this decision directly for name matching, rather than applying the extra word-by-word edit-distance filter it still uses for free-text screening.

Distinctive (strong) name matches

Some surnames are distinctive enough that a single-word match is meaningful on its own — for example PUTIN or IVANOV. EFI flags these as strong name matches when the matching engine assigns the token a high weight. Strong matches are treated more cautiously: notably, they survive the free-text false-positive filter described below even when the full name is not present in the text.

Match on free text

Free-text matching applies to the transaction message — the free-form remittance / narrative — and to any free-text values submitted as AML-tagged or supplementary data. (Party addresses are not name-screened as free text; they are resolved to a country and checked against your country lists — see Match on countries.)

These fields contain unstructured prose, so rather than screen each word on its own, EFI screens overlapping windows of consecutive words — two words at a time by default (configurable). The text is split into words (on spaces and on punctuation — see Punctuation and word boundaries), and every run of adjacent words is screened as a phrase against your selected lists using the configured exact/fuzzy setting. Because a window is a phrase, a hit needs every word in the window to appear in the candidate name, so a two-word window matches a genuine two-word entity (Mahan Air) but not a lone everyday word.

Screening words as phrases avoids the classic false positive of word-by-word screening, where a short everyday word fuzzy-matches a fragment of a longer sanctioned name — WILL in "CONFIRMATION WILL FOLLOW" hitting "W. Anthony Will", or NO hitting "NO Kwang Chol" — because those lone words are never screened on their own. A party named after a known label (for example END BUYER:ROSNEFT) is additionally extracted and screened on its own, so even a single-word buyer is still caught. For the full mechanics of windows and labelled buyer lines, see Watchlist Search & matching.

EFI reduces false positives further in three ways.

1. Automatic noise filter

Before any hit is raised, EFI discards any window made up entirely of noise tokens — bare numbers, single characters, and a built-in list of high-frequency, low-information words (articles, prepositions, and common payment terms such as BANK, PAYMENT, or a currency code). On their own these only ever fuzzy-match a sanctioned name by accident. A window that keeps even one meaningful token is left untouched, so this strips noise without ever hiding a genuine match.

2. Automatic reverse-lookup filter

For free-text fields, EFI applies an automatic check before showing you any hit: the matched entity's full name must actually appear in the text as a run of consecutive words. If a record for "John Smith" is triggered only by the isolated word "John", and "Smith" does not follow it in the message, the hit is dropped automatically. (This comparison is itself fuzzy, so minor spelling differences are tolerated.)

Two exceptions are deliberately kept even if the full name is not present:

• Strong / distinctive single-word matches (see above) — a lone PUTIN is kept.
• Records that have no resolvable name to reverse-check against.

Dropped hits are logged as candidates, so nothing is silently lost from the audit trail.

3. Stop words (manual false-positive suppression)

The noise and reverse-lookup filters are automatic, but you will still encounter recurring noise words specific to your traffic that keep triggering hits — a place name like HONG KONG, or a routine word your business uses constantly that isn't on the built-in list. To suppress these permanently, you add them as stop words, extending the built-in noise list with your own terms.

A stop word is a whitelist entry scoped to free text. It suppresses the matched word only in free-text fields (message and addresses) — it can never clear a hit on an originator or beneficiary name field. This scoping is deliberate: silencing the word HONG KONG in narrative text must not also silence a sanctioned party literally named after it.

How to add a stop word

1. Open the screening request (or the related screening ticket) that produced the false positive.
2. Open the module's detailed run information and find the offending free-text hit.
3. Click to whitelist the hit. For a free-text field, EFI offers you one entry per matched word (for example just HONG KONG), not the whole message — so you suppress precisely the noise word and nothing else.
4. Because this is a free-text hit, the account-level scope options are hidden — a stop word applies to the word itself, across the institution, not to a single account.
5. Submit. Depending on your configuration the entry may go into a pending review state ("Name submitted for review") and only begins suppressing hits once it has been accepted.

How a stop word behaves once active

• Word-precise — it only removes hits triggered by that exact word. Other words in the same message that trigger their own hits still raise alerts. A single message can be partly suppressed and still block.
• List-aware — a stop word can be limited to specific source lists. If it is, it only suppresses hits from those lists; hits from other lists still surface. (If a stop word's list restriction makes it unable to ever match, EFI warns you that the entry is ineffective.)
• Score-aware — a stop word can carry a minimum matching percentage, so it only suppresses hits at or above that confidence and leaves weaker/stronger hits to be handled separately.

Best practice: add stop words iteratively. Review the free-text hits your live traffic generates, and whenever a word is clearly business noise with no sanctions relevance, whitelist that word as a stop word. Over a few weeks this dramatically cuts free-text false positives without weakening name screening, which stop words never touch.

Related but different: the keyword-scanning module (check message) has its own exclusion terms. Those are configured per keyword category and prevent a category term from counting as a hit when an excluding term is present in the same message. Exclusion terms are a module configuration, whereas stop words are whitelist entries you add from a ticket — keep the two concepts separate.

Match on countries

Country matching is exact list membership — there is no fuzzy matching for countries. A country either is or is not on a configured list.

There are three country paths:

• Country lists (check country module) — you define one or more named lists of two-letter ISO country codes (e.g. IR, KP, RU). EFI checks the transaction's originator country, originator FI country, beneficiary country, beneficiary FI country, and any resolved shipping countries against these lists. Any country found on a list raises a flag, recording which country, which field, and which list matched.
• Shipping information (watchlist) — in trade-finance messages, shipping details (ports, vessels, routes) are screened specifically as country records against the UN country lists. This path only performs country-type matching and does not call OpenSanctions.
• Free text (watchlist) — the transaction message (and free-text AML / supplementary values) is also scanned for sanctioned countries: every one-to-three-word phrase is compared exactly against the country lists, so a country named in a narrative — North Korea, United Arab Emirates — is flagged as a country hit even when the message matches no sanctioned entity.

Country resolution

Countries are not always stated explicitly. EFI can resolve the country from a party address (turning a free-text address into an ISO code) so it can be checked against your country lists — this is how addresses are screened. The same resolution feeds the check-country and shipping paths above. It can be disabled per institution if you prefer to rely only on explicitly-stated country codes.

Match on vessels

Vessel fields — a vessel's name or IMO number supplied in structured trade / AML data — are screened as vessels against the built-in watchlist's vessel records and, for institutions with OpenSanctions enabled, against OpenSanctions Vessel entities. This is distinct from the country-based Shipping information screening above: ports and routes are matched as countries, whereas a vessel identifier is matched as a vessel.

• EFI runs two searches for each vessel value: the value exactly as provided, and an IMO-prefixed variant (e.g. 9274446 also tries IMO9274446), so an IMO number matches whether or not the IMO prefix is present.
• Candidates are matched on the vessel's name and its IMO / registration number, honouring the Exact/Fuzzy toggle.
• A vessel hit is tagged with a vessel type, and opening the record shows the matched IMO number. Because OpenSanctions scores a vessel by blending the (perfect) identifier match with a name comparison against the registered name, an exact-IMO hit can read slightly below 100% (e.g. 95%) — read the percentage as match confidence, not string equality.

From hits to a decision

Once every enabled field has been screened and hits have been filtered, EFI decides the outcome for the transaction:

Whether a block becomes a hard block or a warning is controlled by each module's on_hit setting (block or warn). A hard block stops the transaction; a warning surfaces the hit for review without automatically stopping it.

Configuration reference

The following settings shape matching behaviour. Most are configured per institution by your administrator; the algorithm thresholds are fixed and shown here for transparency.

Per-institution screening settings

Whitelist / stop-word entry settings

Fixed algorithm thresholds

These are built into the engine and are the same for every institution:

In short: switch on the fields you need, choose fuzzy matching for sanctions robustness, and then curate your stop words on free-text fields to strip out recurring business noise. Because stop words are scoped to free text, this tuning cuts alert fatigue without ever weakening the name screening that catches real sanctioned parties.