Bank transfer deposits and Faster Payments

Short answerOn a transfer nothing reaches towards your account. You create the payment inside your own bank, your bank authenticates you and releases the money in one direction only. That makes the rail impossible to reverse, which is its strength, and entirely dependent on a reference and a name matching at the other end, which is its weakness.

Our top pick: 22BET — 100% up to £100 on your first deposit
Regulator: Gambling Commission of Great Britain
Credit cards: Banned for gambling since April 2019
Minimum age: 18
Tax on winnings: None for the player
Self-exclusion: GAMSTOP, free and nationwide

A push is a different animal from a pull

Every other common rail works by someone reaching towards your money with your permission. This one does not. You open your own banking app, you build a payment, your bank checks that it is really you, and funds leave in a single direction. Nothing downstream holds any permission to come back for more, because no permission was ever granted.

That reversal of direction changes almost every property of the payment. There is no authorisation sitting as a hold, because the money is simply gone. There is no refusal from an acquirer, because no acquirer is involved. There is no merchant classification being read, because your bank is not paying a merchant; it is paying an account number you supplied.

It also changes who is responsible for getting the details right. On a pull, the cash desk assembles the request and can only get it wrong in ways it will notice. On a push, you assemble it, and a transposed digit or a missing reference produces a payment that completed perfectly and arrived nowhere useful. The shape of the other families is on the hub for payment routes.

A push payment in three stages: you start it, your bank authorises and sends it, the cash desk credits the balance — One direction only. Nothing in the chain after your bank holds any permission to reach back.

What the rail underneath actually is

In Britain most of these payments travel on the service built for near-immediate account-to-account transfers, which is why a transfer between two ordinary current accounts usually lands while you are still looking at the screen. It is a national system rather than a product of any one bank, and it is the same plumbing behind paying a friend back for dinner.

There are slower alternatives still in use, batch systems that settle over working days and are the reason some payments announce themselves as taking longer. Which one a payment uses is decided by your bank and by the amount, and your bank states it on the confirmation screen. For a cash desk the near-immediate service is the normal case.

So if the rail itself is fast, and it is, why is this the slowest way to get money onto a gambling balance? Because the transfer arriving is not the same event as the balance being credited. The money reaching an account and being matched to a customer are two separate jobs, and the second one is where the time goes.

A phone showing an abstract reel grid, a coin and a pair of headphones on a desk

The details screen and what each field is doing

Choosing this rail in a cashier produces a screen with a sort code, an account number, a beneficiary name and a reference. Three of those four are the desk's and will be the same for everybody. The fourth, the reference, is yours alone, and it is the only part of the payment that says which customer sent it.

Some desks improve on this by issuing you an account number of your own, unique to your customer record, so that anything arriving at it is yours by definition. Where that happens the reference stops being load-bearing and the rail gets noticeably more reliable. Where it does not, the reference is the entire matching mechanism and treating it casually is the single biggest mistake available on this page.

Copy, do not retype. Every field, including the reference, every time, even when it looks like the one you used before. References are frequently regenerated per deposit, and an old one points at a payment that has already been reconciled.

Field	Whose it is	What breaks if it is wrong
Sort code and account number	The cash desk's	The money goes to a stranger or bounces back
Beneficiary name	The cash desk's	Your bank warns you; the payment may still send
Reference	Yours alone	The money arrives and cannot be matched to you
The sending account	Yours, and it must be yours	The payment is held and may be returned

The four fields and what each one is responsible for

The reference is the whole of the matching

Picture what the desk receives: a credit of a certain amount, from a certain account, with a string attached. Automated reconciliation reads the string, finds the customer it belongs to, and credits the balance within moments. Everything good about this rail depends on that lookup succeeding.

When the string is missing, wrong or truncated, the credit falls out of the automated process and into a manual one. Somebody has to work out whose money it is, usually from the sending account name, and that work happens in a queue during working hours. This is the mechanism behind a transfer that shows as sent in your bank and absent at the desk, which is the dominant complaint on the rail.

Note that your bank will happily send a payment with a nonsense reference. It is not checked, it is not validated, it is a free-text field passed along untouched. The only party that cares about it is the recipient, and by the time the recipient cares the payment has already completed. The general family of symptoms this produces is covered under a request that sits still, since the same manual queues are involved in both directions.

Why the name on the sending account has to match

A licensed operator has to be able to show that the money on a customer's balance came from that customer. On a card rail this is partly automatic, since a card is tied to a named account. On a push rail the desk's only evidence is the name that arrived with the credit, which makes that name load-bearing in a way nobody expects.

So a payment from a joint account with another name on it, from a partner, from a parent, or from a business account trading under a company name, all create the same problem: money that arrived from somebody who is not the account holder. The usual outcome is not a credit and a quiet note; it is a held deposit, a question, and sometimes a return of the funds to where they came from.

