1. Introduction

1.1 Objectives

This Testing and Certification Framework is designed to ensure that LFIs and TPPs provide Open Finance solutions which are in strict conformance to the Standards.

• For LFIs, this is to ensure that the APIs they expose are consistent, thereby removing the complexity and friction for TPPs in connecting to and consuming these APIs.

• For TPPs, this is to ensure that they connect correctly to the APIs exposed by LFIs, thereby reducing (and where possible removing) the possibility of TPPs raising complaints or disputes against LFIs regarding the consistency of their API implementations.

The requirements below set out what each LFI and TPP must do in order to test and apply for certifications in order to prove their conformance to the Standards.

1.2 Requirements

1.2.1 Summary of Requirements

Wherever possible, the Open Finance Platform (OFP), and in particular the API Hub, will enforce conformance and thereby reduce the testing and certification requirements for LFIs and TPPs. However, these requirements are summarised as follows.

LFIs and TPPs must:

• conduct appropriate testing and obtain the relevant certifications (as set out below) prior to ‘go-live’ for each version of the Standards they implement;

• when testing and obtaining certifications in a Pre-Production Environment, warrant that their Pre-Production Environment mirrors their Production Environment, having the same architecture, network elements, software versions and customer experience elements;

• conduct this testing and obtain a separate complete set of certifications for each brand/application, e.g.

  • for LFIs, in cases where the LFI has a number of brands and/or customer segments, each with separate web or mobile apps; or

  • for TPPs, in cases where the TPP has more than one end customer facing web or mobile application;

• conduct penetration testing (as required below) using a reputable (with the appropriate industry recognized accreditations) independent third party, preferably with expertise in FAPI, OAuth 2.0, JWT vulnerabilities, and familiarity with the UAE regulatory landscape.

LFIs and TPPs may conduct stress testing (as required below) using their own internal resources and tools.

LFIs must:

• conduct Functional Testing (using Ozone Connect Test Suite and Postman Collection) in their Pre-Production Environment prior to promotion to Production Environment and again prior to go-live;

• submit and obtain CX Certification for their web and/or mobile applications prior to prior to promotion to Production Environment;

• perform penetration and stress testing (to meet all NFRs in the Standards) before go-live; and

• engage with TPPs to conduct Live Proving immediately after promotion to Production Environment before go-live.

TPPs must:

• carry out testing and obtain FAPI, Functional and CX Certifications using their production web/mobile app(s) connected to the API Hub Sandbox, in order to be granted access to the API Hub Production Environment;

• perform penetration testing before go-live; and

• engage with at least one LFI to test all relevant endpoints (pertaining to business model) in the LFI’s Production Environment before go-live.

Commercial Applicability
All testing, certification, live and production proving activities occur in a non-commercial context.
No API Hub fees, LFI-to-TPP fees, TPP-to-LFI commissions, or other commercial charges shall be applicable or payable until the relevant participant has achieved go-live status.

1.2.2 Exit Criteria for Each Stage

1.2.3 Retesting and Renewal

LFIs and TPPs must retest and renew their certification:

• every time they introduce a new version of the Standards;

• every time they make any material changes to their infrastructure and/or Open Finance application API, web or mobile interfaces; and

• if requested from time to time at the discretion of the Nebras Open Finance Company (Nebras).

1.3 Ongoing Monitoring

LFIs and TPPs will be subject to ongoing monitoring and enforcement action in case where they introduce any changes which would render a previously obtained certification invalid and where they fail to retest and/or renew their certification.

This includes cases where an LFI or TPP provides test results and/or obtains a certification in a pre-production environment which behaves differently from their production environment.

1.4 Roles, Responsibilities, Process and Fees

The following table summarises each component and sets out the responsibilities, certifying body, certification process and fees for each.

2. LFI Testing and Certification

2.1 LFI FAPI Certification

The OpenID Foundation (OIDF) have developed a Conformance Suite for testing and certifying the security scope of Authorization Servers (OpenID Providers - OPs) and Data Receiving Applications (Relying Parties - RPs). This tool is currently being enhanced by the OIDF to include a set of Financial Grade API (FAPI) 2.0 security tests in accordance with the UAE FAPI 2.0 security profile set out in the Standards.

As and when this is made available, the OFP itself will obtain certification as an OpenID Provider (OP) in accordance with the UAE FAPI 2.0 security profile. The OFP will renew this certification during the implementation of each major new version of the Standards.

2.2 LFI Functional Testing

The OFP includes a number of testing tools which will enable LFIs to test their integration with the OFP during development and prior to any go-live.

2.2.1 Process

The testing process is summarized below:

