What “compliance” means for Open Banking payments in the UK (and who owns what)
For UK Open Banking payments, “compliance” usually means meeting the rules that apply to how payment data is accessed, how consent is captured, and how payments are initiated and protected. In practice, it’s a checklist of responsibilities split across regulated firms, banks, and the business using the service.
- Regulatory permissions (who’s authorised): Payment initiation is typically provided by a Payment Initiation Service Provider (PISP) authorised/registered with the FCA under PSD2/UK payments rules. If you’re a merchant, you usually don’t need FCA authorisation if you’re using a regulated provider and not providing payment services yourself.
- Customer authentication (who enforces it): The customer’s bank (ASPSP) applies Strong Customer Authentication (SCA) during approval. The PISP must integrate correctly and avoid workarounds (e.g., screen scraping).
- Consent and transparency (who captures it): The PISP must obtain explicit consent, show clear payment details (amount, payee, reference), and keep an auditable record of consent and journey steps.
- Data protection (who is controller/processor): Under UK GDPR, the merchant and PISP often act as separate controllers for their own purposes; the bank is also a controller. “Ownership” of data isn’t the key concept—lawful basis, purpose limitation, retention, and security are.
- Liability and disputes (who handles issues): Banks and PISPs have defined responsibilities for unauthorised transactions and operational errors; merchants should align their customer support and refund processes with their provider’s terms.
Step-by-step compliance checklist for integrating Open Banking Pay (PIS): scope, controls, evidence
- Define scope (what you’re building)
Map the payment journey (initiation, redirect/decoupled auth, status, refunds if offered). Identify roles: your business (merchant), your PIS provider, any technical service providers. Evidence: data flow diagram, RACI, list of APIs/endpoints used. - Confirm regulatory coverage with your provider
Verify the PIS provider is FCA-authorised/registered and that your use case fits their permissions (e.g., domestic GBP, recurring/variable payments if applicable). Evidence: provider onboarding pack, FCA register link/screenshot, contract/SLA. - Security baseline & access control
Implement least-privilege access to keys, secrets, dashboards; enforce MFA; segregate environments; rotate credentials. Evidence: access matrix, MFA policy, key rotation logs. - Strong Customer Authentication (SCA) handling
Ensure your UI doesn’t “fake” bank auth, and that redirects/deep links are intact. Handle SCA failures gracefully. Evidence: UX screenshots, test scripts, error-handling matrix. - Consent, transparency & customer messaging
Show clear payer-facing copy: who is initiating, amount, reference, and what happens next. Avoid misleading “instant” claims unless supported. Evidence: approved copy deck, versioned UI strings. - Data minimisation & retention
Store only what’s needed (payment IDs, status, timestamps). Set retention and deletion schedules. Evidence: retention policy, database field inventory. - Operational controls
Reconcile statuses, manage timeouts, idempotency, and duplicate payment prevention. Monitor failures and provider outages. Evidence: runbooks, monitoring alerts, reconciliation reports. - Incident & change management
Define severity, escalation paths, and customer comms templates; track releases affecting payment flows. Evidence: incident log template, change tickets, post-incident reviews.
Open Banking Pay vs cards vs bank transfer vs direct debit: compliance, risk, and ops trade-offs
Open Banking Pay (bank-to-bank via regulated PISPs) typically reduces card-scheme exposure and chargeback risk, but shifts focus to Strong Customer Authentication (SCA), consent capture, and provider due diligence. Ops teams should confirm the payment flow is initiated by the customer, that the PISP/ASPSP is FCA-authorised, and that logs evidence consent, timestamps, and payer account details returned via the API. Refunds can be less standardised than cards, so define a clear refunds process and customer messaging.
Cards are operationally familiar and offer broad consumer protections, but bring higher fraud monitoring overhead and chargebacks. Compliance work concentrates on PCI DSS scope (or reducing it via hosted fields/tokenisation), 3-D Secure/SCA handling, and dispute management. Reconciliation is usually strong, but fees and scheme rules can be complex.
Manual bank transfer (customer-initiated) can be low-cost, yet creates higher operational load: matching references, handling misdirected payments, and slower exception resolution. Compliance risk often sits in AML/CTF controls, beneficiary verification processes, and ensuring you can evidence who paid and why (use unique references and automated reconciliation where possible).
Direct debit is efficient for recurring collections, but requires careful handling of mandate setup, cancellations, and the Direct Debit Guarantee (refund expectations). Operationally, you’ll need robust mandate storage, notice periods, and failure/retry logic. From a checklist perspective, prioritise: customer authorisation records, clear cancellation routes, audit trails, and reconciliation controls across all methods.
UK Open Banking payments compliance FAQs (SCA, consent, refunds, chargebacks, data retention)
Do Open Banking payments require SCA?
Usually yes. For payment initiation, Strong Customer Authentication (SCA) is typically completed in the customer’s bank app or online banking journey using two-factor authentication. If you use a regulated provider, they should handle the SCA step and provide status updates you can log for audit purposes.
What consent do we need, and how do we capture it?
You should obtain clear, informed consent for the specific action (e.g., “make a one-off payment” or “set up a recurring payment where supported”). Record what the customer agreed to, when, and the identifiers used (order reference, user ID, bank journey reference). Provide an easy way to withdraw consent for ongoing access where applicable.
Are refunds supported like card refunds?
Open Banking payments are bank transfers, so refunds are typically initiated as a separate credit transfer back to the customer. Document your refund policy, expected timelines, and the data you need to process a refund (usually account details are not shared; you may refund to the originating account via your provider’s tools).
Do chargebacks apply?
No, not in the card-network sense. Disputes are generally handled via your customer support process and, if needed, the customer’s bank transfer dispute routes. Your checklist should include clear evidence capture (goods/services supplied, delivery confirmation, communications) to resolve complaints.
How long can we retain Open Banking data?
Keep only what you need for operations, reconciliation, fraud prevention, and regulatory/audit needs, and delete or anonymise when no longer required. Align retention with your privacy notice, access controls, and incident response procedures.