1. Introduction

When a TPP encounters a problem as a result of an LFI's API service, it could have a direct impact on a TPP's ability to provide its own service, which in turn has the potential to cause:

• Loss of business;

• Reputational risk;

• Additional resource requirement; and

• Negative outcomes for Users.

This section outlines the policies, procedures, and systems that LFIs and TPPs MUST implement in order to deliver effective problem resolution. It focuses on issues that specifically impact TPPs and what LFIs are required to do in order to reduce such impact.

2. Support from LFIs, TPPs and the OFP

2.1 Documentation

2.1.1 Policy and Process for Issue Management

LFIs and TPPs MUST create documentation to clearly outline their policies, processes, and systems they have for problem resolution and their respective service level objectives. These MUST align with CBUAE open finance policies and procedures. This framework should enable the effective resolution of affected party issues and, therefore, cater to problems that relate specifically to a TPP's use of a LFI's API service (production and sandbox) via the OFP. LFIs and TPPs MUST ensure any such framework for another party has service level targets at least as high as the service levels for resolving problems with its own User interface (e.g., web and/or mobile apps). LFIs and TPPs MUST consider the following template as an example of the Policy and Process for Issue Management documentation:

2.2 Ticket Management Process

LFIs MUST ensure they have a functioning ticket management system that enables them to respond to issues and problems raised within clearly defined service level targets. A successful problem resolution framework will enable the efficient identification and resolution of problems that specifically impact the OFP and TPPs. The system for raising and reporting on tickets SHOULD be transparent in order to fully inform users and engender trust across the ecosystem.

The ticket management process SHOULD categorize problems as and when they are reported and track the progress of each ticket until the point of closure. It SHOULD also enable a LFI to identify which problems relate to the operational use of its API Service.

All tickets SHOULD be given priority ratings, and these ratings SHOULD factor in the severity of the impact on the TPP (via the OFP).

LFIs SHOULD consider incorporating the following impact assessment into their LFIs ticket management process. Ticket fields SHOULD include mandatory and drop-down options to assist in efficiently identifying which level of support the OFP requires. This SHOULD include a field to allow the OFP to select an initial priority rating. The tickets SHOULD be detailed and structured so that they contain sufficient granularity that the LFI is able to allocate appropriate priority levels.

Ticket fields SHOULD include:

• Name of reporting organization

• Name and contact details of contact at the reporting organization

• Date ticket raised

• Problem type/category

• Details of the problem, including an indication of the likely impact for the TPP

• Name of LFI and brand (if applicable)

• LFI environment impacted (test or production)

• Severity, as defined by TPP or OFP (if applicable)

• Severity, as defined by LFI

• Log of all updates from TPP, OFP and LFI

• Start time/date the change/fix is anticipated to take effect and the end date/time (if applicable)

• Date closed

2.3 Problem Mitigation & Escalation Process

CBUAE will define Service Levels Agreements (SLAs). There may be cases where a problem cannot be entirely rectified within the SLA. In such cases, workarounds and interim solutions SHOULD be considered and implemented, if possible. Problems like bugs or security issues are likely to impact the wider user group. Therefore, LFIs SHOULD use the provided portal to give advance notice of relevant information to the OFP and TPPs.

Where workarounds or interim solutions are identified, these SHOULD also be shared as soon as possible. The LFI SHOULD decide the appropriate level of detail required for the communication.

Where a ticket exceeds the required SLA, or in the event that a TPP or the OFP does not agree that a problem can be closed, the TPP or OFP SHOULD be informed of the next steps available. This will include an additional point of escalation within the LFI and any other external channels of escalation that the user SHOULD be made aware of. This information SHOULD be available on the LFI's portal, and the LFI SHOULD inform the OFP of the next steps in the event that an SLA is not met.

2.4 Audit Trail

LFIs and TPPs MUST also regularly review any outstanding tickets that have exceeded their SLA and prioritize those with the greatest impact on the TPP. This rationale SHOULD be recorded within the problem resolution policy.

Statistical data on how many problems are logged within different categories of severity and what percentage, if any, were not dealt with within the service level targets SHOULD be available on a regular basis.

The ticket management process SHOULD record the progress of each ticket, including the date on which a problem is raised through to closure. The historical log SHOULD then be used to evidence an effective problem resolution audit trail.