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 TPP issues and therefore cater for problems that relate specifically to a TPP’s use of an ASPSP’s dedicated interface and test facility.

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

• loss of business;
• reputational risk;
• additional resource requirement; and
• negative outcomes for customers.

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

We recommend that ASPSPs use OBIE’s Support Services (see 4.3) to assist with the notification of problems (and any change) that may impact a TPP. Any problems or changes that may impact a TPP will be added to the central noticeboard facility to inform all ecosystem participant

Online Support

ASPSPs should provide FAQs, which address areas that may be specific to TPPs 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 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 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 relate to the operational use of the dedicated interface and the test facility. Where test facility problems have been raised by AISPs, PISPs and CBPIIs and resolved, this can be provided to the dedicated interface has been designed and tested to the satisfaction of TPPs.

Tickets 

All tickets should be given priority ratings and these ratings should factor in the severity of the impact on the TPP. We recommend that ASPSPs consider incorporating the following impact assessment into their ASPSPs ticket management process.

Business critical issue – represents a complete loss of service or a significant feature that is completely unavailable, and no workaround exists (first response SLA – one hour).

Degraded service issue – includes intermittent issues and reduced quality of service. A workaround may be available (first response SLA – four hours).

General issue – cosmetic issues which include product questions, feature requests and development issues in staging environments (first response SLA – 24 hours).​ ​

Ticket fields should include mandatory and drop down options to assist in efficiently identifying which level of support a TPP requires. This should include a field to allow the TPP 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, set out in the EBA Guideline 6.5 as well as, problems raised in functional testing (RTS. Article 30(5)) 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. 

OBIE recommended ticket fields include:

• Name of reporting organisation.
• Name and contact details of contact at the reporting organisation.
• Date ticket raised.
• Problem type/category.
• Details of the problem, including an indication of the likely impact for the TPP.
• Name of ASPSP and brand (if applicable).
• ASPSP environment impacted (test or production).
• Severity, as defined by TPP (if applicable).
• Severity, as defined by ASPSP.
• Log of all updates from TPP and ASPSP.
• Start time/date the change/fix is anticipated to take effect and the end date/time (if applicable).
• Date closed.

Problem Mitigation & Escalation Process

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 TPPs.

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 a TPP does not agree that a problem can be closed, the TPP 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 website and the ASPSP should inform the TPP of the next steps in the event that an SLA is not met.

 Report Generation & Audit Trail

ASPSPs should also regularly review any outstanding tickets that have exceeded their SLA and prioritise 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 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.

OBIE Support

OBIE Service Desk provides participants with a supplementary ticket management process and supports ASPSPs in communicating problems to ecosystem participants via the noticeboard. ASPSPs are recommended to use the OBIE Service Desk which may provide additional evidence of an ASPSP’s effectiveness in resolving problems.

The OBIE Dispute Management System (DMS) is a communication platform that helps organisations to collectively manage enquiries, complaints and disputes relating to PSUs, fairly and effectively. Version 2 of this platform (due in 2019) will allow all enrolled organisations to communicate with each other in a secure and timely manner. ASPSPs are encouraged to sign up to the platform to ensure efficient resolution of enquires, complaints and disputes relating, but not limited to, requests for information or exchange of information, requests for a redress repayment and complaints forwarding.