Real-Time Fraud Investigation Agents: Fast Evidence, Bounded Action and Human Authority

Real time contains more than one clock

“Real-time fraud agent” sounds like one component watching a payment and deciding whether it should proceed. That design confuses three systems with different clocks and authority. Payment authorisation runs inside a channel or scheme deadline. Customer intervention may have seconds or minutes. Investigation, error resolution, recovery and regulatory reporting operate on case timelines. A system that treats them as one conversation will either miss the payment deadline or give a probabilistic agent more authority than its evidence can support.

A safer architecture has three lanes. The transaction lane uses approved rules and conventional fraud models to produce a bounded decision under a deterministic policy. The intervention lane uses a generative agent to assemble current evidence and recommend a permitted response. The case lane gives authorised people the evidence needed for investigation, customer remediation, account action and any separate suspicious-activity process.

The agent shortens the path from signal to evidence. It does not become the payment policy, the dispute investigator or the legal decision maker.

This distinction matters because payment fraud keeps changing. The EBA and ECB's 2025 joint payment-fraud report says strong customer authentication remains effective against the fraud types it was designed to mitigate while manipulation of payers is rising. The FATF paper on cyber-enabled fraud, published in February 2026, also describes a dynamic cross-border threat. Neither source says a language model should authorise payments.

The composite: a payment the customer intends but does not understand

Maya is a fictional retail customer. She receives a call from someone claiming to represent a trusted service provider. The caller persuades her to add a new beneficiary and send a payment to secure an account. Maya signs in from her usual phone and completes the bank's normal authentication. There is no stolen credential in the scenario. The manipulation sits outside the login event.

The transaction engine sees a valid session, a new payee, an unusual payment purpose and a beneficiary that has recently appeared in another confirmed fraud investigation. A conventional model produces a risk score. A deterministic policy evaluates that score with product, channel, customer and scheme rules. Depending on locally approved controls, it might allow, step up, hold, decline or route the payment for intervention. The exact action is not universal and is deliberately not assigned a threshold here.

The investigation agent receives an event only if policy permits. It retrieves a small, authorised evidence set: payee age, device continuity, recent contact history, customer transaction pattern, beneficiary intelligence and the reason each detection component fired. It does not search the customer's unrelated private data. It does not decide that Maya is lying or negligent. It does not directly release or reject the payment.

Design the three lanes before choosing a model

The transaction lane has the strongest latency constraint and the smallest tolerance for variable behaviour. Its inputs should be versioned features with known freshness. Its outputs should be typed actions. Its fallback should be defined. A generative model should not improvise a payment API call after reading free text.

The intervention lane can add context unavailable to one transaction score. It can assemble recent customer contacts, explain which observable facts are unusual, prepare a targeted question and select an approved intervention template. Its deadline depends on the channel. If the channel window closes, the policy service chooses the fallback; the agent does not keep the payment in an indeterminate state.

The case lane begins when facts require investigation or the payment has already completed. It can run longer because the objective changes from authorisation to evidence, recovery, error resolution and customer treatment. The record must preserve what was known at payment time separately from facts learned later.

Latency is part of the control contract. Each tool call needs a deadline and defined error state. “No result” must distinguish no evidence, source timeout, permission denial and malformed query. Treating all four as a benign absence can turn a service outage into an approval bias.

Build the payment path as a deadline-aware state machine

Real-time architecture begins with an explicit payment state model. “Pending” is not enough. A payment can be received, validated, scored, awaiting a scheme-timed action, held under a permitted intervention, authorised, sent, accepted by the receiving system, rejected, expired, cancelled, returned or under recovery. The valid states and deadlines depend on the payment rail and product. They belong in deterministic services, not in an agent's conversational memory.

Each state transition has a command, authority, precondition and receipt. The fraud system can request an approved action; the payment service validates whether that action is still legal and possible at the current state. If the agent proposes a hold after the payment has become irrevocable, the command is rejected and the case lane receives the settled event. The system does not display a fictional “hold” because that was the intent.

The transaction contract should carry several deadlines: channel response, fraud-feature budget, policy decision, intervention expiry and rail execution. These are not one timeout divided among services informally. Each component has a budget and an error code. The policy defines what happens when a non-critical enrichment misses its budget and when a critical control is unavailable.

An instant-payment rail makes this discipline visible. Regulation (EU) 2024/886 defines, for its scope, execution requirements for euro instant credit transfers and a verification-of-payee service before authorisation, with phased compliance dates. It is a jurisdiction-specific legal source, not a global ten-second design rule. It does show why payee verification, fraud intervention and settlement deadlines must be represented as explicit services rather than an open-ended agent dialogue.

Event delivery is at-least-once in many distributed systems. Commands that can affect money need idempotency keys. Retrying an authorisation, reversal or recovery message must return the original receipt or a safely reconciled state, not perform the effect twice. A network timeout creates “outcome unknown” until reconciliation; it does not justify blind retry.

Concurrency is another control. The customer can cancel while an intervention specialist releases. A beneficiary update can arrive while the policy decision is being taken. Optimistic version checks or equivalent transactional controls ensure that only a command based on the current payment version succeeds. The losing action receives the new state and follows its defined route.

The agent operates on a case snapshot with an expiry. It can draft a recommendation while the payment is in intervention, but the downstream service revalidates state, token and policy. Its output never locks the ledger. If the agent is slow, the deterministic fallback fires. The case can preserve the late recommendation for diagnosis without treating it as an executed action.

The state machine also protects customer communication. A message saying “your payment has been stopped” can be sent only after the payment service returns that state. Before that, the channel can say the payment is being checked, if approved wording permits. Recovery messages distinguish a request sent from funds returned. This prevents generated language from outrunning operational truth.

Money moves through authoritative states, not prose. The agent can explain, retrieve and recommend around those states. Only the payment service establishes which effect actually occurred.

Engineer the feature and event plane for point-in-time truth

Fraud controls combine streaming and historical data: the current payment, session behaviour, device state, account history, beneficiary history, customer contacts and network intelligence. A feature is safe to use only if its definition, value time, knowledge time and availability are known. An impressive score built from a stale or hindsight-filled feature is not a real-time control.

The online feature service should return values with event-time cut-offs and freshness metadata. Offline training must use the same definitions or a tested equivalent. “New beneficiary” needs a precise window, customer-account relationship and treatment of deleted then re-added payees. “Usual device” needs identity, continuity and reset rules. “Unusual amount” needs the population and currency treatment against which it is unusual.

