Support Portal

The 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.

Open it from Screening > Transactions.

Understanding screening results

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

The other columns are Identification, Message identifier, Error Code, Last Update, Amount, Currency, Txn Created At, Txn Date and, for the originator and the beneficiary, Acc. No., Full Name, Country and FI ID (plus FI Country for the beneficiary). Status, Decision, Message identifier, Last Update, Txn Created At and Txn Date can be sorted by clicking their headers. A clock icon next to the status marks an MT799 still collecting supplementary data (hover it for the explanation). The list shows 100 requests per page and refreshes by itself — every second right after a page load or a new request, then at growing intervals up to every five minutes — while the tab is visible and no dialog is open.

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. Hold Ctrl (Cmd on a Mac) while clicking the icon or the row to open it in a new tab; a plain click on the row only highlights it.

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 — Records a revert decision on a request awaiting review, finalising it and (if a webhook is configured) notifying your systems. Shown only where Revert is enabled for your institution
• 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.

Four-eyes approval of decisions

If Elucidate has switched on four-eyes review for your institution, Accept, Reject (Block) and Revert are not applied straight away — they need a second person:

1. Propose. A user with Screening — level 1 or level 2 chooses the decision and enters their assessment. The transaction stays in USER_PENDING, its client decision shows DECISION_PENDING, and a Pending approval panel on the request names the proposed decision and who proposed it. Nothing is sent to your bank system, and no other decision can be proposed while one is pending. Level 2 users are notified.
2. Review. A different user with Screening — level 2 opens the request, or the Decision queue section of Screening > Pending approvals, and chooses Approve or Reject. The person who proposed the decision never sees these options, even if they hold level 2; level 1 users never see them.
3. Approve. The transaction completes, the decision is sent to your bank system, and both people are recorded: the request log reads proposed by … approved by …, and the audit report lists Decision made by and Decision approved by.
4. Reject. A reason is required. The proposal is discarded and the transaction goes back to the open queue as if no decision had been made; the rejection and its reason are written to the request log, and a new decision can then be proposed and approved by any valid pair of users.

The Decision queue lists every decision awaiting approval. Tick Show closed requests to also see approved and rejected ones with their reviewer and reason.

Searching and filtering

Use the search bar to find specific transactions: type a value, pick the field from the Search field dropdown — Identification, Originator account no., Originator full name, Originator country, Originator address and the same four for the beneficiary — and click Search or press Enter. The bin icon clears the search.

The Filter panel provides multi-criteria filtering:

• Status — Queued, Processing, Pending user decision, Completed, Error
• Decision — Allow, Block, No alert, User decision
• Client decision — Allow or Block, 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

Message Type and Modules are dropdowns that read All types / All modules until you tick something. Nothing applies until you click Apply; Clear filters empties the panel. Active filters persist in the URL, so you can bookmark or share filtered views. Click Reset filters in the toolbar 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 — MT103, MT202 / MT202-Cov, the MT n99 and MT7xx types, Generic Swift MT message or pacs.008.001.08 — or leave it to be detected from the message header. The example panel on the right shows the expected message format; click it to fill the form with the example. Click Submit. If the identification is empty, a prompt offers a timestamp instead — click it, or click Submit again to accept it.

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. A toast confirms File uploaded and processing started.; the requests appear in the list as they are created (the list refreshes by itself).

Exporting data

Click Export to download screening request data. Choose between CSV and Excel format and select which columns to include. Number of records starts at Limit to 100 records; choose All records for everything — at most 10,000 per export. The export respects any active filters — only matching records are included. Click Download. Where Google Sheets export is enabled for your environment, a Google Sheets button sends the same selection to a sheet instead of downloading a file.

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).
• Remove a module or a line — select it and click Remove node or Remove edge in the right panel (confirm with Yes), or press Backspace. The fixed nodes cannot be removed.
• Save — click Save configuration (top-left; the button appears as soon as you change something). 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.

