INTRODUCTION: FROM DETECTION TO RESPONSE

In Lessons 8.1 through 8.5, we built the fraud detection infrastructure—the anomaly detection, device fingerprinting, behavioral biometrics, AML rules, machine learning models, and the unified decision engine. The system now makes a decision (Allow, Challenge, Block) for every transaction within 13ms.

However, detection is only the first half of the story. The second half is response. When the system blocks a transaction, what happens next? When a transaction is challenged, how does the PSU authenticate? When the AML rule engine generates a Suspicious Activity Report (SAR), how is it investigated and submitted to the Financial Intelligence Unit (FIU)? How do we know if the fraud detection system is working correctly? Are we detecting all fraud? Are we generating too many false positives?

Fraud Monitoring and Analytics provides the visibility into the system’s performance. It defines the Key Performance Indicators (KPIs): Detection Rate (the percentage of actual fraud that is detected), False Positive Rate (the percentage of legitimate transactions that are flagged), Average Response Time (the time to make a decision), and Case Volume (the number of transactions flagged for manual review). These KPIs are monitored on a real-time dashboard (Grafana, Kibana), allowing the fraud team to spot anomalies in the fraud patterns and adjust the system’s thresholds.

Incident Response is the process of handling a confirmed fraud case. When a transaction is blocked, the ASPSP must:

1. Notify the PSU: Send an alert (email, SMS) explaining why the transaction was blocked.

2. Freeze the Account: Temporarily lock the PSU’s account to prevent further fraudulent activity.

3. Escalate to Investigation: Assign a fraud investigator to review the case.

4. Report to Regulator: If the fraud is significant, report to the FCA or other regulators.

5. Recover Funds: Initiate a funds reversal (if possible).

This lesson formalises the Fraud Monitoring and Incident Response operational layer. We define the Fraud KPI formulas (Detection Rate, False Positive Rate, Mean Time to Detect, Mean Time to Respond). We design the Real-Time Analytics Dashboard using Grafana, with visualisations of the fraud rate, the distribution of risk scores, the top fraud types, and the investigator workload. We implement the Alerting Pipeline—when the fraud rate exceeds a threshold (e.g., > 1% of transactions), the engineering team is paged. We also define the Incident Response Playbook, a documented procedure for handling a confirmed fraud case, including the communication flow (PSU, TPP, regulator), the account freezing steps, and the funds recovery process.

LEARNING OBJECTIVES

1. Define the Fraud KPIs—deriving the formulas for Detection Rate (TP / (TP + FN)), False Positive Rate (FP / (FP + TN)), Mean Time to Detect (MTTD) (the time from the fraud event to the system flagging it), Mean Time to Respond (MTTR) (the time from the flag to the block/challenge), and Investigator Workload (the number of cases per investigator per day). We will quantify the target values: Detection Rate > 95%, False Positive Rate < 10%, MTTD < 100ms, MTTR < 5s (automated), Investigator Workload < 50 cases/day.

2. Design the Real-Time Analytics Dashboard—building a Grafana dashboard with panels for: (1) Fraud Rate over time, (2) Risk Score Distribution, (3) Top Fraud Types (by rule or ML feature), (4) Investigator Workload (cases assigned/open/closed), (5) System Latency (p95 decision time). We will define the data source (Elasticsearch or Prometheus) and the query languages (PromQL, LogQL).

3. Implement the Alerting Pipeline—defining alerts: (1) Fraud Rate > 1% (page the engineering team), (2) False Positive Rate > 15% (investigate rule thresholds), (3) Decision Latency > 30ms (performance regression), (4) Engine Circuit Breaker Open (failure of a detection engine). We will use AlertManager (Prometheus) to send alerts to PagerDuty/Opsgenie.

4. Formalize the Incident Response Playbook—defining a documented procedure for handling a confirmed fraud case. The playbook will have 5 phases: (1) Detection (system blocks the transaction), (2) Notification (PSU and TPP are alerted), (3) Investigation (fraud investigator reviews the case), (4) Resolution (funds reversal or account unfreeze), and (5) Post-Mortem (root cause analysis). We will quantify the SLAs: PSU notified within 10 minutes, investigation completed within 24 hours, funds reversal initiated within 48 hours.

