Open Banking UK

Overview

WSO2 Open Banking is a purpose-built solution for regulatory compliance and supports PSD2. WSO2 Open Banking helps align banking and regulatory needs with technology infrastructures and regulatory expertise to quickly satisfy compliance. This documentation explains the following:

Architecture

WSO2 Open Banking has a technology stack that banks need to become PSD2 compliant and digitally transformed. It is assembled using a componentized architecture ensuring flexibility to meet different technology use cases. Built on top of a unified integration platform. WSO2 Open Banking helps banks become integration agile for any digital initiative beyond compliance.

It leverages five key technology areas critical to a banking infrastructure - API Management, Identity and Access Management, Integration, Analytics and Business Insights, and Fraud Detection bundled together to form a componentized architecture. This gives the flexibility to reuse existing infrastructure, and banks only need to obtain the components that are not available in their current infrastructure.

Modules

WSO2 Open Banking contains the following modules in the solution:

API Management

The WSO2 Open Banking API management component allows banks to securely expose data to third parties via APIs. This enables banks to grant the TPPs with access to customers' account data and the ability to initiate payments with the customers' consent. It supports a fully-fledged API lifecycle management functionality along with version management.

API publishers can publish APIs and once the client registration is completed, API consumers can subscribe to published APIs and use them in their banking applications. API Management module supports token validation, scope validation, and fine-grained access control ensure API security that prevents unauthorized API calls.

Identity and Access Management

The WSO2 Open Banking identity and access management component enables comprehensive security mechanisms to prevent unauthorized access to APIs and secured data.

The Strong Customer Authentication (SCA) module enables banks to authenticate the customers who are requesting to access account data via an AISP and the customers who are requesting to initiate a credit transfer via a PISP. Once authenticated, the user Consent Management module facilitates banks to obtain the customers' consent to proceed with the initiation request. To improve the user experience and reduce the friction between the bank and the customer/PSU, the Transaction Risk Analysis (TRA) module identifies the scenarios where SCA is necessary and feeds that information to the adaptive authentication module. The adaptive authentication module thereby adjusts the authentication strength and enforces SCA only when it is necessary.

Integration

The WSO2 Open Banking integration component provides required integration points to integrate with core banking systems, banking applications, and any other required third-party systems including legacy systems.

Analytics

The WSO2 Open Banking Analytics component enables monitoring and recording of API-level usage activity to ensure that the API owners have full awareness of the APIs, applications, and subscriptions. It also supports business KPI dashboards with business intelligence and insights on usage trends as well as custom business insights on the account and payment flows. The decision-makers of banks can use these statistics to align the business to better suit the customer needs and ultimately increase profits. The configurable alerting module enables informing the necessary parties of abnormal behaviour, e.g., API failures, a sudden increase in the response time of APIs, and a change in the API resource access pattern.

Transaction Risk Analysis

Transaction Risk Analysis is a method that observes the counterparties and attributes involved in a particular transaction to prevent, detect and block possible fraudulent behaviour. PSD2 has additional requirements for minimizing these threats of fraudulent actions that have been on the rise with the advent of new technology. To maintain the balance between user experience and Strong Customer Authentication, some additional measures have been introduced via real-time Transaction Risk Analysis and Fraud Detection during authorization. State-of-the-art identity and access management capabilities such as adaptive authentication have made this process easy by enabling the system to adapt to changing behaviours of fraud.

Fraud Detection

The WSO2 Open Banking Fraud Detection feature enables banks to detect known anomalies, unknown anomalies, and anomalous event sequences by carefully monitoring the API calls related to account and payment initiations. The fraud scoring system enables the reduction of false positives. The module also supports analysis and further investigations by identifying complex relationships between the associated entities.

Regulatory Compliance with PSD2

PSD2 is the revised Payment Service Directive. PSD2 requires Europe's banks to give regulated third-party providers (TPPs) access to customers' account information and payment initiation with the customers' permission and consent.

Some benefits of PSD2 include:

The customers can manage their finances using third-party applications, For example, pay your bills using social media accounts.
More consumer choices and better online and mobile payment methods.
More opportunities for the financial technology companies to introduce new and innovative banking services.
Enhanced payment security.
Ability to standardize the payment systems and impose limits on transaction fees to ensure lower costs for the consumers.

Key Concepts

This section explains the key concepts in open banking. For more details see /wiki/spaces/OB200/pages/48629460.

PSD2
Open Banking Implementation Entity (OBIE)
Open Banking
Stakeholders
Standards

PSD2

PSD2 is the revised Payment Service Directive legislation administered by the European Commission and mandated in 2009. PSD2 requires Europe’s banks to give regulated third-party providers (TPPs) access to customers’ account information and payment initiation with the customers’ permission and consent.

Open Banking Implementation Entity (OBIE)

