Support Portal

The Monitoring Settings page is where you tune every transaction monitoring module — what each one looks for, how sensitive it is, how severe its alerts are, and how often it runs. Reach it from the Monitoring Alerts list by clicking the Settings control in the header (the page lives at Monitoring > Settings).

Each module is a self-contained detection rule. You can turn modules on or off individually, adjust their thresholds, run them on demand, and — if your institution uses four-eyes approval — route changes through a reviewer before they take effect.

How the Page Is Organised

Every module appears as its own collapsible card. The card header gives you the controls you use most often without having to expand anything; clicking the card opens the full configuration form underneath.

At the top of the page you'll find page-wide actions:

• Jobs — opens the Monitoring Jobs page, a history of every run (transactions analysed, alerts generated, tickets created, run duration, and any errors).
• Run All Modules — runs every enabled module one after another, showing a live counter such as "Running (3/9)...". When it finishes you'll see a summary like "7 triggered, 1 already running, 1 failed."
• Save All Changes (or Submit for Approval when four-eyes is on) — persists every change you've made across all cards at once. It stays disabled until you actually change something.
• Unsaved changes indicator — an amber dot appears the moment you edit any field, reminding you that nothing is applied until you save.

If no modules have been set up for your institution yet, the page shows an empty state instead of cards — modules are provisioned by your administrator.

Reading a Module Card Header

The header of each card exposes four settings you can change without expanding the card, plus status information:

When a module has run before, the header also shows its Last run date. If a change to the module is waiting on approval, a Pending Approval badge appears and the card's controls are locked until the request is resolved.

Expanding and Configuring a Module

Click anywhere on a card to expand it. You'll see a plain-language description of what the module detects, followed by its configuration form. The form is tailored to each module type, but a few conventions are shared across all of them:

• Amounts and thresholds are in whole currency units — 10,000 means 10,000 EUR, not cents.
• Percentage fields are entered as whole numbers — type 80, not 0.8.
• Country and currency lists are comma-separated codes (e.g. CN, RU, TR) and are automatically capitalised.
• Keyword lists are comma-separated and automatically lower-cased.

Lookback Window

Almost every module has a Lookback Window (days) field controlling how much transaction history it analyses on each run (1–365 days). A window of 7 means it looks at the last 7 days of activity. Defaults vary by module because different patterns need different amounts of history — fast-moving signals use short windows, statistical ones use longer windows:

(Velocity Abuse is the exception — instead of a day-based lookback it uses its own hour-based Analysis Window, described below.)

The Modules

Each section below describes what the module detects and every setting inside it, with its default value. Defaults are sensible starting points — tune them to your institution's risk appetite and transaction profile.

Structuring

Detects "smurfing" — large sums deliberately broken into multiple smaller transactions kept just below a regulatory reporting threshold so no single transaction triggers a report, while the total still adds up to a significant amount.

Currency Thresholds — the reporting limit per currency. Transactions kept just below these are candidates for structuring. The Default threshold applies to any currency you don't list explicitly.

Velocity Abuse

Flags parties transacting abnormally fast — rapid-fire transactions that can indicate automated fraud, account takeover, or layering.

High Risk Jurisdictions

Flags significant transaction flows to or from countries on international high-risk lists (FATF and EU). An alert fires when either the volume or the transaction count to a flagged country crosses its threshold.

Risk Lists — three built-in reference lists, each with its own enable toggle, a severity override, a link to the official source, and an expandable view of every country it contains. Excluded countries appear struck through.

Invoice Manipulation

Detects over-invoicing, under-invoicing, and statistical anomalies in trade payments. It reads product keywords from payment messages, compares amounts against expected price ranges, and also flags amounts that deviate sharply from a pair of parties' own history.

Product Category Benchmarks

This table is the reference the module checks each trade payment against. For every kind of goods you define, it holds an expected price range, so the module can spot amounts that are implausibly high (over-invoicing) or low (under-invoicing) for what's being traded. Expand it with the Show/Hide benchmarks toggle next to the section heading (shown in the screenshot above).

How it's used on each run:

1. The module reads the transaction's payment message and looks for any of the keywords you've defined for a category (product names or HS commodity codes).
2. On a match, it picks the expected range for the transaction's currency — or the category's DEFAULT range if that currency has no specific entry.
3. It compares the amount against that range, widened by the invoice factors above:
4. Over-invoicing if the amount exceeds Max × Over-Invoice Factor (e.g. Max 50,000 × 1.5 → flags above 75,000).
5. Under-invoicing if the amount falls below Min × Under-Invoice Factor (e.g. Min 100 × 0.5 → flags below 50).
6. A transaction whose message matches no keyword — or whose currency has neither a matching nor a DEFAULT range — is skipped by this check; only the statistical party-history check (the deviation threshold) applies to it.

