Real-Time Detection, Decisioning and Case Management

Introduction

Digital banking has compressed the time available to detect and contain fraud. A payment may be authorised, settled, and withdrawn from a customer account within seconds. Consequently, cybersecurity and fraud analytics teams must move beyond periodic review and construct decision systems that evaluate events continuously, select proportionate interventions, and preserve evidence for later investigation.

Real-time fraud control is not simply a matter of deploying a machine-learning model. It is an operating capability comprising data acquisition, feature computation, rules, risk scoring, decision orchestration, authentication, alert management, investigation, recovery, governance, and customer communication. A technically accurate model can still fail if data arrive too slowly, thresholds are poorly calibrated, alerts overwhelm investigators, or interventions unnecessarily damage legitimate customer relationships.

This chapter examines how banks design real-time detection and decisioning architectures; combine rules, scores, machine learning, and step-up authentication; optimise thresholds; and manage the complete alert-to-case lifecycle.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Explain the architecture and operating requirements of real-time fraud monitoring.
2. Distinguish rules, statistical scores, machine-learning models, and decision policies.
3. Design layered interventions, including step-up authentication and transaction holds.
4. Optimise thresholds using expected loss, customer friction, and operational capacity.
5. Construct an effective alert, investigation, evidence, escalation, and case-management process.
6. Evaluate governance, fairness, privacy, resilience, and regulatory risks.

1. The Real-Time Fraud-Control Problem

A real-time transaction decision must be made under uncertainty. At the moment a payment is submitted, the bank may observe the account, device, beneficiary, amount, location, channel, authentication history, and recent behavioural activity. It does not yet know with certainty whether the transaction is fraudulent. The system therefore estimates risk and chooses an action.

A useful abstraction is:

Here, x is the event and its available context, and D(x) is the decision. The available actions should not be treated as equivalent. Declining a payment may prevent loss but create customer harm; authentication may reduce uncertainty but introduce friction; delaying may permit manual review but affect service expectations.

The core design tension is between:

• Fraud loss: unauthorised payments, reimbursement costs, operational recovery costs, and reputational damage.
• False-positive cost: legitimate payments blocked or challenged.
• Latency: the time taken to collect data, compute features, score the event, and respond.
• Coverage: the proportion of relevant events evaluated.
• Investigation capacity: the number and quality of alerts analysts can process.

Real-time systems should therefore be evaluated as decision systems, not merely classifiers.

2. Reference Architecture

A bank's real-time monitoring architecture normally contains the following layers:

1. Event sources: payment gateways, core banking systems, card processors, mobile applications, online banking, ATM systems, customer-service platforms, identity providers, and cyber telemetry.
2. Event transport: authenticated APIs, message queues, and streaming platforms that deliver events with timestamps and identifiers.
3. Context and feature services: account history, device reputation, network intelligence, beneficiary age, velocity measures, and customer profile information.
4. Detection layer: deterministic rules, anomaly detection, supervised models, graph analytics, and external intelligence.
5. Decision orchestration: a policy engine that combines outputs and selects an action.
6. Intervention layer: step-up authentication, transaction holds, confirmation calls, declines, or case creation.
7. Case-management layer: alert triage, investigation, evidence, workflow, escalation, reporting, and closure.
8. Feedback and governance: confirmed outcomes, customer disputes, model monitoring, rule tuning, and audit trails.

Figure: A layered architecture for real-time fraud detection and decisioning.

2.1 Event and data engineering

The event record should have a stable identifier, event time, ingestion time, customer or account reference, channel, amount and currency, and outcome status. Event time and ingestion time must be distinguished because late or duplicated events can distort velocity controls. Idempotency controls prevent the same payment from being assessed twice or creating duplicate cases.

Features should be computed consistently in training and production. A feature such as “number of transfers in the previous 24 hours” must use only information available before the decision. Using later information creates target leakage and produces deceptively strong model results.

Low latency does not justify weak controls. Data must be authenticated, encrypted in transit and at rest, access-controlled, monitored, and retained according to legal and operational requirements. A degraded dependency should trigger a documented fail-open or fail-closed policy appropriate to the transaction type.

3. Combining Rules, Scores and Machine Learning

3.1 Rules

Rules encode explicit knowledge and are useful for regulatory restrictions, known compromised indicators, impossible travel, sanctions-related conditions, velocity limits, and emergency controls. They are transparent and fast but can become brittle, contradictory, or easy for criminals to probe.

