1. Introduction

The Nebras Open Finance Platform consists of two SaaS solutions:

• Trust Framework, provided by Raidiam

• API Hub, provided by Ozone API

The purpose of this document is to explain the platform assurance measures, certifications and test results relating to each solution.

The security assessments for the Trust Framework and the API Hub have been independently penetration and vulnerability tested. Each platform and its operations conforms to SOC2 and ISO standards, with independent audits and certification processes.

2. Trust Framework

2.1 Overview

The Trust Framework is an existing SaaS platform (Raidiam Connect) that provides a comprehensive Trust Platform technology suite designed to facilitate secure resource / API ecosystems. It is composed of the following key functions:

• A centralized identity provider

• Onboarding and accreditation tools

• A directory service for certificate management.

The Trust Framework Directory is deployed in a dedicated Nebras instance, hosted locally in the UAE (Microsoft Azure UAE, North region)  to ensure that all data is stored and processed in the UAE. The remaining functions are also hosted locally in AWS, within the UAE region.

Raidiam Connect’s Public Key Infrastructure (PKI) capabilities manage digital certificates that are critical to security. The Raidiam Connect platform enables easy participant registration, API-based discovery, and includes a sandbox for testing and certification.  The key challenges addressed by Raidiam Connect include:

1. Client Management: Handling onboarding, organizational lifecycle, and offboarding.

2. Authentication Credential Management: Issues with credential creation, rotation, and permission management, including the limitations of shared credentials.

3. Stakeholder Management: Providing assurance to customers, certification bodies, regulators through conformance with standards like FAPI 2.0.

Raidiam Connect - key features:

• Proven scalability and use as national infrastructure.

• Full-featured UI and API for customer and staff use.

• Self-service management and API integration for rapid deployment.

• Operational control plane for integration management.

• High availability managed infrastructure.

Raidiam Connect supports advanced credential management using non-shareable, asymmetric credentials. Key processes include:

• Creation: Org/app registration, certificate generation, and integration with authorization servers.

• Management: Self-service or automated credential cycling, scope assignment, and RBAC permission management.

• Access Control and Offboarding: Access restriction via UI, certificate invalidation, and org-level deactivation

2.2 Security by Design

Raidiam Connect is built around a “security by design” principle, incorporating defense-in-depth strategies and adherence to global standards like FAPI and the OWASP API Top 10. The platform embeds secure key lifecycle management via FIPS 140-2 Level 3 HSMs, supports mutual TLS, and ensures certificate integrity through OCSP and CRL mechanisms. All services are hardened with intrusion detection, WAFs, and DDoS protections, ensuring secure, resilient operations with 99.999% availability. This approach underpins the platform’s credibility in safeguarding high-volume, critical financial data exchanges.

2.2.1 Policies and Procedures

Raidiam maintains an Information Security Management System (ISMS) and a comprehensive set of policies and procedures which are externally audited for compliance with ISO 27001.

Employees are required to familiarise themselves with these policies and ongoing efforts are made to ensure that employees have appropriate levels of security awareness and understand security requirements. Raidiam security policies and key security procedures are reviewed and approved at least annually by their owners.

Raidiam policies include (but are not limited to):

• Information Security Policy

• Acceptable Use

• Mobile Device Policy

• Secure Software Development Lifecyle Policy

• Risk Assessment and Treatment Methodology

• Incident Management Policy

• Information Security Policy for Suppliers

• Business Continuity Plan

• Raidiam Connect Vulnerability Management Processes

• Disciplinary Policy and Procedure

Raidiam conducts an internal audit programme against ISO 27001, including an assessment of operational compliance with security policies.

2.3 Compliance and Certifications

2.3.1 In Scope 

Certification	Issued By	Date	Evidence
ISO 27001	The British Assessment Bureau	November 2024 Surveillance Audit	Certificate Open
SOC 2 Type 1     Audit for SOC2 Type 2 is scheduled for H2 2025	Moore ClearComm	31 January 2025	Providing the Auditors comments from the SOC2 Type 1 report. Section 3: Independent Service Auditor’s Report To: Raidiam Services Ltd Scope We have examined Raidiam’s accompanying description in Section 4 titled “Description of the Raidiam Connect Platform” (description) as well as the suitability of the design of controls to meet the criteria for the applicable TSCs principles set forth in TSP section 100, Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality (applicable trust services criteria), as at 31st January 2025. The description indicates that certain complementary user entity controls that are suitably designed and operating effectively are necessary, along with controls at Raidiam, to achieve Raidiam’s service commitments and system requirements based on the applicable trust services criteria. The description presents Raidiam’s controls, the applicable trust services criteria, and the complementary user entity controls assumed in the design of Raidiam’s controls. Our examination did not include such complementary user entity controls, and we have not evaluated the suitability of the design or operating effectiveness of such controls. Raidiam uses subservice organisations to provide cloud hosting. The description indicates that complementary subservice organisation controls that are suitably designed and operating effectively are necessary, along with controls at Raidiam, to achieve Raidiam’s service commitments and system requirements based on the applicable trust services criteria. The description presents Raidiam’s controls, the applicable trust services criteria, and the types of complementary subservice organisation controls assumed in the design of Raidiam’s controls. The description does not disclose the actual controls at the subservice organisations. Our examination did not include the services provided by the subservice organisations, and we have not evaluated the suitability of the design or operating effectiveness of such complementary subservice organisation controls. Service Organisation’s Responsibilities Raidiam is responsible for its service commitments and system requirements and for designing and implementing controls within the system to provide reasonable assurance that Raidiam’s service commitments and system requirements were achieved. Raidiam has provided the accompanying assertion about the description and the suitability of the design of controls stated therein. Raidiam is also responsible for preparing the description and assertion, including: ·       the completeness, accuracy, and method of presentation of the description and assertion. ·       providing the services covered by the description. ·       selecting the applicable trust services criteria and stating the related controls in the description; and ·       identifying the risks that threaten the achievement of the service organisation's service commitments and system requirements. Service Auditor's Responsibilities Our responsibility is to express an opinion on the description and on the suitability of design of controls stated in the description based on our examination. Our examination was conducted in accordance with ISAE 3000 attestation standards established by the International Auditing and Assurance Standards Board (IAASB). These standards require that we plan and perform our examination to obtain reasonable assurance about whether, in all material respects, the description is presented in accordance with the description criteria and the controls stated therein were suitably designed to provide reasonable assurance that the service organisation's service commitments and system requirements were achieved based on the applicable trust services criteria. We believe that the evidence we obtained is sufficient and appropriate to provide a reasonable basis for our opinion. An examination of the description of a service organisation's system and the suitability of the design of controls involves the following: ·       Obtaining an understanding of the system and the service organisation's service commitments and system requirements. ·       Assessing the risks that the description is not presented in accordance with the description criteria and that controls were not suitably designed. ·       Performing procedures to obtain evidence about whether the description is presented in accordance with the description criteria. ·       Performing procedures to obtain evidence about whether controls stated in the description were suitably designed to provide reasonable assurance that the service organisation achieved its service commitments and system requirements based the applicable trust services criteria. ·       Evaluating the overall presentation of the description. Our examination also included performing such other procedures as we considered necessary in the circumstances. Service Auditor’s Independence and Quality Control In carrying out our work, we complied with the Institute of Chartered Accountants in England and Wales (ICAEW) Code of Ethics, which includes independence and other requirements founded on fundamental principles of integrity, objectivity, professional competence and due care, confidentiality and professional behaviour, and which is at lease as demanding as the applicable provisions of the IESBA Code of Ethics. We also apply International Standards on Quality Control (UK) 1 and accordingly maintain a comprehensive system of quality control including documented policies and procedures regarding compliance with ethical requirements, professional standards and applicable legal and regulatory requirements. Inherent Limitations The description is prepared to meet the common needs of a broad range of report users and may not, therefore, include every aspect of the system that individual report users may consider important to meet their informational needs. There are inherent limitations in any system of internal control, including the possibility of human error and the circumvention of controls. Because of their nature, controls may not always operate effectively to provide reasonable assurance that the service organisation’s service commitments and system requirements are achieved based the applicable trust services criteria. Also, the projection to the future of any conclusions about the suitability of the design of controls is subject to the risk that controls may become inadequate because of changes in conditions or that the degree of compliance with the policies or procedures may deteriorate. While the controls may be informed by the service organisation’s need to satisfy legal or regulatory requirements, our scope of work and our conclusions do not constitute assurance over compliance with those laws and regulations. Description of Tests of Controls The specific controls we tested, and the nature, timing and results of those tests are presented in Section 5, “Trust Service Criteria, Related Controls and Test of Controls” of this report. Opinion In our opinion, in all material respects, based on the description criteria and applicable trust services criteria: a)     the description fairly presents the Raidiam Connect Platform that was designed and implemented as at 31st January 2025, in accordance with the description criteria, and b)     the controls stated in the description were suitably designed as at 31st January 2025 to provide reasonable assurance that Raidiam’s service commitments and system requirements would be met if the controls have been designed effectively, user entities applied the complementary user-entity controls and the subservice organisation applied the types of controls expected to be implemented at the subservice organisation. Restricted Use This report is intended solely for the information and use of Raidiam, user entities of the Raidiam Connect Platform throughout as at 31st January 2025, as well as prospective user entities, independent auditors and practitioners providing services to such user entities, and regulators who have sufficient knowledge and understanding of the following: ·       The nature of the service provided by the service organisation. ·       How the service organisation’s system interacts with user entities, subservice organisations, or other parties. ·       Internal control and its limitations. ·       Complementary user-entity controls and how they interact with related controls at the service ·       organisation to meet the applicable trust services criteria. ·       User entity responsibilities and how they may affect the user entity’s ability to effectively use the ·       Service Organisation’s services. ·       The applicable trust services criteria. ·       The risks that may threaten the achievement of the applicable trust services criteria and how controls address those risks. This report is not intended to be and should not be used by anyone other than these specified parties. Moore Kingston Smith LLP For and on behalf of Moore Kingston Smith LLP 9 Appold Street London EC2A 2AP 24/2/2025

2.3.2 Out of Scope

Raidiam does not have visibility of the exchanged information between ecosystem participants, hence PCI-DSS compliance is not relevant

2.4 Disaster Recovery

Within the primary nominated region, services are deployed into three availability zones (AZ's) in a hot/hot configuration wherever possible with the exception being the persistence layers of Azure Database for PostgreSQL and MongoDB which are deployed read+write/read/read with auto failover. In the event of a Disaster event occurring, the loss of a single Availability Zone, the Trust Framework will automatically fail over any read+write instances deployed in the failed data centre to an alternative data centre.

2.4.1 Recovery Procedures (General)

1. Incident Detection and Assessment:

   • Raidiam receives alerts and assesses the severity and scope of the incident.

   • Initial triage to identify the affected components.

2. Failover Procedures:

   • In case of zonal failure, Trust Framework will automatically failover to healthy zones.

   • MongoDB replica sets ensure data availability during node or zonal failures.

3. Data Restoration:

   • MongoDB replica sets provide immediate online data redundancy.

   • Continuous point-in-time backups and snapshots are used to restore data in case of corruption or loss.

   • Regular backup restoration testing ensures integrity of backups.

4. Service Restoration:

   • Trust Framework auto-scaling and self-healing mechanisms restore service availability at the individual service.

   • Infrastructure-as-code is used to rapidly re-deploy infrastructure components to their desired state if replacement is required.

   • Stateless configurations allow for rapid service restoration.

5. Validation and Testing:

   • Post-recovery validation to ensure service functionality and data integrity.

   • Performance and load testing to verify system stability.

   • Ongoing enhanced monitoring of each workload.

6. Post-Incident Review:

   • Detailed review of the incident and recovery process.

   • Identification of areas for improvement and implementation of corrective actions.

   • Accountability for these reviews and improvements tracked at ISMF.

2.4.2 Cloud Provider Regional Failure Scenario

This section addresses a specific disaster scenario: a total regional failure of the cloud provider (AWS/Azure).

• Impact:

  • If Azure is unavailable then database access is lost, however critical services will remain available.

  • If an AWS Failure occurs, customer deployments and databases within the impacted region become unavailable.

  • Due to regulatory and data sovereignty constraints, immediate failover to another region is not possible.

  • Data integrity remains unaffected. Stored data remains intact, but access is temporarily lost.

• Recovery Strategy:

  • Acknowledgement and Communication: Immediate notification to Nebras Management/CBUAE regarding the regional outage.

  • Data Integrity Verification: Confirm data integrity through backup validation processes.

  • Infrastructure Recovery:

    • Once the cloud provider restores regional services, initiate a phased recovery of the Trust Framework infrastructure.

    • Utilize infrastructure-as-code to rapidly redeploy the services if required.

    • Restore databases from validated backups if required.

  • Service Validation: Rigorous testing of all restored services to ensure functionality and data consistency.

  • Post-Recovery Analysis: Conduct a thorough post-incident review to identify areas for improvement and implement preventive measures.

• Important Considerations:

  • Due to regulatory and data sovereignty constraints, there is no hot or cold failover to another region. The recovery is dependent on the cloud provider restoring the impacted region.

  • This scenario will have the largest RTO of all disaster scenarios, and its impossible to predict.

  • Communication with stakeholders is critical throughout the outage and recovery process.

  • Documentation and testing of recovery steps is essential for efficient and consistent restoration.

2.4.3 Communication Plan

• Regular updates to Nebras Management/CBUAE during a disaster event, with market communications handled via Nebras Operations.

• Clear communication channels for reporting incidents and receiving updates.

• Post-incident reports detailing the cause, impact, and recovery actions.

2.4.4 Testing and Maintenance

• Annual DR drills and practical exercises to validate recovery procedures to continuously improve processes.

• Periodic review and update of the DR plan.

• Ongoing preventive maintenance of infrastructure and backup systems.

2.4.5 DR Test Report

2.4.5.1. Introduction

This report detailed the results of a Disaster Recovery (DR) test conducted on the Open Finance Trust Framework on 19 Mar 2025. The test aimed to validate the platform's resilience and recovery capabilities as outlined in the Disaster Recovery Document.  

2.4.5.2 Test Objectives

The primary objectives of the DR test were to:

• Simulate a failure of an availability zone.

• Verify automatic failover.

• Assess the platform's ability to maintain service availability and performance during a simulated outage.

2.4.5.3 Test Execution

• The test runtime, as shown in the attached report "CBUAE Dev DR Test Report 19-03-2025.pdf", started at 14:00 19/03/25.  

• Failover to another availability zone was performed as designed.   

2.4.5.4 Test Results

The detailed test results can be viewed here “Insert Link” In summary:

• Raidiam monitoring identified uptime of 100% during test.

• Automated End to End tests demonstrated a successful execution both during and after the DR test execution. 

• All aspects of the test performed as expected.  

2.4.6 Conclusion

Overall, the platform performed as designed. There were no detectable errors or material degradation in service during the simulated DR event. The DR event ended at 14:50 UTC.

A deployment to rescale the development environment back to development configuration occurred at 17:55 UTC to return the environment to its target state.  The 3-hour window was to ensure the environment could sustain operation in a failed over state,

2.5 Penetration Testing

Raidiam performs penetration tests on client sandbox environments. Client sandboxes are replicas of the production environments but do not contain production data. Testing on client sandboxes ensures we have optimal test coverage without any risks to client’s data.

Raidiam performs multiple full platform pen-tests each year, this is in conjunction with feature-level pen-testing for any new features where SDLC risk assessment process identifies the need for external security auditing.

Raidiam SDLC makes use of SAST tools in the form of GitHub’s Dependabot and SonarCloud. DAST OWASP vulnerability scans are carried out using www.edgescan.com as part of QA testing.

2.6 Performance Testing

Raidiam conducts API performance tests and establishes baselines for key metrics such as response time, error rate, and percentile response times (p90 and p95). There is a particular focus on a small subset of GET endpoints that return larger payloads, such as authorisation servers, software statements, and organisation details, as these provide valuable insights into system performance under load. The baseline metrics gathered include target response times for these endpoints (e.g., p95 under X milliseconds for authorization servers).  There is an emphasis on monitoring error rates to detect issues like timeouts or data handling problems.

Raidiam’s testing methodology involves running scenarios with single and multiple concurrent users to measure how concurrency affects performance. Tests will include a warm-up phase, steady-state load, and data collection using tools like k6, with results aggregated and analyzed to define the current performance state. There is continuous monitoring after baseline establishment to detect deviations and guide future optimization.

3. API Hub

3.1 Overview

The API Hub provides a secure and reliable platform for financial institutions (LFIs) to exchange data within the CBUAE Open Finance ecosystem. It is architected for 99.99% availability, excluding planned maintenance.

The API Hub is an existing SaaS platform (the Ozone API Hub), used by over 100 banks and financial institutions globally. Ozone API has deployed a dedicated (to Nebras) instance, hosted locally in the UAE, hosted in Microsoft Azure UAE North region, which ensures that all data is stored and processed in the UAE.

The solution leverages Azure Platform-as-a-Service (PaaS) products (Application Gateway, Firewall, etc.):

• These PaaS products are inherently highly available, with Azure controlling node placement in zones.  

• This inherent high availability of PaaS services contributes to the solution's resilience.  

• More on Azure availability zones overview - https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview?tabs=azure-cli

3.2 Security by Design

3.2.1 Design Principles

The API Hub is designed to offer best in class security and performance in a number of ways:

• The API Hub is fully compliant with the latest version of the UAE Open Finance Standards, including the Financial Grade API (FAPI) profile v2.0 - the global benchmark for API Security.

• All data transferred to/from the API Hub is only transferred between regulated (by CBUAE) parties (TPPs and LFIs) and with the explicit consent of the User or for CBUAE’s legitimate interests (e.g. confirmation of payee).

• All such data is transferred over mTLS, encrypted using the TPP’s or LFI’s keys, with certificates issued by the Trust Framework.

• The API Hub does not store any personal data.

• Access to admin and reporting interfaces is via SSO, using digital credentials of known persons, approved by Nebras Management and stored in the Trust Framework.

3.3.2 Resilience Measures

The API Hub's resilience is built on three core pillars: Platform Design, Validation, and Always-on Monitoring.

Platform Design

• Cloud Infrastructure:

  • Hosted on Microsoft Azure, leveraging PaaS services for high availability.

  • Azure Application Gateway, Firewall, and DNS deployed in multi-zonal configurations for fault tolerance.

  • Auto-scaling capabilities to handle varying load demands.

  • Azure DDoS Protection Plan for mitigating large-scale DDoS attacks.

• Kubernetes (AKS):

  • Core services spread across multiple independent AKS clusters, with the ability to transfer tenants between them without disruption.

  • Resilient control plane provided by AKS.

  • Workloads distributed across multiple nodes in multiple availability zones.

  • Auto-scaling and self-healing mechanisms within AKS.

  • Single-tenanted services for each LFI, with at least 3 replicas per service.

  • Horizontal auto-scaling based on load.

  • Infrastructure-as-code methodologies. Stateless and declarative service configurations for rapid restoration from source code.

• Database (MongoDB):

  • MongoDB database clusters configured as 3-node replica sets.

  • Continuous point-in-time backups and protected snapshot backups.

  • Tolerance for zonal or node failures without data loss or service interruption.

  • Auto scaling of compute and storage based on load, without disruption.

Validation

• Comprehensive Testing:

  • Rigorous testing and QA procedures across the software development lifecycle (SDLC).

  • Manual and automated testing for quality, security, and robustness.

  • Infrastructure-as-code practices for managing and deploying infrastructure.

  • Change review and auditioning in test environments before production deployment.

• Stress Testing and Fault Injection:

  • Infrastructure stress testing to benchmark performance and load capacity.

  • Validation of auto-scaling behaviours.

  • Fault injection techniques to ensure availability during various failure scenarios.

Always-on Monitoring

• Comprehensive Instrumentation:

  • Detailed monitoring of all infrastructure components, including networks, server resources, databases, and service components.

  • Thousands of metrics collected to provide insights into system health and performance.

• Synthetic Monitoring:

  • External monitoring of running services for each LFI.

  • Monitoring of upstream dependencies, such as Ozone Connect.

• SLO Monitoring and Alerting:

  • Real-time monitoring of Service Level Objectives (SLOs).

  • Comprehensive alerting and paging to the Ozone Command Centre.

  • 24/7/365 operational monitoring and response.

  • Proactive trend analysis for early detection and resolution of potential issues.

3.2.3 Policies and Procedures

Ozone API employs best in practice security policies and procedures, including but not limited to:

• Robust HR policies.

• Testing all code for vulnerabilities as part of it’s development lifecycle.

• Proactive monitoring of security events and signals.

• Monitoring and patching all infrastructure operating systems (user devices, servers, etc).

These policies and practices are subject to regular review, assessment and certification, as set out below.

3.3 Compliance and Certifications

3.3.1 In Scope

Ozone API holds the following security certifications:

The FAPI 2.0 certification will be renewed on each major update to the API Hub, up to twice per year. The other certifications and SOC 2 report are each renewed annually.

In addition, the Microsoft Azure Environment used by the API Hub is subject to Core42 Sovereign Controls. These controls provide additional monitoring and assurance around the security of all hosted applications and data. These controls are updated by Core42 regularly and the latest version implemented by Ozone API for each major new release.

3.3.2 Out of Scope

The API Hub does not store or process any card data, hence PCI-DSS compliance is not relevant.

CSA STAR Level 2 is a certification focussed towards general-purpose cloud providers, for example those which offer compute on which you can run arbitrary workloads (Azure, AWS, Salesforce, etc). The Ozone API Hub is a focussed SaaS product, already hosted on CSA STAR certified cloud platforms, in this case Microsoft Azure, which is CSA STAR Level 2 Certified. When combined with Ozone API’s robust ISO/SOC2 controls, this demonstrate sufficient security and governance assurance.  

3.4 Disaster Recovery

The following Disaster Recovery (DR) section outlines the robust resilience measures and recovery procedures implemented for the API Hub service. By adhering to these guidelines, we aim to ensure the continuous availability and reliability of the platform, supporting the critical objectives of the CBUAE Open Finance project.

3.4.1. Recovery Objectives

Due to the Resilience Measures outlined above, failover up to the complete failure of the Azure region would normally be within minutes (if detectable at all).

3.4.2. Recovery Procedures (General)

1. Incident Detection and Assessment:

   • Ozone API Command Centre receives alerts and assesses the severity and scope of the incident.

   • Initial triage to identify the affected components.

2. Failover Procedures:

   • In case of zonal failure, AKS workloads automatically failover to healthy zones.

   • MongoDB replica sets ensure data availability during node or zonal failures.

   • Application gateway and other PaaS services automatically reroute traffic.

3. Data Restoration:

   • MongoDB replica sets provide immediate online data redundancy.

   • Continuous point-in-time backups and snapshots are used to restore data in case of corruption or loss.

   • Regular backup restoration testing ensures integrity of backups.

4. Service Restoration:

   • AKS auto-scaling and self-healing mechanisms restore service availability at the individual service, bank, node and cluster level.

   • Infrastructure-as-code is used to rapidly re-deploy infrastructure components to their desired state if replacement is required.

   • Stateless configurations allow for rapid service restoration.

5. Validation and Testing: