By: Money Navigator Research Team
Last Reviewed: 28/01/2026
FACT CHECKED
Quick Summary
If Tide closes an account while an outgoing payment is “processing”, the outcome usually depends on where the payment is in the chain and which rail it uses (Faster Payments, Bacs, or CHAPS).
Some items complete normally because they have already left the account; others fail or return if closure happens before submission or before the rail can debit/settle.
Tide’s own help content also reflects an important practical point: there can be a short cancellation window for certain in-app payments, while other payment types are excluded and may require a recall workflow instead.
This article is educational and not financial advice.
What “Mid-Processing” Means for Outgoing Payments
“Mid-processing” is a broad phrase that can refer to several distinct states:
Created but not sent (drafted/queued, awaiting authorisation, or awaiting an internal check)
Sent to a payment rail but not yet confirmed (for example, the app shows “pending” while confirmation is still propagating)
In a multi-day rail cycle (common with Bacs Direct Credit files)
Submitted but later recalled/returned (possible in error scenarios, depending on rail and timing)
A closure event also sits on top of other account states. A Tide account might be formally closed, or it might be effectively unusable because it is restricted or locked.
Those distinctions matter because they affect whether the payment instruction can still be transmitted. For the Tide-specific definitions, see Tide business account: restricted vs closed and Tide account locked or frozen: what usually still works.
Why Payment Type Matters More Than the Word “Pending”
Different rails behave differently once a payment is “in flight”:
Faster Payments are designed for near-real-time crediting; Pay.UK also highlights that, due to their real-time nature, once sent they cannot simply be cancelled in the way queued items can.
Bacs Direct Credit uses a staged processing cycle (commonly described as input > processing > entry), so “mid-processing” can literally mean “in the file cycle, but not yet at the debit/credit moment.”
CHAPS is a same-day sterling system used for time-critical payments, and its operating window and settlement characteristics are different again.
This is why a single app status (“pending”) can be misleading: it may reflect an internal status update, not a definitive statement about whether the rail has settled.
The “what happens next” question is therefore usually answered by the combination of (a) rail, (b) stage, and (c) whether closure happened before or after the payment instruction was transmitted.
For a wider explainer of UK rail differences in business accounts (including EMI-style accounts), see Payment rails for EMI business accounts and App business accounts: bank or e-money.
Tide’s In-App Cancellation vs Recall: What Tide Publishes
Tide’s help content describes a practical distinction that affects “mid-processing” outcomes:
Certain in-app payments may have a short cancellation window (Tide describes “up to 30 seconds” in its help centre). See Recalling or cancelling a payment.
Tide also notes that some payment types are excluded from that cancellation route (for example: scheduled, international, bulk, and open banking payments). Where that applies, the question often becomes whether a recall request can be raised, and whether the recipient bank will return funds.
That does not mean recalls are guaranteed or fast in every case. It means Tide’s own published workflow distinguishes between (a) cancelling something that has not meaningfully left the account yet and (b) attempting recovery after the fact.
What Typically Happens When a Tide Account Closes Mid-Processing
1) If the payment is queued (not yet transmitted)
If closure or restriction happens before an instruction is transmitted, the most common practical result is that the payment does not leave the account. In that scenario, the business impact is often administrative (supplier follow-ups, payroll reruns, and reconciliation) rather than a “lost funds” problem.
This is also where “under review” status matters: if an account is in a review workflow, payments can be paused or blocked before being transmitted. See Tide account under review: stages, timelines, typical outcomes.
2) If the payment is within Tide’s cancellation window
Where the payment is eligible and still within the relevant cancellation window described by Tide, the payment may be cancellable in-app. The critical point is timing: once the instruction has progressed beyond that stage, the outcome tends to move from “cancel” to “recall/recovery attempt”. See Recalling or cancelling a payment.
3) If the payment has already been sent via Faster Payments
Pay.UK describes Faster Payments as near-real-time in typical cases, but also notes that timings can sometimes extend (for example, up to two hours in some scenarios) and that once sent they cannot be cancelled in the way queued items can. See How Faster Payments work.
In practice, if the payment has been transmitted and accepted, closure after submission does not “pull it back” automatically. Where the payment fails (for example, beneficiary details invalid), it may return through the normal return pathway rather than being “stuck” indefinitely.
4) If the payment is a Bacs file mid-cycle
Bacs Direct Credit is commonly described in staged steps (input day, processing day, entry day). Bacs’ own scheme guidance describes that cycle and the “entry” day debit/credit moment. See Bacs Direct Credit.
So “mid-processing” here can mean “after the file is submitted, before entry day”. If the account becomes unusable during that window, outcomes can differ depending on whether the file can still be amended/withdrawn by the submitting party and whether the debit can be applied at the entry stage.
5) If the payment is CHAPS
CHAPS is a same-day sterling system with defined operating hours and is used for time-critical payments (including business-to-supplier and tax payments). See CHAPS.
If closure happens before a CHAPS payment is submitted or processed, it may not be sent. If it has already settled, closure does not typically reverse settlement simply because the account later closes.
Summary Table
| Scenario | Outcome | Practical impact |
|---|---|---|
| Payment created but not transmitted | Payment usually does not leave | Supplier/payroll items may need re-issuing elsewhere; reconciliation workload |
| Eligible in-app payment within cancellation window | May be cancellable | Faster resolution than a recall path; fewer downstream queries |
| Faster Payments instruction already sent | Usually completes or fails/returns by rail rules | “Pending” can lag behind reality; counterparties may see funds before the app updates |
| Bacs file submitted, closure occurs before entry day | Outcome depends on cycle stage and submission controls | Payroll/supplier runs can be disrupted because timing is multi-day |
| CHAPS planned for same-day critical payment | May fail to send if closure blocks submission | Time-critical obligations can be impacted within the same day |
| Account closed during review workflow | Outgoing payments can be paused before transmission | Uncertainty can cascade into supplier and tax scheduling |
The “Why Can’t They Tell Me Exactly?” Problem
When a Tide account is restricted or closed in connection with compliance processes, there can be legal and operational limits on what a provider can communicate, especially where disclosure could prejudice an investigation.
For a Tide-specific explainer of communication constraints, see Why Tide can’t explain a restriction.
At a broader regulatory level, UK law includes “tipping off” offences and UK AML regulations set out customer due diligence and ongoing monitoring expectations that can shape account controls.
See Proceeds of Crime Act 2002, section 333A (tipping off: regulated sector) and Money Laundering Regulations 2017, regulation 28 (customer due diligence measures).
Practical Operational Impact: Payroll, Suppliers, Tax
From an operational perspective, “mid-processing closure” tends to hurt most when payments are batch-based or time-critical. Payroll runs and supplier cycles are particularly exposed because they often rely on predictable cut-offs and multi-day rails. See Payroll when a business account is closing or restricted.
A related issue is that some app-based and e-money-style business accounts can pause outgoing payments during restrictions. While Tide products can vary in underlying structure, the general “paused outgoing” operational pattern is explained in E-money provider pauses outgoing payments.
Scenario Table
| Scenario-level | Process-level | Outcome-level |
|---|---|---|
| Closure happens before submission | Instruction never reaches the rail | Payment does not leave; status may show cancelled/failed |
| Closure happens during Tide’s internal window | Cancellation path may still exist | Payment stops early; no rail settlement |
| Closure happens after FPS transmission | Rail processes the instruction | Completes, or fails/returns according to rail rules |
| Closure happens mid-Bacs cycle | Multi-day processing continues to entry point | Entry may succeed or fail depending on stage and debit/credit ability |
| Closure happens around CHAPS timing | Same-day submission window matters | Payment may not be sent if blocked pre-submission; settled payments stay settled |
| Closure is linked to compliance review | Communication constraints apply | Status information can be limited; delays can be longer where checks apply |
Tide Business Bank Account
Tide offers business account products with different underlying structures, which can affect payment rails and how “pending” statuses behave in edge cases. For a neutral overview of Tide’s business account positioning and features, see Tide business bank accounts.
For clarity on the underlying bank-account framework used for Tide bank accounts, ClearBank’s account terms (as published for Tide) set out relevant account-relationship and termination concepts. See ClearBank terms for Tide business bank accounts (PDF).
Frequently Asked Questions
Not always. “Pending” can reflect an internal status update rather than a definitive statement about settlement. Some rails can complete quickly while the app status lags behind, and some rails are inherently multi-stage.
Where the payment uses Faster Payments, Pay.UK describes near-real-time behaviour in typical cases and also notes that once sent, Faster Payments cannot simply be cancelled like a queued item. That distinction is one reason “pending” can be an imperfect indicator of whether funds have already moved. See How Faster Payments work.
- “Queued” generally means the instruction exists but has not been transmitted to the rail.
- “Processing” can mean internal checks are occurring, the instruction is being packaged for transmission, or the rail confirmation is still in progress.
- “Sent” typically means the instruction has been transmitted to a payment rail. At that point, cancellation becomes much harder and often shifts into recall/recovery processes rather than a true cancellation. Tide’s own help content reflects this split by describing a short cancellation window for certain payments and a separate recall request workflow after that. See Recalling or cancelling a payment.
In general terms, real-time rails are not designed for “stop after send” cancellation. Pay.UK explicitly notes that due to the real-time nature, once sent Faster Payments cannot be cancelled in the standard way. See How Faster Payments work.
That does not mean funds can never be recovered. It means recovery is usually handled via mistake-recovery or recall processes, and outcomes depend on the recipient bank and whether the recipient can be contacted or is willing/able to return the funds.
Bacs Direct Credit is commonly described as a staged cycle with an “entry” day when accounts are debited/credited. Bacs’ own scheme guidance sets out this structure. See Bacs Direct Credit.
Because the rail itself is multi-day, “mid-processing” can mean “submitted but not yet at entry”. If closure or restrictions intervene during that window, the outcome can vary by stage: some items may proceed as planned, while others may fail at the point the debit is due.
Yes. CHAPS is a same-day sterling system used for time-critical payments and operates within defined opening hours. The Bank of England explains CHAPS and its operating characteristics. See CHAPS.
The edge case here is timing: if closure blocks submission before CHAPS processing, the payment may not be sent that day. If the payment has already settled, closure does not typically unwind settlement simply because the account later closes.
Yes, because a restriction can stop outgoing payments before formal closure, whereas closure typically ends the payment capability outright. Tide-specific status and impact differences are covered in Tide business account: restricted vs closed and Tide account locked or frozen: what usually still works.
A common edge case is that an account can be “open” in a contractual sense while still being operationally unusable because payment rails are paused. That’s why “mid-processing” issues often show up during review periods, not only after final closure.
Tide’s help content notes that certain payment types can be excluded from the short in-app cancellation route (for example: scheduled, international, bulk, and open banking). See Recalling or cancelling a payment.
Operationally, exclusions typically exist because different payment types run on different submission paths and timing windows. A scheduled payment might already be committed into a batch; an open banking initiation might be controlled by a third-party flow rather than a native in-app instruction.
Sometimes providers have legal and operational reasons to limit what they say, particularly in contexts tied to compliance checks. UK law includes “tipping off” offences and UK AML rules govern due diligence and monitoring.
See Proceeds of Crime Act 2002, section 333A (tipping off: regulated sector) and Money Laundering Regulations 2017, regulation 28 (customer due diligence measures).
In Tide-specific terms, we cover the communication-limits angle in Why Tide can’t explain a restriction. The practical takeaway is that limited explanation can coexist with real operational effects, including payment delays or blocks.
If outgoing payments do not leave, the balance may remain in the account until it is returned through the provider’s closure process. Timing varies by provider process and by whether residual issues (like in-flight items) need to settle first.
For a provider-agnostic view of how balance returns can play out after closure, see How long banks return the remaining balance after account closure. For Tide’s own closure workflow and transaction-history delivery, see Managing your Tide account closure.
This post is Tide-specific, but the underlying mechanism – rail + stage + account state – is not unique to Tide. The broader mapping across banks and account providers is explained in Outgoing payments if an account is closed mid-processing.
Reading the two together usually reduces confusion: the general guide explains the mechanics, while the Tide-specific guide anchors those mechanics to Tide’s published cancellation/recall pathways and the app-led payment experience.
“Mid-processing” is not a single state; it is a range of states that look similar in an app interface but behave differently once you map them onto payment rails.
The most reliable way to interpret outcomes is to ask, “Has this instruction reached the rail yet, and if so, which rail?” because settlement and reversibility are largely determined there, not by the label on-screen.
The second constraint is that closure decisions can overlap with compliance workflows where communication is limited. That combination – rail irreversibility on one side and limited explanation on the other – is why “what happened to my payment?” can be straightforward in outcome yet difficult to narrate in detail.
Related Content
