Support Portal

The All Transactions page is your central view for managing screening requests — individual payment messages that EFI has checked against sanctions lists, PEP databases, and risk rules. Use it to review screening outcomes, investigate flagged transactions, and submit new requests for screening.

Navigate here via the All Transactions tab in the case management area.

Understanding screening results

Each row represents a single screening request. The key columns to watch are:

Click the magnifying glass icon on any row to open the full request detail, where you can see module-level results, the raw message, and take action.

Taking action on a request

From the request detail page, the action buttons on the right side determine the final outcome:

• Accept — Approve the transaction (sets client decision to ALLOW)
• Reject — Block the transaction (sets client decision to BLOCK)
• Revert — Labelled Revert (Postpone); records a revert decision on a request awaiting review, finalising it and (if a webhook is configured) notifying your systems
• Case management — Escalate the transaction to the case management workflow for further investigation

The Screening info section shows the system's automated assessment, including the risk score (LOW, MEDIUM, HIGH). The Module results table breaks down which screening modules ran and whether they raised blocks or warnings.

Searching and filtering

Use the search bar to find specific transactions by typing a value and selecting a search field from the dropdown (e.g., Identification, Originator Name, Beneficiary Name).

The Filter panel provides multi-criteria filtering:

• Status and Decision — narrow down by processing state or outcome
• Client decision — filter by your organisation's override decisions
• Message Type — filter by message type: MT103, MT202, the MT700 documentary-credit series, the other MT categories (MT199/299/499/599/799/999), and MX (ISO 20022)
• Modules — show only transactions flagged by specific screening modules: Watchlist Screening, PEP Check, Country Check, Activity Check, Incoherence, Missing Data, and FinCrime Index
• Transaction date range — restrict results to a specific time window
• Originator/Beneficiary FI id — filter by the financial institution identifiers involved

Active filters persist in the URL, so you can bookmark or share filtered views. Click Reset filters to clear all criteria.

Submitting new screening requests

Click Add new to open the submission modal. There are two ways to submit:

Single Message

Paste a raw SWIFT MT message (for example MT103, MT202/MT202-Cov, or one of the MT700 documentary-credit types) or an ISO 20022 pacs.008 XML message directly into the text area. Provide an Identification value to track the request and select the appropriate Message Type from the dropdown (or leave it to be detected from the message header). The example panel on the right shows the expected message format.

File Upload

Upload a batch of transactions as a file. Supported formats include:

• CSV (Simple) — 9 columns covering originator, beneficiary, amount, and currency
• CSV (EFI v2.0) — 24 columns with full transaction details (see the Elucidate Data Protocols link for the specification)
• Excel (.xlsx) — with id and pacs body columns (pacs.008 XML per row)
• XML — raw SWIFT/ISO 20022 XML messages

After uploading, click Upload & Process to submit the batch. Uploaded files and their processing status appear on the Screening Files page.

Exporting data

Click Export to download screening request data. Choose between CSV and Excel format, select which columns to include, and optionally limit the number of records. The export respects any active filters — only matching records are included.

Building the screening flow

Click Flow to open a full-screen editor that shows your screening configuration as a visual node graph. This is where you decide which checks run on every incoming transaction and in what order. Changes are saved directly from within the editor.

Every transaction enters at Transaction received (green) and flows downward through each connected module until it reaches Risk Scoring, which routes the transaction to one of two final outcomes: Accept (green) or Block (red). The modules in between are the checks that run on each transaction. The path does not have to be a single straight line — a Router module (shown in orange) can branch the flow so different transactions follow different paths (for example, a stricter branch for higher-risk payments and a lighter branch for the rest).

To change the pipeline:

• Add a module — drag one of the cards from the Available modules panel on the right onto the canvas, then connect it into the chain by drawing a line between the small connector dots on each node.
• Reorder or rewire — drag the connection lines to change which module feeds into which.
• Configure a module — click any module node to open its settings panel (see below).
• Save — click Save configuration (top-left). Nothing takes effect until you save. Use the zoom and fit-to-screen controls at the bottom-right to navigate larger flows.

The Available modules panel lists the checks you can add: Activity check, External Screening, Adverse Media, Customer Scoring, Transaction Scoring, Elucidate FinCrime Index©, Portfolio Assessment, Historical Coherence, and Router. Fraud appears only in demo environments. A module only runs if it is placed on the canvas and connected into the flow.