The banner offers View proposed changes to everyone — it lists what approving would change in plain words above the full diff — and Approve / Reject to a different user with Screening — level 2: approving updates and unlocks the flow, rejecting (a reason is required) leaves the current flow unchanged. You cannot approve your own change; that second pair of eyes is the point of the review. The person who proposed the change can withdraw it with Cancel change. Change history, at the bottom-left of the editor, lists past change requests. 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; Deactivated switches it off) and a Matches threshold (3 by default, at least 1). When this module blocks a transaction, EFI counts the completed requests for the same party (same originator account, beneficiary account, or both, depending on the match side) that a module of this type also blocked and that a reviewer then manually allowed. If that count reaches the threshold, the block is downgraded to a warning and the result is marked as a remembered decision — the transaction is not allowed outright, it just stops hard-blocking.

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 screens the name held on the account record matched by the account number instead of the name written on the transaction. If no account record is known, the name on the transaction is screened.
• 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. A bank named without a BIC is screened by name even when this is unticked, since the name is then its only identifier.
• Screen intermediaries — extend screening to intermediary banks in the payment chain, not just the originator and beneficiary.
• Screen all other message fields: also screen every MT tag and pacs element that the options above do not read, for example field :72: of an MT103 that also carries :70:, or the ultimate creditor of a pacs.008. Each result shows the tag or element path it came from. Parts of the message the options above already screen are skipped, and an option you have switched off stays off. Off by default. See Screening all other message fields.

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; its separate words when they are glued together by punctuation (BUYER:ROSNEFT also searches BUYER and ROSNEFT); and a first + last pair for names of three or more parts. A query is only ever added, never removed, so expansion can only widen coverage. Message and address text is handled differently: it is screened as every run of two to four consecutive words, after windows made only of common words or numbers are discarded (see Free-text matching).

Each of those is then looked up against your selected lists. In exact mode a query is compared, case-insensitively, against the whole stored name, so ROSNEFT, Rosneft and rosneft are equivalent. In fuzzy mode it is compared against stored names within an allowed number of single-character changes over the full string. A value submitted as a pre-computed hash is matched against the stored digests of each name instead.

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 the words are compared. In exact mode the screened value and the candidate must consist of exactly the same words, in any order. In fuzzy mode every word of the screened value must line up with a word of the candidate name within the edit budget, and the candidate may carry extra words. 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

Two engines are involved, and which one applies depends on where a list comes from. Lists delivered through OpenSanctions, which is where the official sanctions and export control lists come from, are searched through the OpenSanctions engine. Lists maintained by Elucidate and your custom watchlists are matched against the built-in list index.

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.

For the lists delivered through OpenSanctions, that engine proposes the candidates, including entries whose listed names or aliases are written in another script. Each candidate is then accepted or dropped by the same word-level re-check described above, against the names and aliases the entry carries. Nothing is transliterated: a Cyrillic value in a payment matches a listed party when that party carries a Cyrillic spelling, which the official sources record for most Russian parties, but a party listed only in Latin is not found from a Cyrillic value. Customer records, screened on submission and by the scheduled re-screen, are decided by the OpenSanctions engine itself, which does link spellings across scripts. This applies to the Name field. FI id values are matched on the first six characters of the listed BIC. 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 sanctions and PEP sources you can screen against, for example UN Security Council Consolidated Sanctions, US OFAC Specially Designated Nationals (SDN) list, EU Financial Sanctions Files, UK FCDO Sanctions List and PEP List (OpenSanctions). Each list has two boxes: Tx ticks it for transaction screening, Cust for customer screening. Tick the lists relevant to your compliance obligations. Further OpenSanctions lists can be added on request.

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) — They are not ticked per module: every accepted whitelist and blocklist of your institution applies automatically to every screening run. Click + add new item to create one, click an existing watchlist to open its details, or use the bin icon to propose its deletion — the list stays in use until two other Screening — level 2 users approve.

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. Unlike External Screening it consults no sanctions or PEP list: it is a pure keyword check against your dictionary. By default it reads the transaction message, so it catches what a payment says it is for; tick more Fields to check to also look for activity terms in the parties, their banks, the shipping details or every other field of the message — for example CASINO in a beneficiary's name. The full matching logic is described in How the Activity Check screens a transaction below.

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.

