Operational risk management for TPPs

The following outlines the operational risk management framework implemented by Enable Banking in order to support Third-Party Providers (TPPs) using Enable Banking's Infrastructure-as-a-Service in their operations. It details the architecture of the information systems, data hosting arrangements, information security policies, compliance with regulatory requirements (including GDPR, PSD2 and DORA), authentication and payment approval processes, business continuity measures, and responsibilities of both Enable Banking and TPPs in ensuring secure and resilient service delivery.

# Information systems used for payment initiation and account information services

Enable Banking provides a robust TPP Infrastructure-as-a-Service to facilitate account information and payment initiation services. The service is accessed by TPPs primarily through the Enable Banking API with supplementary functionality available through the Enable Banking Control Panel. This infrastructure is designed to be a single-tenant dedicated environment for each licensed TPP, ensuring isolation and tailored operations.

The solution provided by Enable Banking consists of the following components:

• Open Banking Aggregation Service unifies interaction with APIs exposed by ASPSPs. This component is built over the aggregation core, which supports a large number of Open Banking standards and allows rapid implementation of integrations. While storing the access tokens and other data necessary for persistence of access to account information, initiation of payments and retrieval of payment statuses, it processes data received from ASPSPs’ APIs without storing or caching it.

• API Gateway (api.enablebanking.com) allows the TPP to securely access their single-tenant environment where the Open Banking Aggregation Service is deployed.

• Control Panel (enablebanking.com/cp (opens new window)) is a web dashboard where TPPs manage their open banking operations. It provides a central place to configure and manage API access and usage, access logs and analytics for troubleshooting and reporting.

• eIDAS Broker is an open-source solution maintained by Enable Banking that allows TPPs to use the TPP Infrastructure-as-a-Service hosted by Enable Banking without needing to entrust Enable Banking with the private keys of the eIDAS certificates used to secure interactions with ASPSPs. Alternatively, cryptography offload can be done using HSM services such as AWS CloudHSM (opens new window) or Google Cloud Key Management (opens new window).

# Location of servers and databases processing and storing customer and payment data

The above-mentioned components, except for the eIDAS broker (which is to be rolled out and controlled by the TPP) are hosted by Enable Banking on the Google Cloud Platform (GCP).

All data processing activities performed on behalf of the TPP occur within the EU.

A separate installation of the Open Banking Aggregation Service (including all its infrastructure elements such as computational resources, databases and networks) is performed with separate GCP projects (opens new window) to ensure complete isolation for each licensed TPP.

For all databases and other data storage, as well as computational resources and networks used by the systems supporting Infrastructure-as-a-Service provided to TPPs, Enable Banking uses GCP locations (opens new window) europe-west1 (Belgium), europe-west4 (Netherlands) and europe-north1 (Finland). Backups are stored on AWS S3 cloud storage with AWS Regions (opens new window) within eu-north-1 (Stockholm, Sweden) and eu-central-1 (Frankfurt, Germany).

TPPs shall plan their own data storage locations taking into account regulatory requirements, compliance with legislation such as GDPR and PSD2, availability to users, and robust connection with the Enable Banking API.

# Information security procedures for systems and databases

Enable Banking's Information Security Management System (ISMS) is certified to ISO/IEC 27001:2022 standard (opens new window) and relies on methodologies, tools and technologies provided by OWASP, NIST and SANS.

This ISMS covers all company functions, services, and activities, protecting both company and customer data, source code, IT hardware, and cloud infrastructure. Key objectives include supporting business, ensuring regulatory compliance, protecting information assets, maintaining business continuity, and continuous improvement. The Board of Directors holds ultimate accountability, delegating operational responsibilities to Executive Directors and the Security Committee, chaired by the Chief Technology Officer (CTO) who also acts as the Information Security Manager (ISM). The ISM is responsible for defining security standards, supporting Information Asset Owners (IAOs), monitoring compliance, and managing security awareness programs.

To protect systems and databases, Enable Banking employs multiple policies and procedures on information security. The Access Control Policy ensures granular, auditable, and appropriate user access through processes like user assignment, deregistration, and management of privileged access rights, strictly prohibiting shared accounts. The Cryptography Policy mandates the use of robust cryptographic controls, requiring encryption for sensitive data both in transit (TLS 1.2 or higher) and at rest (AES-256 or equivalent), along with secure management of cryptographic keys and digital certificates. The Cloud Computing Policy sets rules for selecting and managing cloud services, emphasizing risk assessment, due diligence, and the use of 2-factor authentication and Single Sign-On for cloud access. Furthermore, secure development is enforced by the Secure Software Development Policy and Secure Development Environment Guidelines, which require security considerations throughout the development lifecycle, including code reviews, automated testing, and web security scans before deployment.

