APP Fraud Reimbursement: The Claims and Data-Sharing Workflow the PSR Assumes

Mandatory reimbursement turned APP fraud from a goodwill-and-discretion problem into a systems problem. The firms that treated it as a policy update are now discovering they built a manual process where the regulator assumed a machine.

Since 7 October 2024, a payment service provider that sends a Faster Payments transaction a customer later reports as an authorised push payment scam has to reimburse that customer, up to £85,000 per claim, within five business days of the report. A parallel regime covers CHAPS from the same date. This is not a code of practice or a voluntary contingent-reimbursement model. It is a requirement, enforced through the Payment Systems Regulator’s specific directions, with a whole-of-market claims platform sitting underneath it. Most of the commentary you will read about it is written by people selling a case-management product. This is a reading by someone who has to design the workflow the regulator assumes exists.

Reimbursement is a build, not a policy

The tell that a firm has misread this is a single owner in the fraud team with a spreadsheet and an inbox. That arrangement survives at low volume. It does not survive the three structural features the rules impose: a hard decision clock measured in days, a split liability that forces two institutions to agree on the facts of a single fraud, and an evidential test that has to be documented per claim or it did not happen. Each of those is an engineering requirement before it is a compliance one.

Think of it as three subsystems. A claims engine that ingests, tracks and times each case. A data exchange between the sending and receiving PSP that moves the claim and the money in both directions. And an evidence store that captures, per claim, what the consumer did and what the firm decided. Get those three right and the reimbursement obligation becomes a throughput problem you can staff and scale. Get them wrong and every spike in fraud becomes a queue of breached deadlines.

The claims engine has a clock, and it is unforgiving

The default is reimbursement within five business days of the customer reporting the scam. The sending PSP can “stop the clock” to investigate further, including to gather evidence from the receiving PSP, but there is a hard outer limit: an outcome must be reached within 35 business days regardless of how often, or for how long, the clock is stopped. On intake, a separate constraint applies — a firm may decline claims raised more than 13 months after the final payment to the fraudster.

Encode those as first-class fields, not as reminders in someone’s calendar. Every claim needs a started-at timestamp, a running record of stopped periods, and a computed outcome-due-by that recalculates as the clock pauses and resumes. This is the same discipline as an incident-response clock under other regimes, where the moment the timer starts is itself a decision that has to be defensible; I have written before about the classification logic that decides when a regulatory clock starts, and the reasoning transfers directly. If your system cannot tell you, at any instant, how many business hours remain on every open claim, you do not have a claims engine. You have a backlog with good intentions.

The inter-PSP data exchange is the hard part

Reimbursement liability is shared equally. The sending PSP pays the customer; the receiving PSP then reimburses the sending PSP for 50 per cent of what was paid. That single sentence is where the architecture lives. Two firms, who may never have exchanged a message before, now have to agree on the identity of a payment, the amount in dispute, and the outcome of a claim — inside the same 35-business-day envelope, at whatever volume fraud throws at them.

Pay.UK operates the Reimbursement Claims Management System (RCMS) as the market-wide route for exactly this exchange. Whether you integrate with it directly, through an aggregator, or via a case-management vendor, the discipline is the same: you are exchanging structured claim events, not emails, and both sides must reconcile against a shared reference — the Faster Payments transaction, not a free-text description. Design the message as a versioned event with an explicit schema, so that a claim raised, a request for information, a decision and a settlement are distinct, ordered event types rather than states buried in a PDF.

A workable claim event carries the parties, the disputed payments keyed on the transaction reference, the clock, the standard-of-caution evidence and the decision in one envelope:

{
  "schema": "sixteenpillars.app-fraud.claim/v1",
  "event_type": "app_fraud.claim.raised",
  "claim_id": "CLM-2026-04A9F3",
  "raised_at": "2026-05-11T09:42:17Z",
  "reporting_channel": "app",

  "consumer": {
    "customer_ref": "cust_88213",
    "vulnerable_flag": false
  },

  "sending_psp": {
    "psp_id": "FPS:204512",
    "sort_code": "20-45-12",
    "role": "reimbursing"
  },
  "receiving_psp": {
    "psp_id": "FPS:601789",
    "sort_code": "60-17-89",
    "role": "contributing"
  },

  "disputed_payments": [
    {
      "fps_transaction_ref": "FPSABC000123456",
      "amount_gbp": 6400.00,
      "executed_at": "2026-04-28T14:03:55Z",
      "beneficiary_account": "12345678"
    }
  ],
  "claim_amount_gbp": 6400.00,
  "reimbursement_cap_gbp": 85000.00,
  "excess_applied_gbp": 100.00,

  "clock": {
    "started_at": "2026-05-11T09:42:17Z",
    "stopped_periods": [],
    "outcome_due_by": "2026-06-30T09:42:17Z",
    "final_payment_at": "2026-04-28T14:03:55Z",
    "claim_within_13_months": true
  },

  "standard_of_caution": {
    "specific_warning_ignored": null,
    "prompt_notification": true,
    "responsive_to_psp_requests": null,
    "reported_to_police_or_consented": true,
    "gross_negligence_alleged": false
  },

  "decision": {
    "status": "under_investigation",
    "reimbursed_gbp": null,
    "liability_split": {"sending_psp_pct": 50, "receiving_psp_pct": 50},
    "decided_by": null,
    "decided_at": null
  }
}

The schema is the contract. If the sending and receiving PSP disagree about which field carries the transaction reference, or whether the excess is applied before or after the split is calculated, the 50 per cent settlement will not reconcile and someone will be chasing it by email — which is the failure mode the whole regime was built to remove.

Evidence for the consumer standard of caution

A firm can decline or reduce reimbursement where the customer has been grossly negligent, assessed against the consumer standard of caution. In practice that turns on a small set of factors: whether the customer ignored a specific, targeted warning the firm gave; whether they reported the fraud promptly; whether they responded to reasonable requests for information; and whether they reported the matter to the police or consented to the firm doing so. Two carve-outs matter for the build. The standard of caution does not apply to customers in a vulnerable situation, and the optional claim excess — up to £100 — cannot be applied to them either. Vulnerability is therefore a flag your engine has to hold and honour, not a note in a case file.

The engineering consequence is that “grossly negligent” is a conclusion you must be able to evidence, field by field, at the moment of decision. Capture the warning that was shown, the timestamp it was shown, whether it was specific to this payment, and the customer’s response — at the point of interaction, not reconstructed afterwards. A decision to reduce reimbursement that rests on a warning your systems cannot prove was displayed is a decision that will not survive a complaint to the Financial Ombudsman. This is the same principle as encoding accountability into the sign-off workflow itself: the decision and its basis are recorded together, or the decision is unsupported.

Who this is for

This is for the CTO of a payments firm, e-money institution or bank who owns the systems the fraud team relies on; for the fraud or compliance lead who owns the obligation but not the tooling; and for the board member who signed off “reimbursement readiness” in 2024 and has not asked since whether the process scales. The rules are live and bedding in through 2026. The question is no longer whether you reimburse. It is whether your claims engine, inter-PSP exchange and evidence capture carry the load when one scam campaign puts a thousand claims through the door in a week.

Reimbursement is not the cost of the fraud. The cost is the process you built to pay it — and a manual one fails quietly, one breached deadline at a time, until a regulator asks to see the clock.