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 four 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, account age, and the 90-day historical average transaction amount
Velocity	Rolling counters over recent activity, deposit / withdrawal / transfer sums and counts over 1h, 24h, 7d and 30d, 24h net flow, and per-counterparty inbound value and distinct-identity counts. See Velocity

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.

Any integer field can be the metric, which is what makes the velocity counters useful: banding velocity.depositCount24h at 5 / 10 / 20 turns "unusual frequency" into three graded contributions instead of one cliff edge.

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 ad alto 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

Filter the page by Universal, IT, or UK. Filtering by a jurisdiction also keeps the universal entries, since those apply to every book. The in-product catalog is always the live list; the tables below are the current curated set.

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, applicable from 1 January 2024)

Template	Indicator (indicative)
Controparte in paese ad alto rischio (lista configurata)	Either country leg on your configured Italian risk list. Indicatore 6.
Causale anomala	Payment description matches the Italian keyword pack. Art. 5(1), parametri qualitativi di selezione.
Operatività frazionata (structuring)	Repeated EUR cash deposits just under the €10,000 threshold within 24h, banded on velocity.depositCount24h. Indicatore 13, sub-indice 15.11.
Movimento rilevante in contanti	EUR movement on the cash channel, banded by amount. Indicatore 13; art. 4(5)(d).
Carta utilizzata fuori orario	Card activity outside 08:00–19:59 in the organization timezone. Weak proxy; does not raise an alert on its own. Sub-indice 15.10.
Operatività crypto di importo rilevante	EUR movement on a crypto channel or rail, banded by amount. Indicatore 26 and sub-indici 26.1–26.5.

United Kingdom (JMLSG / FCA)

Template	Indicator (indicative)
High-risk jurisdiction	FATF/HMT-style country-risk list hit.
Unusual transaction frequency	Deposit count over 24h, banded on velocity.depositCount24h at 5 / 10 / 20.

The Italian templates are selection signals, not determinations

Article 4(5) of the Provvedimento is explicit that the mere occurrence of an indicator or sub-index — or the use of cash — is not by itself sufficient grounds for a report. The suggested cutoffs and probabilities shipped with these templates are product starter values for you to calibrate; they are not prescribed or endorsed by the UIF.

The velocity-based templates (Operatività frazionata, Unusual transaction frequency) are live and firing: they band on the rolling counters documented under Velocity.

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, spend against the identity's own 90-day average, velocity over any of the four windows, and any AND/OR combination of the glossary fields. That list is still not exhaustive; the builder is.

Who curates the catalog

The template catalog itself is platform-curated: your organization can list templates and instantiate them, but not add, edit, or remove catalog entries. If a typology you need is missing, either build it as an ordinary rule or ask Zyphe to add it to the catalog. A template Zyphe retires disappears from the catalog and can no longer be instantiated; rules you already created from it keep working and keep their provenance.