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 Screening > Transactions.

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. For the Activity Check, the detail view lists every keyword hit with its category, the scanned message and the exact term that matched.

For External Screening, each row names the field that was screened. Rows produced by Screen all other message fields also show where the value sits in the message, as an MT tag such as :72: or a pacs element path. See Screening all other message fields.

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:

Accept, Reject and Revert are shown only while the request awaits a decision (status USER_PENDING) and no proposed decision is pending; under four-eyes review they are also limited to users with Screening — level 1 or level 2. Each opens a dialog — Accept transaction, Reject transaction or Revert transaction — asking for your assessment, at least 20 characters, which you confirm with Confirm Accept (Reject, Revert). The assessment is stored as the request's audit trail and written to case management: the request's ticket receives it as a comment headed Decision: Accept (Reject, Revert); when the request has no ticket yet, one is created, titled Transaction ID: followed by the identification, with the transaction summary and the decision in its description.

After any decision, you are automatically returned to the transactions list. If the decision is recorded but its assessment could not be added to case management, you stay on the request and an error message says so.

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 All tab under Alerts), 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, or to Sanctions screening if no module flagged the request.

After Create, the ticket is linked to this request and shown on the page in place of the button. It also appears in the lists under Alerts 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 Alerts, 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 require the Case management (write) permission (see User management) and a ticket owned by your institution; whitelisting a name requires Screening — level 1 or level 2 instead, again on 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. Copy places it on the clipboard.

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. Each line carries its time, its source in brackets — Screening, the module's name, Supplementary Data with the record's type and id, or Webhook for what was reported to your systems — and the message, in one timeline.

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 collapsible Supplementary Data section that counts the submissions, and EFI screens each submission on its own and shows an ALLOW or BLOCK decision for it. Each submission is listed with its data type, status, decision, id and creation time; expand it to see its Alerts, the Cleared matches your whitelist suppressed, and its Data fields (with a Copy button).

Supplementary data has no configuration of its own — it is screened using the modules you have already set up in your screening flow. Each submitted value — every plain field and every AML-tagged value — is run through the modules that apply to its type, 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.

Free-text values — plain fields and AML tags mapped as Free Text — are also scanned by the Activity Check keyword dictionaries of the modules wired into your flow; a match is listed as an ACTIVITY alert naming the term and category, and always blocks the submission. 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 and then goes straight to Pending user decision: the request stays open, accepting supplementary data, until someone on your team decides it.

A blocking alert flags it, but does not close it. If the MT799 message itself is blocked, or any supplementary submission comes back Blocked, the request's system decision is set to Block so the hit is visible when you review it. The status does not change — it was already pending your decision — and the request still accepts more supplementary data. Once flagged it stays flagged — a later clean submission does not clear it, 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 pending your decision. Use the Pending user decision status filter to find everything waiting on you; the clock icon next to a row's status (hover it: Awaiting supplementary data. Remains open until a decision is recorded.) tells you which of those are MT799s still collecting supplementary data.

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, vessel and the keyword-based Activity Check — 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 — your institution's own prohibited-countries list, maintained by Elucidate.
• OpenSanctions — continuously-updated global sanctions datasets and the PEP (Politically Exposed Person) collection. It is queried alongside the built-in index for every screening, restricted to the lists you have selected, through its own matching engine.

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.

A value that a message does carry but that no field reads, such as a second narrative, a reimbursement agent or the ultimate creditor, is not screened either unless you switch on Screen all other message fields.

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 goes straight to Pending user decision and 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.

Screening all other message fields

The fields in the table above are the values EFI maps out of each message type, and a message usually carries more. An MT103 that has both :70: and :72: screens only :70: as its narrative, and the regulatory reporting in :77B: is never read. A pacs.008 can name an ultimate creditor (UltmtCdtr) or a settlement reimbursement agent (InstgRmbrsmntAgt) that no field reads at all. Tick Screen all other message fields in the External Screening settings to screen the rest of the message as well. The option is off by default, and switching it on changes nothing about the fields above.

What EFI reads

• MT messages, of any type: every field in the message text (block 4), including a tag that appears more than once, plus the sending and receiving bank BICs from the message headers (blocks 1 and 2). The optional user header and trailer (blocks 3 and 5) are not read.
• pacs messages: every element that holds a value, in the business application header (AppHdr) and in the message itself. A repeated element is numbered, so the second unstructured remittance line ends in RmtInf/Ustrd[2].

