Fraud Prevention Platform (FPP)
What it is
Section titled “What it is”The Fraud Prevention Platform (FPP) is the Guardline Suite's module for fraud and money laundering prevention. It operates under the FRAML concept (Fraud Prevention + AML, Anti-Money Laundering), uniting fraud and AML on the same platform, in the same decision engine, and in the same interface. The institution configures rules, policies, and thresholds in one place, covering both transactional fraud scenarios and money laundering patterns.
The FPP evaluates transactions in real time, continuously monitors customer behavior, manages restrictive lists, and provides backtesting with feedback before any 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, profile updates, and other non-monetary events that may indicate risk
Both types pass through the same decision engine and can be combined into compound rules.
Features
Section titled “Features”Decision engine
Section titled “Decision engine”The decision engine is configured by the compliance team through a graphical interface in the 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 routed for review
- Risk policies: rule groupings 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 fire specific actions (notifications, blocks, case creation)
- External source integrations: connection to data providers to enrich the evaluation
- Time windows: rules that consider accumulations over configurable periods (for example, "more than 5 transactions in the last 2 hours")
Evaluation response: each evaluation returns the result (approve, block, alert) along with 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 customer's experience.
Backtest
Section titled “Backtest”Every rule change in the engine can run a backtest before going live. The system runs the new rule against up to 1 million historical transactions and reports:
- 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-tier governance
Section titled “Three-tier governance”Every change to the decision engine follows a mandatory governance flow:
| Tier | 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 goes live without passing through all three tiers. The history of every 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 to its internal policy
- Create additional rules through 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 reference for anomaly detection. The approach is statistical and deterministic, based on standard deviations and percentiles computed over each customer's individual history.
How it works
Section titled “How it works”1. Baseline construction. The system observes each customer's usage pattern: typical transaction amounts, frequency, times of day, locations, devices, and habitual counterparties. 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 flags 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 routed 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 |
|---|---|
| Unusual amount | Transaction above the customer's usual pattern |
| Unusual frequency | Transaction volume outside the pattern in a short period |
| Unusual time | Operation at a time the customer has never used |
| Divergent geolocation | Transaction originating from a location incompatible with the profile |
| New high-value counterparty | High-value transfer to a counterparty without a 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 a transaction. The baseline is updated continuously, which enables:
- Permanent KYC: the customer's risk profile evolves with their behavior, with no dependence on manual periodic reviews
- Detection of gradual drift: patterns that change slowly over weeks or months are identified
- Investigation context: when a case reaches the analyst in the CMP, the behavioral history is already available as part of the dossier
List management
Section titled “List management”The FPP uses the centralized list management from the Core:
| List type | Function |
|---|---|
| Blocklist | Automatic block of transactions involving listed entities |
| Watchlist | Enhanced monitoring without automatic blocking |
| Greylist | Temporary observation with specific rules |
| PEP | Politically Exposed Persons, family members, and close associates |
| Sanctions | International lists (OFAC, UN, EU) and national lists (BACEN/BCRA) |
External lists are updated in real time. The institution can also maintain its own lists, with import and export. All changes are recorded with full history.
Continuous monitoring with AML patterns
Section titled “Continuous monitoring with AML patterns”The FPP can be configured for continuous transaction monitoring, addressing both fraud prevention and AML/CFT requirements:
- Real-time evaluation of every transaction against rules and baselines
- Context accumulation across the day (for example, value transacted in the last 24h)
- Correlation between transactions from the same customer over configurable time windows
- Compound alerts that consider multiple transactions in sequence
- Monitoring patterns aligned with the requirements of BACEN/BCRA Circular 3.978