Each feature response distinguishes a valid value, a valid absence, stale data, source timeout, permission denial and computation error. A model trained with a missing-value code can use it only if production preserves the same meaning. Converting every failure to zero can make an intelligence outage look like a safe beneficiary.

Late and out-of-order events require watermarks or equivalent policy. A device event received after the decision belongs to later investigation unless the feature service can prove it was available earlier. Backfills can improve historical analysis but should not rewrite the original decision manifest. Point-in-time joins are mandatory for evaluation.

The detector manifest includes feature definitions, feature values, freshness, rule versions, model version, score calibration segment and policy version. It need not store unrestricted raw device telemetry beside the case. Stable references and the decision-relevant values can support replay under retention and privacy policy.

Feature quality monitoring should operate before confirmed-fraud labels arrive. Watch null and stale rates, cardinality, value distributions, source latency, join coverage and population counts. A dramatic fall in “new payee” may reflect a mapping defect rather than safer behaviour. Compare online and offline feature values on sampled events to detect skew.

Privacy follows purpose. A fraud feature store should not become a general behavioural dossier. Device, location and contact data are retrieved and retained only as permitted for the control. The agent receives a decision-relevant abstraction or case-scoped evidence, not the whole event stream. Sensitive raw data remains in its governed product with role-based access.

Training examples require a decision-time cut. If a complaint received two days later is joined into the input row at payment time, the model learns from the future. If a beneficiary was placed on a confirmed-risk list after the payment, the historical row must show what the list contained then. The difference between final case truth and live feature truth remains explicit throughout the pipeline.

Point-in-time correctness is more fundamental than model sophistication. A simpler model on faithful features can be evaluated and governed. A frontier model trained on leaked future evidence cannot be trusted at the moment of payment.

Convert scores into actions through explicit policy

A fraud score ranks or estimates under the model's definition. It does not decide the customer action. The same score can have different meanings across products, time, customer cohorts and model versions. Even a well-calibrated probability does not encode rail reversibility, transaction consequence, specialist capacity, customer vulnerability, legal requirements or the cost of a false decline. Those factors belong in policy.

The policy service receives typed signals: model scores with calibration segment, deterministic rule results, feature-health status, payment state, product and channel, amount or exposure, available intervention routes and current operating capacity. It returns one enumerated action with reason codes and expiry. A language model does not interpolate among scores in prose.

Calibration must match the live population and outcome definition. If a score of 0.20 is described as twenty per cent fraud risk, test whether comparable payments mature near that rate over a stated window. Where labels are incomplete, say the score is a ranking or proxy rather than a probability. Calibration can drift when fraudsters adapt, customer behaviour changes or detection affects which outcomes are observed.

Threshold analysis should show an operating frontier rather than one “best” cut-off. For each candidate policy, estimate detected exposure, fraudulent and legitimate interventions, declines, specialist load, expiry, customer abandonment and uncertainty. Use time-split, decision-time data. Then shadow or limited release measures real behaviour, because customers and investigators respond to interventions in ways offline replay cannot capture.

Costs are asymmetric and contextual. A missed scam can create severe financial and personal harm. A false decline can prevent an urgent legitimate payment and reduce trust. A step-up can be relatively low-friction for some customers and inaccessible for others. Senior control and customer owners approve the trade-off within applicable duties. A data-science metric does not decide risk appetite.

Hard rules remain explicit. Sanctions, entitlement, account status or scheme constraints may require an action independently of a fraud score. Their outcomes should not be presented as model decisions. Conversely, a high fraud score does not override a legal or technical inability to hold funds. The case should show which control was decisive.

Capacity-aware policy must not make protection arbitrary. If specialists are unavailable, the service follows a preapproved degraded mode by product and consequence. It may narrow which payments enter a time-bounded intervention, use a safe alternative control or invoke extra manual coverage. It does not quietly raise thresholds until the queue disappears. Changes are logged and reviewed as policy releases.

Overrides have typed reasons and time limits. A control owner might impose a temporary rule during an active fraud campaign. An authorised specialist may use new customer evidence to select a permitted action. Every override records actor, evidence, scope, start, expiry and downstream effect. It becomes evaluation evidence, not an unreviewed training label.

Policy simulation should include source and component failure. Ask what action occurs if beneficiary intelligence times out, the device service is stale, the model endpoint fails, a new-payee flag is unavailable or specialist capacity is zero. A policy that behaves sensibly only when every enrichment succeeds is not production policy.

Monitor action distributions alongside scores. A stable score distribution with a sudden increase in declines may reflect a policy change. A stable action distribution with rising loss may reflect calibration drift. A fall in interventions can reflect source outage. Versioned joint monitoring is needed to attribute consequence.

The model estimates; policy commits. Keeping the translation explicit lets the institution recalibrate a detector, change a customer intervention or respond to capacity without giving one component silent control over money.

Route by fraud mechanism, not one universal risk story

Account takeover, authorised push-payment manipulation, card-not-present fraud, first-party misuse, mule activity and payment error can share surface signals while requiring different questions and actions. A usual device weakens one account-takeover hypothesis but may strengthen the inference that the genuine customer is being manipulated. A payee-name mismatch can indicate error, fraud or a legitimate trading name. The architecture should retain typology as a tested hypothesis, not make one “fraud probability” explain every intervention.

The routing service can maintain several hypothesis scores or rule states, but the customer journey should not expose a technical typology label as an accusation. It selects an approved intervention intent. A scenario question set can seek the discriminating fact without telling the customer which feature fired or suggesting the answer.

Typologies evolve, so routing needs an “other or unresolved” state. Forcing every new pattern into the closest known category can create misleading scripts and training labels. Investigators can assign or revise a mechanism later with evidence. Those changes inform research but do not retroactively alter what the payment-time system knew.

Mechanism-specific evaluation matters. Overall recall can rise because the model improves on abundant card fraud while APP-scam detection worsens. False declines can cluster in urgent legitimate transfers. Device continuity can behave differently after operating-system changes. Report calibration, intervention, customer burden and outcome by mechanism and relevant product cohort.

The EBA-ECB report cited at the outset is useful precisely because it separates mechanisms: strong customer authentication can remain effective for attacks it targets while fraudsters shift toward manipulating payers. The architectural lesson is not that authentication failed. It is that controls need distinct hypotheses, evidence and intervention rather than treating one defensive layer as a universal proof of safety.