Saving when four-eyes review is enabled

If your institution requires four-eyes (maker–checker) review of screening configuration, saving the flow does not apply your changes straight away. Instead the whole edit — any modules you added, removed, or rewired — is submitted together as a single change request, and a banner appears reading "A flow change is awaiting approval." While that request is pending, the editor is locked so no one can start a conflicting edit.

A different user then opens View proposed changes and either approves it — at which point the flow updates and unlocks — or rejects it, leaving the current flow unchanged. You cannot approve your own change; that second pair of eyes is the point of the review. If you simply drag nodes around to tidy the layout, that is not a reviewable change and is saved directly, without creating a change request.

Settings shared by every module

When you open any module, the top of its settings panel has three controls that behave the same across all module types:

• Name — a label for this node, so you can tell apart multiple modules of the same type.
• On hit — what happens when this module flags a transaction: warning (records an alert but lets the transaction continue) or block (stops the transaction). Until you choose, it shows Select action.
• Remember manual decision — when enabled, EFI learns from past manual reviews. Set the Match side (Originator, Beneficiary, or Beneficiary + Originator) and a Matches threshold. If reviewers have previously allowed this many transactions where this module triggered on the same party, EFI applies that decision automatically next time.

The External Screening module

External Screening checks the parties on a transaction against sanctions, watchlist, and PEP (Politically Exposed Person) sources. Add it to the flow from the Available modules panel, then click it to open its settings.

Which parties and fields to screen

• Enrich name from account number — when ticked, EFI looks up historical information tied to the account number to find the best name to screen, rather than relying only on the name written on the transaction.
• Beneficiary fields — choose what to screen on the receiving party: Beneficiary FI id, Beneficiary Name, Beneficiary Address.
• Originator fields — the same choices for the sending party: Originator FI id, Originator name, Originator Address.
• Transaction Message — also screen the free-text content of the payment message itself.
• Shipping Information — in trade-finance messages, screen the ports and routes (matched as countries).
• Originator FI name / Beneficiary FI name — screen the names of the sending / receiving financial institutions, in addition to their BICs.
• Screen intermediaries — extend screening to intermediary banks in the payment chain, not just the originator and beneficiary.
• Screen single words — break names into individual words and screen each separately, which catches matches that a full-string comparison would miss.

Match type

Match type controls how strict name matching is:

• Exact — only flags when the name matches the list entry closely. Fewer false positives, but can miss spelling variations.
• Fuzzy — also flags approximate and misspelled matches. Catches more, at the cost of more alerts to review.

### How name matching works

Match type is the switch; this is what it turns on underneath. Screening runs in two stages. A fast search retrieves candidate records that could plausibly match, then every candidate is re-checked word by word before it is shown to you.

Stage 1: retrieving candidates

Before anything is searched, the screened value is expanded into several queries: the whole value, each of its words (split on every non-alphanumeric character, so BUYER:ROSNEFT also searches BUYER and ROSNEFT), and, for long names, a first + last pair. A query is only ever added, never removed, so expansion can only widen coverage.

Each of those is then looked up against your selected lists three ways at once:

• Whole-value exact lookup: compared against pre-computed hashes of each record's name, catching a byte-for-byte identical name instantly.
• Lowercased term lookup: the same comparison, case-insensitive, so ROSNEFT, Rosneft and rosneft are equivalent.
• Edit-distance lookup: in fuzzy mode only, spelling variants within an allowed number of single-character changes.

Stage 2: the word-level re-check

Every candidate the search returns is re-checked before it becomes a hit. Both the screened value and the candidate name go through the same normalization: lowercased, accents and diacritics stripped (Müller becomes muller, café becomes cafe), then split into words on every non-alphanumeric character.

Then every word of the screened value must line up with a word of the candidate name, exactly in exact mode, or within an edit budget in fuzzy mode. Order doesn't matter. If a word cannot be accounted for, the candidate is dropped.

An edit is one character inserted, deleted or substituted. The budget scales with word length, so short words are matched strictly and long words more leniently:

