Behavior and windows

Behavioral baseline (UBA)

The FPP builds an individual behavioral baseline for each customer from their history: typical amounts, frequency, times of day, usual counterparts, per operation family and per direction. The baseline is statistical and deterministic, based on percentiles and deviations calculated over the customer’s own history, and is updated continuously.

In AML, the baseline is the reference for “incompatible with the profile”: activity above the pattern, abrupt increase, dormant account that reactivates, new counterpart with a relevant amount. The same baseline that fraud prevention uses serves AML, without duplicated calculation.

Windows relative to the transaction date

Every engine window (velocity over the last hours, accumulation over the last days, baseline over the last months) is calculated relative to the business date of the transaction being evaluated, and not to the server clock.

For real-time operation this changes nothing: the transaction date and the moment of evaluation coincide. For AML this is what keeps the history honest:

• a batch history load builds the behavioral baseline in the order the operations happened;
• a reprocessing of past months produces the same windows it would have produced at the time;
• the institution can validate a new scenario against the history and obtain the result the scenario would give in production.

This change is accompanied by an equivalence proof: the same real-time traffic, evaluated by the previous version and by the new one, with zero decision difference. The report of that proof accompanies the delivery.

Circular flow and pass-through

The platform detects chains between counterparts with recursive queries over the tenant’s network of operations:

• pass-through: funds that enter and leave a subject within a short interval, with low dwell time;
• circular flow: funds that leave a subject and return to it through a chain of counterparts.

Both detections are rail-neutral (they apply to any operation family and to any account identifier or instant-payment key of the jurisdiction), work by document and by account, and have a window and a threshold configurable by parameter. The result reaches the engine as a condition field, available to any scenario.

Periodic per-entity evaluator

Not every typology can be seen in a single transaction. Structuring, abrupt increase and volume above the declared profile are accumulations. The per-entity evaluator is a periodic process that, for each active per-entity scenario in the catalog and for each subject with activity in the window, calculates the aggregate defined in the scenario (sum in cents or count of operations), compares it with the threshold and, when it is exceeded, records a per-entity alert with all the operations in the window as evidence.

Three properties of the evaluator matter for the operation:

• it reads the catalog: window, threshold and aggregate are the ones Compliance parametrized, with no hidden constant;
• it is idempotent: running twice on the same window creates no new alert, it only adds new evidence;
• it respects the platform: the cost of the queries is bounded and measured, so as not to interfere with real-time evaluation.

Monetary unit

Inside the engine every amount is handled in whole cents: the transaction amount, the behavioral baseline, the velocity windows and the aggregates. A condition that compares the operation amount with the customer’s limit compares two quantities in the same unit, without scale errors, whatever the local currency.