Because matching is keyword-driven, benchmarks only work as well as your keywords cover your traffic. Add the terms and HS codes your institution actually sees in payment messages, and keep the ranges realistic for your markets — too wide and manipulation slips through, too narrow and legitimate deals get flagged.

Each category row has:

• Label — the category name.
• Keywords — entered as tags: type a term and press Enter (or comma) to add it as a chip; paste a comma-separated list to add several at once; remove one with its × (or press Backspace in the empty box). Terms are lower-cased automatically, and HS codes like 8471 count as keywords.
• Currency ranges — a Min – Max range per currency. Every category has a DEFAULT range, which applies to any currency without its own entry. Click + Currency to add a currency-specific range (EUR, USD, GBP, CNY, JPY, CHF); it starts from the DEFAULT values and you can adjust it. Remove a currency with its × (DEFAULT can't be removed). All amounts are in whole currency units (e.g. 50,000 = 50,000 of that currency).

Per-currency ranges let one benchmark reflect that, say, the same goods trade at different typical values in JPY versus EUR — set a DEFAULT for the common case and override only the currencies that differ.

Guardrails: a category must have a label and at least one keyword, and every range's Min must be 0 or more and below its Max. Invalid entries are outlined in red with a short explanation, and the add form won't accept a new category until it's valid.

Managing the list:

• Search — filter categories by label or keyword.
• Reorder — drag a row by its handle to change the order (clear the search first).
• Duplicate — copy a row, including its ranges, as a starting point for a similar category.
• Import / Export — download all benchmarks as a JSON file, or import a JSON file to replace them (handy for sharing a tuned set between institutions).
• Add / Restore — + add product category adds a row; if you've removed them all, the empty state offers Restore defaults.

Built-in categories (example ranges to get you started — edit them freely):

(Numeric keywords such as 8471 and 2709 are HS commodity codes — including them lets the module match structured trade references as well as plain-language product names.)

Party Clustering

Analyses the transaction network to spot round-tripping (funds bouncing back and forth between two entities), repeated transfers, and unusually large clusters of interconnected parties.

Sanctions Circumvention

Detects likely sanctions evasion: parties that used to transact with a sanctioned country and now route funds through a neighbouring one, plus name variants that closely resemble sanctioned entities.

Sanctioned Countries & Neighbour Routes — a built-in reference (read-only) mapping each sanctioned country to the neighbours through which evasion is watched: North Korea → China, Russia; Iran → Iraq, Turkey, Afghanistan, Pakistan; Syria → Turkey, Iraq, Lebanon, Jordan; Cuba → Mexico; Russia → Georgia, Kazakhstan, Belarus, Azerbaijan, Armenia, Turkey.

Dual Use Goods — an editable keyword dictionary of export-controlled items (civilian goods with potential military use) to scan for in transaction messages; matches add context to alerts. Exclusion terms help suppress false positives.

Shell Companies

Identifies likely shell-company activity using a cumulative score — each suspicious indicator adds points, and an alert fires once the total reaches your threshold (with High severity at threshold + 3).

The scoring reference (shown read-only in the card) is:

Maximum possible score: 11.

Name Keyword Dictionary — categories of terms matched against party names and addresses (a match in a shell jurisdiction contributes to the score). Ships with a "Generic Shell Terms" category (trading, holdings, consulting, international, services, global). You can toggle Use Regex and Full Words Only, and maintain per-category exclusion terms to avoid false positives.

Tax Havens

Flags parties whose transaction flow to tax havens and offshore centres is disproportionate — a signal of tax evasion or illicit fund parking.

Haven Lists — two built-in lists you can enable or disable: EU Non-Cooperative Jurisdictions and Offshore Financial Centres. Click any country to exclude it (and click again to re-enable). Use Additional Countries to add custom codes beyond the official lists — type a code and press Enter to add it as a removable tag.

Round Amount

Detects entities with a disproportionate share of round-number transactions — a FATF/Wolfsberg red flag for trade-based money laundering. An alert needs both enough round transactions and a high enough ratio.

Round Divisors by Currency — an amount is "round" if it divides evenly by its currency's divisor (with a divisor of 1,000, both 5,000 and 10,000 are round but 5,500 is not). The Default divisor is 1,000; JPY defaults to 10,000. You can set per-currency divisors for EUR, USD, GBP, and CNY.

Conveyance Risk

Targets the Central Asia–China trade corridor. An alert requires two signals together: a corridor geography signal (a named chokepoint or a corridor country) and a dual-use goods signal (controlled items such as semiconductors, CNC machine tools, optics, or navigation components).

Corridor countries — an editable list of country codes counting as the corridor geography, pre-filled with the Central Asia–China corridor (China, Kazakhstan, Kyrgyzstan, Uzbekistan, Tajikistan, Turkmenistan, Russia, Belarus, Armenia).

Chokepoints — named transit points that also count as a corridor signal and raise severity to High when hit. You choose which message fields are matched (shipping route, transaction message, party names/addresses, banks, intermediaries) and maintain the named chokepoints and their keywords. Built-in chokepoints cover Khorgos/Altynkol, Dostyk/Alashankou, Bishkek Free Economic Zone, and EAEU transit.

Dual Use Goods

"Dual-use goods" are items, software, and technologies with both civilian and potential military applications — the kind of controlled products sanctions-evasion schemes try to move quietly. In Conveyance Risk this is one of the two signals an alert requires: a transaction has to show a corridor geography signal and a dual-use goods signal together before it's flagged. This dictionary is how you tell the module what counts as a dual-use good in your transaction messages.

Open it with the Show dual use goods configuration toggle (it's collapsed by default). Unlike some other keyword dictionaries in EFI, it starts empty for Conveyance Risk — you define the terms that matter for your exposure. The controlled-goods types named in the module's description are a guide for what to add, for example:

Semiconductors · Computing · Telecom · Optics & sensors · Navigation · CNC machine tools · Measuring & test equipment · Aircraft & UAV · Precision bearings · Pumps & vacuum · Power electronics · Chemical precursors · Specialty materials

How it's used on each run: the module scans transaction messages (alongside controlled HS codes) for your terms. A hit provides the dual-use signal, which — combined with a corridor country or named chokepoint — produces an alert. Exclusion terms let you suppress predictable false positives (a term that would otherwise match legitimate, unrelated wording).

How the editor works — terms are organised into categories:

• Pick or create a Category (the left column). Selecting one shows its terms.
• Add the words or phrases to match under Terms, and any words that should cancel a match under Exclusion terms. Use the + add links to add entries and the trash icon to remove them.
• Two matching options sit at the top:
• Use Regex — treat each term as a regular expression instead of plain text (off by default).
• Full Words Only — match whole words rather than fragments, so "arms" won't match "harmsworth" (on by default).

This is the same keyword dictionary used by the Sanctions Circumvention module, so terms you maintain there are configured the same way.

Running Modules

You can run detection two ways:

• Run Now on a card runs that single module immediately.
• Run All Modules in the page header runs every enabled module in sequence, with a live progress counter. A module already running from a previous trigger is counted as complete and the next one starts.

After a run you'll see a brief summary. If any module fails to start, an error banner appears with a reference ID — share that ID with support if the problem persists. Every run (whether from Run Now or Run All) shows up on the Jobs page with its results.

Saving Changes

Nothing you change takes effect until you save. As soon as you edit a field, the Unsaved changes indicator appears and Save All Changes becomes active — it saves every modified module at once. Navigating away without saving discards your edits.

Four-Eyes Approval

If your institution has four-eyes approval enabled for module configuration, the save workflow changes:

• The save button reads Submit for Approval, and saving creates a change request instead of applying your edits directly.
• A module with a pending change request is locked — its controls are disabled and a Pending Approval badge appears — until an approver acts on it.
• An approver (a different user from the one who proposed the change) sees View changes, Approve, and Reject on the locked card. Approving applies the configuration immediately; rejecting requires a reason, which is sent back to the proposer.
• Each card keeps a Change history of past approved and rejected requests, showing who proposed and reviewed each one, any rejection reason, and a link to view the exact changes.

If four-eyes is later switched off while requests are still pending, a banner explains that those requests won't be processed and won't block direct edits — you can re-enable four-eyes to act on them, or treat them as historical records. Pending requests can also be managed from the separate Pending Approvals page.

Navigating Back

Use the back arrow next to the "Monitoring Settings" heading to return to the Monitoring Alerts list.