Fields to check sets which parts of the transaction the module scans, laid out like the field options of External Screening: Beneficiary name, Beneficiary address, Beneficiary FI name, Originator name, Originator address, Originator FI name, Transaction message, Intermediary FI names and Shipping information. Only Transaction message is ticked by default — modules created before this setting existed keep scanning the transaction message only. Below the grid, Check all other message fields also scans every MT tag and pacs element the options above do not read and shows which field each hit came from. For example, tick the three beneficiary options alone to look for activity terms only in who is being paid, or tick everything for the widest coverage. What each option reads is described in How the Activity Check screens a transaction.

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. The pencil icon renames a category and the bin icon deletes it together with all its terms. Category names must be unique (ignoring case).
• 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. On each term, the pencil icon edits it and the bin icon removes it. Terms are listed alphabetically, with terms that start with a number (such as HS codes) after the words.
• Exclusion terms — longer, legitimate phrases that contain one of the category's terms, used to suppress known false positives (for example casino royale for casino). Click + add new exclusion term to add one. They are sorted the same way as the terms.

Use the Search terms... box (top right) to find a term across every category. It matches your text anywhere inside terms and exclusion terms (not category names) and lists every match, exact matches first, then terms starting with your text. Picking a suggestion selects that category and highlights the term in its column.

How the Activity Check screens a transaction

What is scanned. The module scans the fields ticked under Fields to check, each value on its own:

BICs, country codes, amounts and dates are never scanned: they hold codes, not words. A ticked field that is empty on the transaction is skipped and logged as "no <field> found" — for example "no transaction message found" when the message carries no narrative. The module fires only on a match. If none of its categories has a search term, it scans nothing and logs only "nothing to check: no search terms configured".

Exactly which SWIFT fields form the narrative depends on the message type — for a payment it is the remittance information; for a documentary credit it is the documents-required, additional-conditions, charges and sender-to-receiver fields (the goods description is included for MT701, 705, 710, 711, 720 and 721, not for the other MT7xx types); for MT103 and MT202 the remittance information is used, falling back to sender-to-receiver information when it is absent; see Supported message types and what EFI extracts. Where a message has several narrative fields they are joined into one text and scanned together.

Checking all other message fields

With Check all other message fields ticked, the module also reads the original SWIFT MT or ISO 20022 pacs message field by field — the same fields External Screening's Screen all other message fields reads (see Screening all other message fields) — and scans every free-text one on its own. Typical finds are MT103 sender-to-receiver information (:72:) or regulatory reporting (:77B:), a documentary credit's goods description (:45A:) where it is not part of the narrative, and a pacs ultimate debtor or ultimate creditor. Fields that hold only a BIC or a country code are left out.

A line that only repeats a value one of the options above reads — a party name or address, a bank or intermediary bank name, a shipping place, or the transaction message — is skipped, so the same text is never reported twice. This holds whether or not that option is ticked: the options decide those values, so untick one and its value is not scanned at all. Everything else in the field is scanned, such as the account line of a party field.

Each hit names the field it came from — its SWIFT or ISO 20022 name and the MT tag or pacs element path, for example Sender to Receiver Information :72:.

Matching is case-insensitive in every mode. Casino, CASINO and casino are the same term.

The four matching modes. The mode you pick applies to every category:

The words of a multi-word term may be separated by any spaces or line breaks, so speed boat also matches across a line break.

