Learn the key concepts behind Open Banking, its stakeholders, and the technologies involved.
The global financial services market is oligopolistic in nature. A few key players get to define market dynamics and the rate of innovation. Banks have the sole ownership of the customer data and they have the power to decide on the quality of services that the customer experiences.
Open banking advocates the revised Payment Service Directive (PSD2) and promotes greater financial transparency. It allows third parties to securely and rapidly build financial services with the use of open APIs.
The Payment Services Directives, also known as PSD and PSD2, are two pieces of legislation (European Union directives) administered by the European Commission (Directorate General Internal Market) to regulate payment services and payment service providers throughout the European Union and European Economic Area (EEA).
PSD2 is the revised Payment Service Directive, which was mandated in 2016. It stems from PSD1, which was 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.
Some of the benefits of PSD2 include:
There are six categories of stakeholders that actively participate in Open Banking.
TPPs can create third-party applications to facilitate banking services exposed via APIs by banks.
Before getting TPPs connected with the Banks and onboard, they are subjected to a thorough verification. 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 takes places with the consent of the respective PSU:
An 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 where as 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).
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. Swagger 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. Swagger helps describe a service in the same way that interfaces describe lower-level programming code.
WSO2 Open Banking API management component has an integrated Swagger UI, which is part of the Swagger project. For more information, see the Swagger 2.0 specification.
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:
WSO2 Open Banking comes with a pre-created default application, which allows unlimited access by default. You can also create your own applications.
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:
You can authenticate an entity using one factor, i.e., single-factor authentication or multiple factors, i.e., multi-factor authentication (MFA).
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, e.g., "Authorization: Bearer NtBQkXoKElu0H1a1fQ0DWfo6IX4a".
WSO2 Open Banking supports two types of access tokens for authentication to ensure better security, e.g., preventing DoS attacks:
Access tokens authenticate API users and applications, and ensure better security, e.g., preventing DoS attacks. 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.
Cross-Origin Resource Sharing (CORS) is a mechanism that allows accessing restricted resources, i.e., fonts, images, scripts, videos, and iframes from domains outside the domain from which the requesting resource originated.
By default, web browsers apply the same-origin policy to avoid interactions between different origins. CORS defines a way in which a browser and a server can interact to determine whether or not it is safe to allow the cross-origin requests.