5. Design the SAR Automation Pipeline—integrating the AML rule engine (Lesson 8.3) with the case management system (e.g., Salesforce, ServiceNow). When a suspicious activity is detected, a case is automatically created, assigned to an investigator, and (if confirmed) submitted to the FIU via the goAML API. We will quantify the end-to-end latency of SAR submission: detection (< 1s), case creation (5s), investigation (24-48h), submission (< 5s).

6. Quantify the Cost of Fraud and the ROI of the Detection System—deriving the total fraud losses avoided by the system, using the formula: Fraud_Reduction = (Fraud_Rate_Without_System - Fraud_Rate_With_System) × Total_Transaction_Volume × Avg_Fraud_Loss. We will prove that the system pays for itself within 6 months.

PART 1: THE FRAUD KPIs — Measuring What Matters

We define the core KPIs that the fraud team uses to monitor the system’s performance.

Data Collection:
We log every decision (Allow, Challenge, Block) along with the ground truth (we later learn if the transaction was fraud through chargebacks or customer complaints). The KPIs are computed daily.

PART 2: THE REAL-TIME ANALYTICS DASHBOARD — Grafana + Prometheus

The fraud team needs a real-time dashboard to monitor the system’s health.

Dashboard Panels:

1. Fraud Rate Over Time (line chart):

   • sum(rate(fraud_decisions_total{type="Block"}[5m])) / sum(rate(transactions_total[5m]))

   • Alert: if > 1%.

2. Risk Score Distribution (histogram):

   • histogram_quantile(0.95, sum(rate(fraud_risk_score_bucket[5m])) by (le))

   • Shows the 95th percentile risk score.

3. Top Fraud Types (bar chart):

   • topk(5, sum by (fraud_type) (rate(fraud_alerts_total[1h])))

   • Shows which rules or ML features are triggering the most alerts.

4. Investigator Workload (gauge):

   • sum(fraud_cases_open)

   • Alert: if > 200 open cases.

5. System Latency (heatmap):

   • histogram_quantile(0.95, sum(rate(fraud_decision_latency_bucket[5m])) by (le))

   • Alert: if > 30ms.

Data Source: Prometheus scrapes metrics from the fraud engines. Grafana visualises the metrics.

PART 3: THE ALERTING PIPELINE — Paging the On-Call Engineer

We define alerts that trigger when the system’s health degrades.

AlertManager Configuration:

groups:
  - name: fraud_alerts
    rules:
      - alert: FraudRateSpike
        expr: rate(fraud_decisions_total{type="Block"}[5m]) / rate(transactions_total[5m]) > 0.01
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Fraud rate spike detected"

PART 4: THE INCIDENT RESPONSE PLAYBOOK — Handling a Confirmed Fraud Case

When the system blocks a transaction (or a human investigator confirms fraud), the incident response playbook is triggered.

Phase 1: Detection (Automated) :

• System flags the transaction (Block).

• A case is automatically created in the case management system (ServiceNow).

• The PSU is notified via email/SMS.

Phase 2: Notification (Automated) :

Subject: Suspicious Transaction Alert

Dear PSU,

We detected a suspicious transaction on your account.
- Amount: £1,000.00
- Payee: Acme Corp
- Date: 2026-08-04

If this was NOT you, please contact us immediately at 0800-123-456.
If this was you, you can ignore this message.

To block the transaction, please log in to your account.

Phase 3: Investigation (Human) :

• A fraud investigator is assigned to the case (within 1 hour).

• The investigator reviews the transaction details, the customer history, and the detection engine logs.

• The investigator decides: (1) Confirmed Fraud → proceed to Resolution, (2) False Positive → close case and unblock the account.

Phase 4: Resolution :

• If Confirmed Fraud: The account is frozen. Funds are reversed (if possible). The regulator is notified (if required).

• If False Positive: The account is unblocked. A credit is issued (if a charge was wrongly applied).

Phase 5: Post-Mortem :

• The fraud team conducts a root cause analysis.

• What caused the fraud (e.g., a new phishing attack)? What could we have done differently?