Exclusion terms excuse the phrase they are part of. An exclusion term is a longer phrase containing one of the category's terms, such as casino royale for casino. Where it appears, the term inside it does not count; the term still hits anywhere else in the same value. An exclusion term that does not contain the term excuses nothing: use toy missile, not toy. Exclusion terms use the module's matching mode, but in Fuzzy mode without typos, so casino royale excuses CASINO ROYALE but not CASINO ROYAL.

Example: category Gambling has the term casino and the exclusion term casino royale. PAYMENT FOR CASINO ROYALE DVD raises no Gambling hit, because its only casino is part of casino royale. CASINO ROYALE DVD AND CASINO CHIPS is a hit, because the second casino stands on its own. CASINO CHIPS ORDER contains no exclusion term, so it is a hit.

Exclusion terms are the right tool for a legitimate phrase that happens to contain a risky word. To stop a term from hitting at all, delete it instead. They are a module setting, distinct from the whitelist stop words used by External Screening — stop words never affect the Activity Check.

What a hit records. Every matching term produces its own hit, recording the term, its category, the field it came from, the text that was scanned and where in it the term matched. One value can hit several terms and several categories at once, and the same term can hit in several fields; all of them are listed. However many hits there are, the module reports a single Block or Warning for the transaction.

What happens on a hit. The module's On hit setting decides the outcome: block raises a Block and warning raises a Warning (see Settings shared by every module). A Block gives the request a HIGH risk score and stops the transaction pending a user decision; a Warning gives it MEDIUM and lets it continue while surfacing the hit for review. If Remember manual decision is enabled and enough past requests blocked by this module for the same party were manually allowed, the Block is downgraded to a Warning. When a request blocked by the Activity Check is turned into a case, the ticket category is Activity Check.

Where you see the results.

• Screening request page → Module results — the Activity Check row shows Block or Warning. Click the module name to open the detail view. It lists the hits as Alerts, laid out like External Screening's: one HIT heading per scanned value (for example Beneficiary name = "GRAND CASINO LTD"), each matching term with its category, and a Matched in text line with the matching words highlighted. A Fuzzy hit on a different spelling also names the words it matched, for example narcotics [Narcotics] · matched on “NARCOTCS”.
• Request logs — the module writes one "checking <field>: …" line per value it scans (for example "checking transaction message: …" or "checking message field :72: (Sender to Receiver Information): …"), then one line per hit reading "found match on <term>, <category>", or "no matches found". A Fuzzy hit on a different spelling names the matched words too, for example found match on narcotics (fuzzy match on "NARCOTCS"), Narcotics. When no category has a search term, it writes only "nothing to check: no search terms configured".
• Transactions list → Modules filter → Activity Check — lists every transaction the module flagged.
• Cases — tickets raised from an Activity Check block carry the Activity Check category.

Removing or excluding a term from a hit. Users with Screening level 1 or level 2 see a Remove / exclude term button under each hit in the detail view. It offers two choices:

• Remove the term from its category.
• Keep the term and add an exclusion term. Pick one of the two- or three-word phrases around the hit — for speed in INVOICE 4471 SPEED BOAT SPARE PARTS: 4471 speed, speed boat, speed boat spare and so on — then edit it or type your own. The dialog warns when the phrase does not cover this hit.

The change is made to the module that produced the hit and applies to transactions screened from then on. With four-eyes review it is submitted like a flow edit (see Saving when four-eyes review is enabled): the flow is locked until a different Screening level 2 user approves or rejects it, and no new change can be requested meanwhile.

Supplementary data. When supplementary data (for example invoice or transport-document fields, including AML-tagged values) is submitted against a request, its free-text values are also scanned against the same categories, terms, exclusion terms and matching mode — provided an Activity check module is configured for your institution. The Fields to check setting does not apply here: a submission has its own fields, and every free-text one is scanned. That means every plain field and every AML-tagged value whose tag is mapped as Free Text; values tagged as a name, country, bank identifier or vessel are screened against the watchlists instead and are not keyword-checked. Each submitted value is scanned on its own, so an exclusion term only excuses a term within the same value, and every Activity check module wired into your flow contributes its dictionary; a module that exists but is not connected in the flow does not run. A match appears on the submission as an ACTIVITY alert listing each term (with the words it matched, for a Fuzzy match on a different spelling) and its category, and any activity match makes the submission Blocked, whatever the module's On hit setting. Whitelist entries do not apply to activity matches; use exclusion terms to suppress a recurring false positive.

