JSON is the open standard data format that is used by standards such as OAuth, OpenID Connect, and many other RESTful standards, to send data from one service to another. JSON, however is a very loosely formatted data format that allows the user to send data in any structure they like. For Open Finance, a very strict and secure data structure was agreed upon to be used in Open Finance data exchanges.
The Financial-grade API is a highly secured OAuth profile (or layer) that aims to provide specific implementation guidelines for security and interoperability. The FAPI security profile can be applied to APIs in any market area that requires a higher level of security than provided by standard OAuth or OpenID Connect, but here it is often key to a secure Open Finance implementation.
FAPI supports two types of security profiles: the Baseline Security Profile, and the Advanced Security Profile, both of which are supported by Cloudentity.
Strong Customer Authentication (SCA) is a requirement of organizations such as the EU Revised Directive on Payment Services (PSD2) on payment service providers within the European Economic Area. The requirement ensures that electronic payments are performed with multi-factor authentication, to increase the security of electronic payments. Physical card transactions already commonly have what could be termed strong customer authentication (Chip and PIN), but this has not generally been true for Internet transactions prior to the implementation of the requirement, and many contactless card payments do not use a second authentication factor.
From an Open Finance compliance perspective, your applications and services may need to initiate an additional multi-factor authentication validation as part of the authorization part, and thus next to or on top of the possible initial MFA based authentication flow.
Cloudentity supports SCA as part of its policy framework and consent request functionality, allowing you to reach out to your end-user for that additional MFA when the authorization policy or consent requirements configured dictated as such.
CIBA, or Client-Initiated Backchannel Authentication, is another layer on top of FAPI, OpenID Connect and thus OAuth.
Due to relying on OAuth communication between the end-user and the application is typically web-based. This is also true for SCA interaction where the user is asked for an MFA (Multi-Factor Authentication) type step-up credential validation as part of an authorization or consent request. For Open API based transactions, and for Open Finance ones in particular, consumers need to be able to leverage their mobile phones, or other devices, to take care of that MFA request (e.g., by using faceID, touchID). That means that web-based interaction needs to interact with non-browser-based devices. That type of communication is not standardized in OAuth and therefore prone to proprietary integration code and vendor lock-in. That is, until CIBA.
The Client Initiated Backchannel Authentication (CIBA) specification extends OpenID Connect to define a “decoupled” flow where authentication can be initiated on one device and carried out at another. With CIBA, there is no requirement for user interaction on the client initiating the flow, and there are no HTTP redirects through the user’s browser. Instead, CIBA enables direct communication between the application and the OpenID provider (Authorization Server). In this way, the client can obtain tokens from the Authorization Server for a given user at one device after the same user authenticated and granted consent through another device (e.g., the mobile phone).
The beauty of CIBA is that it has now standardized how the browser needs to relay the MFA request to the mobile phone, so that any CIBA compliant authentication provider (e.g., your IDP(s)), can simply respond to CIBA based request without the client needing to implement proprietary communication flows.
Building an Open Finance client application that relies on the OAuth-based authorization, you need to limit the access that the fintech application and services have to the financial institution. The typical way to restrict that access is to utilize the concept of OAuth scopes represented in a special OAuth access token claim (made uniquely for that transaction) that has a set of governance and privacy workflows connected to it.
The API or application owner usually defines scopes as simple nouns or verbs describing actions that the client application can perform using the so-called “dot” notation.
Examples of scopes using the dot notation
Such scopes are perfect if you want to control access at the coarse-grained level. However, what can pose a challenge for the client application developer is restricting access to a specific object, transaction, or intent. If the developer is aware that the next set of operations relates to a single item, such as a specific account or user, they might want to restrict the authorization access token to this action or intent. It can be done by including a reference to the object as a part of the scope.
Examples of scopes using the dot notation and the identifier
To facilitate this type of scenarios, Cloudentity supports the mechanism of wildcard-based authorization policies so that generic policies can be written once for each of the protected object, transaction, or intent, in such a way that the policy can derive the various parts of the dynamic scope when evaluated.
With dynamic scopes, your authorization flows get fine-grained and simplified, and so does your access to the clients. The use of dynamic scopes not only speeds up and facilitates the process of defining scopes but also enables you to build your policies more efficiently.
For your Open Finance applications to authorize specific requests, e.g., for a payment initiation flow, dynamic scopes can be validated against using wildcard governance authorization policies.
Examples of dynamic scope matching:
accountsdoes not match
accounts.read.*does not match
pay.*.GBPwhere the currency must match GBP
Dynamic Client Registration
In an Open Finance economy, there are a lot of fintech applications that need to register against on or more Open Finance enabled financial institution, such as banks. To avoid the need to manually register each of these applications and services, yet another layer was added on top of the base OAuth standard, allowing you to securely programmatically register OAuth clients (such as your Open Banking application or service) with authorization servers (such as Cloudentity).
Everybody knows a web browser can communicate over https to allow for an encrypted communication. What many do not understand is that HTTPS, leveraging SSL and TLS, only takes care of the security of the website you are communicating with, the website has no idea it is talking to your browser.
For Open Finance type of communication, both parties, the financial institution, and the client application (e.g., fintech or aggregator) both need to be sure of each other’s identity, encryption keys and security enforcement. To allow TLS in both directions, MTLS was defined.
Mutual TLS, or mTLS for short, is a method for mutual authentication. mTLS ensures that the parties at each end of a network connection are who they claim to be by verifying that they both have the correct private key. The information within their respective TLS certificates provides additional verification.
Open Banking Participants
Let’s check the profile descriptions of typical actors of the Open Banking scene in order to understand their goals, responsibilities, interrelations, and dependencies.
The end user in Open Banking (OB) is usually an individual with no technical or engineering background who is a consumer of final Open Banking products/services. Typically, there are two end-user personas in OB: the Fintech app user and the bank customer. Although they can both benefit from what OB provides (safe and transparent data exchange and financial operations), most often they are not aware of OB enablement and integration processes that are behind their sound and secure services. Those are Fintech app developers, banks, and most of all, Open Banking enablers (such as Cloudentity) who make Open Banking work for the end users.
Why use Cloudentity for Enabling Open Banking
Refer to Cloudentity as an Open Banking enabler to to check how Cloudentity helps enable Open Banking for different parties and the scenarios it covers to get them OB-compatible.
Fintech App User
The Fintech application user is an individual who has a financial application installed on a device and intends to use it for OB purposes, such as aggregating financial data from different banks and/or accounts, filtering the data to retrieve specific information, performing financial operations (for example, transfers), or displaying the transaction history. Most ofter the Fintech app user is a customer of a bank or a few banks.
Check the OB Quickstart
Check the OB Quickstart by Cloudentity to see how Cloudentity can support developing Fintech apps, building bank consent pages, creating customer self-service portals and admin panels of the bank so that they are in line with OB standards.
The bank customer is an individual using products and/or services of the bank. The bank customer can communicate with the bank in multiple ways, for example, by visiting a bank branch in person, by using a web portal of the bank, or by contacting their customer call center. One more way for the bank customer to connect to the bank is the use of the financial application (Fintech app), which gives him/her benefits of connecting to a number of banks at the same time with one medium only.
As mentioned, the bank customer can use the bank portal for exchanging information and performing operations, which is usually handled by the self-service portal. The self-service portal is a website offered by the bank (on top of the bank portal) to the customer for verifying and maintaining the profile information, checking data on accounts and transactions, performing financial operations, and, finally, managing data security and privacy (for example, permissions).
Fintech App (TPP)
The Fintech app, also called the TPP (third party provider) app, is a financial application that enables the end users of financial services to retrieve and/or process their financial data. Typically, the Fintech app allows the users to connect to their banks for acquiring financial information and/or performing financial operations.
The Fintech application needs to comply with Open Banking standards so that the users can share their data safely from the bank to the app. To achieve the optimal level of security and privacy, OB standards specify what methods of authentication and authorization the Fintech app needs to use.
The bank represents an institution that provides financial services and products to the customers. Consequently, the bank is responsible for storing, processing, and sharing its users' data according to the highest privacy and security standards. There are a number of requirements that the bank needs to meet for the OB compatibility. Altogether these requirements are to enable the safe integration with the bank for all those who decides to connect it. OB standards defined for banks focus on APIs that the banks exposes. There are also requirements concerning the identity provider of the bank and services that the bank provides, such as the custom consent page, the customer self-service portal, or the admin portal of the bank.
The bank administrator is a a professional with a technical background hired by the bank to administer users' profiles, accounts, and data. In the context of Open Banking, the bank administrator is responsible for security and privacy of users' data. The admins have access to all users' security and privacy settings, for example, to permissions granted to Fintech apps for accessing user’s data. In the admin portal of the bank, they can modify the security settings on behalf of the users, for example, by revoking permissions granted to the apps. The admin portal needs to comply to OB standards in terms of its architecture and operation.
Check the Admin Portal in the OB Quickstart
Check the OB Quickstart by Cloudentity to see a sample administrator portal that is integrated with Cloudentity and, hence, Open-Banking-compatible.
The bank developer is a professional with a technical background hired by the bank to handle any programming tasks. In the Open Banking context, the bank developer can be responsible for building the bank consent page, the customer self-service portal, the bank admin portal, and more.
How Cloudentity Helps Bank Developers Keep their Code OB-compatible
Cloudentity provides an easy integration for the bank consent page. The integration of the bank with Cloudentity ensures the compliance with Open Banking standards not only for the bank consent page but also for other bank services, such as the self-service portal and the admin portal. Read more on the OB-compliant consent page in Building the Open-Banking-compliant consent page with Cloudentity.
Check the Self-Service Portal and the Admin Panel in the OB Quickstart
Check the OB Quickstart by Cloudentity to see a sample customer serf-service portal and a sample administrator portal that are integrated with Cloudentity and, hence, Open-Banking-compatible.
The individual developer is a person with technical skills whose goal is to create a financial application compatible with OB standards. The developers can build Fintech apps for themselves or for commercial purposes. In both cases, they need to follow specific requirements that OB sets for Fintech apps.
Open Banking Enabler
Open Banking is complex and multifaceted. To ensure a safe and secure ecosystem for financial operations, it sets strict requirements for its participants. Such an approach poses a challenge not only to individual users and developers but also to financial institutions (such as banks) who want to enter on Open Banking.
To cope that challenge, there are services that can help Fintech-app users, banks, and developers to meet OB requirements and get involved in OB easily and smoothly. OB enablers, such as Cloudentity, offer diverse services and features that allow individuals and institutions to get Open-Banking-compatible. They serve as catalysts to processes of the integration between different parties required for the healthy and operational OB ecosystem.
Check Cloudentity in the OB Quickstart
Check the OB Quickstart by Cloudentity to see how the Cloudentity component is configured to support multiple OB scenarios and help you get compatible easily.
Revised Payment Services Directive (PSD2) is a set of laws and regulations for payment services in the European Union (EU) and the European Economic Area (EEA), which set the foundation for its implementation in specific countries (such as Open Banking UK). Its main goal is to make the European payments market more efficient and integrated, but it also aims to:
Make it easier for new institutions and initiatives to come into the payments market
Make payments safer and more secure, thus, reducing the risk of fraud
Promote the development and use of innovative online and mobile payments (such as Open Banking)
PSD2 came to life in October 2015, but the most important changes for payments in the context of Open Banking came into force in January 2018. Since that date, all European banks must comply with European Union regulations concerning the technical standards for strong customer authentication and common and secure open standards of communication.
Remember that regulations provided by PSD2 are for payment transactions that take place within the European Union. If a payment transaction comes from outside of the EU, stronger customer authentication is not required.
To learn more about PSD2 regulations, see the Revised Payment Services Directive.
Strong Customer Authentication
PSD2, in its article 4, point 29 defines authentication as a procedure that allows the payment service provider to verify the identity of a payment service user or the validity of the use of a specific payment instrument, including the use of the user’s personalized security credentials.
Strong customer authentication (SCA) is a requirement of PSD2 for payment service providers. It ensures that all electronic payments are performed with multi-factor authentication to increase the level of security.
Article 4, point 30, of PSD2 defines SCA as authentication based on the use of two or more elements categorized as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data.
SCA must take place when the payer:
Accesses their payment account online.
Initiates any electronic payment transaction.
Performs any action through a remote channel which may imply a risk of a payment fraud or other abuses.
In terms of security, European banks had to update their authentication elements that they provide their customers with. They had to, for example, replace already existing solutions with, for example, cell phone messages or more advanced access tokens.
Payment Initiation Service
Payment Initiation Services (PIS) enable customers to instantly transfer money between their accounts within different banks and to make online purchases. The process takes place within their application or a website.
Payment Initiation Services Providers
Payment Initiation Services Providers (PISPs) are service providers that facilitate the use of online banking to make payments online. They create an interface that bridges the gap between the customer’s account and the merchant’s account. They provide all the information needed for the bank to enable a payment transaction (like, for example, the amount of funds, or account number). They inform the store of a transaction taking place. In other words, PISPs can access consumer and business accounts directly by utilizing the bank’s APIs.
Before PSD2 came into life, Third-Party Providers had it difficult to offer larger-scale solutions as online banking was not regulated between different countries that belonged to the EU or EEA. Now, the payments market is much more accessible for new players and it is easier for already existing actors to provide such services. Both new players and existing actors have to comply with all rules for traditional service providers, like authorization, registration, and authorities supervision.
Account Servicing Payment Service Provider
Account Servicing Payment Service Providers (ASPSP) provide and maintain payment accounts for payment service users. They may be a bank or a similar institution. PSD2 requires ASPSPs to publish their READ/WRITE APIs to enable their customers to share their account transactions data with third-party providers (TPPs), like PISPs.
How Cloudentity Supports OB Payment Services
Cloudentity can be treated as a safeguard for Account Servicing Payment Service Providers. Cloudentity can be utilized to authorize and authenticate OAuth client applications (in this case, PISPs) and to authenticate the customers trying to make online transactions. Such user authentication can be also enhanced by the Cloudentity using strong customer authentication if needed. Cloudentity also provides a possibility to create and manage custom consent pages that can be used to get payment authorization from the users (payers).
Additional Open Finance standards support
Additional to the above explained standards, Cloudentity also supports the following advanced standards as to full compliance to Open Finance and Financial API security guidelines and recommendations:
Proof Key for Code Exchange for OAuth Public Clients (RFC 7636)
OAuth 2.0 Threat Model and Security Considerations (RFC 6819)
Certificate-bound access tokens (RFC 8705)
JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)
OAuth 2.0 Pushed Authorization Requests (PAR)
Self-service as well as administrative Open Banking consent management UI and API
SPIFFE (used to automatically assign and validate an identity to cloud workloads)