• Prior to updating their Production Environment in the API Hub, LFIs must run two sets of tests in their Pre-Production and Production Environments:

  • Using the API Hub Testing Tool to test their integration with the API Hub.

  • Using the Postman Collection to test that a TPP can successfully call all API endpoints defined in the Standards. LFIs can either do this using their own TPP credential from the Trust Framework, or they can partner with a TPP to run these end to end tests. Tests must be executed for each API endpoint relevant to LFI deployment as set out in this template:

• Once all tests have been passed, the LFI must submit evidence (following the steps in p.2.2.2 , along with the above functional checklist) to Nebras, so that Nebras can validate.

• Nebras will then confirm acceptance for the LFI to exit Pre-Production.

• LFIs must rerun both sets of tests in their Production Environment and resubmit test reports to Nebras prior to go-live.

• LFIs must rerun both sets of tests and resubmit results whenever they implement any new version of the Standards or whenever they make any substantive changes to their integration with the API Hub. These retests must be conducted in both their Pre-Production Environment and again in their Production Environment before go-live each time.

2.2.2 Ozone Connect test results submission

The Ozone Connect Testing tool generates reports to verify LFI implementation correctness against the Open Finance API Hub specifications. Steps below outline approach for submitting these reports for the Nebras assessment.

• The Ozone Connect Testing tool, by default, covers all possible test cases for the API Hub endpoints. LFIs must submit reports only when all functionality relevant for them has been successfully tested, providing one HTML report per endpoint.

• Along with the report, LFIs must explicitly state:

  • Which segment(s) / Account type(s) they support: Retail, SME, Corporate, or a combination.

  • Which Account subtypes they support.

• LFIs are expected to have resolved all raised issues with their implementation before running the tests and submitting the report.

• Reports should not contain any failed or skipped test cases due to unresolved implementation issues.

• For the endpoints that are postponed for implementation LFIs should proactively use Testing Tool Regular Expressions in order to skip such test cases, and avoid Failure status.

• If, despite best efforts, some test cases are still failed or skipped, LFIs must provide justifications for each case. These justifications must be presented in a table format as in the following example:

2.2.3 Fees

N/A

2.2.4 Support

Please contact support@nebrasopenfinance.ae

2.3 LFI Customer Experience Certification

Each LFI must ensure conformance to the Customer Experience (CX) requirements in the Standards for each use case, for each screen in their Open Finance consent flow and their Open Finance consent dashboard. Each of these screens must meet all the mandatory requirements set out in the Standard.

2.3.1 Process

The certification process is summarised below:

• LFIs must submit a certification request using this template: (Bank’s delivering to the Standards V2.0 and Standards V1.2 should reference the following CX documents ).

• LFIs must use a separate copy of this template for each brand/segment (e.g. retail v sme v corporate) and for each interface (web v mobile).

• For each template, LFIs must complete the required fields on the first tab and then paste in the relevant screen grabs on each subsequent tab.

• All screens must be in English language.

• These screens can be from the LFI’s Pre-Production Environment or their Production Environment. However, if LFIs submit screens based on their Pre-Production Environment, they must confirm and warrant that these screens are an exact match for their Production Environment.

• Nebras will validate that these screens meet the stated requirements in the Standards and require the LFI to update these screens and resubmit screen grabs if required.

• As soon as all screens meet the requirements, Nebras will issue a certification to the LFI.

• LFI CX Certification is an exit criteria from Pre-Production.

2.3.2 Fees

N/A covered by OFP Fees.

2.3.3 Support

Please contact support@nebrasopenfinance.ae

2.4 LFI Live Proving

Prior to Live Proving, LFIs must:

• Conduct Penetration Testing and address/fix all critical, high and medium priority issues, providing evidence no issues of this priority remain open to Nebras.

• Conduct Stress Testing to demonstrate that all Non-Functional Requirements (NFRs) meet the requirements of the Standards and provide evidence of such to Nebras. These NFRs must be achieved at a volume of API calls that will vary according to each LFI’s customer base; these volumes will be agreed individually between each LFI and Nebras.

LFIs must engage with TPPs to validate and test their APIs in their Production Environment to provide assurance to Nebras that their APIs operate fully in accordance with the Standards in real-life scenarios. This “Live Proving” must be conducted as follows:

• LFIs must engage with at least one TPP to test and validate all API resources/endpoints in the LFI’s Production Environment.

• LFIs may provide the TPP with test user accounts in Production and/or agree with the TPP to use volunteer users (e.g., staff, friends, and family) to enable end-to-end testing.

• Nebras will engage with the TPP(s) to gather evidence that the testing covers the required resources and validates compliance with all Standards requirements.

• This testing must be conducted immediately after each new deployment into Production and prior to go-live, including the release of new or updated API resources.

2.4.1 LFI Self-Testing in Production