A typology is a way to choose the next evidence and control, not a verdict about the customer. Keeping it provisional supports better interventions and cleaner learning data.

Treat beneficiary intelligence as a sourced, perishable claim

Beneficiary intelligence can be powerful because multiple institutions, schemes or internal cases may observe risk around the receiving account before one customer sends money. It is also easy to overstate. A score may be based on unconfirmed reports, stale activity, an incorrectly resolved entity or signals the sending institution is not permitted to inspect.

The intelligence product should return a typed result: beneficiary identifier and resolution method; signal type; source class; observation and expiry time; confirmation state; permitted purpose; model or rule version; and an explanation suitable for the receiving role. It should never return only “high risk.” A case investigator may receive richer evidence than a payment-time policy, but both need provenance.

Identity resolution must account for account recycling, portfolio migrations, virtual identifiers and joint or platform accounts. A historical confirmed case associated with an account number may not describe the current holder. The intelligence service needs effective dates and provider context. Where the receiving identity is unresolved, the signal is weaker and the system must say so.

Network expansion has a purpose and hop limit. Direct flows to a confirmed fraudulent account can be relevant. Sharing an IP address with thousands of users or a corporate-service address may not be. The graph should type each edge and expose its base rate. The agent cannot turn a visually dense network into a criminal allegation.

Feedback needs distinct states: customer report, internal investigator assessment, receiving-bank response, confirmed fraud under an approved standard, recovery, law-enforcement information and later correction. Each has different reliability and sharing permission. Pooling them into one positive label can create feedback loops in which model alerts generate reports and those reports then validate the model.

Challenges and corrections must propagate. If an account was wrongly linked, lineage identifies payments and cases that used the signal. The institution decides whether to reassess interventions, correct a customer record or adjust training data. Expiry prevents an old event from remaining a permanent adverse mark without review.

Cross-institution data sharing requires its own legal, contractual, security and quality arrangements. This article does not assume that every desirable signal can be shared. The architecture works with a minimal policy-approved abstraction at payment time and a more restricted route for underlying facts where permitted. “The network knows” is never an access justification.

Beneficiary intelligence should increase the precision of a question, not eliminate the need to ask it. Its value comes from earlier, sourced warning; its danger comes from turning an opaque ecosystem score into irreversible treatment.

Put a policy token between reasoning and effect

The intervention agent should never hold a standing credential that can alter payments. When the transaction policy opens an intervention, it issues a short-lived capability token containing the case, allowed tools, maximum action class, expiry and policy version. The agent can use it to retrieve the permitted evidence and propose one of the allowed actions. The downstream service validates the token and the authorised actor before any effect.

This pattern keeps identity and authority separate. The customer authenticated the payment request. The fraud service identified risk. The agent assembled evidence. A human or deterministic policy authorised the next state. The ledger executed it. One service account should not impersonate all five roles.

Build the evidence packet around decision time

A fraud investigation is vulnerable to hindsight. After a scam is confirmed, a new beneficiary looks obviously dangerous. At authorisation time, the institution may have had only a weak network link, a usual device and no prior complaint. The packet should freeze the features, source versions and policy available at the decision point. Later evidence belongs in a separate layer.

The packet needs event time and knowledge time. Event time says when the payee was added or transaction requested. Knowledge time says when the institution received a beneficiary warning or customer contact. This prevents an evaluator from crediting the system for information it learned after the action.

Every model or rule contribution should be named. “High risk” is not sufficient. The record should show which version produced the score, which input features were available, whether any source timed out, and how the deterministic policy converted those signals into an action. The agent's summary then cites those exposed events.

Decision-time truth and final case truth are different datasets. Training and evaluation must preserve that difference. Otherwise the next model is trained on labels containing information that no live system could have known.

Customer intervention should seek signal without assigning blame

An APP scam case is difficult because the customer may have authenticated and intended the payment while being deceived about its purpose or recipient. Asking “Did you make this payment?” may produce a truthful yes and no useful signal. The intervention should test the scenario: how was the beneficiary introduced, is anyone directing the customer, is the payment described as a safe-account transfer, is remote-access software involved, and can the customer independently verify the recipient?

Those questions need legal, conduct and vulnerability review. A frightened customer may follow a fraudster's instruction to conceal the call. A rigid script can sound accusatory or disclose exactly which control fired. The agent may select an approved question set from the observed typology, but a channel owner controls the final language and any required human transfer.

Voice adds identity and coercion risks. A generative voice system should not claim certainty from emotion or accent. If the agent detects inconsistency, it can route to a trained person. It should preserve the customer's words as statements, not rewrite them as admissions.

The institution also needs a route for accessibility and vulnerability. A silent app challenge may not work for every customer. A phone callback may itself be unsafe if the fraudster controls the call. Alternative channels and trusted-contact processes must be established outside the model. A fraud control that customers cannot safely complete is not a successful control.

Use a reversible action ladder where the rail allows it

Fraud action is often described as allow or decline. In practice, institutions may have a ladder of interventions: passive warning, payee verification, additional contextual questions, strong re-authentication, trusted-channel callback, transaction limit, time-bounded hold, specialist review, decline and post-event recovery. Which rungs exist depends on product, rail, law, scheme and operating capacity. The policy service must know those constraints.

Reversibility is valuable because payment-time evidence is uncertain. An approved, short hold may create time to contact the customer with less harm than a final decline, where the rail and legal framework permit it. A warning may resolve a payee-name error without specialist intervention. Conversely, a weak warning can be ignored under coercion, and delay may be impossible for an instant payment. The ladder is not automatically conservative; each rung has customer and fraud costs.

The action policy should consider consequence, evidence strength, rail state, customer context, availability and known intervention effectiveness. It should not optimise only prevented loss. A false decline on rent, medical care or business payroll can be severe. An intervention that discloses control logic can help fraudsters adapt. A callback that is safe for one scam can keep another customer on a compromised channel.

For every rung, define entry criteria, maximum duration, authorised role, customer message, fallback, evidence retained and appeal or recovery path. The agent can recommend a rung within its capability token. It cannot create a novel “temporary freeze” or extend a hold beyond policy by continuing to ask questions.

