AML in the Guardline Suite
What it is
Section titled “What it is”The Guardline Suite handles fraud prevention and anti-money laundering (AML) on the same platform, with the same decision engine and the same interface. Fraud and AML are two domains of the same engine: each has its own workflow, its own rules and its own thresholds, and the institution configures both in the same place, with the same governance and the same audit trail.
AML adds to the engine what fraud prevention does not need: a catalog of scenarios with regulatory identity, an alert that is a document and not just a decision, the consolidation of several triggers into a single case, and a round trip with the Decision Desk, where the investigation, the committee and the preparation of the case dossier take place.
Everything that depends on the jurisdiction is catalog data: the scenarios and their regulatory references, the document types, the operation types and the screens, in the language of the jurisdiction. The platform ships today with catalogs for Brazil and Argentina, described in the Portuguese edition and in the Spanish edition.
Who does what
Section titled “Who does what”The boundary between the modules is fixed and is what makes the operation auditable.
| Module | Responsibility in AML |
|---|---|
| Fraud Prevention Platform (FPP) | Receives the transactions, evaluates each one against the AML workflow, produces the alert with scenario, severity and evidence, consolidates repeated triggers and dispatches the alert to the Desk. Offers Compliance the scenario parametrization and the alert list. |
| Case Management Platform (CMP) | Owns the case. Receives the alert, opens or updates the case, runs triage, investigation, review and committee, organizes the case dossier and returns the verdict to the FPP. |
| Onboarding Platform (ONP) | Owns the customer registration and the customer risk matrix. Screens for PEP, sanctions and background during onboarding and delivers those attributes, with provenance, to the other modules. |
| Institution | Decides in the committee, files the report with its regulator using the dossier the Desk prepared, and maintains its own lists, loaded manually or through the API. |
The end-to-end flow
Section titled “The end-to-end flow”- The transaction comes in through the real-time integration or through the batch queue, with a typed document and explicit country and currency.
- The engine evaluates the transaction in the AML domain, with the same enrichment, the same behavioral baseline and the same windows that serve fraud.
- A rule that triggers produces an alert, because every AML rule points to a scenario in the catalog. The alert is born with the scenario code, the severity configured by Compliance and the transactions that support it.
- The per-entity evaluator runs periodically and produces alerts that no single transaction would produce: accumulations by subject, scenario and window.
- Repeated triggers of the same subject in the same scenario consolidate into a single alert within the scenario’s window. The first opens the case; the following ones add evidence to the same case.
- Medium and high severity alerts go to the Decision Desk; low severity alerts are recorded and aggregated in the FPP, available to Compliance.
- The Desk runs the case through to the committee and, when applicable, prepares the dossier with which the institution files the report with its regulator.
- The verdict comes back: the closure at triage, the committee decision and the record of the filing reach the FPP, update the alert state and enter the customer history.
Why the platform is built this way
Section titled “Why the platform is built this way”One engine, two domains. The institution does not maintain two systems, two customer bases and two rule registries. The behavioral baseline that fraud builds serves AML, and the fraud decision is never affected by an active AML workflow.
The alert is a document. Each alert carries a subject with typed document and country, a scenario with code and catalog reference, a severity with its origin, a window, evidence stored as a snapshot of the transactions, and a state. It is what an investigation and a regulatory dossier need.
The catalog governs. Rules without a scenario produce no alert. This prevents the noise of alerts without a typology and gives Compliance a single place to enable, disable and parametrize each scenario, with approval and history.
There is one Desk. The case, the committee and the case dossier live in the CMP. The FPP does not duplicate the desk; it feeds it and receives back from it, and the institution files the report with its regulator from the dossier the Desk prepared.
The jurisdiction is first-class. Document, counterpart, operation type, scenario and screen are resolved by the tenant’s jurisdiction, never by a hidden default.
Every engine change is proven. Before reaching an institution’s environment, each change to the engine goes through a differential round: the same traffic evaluated by the current version and by the new one, with zero decision difference required for the fraud path. The report of that round accompanies the delivery.
How this section is organized
Section titled “How this section is organized”| Page | What it covers |
|---|---|
| Profiles and domains | How a tenant is fraud, AML or both, and what changes in each case |
| Ingestion and identity | How the transaction comes in, identity documents and counterpart identifiers of the jurisdiction, batch and replay |
| Scenarios and typologies | The catalog by jurisdiction, the typology families it expresses and how a rule becomes an alert |
| Behavior and windows | Behavioral baseline, windows relative to the transaction date, circular flows and the per-entity evaluator |
| Alerts | The alert object, the two types, consolidation and the list in the FPP |
| Decision Desk and the return path | Dispatch to the CMP, the case, the committee and the verdict that returns |
| Parametrization and governance | The Compliance matrix screen, approval and audit |
Version 18, updated on