GDPR and Pay by Bank: How Customer Data Is Protected
“Is my bank data safe?” is a fair question, and one the industry does not always answer plainly. Here is exactly what a Pay by Bank provider sees, what it never sees, and how that fits within GDPR.
A Pay by Bank provider like SSV SmartPay only receives what it needs to initiate and confirm a payment, such as the amount and a payment reference, and never receives the customer’s bank account number, sort code, or online banking password. The customer approves each payment individually inside their own banking app, and the data involved is narrower than what a typical card payment shares with a merchant.
What the Bank Shares With the Payment Provider, and What It Doesn’t
Open Banking runs on a specific, regulated role called a payment initiation service provider, or PISP. A PISP’s job is narrow by design: it asks the customer’s bank to move a specific payment, and the bank tells it whether that happened. That narrowness is a feature, not a limitation.
What is typically shared
The payment amount, a payment reference or description, confirmation that the customer authorised the payment, and confirmation of success or failure. Enough to complete and prove the transaction, nothing more.
Amount, reference, authorisation statusWhat is not routinely shared
The customer’s full transaction history, account balance, other payees, savings details, or their online banking password. A PISP is not the same as an account information service, which is a separate, distinctly consented role.
No balance, history, or login credentialsWhat the merchant sees
The merchant receives confirmation that a payment of a specific amount succeeded, with a reference. It does not receive the customer’s bank account number, sort code, or any reusable credential.
Payment confirmation only, no account detailsThis is a deliberate design choice within the regulatory framework, not a courtesy extended by any individual provider. A PISP is only authorised to request payment initiation, so anything beyond that would fall outside what it is regulated to do.
The plain-English version: the payment provider is a messenger asking your bank to move a specific amount, and your bank confirms whether it moved. It is not handed a copy of your account.
Consent: Authorised Per Payment, Not Once and Forever
How consent works is where Pay by Bank differs most visibly from a card left on file. There is no standing permission sitting in the background waiting to be used again.
Each payment is its own request
When a customer scans a QR code or taps a payment link, that action starts a single, specific payment request, for a specific amount, to a specific business.
The customer sees exactly what they are approving
Before confirming, the customer’s own banking app shows the payee and the amount, so consent is given with full visibility of what is about to happen, inside an app they already trust.
Nothing carries over to the next payment
Approving one payment does not authorise a second one. Each future payment needs its own fresh request and its own fresh approval, unless the customer has specifically set up a Variable Recurring Payment with its own defined limits.
That per-payment model is a meaningfully different consent shape to a stored card, where the card details themselves persist and could, in principle, be charged again without the customer actively doing anything at that moment.
“Consent that has to be given again every time is a stronger form of consent than permission granted once and assumed forever.”
The GDPR Basis: Lawful Processing and Data Minimisation
Payment data still counts as personal data under GDPR, so it needs a lawful basis to be processed, and the amount collected should be no more than necessary.
Performance of a contract
When a customer chooses to pay for something, processing the payment data needed to complete that purchase is generally carried out under the “performance of a contract” lawful basis: the data is necessary to deliver what the customer asked for.
Legal obligation, for some records
Certain transaction records also need to be kept to meet financial regulation and accounting requirements, which can sit alongside contractual processing as a separate lawful basis for that specific retention.
Data minimisation, by design
GDPR’s data minimisation principle says only necessary data should be collected. The narrow scope of what a PISP receives, described in Section 1, is a practical example of that principle already built into how the payment works.
Data minimisation is not just good practice here, it is a legal principle under UK GDPR. A payment method that structurally shares less data has less to secure, less to justify retaining, and less that could ever be exposed if something went wrong.
What This Means for Merchants
Using Pay by Bank does not remove a merchant’s own data protection responsibilities, but it does shrink them in one important way.
You are still a data controller for your own data
Order details, customer names, delivery addresses, and anything else you collect directly are still your responsibility under GDPR, with your own privacy policy explaining what is collected and why.
You never hold card numbers or bank credentials
Because payment approval happens inside the customer’s own banking app, you are not storing, transmitting, or securing card numbers or bank login details at all, which removes a major category of data protection and security risk.
Less to disclose if something goes wrong
If a security incident ever occurred elsewhere in your systems, there would be no stored payment credentials for it to expose, which simplifies both your risk and your obligations around breach reporting for that data.
None of this replaces the need for your own clear privacy policy and lawful handling of the data you do collect, such as order and delivery details. It does mean the single most sensitive category of data in most businesses, financial credentials, is one you no longer need to worry about at all.
Card vs Pay by Bank: Data Shared, Side by Side
Put plainly, side by side, the difference in what actually moves between the customer, the payment method, and the business looks like this.
| Data point | Typical card payment | Pay by Bank |
|---|---|---|
| Card number | Shared with merchant or processor, often stored for refunds | Never exists in the flow, nothing to share |
| Expiry date / CVC | Entered at checkout, may be stored by processor | Not applicable, no card involved |
| Bank account number / sort code | Not typically involved | Known only to the customer’s own bank, never shared with the merchant |
| Online banking login | Not involved | Used only inside the customer’s own banking app, never seen by merchant or provider |
| What the merchant actually receives | Card details or a stored token, plus payment confirmation | Payment confirmation and a reference only |
| Consent model | Often stored for repeat use unless removed by the customer | Given fresh for each payment, unless a VRP is separately set up |
A general comparison of typical practice. Exact data handling varies by card processor, wallet, and payment provider.
Frequently Asked Questions
What customer data does a Pay by Bank provider receive?
A payment initiation service provider (PISP) typically receives only what is needed to initiate and confirm the payment: confirmation that the customer authorised it, the payment amount, a reference, and confirmation of success or failure. It does not routinely receive the customer’s full transaction history, account balance, or other account details unless a separate account information service has also been agreed to.
Does Pay by Bank share more data than a card payment?
Generally less, for the merchant’s purposes. A card payment typically involves the merchant or its payment processor holding a card number, expiry date, and cardholder name. A Pay by Bank payment does not give the merchant any bank account number or sort code at all; the merchant receives only confirmation that a specific payment was made, with no reusable financial credential passed to them.
How does consent work for a Pay by Bank payment?
Consent is given per payment, inside the customer’s own banking app, each time they pay. The customer sees the amount and the payee before approving with their bank’s login and biometric checks. There is no standing authority to take further payments unless the customer separately sets up a Variable Recurring Payment with defined limits.
What is the GDPR lawful basis for processing this data?
Processing payment data to fulfil a purchase is generally carried out under the “performance of a contract” lawful basis, since the data is necessary to complete a transaction the customer has requested. Regulated payment providers are also subject to data minimisation principles, meaning they should only collect what is necessary for the payment itself.
What are a merchant’s GDPR obligations when using Pay by Bank?
A merchant remains responsible for its own data protection obligations as a data controller for the customer data it collects directly, such as order details, and should have a privacy policy explaining what is collected and why. Using a regulated Pay by Bank provider can reduce this burden since the merchant does not handle or store card numbers or bank credentials at all.
Continue exploring SSV SmartPay
References
- Information Commissioner’s Office (ICO). Guide to the UK GDPR. Available at: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/
- Financial Conduct Authority. Strong Customer Authentication. Available at: https://www.fca.org.uk/firms/strong-customer-authentication
Important information
General guide, not legal advice. This article explains, in general terms, how data typically flows in Open Banking payments and how GDPR principles apply. It is not legal advice, and it does not describe the specific data fields, retention periods, or lawful basis documentation used by any particular provider. Confirm the details relevant to your business with a qualified data protection adviser and with your payment provider directly.
Merchant obligations vary. A merchant’s own GDPR obligations depend on what data it collects and how, and are not removed by using any particular payment method. Seek your own advice on your specific obligations as a data controller.
SSV SmartPay terms. Full pricing, terms, and conditions are available at ssvsmartpay.co/our-pricing. SSV SmartPay Limited is registered in England and Wales (CRN 15424021). SSV SmartPay is not directly FCA-regulated; payment initiation services are provided by FCA-authorised Payment Institution partners.
T&Cs Applied
Less data to hold, less to worry about
SSV SmartPay never gives you card numbers or bank credentials to store. Sign up in minutes, typically approved within 24 hours, with no monthly fees.
Start free trial Book a demo Or get in touch with the team →Frequently Asked Questions
What customer data does a Pay by Bank provider receive?
A payment initiation service provider (PISP) typically receives only what is needed to initiate and confirm the payment: confirmation that the customer authorised it, the payment amount, a reference, and confirmation of success or failure. It does not routinely receive the customer's full transaction history, account balance, or other account details unless a separate account information service has also been agreed to.
Does Pay by Bank share more data than a card payment?
Generally less, for the merchant's purposes. A card payment typically involves the merchant or its payment processor holding a card number, expiry date, and cardholder name. A Pay by Bank payment does not give the merchant any bank account number or sort code at all; the merchant receives only confirmation that a specific payment was made, with no reusable financial credential passed to them.
How does consent work for a Pay by Bank payment?
Consent is given per payment, inside the customer's own banking app, each time they pay. The customer sees the amount and the payee before approving with their bank's login and biometric checks. There is no standing authority to take further payments unless the customer separately sets up a Variable Recurring Payment with defined limits.
What is the GDPR lawful basis for processing this data?
Processing payment data to fulfil a purchase is generally carried out under the "performance of a contract" lawful basis, since the data is necessary to complete a transaction the customer has requested. Regulated payment providers are also subject to data minimisation principles, meaning they should only collect what is necessary for the payment itself.
What are a merchant's GDPR obligations when using Pay by Bank?
A merchant remains responsible for its own data protection obligations as a data controller for the customer data it collects directly, such as order details, and should have a privacy policy explaining what is collected and why. Using a regulated Pay by Bank provider can reduce this burden since the merchant does not handle or store card numbers or bank credentials at all.