Step-up authentication and scam intervention solve different questions. Re-authentication can establish control of a credential or device. It does not establish that the customer understands the recipient or purpose. The workflow should not treat successful authentication as the end of an APP-scam intervention. It also should not ask repeated authentication questions when the actual uncertainty is social manipulation.

Payee verification has a defined role. The EU regulation cited earlier and the United Kingdom's confirmation-of-payee arrangements illustrate specific implementations, but a name match does not make a beneficiary safe. A fraudster can provide the accurate name of an account they control. A mismatch is evidence to explain, not automatic proof of fraud. The customer-facing wording should distinguish no match, close match, unavailable and verified match precisely.

The policy must also handle customer insistence. Depending on the applicable framework and product, a customer may be able to proceed after a warning, or the institution may have grounds for another action. The decision cannot be inferred from frustration in a conversation. The channel collects the required acknowledgement and routes the case to the authorised rule or person.

Measure each rung separately: fraud prevented, legitimate payments delayed or declined, abandonment, specialist handling, customer comprehension, complaints and later outcomes. A high warning-completion rate is not success if customers click through without understanding. Controlled usability tests and post-event sampling can assess comprehension without coaching the live answer.

The purpose of an action ladder is to buy the right evidence at the lowest justified customer cost. It is not a way to make every uncertain payment endure every available control.

Design for coercion, vulnerability and unequal access

Fraud intervention is a human-safety system. Customers may be frightened, isolated, under time pressure, unfamiliar with digital payments, cognitively impaired, financially distressed, or communicating in a second language. Fraudsters deliberately exploit these conditions. A technically accurate prompt can still cause harm if it assumes calm, private and fully accessible interaction.

The FCA's current page on treating vulnerable consumers fairly and its supporting guidance are official United Kingdom materials for their scope. They do not establish a global fraud script. They reinforce the design need to understand vulnerability, provide appropriate support and test outcomes. Every institution must map comparable duties and processes for its customers and jurisdictions.

The system should separate vulnerability support from a fraud-risk score. A customer can require an accessible channel without being more fraudulent. A vulnerability flag should not automatically increase suspicion or expose sensitive health or personal information to the agent. The channel policy can provide larger text, more time, language support, relay services or a trained specialist using the minimum necessary data.

Coercion changes the reliability of direct questions. A customer may be told to deny a call or describe the transfer as a purchase. The intervention can suggest stepping away from the call, independently contacting the purported organisation and using a verified bank channel, subject to approved wording. It should not challenge the customer aggressively or reveal all reasons the bank is concerned.

Trusted contacts and third-party assistance are legally and operationally sensitive. The agent cannot select a family member from the customer's address book or disclose a payment because that seems helpful. The institution needs an established consent, mandate or safeguarding process. Where emergency escalation exists, it is invoked by authorised people under policy.

Accessibility has failure modes that ordinary fraud tests miss. Timed challenges can disadvantage people using assistive technology. Voice biometrics can perform differently across health conditions and accents. Visual warnings may not reach a customer using a screen reader. A branch visit may be impossible. Test complete journeys with affected customers or qualified representatives, not only whether the interface technically meets a checklist.

Customer statements should be recorded faithfully. The agent can structure them into propositions while preserving the original wording and channel. It should not infer deception from hesitation, spelling, tone or accent. Emotion classification is not a safe basis for a payment decision. If the account differs from objective events, the interface presents the conflict without labelling the customer dishonest.

Staff need room to exercise judgement. A specialist may extend a conversation, switch channel, request a welfare escalation or use a permitted alternative verification route. Those actions have reason codes and review. Productivity targets should not punish appropriate support or reward quick declines.

Outcome analysis should compare relevant groups lawfully and carefully. Are certain customers more likely to abandon interventions, fail time limits, receive declines or complain? Are translation and accessible-channel failures being mislabelled as non-response? The purpose is to correct the service, not infer that a demographic attribute is a fraud signal.

Equal treatment is not an identical script. A governed system provides different safe routes to the same evidence and decision standard while preventing vulnerability data from becoming an adverse shortcut.

Work the maya scenario through the lanes

At payment time, the transaction controls identify a new payee and a payment purpose outside Maya's normal pattern. Device continuity reduces the likelihood of account takeover but does not answer whether she is being manipulated. Beneficiary intelligence returns a recent risk event from an approved network source. The result is current but not independently confirmed.

The policy places the payment into an approved intervention state. It issues a bounded case token. The agent retrieves the feature reasons, recent relevant contact history and beneficiary event. It reports three facts, one inference and two unknowns. The facts are that the payee is new, the device is usual and the beneficiary has a recent network event. The inference is that the pattern is compatible with payer manipulation. The unknowns are how Maya learned of the payee and whether another person is directing the transfer.

The agent selects an approved APP-scam question set and drafts a short explanation. A trained intervention specialist contacts Maya through a verified channel. The specialist records her statements and decides the next permitted action under policy. The transaction service executes that action and returns a receipt. The scenario does not prescribe whether the payment is released or declined; that depends on the verified facts and locally approved process.

If the payment had already settled, the same evidence would open a case rather than retroactively change the authorisation record. The case team could pursue recovery, beneficiary-bank contact, dispute handling and customer remediation through authorised routes. A separate financial-crime process would decide whether the facts require regulatory reporting. The investigation agent could package underlying facts for that referral but could not make the reporting decision.

One evidence packet can support several decisions, but those decisions do not share one authority. Payment action, customer reimbursement, account restriction and suspicious-activity reporting remain separate state machines.

Error resolution and reimbursement are not model labels

Confirmed fraud is not one universal label. A payment can be unauthorised, incorrectly executed, authorised under deception, disputed for another reason or outside a particular consumer-protection rule. Applicable rights differ by instrument and jurisdiction.

For United States consumer electronic fund transfers, the CFPB's current Regulation E error-resolution provision defines covered errors and investigation procedures. The CFPB's Electronic Fund Transfers FAQs add official interpretation and examples. These sources do not govern every payment or country.

In the United Kingdom, the Payment Systems Regulator's consolidated APP scams guidance points readers to the legal instruments that define the reimbursement requirement. The PSR's 2026 reimbursement dashboard is regulator-published outcome evidence, not a model benchmark.

The case agent can assemble transaction, authentication, contact and intervention evidence. An authorised investigator applies the relevant definition and process. The outcome label should record which test was applied, what facts were available and whether the decision later changed. Feeding “reimbursed” directly back as “model was wrong” can be misleading because reimbursement may reflect a legal or policy rule broader than transaction-fraud classification.