Values that can never name a party are left out: amounts, balances and exchange rates, dates and times, counters, and fields limited to a fixed list of codes. For MT these are:

• Amounts and rates: :19:, :32A:, :32B:, :32C:, :32D:, :33A:, :33B:, :34A:, :34B:, :34F:, :36:, :60F:, :60M:, :62F:, :62M:, :64:, :65:, :71F:, :71G:, :90C: and :90D:.
• Dates and times: :13C:, :13D:, :30:, :31C:, :31E:, :31L:, :31S: and :44C: (latest date of shipment).
• Counters and tolerances: :11R:, :11S:, :26E: (number of amendment), :27: (sequence of total), :28:, :28C:, :28D: and :39A: (credit amount tolerance).
• Code lists: :12:, :22A:, :22D:, :22G:, :22Y:, :23B:, :23H:, :23S:, :26T:, :40A:, :40B:, :40D:, :43P: and :43T: (partial shipments, transhipment), :48B:, :48D:, :49: (confirmation instructions) and :71A:.

For pacs they are the date, time and date-time elements (creation, settlement, acceptance and pooling-adjustment dates, the settlement time indications and requests, dates of birth and of related documents), the amount, rate and counter elements, the currency, the booleans (BtchBookg and the garnishment indicators), code values (Cd, ChrgBr, SttlmMtd, SttlmPrty, InstrPrty, ClrChanl, CdtDbtInd, DbtCdtRptgInd, NmPrfx, PrefrdMtd), NbOfTxs, UETR, MsgDefIdr and BizSvc.

What is skipped because it is already screened

A line of an MT field, or a pacs element, is skipped when it only repeats a value that one of the fields above already holds: a party name or address, a bank name or BIC (originator, beneficiary or intermediary) or the transaction message. A line only repeats a value when every word in it, ignoring numbers and single characters, appears in that one value. BICs are compared by bank office, so BANKDEFF, BANKDEFFXXX and the 12-character header address of the same office count as one bank. In an MT103 :50K:, for example, the name and address lines are skipped and only the account line is left for this option.

Skipping keeps each value under the setting that owns it. The fields above keep their own switches and their own whitelist entries, and a field you have switched off, such as Beneficiary Address, stays off: this option does not pick it up again.

Shipping places are the exception. The Shipping Information check only screens the country resolved from each place, so the place names themselves are screened here as text.

The request logs list the fields that were skipped as already screened, and the ones that held nothing to screen (only numbers or common words).

How each field is screened

• Text: as described in Match on free text, with windows of consecutive words, the noise filter, the reverse lookup, country names found in the text, your blocklist and your stop words.
• BICs: a BIC line in a party or institution field in option A or in :41F: (the bank a guarantee is available with, in an MT760), the header BICs, and the pacs BICFI and AnyBIC elements are screened like the FI ID fields, on the BIC prefix and on the country code inside the BIC. Most of these banks are already read by the FI ID and intermediary fields and are skipped; what is left are banks no field names, such as a reimbursement agent. A line in an option A field that is not a valid BIC, such as a bank name typed into it, is screened as text.
• Country codes: the pacs Ctry, CtryOfRes and CtryOfBirth elements are checked exactly against the country records of your selected lists, the same check as a country resolved from an address.

Reading the results

Each field screened this way gets its own row in the External Screening details, under Alerts, Whitelisted or No matches. The row shows a readable name for the field followed by where it sits in the message: an MT tag, as in Sender to Receiver Information :72:, or a pacs element path, as in Ultimate Creditor › Name FIToFICstmrCdtTrf/CdtTrfTxInf/UltmtCdtr/Nm. The tag or path is always exact; the name is only a label. The Match summary and the audit report name the field the same way.

An MT field is named the way SWIFT names it in that message type, because the same tag means different things in different messages. :57A: is the Account With Institution of an MT103 but the 'Advise Through' Bank of an MT700, and :50: is the Applicant of an MT700 but the First Beneficiary of an MT720. In a guarantee, :24E: is named after its sequence: the delivery of the original or of the local undertaking. In an MT202 COV or MT205 COV, the underlying customer's :59: is the Beneficiary Customer, as in an MT103. The name is saved with the result, so a request keeps the name it was screened with.

A hit on a message field counts like any other hit. It blocks the transaction, or raises a warning when the module's On hit is set to warn, unless it is whitelisted. A blocklist match makes it an override, as for any other field.

