Parametrization and governance

Parametrize without redeploy

Everything that defines AML behavior in a tenant is data, editable by Compliance with approval and history: the scenario catalog, the parameters of each scenario, the AML workflow with its rules and thresholds. No change requires a new version of the system.

The matrix screen

The parametrization screen presents the scenarios of the tenant’s jurisdiction in a matrix view, one row per scenario, with the columns Compliance governs:

Column	What it controls
Active	Whether the scenario produces alerts
Threshold	The amount (in currency) or the count from which the scenario triggers
Window	The period of the aggregate, in per-entity scenarios, and the consolidation window
Severity	High, medium or low, which decides whether the alert goes to the Desk
SLA	The deadline associated with the scenario, which travels with the alert
Weight	The scenario’s contribution to the AML domain score

Editing is per row, in a form, with type and unit validation, and nothing is saved without a change reason.

A single source of truth

For per-entity scenarios, the catalog row is the authority: the periodic evaluator reads from there. For per-transaction scenarios, the authority remains the condition and the rule in the workflow; the screen writes through them, with the version and the approval they already have. A parameter saved through the screen and the same parameter written through the API produce exactly the same evaluation. There is no copy of the value anywhere else that could diverge.

Approval and history

Every parameter change follows two-step approval: whoever edits proposes, another user approves. The screen shows the history as a list (who changed, when, what, from which value to which value), and each approval is kept in the platform’s audit trail.

Rules, conditions, stages and policies of the AML workflow remain in the workflow editor, with the three-level governance and the backtest that serve fraud prevention. The matrix screen is Compliance’s workplace for the day to day; the editor is the workplace of whoever designs the detection.

API

Everything the screen does is available through the API, with the same validations and the same approval: reading the catalog in each language it is translated into, reading and writing parameters, querying the history. The institution can integrate parametrization into its own governance process.

What Compliance sees after parametrizing

An approved change applies from the next evaluation and the next round of the per-entity evaluator. The alert list shows the alerts produced with the new parameters, and the Desk receives the updated severity and SLA on the next dispatch. When a threshold or window change needs to be validated before it applies, the batch history replay allows measuring the effect before approval.