Recovery is a separate workflow with a perishable clock

When a payment has completed, the architecture must change mode quickly. Authorisation controls cannot reverse history, and an investigation agent cannot promise recovery. The case service should create a recovery packet containing the payment identifier, beneficiary details, settlement state, customer report time, contact attempts and the evidence needed by the authorised recovery team. It should then call only the routes permitted for that payment type and jurisdiction.

The urgency is real, but “act fast” is not a permission model. The recovery service owns the approved bank-to-bank, network or scheme messages. The agent may populate a typed request from ledger facts. An authorised operator or deterministic rule submits it according to policy. If a beneficiary response arrives, it becomes a new event with provenance; it does not overwrite what the sending institution knew at authorisation.

Customer communication needs bounded claims. The system can confirm that a case has opened and state the next procedural step. It should not guarantee return of funds, accuse the beneficiary or disclose a confidential financial-crime referral. Message templates should vary by case state, legal process and channel while preserving one underlying event record.

Recovery also creates valuable but messy labels. Funds returned does not prove the original payment was fraudulent. No funds returned does not prove it was legitimate. A beneficiary account closure can occur for several reasons. The learning pipeline should preserve the source and meaning of each outcome: customer assertion, investigator finding, scheme response, confirmed fraud, recovery amount, reimbursement decision and law-enforcement information where use is permitted.

Case outcomes are evidence with different strengths, not one binary training label. Before an outcome enters model development, the dataset owner should define its meaning, allowed purpose, observation delay and likely bias. Cases with rapid customer contact may be overrepresented among recoveries. Cases escalated by an existing model may be overrepresented among confirmed fraud. Training blindly on either group can reproduce the old control's selection bias.

Turn recovery into a coordinated, auditable race

Recovery brings several organisations and clocks into one case. The sending institution needs to establish the payment and customer report, identify the receiving route, send the permitted request, monitor acknowledgement, preserve evidence and communicate accurately. The receiving side may need to investigate, restrict funds under its own authority and respond through a scheme or bilateral process. Law-enforcement or financial-crime routes may run separately.

The recovery orchestrator should therefore manage obligations and dependencies, not improvise messages. Its case plan is built from the payment type, settlement state, jurisdiction, scheme, customer report time and authorised findings. Each task has an owner, service level where applicable, request schema and receipt. The agent can populate factual fields from the ledger and explain missing information. It cannot claim the receiving institution has frozen funds until a response establishes that state.

Deadlines are computed by deterministic policy and displayed with their basis. Where a route is best-efforts rather than guaranteed, the system says so. Escalation paths are preapproved. A language model should not search the web for a receiving institution contact and send customer data to it.

Amounts need reconciliation. The original payment, any partial return, fees, currency conversion, temporary credit and final reimbursement are distinct ledger events. The customer case should show them separately. “Recovered” may mean funds returned from the beneficiary route; “reimbursed” may mean the institution credited the customer under a legal or policy process. Mixing them corrupts customer communication and performance measurement.

Recovery interactions generate network intelligence, but the feedback route is governed. A receiving institution's acknowledgement is not automatically a confirmed-fraud label. A returned amount can follow a precautionary request. The dataset records who asserted what and when. Only outcomes meeting the approved label standard enter the relevant model or beneficiary intelligence product.

Fraud and AML referrals remain separate. A recovery case can send factual events to an authorised financial-crime intake under policy. The existence or content of any suspicious-activity report does not flow back into general recovery messaging. Likewise, an AML decision does not authorise customer reimbursement or a ledger reversal.

Operational dashboards should reveal dependency time. Show time to customer report, time to validated recovery request, receiving acknowledgement, first substantive response, funds status, reimbursement decision and closure. One blended case duration hides whether delay sits inside the bank, a scheme, another institution or customer evidence collection.

The manual route must work during an agent outage. Staff can retrieve the ledger event, use approved templates, send through the controlled route and record receipts. The agent is valuable when it reduces retrieval and coordinates tasks; it is not a single point of failure for perishable recovery action.

Speed in recovery comes from pre-authorised routes, accurate identifiers and visible dependencies. Generating text faster is useful only after those foundations exist.

Build a learning system that respects delayed and selected labels

Fraud outcomes arrive at different times and through biased paths. Some customers report immediately; others never report. Some cases receive specialist investigation; low-score payments may receive none. Recovery and reimbursement depend on process and policy. Law-enforcement confirmation is sparse. Treating the eventual case table as an ordinary supervised dataset produces leakage and selection bias.

Create a label ontology before training. It distinguishes reported fraud, investigator-confirmed fraud under a named standard, unauthorised transaction finding, APP-scam finding, operational error, customer withdrawal, unresolved case, recovered amount, reimbursement outcome and external confirmation. Each label has a source, observation date, eligible use, confidence or review status and supersession rule.

The EBA guidelines on fraud reporting under PSD2 are official reporting guidance for their scope. They are not a machine-learning label specification. They illustrate why regulatory reporting categories and timing have defined purposes. A model-development dataset can map from governed outcomes, but it should not assume that one reporting category is universal ground truth for every fraud mechanism.

Delayed labels require fixed evaluation windows and maturity reporting. Results for payments only seven days old cannot be compared directly with results for payments observed for six months. Publish performance by label maturity and mechanism. Use survival or delayed-outcome methods where appropriate, with assumptions stated. Do not fill unresolved cases with “legitimate” simply because no complaint has arrived yet.

Selection bias needs explicit analysis. Investigator-confirmed cases are drawn from the controls that already escalated. Declined transactions may never reveal whether fraud would have occurred. Allowed transactions with no customer report are not all verified legitimate. Random or risk-based review of selected low-score and non-alerted events, where lawful and operationally feasible, can estimate blind spots. External or network outcomes can add evidence if provenance and sharing terms permit.

Feedback loops are especially dangerous in beneficiary intelligence. If a model flags an account, investigators look more closely, reports accumulate and the account receives a stronger model score. The programme should distinguish evidence independent of the model from evidence caused by its own intervention. Confirmations require an approved standard; volume of alerts does not equal validation.