Returning money is the best case rather than the bad one. The genuinely bad case is a credit that happens, is played, and then surfaces during a check at withdrawal time, with the balance frozen behind a mismatch that cannot be fixed retrospectively. What is examined and when is on the page about identity checks.

A laptop showing an online cashier, a debit card and pound coins on a desk by a window

The name check your bank runs before sending

Before a transfer leaves, British banks compare the beneficiary name you typed against the name actually registered on the destination account, and warn you when they do not match. It is a sensible protection built for a different problem, namely people being talked into sending money to criminals, and it behaves oddly here.

A cash desk's receiving account is frequently registered to a payment company rather than to the brand on the website, so the name you were given and the name on the account are not the same words. Your bank raises a warning, you are asked whether you are sure, and the correct answer depends on something you cannot verify from your sofa.

The reasonable discipline is to take the beneficiary name from the cashier screen and from nowhere else, to type nothing from memory, and to treat details that arrive by email or chat as untrustworthy however convincing they look. Payment details reached through a logged-in cashier are the only ones with any provenance at all.

Nothing can be pulled back, and what that means

Once your bank has sent it, no party at the other end can take more and no party at the other end can be made to give it back. Your bank can attempt a recall on your behalf, but a recall is a request rather than a command, and the receiving bank will only act with the recipient's cooperation. Treat an irreversible payment as irreversible.

The upside of that is real and often forgotten. There is no stored instrument, nothing a desk can charge again, no subscription accidentally created and no number sitting in somebody's database waiting to leak. A push leaves no permission behind it, and for one-off funding that is the cleanest arrangement of any rail here.

The downside is that every protection you might reach for afterwards belongs to a different rail. Card disputes exist because cards are pulls and the scheme can unwind them. There is no equivalent machinery here, which is why checking the licence before sending matters more on this rail than on any other, and why a wallet-based route keeps a card dispute available in the background, as the page on wallet payments describes.

Why it is slow at the front door

Three delays stack at the entrance and none of them is the transfer itself. The first is you: finding the app, copying four fields, passing your bank's authentication. The second is your bank's own caution about a new recipient, which can add a confirmation step or a cooling period on a first payment to an unfamiliar account. The third is the matching at the far end.

The third is the one that varies most. A desk with per-customer account numbers credits almost on arrival. A desk relying on references credits automatically when the reference reads cleanly and manually when it does not, and the manual path runs in office hours. A payment sent late on a Friday with a mistyped reference can sit for the whole weekend having completed perfectly.

Which is why this rail is a poor choice for funding something you want to do in the next five minutes. If immediacy is the point, a pull is the honest answer, and the mechanics of the quickest one are on the page about debit card payments.

A bank statement, a phone showing an open banking confirmation and a pen on a desk

Open banking: the same push without the typing

The modern form of this rail removes the part you get wrong. Instead of handing you details to copy, the cashier hands you to your own bank with the payment already built: correct account, correct amount, correct reference, prepared by software rather than by you. You authenticate in your bank as usual and approve it.

Nothing about the direction of travel changes. It is still a push, still irreversible, still authorised by your bank rather than by a card scheme, and still leaves no stored instrument behind. What changes is that the reference cannot be mistyped and the matching is near-instant, which removes both of the delays that are actually yours.

This is why the two rails often appear as separate buttons in the same cashier, and why the newer one is almost always the better choice when both are present. How the authorisation flow works in practice, and what the intermediary in the middle can and cannot see, is on the page about open banking payments.

Why it is predictable on the way out

Everything that makes this rail awkward at the entrance makes it dependable at the exit. A payout by transfer is a credit to a named account, with no scheme in the middle, no card that might have been reissued, and no second leg for you to arrange. It either arrives or it is still in a bank's queue, and there is no third state.

Compare that with a wallet, where the money lands in the wallet and the journey to your bank is a separate transaction you have to make. Or with a card, where a credit posts under rules that differ from a debit and often surfaces later than you expect. The transfer has one leg and ends in the account you actually spend from.

What it does not do is shorten the review before release, which is where nearly all of the waiting lives and is the same review whatever the rail; how a payout is processed sets out the order of events. Rails marketed on speed are competing over the last stage only, as the page on quick payouts explains.

Registering the account you want to be paid into

Because the rail cannot be reversed, a payout on it is aimed at details you supply rather than at a transaction that already exists. That means the details have to be verified before anything is sent, and the verification is of the account rather than only of you: name, sort code, account number, and usually a document that shows all three together.

The requirement that trips people up is the match. The account you are paid into has to be in the same name as the gambling account, and a desk will not pay a third party on your instruction even with your written consent. There is no flexibility here and asking for it reads badly rather than helpfully.

If you deposited by transfer, the account that sent it is the natural destination and usually needs no further work. If you deposited by another rail and want a transfer out, you are introducing a new instrument at the moment of withdrawal, which is the slowest possible moment to introduce one, and the ceilings that apply to each period are the operator's to set, as the page on deposit floors notes for the other direction.

