The clock · UK APP scam claims

Stop the clock (PSR): five reasons to pause, one day-35 limit

Under the PSR's APP reimbursement rules, a bank may stop the five-day clock only while it waits for an answer to a request made for one of five listed purposes, and must still close the claim by the end of the 35th business day. This guide works through the rule, a worked count across Christmas, and how APP Fraud Reimbursement keeps every stop inside it.

Updated · 12 min read

"Stop the clock" is the PSR provision that lets a bank pause the five-business-day deadline for reimbursing an APP scam victim, but only while it waits for a response to a request for information made for one of five permitted purposes, and never past the end of the 35th business day after the claim was reported. The pause starts when the request is sent and ends the moment an answer arrives. A bank can stop the clock as many times as it needs to. It cannot stop it to give a handler more time, to wait for a backlog to clear, or to think. That makes each stop a small decision with its own evidence: which purpose, what was asked, when it went, when the answer came. Botminds' APP Fraud Reimbursement treats it that way. An agent drafts the request and names its purpose, a reviewer approves the stop, and the clock's history goes into the bank's monthly reporting.

The rule matters because the five days are tight and the information a claim needs is often outside the bank: messages on the customer's phone, the receiving bank's view of the mule account, a conversation about the customer's circumstances. What follows is the rule in the PSR's words, a worked count, and the operating choices it forces.

One claim, two stops: five business days stretch to eight

With two stopsdue Tue 8 Dec
Runningdays 1–2
Stopped: waiting for the customer’s messagesstop 1
Runningdays 3–4
Stopped: vulnerability call bookedstop 2
Runningday 5
  • Runningdays 1–2
  • Stopped: waiting for the customer’s messagesstop 1
  • Runningdays 3–4
  • Stopped: vulnerability call bookedstop 2
  • Runningday 5
With no stopsdue Thu 3 Dec
Runningdays 1–5
  • Runningdays 1–5
An invented claim reported on Wednesday 25 November 2026, counted in whole business days with the day after the report as day 1. Business days exclude weekends and bank holidays in any part of the UK, so St Andrew's Day (Mon 30 Nov), 25 and 28 December, 1 January and Scotland's 2 January holiday (Mon 4 Jan) are skipped. Either way the claim must close by the end of the 35th business day, Wednesday 20 January 2027. The rule itself pauses the clock from the moment a request is sent to the moment an answer arrives (SR1 para 5.5).Source: PSR, Specific Requirement 1 (July 2024); GOV.UK, UK bank holidays

When can a bank stop the clock on an APP claim?

Only when it has asked for information to assess the claim and is waiting for the answer, and only for one of five purposes. Specific Requirement 1 puts it in one sentence: a firm "can only stop the clock if it has asked for information to assess the claim and is waiting for a response in at least one of the following circumstances". The PSR's consolidated policy statement closes the door on everything else: "These are the only circumstances in which a sending PSP may ‘stop the clock’."

Two conditions therefore have to be true at once. There must be an outstanding request, sent by the bank, and it must serve a listed purpose. A handler who has all the information but has not yet read it cannot stop the clock. Nor can one waiting on an internal fraud team, a manager's view or a system extract, because none of those is a request to the parties the rule names.

The five permitted purposes, and who must answer

The five purposes cover the customer, a claims management company acting for them, the receiving bank, law enforcement, and other firms in a multi-step scam. Each request goes to a different party, and only some of them place a duty on the customer.

The five purposes for which the clock may stop

Purpose (SR1 para 5.4)Who is askedDoes the customer have to answer?
a. Assess whether the claim is a reimbursable APP scamThe victim, their agent, or the receiving firmYes, where the request goes to the customer
b. Verify that a claims management company is submitting a legitimate claimThe company, and the customer it says it acts forYes
c. Gather additional information to assess vulnerabilityThe victimYes
d. Where there is evidence of fraud by the person claiming, gather informationThe receiving firm, law enforcement or other relevant partiesNo, on its wording
e. In a multi-step scam, gather information from the other firms involvedThe other payment firmsNo, on its wording
Purposes as listed in Specific Requirement 1, para 5.4. The PSR notes that two of the five 'do not place an obligation on consumers' (PS25/5, footnote 23); which two is our reading of their wording. The customer's duty to respond comes from the consumer standard of caution, which covers reasonable and proportionate requests for these purposes.Source: PSR, Specific Requirement 1 (July 2024); PSR, PS25/5 consolidated policy statement, May 2025