• The findings are documented and used to improve the detection system.

SLAs:

• PSU notified: within 10 minutes.

• Investigation assigned: within 1 hour.

• Investigation completed: within 24 hours.

• Funds reversal initiated: within 48 hours.

PART 5: THE SAR AUTOMATION PIPELINE — Submitting to the FIU

When the AML rule engine detects a suspicious transaction (e.g., structuring), a Suspicious Activity Report (SAR) must be submitted to the Financial Intelligence Unit (FIU).

The SAR Automation Flow:

1. Rule Trigger: The AML rule engine fires (e.g., structuring detected).

2. Case Creation: A case is created in the case management system with the transaction details.

3. Investigation: The AML investigator reviews the case. If suspicious, they prepare the SAR.

4. SAR Generation: The case management system automatically generates the SAR XML (in the FIU’s required format, e.g., goAML).

5. SAR Submission: The SAR is submitted to the FIU via an API (e.g., the goAML web service).

6. SAR Confirmation: The FIU acknowledges receipt. The case is closed.

SAR XML Payload (Simplified) :

<?xml version="1.0" encoding="UTF-8"?>
<SAR>
    <ReportID>SAR-2026-001</ReportID>
    <ReportingEntity>Bank ABC</ReportingEntity>
    <DateSubmitted>2026-08-04</DateSubmitted>
    <Transaction>
        <TransactionID>txn-123</TransactionID>
        <Amount>9500.00</Amount>
        <Currency>GBP</Currency>
        <Date>2026-08-03</Date>
        <Payee>Acme Corp</Payee>
        <Payer>PSU-456</Payer>
    </Transaction>
    <SuspicionReason>Structuring detected (multiple payments under 10,000 threshold)</SuspicionReason>
    <InvestigatingOfficer>John Doe</InvestigatingOfficer>
</SAR>

Regulatory Timeline:

• The report must be submitted within 24 hours of the suspicion (UK Money Laundering Regulations).

• The investigation must be completed within 48 hours.

PART 6: THE ROI OF THE FRAUD DETECTION SYSTEM — Quantifying the Value

We calculate the Return on Investment (ROI) of the fraud detection system.

Assumptions:

• Total annual transaction volume: 100 million transactions.

• Average fraud rate without the system: 0.5% (industry average for online banking).

• Average fraud loss per successful fraud: £500.

• Annual fraud losses without system: 100M × 0.005 × £500 = £250,000,000.

With the System:

• Fraud rate reduced to 0.05% (a 10x reduction due to the detection system).

• Annual fraud losses with system: 100M × 0.0005 × £500 = £25,000,000.

Fraud Reduction:
£250M - £25M = £225M saved per year.

Cost of the System:

• Development: £2M (one-time).

• Infrastructure (servers, Redis, ML training): £500k/year.

• Operations (investigation team of 10): £1M/year.

• Total annual cost: £1.5M.

ROI:
ROI = (£225M - £1.5M) / £1.5M = 14900%.

Conclusion: The fraud detection system pays for itself within 2 days of operation.

CLOSING — THE COMPLETE FRAUD MANAGEMENT FRAMEWORK

You have now completed the entire fraud management stack: detection (anomaly, device, behavior, AML rules, ML), orchestration (parallel scoring, meta-classifier, decision engine), and response (monitoring, analytics, incident response, SAR automation). The system detects 95% of fraud with a 10% false positive rate, adds < 13ms of latency, and saves over £200M per year.

Key Takeaways:

• KPIs: Detection Rate > 95%, FPR < 10%, Latency < 13ms.

• Dashboard: Grafana + Prometheus for real-time monitoring.

• Alerting: PagerDuty for critical alerts (fraud rate spike, latency spike).

• Incident Response: 5-phase playbook with SLAs.

• SAR Automation: goAML API integration.

• ROI: 14900%.

Transition to Module 9: With the fraud detection and AML compliance fully implemented, we now turn to Data Quality, Deduplication, and Merchant Enrichment. Module 9 will teach you how to handle missing data, deduplicate merchant names, and enrich transaction descriptions with meaningful metadata (merchant logos, categories, geolocation) to improve the end-user experience in budgeting apps.