The Open Banking Implementation Entity was created by the UK’s Competition and Markets Authority to create software standards and industry guidelines that drive competition and innovation in consumer banking. Their responsibilities include the following:

Design the specifications for the APIs that banks and building societies use to securely provide Open Banking
Support regulated third party providers and banks and building societies to use the Open Banking standards
Create security and messaging standards
Manage the Open Banking Directory which allows regulated participants like banks, building societies and third party providers to enrol in Open Banking
Produce guidelines for participants in the Open Banking ecosystem
Set out the process for managing disputes and complaints

Open Banking

Open banking has been introduced to make banking a more competitive business. Its main goals are offering greater financial transparency, a shared chance of success for all financial service providers, and more innovative services to the consumers.

The current banking practice involves the customer or merchant to maintain separate relationships with different financial institutions to achieve their financial goals. Open banking introduces a more consolidated experience to the customer by allowing banks to expose their functionality via APIs.

Stakeholders

PSU

A PSU (Payment Service User) is a person who makes use of a payment service in the capacity of either a payer, payee, or both.

PSP

A Payment Services Provider (PSP) is an entity which carries out regulated payment services, including AISPs, PISPs, CBPIIs and ASPSPs.

ASPSP

An Account Servicing Payment Service Provider (ASPSP) is a PSP that provides and maintains a payment account for a payer. Examples of ASPSPs are banks and credit card issuers. The ASPSPs are obligated to grant access to the account and transaction data on their customers’ payment accounts through APIs.

TPP

A Third-Party Provider (TPP) is an authorized third-party that allows merchants to accept a wide variety of payments through a single channel/third-party application, and manage the entire transaction process from start to finish. This means the TPP is responsible for the transaction flow starting from the moment a customer inputs the credit card details to the moment the funds appear in the merchant's bank account. In this process, the bank continues to be the gatekeeper of the customer's information and requires the third-party to produce a security token to access the customer's bank details.

A TPP can be categorized into the following types: AISP, PISP, and PIISP. The customer's bank too can offer AISP and PISP services.

AISP

An Account Information Service Provider (AISP) provides an aggregated view of all the accounts and past transactions that a customer has with different banks. To provide this view to the customer, the AISP should have authorization from the customer to view the corresponding transaction and balance information of all the payment accounts. The AISPs can also provide the facility to analyze the customer's spending patterns, expenses, and financial needs. Unlike a PISP, an AISP cannot transfer funds from a payment account. The following diagram depicts a generic AISP flow:

To view a live demo of the AISP flow of events, see AISP demo.

PISP

A Payment Initiation Service Provider (PISP) initiates credit transfers on behalf of a bank's customer.

The following diagram depicts a generic PISP flow:

To view a live demo of the PISP flow of events, see PISP demo.

PIISP/CBPII

A Payment Instrument Issuer Service Provider (PIISP) is a PSP that verifies the coverage of a given payment amount of the PSU's account. Examples of PIISPs are the banks and credit card issuers that are obligated to verify whether the given payment amount can be covered by the PSU's account through APIs.

Card-Based Payment Instrument Issuer (CBPII) is a PSP (ASPSP/TPP) that issues payment instruments based on cards. Those cards can be used to initiate a payment transaction between an ASPSP and another PSP.

Standards

GDPR

The General Data Protection Regulation (GDPR) is a new legal framework formalized in the European Union (EU) in 2016 and comes into effect from 28, May 2018. GDPR effectively replaces the previously used EU Data Protection Directive (DPD).

Regulatory Technical Standards (RTS)

The European Banking Authority (EBA) published Regulatory Technical Standards (RTS). PSD2 refers to RTS for technical guidance on authentication, authorisation, and other security aspects.

RTS also defines when and how to apply SCA considering the requirements of PSD2.

FAPI

Financial-grade API (FAPI) is an industry-led specification of JSON data schemas, security and privacy protocols to support use cases in the financial industry and other industries that require higher security. FinTech developers can accelerate secure open banking with FAPI. It uses OAuth 2.0 and OpenID Connect (OIDC) as its base and defines additional technical requirements.

ISO/IEC 27001

ISO/IEC 27001 is the internationally recognised specification for an Information Security Management System (ISMS), and it is one of the most popular standards for information security.

Features

WSO2 Open Banking supports the following APIs defined by the Open Banking UK specification. These APIs enable the consumers to access and direct the sharing of data about them with third parties flexibly and simply, and in ways that ensure security and trust in how that data is being accessed and used.

Available APIs	Purpose
Accounts Information API	Retrieving information about customer accounts from banks.
Payments API	Processing bank's customer payments.
Confirmation of Funds API	Managing the funds' confirmation consents by checking and revoking statuses.
Event Notification APIs	To notify the TPPs of events.

These features are available in WSO2 Open Banking for UK: