/
Problem Resolution (Draft Version 1.0)

Problem Resolution (Draft Version 1.0)

Overview

This section outlines the policies, procedures, and systems that an ASPSP should create and embed in order to demonstrate effective problem resolution for OBSPs using their dedicated interface and test facility. It focuses on issues that specifically impact OBSPs.

An ASPSP must submit information to the Open Banking Governing Entity which demonstrates they have the applicable systems and procedures in place for tracking, resolving, and closing problems, as well as an explanation of problems which were not resolved within its relevant service level targets. The explanations should include problems which occurred within the context of both testing and production of the dedicated interface.

Procedures, Processes, and Systems for Problem Resolution

Effective Resolution of Problems

An ASPSP should create documentation to clearly outline the policies, processes, and systems it has in place for problem resolution and its respective service level objectives. This framework should enable the effective resolution of OBSP issues and therefore cater for problems that relate specifically to an OBSP’s use of an ASPSP’s dedicated interface and test facility.

ASPSPs must ensure any such framework for OBSPs has service level targets at least as high as the service levels for resolving problems with its own customer interface (e.g., web and/or mobile banking apps).

When an OBSP encounters a problem with an ASPSP’s dedicated interface, it could have a direct impact on an OBSP’s ability to provide its service, which in turn has the potential to cause:

  • Loss of Business

  • Reputational Risk

  • Additional Resource Requirement

  • Negative Outcomes for Customers

Accordingly, it is important that an ASPSP’s problem resolution framework resolves problem efficiently to enable OBSPs to provide a continuous, uninterrupted service to their customers. An ASPSP should review its existing problem resolution framework and associated service level targets for its dedicated interface and consider if, in certain circumstances, it needs to go beyond the service levels for resolving problems with its own dedicated interface.

ASPSP’s must communicate to the OBSPs in case of any change/event that can affect the services offered by the OBSP. The detailed procedure on communication of any change/event has been detailed in the Change Management section.

Online Participant

ASPSPs should provide FAQs, which address areas that may be specific to OBSPs such as technical advice or test facility guidance. They should also consider a means of identifying recurring questions or user-error issues so these can be collated into FAQs to support the early resolution of problems.

Problem resolution documentation, FAQs, contact details, opening times and out of hours support should be published and easily accessible in one collective area on the ASPSP’s website.

Ticket Management Process

ASPSPs must ensure they have a functioning ticket management system which 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 which specifically impact OBSPs. The system for raising and reporting on tickets should be transparent in order to fully inform users and uphold trust across the ecosystem.

The ticket management process should categorise problems as and when they are reported and track the progress of each ticket until the point of closure. It should also enable an ASPSP to identify which problems related to the operational use of the dedicated interface and the test facility. Where test facility problems have been raised by OBSPs and resolved, the ASPSP should design the dedicated interface to the satisfaction of OBSPs.

Tickets

All tickets should be given priority ratings and these ratings should factor in the severity of the impact on the OBSP. ASPSPs could consider incorporating the following impact assessment into their ASPSPs ticket management process. Ticket fields should include mandatory and drop-down options to assist in efficiently identifying which level of support an OBSP requires. This should include a field to allow the OBSP to select an initial priority rating. The tickets should be detailed and structured so that they contain sufficient granularity that the ASPSP is able to allocate appropriate priority level.

When considering and reporting problems related to testing, ASPSPs must take into account the categories, problems raised in functional testing and ensure problems raised within these categories are resolved within the relevant service level targets, as well as record any problems which are not resolved within those targets. ASPSP should also the use this process to identify problems raised in live use of the dedicated interface.

Recommended ticket fields include:

  • Name of reporting organization

  • Name and contact details of contact at the reporting organisation

  • Date when the ticket was raised

  • Problem type/category

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

  • Name of ASPSP and brand (if applicable)

  • ASPSP environment impacted (test or production)

  • Severity, as defined by OBSP (if applicable)

  • Severity, as defined by ASPSP

  • Log of all updates from OBSP and ASPSP

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

  • Date when the ticket would be closed

Problem Mitigation and Escalation Process

The SLAs for problem mitigation and escalation should be defined by ASPSPs at an individual level. 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 and therefore ASPSPs should create an accessible web page or communication tool to give advance notice of relevant information to OBSPs.

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

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

Report Generation and Audit Trail

ASPSPs should also regularly review any outstanding tickets that have exceeded their SLA and prioritise those with the greatest impact on the OBSP. 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 produced 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 audit trail of effective problem resolution.