AI can group suspicious payments, summarise a case and propose why two records did not reconcile. It must not rewrite the ledger, silently reject a fraud claim or move safeguarded money. Payment operations need deterministic books, explicit regulatory scope and human ownership of consequential decisions.
This guide reflects the UK position on 31 July 2026. FCA and Payment Systems Regulator requirements discussed here apply to specified firms, systems and transactions, not every merchant finance team. Banks, payment institutions, e-money firms, account-information providers, merchants and outsourced operators must determine their own regulatory perimeter and obtain specialist advice.
Separate three different operating problems
Fraud detection, fraud-claim handling and reconciliation interact but have different truths.
- Detection estimates whether an event or pattern deserves investigation.
- Claim handling determines what happened, what rules apply and what remedy is due.
- Reconciliation proves that independent records agree or creates an owned exception.
A model score is not a ledger entry or legal conclusion. Keep the event stream, accounting record, safeguarding calculation and case system separate, joined through stable identifiers and controlled interfaces.
Our UK payments AI and fraud-prevention guide-fraud-prevention-uk) covers preventive patterns. This playbook focuses on the operational evidence after an alert, transaction or settlement arrives.
Record the current regulatory baseline
The FCA’s strengthened safeguarding rules for relevant payment and e-money firms took effect on 7 May 2026. The FCA safeguarding requirements page explains the applicable regimes and states that internal and external safeguarding reconciliations must be performed at least once each reconciliation day for firms in scope.
CASS 15 defines the supplementary safeguarding regime, including calculation of safeguarding resources, requirements and individual balances. The FCA’s PS25/12 policy statement sets out audits, monthly reporting, resolution packs and related changes. AI may help explain an exception, but the firm remains accountable for compliant records and calculations.
Authorised push payment scam reimbursement is another distinct regime. The PSR’s consolidated APP scams policy statement guides interpretation, while definitive obligations sit in the legal instruments and scheme rules. The June 2026 PSR dashboard reports outcomes through December 2025; it should not be treated as a guarantee for an individual claim.
| Control record | Authoritative source | AI may do | AI must not do |
|---|---|---|---|
| Customer ledger | Posted transaction system | Retrieve related events | Modify entries |
| Safeguarding calculation | Approved deterministic method | Explain variances | Choose inclusions |
| Scheme settlement | Network and bank files | Suggest matches | Invent missing records |
| Fraud case | Preserved evidence and reviewer decision | Summarise chronology | Auto-reject a claimant |
| Reimbursement | Current rules and case facts | Retrieve relevant criteria | Apply an unstated policy |
| General ledger | Controlled accounting process | Propose journal support | Post without authorisation |
Design a reconciliation spine
Ingest each source without transformation first: payment instruction, authorisation, gateway event, network clearing, bank settlement, customer ledger, fees, refunds, chargebacks and general ledger. Preserve file hash, row count, control total, currency, time zone, received time and source owner.
Normalise into a canonical event model with separate event, processing and settlement times. Record gross amount, fee, net amount, currency, status and references. Never overwrite an earlier state when a payment moves from authorised to captured, reversed or disputed.
Use deterministic matching first:
- exact scheme or processor reference;
- account, currency and exact amount within the expected window;
- approved composite key for known source limitations;
- controlled one-to-many or many-to-one allocation;
- an exception when no rule resolves the records.
AI can rank candidate matches for an exception analyst, but show every component and why the candidate was proposed. A suggestion cannot mark an item reconciled. The reviewer action, rule, evidence and resulting journal must remain attributable.
Define tolerances by purpose. A rounding tolerance may be valid for a converted fee but not for customer safeguarded funds. Separate timing differences from unexplained value differences and track their age.
Build fraud review around evidence and customer harm
A detection model should create a case with reason features, not a verdict. Preserve the transaction, authentication, device and account events that existed at decision time. Do not reconstruct the evidence from a live profile that has since changed.
Route by risk and urgency. A suspected account takeover may justify a temporary protective step under an approved policy, while a reimbursement decision requires investigation against the current rules. Provide customers a reachable route to report context, correct data and obtain support.
Reviewers should see:
- transaction and beneficiary chronology;
- authentication and Confirmation of Payee results where relevant;
- device, session and account-change evidence;
- known-scam indicators with source and date;
- customer contact and vulnerability needs;
- model reasons, uncertainty and counter-evidence;
- applicable policy version and decision deadline.
Do not present a proxy feature as cause. Unusual location, device or typing speed can reflect travel, disability, shared equipment or security software. Test adverse outcomes across product, channel, age bands and other lawful monitoring dimensions, with privacy and equality advice.
The FCA’s [financial-crime resources](https://www.fca.org.uk/firms/financial-crime) place technology inside wider systems and controls. Our AI cyber-resilience guide helps connect payment cases with account and infrastructure incidents.
Human review must be capable of changing the result
Do not measure reviewers by agreement with the model. Give them the underlying evidence, policy, alternative outcomes and authority to reverse. Capture the reason for disagreement and quality-assure both approvals and rejections.
Escalate ambiguous civil disputes, vulnerable-customer cases, high values, novel scam types and conflicting identity evidence. A second reviewer should handle the highest-impact outcomes. Make deadlines visible so “manual review” does not become indefinite delay.
The ICO’s existing automated-decision guidance is being updated after the Data (Use and Access) Act. Its technology guidance plan said final updated ADM and profiling guidance was due in winter 2026, after this cutoff. Teams should use current law and guidance and not treat a consultation draft as final.
Where a decision has a legal or similarly significant effect, document whether human involvement is meaningful and provide applicable safeguards, information and contest routes. Fraud prevention does not eliminate data-protection obligations.
Privacy, security and model controls
Payment telemetry can reveal location, behaviour, relationships and financial vulnerability. Define purpose, lawful basis, minimisation, retention and access for each data source and derived feature. A data broker’s “fraud intelligence” label does not prove its collection is lawful or accurate.
Keep raw payment data, model features and analyst notes compartmentalised. Tokenise account and card identifiers. Prohibit sensitive data from general-purpose model training. Contract for processors, transfers, deletion, incident notification, audit and cooperation with complaints or regulator requests.
Threat-model prompt injection in merchant descriptions, payment references, customer messages and case attachments. Untrusted text must not change risk thresholds or tool permissions. A summarisation model should have read-only access to a bounded case bundle, never credentials for payment execution.
Follow the NCSC’s secure AI development guidelines and the government’s AI Cyber Security Code of Practice. Monitor model drift, adversarial inputs, data-pipeline compromise and unauthorised case access.
Operate through independent control totals
Every source load should prove row count and monetary control total before matching. Each reconciliation run should report opening population, exact matches, allocated matches, breaks, reversals, manual actions and closing unresolved value. The sum must balance independently of the AI service for every affected legal entity and settlement currency.
Use dual authorisation for bank-detail changes, high-risk journals and write-offs. Separate operators who configure matching rules from those who approve exceptions. Lock accounting periods and preserve later adjustments rather than editing historical evidence.
Re-run reconciliation after late events using an idempotent process. A retry must not duplicate journals, refunds or case actions. Keep a manual runbook and tested ability to operate when the model or vendor is unavailable.
Measure outcomes, not alert volume
Track:
- unreconciled count and value by cause and age;
- false match and missed-match rates from sampled review;
- safeguarding or ledger differences and resolution time;
- fraud precision, recall and loss by typology;
- customer claim time, reimbursement outcome and complaint rate;
- false positives and account restrictions by cohort;
- reviewer override, second-review and correction rates;
- model, feed, privacy and security incidents.
Measure detection alongside customer harm. A system that blocks more legitimate payments and drives more complaints is not necessarily better. Reconciliation productivity should exclude work merely transferred to accounting or customer support.
A measurable 90-day pilot
Days 1–30 — perimeter and baseline. Confirm regulated entities, payment flows, rules and decision owners. Choose one processor and currency. Map event lineage, control totals, fraud case data, lawful bases and suppliers. Baseline reconciliation age, losses, false positives, complaints and analyst time.
Days 31–60 — shadow operation. Run deterministic matching and AI candidate ranking on a preserved copy. Keep production unchanged. Replay late settlements, duplicates, partial refunds, multi-currency fees, scam claims and malicious references. Calibrate the model by typology and customer segment.
Days 61–90 — bounded assistance. Allow AI summaries and suggested exception matches for trained reviewers. No automatic rejection, journal or payment action. Reconcile daily to independent totals, sample accepted cases and exercise provider failure, data rollback and customer contest.
Expand only when:
- source and monetary control totals balance for every run;
- zero AI suggestion posts or changes a ledger without approval;
- sampled false matches remain below the risk-specific threshold;
- all consequential fraud decisions have evidence, policy and reviewer identity;
- unresolved value and case time improve without more corrections or complaints;
- access, deletion and supplier controls pass independent testing;
- manual processing succeeds during an outage exercise.
Pause when control totals fail, a source feed loses integrity, model drift changes a high-risk cohort, reimbursement deadlines are at risk, or a reviewer cannot inspect evidence. Disable automated actions after an unexplained ledger movement, duplicate refund, safeguarding discrepancy or access incident. In payments, a clean audit trail is part of the product.
Primary sources checked
- Safeguarding requirements for payment and e-money institutions, FCA, updated 7 May 2026
- CASS 15: payment services and electronic money relevant funds, FCA Handbook
- PS25/12 safeguarding regime changes, FCA
- Payment Services and Electronic Money key publications, FCA, updated July 2026
- APP scams reimbursement consolidated policy statement, PSR
- APP scams reimbursement dashboard, PSR, updated 11 June 2026
- Financial crime resources, FCA
- ICO technology guidance plans, including ADM and profiling
- Guidelines for secure AI system development, NCSC
- AI Cyber Security Code of Practice, DSIT



