The old bank transfer deposit worked like this. The client copied an IBAN from a PDF, typed a reference into their banking app, got one character wrong, and two days later a support agent matched the payment by hand against a bank statement. Somewhere between the copy and the match, a percentage of clients gave up.
Open banking removes every step in that chain. The merchant's provider prefills the beneficiary, the amount and a reference the merchant controls, the client authenticates inside their own bank app, and the merchant gets a webhook confirming the payment against a specific order. The rail underneath is the ordinary domestic or SEPA credit transfer. The difference is who assembles it.
What a payment initiation provider actually does
Under European payment services rules, a licensed payment initiation service provider can instruct a payment on the account holder's behalf, with their explicit consent, using the bank's regulated interface. The provider never holds the money. It builds the instruction, hands the client to their bank for strong customer authentication, and reports back what the bank said.
Because authentication happens in the client's own app with biometrics or a device passcode, there is no separate challenge screen to abandon, and no issuer risk engine deciding whether to allow the transaction. The bank is checking that the account holder is present and that the balance covers the payment. That is a far simpler test than the one a card issuer applies to a deposit at a trading firm.
The cost comparison brokers care about
Open banking providers generally price per transaction, sometimes with a small percentage on larger amounts, rather than the percentage-plus-fixed model of card acquiring. Since there is no interchange and no scheme fee, the cost does not scale with the deposit size in the same way. On a 20,000 euro funding transfer, the difference against a card deposit is significant enough to change a firm's payment strategy on its own.
| Card deposit | Open banking deposit | |
|---|---|---|
| Authentication | 3DS challenge in browser | Biometric in the bank app |
| Pricing shape | Percentage plus fixed fee | Mostly flat per transaction |
| Settlement | Batched, days later | Often within seconds |
| Dispute route | Scheme chargeback | No scheme dispute process |
| Coverage | Global | Country by country |
Settlement speed is the second commercial argument. On instant rails the funds land in the merchant account in seconds rather than sitting in an acquirer's settlement cycle, which shortens the gap between a client's decision to fund and the balance appearing on the platform. Firms running multiple processors often place open banking first for domestic traffic and keep cards as the fallback.
Push payments are irreversible by design. That protects the merchant from card-style disputes, and it also means a mistaken or fraudulent deposit has to be resolved by sending money back, which triggers the firm's own AML checks on returning funds to a source. Write that process down before you switch the rail on.
Where the coverage stops
Open banking is a European regulatory achievement first and a global product second. The UK has the deepest bank coverage, and most euro area countries are workable, but quality varies bank by bank. A provider's claimed coverage of "over 2,000 banks" tells you nothing about whether the three institutions your clients actually use return a clean instant confirmation or a delayed one.
Outside Europe the equivalent function exists under different names and different governance. Instant local rails carry a large share of consumer payments in several markets, and they behave more like national schemes than like the European interface model. For a firm serving clients across regions, open banking is one method in a set alongside cards, e-wallets and local transfer methods rather than a replacement for the set. Our comparison of payout rails covers the outbound side of the same question.
What it does not solve
Payouts are the obvious gap. Payment initiation is inbound. Sending withdrawals to clients still requires a bank transfer from the firm's own account, a mass payout provider, or an e-wallet rail, and the reconciliation for that lives on a separate track.
Recurring billing is the second gap. Variable recurring payments were designed for exactly this, and bank support remains uneven, so a prop firm billing monthly for an evaluation subscription cannot yet treat open banking as a full replacement for stored cards. Refunds are the third: there is no one-click reversal, so a refund is an outbound transfer with its own approval workflow.
The fourth issue is quieter. Because there is no chargeback process, some firms conclude fraud risk has disappeared. It has moved. Deposits from an account that does not match the verified client name are exactly the third-party funding problem that AML procedures exist to catch, and a rail that confirms in two seconds gives an agent less time to notice. Name matching on the payer account should be a hard control, not a report someone reads on Friday.
Adding it without breaking reconciliation
The implementation detail that matters most is the reference. The merchant sets it, so every payment can carry the client ID and the deposit request ID, which makes automatic matching in the back office reliable rather than probabilistic. If the confirmation webhook writes straight onto the client record with the payer name and account attached, the compliance question and the accounting question are both answered by the same event.
The rest is measurement. Track completion rate per bank rather than overall, because one large institution with a broken redirect can drag a market's numbers down while the rail itself works perfectly. That is the same discipline described in approval rate work, applied to a rail where the failure modes are different but the reporting requirement is identical.
"Clients do not think of it as open banking. They think their bank app opened, they pressed the fingerprint, and the money was there. That is the entire product, and it is why the conversion is better."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- A payment initiation provider builds the transfer and the client approves it in their own bank app, removing typed IBANs and references.
- Flat per-transaction pricing and instant settlement make the rail strongest for large deposits.
- Bank coverage and redirect quality vary institution by institution, so measure completion per bank rather than per country.
- No chargebacks does not mean no fraud risk: payer name matching becomes the control that carries the weight.
Frequently Asked Questions
How is an open banking payment different from a normal bank transfer?
The payer never types the beneficiary details. A licensed payment initiation provider prefills amount, reference and account, the payer approves inside their own banking app, and the merchant receives a real-time confirmation tied to the order. That removes wrong references and mistyped IBANs.
Can an open banking payment be charged back?
There is no card scheme dispute process behind it, so the merchant does not face chargebacks in the card sense. Funds can still be recalled through bank processes in fraud cases, and some markets have reimbursement rules for authorised push payment fraud that can reach the receiving firm.
Does open banking work for recurring subscription billing?
Only partly. Variable recurring payments allow repeat debits under a mandate, but availability is uneven across banks and countries. Firms billing a monthly subscription usually keep cards or direct debit as the primary method and offer open banking for one-off funding.