The distinction matters later. A customer who fails, through gross negligence, to answer a reasonable request for one of the customer-facing purposes may lose the claim under the consumer standard of caution. A receiving bank that is slow to answer is a different problem: it must respond "in a timely and accurate manner" (SR1 para 5.6), and its delay is the sending bank's to escalate, not the customer's to bear.

When does the clock stop, and when does it restart?

It stops when the bank sends its request and restarts as soon as the bank receives a response. The rule is precise about both ends: the five-day timescale "is paused at the point when the sending PSP sends its request for information. The five-day clock resumes as soon as the sending PSP receives a response."

Three operating consequences follow. The send time and the receipt time both need to be captured to the minute, because together they are the evidence that the stop was valid. A response restarts the clock even if it is incomplete; whether a partial answer justifies a second request is a new decision. And a request drafted on Monday but sent on Wednesday stops nothing until Wednesday.

How many times can the clock be stopped?

As many times as necessary, within one hard limit. The rule says the bank "can stop the clock as many times as necessary. However, it must close the claim before the end of the 35th business day following the reporting of the APP scam claim". Closing means either reimbursing the customer for every reimbursable payment or rejecting the claim, with written reasons given first (SR1 paras 5.8 and 5.9).

Firms rarely run out of time. The PSR's dashboard reports that over the first 18 months, 82% of claims were closed within five business days and 98% within 35. Its supervision team added a caution worth noting: "our data reflects only closed cases, so a small number of more complex ones that take longer to resolve may not be included." A claim still open after day 35 does not appear in a closed-claims statistic, which is why the long stop needs watching claim by claim.

How quickly claims close, and the cases the figures miss

82%

closed within five business days

7 Oct 2024 to 31 Mar 2026

98%

closed within 35 business days

same period

84%

closed within five business days in the first nine months

Oct 2024 to Jun 2025

5

purposes for which a clock may stop, and no others

SR1 para 5.4

Faster Payments claims closed in each period, as reported by sending firms to Pay.UK and published by the PSR. Claims still open are not counted.Source: PSR, APP scams reimbursement dashboard, Q1 2026; PSR, One year on: impact of APP reimbursement on victims, 8 October 2025

What is the 35 business day limit, counted the rule's way?

It is the end of the 35th business day after the day the claim was reported, and the rule's definition of a business day is wider than most calendars assume. Specific Requirement 1 defines a business day as any weekday that is not "a bank holiday in any part of the United Kingdom". A bank that counts only English and Welsh bank holidays will set some deadlines a day or two earlier than the rule does. That is safe for customers, but it misstates which claims were on time.

Take the claim in the figure above, reported on Wednesday 25 November 2026. Counting the next day as day 1, the five-day deadline with no stops is Thursday 3 December, because Monday 30 November is St Andrew's Day, a bank holiday in Scotland. On an England-and-Wales calendar it would be Wednesday 2 December. The long stop moves the same way. Skipping 30 November, Christmas Day, 28 December (the substitute Boxing Day), New Year's Day and Scotland's 2 January holiday, which falls on Monday 4 January 2027, the 35th business day is Wednesday 20 January 2027. An England-and-Wales count gives Monday 18 January (GOV.UK bank holidays).

The stops in the example work like this. On day 2, Friday 27 November, the handler asks the customer for the messages exchanged with the fake seller (purpose a), and the clock stops. The messages arrive at the start of Wednesday 2 December, after one stopped business day. On day 4, Thursday 3 December, a note on the file suggests the customer may have been in hospital during the scam, and the bank books a call to assess vulnerability (purpose c) for Tuesday 8 December. After two more stopped days, the call takes place, the clock restarts, and day 5 falls on Tuesday 8 December. The two stops added three business days to the five. The long stop did not move at all.