Training data retains the decision-time feature cut separately from labels. The input row shows only what was available before the payment action. Later case events become targets or analysis variables. Dataset manifests record inclusion, exclusion, sampling, feature versions, label maturity, protected attributes where lawfully used for fairness evaluation and known limitations.

Human overrides are not immediate labels. A specialist can be wrong, or can apply customer and policy considerations that differ from fraud classification. Classify the reason and send it to quality assurance. Only reviewed, semantically appropriate outcomes enter training. Free-text notes require privacy and purpose review before any model use.

Compare candidate models on consequence, not one area-under-curve figure. Measure calibrated risk, detection at policy-relevant false-positive levels, loss or exposure, customer interventions, false declines, group effects, latency, feature coverage and stability over time. Policy simulation then estimates actions with uncertainty; shadow and limited release measure actual operational response.

A mature learning loop preserves why a label exists and what the model could know. Without those two facts, continuous learning becomes continuous reinforcement of the old system's blind spots.

Human review must be designed for urgency

A fraud specialist cannot meaningfully review a page of generated prose while a payment state is expiring. The intervention view should begin with the permitted actions and remaining time, then show the few facts that distinguish those actions. The reviewer can expand source records and later evidence, but the first screen should not require hunting for the transaction amount, payee age, device state or reason for intervention.

The system should separate a verified fact, a model signal, an agent inference and a customer statement visually. If a beneficiary score is unverified or unavailable, the interface should say so. If the agent recommends a callback, it should cite the unknown the callback can resolve. A reviewer should not have to infer why a question is being asked.

Override is expected. Reviewers need reason codes that capture policy, new evidence, customer vulnerability, source failure and model error without forcing every decision into “agree” or “disagree.” These reasons support evaluation and operational improvement. They should not automatically become training labels until reviewed.

Staffing and fallback matter too. A system calibrated for weekday specialist coverage may behave differently overnight. The policy should know whether a trained reviewer is available and select only actions valid for that operating state. Human in the loop is a capacity commitment, not a diagram label.

Treat customer communication as a measured control

Warnings and questions change customer behaviour. They can interrupt a scam, create useful evidence, confuse a legitimate payer, reveal controls or push a frightened customer back to the fraudster. Copy quality is therefore part of fraud effectiveness, not a final design review after the model is complete.

Every message should have an approved intent: inform, verify context, recommend a safe independent action, explain a delay or decline, confirm a case state, or request specific evidence. The message service selects only intents permitted for the payment and case state. A generative component may adapt plain language within approved constraints; the channel validates prohibited claims, required text, links and next actions.

The wording should say what the institution knows. “The payee details do not match” differs from “we could not check the payee” and “we are reviewing this payment.” “Funds have been recovered” requires a ledger or receiving response, not an agent recommendation. Avoid accusations, guarantees, legal conclusions and disclosure of confidential referrals.

Questions should discriminate among plausible scenarios. “Did you make this payment?” is weak for an authorised scam. “Did anyone ask you to move money to protect it?” may be more useful for a safe-account story. The question set should not teach a fraudster the full detection logic or imply that one answer will ensure release. It should give the customer a safe route to pause and contact the bank independently.

Sequence matters. A long list of generic warnings can be clicked through. Present the most relevant approved message at the decision point, then a small number of questions. If answers indicate coercion or vulnerability, move to a trained human rather than ask the model to cross-examine the customer. The system records the actual displayed message, response and timing.

Evaluation needs comprehension, not only click rate. In controlled research, ask representative participants what the warning means, what they believe will happen, whether they recognise the scam scenario and what action they would take. Include accessibility, language and high-stress conditions. A message that reduces completion because it successfully stops risky payments differs from one that causes general confusion.

Live testing must protect customers. Shadow mode can generate messages without displaying them. Limited release uses approved variants and predeclared harm limits. Randomisation, where lawful and ethically approved, should not withhold a control believed necessary for high-consequence cases. Complaints, abandonment, repeat attempts, specialist transfers, fraud outcome and legitimate-payment completion all matter.

Generated variations require versioning. Store the template, model, constraints and final text. If a later review finds a misleading phrase, lineage identifies the customers and decisions exposed. The channel can disable generation and fall back to fixed text immediately. Copy changes with material behavioural effect receive control review, not only brand approval.

Staff communication is part of the same system. The specialist sees what the customer saw and answered, with channel and time. They should not ask the same question unnecessarily or contradict the app. If a transfer occurs, the handoff says why and what evidence remains unresolved. The agent cannot fabricate a warm handoff from an unread transcript.

After the event, messages remain state-accurate. A case acknowledgement distinguishes investigation, recovery request, temporary credit and final resolution. The customer can see what information is needed and how to challenge an error. Confidential financial-crime work remains outside the message context.

A good message produces safer understanding, not merely a button press. Its effectiveness is a measured part of the control and its failure can justify narrowing an otherwise accurate model.

Industry evidence must remain in its lane

The UK Finance Annual Fraud Report 2026 is industry-reported evidence. It describes changes in payment-fraud categories and the continued significance of APP scams. It helps frame threat movement and operational priorities. It does not establish the effectiveness of one bank's agent or prove that a specific architecture will prevent loss.

Vendor surveys can identify adoption hypotheses, but their samples, definitions and commercial interests need scrutiny. A claim that organisations “saved” an amount may be modelled avoided loss rather than realised recovery. Such evidence belongs in a clearly labelled market section, not beside regulator requirements or controlled experiment results.

Architecture should be justified by failure containment and measured local outcomes, not by market enthusiasm. The evidence hierarchy is official obligation and scheme rule, controlled internal measurement, independent research, public industry data, then vendor claim.

Engineer operational resilience around customer impact

A fraud platform can be highly available and still fail its important service. If beneficiary intelligence is down, the transaction engine may continue authorising. If the intervention channel fails, payments can expire into a fallback customers do not understand. If case tooling is unavailable, recovery requests can miss a perishable window. Availability must be evaluated against the service outcome and the rail's deadlines.

The Bank of England's June 2026 operational-resilience supervisory statement for recognised payment-system operators and specified service providers applies to its stated firms and framework, not every bank or fraud service. Its focus on important business services, impact tolerance and severe-but-plausible disruption is nevertheless a useful official illustration of outcome-based resilience thinking. Institutions should apply the requirements that actually govern them.

Map the service from customer request to final state. Include authentication, event streaming, online features, detection, policy, beneficiary intelligence, intervention channel, specialist staffing, payment execution, case creation and recovery routes. Identify synchronous dependencies that can block a payment and asynchronous dependencies whose absence weakens evidence. The map must include third parties and manual teams, not only software components.

Fault injection should test the composed path. Simulate slow sources, partial event feeds, model failure, corrupted schemas, unavailable reviewers, duplicated messages, network partitions and clock skew. Observe the payment state and customer message, not only the component error. A chaos test that shows a service restarted is insufficient if customers received contradictory states.

Capacity is part of resilience. An intervention policy calibrated with specialists available can become harmful when the queue grows. The policy service needs current capacity bands and actions approved for each operating state. It cannot automatically relax a critical control to protect average response time. Nor can it hold more payments than staff can resolve before expiry.

Manual workarounds have access and evidence controls. A spreadsheet emailed to a personal address is not a recovery route. Staff need a protected minimum interface or approved contingency procedure with identifiers, templates, recipient verification and later reconciliation. Exercise it regularly and measure how long it supports the important service.

Recovery priorities should consider customer impact and payment state, not simply queue age or amount. A vulnerable customer with a time-critical report may require specialist attention. A large pending payment close to expiry may require a rapid decision. The priority rule is documented and tested; a model can surface facts but does not secretly reorder cases.

Incidents trigger lineage analysis. A faulty feature or model version identifies affected payments, actions, interventions and downstream cases. The control owner decides whether to notify customers, reassess decisions, correct intelligence or amend datasets. Restoration does not end the incident until integrity is reconciled.

Resilience means the institution can keep the payment, customer and evidence states coherent under failure. It is not merely the ability to keep an agent endpoint responding.

Govern the whole decision system, not an undifferentiated model

The fraud stack mixes deterministic policy, conventional models, generative components, third-party signals, human intervention and ledger services. Each has a different owner and assurance method. Calling the whole stack “the AI model” makes accountability vague. Calling the agent “just a user interface” understates its influence on evidence and reviewers.

For United States banking organisations in its scope, the Federal Reserve's SR 26-2 revised model-risk guidance, issued with the OCC and FDIC in April 2026, applies to traditional statistical, quantitative and non-generative, non-agentic AI models and expressly excludes generative and agentic AI from the guidance's formal scope. A conventional fraud model may therefore sit within the applicable model-risk framework, while the agent layer requires governance chosen for the complete system. The exclusion is not an exemption from risk management.

The inventory should list components and their use, not only vendor names. For the scoring model: population, features, training data, calibration, limitations and validation. For the agent: model and prompt version, tasks, tools, data classes, action ceiling, evaluation and human interface. For policy: owner, rules, jurisdictions, effective date and approvals. For third-party intelligence: source, semantics, expiry and assurance. For human operations: roles, capacity, training and quality review.

Release evidence is component-specific and integrated. A model's discrimination and calibration do not prove the action policy is fair or resilient. Agent citation accuracy does not prove the payment state is safe. Usability does not prove protected data is contained. The integrated test passes only when all critical boundaries meet their gates on the same representative scenarios.

Change impact follows observable effects. A prompt change that alters which facts specialists see is a control change. A beneficiary-provider schema change can alter score meaning without changing the model. A channel redesign can change customer comprehension. Each candidate release states the intended improvement, affected populations, critical failures, rollback and cases requiring revalidation.

Roles should remain named. The fraud-control owner is accountable for the objective and risk appetite. Payment engineering owns state and execution. Data owners own feature meaning and quality. Model owners and validators govern conventional models where applicable. The agent product owner owns tool scope and observable behaviour. Security owns identity and containment. Customer, legal, conduct and privacy owners approve their requirements. Operations owns case execution and capacity. Independent assurance challenges the system.

The NIST AI Risk Management Framework is a voluntary, sector-neutral reference whose govern, map, measure and manage structure can help connect these roles. Its generative profile, cited later, adds generative-specific considerations. Neither decides the applicable payment or banking obligations.

Management reporting must show limits. A reported fraud-loss reduction may coincide with more declined legitimate payments or customers abandoning a channel. A higher review rate may reflect a model shift or a threat shift. Results include cohorts, observation windows, policy changes, unresolved labels and source coverage. Hypothetical avoided loss is marked as an estimate with assumptions, not reported as realised saving.

Stop authority is explicit. Security can disable a leaking tool. Payment owners can block an invalid command. Fraud control can revert a threshold or policy. Customer owners can suspend a harmful intervention. An incident leader coordinates the whole system. No team must wait for the next model-governance meeting to contain an active defect.

The decision system is the governed object because customer harm and fraud loss emerge from its interactions. Component assurance is necessary; end-to-end accountability makes it meaningful.

Evaluate the system at five boundaries

Transaction accuracy alone is insufficient. The release suite must test signal construction, policy action, evidence assembly, human intervention and customer outcome. A system can catch more fraud while creating excessive false declines, inaccessible challenges or unreviewable evidence.

The adversarial corpus should include a familiar device used under coercion, a new device making a legitimate urgent payment, a beneficiary with a false network match, an intelligence source that times out, a prompt injection in payment text, a vulnerable customer, and a case where the correct action changes after new evidence. Expected behaviour is defined as typed states and source events, not hidden model reasoning.

Private chain-of-thought is neither requested nor retained. The assurance record is the model/rule version, inputs, policy decision, tool calls, evidence references, human action and ledger receipt. A concise rationale can connect exposed facts to a recommendation. If an incident cannot be replayed from observable events, the system is not ready for consequential action.

Measure economics without turning avoided loss into fact

Fraud business cases often add the value of declined high-risk payments and call it loss prevented. That is an estimate, not an observed outcome. Some declined payments would have been legitimate; some fraudulent attempts would have failed or been recovered; some customers will retry through another channel; and interventions carry operational and customer cost. A credible economic model preserves those uncertainties.

Start with observed ledger and case quantities: gross attempted value, authorised value, confirmed outcome under a stated definition, recovered funds, reimbursement, temporary credit, operational error, customer compensation and direct processing cost. Keep stock, flow and accounting treatment distinct. A recovery is not new revenue. A reimbursement reduction is not automatically fraud prevention if customer eligibility or policy changed.

Estimate avoided loss through designs proportionate to risk. Shadow mode compares decisions but cannot observe what would happen after a counterfactual intervention. Limited randomisation may be possible for low-consequence messaging or routing where lawful and ethically approved, not for withholding required controls. Staggered rollout, matched cohorts and policy discontinuities can provide evidence with assumptions and bias stated. No method should be described as causal merely because it has a control group name.

