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 Alerts > Transaction monitoring alerts by clicking Settings in the header; like that tab, it needs the Monitoring product and the Transaction monitoring permission.

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 header (anywhere except its controls) 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, deduplicated hits, tickets created or updated, run duration, and any errors).
• Run All Modules — queues a run of every enabled module one after another, showing a live counter such as "Running (3/9)...". When every module was queued you'll see a summary like "7 triggered, 1 already running."; if any could not be queued, a red banner reads "Some modules could not be started" with a Ref ID for support. The button is disabled while no module is enabled.
• 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. If the modules could not be loaded, the page says so and offers Try again.

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 a card's header 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.
• Amount thresholds are set per currency — every amount threshold is a small table with a Default row that covers any currency without a row of its own. Add a currency with its three-letter code (it starts from the Default value) and remove it with ×. Amounts are never converted between currencies: a party's volume is totalled per currency and each total is compared with that currency's threshold, so 30,000 EUR and 30,000 USD to the same country do not add up to 60,000.
• Percentage fields are entered as whole numbers — type 80, not 0.8.
• Country lists you own (the High / Medium / Low lists of High Risk Jurisdictions and the haven list of Tax Havens) are rows of chips: click a chip to remove the country, type two-letter ISO codes and press Enter to add them. Other country and currency fields 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 hides this field: it always loads the last day of transactions and measures frequency inside it with its hour-based Analysis Window, described below — values above 24 hours cannot look further back.)

Default Schedule

New modules start with the schedule that fits their pattern; change it in the card header.

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, as a table you can extend with any currency. Transactions kept just below these are candidates for structuring. The Default row applies to any currency without a row.

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 the countries you rate as high, medium or low risk. The module totals, per party, every transaction that touches a listed country — through the originator's or beneficiary's country or either bank's — and an alert fires when the party's volume in any one currency or its transaction count reaches its threshold; the alert reports the volume in the currency that reached its threshold, or came closest. It carries the severity of the highest list among the countries hit: a party with one Medium-list country and one High-list country raises a High alert.

Countries by Severity — three lists, High, Medium and Low, that you own: click a country to remove it, type two-letter ISO codes and press Enter to add them. A country on two lists counts at the higher one; an empty list triggers nothing. The lists come pre-filled from the FATF black list (High) and from the FATF grey list and the EU list of high-risk third countries (Medium); the module follows your lists from then on, not those publications, so review the defaults against the current ones.

Invoice Manipulation

Detects over-invoicing, under-invoicing, and statistical anomalies in trade payments. It reads product keywords from payment messages (case-insensitive, matching inside longer words), compares amounts against expected price ranges, and also flags amounts that deviate sharply from a pair of parties' own history. Over- and under-invoicing alerts are High, statistical anomalies carry the module's Default Severity.

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. Pairs are evaluated per currency; a pair that qualifies as round-tripping is not also reported for repeated transfers. Round-tripping and suspicious networks are High, repeated transfers carry the module's Default Severity.

Sanctions Circumvention

Detects likely sanctions evasion: parties that used to transact with a sanctioned country and now route funds through a neighbouring one, beneficiaries whose names closely resemble a party that transacted with a sanctioned country in the same period, and new corridors next to a sanctioned country. Neighbour routing and name matches are High, corridor shifts carry the module's Default Severity.

Sanctioned Countries & Neighbor 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 (open it with Show scoring breakdown) is:

Maximum possible score: 11.

Name Keyword Dictionary (open it with Show keyword configuration) — 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.

An alert fires when the amount in any one currency or the ratio is reached; it reports the currency that reached its threshold, or came closest. It is High when that amount is at least twice its currency's threshold and the ratio is also reached, otherwise it carries the module's Default Severity.

Haven Countries — one list that you own: click a country to remove it, type two-letter ISO codes and press Enter to add them. An empty list triggers nothing. It comes pre-filled from the EU list of non-cooperative jurisdictions and the IMF's list of offshore financial centres; the module follows your list from then on, not those publications, so review the defaults against the current ones.

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 table lists every currency with its own divisor and a Default row for the rest: 1,000 by default, with CNY 1,000, JPY 10,000, KRW 100,000 and VND 1,000,000 pre-filled; add or remove currencies as in any threshold table.

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 are listed by key — khorgos_altynkol, dostyk_alashankou, bishkek_fez, eaeu_transit — and match as case-insensitive text inside the chosen fields.

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.

The dual-use signal comes from a built-in list of 13 controlled-goods categories, each matched by HS-code prefixes and keywords in the Scan Fields, plus any category you add to the Dual Use Goods dictionary:

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

The Dual Use Goods dictionary (open it with the Show dual use goods configuration toggle; it starts empty) extends that list: a transaction whose scan fields contain a term of one of your categories, and none of that category's Exclusion terms, carries the category as a dual-use goods signal exactly like a built-in category, and the category is named on the alert. A dictionary on its own is enough: with it, the module raises alerts even if none of the built-in categories matches.

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.

Runs are queued and execute in the background. 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; the page confirms "Change request submitted for approval." and the approvers are notified. A save with nothing changed is refused.
• 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. The proposer's card reads "Awaiting approval from another user." with only View changes; a second request for the same module is refused while one is pending.
• An approver (a user with the Screening — level 2 permission, other than the one who proposed the change) sees View changes (what approving would change, in plain words, above the full diff), Approve, and Reject on the locked card. Approving applies the configuration immediately; rejecting requires a reason (up to 500 characters), 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. If your institution also holds the Screening product, pending requests can be managed from Screening > Pending approvals as well: one table of module and screening-flow requests (Name, Scope, Mode, Proposed by, Submitted at) with View changes, Approve and Reject; tick Show closed requests for the approved and rejected history.

Navigating Back

Use the back arrow next to the "Monitoring Settings" heading to return to the Transaction monitoring alerts list.