For risk management, incident response, and business continuity, Enable Banking relies on structured procedures. The Risk Assessment Policy outlines a systematic approach for identifying, evaluating, and estimating risks to company assets, categorizing information as Public, Internal, Confidential, or Secret based on sensitivity. The Logging and Monitoring Policy details the collection and analysis of security event logs from all IT systems to detect incidents promptly, with requirements for sensitive data obfuscation, clock synchronization, and automated alerts. In the event of a security incident, the Information Security Incident Management Policy guides reporting, classification, and resolution, ensuring timely notification to relevant authorities. Data integrity and availability are addressed by the Backup Policy and Procedure, which specifies automated, secure, and verifiable backups of critical data, including Enable Banking API consents and source code. Lastly, the Business Continuity Plan details steps to minimize business impact during disruptive incidents, with a target to recover systems within 48 hours, including specific disaster recovery scenarios for the Enable Banking API and TPP Infrastructure-as-a-Service as whole.

Enable Banking’s Information Security Policy is a public document that provides an overview of the company's Information Security Management System (ISMS), outlines its guiding principles, and references the relevant legislation, regulations, and standards governing its operations. The policy demonstrates the company’s commitment to safeguarding data, ensuring compliance with statutory and regulatory requirements, and maintaining business continuity. It serves as a framework for employees, subcontractors, business partners, authorities, and customers to understand Enable Banking’s approach to information security, supported by detailed procedures and complementary policies.

Enable Banking's ISMS has been adapted to comply with the requirements of Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), which applies to the company as both an obliged entity and a service provider to other obliged entities. The company maintains a DORA requirements mapping with references to relevant ISMS documents and related procedures, which summarised below.

• ICT Risk Management Framework (Article 6): Enable Banking maintains a robust ICT risk management framework, with clear governance and oversight from the Executive Directors and Security Committee. Risks are systematically managed using the Risk Assessment Policy, Information Risk Register, and Risk Treatment Plan, with annual reviews and integration into the incident response process.

• ICT Systems, Protocols, and Tools (Article 7, 8): All ICT systems, protocols, and tools used are identified and documented in the Cloud Service Register, as per the Cloud Computing Policy. Information assets are inventoried, classified, and their impact on confidentiality, integrity, and availability is rigorously estimated.

• Protection and Prevention (Article 9): The Information Security Policy provides overarching guidance for continuous monitoring and control of ICT systems to minimise risk impact. Specific controls for cryptography are detailed in the Cryptography Policy, while logical and physical access controls are managed by the Access Control Policy. Changes to systems are governed by the Change Management Policy, which mandates testing in non-production environments and security tests before release. Measures for personal data protection are specified in the Personal Data Processing Activities register.

• Detection (Article 10): The Logging and Monitoring Policy establishes requirements for the collection, protection, retention, and continuous monitoring of security event logs from various sources, including source code changes, HTTP logs, authentication attempts, and API metrics. Automated log correlation and alerting mechanisms are configured using GCP Monitoring and the Google Workspace Alert Centre.

• Business Continuity and Backup (Article 11, 12): Enable Banking's Business Continuity Plan (BCP) and the Enable Banking API Disaster Recovery document outline detailed procedures for recovery from disruptive incidents, aiming for systems recovery within 48 hours. The Backup Policy and Procedure mandates automated, secure, and verifiable backups, with defined retention and disposal policies.

• Learning and Evolving (Article 13): The Information Security Incident Management Policy ensures that incidents are reviewed to identify root causes and areas for improvement. Regular training programs, including secure software development and business continuity training, are provided to employees.

• Communication (Article 14, 19): The BCP and Information Security Incident Management Policy stipulate clear communication protocols during incidents, covering internal teams, customers, business partners, and notifications to relevant authorities such as FIN-FSA and the Office of the Data Protection Ombudsman.

• Digital Operational Resilience Testing (Article 24, 25, 26): A comprehensive testing program is in place, including vulnerability assessments, open source analyses, source code reviews, and independent penetration testing performed at least annually. BCP tests are also conducted annually, with results reviewed during internal audits. Advanced testing, such as threat-led penetration testing (TLPT), is selected based on risk assessment.

• ICT Third-Party Risk (Article 28, 29, 30): The Outsourcing Policy and Cloud Computing Policy govern the principles for managing risks associated with third-party providers. This includes conducting due diligence, addressing contractual requirements, and assessing ICT concentration risk. Enable Banking also specifically addresses DORA Article 30 requirements within its Enable Banking API license agreements for companies that fall within the scope of DORA.

The Infrastructure-as-a-Service provided by Enable Banking to TPPs is implemented on Google Cloud Platform, which is ISO 27001, ISO 27017, ISO 27018, EU Model Contract Clauses certified.

In addition to the security measures implemented by Enable Banking, the TPP is responsible for adopting and maintaining their own robust information security practices when connecting to and using the TPP Infrastructure-as-a-Service. This includes ensuring secure integration with Enable Banking's systems, implementing appropriate access control, encryption, and monitoring measures on their side, and following best practices for vulnerability management, incident response, and business continuity. The TPP should regularly review their security posture, conduct independent security testing where applicable, and ensure compliance with all relevant legal and regulatory requirements to maintain end-to-end protection of data and services when leveraging the Enable Banking IaaS platform.

# Service authentication and approval of payments and access to account information

Third-Party Providers (TPPs) are responsible for authenticating their own service users. TPPs must design and operate their own authentication mechanisms (such as login, identity validation, and session management) to ensure that only legitimate users can access their services. Enable Banking does not identify service users, create or manage user accounts, or store user profiles on behalf of the TPP.

As illustrated in the diagram below, once a user (Payment Service User, PSU) is authenticated within the TPP’s service (or identified in another way), Enable Banking facilitates the regulated interaction with the Account Servicing Payment Service Provider (ASPSP). This is followed by connecting the user to their ASPSP for Strong Customer Authentication (SCA) and account information or payment initiation consent capture. The ASPSP authenticates the user and obtains their explicit consent before providing confirmation of success or rejection. Enable Banking then securely communicates the outcome back to the TPP, allowing the service flow to continue according to the TPP's business logic.

The diagram below provides a more detailed and technical view of the payment initiation process. It illustrates the step-by-step interactions between the user (PSU), the TPP's application, Enable Banking API, the eIDAS broker, and the Account Servicing Payment Service Provider (ASPSP). The flow covers all relevant stages including ASPSP selection, user authentication, account selection, consent capture, and Strong Customer Authentication (SCA). It also shows how payment requests are initiated, authorised, and confirmed, along with status retrieval and webhook notifications to keep the TPP informed of the final outcome.

When designing services using the infrastructure provided by Enable Banking, it is the responsibility of the TPP to define how different payments are handled. For instance, TPP shall handle different statuses communicated to it while the ASPSP executes the payment. It is important to take into account that payment execution and settlement may take time, and the duration can vary significantly depending on the payment type. The TPP must therefore design an efficient process for monitoring status changes and ensuring that users are informed appropriately.

In addition, the TPP needs to plan for scenarios where payments are rejected by the ASPSP even after successful approval by the PSU, as well as other possible negative outcomes. The business logic for handling such cases must be clearly defined to ensure transparency and reliability of the service.

It is also the TPP's responsibility to define the payment settlement process. This includes determining the destination account for received funds—for example, whether the funds are transferred to the TPP's own account, to accounts belonging to merchants using the TPP's service, or to an arbitrary account specified by the PSU (such as for invoice payments). The chosen settlement process must consider reconciliation strategies, risk management for different money transfer scenarios, and overall operational robustness.

# Payment service security and usage limits

Enable Banking does not set euro-denominated, geographical, or time-based limits for payments. It is the responsibility of the TPP to define such limits, as well as to build rules for payment transaction monitoring that are sufficient to prevent fraud and ensure compliance with AML/CTF legislation.

Enable Banking provides the technical capability to connect with the TPP's payment transaction monitoring system. Every payment initiated through Enable Banking is checked against the TPP's monitoring rules. If the monitoring system returns a “no-go” decision, Enable Banking will prevent the initiation of the payment.

The diagram below illustrates the payment initiation process flow with integrated transaction monitoring checks. It shows how the PSU, TPP, Enable Banking, and the ASPSP interact during payment initiation and authorisation. At key points in the flow, the TPP's transaction monitoring system evaluates the payment against defined rules. Based on the results (“go” or “no-go”), Enable Banking either allows the payment to proceed or prevents its initiation.

As indicated on the diagram, Enable Banking also communicates to the TPP's transaction monitoring system whether a payment has been successfully executed by the ASPSP or not. This feedback loop allows the TPP to implement additional monitoring rules and cumulative limits (e.g., by user, merchant, time frame, or geographical location).

# Business continuity procedures for IT systems

Enable Banking, certified under ISO/IEC 27001:2022, implements comprehensive business continuity procedures for its IT systems, particularly those involved in the provision of the Enable Banking API (and all other components of TPP Infrastructure-as-a-Service). The company's Business Continuity Plan (BCP) is tested at least annually and has been audited multiple times, ensuring its robustness and effectiveness.

The primary goal is to minimise negative impact on the TPPs’ business, ensure the continuation of services in a limited form, and restore normal operations as swiftly as possible, aiming for system recovery within 48 hours following a disruptive incident of any magnitude.

These incidents can range from software failures and cloud computing service unavailability to cyber-attacks like Denial-of-Service or unauthorised data access. The IT Recovery Team is responsible for restoring cloud infrastructure, operating systems, applications, and data from verified backups, with detailed guidelines for scenarios such as migrating the Enable Banking API from Google Cloud Platform to Amazon Web Services if the primary PaaS infrastructure is significantly disrupted. The procedures also outline crucial steps for communicating with affected parties and relevant authorities, such as FIN-FSA and NCSC-FI, to manage and report incidents effectively.

Any TPP using the infrastructure provided by Enable Banking is required to establish and maintain its own Business Continuity Plan covering its internal operations, processes, and customer-facing services. This ensures that, while Enable Banking manages the continuity and recovery of the Open Banking connectivity and aggregation infrastructure, the TPP can independently address potential disruptions within its own systems, integrate incident communication procedures, and meet its regulatory and contractual obligations.