So Qaddafi (7 characters, one substitution) catches Gaddafi, and Catherine (9 characters, two edits) catches Katherina, while a 4-letter word must match exactly. The budget is deliberately tight: Mohamad and Mohammed differ by two edits and, at 7 characters, are not matched. Swapping two adjacent letters (Bahar vs Bahra) also counts as two edits, not one.

Scripts and transliteration

Matching against your custom watchlists and the built-in list index is script-preserving. Text is compared in the script it arrives in.

• Latin script, any accents: the word-level re-check folds diacritics away, so an accented spelling is never rejected there. Retrieval itself is literal. In exact mode the value must be spelled with the same characters, while in fuzzy mode an accent difference costs one edit and is absorbed by the budget above.
• Non-Latin scripts (Cyrillic, Arabic, Greek, Hebrew, CJK): matched within the same script. A Cyrillic name in a payment message is matched against the Cyrillic spellings held on your lists.
• Across scripts: a name written Путин is not automatically converted to Putin before searching. No romanization step is applied to your custom watchlists or the built-in index.

Where the external matching engine is enabled for your account, name screening against the official sources additionally uses an engine built for cross-language work, which does bridge scripts. Rather than blanket-converting everything to Latin, which loses precision for scripts whose romanization is ambiguous, it keeps comparisons in the native script and links spellings through curated multi-lingual reference data. A single entry for a given name collects its Latin, Cyrillic, Arabic, Hebrew, Armenian and CJK spellings, and a single entry for a company type treats OAO, Joint Stock Company and Aktiengesellschaft as the same concept. Name parts are also aligned by role, given names comparing to given names and family names to family names rather than the two being run together, which keeps unrelated people who share a common given name apart. This applies to the Name and FI id fields. Transaction Message, Shipping Information and vessel values are matched with the word-level rules above.

Practical consequence. If your traffic carries names in Cyrillic (or Arabic, or CJK) and you also want them caught against Latin-script entries on your own watchlists, add both spellings as separate entries: Путин and Putin. Two entries cover both directions reliably.

Phonetic ("sounds-like") matching

Phonetic matching is a different technique from the edit-distance matching above. Each word is reduced to a code representing how it sounds, Metaphone and Soundex being the common schemes, and two names match when their codes agree.

EFI does not use phonetic matching. Phonetic codes sort names into coarse buckets, so they raise alert volume without improving the decision, and a code match is difficult to justify to a reviewer or a regulator because it cannot show what actually differed between the two names. An edit-distance hit always traces back to a specific word and a specific number of character changes. The technique is bounded by script in any case: Soundex and Metaphone work on the Latin alphabet only, and no phonetic scheme has anything to offer for non-alphabetic writing systems such as Chinese, Japanese, Korean or the Indic abugidas.

Choosing the lists to screen against

Official Lists is a scrollable checklist of the public sanctions and PEP sources you can screen against. Tick the checkbox next to each source you want to include, choosing only the lists relevant to your compliance obligations. It covers the major consolidated sanctions lists (UN, EU, US OFAC SDN and non-SDN, UK FCDO, Swiss SECO, Australia DFAT, Japan, and others), national and terrorism lists, PEP databases, and UN country sanctions.

Sanctions and PEP sources record names in more than one alphabet. A Russian entity is typically listed in both Cyrillic and Latin, an Iranian one in Arabic and Latin, a Chinese one in Han characters and Latin, but coverage is uneven, and not every record carries every script. Because matching is script-preserving (see Scripts and transliteration), a value is only compared against the spellings held in the same alphabet. For romanized SWIFT traffic this means you are matching the romanized spellings on the list.

Custom Watchlists lets you screen against your own internal lists in addition to the official ones. Each custom watchlist you create appears in this panel, labelled with its type — for example Test (whitelist) or Internal exclusion (blocklist) — and can be ticked on alongside the official lists. Click + add new item to create one, click an existing watchlist to open its details, or use the bin icon to delete it.

The Activity Check module

Activity Check scans a transaction for terms that indicate prohibited or high-risk activity — for example narcotics, gambling, or wildlife trade — organised into categories of terms you maintain yourself.

A single matching mode selector controls how terms are compared — pick one of four options:

• As string — match the term wherever it appears in the message text (a substring match).
• Full words only — match a term only when it appears as a whole word, so cash won't match cashew.
• Fuzzy — also match small spelling variations of the term.
• Use regex — treat each term as a regular expression, for advanced pattern matching.