Tuning tips.

• Prefer Full words only for short or generic terms (arms, gold, cash); use As string only for fragments you genuinely want to match inside longer words.
• Fuzzy is most useful for long, distinctive terms where misspellings or transliterations are common (narcotics, ammunition, cryptocurrency); short terms must match exactly anyway. It also matches everyday words one letter away from a term, such as INDIA for indica; switch to Full words only or remove the term if these keep coming up.
• Add exclusion terms for the legitimate phrases your traffic produces (casino royale, arms length), rather than removing the risky term.
• After changing terms, open a flagged request's logs and detail view to confirm that the hits are the ones you expect.

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.

Exporting categories as a CSV

Click Download CSV to save every category of the module — with its terms and exclusion terms — as a file in exactly the format Upload CSV accepts: the category, terms, exclusion_terms columns, one category per row, terms separated by a semicolon (;). Use it to keep a copy of your lists, review them in a spreadsheet, or move them to another Activity check module.

• The file contains the saved configuration only. Edits you have not saved yet are left out — click Save configuration first to include them. The matching mode is not part of the file.
• A category that has no terms is exported, but Upload CSV rejects a row without terms — add a term or remove the row before importing the file.
• A value that a spreadsheet would treat as a formula (starting with =, +, - or @) is written with a leading apostrophe so it opens as plain text. Upload CSV removes that apostrophe again, so the terms come back unchanged.

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, Type, Originator/Beneficiary Country, Originator/Beneficiary FI Country, Originator/Beneficiary FI ID), Request (Message Type), and Customer (Sender) / Customer (Receiver) attributes (Client Type, Customer ID, Gender, Birth Place, ID Type, ID Issue Location, Date of Birth, User Name, AML Info Entry — the last with a tag). Operators are =, ≠, >, ≥, <, ≤, in list, and not in list; customer attributes allow only =, ≠, in list and not in list. in list and not in list take comma-separated values (a,b,c).
• + 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 and is not used until two other Screening — level 2 users approve it in Watchlist Details (the banner there reads This list is pending creation (0/2 approvals) and is not used in screening yet). A whitelist left non-generic with no override sources ticked is saved as generic. 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 whitelist entry removes the individual hits its value produced, on the fields its Applies to setting covers; any hit not covered still blocks. Whitelists can override specific official sources (via Override Sources) or apply generically (Is Generic). A whitelist entry covers a hit when every word of the matched value appears in the entry, case-insensitively; spelling variants are never tolerated.
• 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. Blocklist terms are matched like the official lists, on every field the module checks and with the module's Match type: Exact needs the words as written, Fuzzy tolerates the same spelling variants sanctions matching does. On a name field the screened value is compared to the entry as a whole; on the transaction message and the address fields a term is flagged wherever its words appear next to each other in the text, in any order.

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, and review Status (accepted, pending, or rejected). Hover over a field and click the pencil icon to propose a new value, then Save: the proposal appears under Pending List Changes and applies once two other Screening — level 2 users approve it. Only an accepted list with no pending change can be edited — one change at a time per list.

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, or Export CSV to download the entries shown in the two tables (the current page) for offline review. Entries are listed 30 per page, with First, Prev, Next and Last below the tables.

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. Every new entry starts as pending, whoever added it, and is accepted once two different reviewers have approved it; a single rejection rejects it. Only users with Screening — level 2 (or Administrator) see Approve and Reject on a pending entry, and never on an entry they proposed themselves or have already approved. 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.