By: Money Navigator Research Team
Last Reviewed: 26/01/2026
FACT CHECKED
Quick Summary
In card payments, the “money” from a sale can appear as three different things at different points: a merchant account (settlement ledger), an EMI e-money balance, or a bank deposit balance. Each sits under different rules, which changes who can hold, reverse, net-off, or release value and when.
If something goes wrong (chargebacks, refunds, reserves, bank restrictions, provider failure), outcomes differ depending on which balance type is involved – and which contracts or regulatory regimes apply at that point in the chain. This article is educational and not financial advice.
This article is educational and not financial advice.
What people mean by “who holds the money” (and why it’s usually the wrong question)
In a payments chain, “holding” can mean any of the following:
Ledger control: who can change the balance shown (credits, debits, reserves, fees).
Settlement control: who is responsible for moving funds between banks in scheme settlement cycles.
Operational control: who can pause outgoing payments or delay payouts.
Legal character: whether the value is a deposit, e-money, or a merchant settlement entitlement under contract.
Card payments are a networked system (issuer, scheme, acquirer, processors). A good high-level explainer of the ecosystem is the Payment Systems Regulator’s overview of card payments, which is useful context for why a single “balance” can behave differently at different stages.
The three balances that get confused
1) Merchant account balance (typically an acquirer/processor settlement ledger)
A “merchant account” is often shorthand for the arrangement that receives card settlements for a merchant. In many models it is best understood as a settlement ledger within the acquiring/processing relationship, not simply “cash in the bank”.
That ledger can include:
gross settlement credits,
fees,
refunds and chargeback debits,
reserves/holds,
other netting adjustments.
Because the acquiring side sits inside scheme rules and merchant services terms, a merchant-facing credit can remain economically reversible for a period (for example via dispute processes).
For merchant-facing dispute pathways and how complaints are framed, the Financial Ombudsman Service’s page on disputed transactions is a useful reference point.
Internal context: our explainer on who can withhold funds in disputes across EMI and settlement flows goes deeper on the “withholding” mechanics when multiple ledgers are involved.
2) EMI balance (e-money)
An EMI “balance” is typically e-money – a claim on the EMI to redeem value – rather than a deposit. The baseline legal framework is the Electronic Money Regulations 2011.
EMIs are expected to implement safeguarding arrangements for relevant funds, and the FCA summarises expectations in its guidance on safeguarding requirements for authorised payment and e-money firms, alongside the wider FCA Approach Document for payment services and e-money.
Internal context: our guide to how EMI safeguarding works and our practical walkthrough of where safeguarded funds sit and who can release them are the companion pieces if you want the safeguarding mechanics.
3) Bank balance (deposit)
A business bank account balance is typically a deposit – the bank owes the depositor that amount. Deposit failure handling and statutory schemes are different from EMI safeguarding. For business eligibility and scope, the FSCS sets out detail on cover for small businesses and limited companies.
Internal context: our comparison of safeguarding vs deposit cover focuses on how the two regimes differ in concept and failure pathway.
Where the “money” sits during a card payment lifecycle
Authorisation is the issuer confirming the transaction can proceed. It’s a decision and a message flow; it is not the same as settlement into the merchant’s bank deposit. This matters because “approved” does not automatically mean “available and final” in the merchant’s settlement ledger.
Stage 2: Clearing and settlement (scheme processes moving value between banks)
Settlement is where interbank value transfer happens through scheme settlement cycles. UK Finance’s taxonomy document on the UK card acquiring ecosystem entities is helpful for understanding which entities sit where (issuer, acquirer, processors, gateways) and why control points are distributed.
Stage 3: Funding/payout (making value usable for the merchant)
This is where merchants experience “payouts” and “available balances”. Depending on the model, funds may:
stay on a merchant settlement ledger until payout,
be paid into an EMI account (creating an e-money balance),
be paid into a bank account (creating a deposit balance).
Visa’s overview of how payments move through acceptance and settlement is a simple example of how consumer-facing card use maps to a multi-party settlement process on the merchant side.
Internal context: if the destination account becomes restricted, our guide on card settlement payouts when a business account is frozen explains the typical “ledger moves but payout doesn’t land” pattern, and our explainer on why processors hold payouts during account restrictions covers common hold/reserve mechanics.
Summary table
| Scenario | Outcome | Practical impact |
|---|---|---|
| Card payment authorised | Approval message; not final settlement | A later reversal/decline can still occur before funding |
| Clearing and scheme settlement | Value moves between issuer/acquirer under scheme processes | Merchant’s “available” balance may lag or be netted |
| Merchant settlement ledger credited | Credits recorded; fees/reserves/adjustments may apply | Ledger can change without new sales (fees, disputes, reserves) |
| EMI balance credited | E-money issued; safeguarding regime applies | Operational controls and redemption mechanics differ from deposits |
| Bank account credited | Deposit balance increases | Access depends on bank operations; deposit regime differs from safeguarding |
| Refund initiated | Debit applied per contract/process flow | Cashflow impact depends on where the debit is taken (ledger/EMI/bank) |
| Chargeback raised | Potential debit under scheme rules | Timing can be delayed and evidence-dependent |
| Reserve/hold applied | Portion of value ring-fenced on the ledger | Payout timing and “available” funds reduce |
| Bank account restricted | Incoming/outgoing controls may apply | Payouts may fail to land even if the merchant ledger updates |
Why the three balances behave differently under stress events
Disputes, refunds and reversals live “upstream” of your bank balance
In many models, disputes and refunds are resolved through the merchant services agreement and scheme processes before funds become a straightforward bank deposit. That’s why a merchant settlement ledger can show netting debits even if the original sale looked “complete”.
EMI safeguarding is segregation-focused, not deposit-focused
Safeguarding is aimed at keeping relevant customer funds separate from the firm’s own funds and other creditors, under the relevant payments and e-money framework (the Payment Services Regulations 2017 sit alongside the e-money regime and the FCA’s approach guidance). The practical experience can still involve operational pauses, reconciliation steps, and dependency on third-party banks holding safeguarding accounts.
Bank restrictions can cause “payout mismatch” (ledger vs landing)
If a bank account becomes restricted, a processor may still be able to move a merchant ledger internally while being unable to complete a payout to the restricted destination account. Internal context: our explainer on how bank restrictions can trigger higher reserves and payout delays describes common knock-on effects.
Scenario table
| Scenario-level | Process-level | Outcome-level |
|---|---|---|
| Merchant account (settlement ledger) | Credits/debits applied under merchant services terms; scheme-driven adjustments, fees, reserves and dispute debits can be netted | “Available” can change after the sale; payouts can be delayed or reduced |
| EMI balance (e-money) | E-money issued; safeguarding arrangements and operational controls govern movement and redemption | Access and failure pathways differ from deposits; outgoing payments can be paused by the provider |
| Bank balance (deposit) | Deposit liability of the bank; payments executed via payment rails subject to bank controls | Funds may be usable when credited, but restrictions can block movement; deposit regime differs from safeguarding |
| Destination change events | Processor payout rules may prevent “switching” mid-flow without checks | Merchant may see temporary holds, re-verification, or rerouting constraints |
| Stress event (disputes/restrictions) | Different parties control different layers (scheme, acquirer, processor, EMI, bank) | Outcomes vary by layer: reversals, reserves, payout failures, operational pauses |
Compare Business Bank Accounts
Merchants often end up comparing account types not because one is “better”, but because settlement landing behaviour (and what happens under restrictions) is different when the destination is a bank deposit vs an EMI balance. Our hub on business bank accounts provides a neutral starting point for how UK business accounts are categorised and compared.
Internal context: if the question is “is this app account a bank or an EMI?”, our step-by-step guide on checking FCA register status for app business accounts explains what to look for without relying on branding.
Frequently Asked Questions
A merchant account is commonly a settlement arrangement and ledger within the acquiring/processing relationship. It can show credits and debits that reflect scheme settlement timing, merchant fees, reserves, refunds and disputes.
A business bank account balance is typically a deposit. That deposit sits under a different legal character and different operational controls, which is why “payout sent” in a merchant interface is not always the same as “deposit received” at the bank.
An EMI balance is usually e-money, not a deposit. The value can be safeguarded via accounts held with banks, but the customer-facing balance is still an e-money claim on the EMI rather than a bank deposit in the customer’s name.
This distinction matters most when something unusual happens (provider failure, operational pauses, reconciliation delays), because the access pathway and priority mechanics are not identical to a deposit relationship.
Settlement is a defined stage in a card payment lifecycle. It does not remove the existence of later dispute pathways and corrections that can arise via scheme rules and contractual processes.
Practically, that means a merchant ledger can experience later debits (for example, chargebacks or reversal adjustments) even when the original sale appeared completed in front-end reporting.
It depends on the provider model and the contract. Many models apply debits to the merchant settlement ledger (and net them against future payouts) rather than initiating a separate debit from the merchant’s bank account.
In mixed setups, debits can also interact with the balance type used for payouts. The same event (refund or dispute debit) can therefore appear as a ledger movement, an EMI balance movement, or a bank-account movement, depending on where the provider has operational control.
Card systems carry post-transaction risk (refunds, disputes, fraud claims). Holds and reserves are common tools to manage that risk under the merchant services agreement.
The operational effect is usually a timing difference: value exists on a ledger but is not released for payout until conditions or time windows are satisfied, or until evidence/reviews are completed.
Safeguarding is designed to segregate relevant funds in a way that reduces exposure to the firm’s own creditors, but it does not turn e-money into a deposit. Access can still be affected by operational pauses, reconciliation steps, and dependency on third parties holding safeguarding accounts.
This is why safeguarding-focused questions often become practical questions about timelines and process steps rather than simply “is it covered”.
A restriction can prevent payouts from landing even while the merchant ledger continues to record settlements and adjustments. Merchants can experience a mismatch where internal settlement accounting progresses but external payout completion does not.
The practical consequences can include delayed cash availability, higher reserves, or temporary payout rerouting constraints depending on the processor’s controls and the receiving bank’s status.
FSCS cover depends on eligibility and the nature of the deposit relationship. For small businesses and limited companies, eligibility and scope are set out by FSCS in its guidance on business claimants.
This is different from EMI safeguarding. The key point is that the label “balance” does not by itself determine cover; the underlying legal character of the funds does.
The cleanest method is checking the provider’s regulatory status and permissions, because branding and app design can obscure the legal structure.
Where the product uses e-money, the customer-facing balance is typically e-money issued by an EMI; where it is a bank account, it is typically a deposit relationship with a bank. Those distinctions often show up in terms and in how funds are held and moved.
Different parties can control different layers: the issuer’s dispute process, scheme rules, the acquirer’s obligations, and the processor’s contractual controls over the merchant ledger. “Withholding” can therefore occur at more than one point in the chain.
The practical result is that two merchants experiencing “a hold” may be in materially different situations depending on whether the hold is scheme-driven, acquirer/processor risk-driven, EMI operational, or bank operational.
Most confusion comes from treating a payment as a single “pile of cash”. In reality, card payments are an orchestrated set of ledgers and obligations that change character as the transaction moves from authorisation to settlement to payout.
A merchant settlement ledger is designed to absorb post-transaction events (disputes, refunds, reserves). An EMI balance is designed around e-money issuance and safeguarding. A bank balance is designed around deposits and payment rails.
Once the balance type is identified, the questions become more precise: which entity controls the ledger at that stage, which rules apply (scheme, contract, safeguarding, bank operations), and what triggers can change availability.
That framing explains why merchants can see “available” in one place while being unable to move funds elsewhere.
Sources & References
Related Content
