Fraud Prevention Platform (FPP)
What it is
Section titled “What it is”The Fraud Prevention Platform (FPP) is the fraud and money laundering prevention module of the Guardline Suite. It operates under the FRAML concept (Fraud Prevention + Anti-Money Laundering), bringing fraud and AML together on the same platform, in the same decision engine and in the same interface. This means the institution configures rules, policies and thresholds in a single place, both for transactional fraud scenarios and for money laundering patterns.
The FPP evaluates transactions in real time, monitors customer behavior continuously, manages restrictive lists and offers backtest with feedback before every rule change.
Supported event types
Section titled “Supported event types”The FPP processes two event types:
- Monetary transactions: Pix, TED, DOC, boleto, card, foreign exchange and any other financial operation
- Customer events: password change, new device, registration data change and other non-monetary events that may indicate risk
Both types go through the same decision engine and can be combined in composite rules.
Features
Section titled “Features”Decision Engine
Section titled “Decision Engine”The decision engine is configured by the compliance team through the graphical interface in the admin panel, with no code required. The institution defines:
- Multi-stage workflows: evaluation sequences with multiple stages, each with its own rules and actions
- Rules with conditions: deterministic logic that defines when a transaction is approved, rejected or referred for review
- Risk policies: groupings of rules by transaction type, channel, customer segment or product
- Thresholds: score thresholds that trigger automatic actions (approve, block, alert, escalate)
- Scores: definition of how risk is calculated, which variables feed the score and which weights to apply
- Triggers: conditions that trigger specific actions (notifications, blocks, case creation)
- Integrations with external sources: connection to data providers to enrich the evaluation
- Time windows: rules that consider accumulations over configurable periods (e.g., “more than 5 transactions in the last 2 hours”)
Evaluation response: each evaluation returns, in addition to the result (approve, block, alert), the engine’s breakdown, detailing every item that scored and its contribution to the final score. This lets the analyst and the institution understand exactly why a transaction was flagged.
Response time operates under a contractual SLA of P95 at 300ms, allowing real-time evaluation with no perceptible impact on the end user’s experience.
Backtest
Section titled “Backtest”Every rule change in the engine can run through a backtest before it takes effect. The system runs the new rule against up to 1 million historical transactions and shows:
- How many transactions would be affected
- How many additional alerts would be generated (or reduced)
- Impact on the volume of false positives and false negatives
- Comparison between the current policy and the proposed one
The backtest is part of the rule editing flow, not a separate tool. The team sees the impact before submitting the rule for approval.
Three-level governance
Section titled “Three-level governance”Every change to the decision engine follows a mandatory governance flow:
| Level | Role | Action |
|---|---|---|
| 1 | Analyst | Creates or edits the rule |
| 2 | Supervisor | Reviews and validates the change |
| 3 | Administrator | Approves and activates in production |
No rule takes effect without going through all three levels. The history of each change (who edited, who reviewed, who approved, backtest result) is recorded in the audit trail.
Pre-configured rules
Section titled “Pre-configured rules”The FPP ships with a set of fraud prevention and AML rules already configured, based on regulatory best practices and common scenarios. The institution can:
- Use the rules as they are to start operating
- Adapt thresholds and conditions according to its internal policy
- Create additional rules from the interface
UBA (User Behavior Analytics)
Section titled “UBA (User Behavior Analytics)”UBA monitors each customer’s behavior over time and builds individual baselines that serve as a reference for anomaly detection. The approach is statistical and deterministic, based on standard deviations and percentiles calculated over each customer’s individual history.
How it works
Section titled “How it works”1. Building baselines. The system observes each customer’s usage pattern: typical transaction amounts, frequency, times of day, locations, devices, usual counterparts. This data forms an individual behavioral profile.
2. Anomaly detection. When a transaction deviates from the customer’s baseline beyond the configured statistical thresholds (standard deviations, percentiles), the system identifies the anomaly. The deviation is quantified and feeds the risk score.
3. Behavioral segmentation. Customers are grouped into segments based on similar behavior patterns. This allows rules and thresholds to be calibrated per segment, reducing false positives.
4. Automatic alerts. Anomalies generate alerts that can be forwarded to the Case Management Platform (CMP) or handled by additional engine rules.
Examples of detected deviations
Section titled “Examples of detected deviations”| Deviation type | Description |
|---|---|
| Atypical amount | Transaction above the customer’s usual pattern |
| Uncommon frequency | Transaction volume outside the usual pattern in a short period |
| Unusual time | Operation at a time of day the customer has never used |
| Divergent geolocation | Transaction originating from a location inconsistent with the profile |
| New high-value counterpart | High-value transfer to a counterpart with no relationship history |
| Device change | Operation from an unknown device |
UBA and continuous monitoring
Section titled “UBA and continuous monitoring”UBA does not operate only at the moment of the transaction. The baseline is updated continuously, which allows:
- Permanent KYC: the customer’s risk profile evolves with their behavior, without depending on periodic manual reviews
- Gradual degradation detection: patterns that change slowly over weeks or months are identified
- Context for investigation: when a case reaches the analyst in the CMP, the behavioral history is already available as part of the case file
List management
Section titled “List management”The FPP uses the centralized list management of the Core:
| List type | Function |
|---|---|
| Blocklist | Listed entities trigger the blocking rules configured by the institution |
| Watchlist | Enhanced monitoring without blocking |
| Greylist | Temporary observation with specific rules |
The lists belong to the institution: loaded manually through the panel or through the API, with import, export and a history of every change. PEP status and presence on sanctions lists reach the FPP as customer attributes, with provenance, screened by the Onboarding Platform during registration.
Anti-money laundering (AML)
Section titled “Anti-money laundering (AML)”AML is a domain of the same engine, with its own workflow, rules and thresholds, and adds what money laundering requires: a catalog of scenarios by jurisdiction (Brazil and Argentina), per-transaction and per-entity alerts with evidence and severity, consolidation by subject and scenario, dispatch to the Decision Desk and the verdict back into the customer history. Compliance parametrizes the scenarios in a matrix view, without redeploy and with approval.
The full description is in the AML section.
Version 18, updated on