Scenarios and typologies

The scenario catalog

A scenario is a money laundering typology with an identity of its own: code, name, description, regulatory reference, default severity, SLA, consolidation window and minimum dispatch severity. The catalog is per jurisdiction, versioned, translated into the language of the jurisdiction, and every change goes through approval with history.

Each rule in the AML workflow points to a scenario. When the rule triggers, the alert is born with that scenario’s code. A rule without a scenario produces no alert, which guarantees that no alert reaches the Desk without a typology.

Two types of scenario

Type	How it is detected	Example
Per transaction	An engine rule triggers during the evaluation of a transaction	Transaction above the declared profile; newly registered counterpart; amount close to the reporting threshold
Per entity	The periodic evaluator sums or counts a subject’s operations in a window and compares the result with the scenario threshold	Accumulated volume over 7 days above the threshold; number of structured operations in 24 hours

The per-entity scenario keeps in the catalog itself what the evaluator needs: the aggregate (sum or count), the aggregated field, the window and the threshold. That is what the parametrization screen edits.

Typology families

Each jurisdiction’s catalog carries its own codes and regulatory references, taken from the national typology catalog, with the same code the Decision Desk uses to classify the case. Underneath those codes the catalog expresses a stable set of typology families, and the platform’s AML rule package has detection for each of them:

Family	What the engine observes
Movement incompatible with the profile	Amount and volume above the customer’s behavioral baseline or above the transactional profile declared at registration
Structuring near reporting thresholds	Split operations and amounts just below the regulatory threshold, several operations under the threshold within a short interval, sequences of relevant-amount operations on the same day
Abrupt increase in activity	Volume and frequency of a window compared with the customer’s own previous window
New or recently registered counterparties	First operation with a new counterpart, with a relevant amount, and frequency patterns outside the usual
Politically exposed persons	Operation by a customer flagged as PEP during onboarding
Sanctions and terrorism lists	Customer or counterpart on a sanctions or terrorism list
High-risk sectors and non-profits	Customer in a high-risk sector or a non-profit entity, and counterparts in high-risk countries
Interposed third parties	Operation by a third party on behalf of the customer, and chains of counterparts without a declared relationship
Circular flows and pass-through	Funds that leave and return to the same subject through a chain of counterparts, or that enter and leave a subject within a short interval

The other typologies of the national catalog enter the tenant’s catalog as the institution defines the corresponding detection rules, with no system change.

Some scenarios depend on data that comes from the institution’s systems. Geographic risk, continuous crypto activity and anomalous account rotation are activated when the institution starts supplying the data that supports them (list of observed countries, crypto counterpart flag and the account registry data of the jurisdiction). Product incompatibility, economic activity, customer-anchored pass-through and cash outside the profile depend on limit and expected-use data; the fields exist in the canonical payload and those scenarios come into effect when that data is made available.

Severity

In AML, the alert severity comes from the scenario configuration, independent of the transaction score. Compliance defines high, medium or low per scenario, and it is the severity that decides whether the alert goes to the Desk or stays aggregated in the FPP.

In fraud prevention, severity is inherited from the decision: a block is high and a review is medium. The fraud score does not change because of the alert.

Field-to-field comparison

Rule conditions compare a field with a fixed value or with another field of the same type, using the ordering operators (greater than, greater than or equal, less than, less than or equal). This is what allows writing “operation amount greater than the customer’s declared limit” or “volume of the last 7 days greater than the volume of the previous 30 days” without any calculation outside the engine, whatever the jurisdiction.