The shift to digital services has accelerated since 2020, improving the potential of Open Banking payments to become a viable alternative to card payments. Cumulatively, over 26.6 million Open Banking payments had been executed by the end of 2021. There was a 500% increase in that year alone.
The user experience will be key to the wider adoption of Open Banking payments—specifically, how integrated and frictionless their journey is. Customers expect to make a payment and continue their day, not giving a second thought about the success or failure of their transaction.
If the transaction does fail, customers expect to be told why and how to resolve the problem. However, despite widespread adoption of Open Banking standards, error messages across Open Banking APIs vary, making it difficult to find the root cause of payment failures and resolve them.
What causes inconsistency in error messages?
Open Banking standards are regularly reviewed and updated; the Open Banking implementation entity (OBL) released a new version in early April 2022. The API specifications outline what account servicing payment service providers (ASPSPs) must do so that third-party providers (TPPs) can connect efficiently and securely on behalf of a customer. The specifications also outline the expected error payload structure (see the screen capture below), including mandatory and standardized fields.
Open Banking ecosystem members can assess their compliance, including the structure of their error messages or payloads, using OBL’s functional conformance test suite (FCS). However, FCS test cases mainly simulate successful transactions. There is not much testing of error responses, because simulating failed request conditions (such as using unsupported values, mimicking a timeout or invoking a server error) could compromise the ASPSP’s live systems and services.
Despite similarities with other Open Banking regulatory standards (for example, Berlin Group, Consumer Data Rights and Open Banking Brazil), the standardized HTTP status codes and error messages defined in the OBL standard are not comprehensive enough, so optional fields often need to be used to provide further information. In many cases, the optional fields are not returned or provide non-specific information.
There are several other reasons why an error message may not be as useful as a TPP expects. First, locating the root cause of an issue within legacy architecture and relaying that information in real time is challenging. In some cases, it is nearly impossible to uncover the origin of an error due to the siloed nature of traditional banking systems and their often-finite logging capability.
There are also legal limits to the information that can be disclosed to a TPP or customer. For example, a payment may fail because the customer’s account is suspended or under investigation. Banks typically do not disclose this information to customers to avoid “tipping off” any parties during an ongoing investigation (as required under the Proceeds of Crime Act 2002). The information will also be kept from TPPs, to reduce the risk that they could inadvertently alert a customer. In addition, GDPR compliance may require a customer’s consent before account-specific information is disclosed to a TPP.
What impact is this having?
Inconsistent and unclear error messaging has an impact on both TPPs and customers. The different response structures across APIs make parsing the information difficult and increase the cost of maintaining custom coding. Additionally, responses are rarely clear about why a request has failed. This forces TPPs to seek out further clarification. In the meantime, the customer has no idea why their payment has failed or what to do next.
A good error message allows developers to make their way out of the failed call.
Customers are more likely to abandon payments journeys if they encounter unknown errors or extra steps during a transaction (for example, being asked to authenticate their ID again after the payment fails). If errors cannot be resolved quickly, the customer may lose confidence in the payment method and not use it again.
How can we address key challenges?
Should the OBL standard be redefined to require ASPSPs to disclose further information through new, mandatory, specific payload attributes? Perhaps not.
The scope of the current standard is sufficient and considers the other regulations ASPSPs must adhere to when they share customer data. It would take a lot of work for ASPSPs and TPPs to implement and accommodate new attributes or payload structures. Instead, it would be simpler to optimize the standard with more specificity and standardization to address some of these challenges.
Here are some ways this could be achieved:
- Optimize existing attributes to return more concise, standardized information:
- Classify error message codes according to endpoints, rather than returning the same codes across all API endpoint categories. This supports more precise and consistent error reporting using a pre-existing attribute, as opposed to creating an additional attribute.
- Standardize the type of information returned in the error message field. For example, where there is an issue with missing or invalid data, the field that the error refers to should be returned.
- Increase test coverage in the FCS:
Implement more test cases that assess failure scenarios. This will make testing more robust and provide insights into how errors are handled across ASPSPs. This approach would also help identify gaps in validation logic, thus making it easier for ASPSPs to improve their service. - Monitor compliance test results:
While only certain fields are mandatory or used to assess compliance, maintaining records of all data submitted to the FCS could help identify gaps and areas where the standard could be improved. For example, analysis of optional attributes could be used to improve standardization or move attributes from optional to mandatory.
As payments become more deeply embedded across industries and platforms, the customer experience will need to be a priority to ensure that Open Banking payments are widely adopted. This includes making it easier for customers to resolve issues when something goes wrong with a payment.
Contact us to find out how your business can get ahead of the curve on digital payments in Open Banking and be a market leader.
