v2.0

GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here!

Watch the launch videoWatch
gorules
Book a demoGet started

Real-Time Fraud Detection

Advanced transaction monitoring system that identifies suspicious financial activities using location analysis, spending patterns, and behavioral anomalies.

Solution

This fraud detection system provides immediate identification of potentially suspicious financial transactions by examining multiple risk factors simultaneously. The solution analyzes transaction location against the customer's home country and travel history to spot geographic anomalies. It compares current transaction amounts with established spending patterns, flagging values that significantly exceed historical averages or maximum thresholds.

The system evaluates transaction timing, identifying unusual activity during non-standard hours, and monitors transaction frequency to detect rapid successive purchases that may indicate fraudulent behavior. Each transaction receives a calculated risk score with clear reason codes, enabling immediate action for high-risk transactions while minimizing interruptions for legitimate activity. This balanced approach helps financial institutions reduce fraud losses while maintaining positive customer experiences by limiting false positives.

How it works

The fraud detection graph processes transactions through several key evaluation steps:

  1. Input Processing: Captures transaction details (amount, location, time) and user profile data (home country, spending patterns, frequent locations).
  2. Location Analysis: Compares transaction location against customer's home country and frequently visited locations.
  3. Amount Verification: Evaluates transaction value against customer's average and maximum historical spending.
  4. Time Pattern Matching: Identifies transactions occurring outside normal activity hours.
  5. Frequency Monitoring: Detects unusual patterns of multiple transactions in short timeframes.
  6. Risk Scoring: Calculates a numeric risk score based on combined risk factors.
  7. Decision Logic: Determines whether to allow, flag for review, or block transactions based on configured thresholds.

Where teams use it

  • Credit card transaction monitoring
  • Bank transfer fraud detection
  • E-commerce payment protection
  • Mobile payment security
  • Cross-border transaction validation
  • ATM withdrawal monitoring
  • Corporate expense anomaly detection
  • New account fraud prevention

Inside the decision model

Real-Time Fraud Detection ships as a JDM decision graph with 3 nodes, 1 decision table and 7 rules. Download it, load it into GoRules, and run it as-is on Zen Engine.

Decision graph3 nodes · read-only
input requesttable detectSuspiciousActivityexpression calculateRiskScore
01

Request

input

Two objects arrive in the request: transaction, with the amount, location, time, and recentCount under evaluation, and userProfile, which supplies the customer's baseline of homeCountry, frequentCountries, averageTransactionAmount, and usual activity hours.

Sample requestJSON 
{
  "transaction": {
    "id": "tx-28473",
    "amount": 1250,
    "location": "Germany",
    "time": "23:45",
    "recentCount": 4,
    "merchantCategory": "Electronics",
    "date": "2023-03-18"
  },
  "userProfile": {
    "id": "user-5932",
    "homeCountry": "USA",
    "frequentCountries": [
      "Canada",
      "UK"
    ],
    "averageTransactionAmount": 350,
    "maxTransactionAmount": 800,
    "usualMerchantCategories": [
      "Groceries",
      "Dining",
      "Retail"
    ],
    "usualTransactionTimeRange": [
      "08:00",
      "21:00"
    ]
  }
}
02

Detect Suspicious Activity

table

Seven rows run under a first hit policy, ordered so the strongest combinations win: a transaction.amount over 4x userProfile.averageTransactionAmount with recentCount > 3 scores 80, an unusual transaction.location (outside userProfile.homeCountry and frequentCountries) combined with an amount over 3x average scores 75, and a foreign transaction at night between time('22:00') and time('06:00') with an amount over 2x average scores 65, all flagged 'high'. Milder single-signal rows score 50 and 45 as 'medium', and the empty catch-all returns 0 with 'low' and 'No suspicious patterns detected'.

Layering geography, spend deviation, timing, and velocity is how card issuers actually monitor transactions, since no single signal separates fraud from travel or a large purchase. The multiplier approach (2x to 4x of the customer's own average) adapts thresholds to each profile instead of using a fixed dollar cap, which keeps false positives down for high spenders; the specific multipliers are business calibration rather than any regulatory standard.

Decision tablefirst hit policy
Transaction Locationtransaction.locationTransaction Amounttransaction.amountTransaction Timetransaction.timeRecent Transactions Counttransaction.recentCountRisk Scorefraud.riskScoreRisk Flagfraud.flagRisk Reasonfraud.reason
!= userProfile.homeCountry and != userProfile.frequentCountries> userProfile.averageTransactionAmount * 3--75'high''Unusual location with amount significantly above average'
!= userProfile.homeCountry> userProfile.averageTransactionAmount * 2time($) > time('22:00') and time($) < time('06:00')-65'high''Foreign transaction at night with high value'
-> userProfile.averageTransactionAmount * 4-> 380'high''Multiple high-value transactions in short timeframe'
!= userProfile.homeCountry--> 570'high''Multiple foreign transactions in short timeframe'
-> userProfile.averageTransactionAmount * 2time($) > time('22:00') and time($) < time('06:00')-50'medium''Night transaction with amount above average'
---> 345'medium''Multiple transactions in short timeframe'

+1 more row in the downloadable template

03

Calculate Risk Score

expression

Three operational outputs come out of the table's verdict: finalRiskScore normalizes fraud.riskScore with number(), requiresReview is true when fraud.flag == 'high' or the score exceeds 60, and blockTransaction only trips above 75. Separating review from blocking lets the institution hold marginal transactions for analysts while reserving hard declines for the strongest signals.

Expressions4 fields
finalRiskScorenumber(fraud.riskScore)
requiresReviewfraud.flag == 'high' or $.finalRiskScore > 60
blockTransaction$.finalRiskScore > 75
reasonfraud.reason

Other Financial templates

View all templates
Financial

Loan Approval

Automated system that evaluates credit scores, income, debt ratios, and employment history to determine mortgage eligibility and personalized interest rates.

Financial

Customer Onboarding KYC Verification

Automated compliance checks that validate identity documents, screen against watchlists, and apply risk-based due diligence during onboarding.

Financial

Portfolio Risk Monitor

Dynamic portfolio management system that continuously evaluates investment holdings against market conditions to implement appropriate risk mitigation actions.

Make this template
your own.

Load Real-Time Fraud Detection into GoRules, adjust the rules to your policy, and ship it behind your own API.

Get started Book a demo