Can a bank stop the clock to check vulnerability?

Yes. Gathering additional information from a victim to assess their vulnerability is one of the five purposes (SR1 para 5.4c), and the PSR's consumer page gives it as its example: "firms may need more information from victims to assess their vulnerability to the scam."

Two cautions apply. The request must still be proportionate, so a stop to ask about vulnerability needs a reason in the file, not a routine question put to every customer. And vulnerability can show itself in the stop itself: the PSR's guidance warns that where a customer cannot or will not answer, "this may be indicative of vulnerability", and firms should not mistake it for gross negligence. A stop that goes unanswered is a signal to look harder at the customer, not a route to refusal.

The clock above the claim, with the long stop always in view

A claim page for a fictional customer, Edith Carraway, 74, romance scam, £11,750, six Faster Payments. A strip across the top shows the clock: reported Monday Oct 19 at 9:12 a.m., day 1 Tuesday Oct 20, day 2 Wednesday, day 3 today Thursday Oct 22, day 4 Friday, day 5 Monday Oct 26 due. On the right: Clock never stopped. Long stop: 35th business day, Mon Dec 7. Below, the claim's five questions answered in turn, with the decision proposed and buttons to approve, change the amount, refuse with a reason or stop the clock.
Fictional sample data. Stopping the clock is a request the handler makes from the claim; it goes to a reviewer for approval before the request is sent.

What if the customer does not reply?

The clock stays stopped, but the bank cannot simply wait out the 35 days and reject. The guidance limits what can be asked and what silence means. Requests must be "strictly limited to essential information", proportionate to the value and complexity of the claim, and firms "should not impose unreasonably short time frames" for answers. Firms should not use requests "to deter or frustrate reimbursement claims".

Where the customer still does not answer, the question becomes whether the silence is gross negligence, and the guidance makes that hard to show. Reluctance driven by "emotional, psychological or other complexities" would not in itself justify a refusal. A sensible operating rule is to chase by a second channel, record each attempt, and put the claim to a reviewer well before day 35, with a decision on the evidence the bank already has.

Does a claims management company stop the clock?

Verifying that a claims management company is submitting a legitimate claim is the second permitted purpose, for example confirming that the victim authorised it. The clock stops while that check is outstanding. Specific Requirement 1 treats a claims management company as the victim's agent, so once it is verified, the claim runs as if the customer had made it.

The company's involvement does not change the customer's duties. The guidance says a consumer using one "can be expected to meet the same disclosure obligations" as one who claims directly. The refund goes back to the account that made the payment unless the customer is using a claims management company or the law requires otherwise (PS25/5 para 3.17), which is one more reason to complete the verification before money moves.

An agent that asks, a person who approves the stop

Because every stop needs a purpose, an outstanding request and two timestamps, it is well suited to an agent that drafts and records, with a person approving. In Botminds' APP Fraud Reimbursement the Clock agent counts business days using UK bank holidays, records each stop of the clock with its permitted purpose, watches the long stop and raises an alert at 9:00 a.m. on day 4. It stops a clock only after a reviewer approves. The handler role can request a stop but cannot approve one.

How a stop of the clock moves from request to restart

  1. Agent

    Clock agent

    Counts business days from the report against the UK bank-holiday calendar, and shows the five-day due date and the 35th-day long stop.

    Never: Stops a clock on its own

  2. Agent

    Draft request

    Drafts the request for information, names which of the five permitted purposes it serves, and says what is asked and why it is needed.

  3. A person decides

    Reviewer approves the stop

    Checks the purpose is one the rule allows and the request is proportionate, then approves; the request goes out and the clock pauses at that moment.

  4. Agent

    Answer arrives

    Restarts the clock when the response is received, logs both times, and raises an alert on day 4 of the five.

  5. A person decides

    Handler decides

    Decides inside the remaining days, and in any case before the end of the 35th business day after the report.