Below that are up to three linked columns:

• Category — your groups of terms (e.g. gambling, military, narcotics). Click a category to select it and show its terms; click + add new category to create one, or the bin icon to delete one.
• Terms — the words or codes that belong to the selected category. A transaction that contains one of these terms triggers the module. Click + add new term to add to the selected category.
• Exclusion terms — terms that cancel a match for the selected category, used to suppress known false positives. Click + add new exclusion term to add one.

Bulk-importing categories with a CSV

Instead of typing categories one at a time, click Upload CSV to import several at once. The file needs three columns — category, terms, exclusion_terms — with one category per row. Separate multiple terms within a cell using a semicolon (;), and leave the exclusion_terms cell empty if a category needs none.

How the import behaves is important:

• It adds; it never overwrites. Uploaded categories are appended to what you already have — your existing categories and their terms are left untouched. There is no "replace all".
• Category names must be new. If any category in the file has the same name as one that already exists, the whole upload is rejected with a message listing the clashing names, and nothing changes. To grow an existing category (say, add more terms to Military), edit it directly in the columns above, or rename/delete it first and then re-upload.

Click Save configuration to apply your changes.

The Router module

Router doesn't screen anything itself — it directs each transaction down a different branch of the flow based on its attributes. Use it to apply different checks to different transactions (for example, route payments from a particular country through stricter modules).

The module is a list of Routing Rules, evaluated top to bottom. The first rule whose conditions match decides where the transaction goes; if no rule matches, the Default target is used.

Each Rule has:

• One or more conditions, each made of a field, an operator, and a value. Fields are grouped into Transaction (Amount, Currency, MT Type, Originator/Beneficiary Country, Originator/Beneficiary FI Country, Originator/Beneficiary FI ID), Request (Message Type), and Customer Sender/Receiver attributes. Operators include =, ≠, >, ≥, <, ≤, in list, and not in list.
• + Add condition to combine several conditions. When a rule has more than one condition, a Logic selector (AND / OR) controls how they combine.
• A Target — the module the transaction jumps to when the rule matches.
• Controls to reorder the rule (▲ / ▼) or remove it (✕). Rule order matters, because evaluation stops at the first match.

Click + Add Rule to add another rule. The Default target at the bottom sets where transactions go when no rule matches — choose a module, or None (skip remaining modules) to send them straight on. Click Save configuration to apply.

Creating a custom watchlist

Clicking + add new item opens the Create New Watchlist dialog.

A new watchlist is created with a pending review status. Click Create Watchlist to save, or Cancel to discard.

Whitelist vs Blocklist

The Type determines how the watchlist affects screening:

• Whitelist — entries on this list are treated as known-good. A match against a whitelist clears the party, suppressing what would otherwise be a false-positive alert. Whitelists can override specific official sources (via Override Sources) or apply generically (Is Generic).
• Blocklist — entries on this list are treated as known-bad. A match against a blocklist flags the transaction. Blocklists have no Override Sources or Is Generic options — they simply add your own names to screen against.

Viewing and editing a watchlist

Clicking a watchlist in the Custom Watchlists panel opens Watchlist Details.

The Watchlist Information section shows the watchlist's Name, Type, Is Generic, Override Sources (for non-generic whitelists), Description, Matching %, and review Status (accepted, pending, or rejected). Hover over any field and click the pencil icon to edit it inline, then Save.

Below that, the Entries section manages the actual names on the list, split into two groups:

• Pending Entries — changes awaiting review.
• Processed Entries — changes that have already been reviewed (accepted or rejected).

Click Add new to propose a new entry.

Adding a watchlist entry

The Add Watchlist Entry dialog proposes adding one or more entries to the list. (To change or remove an existing entry, use the Edit button on its row instead — the Add dialog only adds.)

Click Save to submit. The entry is created with a pending status and appears under Pending Entries until it's reviewed.

Reviewing entries

The Pending Entries and Processed Entries tables share the same columns:

Pending Entries holds changes still awaiting review; Processed Entries holds those already accepted or rejected. In the Processed Entries table the Action, Proposed At, Reviewed At, and Status columns are sortable. Use the Edit button on a row to change that entry.