"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
- Runningdays 1–2
- Stopped: waiting for the customer’s messagesstop 1
- Runningdays 3–4
- Stopped: vulnerability call bookedstop 2
- Runningday 5
- Runningdays 1–5
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 asked | Does the customer have to answer? |
|---|---|---|
| a. Assess whether the claim is a reimbursable APP scam | The victim, their agent, or the receiving firm | Yes, where the request goes to the customer |
| b. Verify that a claims management company is submitting a legitimate claim | The company, and the customer it says it acts for | Yes |
| c. Gather additional information to assess vulnerability | The victim | Yes |
| d. Where there is evidence of fraud by the person claiming, gather information | The receiving firm, law enforcement or other relevant parties | No, on its wording |
| e. In a multi-step scam, gather information from the other firms involved | The other payment firms | No, on its wording |
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
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

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
Agent
Clock agentCounts 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
Agent
Draft requestDrafts the request for information, names which of the five permitted purposes it serves, and says what is asked and why it is needed.
A person decides
Reviewer approves the stopChecks 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.
Agent
Answer arrivesRestarts the clock when the response is received, logs both times, and raises an alert on day 4 of the five.
A person decides
Handler decidesDecides inside the remaining days, and in any case before the end of the 35th business day after the report.
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

What every stop-the-clock request should carry
- One named purpose from the five
If no purpose fits, the clock cannot stop, whatever the reason for the delay.
- The exact question, and why the claim needs the answer
Requests must be limited to essential information and proportionate to the claim.
- The time it was sent, and to whom
The pause starts at sending, not at drafting.
- A reasonable time to reply, and a second channel
Short deadlines and single attempts invite a complaint, and may miss a vulnerable customer.
- The approver
A second person confirms the purpose and proportionality before the request goes.
- 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.