For a hit on a text field, Add to whitelist creates a stop word for the matched phrase, the same as for the transaction message. BIC and country hits on these fields have no Add to whitelist button, and only a whitelist entry scoped to all fields suppresses them.

Example. An MT103 pays a clean beneficiary. Its :70: reads /INV/2026-0415 OFFICE EQUIPMENT and its :72: reads /INS/BANK MELLI IRAN. Without the option only :70: is screened and the payment is allowed. With it, :72: is screened as text and the payment is blocked on Sender to Receiver Information :72:, matching Bank Melli Iran.

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 listed name's word, so that short words are matched strictly and long words more leniently. The budget is measured on the listed word, not on the word in the message, so a typo that drops a letter counts the same as one that adds a letter, and a listed word of 4 characters or fewer is only found when written exactly:

This length-based tolerance governs the built-in watchlist, and also re-checks every OpenSanctions candidate for transaction names, free-text, vessel and country values. It does not apply to customer screening, where a customer name is sent to OpenSanctions 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 name, country and vessel screening. Customer screening is the exception: a customer name is sent to OpenSanctions as one whole 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; when no account record is known, the name written in the transaction is used.

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 — for a transaction name, the value is split on punctuation and searched as a legal entity (person, organisation or company) and as a vessel, and every candidate the engine returns is re-checked word by word with the edit-distance filter above. For customer records and AML-tagged Name values, the whole name is sent as a single entity and the engine returns only the candidates it judges a match: 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 produces no 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. For customer records and AML-tagged Name values, which are scored as one whole entity, EFI trusts this decision directly; transaction names, like free text, still go through the word-by-word edit-distance filter.

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 — to the paying and receiving party addresses, and to any free-text values submitted as AML-tagged or supplementary data. (Addresses are additionally resolved to a country and checked against your country lists — see Match on countries.) With Screen all other message fields on, it also applies to the text of every other message field.