The steps as Botminds' solution runs them. The agent can draft and count; only people approve a stop and decide the claim.

Below a confidence threshold the agents ask rather than propose, and that includes the question that most often leads to a stop. In the solution's fictional sample, a vulnerability signal scored 0.74 against a threshold of 0.85, so the Vulnerability agent put it to the specialist instead of proposing a finding. Her clock was stopped for a permitted purpose while a call was booked. Every stop then appears in a log with its purpose and approver, which a bank can export for Pay.UK, the PSR or the Financial Ombudsman.

Every stop, with its permitted purpose and who approved it

An audit trail screen with a dialog titled Build an export pack. The option PSR and FCA request is selected: decisions with reasons, stop-the-clock log, timings, vulnerability outcomes, contributions, agent versions. Period September 2026, redaction accounts to last four and health details removed. Progress lines: collected 1,342 claims; added the stop-the-clock log, 113 stops, each with its permitted purpose and approver; added evidence and letters; redacted and sealed.
Fictional sample data: a month's export for a regulator's request, including 113 stops of the clock, each with the purpose the rule permits and the person who approved it.

What every stop-the-clock request should carry

  1. One named purpose from the five

    If no purpose fits, the clock cannot stop, whatever the reason for the delay.

  2. The exact question, and why the claim needs the answer

    Requests must be limited to essential information and proportionate to the claim.

  3. The time it was sent, and to whom

    The pause starts at sending, not at drafting.

  4. A reasonable time to reply, and a second channel

    Short deadlines and single attempts invite a complaint, and may miss a vulnerable customer.

  5. The approver

    A second person confirms the purpose and proportionality before the request goes.

  6. The long-stop date

    Counted with bank holidays across the UK, and shown on the claim until it closes.

What the PSR may change about day 35

The PSR plans to consult in December 2026 on how claims that cannot be resolved within 35 business days should be treated. Its policy roadmap, published after the July 2026 independent evaluation, lists among the policy parameters it will consult on "the treatment of claims that cannot be resolved within 35 business days", with a decision and revised legal directions planned for May 2027. Until then the rule stands as written. What the consultation means for the regulator's handover to the FCA is covered in APP fraud reimbursement and the FCA.

For a bank the practical step is the same either way: know, every morning, which claims are stopped, for which purpose, waiting on whom, and how many business days remain to the long stop. A claim found on day 34 is a claim decided on whatever is in the file. For how stops fit the daily work of a claims team, see PSR mandatory reimbursement, seat by seat.

Questions people ask

Can a bank stop the clock while it waits for the receiving bank?

Yes, if it has asked the receiving bank for information to assess whether the claim is a reimbursable APP scam, which is purpose (a). The receiving bank must respond in a timely and accurate manner, and the clock restarts as soon as its answer arrives.

Does the 35-day limit pause when the clock is stopped?

No. Stops pause only the five-business-day timescale. The claim must still close before the end of the 35th business day after the customer, or their agent, reported it, however many stops there were.

Do Scottish bank holidays count when counting business days?

Yes. Specific Requirement 1 excludes any bank holiday in any part of the United Kingdom, so St Andrew's Day and Scotland's 2 January holiday are not business days for any firm, wherever it is based. In late 2026 that moves a 35th-day deadline by up to two days.

Can a bank stop the clock to investigate a mule account itself?

Not on its own initiative. The clock stops only while a request to another party is outstanding. Where the bank has evidence of fraud by the person making the claim, it may stop the clock to gather information from the receiving firm, law enforcement or other relevant parties under purpose (d).

What happens to a claim not closed by day 35?

The firm has missed the requirement, which Pay.UK monitors through monthly compliance reporting and the PSR supervises. The PSR's December 2026 consultation is expected to address how claims that cannot be resolved within 35 business days should be treated.

APP Fraud Reimbursement.
See it on your own files.

An agentic solution from Botminds. UK banks assess APP scam claims within 5 business days and settle the 50/50 split Book a demo, or explore how it works.