A rule should have an owner, purpose, scope, effective date, test evidence, expiry or review date, and performance metrics. Rules should not be added merely because an individual case appears suspicious; analysts should test whether the pattern generalises.

3.2 Risk scores

A risk score ranks events by estimated concern. Scores may be statistical, expert-derived, or model-based. If a score is intended to represent probability, calibration is essential. A model that ranks cases accurately but systematically overstates probabilities is useful for prioritisation but unsafe for direct probability-based decisions.

For a binary event, a standard logistic model may be written as:

Here, y = 1 denotes fraud, x_i are features, β_i are estimated coefficients, and p is the estimated probability. The model assumes that the log-odds are a linear function of the predictors; this assumption may be inadequate where interactions and nonlinear effects are important.

3.3 Machine learning

Supervised learning uses labelled historical outcomes. Labels may include confirmed fraud, customer-confirmed legitimate activity, chargebacks, reimbursement decisions, or investigator findings. Labels are often delayed, incomplete, and affected by selection bias because only some transactions are investigated.

Unsupervised and semi-supervised methods identify unusual behaviour without requiring complete fraud labels. They can detect new attack patterns, but unusual does not necessarily mean fraudulent. Human review and contextual controls remain necessary.

Useful model families include gradient-boosted trees, regularised regression, neural networks, sequence models, graph methods, and anomaly-detection techniques. Model choice should reflect latency, interpretability, data quality, drift, explainability, and resilience requirements rather than novelty.

3.4 Decision orchestration

The decision engine should not simply add every signal together. A policy may include precedence rules, confidence requirements, customer segment constraints, transaction limits, and intervention availability. For example, a confirmed compromised device may require a decline even if a transaction model assigns moderate risk, while a moderate score may trigger authentication only when a reliable challenge method exists.

A practical layered policy is:

4. Threshold Optimisation

A threshold converts a score into an action. Choosing it requires more than maximising accuracy, because fraud is usually rare and the costs of errors are asymmetric.

Let C_FP be the cost of challenging or declining a legitimate event, C_FN the cost of allowing a fraudulent event, p the estimated probability of fraud, and C_CH the cost of an intervention. If the choice is simply “allow” versus “intervene,” intervention is economically preferable when:

Equivalently, when the costs are constant and the estimate is calibrated, intervene when:

The formula assumes mutually exclusive outcomes, calibrated probabilities, constant costs, and no capacity constraint. Real banks must also include recovery, reimbursement, regulatory, customer-lifetime, and operational costs. Authentication may have a different fraud-reduction effectiveness from outright decline, so each action should have its own expected-cost analysis.

Worked example

Suppose a transaction has an estimated fraud probability of 2%. Allowing fraud costs £800. A step-up challenge costs £2 in operational and customer-friction terms when successful or unsuccessful, and a legitimate customer challenged incurs an additional estimated £3 relationship cost. Assume the challenge eliminates 75% of expected fraud loss.

Expected cost of allowing is:

0.02 × £800 = £16.

Expected residual fraud cost after challenge is 0.02 × £800 × (1 − 0.75) = £4. The challenge cost for a legitimate event is approximately 0.98 × (£2 + £3) = £4.90, giving total challenge cost of £8.90. Under these assumptions, challenging is preferable to allowing (£8.90 versus £16). The calculation is illustrative: the bank should estimate actual authentication success, abandonment, reimbursement, and customer-impact costs.

Capacity and precision

If investigators can review only a fixed number of alerts, the threshold must reflect queue capacity. Precision is:

Recall is:

TP, FP, FN denote true positives, false positives, and false negatives. Precision answers “what proportion of alerts are genuinely concerning?” Recall answers “what proportion of relevant events were detected?” Neither metric alone captures financial severity, customer harm, latency, or investigator workload.

Banks should also monitor prevented loss, loss per thousand transactions, challenge rate, abandonment rate, alert ageing, investigator productivity, and outcome stability across customer groups and channels. Thresholds should be tested using time-based out-of-sample data and stress scenarios, not only random train-test splits.

5. Step-Up Authentication as a Decision Control

Step-up authentication adds evidence when risk is uncertain. Methods include push approval, one-time passwords, cryptographic device binding, biometrics, callback verification, and confirmation through a trusted channel. Stronger methods generally reduce attack risk but can impose greater friction and may be vulnerable to social engineering or SIM compromise.

