Skip to main content
The Fraud Prevention module monitors transactions against configurable thresholds and flags anything that deviates from expected behavior. It gives your team a chance to review and act on suspicious activity before points are permanently credited or redeemed.

What it does

CapabilityDescription
Anomaly detectionFlags transactions that exceed configured thresholds based on points volume, transaction frequency, or product-specific limits
Real-time notificationsAlerts administrators to unusual accrual and redemption activity as it happens
Pending review queueHolds flagged transactions so a human can approve or reject before points are finalized
Loss mitigationEnables corrective action before suspicious activity escalates into financial damage

How to enable Fraud Prevention

Fraud Prevention must be activated at three levels:
1

Environment configuration (Level 1)

This foundational step is performed by the Loyalife team or your DevOps team in the environment configuration file. It cannot be done from within the Loyalife UI. Contact Loyalife support to request this activation.
2

Module activation (Level 2)

Once the environment is configured, navigate to Fraud Prevention in the left sidebar and enable the module from the available options.
3

Threshold configuration (Level 3)

After the module is active, go to Fraud Prevention → Threshold Settings to define the detection parameters. Once saved, the system begins monitoring all transactions against those thresholds.
All three levels must be active for fraud detection to function. Completing only Level 2 without Level 1 environment configuration will not enable monitoring.

Anomaly detection

Anomaly detection works by comparing incoming transaction data against the thresholds you define per product code. When a transaction exceeds a threshold, it is flagged as anomalous and sent to the Pending Transactions queue for manual review.

How thresholds are structured

Thresholds are configured at two levels:
LevelScopeExample
GlobalApplies to all transactions, regardless of product codeFlag any member who earns more than 10,000 points in 30 days
Product code-specificApplies only to transactions tagged with a specific product codeFlag any credit card transaction above 5,000 points, but allow travel bookings up to 20,000
Product-code-specific thresholds override the global threshold for transactions that match that product code.
Product codes must exist in the Rule Engine’s Attributes Manager before they can be used in anomaly detection thresholds. If no product codes are defined, the threshold settings interface will prompt you to add product codes first via Rule Engine → Attributes → Product Codes.

Monitored dimensions

DimensionWhat is checked
Points per transactionA single transaction that would award more than the configured maximum
Cumulative points in windowTotal points earned within a rolling time window (e.g., past 7 days)
Redemption amountA single redemption that exceeds the configured limit

What happens when a transaction is flagged

  1. The transaction is held in Pending Transactions — it does not post points to the member’s account immediately.
  2. An administrator with the Fraud Review permission receives a notification.
  3. The reviewer can approve (allow the transaction and post points) or reject (discard the transaction).
  4. If no action is taken within the configured timeout, the transaction follows the default resolution path (approve or reject, as configured).
The Fraud Prevention section contains two menu items:
Menu itemDescription
Anomaly DetectionConfigure thresholds and view the anomaly detection settings
Pending TransactionsReview and action transactions that have been flagged by anomaly detection
In the navigation menu, Anomaly Detection and Fraud Prevention are distinct items — they map to the same underlying module. Editing either menu label in your program’s locale settings updates both.