By: Money Navigator Research Team
Last Reviewed: 25/01/2026
FACT CHECKED
Quick Summary
If an e-money provider pauses outgoing payments, the immediate issue is usually execution: payroll files may not release, supplier transfers can be queued or rejected, and HMRC payments that rely on bank transfer or Direct Debit collection may fail or arrive late.
What still works depends on what has been paused (for example Faster Payments vs Bacs vs card spend) and why (for example a compliance restriction, a banking partner issue, or an operational incident).
In many cases, incoming payments can continue even while outbound payments are paused, which can create a growing balance that cannot be sent out until the restriction is lifted.
This article is educational and not financial advice.
What “paused outgoing payments” usually means for an e-money account
E-money accounts sit inside a payments stack. A pause can be applied at different points:
Provider-level pause: the e-money provider blocks all outbound payment initiation in the app/portal.
Rail-level pause: only certain rails are blocked (for example Faster Payments, Bacs, or international transfers), while others may still operate.
Banking-partner pause: the provider’s sponsor bank or scheme access route limits outbound flow, even if the provider’s interface still shows the balance.
Most of the time, a “pause” is not the same thing as a permanent closure and not automatically the same thing as insolvency. It is closer to an operational restriction: the money is visible on the account, but outgoing settlement is constrained.
Two context checks help interpret what’s going on:
Which rails does the account use? Many e-money business accounts use Faster Payments, Bacs and (less commonly for SMEs) CHAPS; rail access varies by provider and partner structure. Our explainer on e-money payment rails (Faster Payments, Bacs, CHAPS) sets out common patterns.
Is it definitely e-money (not a bank)? The protections and complaint routes can differ depending on whether the firm is a bank or an e-money institution. If it is not clear, checking the FCA register for app-based business accounts is the usual starting point.
Why an e-money provider might pause outgoing payments
A pause can be triggered for reasons that are commercial, operational or regulatory. The provider may not be able to give detail in real time, especially where financial crime controls are involved.
Common underlying mechanisms include:
Compliance restriction: additional verification, enhanced due diligence, sanctions screening, or transaction monitoring flags can lead to outbound restrictions while information is reviewed.
Safeguarding and reconciliation controls: e-money firms must safeguard relevant customer funds, and those processes can involve reconciliations and controls around release. The FCA signposts the supervisory framework and guidance documents at Key publications – electronic money and payment services.
Banking partner or scheme access issue: if the sponsor bank or scheme connectivity is disrupted or constrained, the provider may be unable to send payments even if customer balances are unchanged.
Operational incident: system outages, cyber controls or payment processing failures can result in temporary pauses to prevent duplicate, incorrect or non-compliant releases.
None of these drivers automatically indicates that funds are “lost”. The practical impact is usually about timing and payment completion.
What happens to payroll when outbound payments are paused
Payroll tends to be the first high-stakes pain point because it is time-sensitive and multi-recipient. What happens depends on the method your payroll process uses.
1) Payroll sent by bank transfer (often Faster Payments)
If payroll is set up as many individual bank transfers, and the provider pauses outgoing Faster Payments, common outcomes are:
Transfers remain “pending/queued” inside the provider until outbound rails reopen, or
Transfers are rejected and show as failed, requiring re-initiation later.
Even a short pause can create a cascade: employees may be paid at different times depending on when each transfer is actually executed.
The Faster Payments network itself is designed for near real-time transfers; Pay.UK’s overview of the rail is at Faster Payment System. The key point is that a provider pause prevents initiation, regardless of the rail’s normal speed.
2) Payroll sent via Bacs Direct Credit
Where payroll is sent via a Bacs cycle (direct credit), a pause can show up differently:
A file may fail submission if the provider cannot access Bacs processing, or
It may be accepted but not released if release controls are applied before settlement.
Bacs is not a real-time rail; it runs on set processing cycles. Pay.UK’s overview is at Bacs Payment System. When a pause happens close to payroll cut-off, the practical impact is often that the next available processing window is missed.
3) Payroll sent by CHAPS (less common for payroll)
CHAPS is a same-day sterling system used for high-value or time-critical payments. It is not typically used for payroll runs, but in some businesses it is used for urgent settlement (for example where a single payment must arrive the same day). The Bank of England explains CHAPS at CHAPS.
If CHAPS is available but other rails are paused, a business may still be unable to use it if the provider’s pause is applied at the account level (blocking all outbound initiation).
Payroll often triggers HMRC payments (for example PAYE/NIC) on a timetable. If outbound payments are paused, HMRC settlement can be impacted in two ways:
Payment timing: GOV.UK notes that Faster Payments usually reach HMRC the same or next day, CHAPS the same working day (within bank processing times), and Bacs usually takes 3 working days. See Pay employers' PAYE: pay using another payment method.
Source account constraints: if the paused account is the sole payment account used for HMRC settlement, a pause can prevent sending the payment even if the tax calculation is correct.
What happens to supplier payments and trade settlement
Supplier settlement often uses a mix of transfers, card payments and Direct Debit collections. A pause does not necessarily affect all of them equally.
Supplier bank transfers
If suppliers are paid by bank transfer, outcomes often mirror payroll:
Queued/pending: the payment instruction sits inside the provider awaiting release.
Rejected/failed: the provider blocks initiation and returns an error.
Partially processed: a batch payment can show mixed statuses if some instructions were created before the pause and others after.
Where suppliers are paid using different rails (for example Faster Payments for day-to-day suppliers, and CHAPS for time-critical payments), a rail-level pause can create uneven disruption.
Card payments to suppliers (if the account has cards)
Some e-money products allow card spending from the same balance. A pause on outbound bank transfers does not automatically mean card spending is also paused. That said, if a provider applies a broad account restriction, cards may also stop authorising.
If supplier settlement relies on card payment (for example online ad platforms, SaaS subscriptions, courier accounts), the operational question is whether card authorisations are affected independently from bank transfers.
Direct Debits and Standing Orders
Direct Debits and Standing Orders can be affected in two ways during a pause:
Collections may be returned unpaid if the account cannot honour settlement at the time of collection.
New mandates or changes may not take effect if the provider’s controls restrict the relevant processing path.
If you are comparing behaviour across banks and non-bank payment accounts, our guide to Direct Debits and Standing Orders when a business account is frozen sets out typical “what happens next” outcomes (even though the trigger in that guide is a bank restriction rather than an e-money pause).
What happens to tax runs (VAT, Corporation Tax, Self Assessment and other HMRC payments)
A “tax run” is often a combination of (1) calculating what is due and (2) sending the payment. A paused outgoing payments function mainly affects step (2), but it can also disrupt automated collections.
VAT paid by Direct Debit
VAT Direct Debit is a common example of an automated collection. GOV.UK notes the Direct Debit must be set up at least 3 working days before submitting the VAT return, otherwise the payment will not be taken. See Pay your VAT bill: pay by Direct Debit.
If a pause prevents Direct Debit settlement or honouring outbound settlement obligations, the payment may fail even though the return is filed. The practical impact is then a separation between “filed” and “paid” timelines.
Other HMRC payments made by bank transfer
Many HMRC payment routes allow Faster Payments, CHAPS or Bacs bank transfers. If the e-money provider pauses outgoing transfers, the payment cannot be sent from that account while the pause remains in place (even if the rail itself is operational).
For PAYE specifically, GOV.UK’s timing guidance for Faster Payments, CHAPS and Bacs is set out at Pay employers' PAYE: pay using another payment method. This matters because a late-arriving Bacs payment is not the same thing as a Faster Payments payment blocked at source.
Summary table
| Scenario | Outcome | Practical impact |
|---|---|---|
| Outgoing bank transfers paused (all rails) | New transfers cannot be initiated; existing instructions may queue or fail | Payroll batches and supplier payments may remain unpaid until the pause lifts |
| Faster Payments paused only | Faster Payments fail/queue; other rails may still function | Day-to-day supplier transfers and multi-recipient payroll transfers are most affected |
| Bacs processing paused only | Bacs files cannot be submitted or are not released | Timetabled payroll cycles and Bacs-based supplier payments can miss cut-offs |
| CHAPS available but account-level pause in place | CHAPS cannot be initiated | Time-critical payments cannot be used as a “fallback” if the pause is account-wide |
| Direct Debit settlement constrained | Collections can be returned unpaid | Subscriptions, utilities and HMRC Direct Debit payments may not complete |
Scenario table
| Scenario-level signal | Process-level constraint | Outcome-level pattern |
|---|---|---|
| Outgoing transfers stopped but inbound still arriving | Payment initiation blocked at provider layer | Increasing balance with no outbound movement; “queued” statuses accumulate |
| Some payment types still work (for example cards) | Restriction applied to bank transfer rails only | Supplier card spend may continue while bank transfers fail |
| Outbound available for one rail but not another | Rail-level access or scheme connectivity constrained | Faster Payments failures alongside normal Bacs/CHAPS (or vice versa) |
| Batch uploads fail while single transfers also fail | Pre-processing or compliance gating before execution | Uniform rejection messages across payment methods |
| Repeated “pending” without settlement | Release controls / reconciliation holds | Payments appear created but do not complete, even after hours or days |
Safeguarding and “where the money is” when outbound payments are paused
It helps to separate three ideas:
Your balance in the app (what the provider shows)
The safeguarded funds arrangements (how the provider holds relevant funds)
The ability to execute payments (rail access and release controls)
E-money institutions are required to safeguard relevant funds received in exchange for issued e-money.
In UK law this is set out in the safeguarding requirements within the Electronic Money Regulations 2011 (for example regulation 20 and the safeguarding options in regulations 21 and 22) in the official text at The Electronic Money Regulations 2011 (UKSI 2011/99) – official PDF.
Payment institutions have similar safeguarding obligations for relevant funds under the Payment Services Regulations 2017 (including regulation 23) at The Payment Services Regulations 2017 (UKSI 2017/752) – official PDF.
Safeguarding is not the same thing as bank deposit cover. If you want the “protections map” in one place, see our explainer on safeguarding vs deposit cover for EMI balances and the operational detail in how safeguarding accounts work in practice. For a high-level walkthrough, see safeguarding explained for e-money institutions.
Compare Business Bank Accounts
Paused outgoing payments are one reason some businesses compare banks and e-money providers: the products can look similar day-to-day, but the underlying rails, partner structures and protections can differ.
Our comparison hub at Compare business bank accounts sets out the main categories and how to evaluate features and constraints in a like-for-like way. This is not a recommendation of any provider; it is a framework for comparing account types and product features.
Frequently Asked Questions
Sometimes a payroll run is created in advance but only released later (for example after approval steps, checks, or scheduled execution). In that case, a pause can catch payments that exist in the system but have not yet been executed, resulting in “pending” or “queued” statuses until release is permitted.
If the payroll process uses a file submission route (for example a Bacs file) the submission itself may be blocked, or the file may be accepted but not released. The key operational uncertainty is where the restriction is applied: at file creation, at submission, or at final release.
Both patterns are seen. Some providers hard-block initiation and return an immediate failure message; others allow creation but stop execution, leaving payments in a pending state.
Pending does not necessarily mean “processing will complete next”; it can simply mean the instruction exists but cannot pass the release gate. Where suppliers require confirmation of payment, the visible status inside the provider’s portal can differ from what the beneficiary sees (often nothing, until execution occurs).
Often, yes. Many pauses target outbound payment initiation or settlement, while inbound rails continue to function. That can result in customer payments, platform settlements or refunds continuing to arrive.
However, not every pause is limited to outbound. If the underlying issue is a wider operational incident or a broad account restriction, inbound routing can also be affected. The practical indicator is whether your account details still accept credits and whether you see completed inbound entries.
Not always, but it is possible. Card authorisations can be controlled separately from outbound bank transfers, depending on the provider’s architecture and the reason for the pause.
Even where cards continue to authorise, settlement and dispute handling are separate processes. A broad restriction can still lead to card declines, spending limits, or delayed settlement handling. The outcome is provider-specific rather than rail-specific.
If a Direct Debit is presented and the account cannot honour settlement because of the pause, the collection can be returned unpaid. This can be visible as a failed or returned Direct Debit in the account history.
There is also a “set-up and change” dimension: where the pause restricts certain processing paths, new mandates or changes might not flow through in the usual way. The result can be that an expected collection does not happen, or that a collection happens but is subsequently returned.
There is no single standard duration. Some pauses are short (for example operational incidents that resolve within hours), while compliance-driven restrictions can take longer if information requests or checks are involved.
Time also depends on the level of restriction. A rail-level disruption can lift as soon as connectivity is restored; a provider-level compliance restriction may require case-by-case clearance. Without provider-specific information, timelines can be uncertain.
A pause does not automatically indicate insolvency or administration. Providers can pause outbound payments for operational or compliance reasons while continuing as a going concern.
Administration is a different scenario with its own legal process, communications and access path. For that separate situation, see what happens when an e-money provider enters administration, which focuses on access steps and delays under an insolvency process.
A pause is about execution, not automatically about ownership of funds. For e-money, the relevant protection concept is safeguarding: relevant funds must be safeguarded under the Electronic Money Regulations 2011, and similar safeguarding requirements exist for payment institutions under the Payment Services Regulations 2017.
Safeguarding is not the same as FSCS deposit cover. The practical distinction is that safeguarding aims to protect relevant funds from claims on the firm’s own assets, but it does not function like a bank deposit guarantee.
Direct Debit collections are initiated by the organisation collecting the money, not by the payer. However, the payer’s account still has to honour settlement when the Direct Debit is presented.
GOV.UK’s VAT Direct Debit guidance focuses on set-up timing and collection rules, but does not guarantee collection if the account is restricted. The practical implication is that a return can be filed while payment collection fails, leaving a mismatch between filing and settlement timing.
Providers typically have a complaints process, and regulatory status matters. Whether a complaint can be escalated externally can depend on the firm type (bank vs e-money vs payment institution), the product, and the complainant’s eligibility.
If the situation develops into closure or longer-term restriction, the practical outcomes seen in external dispute routes can differ from expectations. Our guide on business account closure complaints and realistic outcomes explains what tends to be looked at in complaint outcomes (noting that it is written for bank account closures rather than e-money pauses).
A paused outgoing-payments event is best understood as a control point in a layered system. The balance a business sees in an e-money interface is not the same thing as guaranteed payment execution at any moment in time.
Execution depends on rails (Faster Payments, Bacs, CHAPS), sponsor arrangements, and release controls that can be tightened rapidly when risk signals, reconciliation issues or operational incidents appear.
The practical risk is therefore not just “can the balance be seen?” but “can settlement be completed on schedule?” Payroll, supplier settlement and HMRC runs are all scheduled, multi-step processes.
A pause that interrupts only one step (execution) can still create outsized downstream disruption because it breaks the normal timing assumptions that payroll bureaux, suppliers and tax schedules rely on.
Related Content