The decision should consider authentication assurance, transaction value, beneficiary novelty, device integrity, recent account changes, and signs of coercion. A customer who successfully authenticates may still be a victim of an authorised push-payment scam; authentication proves control of a factor, not necessarily informed intent.

Controls should include:

• clear transaction details in the challenge;
• resistance to number matching and push-fatigue attacks;
• limits on repeated attempts;
• independent-channel confirmation for high-risk activity;
• safe recovery when the customer cannot authenticate;
• logging of challenge type, delivery, response, and timing.

6. Alert and Case Management

An alert is a detection output; a case is an organised investigative record. Treating every alert as a case creates unnecessary workload. Triage should deduplicate related alerts, group events by customer or attack campaign, assign severity, and suppress known benign patterns under controlled conditions.

A case record should normally contain:

• unique case identifier and linked alert identifiers;
• event timeline with time zones and source systems;
• customer, account, device, beneficiary, and channel context;
• detection signals and model or rule versions;
• actions taken and authorisations;
• evidence references and integrity metadata;
• investigator notes and hypotheses;
• customer contact and outcome;
• escalation history;
• closure reason, loss amount, recovery, and lessons learned.

Evidence should be attributable, time-stamped, access-controlled, and protected against unauthorised alteration. Hashes can support integrity verification, but a hash alone does not establish that the underlying record was accurate when created. Investigators should preserve original records and document transformations.

Investigation workflow

A disciplined workflow generally proceeds as follows:

1. Intake and prioritisation: validate the alert, calculate severity, and identify immediate containment needs.
2. Enrichment: retrieve relevant transactions, authentication events, device information, communications, and related cases.
3. Hypothesis formation: distinguish account takeover, payment-authorised fraud, mule activity, insider misuse, malware, or benign activity.
4. Containment: apply holds, limit channels, reset credentials, freeze beneficiaries, or contact the customer according to policy.
5. Corroboration: seek independent evidence rather than relying on a single model score.
6. Decision and escalation: close, monitor, reimburse, report, or refer to specialist teams.
7. Recovery and communication: pursue recalls or recovery and communicate accurately without revealing exploitable detection logic.
8. Closure and feedback: record the final label, loss, root cause, and improvements to controls.

Service-level objectives should distinguish critical cases from routine cases. A critical account takeover alert may require immediate containment, while a low-value anomaly can enter a prioritised queue.

7. Illustrative Case: Northbridge Bank

This is a fictional illustrative case.

Background

Northbridge Bank observed increasing instant-payment fraud. Attackers were taking over mobile accounts after persuading customers to install remote-support software. The existing system used a static rule that challenged transfers above £5,000, but many losses were below that amount.

Problem

The rule produced few false positives but missed coordinated low-value transfers. A new machine-learning model improved recall in testing, yet the initial production threshold generated too many alerts for the investigations team.

Analysis

The bank examined 90 days of time-ordered data and found that high-risk combinations included a new device, recent password reset, new beneficiary, remote-access indicators, and an unusual transfer sequence. It also found that a successful one-time password did not reliably indicate legitimate intent because customers were being coached by fraudsters.

Approach

Northbridge introduced a layered policy:

• confirmed remote-access indicators plus a new beneficiary caused a temporary hold;
• medium model risk triggered an in-app warning displaying the beneficiary and amount, followed by a cooling-off period for selected customers;
• high risk or repeated failed challenges generated an immediate case;
• low-risk events remained subject to passive monitoring;
• analysts received grouped cases rather than separate alerts for each transfer.

The bank calibrated the model on a later validation period, monitored precision by channel and customer segment, and created a fallback ruleset for model-service outages. Investigators recorded whether the customer had been coached, whether the device was compromised, and whether recovery was possible.

Outcome

The redesigned process reduced avoidable alerts while identifying coordinated attack sequences earlier. Customer complaints initially increased because of cooling-off periods, so the bank improved explanations and provided a safe expedited-review route. The case demonstrated that authentication, model output, customer communication, and investigation must be designed together.

Learning points

1. A single amount threshold is a weak substitute for behavioural context.
2. Authentication success is not proof that a payment is safe.
3. Alert grouping can improve investigative capacity without reducing detection coverage.
4. Customer outcomes must be included in threshold evaluation.
5. Feedback labels require quality controls because premature closure can train future models incorrectly.

