WSO2 Open Banking caters to global open banking requirements. The latest release, version 1.3, focuses on helping banks open up their APIs for external testing. This was brought about by the March 2019 deadline for PSD2 and Open Banking, which requires all banks operating in Europe and the UK to have a sandbox environment ready to open up their APIs securely to third-party providers (TPPs). This blog discusses the new release’s features, improvements, and changes.
From a UK standpoint, the Open Banking Implementation Entity (OBIE) mandates that the UK Open Banking API specification v3.1 should be used for the March deadline. If you look at the revised roadmap, it explains what is required for each deadline based on the bank type, CMA9 or non-CMA9. The API Release Management Policy explains the API specifications that the bank needs to support based on the time it is published.
We considered the following UK standards for the new release:
Europe follows the Berlin Group NextGenPSD2 and STET specifications. However, the region does not have mandated requirements for the March deadline. The new release also includes support for the Berlin Group NextGenPSD2 specification v1.1 and the STET specification v1.4.
In addition, the release includes enhancements to security, user experience, transaction risk analysis, and fraud detection considering future requirements beyond the March deadline.
The complete release notes can be found here.
WSO2 Open Banking comes with three product packs:
A user with a WSO2 subscription can download the WSO2 Open Banking solution via WSO2 Update Manager (WUM). As WSO2 Open Banking is closed source, it is not publicly available to download.
The wso2-obam pack contains API management-related components including the key generation, consent management, and authentication (identity and access management) components.
The new v1.3.0 release introduces wso2-obbi - WSO2 Open Banking Business Intelligence. The business intelligence component should be purchased to utilize transaction risk analysis, fraud detection, business intelligence, monitoring, and reporting capabilities.
The wso2ob-am-analytics and wso2ob-ei components have been removed from the open banking solution as the wso2-am-analytics and wso2-ei products offer the same functionality. So hereafter WSO2 Open Banking will not maintain or improve the features of those components.
If we consider the open banking requirements for different banks and regions, the main requirements are covered in the Open Banking API Manager and Open Banking Key Manager components. Our standard deployment contains wso2-obam and wso2-obkm, as shown in the below image.
The Open Banking API Manager component provides API management capabilities. It needs to connect with the internal banking systems to expose the required data and services to external third parties. The Open Banking Key Manager component provides API security, strong customer authentication, consent management, and user management capabilities.
A bank may want to see how their APIs are performing, provide analytics to third parties to see how their applications are performing and make decisions based on those to improve the whole open banking ecosystems. To do this they need to download wso2-am-analytics and integrate with the standard deployment as shown below.
When exposing internal bank data and services via APIs to third parties, open banking solutions need to integrate with the internal banking system. If that internal bank system has its own API, we can directly map those with the external APIs. However, you may need to add an additional layer that can transform different message formats and protocols. In such cases, banks can integrate the WSO2 EI Integrator Profile.
Some banks may want to have business workflows for certain functionality. For example, when a third party signs up with the open banking solution, the bank wants to take them through the approval process where someone goes through all the third party information and provides the approval to access the exposed APIs. Another use case involves the bank wanting to introduce the approval process when a third party wants to access a production API after testing in the sandbox APIs. In that kind of situation where a bank wants to introduce human interaction, it can be achieved by introducing the WSO2 EI Business Process Profile to the standard deployment.
Both these scenarios (integrator and business process profiles) are shown in the image below.
Apart from the basic compliance requirements that are required for the March deadline, there are more requirements mentioned in the Regulatory Technical Standards (RTS) and guidelines published by the European Bank Authority (EBA). Transaction risk analysis (TRA) and fraud detection gets the highest priority among those requirements because once the banks open up their APIs to external parties, there’s a high chance for fraud to happen.
That’s why WSO2 Open Banking now provides a new component - Open Banking Business Intelligence (OBBI), which analyzes the transaction risk and identifies fraud situations. The OBBI component can be integrated with the standard deployment as shown below. If any bank has its own TRA and fraud detection systems, that can also easily be integrated with the standard deployment.
This OBBI component is built on top of the Siddhi engine, so this component can also provide business insights, and reporting and monitoring capabilities. If a bank wants to build their own dashboard, that is also supported through this component.
The OBIE has implemented a test suite to help Account Servicing Payment Service Providers (ASPSPs), TPPs and solution providers to check that they have implemented each part of the OBIE standard correctly, i.e. Read/Write APIs, Security Profile, Operational Guidelines, and Customer Experience Guidelines. When the implementers use these tools to self-attest, then OBIE validates and publishes the conformance certificate. These certificates can be used by implementers as evidence to all parties including regulators that they have followed the standard correctly.
We are pleased to announce that WSO2 Open Banking OBIE Security Profile Conformance Certified. You can see that WSO2 is listed as an OBIE Security Profile Compliant solution here.
If you wish to run the OBIE security profile conformance suite against the WSO2 Open Banking solution, this document provides the instructions for your reference.
Another great improvement that came with WSO2 Open Banking v1.3.0 is the availability of public documentation. Here are some of the important links to WSO2 Open Banking documentation.
All banks in Europe and the UK were required to have their open banking setups ready for external testing by March 2019. If your bank couldn’t meet that deadline yet, or is still struggling to select the required open banking platform, WSO2 can help you. Here are some useful resources:
Our next target is to help banks achieve the regulatory deadlines that fall in September. This includes providing a production system available for third parties to go live with their third-party applications.
We are planning another release before September to ensure banks have time to upgrade their solution on time. That release will contain the required implementations of the UK v3.1.1 Specification for banks in the UK and Berlin Group NextGenPSD2 v1.3 Specification for banks in Europe.
Apart from that, we are working towards implementing the Australia CDR Specificationtoo.
WSO2 Open Banking is purpose-built for global open banking. It is built to align banking and regulatory needs with technology infrastructure and domain expertise to fully satisfy the technology requirements for PSD2 and Open Banking. If you missed the March 2019 deadline to open up APIs, we can help. The solution roadmap focuses on several enhancements to the solution especially those in line with meeting the September 2019 deadline for the RTS. If you’re exploring open banking or you’re already knee deep in a PSD2 compliance project and require a technology partnership, drop us a note at [email protected].