In addition to testing with external TPPs, an LFI may conduct Production end-to-end testing (acting as the TPP) in order to ensure the safe, stable, and reliable rollout of new or updated resources and to confirm compliance with the Standards.

Where an LFI performs such self-testing, the LFI must demonstrate that the following governance and control principles are strictly enforced:

Access Management

• Dedicated testing credentials (acting as a TPP) must be used.

• Credentials must follow least-privilege access principles.

• All testing credentials must be revoked immediately after testing is completed.

Segregation of Duties

• Separate teams must be used for testing (acting as a TPP) and for core LFI production operations.

• There must be no overlapping access to production credentials between these teams.

Environment Isolation

• All LFI production testing must be limited to approved testing accounts only.

• Testing activities must not impact real customers outside the defined testing perimeter.

Monitoring & Logging

• All production testing activities must be continuously monitored and logged.

• Automated alerts must be configured and triggered for:

  • Any activity involving non-test accounts;

  • Any unusual access outside of what would is newly released and needs to be tested.

  • Any breach of approved testing scope.

Internal Audit & Review

• All self-testing activities must undergo independent internal review.

• Testing credentials, test accounts, scope, and testing methods must be periodically reviewed and formally documented.

• Records of such reviews must be available and may be shared with CBUAE or Nebras upon request.

Legal Liability

• The LFI must formally acknowledge and accept full legal and operational liability for all production self-testing activities by signing the below: “Acknowledgment and Indemnity Undertaking”

Open

• This also ensures that any incidents, breaches, or deviations affecting real customers that arise from self-testing must be:

  • Immediately escalated to Nebras and CBUAE; and

  • Remediated in full by the LFI without delay.

The Open Finance commercial model does not apply to any self testing done by LFIs. All production self testing API usage is performed on a non-commercial basis.

3. TPP Testing and Certification

3.1 TPP FAPI Certification

As stated above, the OIDF’s Conformance Suite has been enhanced by the OIDF to include a set of Financial Grade API (FAPI) 2.0 security tests in accordance with the UAE FAPI 2.0 security profile set out in the Standards.

Each TPP must obtain a Relying Parties (RP) certification for their application(s) in accordance with the UAE FAPI 2.0 security profile. TPPs must renew this certification during their implementation of each major new version of the Standards.

3.1.1 Process

For running the conformance tests, please check the documentation issued by the OIDF:

• How to run conformance tests for FAPI RP

• Access the OIDF conformance suite

• Conformance Suite Repository

To request certification from the OIDF, TPPs should consult the instructions at the following address: https://openid.net/how-to-certify-your-implementation/ .

TPPs must inform Nebras immediately on receipt of a FAPI Certification from OIDF. This is an exit criteria from the API Hub Sandbox.

3.1.2 Fees

The price table for FAPI certification is available at: https://openid.net/certification/fees/.

The fees for each certification are fixed and paid directly to the OIDF. Please note, these fees are significantly reduced for OIDF members. Therefore, it may be of interest for some institutions to join the OIDF. Below, we present some important information that can assist in the membership process.

• The membership costs follow the OIDF table which can be found at: https://openid.net/foundation/members/registration.

• To join, the institution must proceed directly through the OIDF website at: https://openid.net/foundation/members/registration.

• The benefits of becoming a member, as well as further information, can be accessed at: https://openid.net/foundation/benefits-members/.

3.1.3 Support

If you have questions about the execution of conformance tests or the certification process, please contact the OIDF by email at certificate@oidf.org.

To report possible bugs or necessary changes, please open tickets at https://gitlab.com/openid/conformance-suite/-/issues/new.

3.2 TPP Functional Certification

Each TPP must ensure they can correctly call the APIs defined in the Standards for each use case relevant to their Open Finance license application.

3.2.1 Process

The certification process is summarised below:

• TPPs must access the API Hub Sandbox and execute API calls for each API endpoint relevant to their use case as set out in this template: .

• TPPs must then submit a certification request using this template.

• If the TPP has more than one application, the TPP must use a separate copy of this template for each separate application.

• For each template, the TPP must complete the required fields on each tab, i.e.

  • Bank Data

  • Bank Service Initiation

  • Insurance Data

• However, TPPs only need to complete the tabs relevant to their use case (e.g. if the TPP does not offer insurance services then they do not need to make calls to the Insurance Data endpoints, nor complete this tab).

• Nebras will validate that the TPP has made successful API calls for each relevant use case and require the TPP to retry if required.

• As soon as all APIs have been called successfully, Nebras will issue a certification to the TPP.

• This is an exit criteria from the API Hub Sandbox.

3.2.2 Fees

N/A covered by OFP Fees.

3.2.3 Support

Please contact support@nebrasopenfinance.ae

3.3 TPP Customer Experience Certification

