Open Banking Concepts and Terms

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 SecureAuth.

Australia's Consumer Data Right (CDR) gives consumers greater access and control over their data, improving their ability to compare and switch between products and services. It encourages competition between service providers, leading to better prices and more innovative products and services. The CDR is rolled out industry-by-industry, starting with the banking sector and followed by the energy and telecommunications sectors. To build a standardized ecosystem of data sharing agreements, it is important to have explicit consent from consumers before data access is provided, and to use secure application programming interfaces (APIs) for third parties to access customer data with the customer's consent. This momentum is being replicated worldwide with the "Open Banking" initiative and similar legislation in other countries.

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.

SecureAuth 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, SecureAuth 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:

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 SecureAuth).

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.

Let's check the profile descriptions of typical actors of the Open Banking scene in order to understand their goals, responsibilities, interrelations, and dependencies.

Additional to the above explained standards, SecureAuth also supports the following advanced standards as to full compliance to Open Finance and Financial API security guidelines and recommendations: