6 Aug, 2019 | 3 min read

WSO2 Open Banking 1.4: Support for Global Open Banking Standards

  • Amalka Subasinghe
  • Technical lead - WSO2

WSO2 Open Banking supports global banks with their PSD2 compliance and open banking journeys. The latest release of WSO2 Open Banking 1.4 meets the technical and regulatory requirements for two global Open Banking API Standards - Open Banking UK API v3.1.1 and NEXTGEN Second Payment Services Directive (PSD2) API v1.3 standards.

This release also focuses on helping European and UK banks meet the requirements of the Regulatory Technical Standards (RTS). The RTS requires banks to have several technical features and standards applied to their Open Banking APIs including Transaction Risk Analysis, eIDAS support, and data reporting among others.

What Can Open Banking Developers and Architects Expect From WSO2 Open Banking 1.4?

Support for Open Banking UK API v3.1.1

Accounts, Payments, and Confirmation of Funds

  • Provide support for the UK v3.1.1 read-write API standard which mandates how Accounts, Payments, and Confirmation of Funds requests are handled.

Dynamic Client Registration DCR v3.2

  • This API mandates the mechanism where a Third Party Provider (TPP) client should be able to register with the Account Servicing Payment Service Provider (ASPSP) using DCR.

Support for Berlin API v1.3

Accounts, Payments, Confirmation of Funds

  • Provide support for the Berlin API v1.3 NEXTGEN PSD2 API standard which mandates how Accounts, Payments, and Confirmation of Funds requests are handled.

Authorization endpoint support

  • Authorization endpoints satisfying the NEXTGEN PSD2 API requirements. This API supports explicit authorization sub-resources and payment cancellation authorization.

Other Features

Transaction Risk Analysis (TRA)

  • TRA for both UK and Berlin specifications. This helps Improve the user experience of exempting strong customer authentication.

eIDAS Support - RTS

Provides support for:

  • eiDAS Qualified website authentication certificate (QWAC) validation in the transport layer.
  • eiDAS Qualified Electronic Seal (QSeal) certificate validation for message signature.

Management Information Reporting for Open Banking UK API standard

  • Data reporting functionality based on UK specification. This data is used to generate reports required by the standard. These reports cover various specification mandated authentication and API statistics.

Ability to restrict PS256 as the signing algorithm for incoming requests which contain signed Json Web Tokens (JWTs) as required by the UK specification.

Fraud Detection Requirements based on RTS. This includes Rule-Based Fraud Detection and dashboards to monitor fraudulent transactions.

An Enhanced User Experience for Open Banking Developers

WSO2 Open Banking 1.4 improves developer interaction with the various technical and regulatory components of the solution through the following:

Swagger based request payload validations - Account and Payment

  • The payload validation is moved to swagger based validations instead of manual validations. This helps increase the effectiveness and completeness of the validations.

Re-architecture of authentication endpoint

Re-architecture of the authentication endpoint to cater to the following requirements:

  • Externally deployable authentication endpoint. This is required when banks want to deploy the authentication endpoint in a separate environment.
  • Extendable consent retrieval and consent persist steps. Enables banks to conduct their own customizations to the flow seamlessly without having the need to re-write parts of the authentication flow.

Transaction Risk Analysis (TRA) implementation moved to Open Banking Business Intelligence

  • The TRA implementation which used to function as java based classes, is moved to siddhi (OBBI) as siddhi apps. This increases the efficiency of the TRA component.

OBBI is built with API Analytics incorporated so that OBBI users don’t have to deploy a separate APIM analytics node

Ability to extend key manager extension to add authentication steps based on Strong Customer Authentication (SCA) requirements

  • Different customers use different authentication steps in the authentication process. This feature reduces the effort taken to add an authentication step.

Introducing new REST APIs for operations in WSO2 Open Banking

  • API endpoint to retrieve Third Party Provider (TPP) information.
  • API to retrieve data to be displayed on a consent page.
  • API to persist consent data from a consent page.

In addition to these developments, the solution is now compliant with the OBIE Security Conformance Suite v3.1.0 and Functional Conformance Suite v1.1.17 versions.

Why Choose WSO2 Open Banking?

WSO2 Open Banking is purpose-built to align technology infrastructure and regulatory needs with domain expertise to fully satisfy technology requirements for open banking. The solution roadmap focuses on updates that keeps the solution on par with global Open Banking API standards. This helps banks using WSO2 Open Banking to easily migrate to these newer versions, without having to spend cycles on implementing version updates themselves.

Our webinar about the latest release will take you through an in-depth discussion on how WSO2 Open Banking 1.4 can expedite your compliance journeys and prepare you for the RTS deadline.

Another key advantage WSO2 Open Banking is its flexible architecture that meets technology use cases extending beyond open banking. Built on top of a unified integration platform, it helps banks extend open banking initiatives to any API-first digital initiative.

For more information on how WSO2 Open Banking can help your open banking journey, please visit our landing page.

Looking for more helpful resources? Here they are:

Documentation for WSO2 Open Banking

A Deep Dive of Transaction Risk Analysis for Open Banking and PSD2

Successful Third Party On-boarding for Open Banking UK

Fraud Detection: Making Open Banking a Safer Place

Strong Customer Authentication and Dynamic Linking for PSD2