Each TPP must ensure conformance to the Customer Experience (CX) requirements in the Standards for each use case relevant to their Open Finance license application, for each screen in their Open Finance consent flow and their Open Finance consent dashboard. Each of these screens must meet all the mandatory requirements set out in the Standard.

3.3.1 Process

The certification process is summarized below:

• TPPs must submit a certification request using this template: .

• If the TPP has both a web and mobile application, then they must submit screens for each, otherwise they only need to submit screens for the supported application

• For each template, TPPs must complete the required fields on the first tab and then paste in the relevant screen grabs on each subsequent tab.

• All screens must be in English language.

• Nebras will validate that these screens meet the stated requirements in the Standards and require the TPP to update these screens and resubmit screen grabs if required.

• As soon as all screens meet the requirements, Nebras will issue a certification to the TPP.

• This is an exit criteria from the API Hub Sandbox.

3.3.2 Fees

N/A covered by OFP Fees.

3.3.3 Support

Please contact support@nebrasopenfinance.ae

3.4 TPP Live Proving

Prior to Live Proving, TPPs must conduct Penetration Testing and address/fix all critical or high priority issues and provide evidence of such to Nebras.

TPPs must engage with at least one LFI (see buddying process below) to validate and test that their application(s) work successfully with the LFI’s Production APIs to provide assurance to Nebras that their app is working fully in accordance with the Standards in a real life scenario. This ‘Live Proving’ must be conducted as follows:

• TPPs must engage with at least one LFI to test and validate they can successfully call all API resources/endpoints relevant to their business model in the LFI’s Production Environment.

• TPPs must use volunteer (e.g. staff, friends and family) users/accounts/policies at an LFI to enable end-to-end testing. These should be established in advance and the TPP must notify the LFI of these users in before live proving commences. LFIs may also provide the TPP with test user accounts from their Production Environment.

• TPPs must provide evidence to Nebras of such testing, so that Nebras can validate and approve the TPP app meets all requirements in the Standards.

• This testing must be conducted prior to go-live, for each major new version of the TPP app and/or the implementation of any new version of the Standards.

4. Production Proving Phase

4.1 Buddying Phase

In this phase, a "buddying" process will be used to pair up TPPs and LFIs to ensure their systems align with each other’s functionality and data expectations. This will be administered by Nebras. Each TPP must work with their assigned LFI to ensure the integration is functioning as expected in a production environment. The Production Proving Phase remains non-commercial, API Hub fees, LFI-to-TPP fees, TPP-to-LFI commissions, or other commercial charges do not apply during live proving , they only apply once go-live approval is granted.

• TPP's Responsibility: The TPP will validate their connectivity to the LFI's system, check the authentication protocols, and ensure that all services are accessible in the production environment. They will test endpoints for their ability to make requests and receive correct responses.

• LFI's Responsibility: The LFI will confirm that it can handle the TPP’s requests, properly mapping data fields and responding with appropriate responses. This includes confirming that the data returned to the TPP is in the correct format and meets quality standards (such as accuracy, timeliness, and completeness).

4.2 Confirmation and Validation

Once the buddying phase confirms that the systems are connected and functioning correctly, a formal confirmation process will be implemented. This will involve a detailed review of the data exchanged between TPPs and LFIs to ensure compliance with required standards.

• Data Quality Assurance: Both parties will assess the quality of the data being exchanged. This includes ensuring that the data provided by the LFI is accurate, complete, and timely. The TPP will test that the data is usable for the intended purposes (such as account information, transaction history, or payment initiation).

• Test Scenarios: The TPP will conduct a series of functional tests, verifying that the data sent by the LFI is consistent with the data expected, ensuring no discrepancies. The tests will cover all use cases and will include error scenarios to verify how the systems handle issues like missing data or failed requests.

• Functional Certification Comparison: During this process, the TPP will compare the current system’s behavior with the certification results from previous functional certification. This will allow them to confirm that the system still meets all the necessary functional criteria. Anomalies or errors should be raised as tickets at the service desk.

• Customer Experience Certification Comparison: During this process, the TPP will compare the published customer experience to that experienced with the LFI. Anomalies should again be raised as tickets at the service desk.

4.3 Data Quality Verification

Throughout the production proving process, it is crucial to ensure that the data quality remains appropriate for its intended use. The TPP will evaluate the following:

• Completeness: All relevant data fields should be filled with the correct information.

• Accuracy: The data received must match the expected values, with no discrepancies or errors.

• Timeliness: The data should be provided within the expected timeframes, ensuring real-time or near-real-time processing where applicable.

• Usability: The TPP will verify that the data provided can be effectively used in the intended business processes, ensuring that there are no issues with interpreting or processing the data.

By ensuring that both the TPP and LFI systems meet these standards, the production proving process will ensure that all services are fully operational before go live.