8. Governance, Ethics and Regulation

Real-time fraud systems affect access to money and may cause serious hardship. Governance should therefore cover fairness, explainability, privacy, security, accountability, and contestability.

Important controls include model inventory, documented purpose, data lineage, validation independent of the development team, approval authorities, change control, drift monitoring, performance thresholds, and retirement criteria. High-impact decisions should have human review or an effective appeal route where feasible.

Data minimisation is essential. A bank should use information relevant and proportionate to the fraud objective, restrict access, define retention periods, and assess whether external data introduce discrimination or unlawful profiling. Proxy variables may reproduce protected characteristics even when those characteristics are excluded explicitly.

Customer explanations should be meaningful but should not disclose precise rules that enable evasion. Communications should distinguish suspected fraud from confirmed fraud, avoid blaming victims, and explain available review or recovery routes.

Operational resilience requires tested continuity plans, rate limits, dependency monitoring, secure fallback modes, and post-incident review. A system that blocks every transaction during a model outage may create unacceptable customer harm; a system that allows everything may create unacceptable loss. The appropriate contingency depends on product, risk, legal duties, and service criticality.

9. Contemporary Developments and Limitations

Graph analytics increasingly represent relationships among accounts, devices, beneficiaries, merchants, IP addresses, and identities. Graph signals can reveal mule networks and coordinated attacks that transaction-level models miss. However, shared households, corporate networks, and legitimate intermediaries can create misleading connections.

Sequence models and streaming feature stores support behavioural analysis over time. Generative AI can assist investigators with summarisation and search, but it should not silently determine high-impact outcomes. Generated summaries require source links, human verification, access controls, and safeguards against prompt injection and sensitive-data leakage.

Adversarial adaptation remains a fundamental limitation. Criminals test thresholds, distribute activity across accounts, poison feedback, and exploit recovery processes. Models therefore require drift detection, red-team testing, champion-challenger evaluation, and controlled experimentation.

No detection system eliminates fraud. Its purpose is to reduce expected harm while preserving legitimate access, producing defensible decisions, and learning from outcomes.

Best-Practice Design Principles

• Design for decisions and customer outcomes, not model accuracy alone.
• Separate detection, policy, intervention, and investigation responsibilities.
• Use time-correct data and prevent leakage in development.
• Combine transparent rules with calibrated, monitored models.
• Give each action its own cost, effectiveness, and customer-impact assumptions.
• Optimise thresholds within investigator and authentication capacity.
• Preserve complete, attributable, tamper-evident evidence.
• Group related alerts and prioritise by expected harm and urgency.
• Monitor performance across time, channel, product, and relevant customer groups.
• Test failure modes, outages, adversarial behaviour, and recovery processes.
• Provide proportionate human review, appeal, and customer assistance.
• Feed confirmed outcomes back through controlled data-quality and model-governance processes.

Chapter Summary

Real-time fraud control is an integrated decision capability. It collects events and context, applies rules and analytical models, selects proportionate interventions, and manages resulting alerts through investigation and closure. Rules provide speed and transparency; machine learning identifies complex patterns; risk scores support prioritisation; and step-up authentication can resolve uncertainty, although authentication does not prove that a customer acted freely or safely.

Thresholds should be selected using expected loss, false-positive cost, intervention effectiveness, customer impact, and operational capacity. Precision and recall are useful but incomplete measures. Effective case management requires triage, enrichment, containment, evidence preservation, escalation, customer communication, recovery, and feedback. Governance must address model risk, privacy, fairness, explainability, resilience, and accountability. The strongest systems are layered, measurable, adaptable, and designed around both fraud prevention and legitimate customer access.

Key Terms

Alert: A signal indicating that an event may require attention.

Case: A structured investigative record containing alerts, evidence, actions, and outcomes.

Calibration: Agreement between predicted probabilities and observed event frequencies.

Concept drift: Change in the relationship between inputs and outcomes over time.

Decision orchestration: The policy process that combines signals and selects an action.

False positive: A legitimate event incorrectly treated as suspicious.

Feature leakage: Use of information unavailable at decision time during model development.

Graph analytics: Analysis of relationships among entities and events.

Idempotency: Property ensuring repeated processing does not create duplicate effects.

