Psd2 API Compliance

PSD2 (Payment Services Directive 2) is a European Union regulation that came into effect in January 2018, with strong customer authentication (SCA) requirements enforced from September 2019. The regulation fundamentally changed how payment services operate in the EU/EEA, opening banking to third-party providers and mandating stronger security controls for electronic payments.

The directive applies to:

• Payment service providers (banks, payment institutions, e-money issuers)
• Account information service providers (AISPs)
• Payment initiation service providers (PISPs)
• Payment card networks and processors
• Any business offering payment services within the EU/EEA

PSD2's scope extends beyond traditional banking APIs to include any interface that enables payment initiation, account information access, or payment processing. This includes RESTful APIs, SOAP services, and even legacy payment gateways that expose programmatic interfaces.

PSD2 mandates specific security controls for APIs that handle payment services. The regulation doesn't just require authentication—it demands comprehensive API security that protects against multiple attack vectors.

Strong Customer Authentication (SCA)

Article 97 requires two-factor authentication for payment services, but this extends to API access patterns. APIs must implement robust authentication mechanisms that prevent credential stuffing, brute force attacks, and session hijacking. This means multi-factor authentication isn't optional for payment APIs—it's a regulatory requirement.

Transport Layer Security

PSD2 implicitly requires TLS 1.2 or higher for all payment API communications. While not explicitly stated, the security requirements make unencrypted API endpoints non-compliant. This includes proper certificate management, HSTS headers, and protection against TLS downgrade attacks.

Input Validation and Parameter Tampering

The regulation's security requirements align with OWASP API Top 10's broken object level security (BOLA) and injection vulnerabilities. APIs must validate all input parameters, enforce strict type checking, and prevent parameter manipulation that could lead to unauthorized data access or payment manipulation.

Rate Limiting and DoS Protection

PSD2 requires APIs to implement rate limiting to prevent denial-of-service attacks and credential stuffing attempts. This includes per-IP rate limiting, per-account rate limiting, and intelligent throttling based on request patterns.

Audit Logging

Article 75 requires comprehensive audit trails for all payment transactions and API access. APIs must log authentication attempts, data access patterns, and any suspicious activities. These logs must be tamper-evident and retained for regulatory review.

Secure Communication with Third Parties

PSD2's open banking provisions require secure API-to-API communication between banks and third-party providers. This includes mutual TLS authentication, API key management, and secure webhook implementations for payment notifications.

Meeting PSD2 requirements requires both technical implementation and documented proof of compliance. Here's how organizations can demonstrate they meet the regulation's API security standards.

Technical Implementation Steps

Start with a comprehensive API inventory to identify all endpoints that handle payment services. Each endpoint must be assessed against PSD2 requirements. Implement OAuth 2.0 with JWT tokens for authentication, ensuring tokens include proper scopes and expiration times. Use API gateways to enforce rate limiting, input validation, and TLS termination.

Continuous Security Testing

PSD2 compliance isn't a one-time achievement—it requires ongoing security validation. Implement automated security scanning that runs before each API deployment. This includes static analysis of API specifications, dynamic testing of running endpoints, and regular penetration testing focused on payment-specific vulnerabilities.

Documentation and Reporting

Maintain comprehensive documentation of your API security controls, including architecture diagrams, authentication flows, and security policies. Generate regular compliance reports that map your security controls to PSD2 requirements. These reports should include scan results, vulnerability assessments, and remediation timelines.

Using middleBrick for PSD2 Compliance

middleBrick provides targeted PSD2 compliance scanning that validates your APIs against the regulation's specific requirements. The scanner tests for authentication bypass vulnerabilities, input validation weaknesses, and data exposure issues that could lead to PSD2 violations. With 12 parallel security checks, middleBrick identifies risks across authentication, authorization, data protection, and communication security.

The platform generates compliance-ready reports that map findings to PSD2 requirements, making it easier to demonstrate due diligence to regulators. The GitHub Action integration allows you to fail builds when security scores drop below compliance thresholds, ensuring PSD2 requirements are enforced throughout your development lifecycle.

Third-Party Provider Security

If you're a bank providing APIs to third-party providers, you must also verify their security posture. middleBrick's self-service scanning allows you to quickly assess third-party API implementations without requiring access to their codebases or credentials. This helps you maintain regulatory compliance while enabling open banking innovation.