Addressing API Security Regulations in Financial Services

Introduction

APIs are disrupting almost every industry vertical, and nowhere is their impact more profound than in the financial services industry. Whether helping modernize legacy systems or creating entirely new business opportunities through innovations such as OpenBanking, APIs are the lifeblood of the financial services industry. At the same time, there is increasing scrutiny on the security of these very APIs to ensure that they both meet the requirements of strict regulatory standards (such as PSD2 and PCI-DSS) and instil confidence within their customers. 

OpenBanking depends on APIs to connect banking systems, customer devices, and third-party providers (TPPs). OpenBanking allows TTPs to provide innovative services, access account information, and initiate payments on the account holder’s behalf. It is becoming widely adopted, with one in nine people in the U.K. using associated services in 2023 and a doubling in the volume of payments in that period. Due to the sensitive nature of the data and operations processed by OpenBanking APIs, providers must ensure they are implemented securely to meet regulatory requirements and customer demands. 

The overarching regulatory standard to ensure secure APIs is the European Union (EU) Payment Services Directive (PSD2), which has specific requirements for the following:

• Strong Customer Authentication (SCA): PSD2 requires the implementation of SCA to access payment accounts and initiate payment transactions through APIs. 
• Secure Communication: PSD2 mandates using secure communication protocols, such as TLS (Transport Layer Security), for all API communications.
• API Access and Consent Management: PSD2 requires financial institutions to provide access to customer account information and payment initiation services to authorized third-party providers (TPPs) through APIs.
• API Documentation and Testing: Financial institutions must provide comprehensive and up-to-date documentation for their APIs, including technical specifications, security requirements, and integration guidelines.
• Fraud Detection and Risk Management: PSD2 requires financial institutions to implement robust fraud detection and risk management mechanisms for APIs. APIs should incorporate real-time monitoring and analysis of transactions to identify and prevent fraudulent activities.
• Incident Reporting and Management: Financial institutions must have processes in place for reporting and managing security incidents related to APIs.
• Regulatory Reporting: PSD2 requires financial institutions to regularly report to regulatory authorities regarding their API implementations and compliance status. This includes reporting on API performance, security measures, incident management, and any deviations from the regulatory requirements.

Mandate For Automated API Security Testing

The Payment Card Industry Data Security Standard (PCI-DSS) version 4.0 also has specific mandates relating to software security, which providers should be aware of. Section 6.2.4 requires providers to implement automated application vulnerability security testing of public-facing web applications, APIs, and internal components. Typically, these requirements can be met by incorporating various software engineering techniques, such as secure design or static code analysis — in general, a shift-left approach is recommended. Section 6.2.3 recommends implementing a secure code review process that is well suited to an API design-first approach since reviews can be conducted on API definitions to ensure they comply with the OpenAPI Specification (OAS) and implement security best practices. Of specific interest to API providers is the new section 6.4.2, which requires affected businesses to

“Deploy an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks.”

The technical requirements mandate that such a device be placed in front of public-facing interfaces or applications, be active and capable of either directly blocking web-based attacks or generating alerts that are immediately investigated.  

42Crunch works with many leading financial institutions providing and consuming APIs and we acknowledge that these requirements may initially seem daunting. Let us break them down to see how to address them. 

To address the requirements of OpenAPI / PSD2, begin with the following:

• Strong Customer Authentication (SCA): APIs must support SCA and ensure that the authentication process is secure and complies with the regulatory technical standards (RTS) specified by PSD2. SCA involves a multi-factor authentication process, such as 3DSecure. 
• Secure Communication: APIs must ensure the confidentiality and integrity of sensitive payment data transmitted between parties. Proper encryption mechanisms should protect data in transit and at rest. 
• API Access and Consent Management: Open Banking APIs require explicit customer consent for TPPs to access their data or initiate payments on their behalf. Consent management mechanisms allow customers to view, manage, and revoke consents easily.
• Data Minimization and Purpose Limitation: Open Banking APIs adhere to the principles of data minimization and purpose limitation, meaning that TPPs should only request and access the minimum amount of data necessary for the specific service they provide. APIs should have granular data access permissions to ensure that TPPs can only retrieve the specific data points they need and cannot access unnecessary customer information.
• Use OAuth2 and OpenID Connect: OAuth2 is a robust mechanism for managing API authorization, allowing granular user control of delegated access, while OIDC allows strong proof of identity using a standard mechanism.
• Use Financial Grade API (FAPI): The standard provides additional security features at the authorization server, tightening behaviors by segmenting TPP permissions.
• API Documentation and Testing: APIs should be thoroughly tested to ensure they meet PSD2 requirements, including functional testing, security testing, and performance testing. 
• Incident Reporting and Management: Ensure that all API access is sufficiently logged to a central location and that a continuous monitoring process is implemented to ensure that incidents and events are investigated timeously.

How to Automate API Security 

42Crunch provides a range of solutions across the SDLC that address many of these requirements. PCI-DSS sections 6.2.3 and 6.2.4 mandate the use of tooling to address design issues early in the development lifecycle, and here, the 42Crunch API Audit product can address design issues in the earliest development stage, namely the API definition. The 42Crunch API Scan product is able to assess the API implementation as the developer builds the API in their IDE or anywhere further down the pipeline. The API Scan validates the API implementation against the definition and is able to detect deviations in a continuous manner with low false positives. This Audit and Scan combination can also address the needs of OpenAPI/PSD2 by enforcing well-documented APIs (via the OpenAPI definition) and a regimen of continuous testing across the lifecycle.

42Crunch API Protect is an API micro-firewall ideally suited to providing coverage for PCI-DSS section 6.4.2, which requires an inline solution with protection capability. The firewall is able to inject itself into the backend API data path (as a reverse proxy) and enforce the API definition at runtime by blocking invalid requests or data payloads. This would also address the OpenAPI/PSD2 requirements for ensuring data minimization (by blocking excessive data exposure), and by providing continuous API monitoring and reporting via various SIEM integrations.

The regulatory landscape for financial services API providers is only likely to become more stringent as more standards are enforced or existing standards (such as PCI-DSS) are bolstered. A broad focus on shift-left and simultaneous shield-right approaches is likely to ease the burden on implementors and providers alike.