Intervention: An action such as authentication, hold, decline, or review.

Model drift: Deterioration or change in model behaviour caused by changing data or environments.

Precision: The proportion of flagged events that are genuinely relevant.

Recall: The proportion of relevant events that are detected.

Risk score: A numerical indication of estimated concern or probability.

Rule: An explicit logical condition that triggers a control or response.

Step-up authentication: Additional identity or transaction verification applied to a risky event.

Target leakage: Another term for using future or outcome-derived information improperly in training.

Threshold: A boundary used to map a score or condition to an action.

Velocity feature: A measure of event frequency or value over a defined time window.

Review Questions

Short Answer Questions

1. Why should real-time fraud systems be evaluated as decision systems rather than classifiers?
2. Distinguish an alert from a case.
3. What is the purpose of step-up authentication?
4. Define precision and recall.
5. Why must event time and ingestion time be recorded separately?

Long Answer Questions

1. Explain the main layers of a real-time fraud-monitoring architecture and their interactions.
2. Compare deterministic rules, risk scores, supervised machine learning, and anomaly detection.
3. Discuss the assumptions and limitations of expected-cost threshold optimisation.
4. Describe a complete alert-to-case investigation workflow.
5. Evaluate the governance and ethical risks of automated fraud decisioning.

Analytical / Application Questions

1. A bank has high fraud recall but investigators can review only half the generated alerts. Propose a threshold and triage strategy, including the metrics you would monitor.
2. Design a layered decision policy for a payment involving a new device, a new beneficiary, unusual location, and successful push authentication. Explain why authentication should not automatically result in approval.
3. A model's precision falls sharply after a new payment product is launched. Diagnose possible causes and propose validation, containment, and model-governance actions.

Multiple Choice Questions with Answers

Question 1

Which component combines rules, model outputs, customer context, and available interventions to select an outcome?

A. Event transport layer

B. Decision orchestration layer

C. Data-retention schedule

D. Cryptographic hash

Correct Answer: B. Decision orchestration layer

Question 2

What is the principal danger of using information generated after a transaction decision in model training?

A. Higher network latency

B. Target leakage

C. Lower encryption strength

D. Duplicate authentication

Correct Answer: B. Target leakage

Question 3

A model produces 80 true-positive alerts and 20 false-positive alerts. What is its precision?

A. 20%

B. fifty percent

C. 80%

D. 100%

Correct Answer: C. 80%

Question 4

Which statement best describes successful authentication in an authorised push-payment scam?

A. It proves the payment is legitimate

B. It proves the customer understood the fraud risk

C. It proves control of an authentication factor but not necessarily informed intent

D. It eliminates the need for transaction monitoring

Correct Answer: C. It proves control of an authentication factor but not necessarily informed intent

Question 5

Which measure answers the question, “What proportion of relevant events were detected?”

A. Precision

B. Recall

C. Latency

D. Specificity of a rule owner

Correct Answer: B. Recall

Question 6

Why is alert grouping useful in case management?

A. It removes the need to preserve evidence

B. It ensures every alert is automatically closed

C. It links related events and can reduce duplicated investigative work

D. It prevents all false negatives

Correct Answer: C. It links related events and can reduce duplicated investigative work

Question 7

In the illustrative threshold example, allowing a transaction with a 2% fraud probability and an £800 fraud cost produces an expected fraud cost of:

A. £0.16

B. £2

C. £16

D. £800

Correct Answer: C. £16

Question 8

Which practice best supports evidence integrity?

A. Allowing investigators to overwrite original records

B. Preserving original records with attributable timestamps and controlled access

C. Deleting unsuccessful authentication logs immediately

D. Relying only on an undocumented analyst memory

Correct Answer: B. Preserving original records with attributable timestamps and controlled access

Question 9

Which is a limitation of anomaly detection?

A. It can identify unusual behaviour that is not actually fraudulent

B. It always requires confirmed fraud labels

C. It cannot operate on streaming data

D. It guarantees calibrated probabilities

Correct Answer: A. It can identify unusual behaviour that is not actually fraudulent

Question 10

What should a bank do when a model-service outage occurs?

A. Permit all high-value transactions without monitoring

B. Use a documented contingency policy appropriate to the transaction risk

C. Delete all pending cases

D. Change thresholds informally during the outage

Correct Answer: B. Use a documented contingency policy appropriate to the transaction risk