Learn the core concepts of Open Banking
Learn the key concepts behind Open Banking, its stakeholders, and the technologies involved.
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 in order to achieve their financial goals. Open banking introduces a more consolidated experience to the customer by allowing banks to expose their functionality via APIs.
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.
Benefits of PSD2 include:
Following are the categories of stakeholders that actively participate in Open Banking:
PSU: A Payment Service User (PSU) is a person who makes use of a payment service in the capacity of either a payer, payee, or both. For example a bank customer.
PSP: A Payment Services Provider is an entity that carries out regulated payment services, including AISPs, PISPs, CBPIIs, and ASPSPs.
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. 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 in order to access the customer’s bank details.
A TPP can be categorized into the following types: AISP, PISP, and PIISP. The customer’s bank can also 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) provides an online service to initiate a payment order at the request of the PSU (a bank customer) with respect to a payment account held at another PSP. To provide this facility PISPs should be authorized by the customer to proceed with the payment. PISPs are responsible for the transaction flow starting from the moment a customer inputs the payment details to the moment the funds appear in the merchant’s bank account.
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.
Fintech: Fintech is another name for financial technology and is often used to refer to a business that offers new and innovative financial services using software and modern technology.
Fintechs thrive to offer various financial services like money transfers, payments, and lending in fast and easy ways to keep up with the requirements of the modern-day, tech-savvy, digitally advanced customers. Due to this reason, Fintechs have become quite a competitive challenge to banks that have more rigid, process-oriented structures.
Third-Party Providers (TPPs) can create third-party applications to facilitate banking services exposed via banking APIs. A TPP can play the role of a PISP/AISP/CBPII or a combination of those roles.
The TPPs are subject to thorough verification before connecting them with the banks/ASPSPs. This verification includes a comprehensive sign-up process at the API Store; the developer portal of WSO2 Open Banking. For a TPP to start providing open banking services, it has to be registered under a Competent Authority, which is a regulatory body that authorizes and supervises the open banking services delivered by the TPP.
Consent management ensures that the following scenarios take place with the consent of the respective PSU:
The Australian Government introduced the Consumer Data Right (CDR) to give consumers more control over their data. CDR provides customers and small businesses a choice about how their data is shared with third parties and sets standards for a whole industry about what data should be made available, safely. In doing so, CDR encourages competition between service providers, leading to better prices for customers and more innovative products and services.
The CDR will be rolled out sector-by-sector, starting with the banking sector. Further information on the CDR is available on the Treasury website.
The Consumer Data Standards (CDS) are the technical standards produced by Data61, which is the Data Standards Body that provides guidance for the banks/Data Holders on how to implement the CDR. These standards enable 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.
Following are the key actors related to CDR context:
Data Recipients (DRs) can create applications to facilitate banking services exposed via Bank APIs.
The DRs are subject to thorough verification before connecting them with the banks/Data Holders. This verification includes a comprehensive sign-up process at the API Store, the developer portal of WSO2 Open Banking. For a DR to start providing open banking services, it has to be registered under the Australian Competition and Consumer Commission (ACCC).
Application Programming Interfaces (API) is a mechanism that enables exposing software functionality without revealing its implementation. APIs enable software applications to interact with each other and exchange data. WSO2 Open Banking supports REST, SOAP, and WebSocket APIs.
An API is made up of one more resources, each of which handles a particular type of request. A resource is defined with a URL pattern and a set of methods that operate on it.
The URL mapping performs a one-to-one mapping with the request URL whereas the URI template performs a pattern matching.
You can parameterize the API resource URL to map the incoming requests to the defined resource template based on the message content and the request URI. Once a URI template is matched, the parameters in the template are populated appropriately.
APIs have their own lifecycles that are independent of the backend services they rely on. By default, WSO2 Open Banking maintains six API lifecycle states:
Visibility settings prevent certain user roles from viewing and modifying APIs created by another user role. You can either make them public or restrict to users with specific user roles. Public APIs are visible to all anonymous (users who use APIs without signing in) and registered users, and can be advertised in multiple stores/developer portals.
WSO2 Open Banking facilitates adding documentation to APIs. API documentation helps API subscribers to understand the functionality of the API and API publishers to market their APIs better and sustain the competition. Similar to APIs, WSO2 Open Banking enables access control to API documentation.
Throttling allows you to limit the number of successful hits to an API during a given period of time, typically in cases such as the following:
WSO2 Open Banking enables defining throttling at the API, application, and resource levels. The final request limit granted to a given user for a given API is ultimately defined by the consolidated output of all the applicable throttling tiers. The throttling tiers are also referred to as Service-level agreements (SLAs).
OpenAPI (formerly known as Swagger) is a 100% open source, standard, language-agnostic specification and a complete framework for describing, producing, consuming, and visualizing RESTful APIs, without the need of a proxy or third-party services. OpenAPI allows consumers to understand the capabilities of a remote service without accessing its source code, and interact with the service with a minimal amount of implementation logic. OpenAPI describes a service in the same way that interfaces describe lower-level programming code.
An application is an intermediary that sits between an API and its consumer. API consumers use applications to subscribe to APIs and consume them.
An API consumer can subscribe to multiple APIs using a single application. Thus, it acts as a logical collection of API subscriptions and decouples the API consumer from the APIs. Each application can be associated with different Service Level Agreement (SLA) levels. This is enabled by attaching an application with throttling tiers that determine the maximum number of API calls allowed during a given duration.
Applications therefore enable:
Security refers to the means through which computer systems are protected from damage and disruption without being compromised to risks and vulnerabilities. WSO2 Open Banking implements security at the application level and transport level.
Encryption is the process of translating/encoding data/messages (plaintext) using an algorithm (cipher) into a secret code (ciphertext) that can only be accessed by authorized entities with a secret key or a password.
Authentication is the process used to distinctly identify a certain entity using the following factors:
Authentication is implemented in either of the following forms:
Authorization is the process through which an entity is granted permission to access another entity such as data, resources, and system. In general, authorization takes place subsequent to authentication.
WSO2 Open Banking uses role-based access control (RBAC) and scopes to implement authorization.
Scopes enable fine-grained access control to API resources based on user roles. When a user invokes the API, the user’s OAuth2 bearer token cannot grant access to any API resource beyond its associated scopes.
An access token is a simple string that is passed as an HTTP header of a request. For example, “Authorization: Bearer NtBQkXoKElu0H1a1fQ0DWfo6IX4a”.
WSO2 Open Banking supports two types of access tokens for authentication to ensure better security such as preventing DoS attacks:
Access tokens authenticate API users and applications, and ensure better security. If a token that is passed with a request is invalid, the request is discarded in the first stage of processing. Access tokens work equally well for SOAP and REST calls.
Access tokens grant access to protected API resources. The level of access granted by each access token is determined by the method (known as grant type) used to generate the access token. There are several grant types used in WSO2 Open Banking:
A certificate (also known as an SSL certificate or digital certificate) is an encryption tool issued by a trusted certification authority (CA) that encrypts data transmitted between a client and a server. Certificates are used for public-key encryption in Public Key Infrastructure (PKI).
In WSO2 Open Banking a TPP must forward a certificate to the ASPSP so that when the TPP sends an application access token request, the ASPSP can verify the authenticity of the request using the shared certificate. A keystore is a repository that contains multiple certificates.