Rules and Templates

Transaction Monitoring → Rules holds the rules evaluated on every ingested transaction. Each fired rule contributes a probability, and the noisy-OR combination of all contributions decides Allow / Review / Block.

The Rules page lists the enabled rule set with each rule's key, version, type, and probabilities.

Anatomy of a rule

A rule is made of:

• Rule key: a stable lowercase slug (a–z, 0–9, - and _) that identifies the rule across versions.
• Name and description: for your reviewers.
• Condition: when it matches, the rule fires and contributes its probability to the combined P(risk).
• Probabilities: how much a firing contributes, between 0 and 1.
• Raise alert: whether a firing also creates a review-queue alert and notifies your webhook.

The condition builder

Conditions are built visually as nested AND / OR groups of field comparisons (equals, not equals, greater/less than, in a set, contains, is empty / not empty).

The rule builder: name, stable rule key, and the visual condition editor with nested groups.

Fields come from three sources. Each field is defined, with units and examples, in Condition fields. Amounts use minor units (cents, not euros): see that glossary before setting cutoffs.

Transaction	Amount (minor units), currency, direction, payment status, counterparty name / account / country, origin country, channel, rail, payment description, and derived time fields, hour of day, day of week, outside business hours (driven by the timezone in Settings)
Lists	Matches against your managed lists, counterparty blocklist / allowlist hits, country-risk list hits, keyword list hits
Identity	Signals from the verified identity behind the transaction, KYC risk score and account age

Boolean vs banded rules

There are two rule types:

• Boolean signal: the rule fires at a single probability whenever its condition matches. Example: counterparty is on the blocklist → contribute 0.9.
• Banded metric: on top of the condition, a numeric field (the metric) is banded against low / medium / high cutoffs, and each band contributes its own probability. Example: withdrawal amountMinor banded at 100000 / 1000000 / 10000000 (that is €1,000 / €10,000 / €100,000 when the currency is EUR) → contribute 0.1 / 0.4 / 0.7 depending on where the amount lands. Cutoffs must be ordered (low ≤ med ≤ high), and any subset of them can be provided. Always pair amount cutoffs with a currency condition.

Versioning

Rules are append-only: saving an edit creates a new version and enables it atomically, so the change is live on the very next ingested transaction. The rule page shows the full version history: enabling a previous version disables every other version of that key, and disabling a rule stops it from firing on the next ingest while keeping all versions reconstructable.

Because ingested transactions record the exact rule versions that fired, historical decisions remain explainable regardless of how the rule set evolves.

Backtesting

Before enabling a rule (or a new version of one), you can backtest it: a dry-run of the rule, as currently edited, against your stored transactions over a chosen scan window. The backtest reports:

• how the simulated decisions compare with the stored baseline (Allow / Review / Block distribution);
• how often the candidate rule would fire, per band for banded rules;
• a sample of fired transactions with their simulated decision and P(risk).

You can run the candidate rule alone or combined with the currently enabled rules; a candidate sharing an enabled rule's key replaces it for the run. Nothing is persisted or billed, the backtest uses the same validation and evaluation core as live ingestion.

The rule page: Raise alert toggle, the Backtest panel, and the append-only version history below.

Templates vs rules

A rule is what the engine evaluates: a condition you own, versioned, with probabilities you set. You can create a rule from a blank builder at any time.

A template (the dashboard also calls these models) is a starter: a pre-filled copy of a known pattern, tagged with a jurisdiction and often a regulator citation. Instantiating a template pastes it into your rule set as an ordinary rule. After that it is yours — edit, retune, disable, or ignore the rest of the catalog.

The cards you see (“Causale anomala”, “Controparte in paese a rischio”, large deposit, night-time activity, …) are examples, not the full universe of rules you can run. Banca d’Italia / UIF indicatori di anomalia cover far more typologies than the seeded cards. If a pattern is missing, create a rule from scratch over the condition fields, or instantiate the closest template and change the condition.

Rule templates

Transaction Monitoring → Rule Templates is a jurisdiction-tagged catalog of ready-made rules, with regulator citations (for example UIF indicatori di anomalia, FCA/JMLSG) plus universal primitives that apply anywhere.

The template catalog, filterable by jurisdiction, each card shows the condition, type, probabilities, and alert flag.

What instantiating does

Instantiating turns a parametric template into a concrete, enabled rule (version 1) in your organization.

On the Instantiate dialog you set, for this copy:

• Rule key, name, description — how it will show up in your rule list and in fired-rule provenance.
• Low / medium / high cutoffs — only for banded templates. These are the numeric thresholds of the metric (for amount templates, in minor units).
• Probabilities per band (or the single probability of a boolean template).
• Raise alert — whether a firing also opens a review alert and hits your webhook.

The condition (when the rule fires) comes from the template and is not edited in that dialog. Change it afterwards on the rule, like any other rule. Template provenance is stored so you can see which catalog entry it came from.

Think of it as: pick a starter → name it and set your policy thresholds → it is live on the next ingested transaction. Cutoffs you do not yet know can be agreed at onboarding and filled in then; you can also retune them later and backtest first.

Catalog (indicative)

Filter the page by Universal, IT, or UK. The in-product catalog is the live list; this table is the seeded set so you can see it is broader than the two Italian examples that sit on the first screen.

Universal (any book)

Template	What it catches
Blocklisted counterparty	Counterparty account is on a block list (hard block through the combined score).
High-risk country (either leg)	Origin or counterparty country is on an enabled country-risk list.
Suspicious keyword in description	Payment description matches a keyword list (SEPA causale).
Large deposit / large withdrawal	Amount banded in minor units; adjust cutoffs to your currency.
Night-time activity	Hour of day 00:00–05:59 in the organization timezone. Weak signal; accumulates with others.
New account, high value	Identity verified less than 24 hours ago, amount banded.

Italy (UIF indicatori di anomalia, Provvedimento 12/05/2023)

Template	Indicator (indicative)
Controparte in paese a rischio (MEF/BdI)	High-risk countries.
Causale anomala	Anomalous payment descriptions / cash-related keywords.
Operatività frazionata (structuring)	Repeated deposits just under threshold. Dormant until velocity counters ship; listed so the indicator is not missing from the catalog.

United Kingdom (JMLSG / FCA)

Template	Indicator (indicative)
High-risk jurisdiction	FATF/HMT-style country-risk list hit.
Unusual transaction frequency	Deposit count over 24h. Dormant until velocity counters ship.

You can also encode, as ordinary rules, patterns the seeded cards do not name: round amounts, just-under-threshold single payments, weekend activity, new-account plus high-risk country, allowlisted counterparties as suppressors, KYC risk score on the identity, and any AND/OR combination of the glossary fields. That list is still not exhaustive; the builder is.

Velocity / frequency templates stay in the catalog so you can see the intended Banca d’Italia / JMLSG coverage; they do not fire until the velocity.* fields exist. Amount-based “importo sospetto” rules are already live.