Cybersecurity for Payment Firms: PSD2, Open Banking, APP Fraud, and PCI DSS v4.0
Payment firms — authorised payment institutions, e-money institutions, and acquirers — operate at the intersection of the most demanding cybersecurity regulatory requirements in UK financial services: PCI DSS v4.0 applies to all firms handling cardholder data; the Payment Systems Regulator's APP fraud reimbursement scheme (effective October 2023) creates direct financial liability for fraud losses; PSD2 open banking introduces API security obligations; and the FCA's PS21/3 framework requires payment processing to be treated as an important business service with defined impact tolerances. This is the sector where cybersecurity failures most directly translate into financial losses for the firm.
Under the PSR's mandatory APP fraud reimbursement scheme (effective October 2023), payment firms bear direct liability for APP fraud losses — up to £415,000 per claim.
PCI DSS v4.0: What Changed and What Payment Firms Must Do
PCI DSS version 4.0 came into full effect on 31 March 2024. The key changes relevant to payment firms:
- Customised approach: v4.0 allows firms to implement alternative controls that meet the intent of requirements — giving flexibility but requiring more documentation and risk assessment
- MFA everywhere: v4.0 requires MFA for all access to cardholder data environments — not just remote access as in v3.2.1
- Phishing-resistant authentication: New requirements for phishing-resistant MFA for privileged accounts — standard TOTP is no longer sufficient for admin access to cardholder data systems
- Script security: v4.0 adds requirements to manage scripts on payment pages — addressing web skimming (Magecart-style) attacks
- Targeted risk analysis: Each firm must conduct tailored risk analysis for each PCI DSS requirement — the standard is more risk-based, less checkbox-based
- Increased testing frequency: Some controls require more frequent testing, monitoring, and review than v3.2.1 mandated
Open Banking API Security: PSD2 Technical Standards
Open Banking and PSD2 create specific API security obligations for payment firms:
- Strong Customer Authentication (SCA): PSD2 requires SCA for electronic payment initiation and account access — two-factor authentication with possession, knowledge, or inherence factors
- API security: Open Banking APIs must implement OAuth 2.0 and OpenID Connect standards — misconfigurations are a common vulnerability in third-party provider integrations
- Third-party provider (TPP) authentication: Payment firms must securely authenticate TPPs accessing customer accounts — a misconfigured authentication flow creates fraud risk
- Transaction monitoring for open banking: Real-time monitoring of API-initiated transactions for anomalous patterns — open banking payment rails are increasingly targeted by fraudsters
- Incident reporting: FCA and PSR require notification of material incidents affecting payment services — open banking outages and security incidents are in scope
APP Fraud Liability: The Cybersecurity-Fraud Nexus
The PSR's mandatory reimbursement scheme creates direct financial liability for payment firms when their customers are victims of APP fraud. The cybersecurity connection is direct:
- Sending firms are liable for reimbursement up to £415,000 per claim — creating per-incident financial exposure that makes fraud prevention a commercial priority
- The scheme requires firms to implement the Contingent Reimbursement Model (CRM) Code standards — including customer education, unusual payment monitoring, and effective friction on high-risk payments
- Confirmation of Payee: PSR requires full CoP implementation for all Faster Payments — CoP verifies account name against sort code/account number, blocking misdirected or fraudulent payments
- Transaction monitoring: Real-time transaction monitoring must detect APP fraud patterns — customers being directed to "safe accounts", unusual beneficiaries, and high-value first-time payments
- Cybersecurity enabling fraud: BEC attacks that compromise payment firm email to intercept and redirect payments are both a cybersecurity incident and an APP fraud event — controls for both are the same
Security Architecture for Payment Systems
Payment firms require specific security architectural controls beyond standard financial services requirements:
- Network segmentation: Cardholder data environments must be isolated from general corporate networks — flat networks are a PCI DSS failure and a systemic risk
- Encryption in transit and at rest: All cardholder data must be encrypted — TLS 1.2+ for transit, AES-256 for storage
- Key management: Cryptographic key management must be documented and tested — key rotation, key storage, and key destruction procedures
- SIEM and log management: PCI DSS v4.0 requires centralised log management with real-time alerting — logs must be retained for 12 months
- Vulnerability management: Quarterly internal and external vulnerability scans, annual penetration testing, and rapid patching of critical vulnerabilities in cardholder data system components
Frequently Asked Questions
We are a small payment institution — do we need to be PCI DSS compliant?
If your firm handles, processes, stores, or transmits cardholder data (card numbers, CVVs, PINs), you are in scope for PCI DSS. The level of compliance (SAQ vs full QSA assessment) depends on your transaction volumes and how you process cards. Small payment institutions that use third-party payment processors and never directly handle cardholder data may qualify for a simplified SAQ-A self-assessment. Your acquiring bank will confirm your compliance level requirements. Regardless of PCI DSS level, FCA regulatory requirements for payment institutions apply independently.
Does implementing SCA for open banking mean our customers need hardware tokens?
No. SCA requires two of three factors: something you know (PIN/password), something you have (mobile device, payment card), and something you are (biometric). Mobile app authentication — where the app proves possession of a registered device plus a biometric or PIN — satisfies SCA. Hardware tokens are one option but not required. The key requirement is that two independent factors from different categories are used, and that the authentication generates a transaction-specific code (dynamic linking for payment SCA).
How quickly must we notify the FCA and PSR of a payment system incident?
FCA PS21/3 requires notification of major operational incidents within 72 hours of becoming aware. The PSR has its own incident reporting regime for participants in regulated payment systems. Incidents affecting the availability, reliability, or security of payment services must be notified — the specific timeline depends on the incident classification. For incidents affecting customers' ability to make or receive payments, FCA expects rapid notification (within hours for severe incidents). You should have a pre-defined assessment procedure that triggers regulatory notification analysis for any payment system incident.
Build PCI DSS v4.0 and PSD2 compliant security controls
Kyanite Blue specialises in cybersecurity for iGaming operators. MGA-licensed operators across Malta trust our stack.
Get in touchReady to secure your iGaming operation?
MGA-licensed operators across Malta trust Kyanite Blue.