Symptom	What is happening	What actually resolves it
Sent in your bank, absent at the desk	The reference did not read; it is in a manual queue	Your bank's payment confirmation, sent once, then waiting
Your bank warns the name does not match	The account is registered to a payment company	Details taken from the logged-in cashier and nowhere else
Deposit held and queried	The sending name is not the account holder's	Nothing retrospective; pay from your own account
Returned to your account days later	The desk could not attribute or accept it	A fresh payment with the current reference

Where a transfer stalls, and what resolves it

What to send when a transfer goes missing

Send three things and send them once. The payment confirmation your bank produces, which names the destination, the amount and the reference as it was actually transmitted. The exact time including the time zone. And the reference you used, quoted rather than described. That set lets somebody find an unmatched credit in a ledger, which is the only job that needs doing.

Do not send a second payment. An unmatched credit is already waiting to be attributed; a second one creates two, and two unexplained credits from the same person is a pattern that gets accounts reviewed rather than credited. Do not change the reference on a retry either, since that guarantees the second payment fails the same way.

And be patient in a specific way: the delay is almost never the rail. The money has arrived. Somebody has to connect it to you, during working hours, in a queue. The same manual process explains most of what people describe as a transfer that vanished, and almost none of it involves money actually being lost.

When this rail is the right choice

Pick it when you want no stored instrument anywhere, when the amount matters enough that one direction of travel is a feature, or when you want the payout to land in the account you actually live out of with no second leg. Those are good reasons and this rail serves them better than any other.

Do not pick it when you want to deposit in the next minute, when you cannot copy the details carefully, or when the account you would be sending from is not solely in your name. And do not pick it as a way around a control you set at your bank: a transfer towards a recipient your bank recognises as a gambling business may well be caught anyway, and the versions of that control in an app-based bank and in a multi-currency account each cover slightly different ground.

If the newer, built-in version of the rail is offered, take it. The typing is the part that fails, and removing the typing removes the failure, while keeping everything that made the push worth choosing in the first place. The wait after that is the operator's review, and the review is the same for every rail on this site, as the page on payout timing sets out.

Questions people ask

Can a transfer be cancelled once I have sent it?

Not by you and not by the desk. Your bank can attempt a recall, but that is a request to the receiving bank which only succeeds with the recipient's cooperation. Treat the payment as final at the moment you approve it, which is the main reason to check the destination before rather than after.

What if I forget the reference entirely?

The money still arrives, it simply arrives unattached, and somebody has to work out whose it is from the sending account name. That happens manually and in working hours. Send your bank's payment confirmation to support once and then wait rather than paying again.

Can I pay from my partner's account if mine is empty?

No, and this is worth taking seriously rather than trying. The operator has to show the money came from its own customer, so a payment in another name is held, questioned and often returned. If it slips through, the mismatch surfaces at withdrawal with a balance frozen behind it.

My bank says the beneficiary name does not match. Is it a scam?

Usually it means the receiving account belongs to a payment company rather than to the consumer brand, which is ordinary. The protection against it being something worse is provenance: take the details from the cashier while logged in, never from an email, a chat message or a search result, and never retype them from memory.

Why is this slower than a card when the rail itself is instant?

Because arriving and being credited are two different events. The transfer lands quickly; connecting it to your account depends on the reference reading cleanly, and where it does not the job moves into a manual queue that runs in office hours. A desk that issues each customer their own account number avoids most of that.

Is open banking the same thing as a bank transfer?

It is the same push with the details filled in for you by software and authorised inside your bank. Direction, irreversibility and the absence of a stored instrument are unchanged. What disappears is the typing and the matching delay, which is why it is the better option wherever both appear in a cashier.

Can I be paid out to a different account from the one I sent from?

Only if you register it and it is in your own name, and expect the check to take longer than the payout itself. A desk will not pay a third party on your instruction in any circumstances. Introducing a new account at the moment of withdrawal is the slowest possible timing for it.

Does a bank transfer avoid my bank seeing that I gamble?

No, and it is arguably the most visible rail of all. Your statement shows the destination account and whatever name is registered to it, and a transfer towards a recipient your bank recognises as a gambling business can be stopped by the same control that stops card payments. Privacy from your own bank is not a property of any rail here.

Is money won and paid in by transfer taxable?

A player in the United Kingdom pays no tax on gambling winnings, whichever rail carried them. A credit on a bank statement is a record rather than income to declare. The duty in this market is charged to the operator, not to the person who won.

What if I have self-excluded and a transfer still goes through?

The register works at the operator rather than at your bank, so a successful transfer tells you nothing about it: a licensed site will refuse the account and return the money. Hunting for one that would accept it means leaving British licensing and the complaints route that comes with it. The National Gambling Helpline is on 0808 8020 133.