These fields contain unstructured prose, so rather than screen each word on its own, EFI screens overlapping windows of consecutive words — every run of two, three and four adjacent words (the two-word minimum is 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, and a four-word window reaches a long company name that none of its two-word fragments would.

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 Manual Screening & 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. (In Fuzzy mode this comparison tolerates the same edit budget as matching; in Exact mode it is literal.)

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, beneficiary or financial institution 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. The entry goes into a pending review state ("Name submitted for review") and only begins suppressing hits once two other reviewers (Screening — level 2 or an administrator) have accepted it.

How a stop word behaves once active

• Word-precise — it only removes hits triggered by that exact word, matched one to one with no tolerance for spelling variants. 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 — the whitelist a stop word belongs to can be limited to specific source lists. If it is, its entries only suppress hits from those lists; hits from other lists still surface.

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 Activity Check module has its own exclusion terms. Those are configured per keyword category and stop a category term from counting as a hit where it is part of a longer, legitimate phrase in the same value. Exclusion terms are a module configuration, whereas stop words are whitelist entries you add from a ticket — keep the two concepts separate.

4. Whitelisting a name or a bank identifier

Stop words cover the free-text fields. For the structured fields the same Add to whitelist button appears on each hit in the module's run information — on the originator and beneficiary names, on the originator and beneficiary FI names, and on the originator, beneficiary and intermediary BICs — and opens the dialog described in Whitelisting a screened name with the screened value filled in.

• A party name can be whitelisted on its own or tied to the account it was paid from or to.
• An FI name or a BIC is always whitelisted on its own, since a financial institution has no account on the transaction. The entry is stored with the names or bic scope, so it can never clear a hit on another kind of field.
• A whitelisted BIC clears both hits that BIC produced: the match on the bank itself and the prohibited-country hit on the country code inside the BIC. Any other BIC from that country still blocks — the country code is never whitelisted, only the one bank identifier, exactly as written. A different branch code of the same bank needs its own entry, and when several intermediaries share one prohibited country, every one of them must be whitelisted before that country hit clears.

Every entry added this way starts as pending and begins suppressing hits only once two other reviewers (Screening — level 2 or an administrator) have accepted it; the person who added it cannot approve it.

Match on countries

Country checks on ISO codes, from resolved addresses, shipping places and BICs, are exact list membership: a code either is or is not on a configured list. Country names found in free text as separate words are matched with your Exact/Fuzzy setting; a country name found inside a longer word is matched letter for letter. Punctuation, apostrophes and spacing between initials are ignored on both sides of every country comparison, so D.P.R.K. and Democratic Peoples Republic of Korea find North Korea.

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 country records of your prohibited-countries list. This path only performs country-type matching and does not call OpenSanctions.
• Free text (watchlist) — the transaction message, the party addresses, and free-text or country-tagged AML / supplementary values are also scanned for sanctioned countries, in two ways:
• every one-to-three-word phrase is compared against the country lists with your Exact/Fuzzy setting, 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;
• every country name on your lists — including its translations and alternative spellings, but never the two-letter codes — is also searched for inside words, so text typed without a space is still caught: 123 ROADRUSSIA hits Russia and TEHRANIRAN hits Iran. This search is letter for letter whatever your Exact/Fuzzy setting (case is ignored, accents are not) and has no minimum length, so a short name can also fire inside an unrelated word — KUBATBEK contains kuba (Cuba in German) and MALIKA contains mali. Where names overlap, the longest wins, so SOMALIA is reported as Somalia only, not also as Mali. The hit records the whole word the name was found in (ROADRUSSIA) as the matched value, so whitelisting that word clears only that word and a genuine RUSSIA elsewhere still alerts.
• every run of up to three words is also compared with all spaces and punctuation removed, so D.PR.K. or D P RK still finds North Korea.

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 runs alongside the free-text screening of the address itself (see Match on free text). 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 a normalised variant. For an IMO number that is the IMO-prefixed form (e.g. 9274446 also tries IMO9274446), so an IMO number matches whether or not the IMO prefix is present. For a vessel name carrying a vessel-type prefix (MV, M/V, MV., M.V.) it is the bare name (e.g. MV PEGAS also tries PEGAS), so a vessel written in standard maritime format still matches the listed name.
• 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.

Match on activity terms (Activity Check)

The Activity Check module works differently from everything above: it consults no sanctions or PEP list. By default it scans the transaction message — the free-form narrative — for the keywords you maintain in categories such as Gambling, Narcotics or Military, so it catches what a payment is for. The module's Fields to check can add the party names and addresses, the bank and intermediary bank names, the shipping places and — with Check all other message fields — every other free-text MT tag or pacs element, each value scanned on its own. BICs, country codes and amounts are never scanned; a transaction with nothing in the ticked fields simply produces no hit. Configuring the module is described in The Activity Check module; the matching rules are these:

• Case-insensitive in every mode.
• One matching mode for the whole dictionary, chosen in the module settings:
• As string — The term appears anywhere in the message as a substring (cash matches CASHEW).
• Full words only — The term appears as a whole word or phrase, bounded by spaces, punctuation or the text boundaries (cash does not match CASHEW).
• Fuzzy — Message and term are lower-cased, accent-stripped, split into words, and the term's words must appear consecutively and in order. Each word tolerates typos by length: none under 5 letters, one for 5–8, two over 8 — the same tolerance as fuzzy sanctions matching.

• Use regex — Each term is a regular expression searched anywhere in the message, ignoring case; word boundaries must be written into the pattern.

• Exclusion terms are configured per category and matched with the same mode, but without typos in Fuzzy mode. An exclusion term only excuses the term it contains: with casino royale as an exclusion, the casino inside it is not a hit, but another casino in the same value still is. Whitelist stop words never apply to this module.

• Every matching term is a separate hit recording the term, its category, the field it came from (a message field shows its MT tag or pacs path) and the scanned text; all hits are shown in the module's detail view, with the matching words highlighted, and logged as "found match on <term>, <category>". Screening level 1 and level 2 users can remove the term or add an exclusion term from the detail view (see The Activity Check module).
• Outcome follows the module's on_hit setting: a Block (HIGH risk score, transaction stopped pending a decision) or a Warning (MEDIUM). A Remember manual decision configuration can downgrade a Block to a Warning when enough past blocks for the same party were manually allowed. Cases opened from an Activity Check block carry the Activity Check category.
• Supplementary data is scanned with the same dictionary: every plain field and every AML-tagged value mapped as Free Text is checked (name, country, BIC and vessel tags are not), a match is listed on the submission as an ACTIVITY alert, and any activity match makes the submission Blocked regardless of on_hit. Values are scanned one at a time, so an exclusion term only excuses a term within the same value.

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.