Ingestion and identity

Two entry points

The FPP receives transactions through two paths, which converge on the same engine and the same database.

Real time. The institution sends each transaction at the moment it happens and receives the decision in the same call. Fraud prevention customers already integrated use the existing analysis contract, which does not change. For AML, the platform exposes a canonical transaction endpoint, with the fields that money laundering requires and that transactional fraud prevention did not need: document type, country, operation family, explicit currency and the payload signals described below.

Batch. The institution sends sets of transactions (initial load, history, reprocessing) to a queue. The queue delivers to the engine in business date order, keeps the state of each item, produces a rejection report and, when the batch is historical, runs the two-phase replay: first the history builds the behavioral baseline, then the transactions are scored in order. The batch load does not affect the latency of real-time evaluation.

The data path is the same whatever the tenant’s profile: a transaction sent to two instances produces the same result, and neither of them refuses data because of deployment configuration.

Jurisdiction-neutral identity

AML depends on knowing who is moving the money. The platform handles identity without inference and without a hidden default.

Element	How it is handled
Document type	First-class enumeration covering the tax identifiers, identity documents and passports of the jurisdiction. The type is explicit in the payload; the platform never infers the type from the number of digits.
Country	Present on the customer and on the account. The tenant declares its country and its currency, and that is what defines what an international operation is.
Counterpart	Identified by typed document or by the account identifiers and instant-payment keys of the jurisdiction’s rails. An unexpected identifier is recorded as it came and never interrupts the evaluation.
Currency and amount	The amount comes with explicit unit and currency. Inside the engine every amount is handled in whole cents, which eliminates scale errors between the transaction amount, the behavioral baseline and the velocity windows.

Operation types and families

Operation types are a catalog by jurisdiction, versioned and translated, organized into families: transfer, check, card, cash and foreign exchange, foreign trade. The behavioral baseline and the scenarios rely on the family, not on the rail, and adding a new rail is catalog data, with no system change.

Payload signals

The canonical transaction carries signals that the AML scenarios consume directly as condition fields:

• the institution’s product to which the operation belongs;
• the customer’s economic activity, with the declared source;
• the channel the operation originated from;
• the cash flag, when the operation involves physical currency;
• crypto counterpart, when the counterpart is a virtual asset service provider;
• betting origin, when the funds come from betting houses.

Each signal becomes a condition field in the rule editor, available whatever the jurisdiction.

Idempotency and rejections

Every transaction carries the institution’s external identifier. Resending the same transaction neither duplicates nor re-evaluates it. In batch, each item has a queryable state, and rejected transactions appear in the rejection report with the reason, available by file and by API.

Synthetic data for acceptance testing

Guardline has a synthetic traffic generator, with one mode per jurisdiction served, that produces a customer portfolio, counterparts and sequences of operations designed to trigger each scenario in the catalog. It is used in the acceptance testing of the integration and in product demonstrations before any real data, and the synthetic history is flagged as such in the database.