The PSR reimbursement dashboard provides regulator-published outcomes for its specific United Kingdom scope. It can help test market context and definitions, but it does not supply the counterfactual for one institution's agent. The UK Finance report cited earlier remains industry evidence and should not be blended with internal audited results.

Customer lifetime or trust effects should be measured cautiously. Complaint, attrition, reduced payment use and repeated intervention are observable. Attributing them to one control requires analysis. Assigning a hypothetical lifetime value to every abandoned payment can make either fraud prevention or friction appear arbitrarily large.

Capacity benefits are realised only when work changes. If the agent saves retrieval time but specialists use it for deeper investigations, the benefit may be improved control quality or avoided future hiring rather than current cost removal. Report the realised outcome accurately. Include new work in source assurance, prompt and policy release, security, evaluation, customer testing and incident response.

Segment economics by mechanism and action. APP-scam intervention, account-takeover step-up and post-event recovery have different loss, latency and customer profiles. An aggregate return can hide a profitable high-volume control subsidising a harmful low-volume one. It can also hide poor service for a group whose payments are smaller in monetary terms but essential in consequence.

Decision thresholds should not maximise one currency total. Risk appetite includes customer rights, access, conduct, resilience and legal obligations. The economic view informs that judgement and shows trade-offs; it does not replace the authority of control and customer owners.

Publish scenario ranges before production and observed cohorts after it. Label assumptions, confidence and maturation. Reconcile modelled avoided loss with later case outcomes and revise the method when it is biased. A programme that never lowers its prior benefit estimate after real evidence is not measuring.

The sound business case is usually broader than labour reduction and narrower than every payment “saved.” It values demonstrable loss reduction, faster recovery, better customer outcomes and stronger evidence while counting the full operating and control cost.

Drift is a fraud feature, not an edge case

Fraud patterns adapt to controls. A model that remains statistically stable may become less useful because criminals move to a different channel or manipulate genuine customers. The EBA-ECB report's distinction between strong-authentication effectiveness and rising payer manipulation illustrates why one aggregate fraud rate cannot explain control performance.

Monitoring should separate population shift from policy shift. Watch new-payee share, device continuity, intervention reasons, beneficiary-network coverage, agent tool selection, evidence timeouts, human overrides and outcome labels by fraud typology. A sudden drop in beneficiary queries may indicate a service problem before confirmed losses appear. A rise in APP interventions may reflect a real threat shift rather than model drift.

Baselines must be versioned. Recalibrating a threshold should create a change record and replay result, not erase the prior behaviour. When a source changes its schema, the evidence agent should fail closed for affected claims and route to the defined fallback. When the generative model changes, policy and ledger code should not.

The NIST Generative AI Profile offers a non-binding lifecycle frame for generative risks. NIST SP 800-207 is useful for the principle that trust should not follow network location alone. Neither replaces payment, consumer or financial-crime requirements. They support the technical design of bounded identity, access and monitoring.

Failure modes that should stop deployment

The first is an agent in the direct authorisation path with an open-ended tool. A model update or crafted payment description could then change ledger behaviour. Replace it with typed policy actions and downstream enforcement.

The second is hindsight leakage. If later confirmed fraud data appears in the decision-time replay, evaluation will overstate what the live system could know. Preserve knowledge time and source version.

The third is “usual device equals safe customer.” Social engineering can occur inside an authenticated session. Device continuity is one feature, not a decision.

The fourth is customer contact that reveals the rule or blames the victim. Approved question sets, usability testing and specialist escalation are part of fraud control, not cosmetic content review.

The fifth is one outcome label for every regime. Unauthorised transfer, APP scam, reimbursement and suspicious-activity outcomes are different. Store the governing process and decision basis.

The sixth is a network-risk score without provenance. A score may be stale, commercially opaque or based on an unresolved entity. Preserve its provider, time, scope and known limitations.

The seventh is an alert queue that silently becomes a transaction queue. Case backlog must not leave payments indefinitely pending. Every state needs a deadline and fallback owned by the payment service.

The production standard

Production reporting should preserve three denominators. The payment denominator shows every eligible attempt and action, including controls that never opened a case. The intervention denominator shows customers who saw, completed, abandoned or escalated each journey. The case denominator shows mature outcomes, recovery and remediation. Dividing case fraud by payment attempts without accounting for label maturity, or intervention success by only completed challenges, produces misleading confidence.

Decision ownership should also remain visible after the event. The payment service owns the executed state. Fraud control owns the approved policy. The specialist owns the recorded intervention judgement. The dispute investigator owns the customer-case finding. The recovery team owns its requests and reconciliation. Any financial-crime reporting role owns its separate protected decision. A shared case identifier connects evidence without implying one person or model made all decisions.

The system should be able to produce a customer-safe explanation distinct from an internal control rationale. The first states the payment or case status, information required and route to challenge. The second preserves model, rule, policy and evidence detail for authorised review. Neither is generated from hidden reasoning. Both derive from observable events and approved language.

A production claim needs a period, population and evidence status. “Reduced handling time” says which case types, whether customer waiting is included and whether quality remained inside gates. “Prevented loss” distinguishes observed from estimated value. “Improved detection” states the mature label definition and effect on legitimate payments. Vendor benchmarks and composite scenarios cannot substitute for those local measurements.

The production standard is not that every component is intelligent. It is that every payment effect, customer interaction and case conclusion has a known authority, recoverable state and supportable evidence.

The design is ready only when an operator can answer these questions from retained evidence:

• What information was available before the payment decision?
• Which model, rules and policy converted it into a typed action?
• What could the investigation agent retrieve and why?
• Which source failures were visible?
• Which actor authorised the eventual ledger effect?
• Could the system recover if the agent or evidence service failed?
• How did the customer experience the intervention?
• Which later facts changed the case outcome?
• Which legal or policy process governed dispute and reimbursement?
• Was a financial-crime referral handled by a separate authority?
• Can the case be replayed without private reasoning text?
• Which measurements would narrow or stop the agent's permissions?

Real-time fraud control is a system of clocks, evidence and authority. Speed belongs in evidence retrieval and deterministic execution. Judgement remains attributable, and every effect remains bounded by policy.