Understanding Consumer Data Right in Banking (Open Banking) for Australia
On 26 November 2017, the Australian Government announced the introduction of a Consumer Data Right (CDR) in Australia. The consumer data right will improve consumers’ ability to compare and switch between products and services. It will also encourage competition between service providers, leading not only to better prices for customers but also more innovative products and services.
Government has decided that CDR will be applied to Banking sector and commonly known as Open Banking. Under Open Banking, consumers will be able to access and safely transfer their banking data to trusted parties. Open Banking will be introduced in phases, with basic product information to be available on the first phase.
Multiple government organizations interact with each other to establish open banking eco system and its governance as shown below.
The Consumer Data Standard team of Data61 maintains a work space for API standards development under the Consumer Data Right regime in a GitHub project. This repository contains the binding API Standards and Information Security profile created in response to the Consumer Data Right legislation and the subsequent regulatory rules. These standards are maintained by the Data Standards Body (DSB) with final decisions on standards being taken by the Data Standards Chair.
Government CDR program is composed of multiple working group streams as shown below.
API Standards: drafting and validating API specifications;
Information Security: defining the information security profile supporting the API specifications, and authorisation and authentication flows;
Consumer Experience (CX): providing best practice language and user experience (UX) design patterns to request consumer consent and guide authentication and authorisation flows; and
Engineering: focuses on demonstrating the API Standards through the delivery of usable software artefacts that assist ecosystem participants demonstrate conformance with the standards and rules for CDR.
Following CDR participants are defined under Consumer Data Standard (CDS) in a CDR ecosystem.
The following is a high level overview of the CDR ecosystem outlining the components and API endpoints each participant within the ecosystem will be expected to implement. Note that ADRs are expected to have one or more Software Applications consuming CDR data.
Data Holder shares CDR data with an Accredited Data Recipient using APIs. A CDR Data Set is composed of following types of information and against a specific banking product.
Following diagram shows the relationship between data sets.
Accredited Data Recipient (ADR) has its own software products. The accreditation status of Accredited Data Recipients, and the status of their associated software products, may traverse through multiple states in the CDR as a result of decisions by the ACCC, in its capacity as Data Recipient Accreditor, or where an Accredited Data Recipient surrenders accreditation.
Data Holders will have the responsibility to ensure that CDS data relating to consumers is disclosed to ADRs and to cease sharing data where the accreditation of a data recipient is
- Suspended or revoked by the ACCC
- Surrendered by the Data Recipient
The Register will notify all Data Holders of the above changes in Accredited Data Recipient status as per the ACCC’s decisions.
ADR software products have following lifecycle states.
CDS API Specification Details (v.1.3.0)
Consumer data will be exposed using RESTful APIs. API definition should support open API specification like Open API 3.0. APIs are grouped in to three catagories based on the data they expose and functions they execute as shown below.
- Banking APIs
- Common APIs
- Administration APIs
URI pattern for these groups are shown below.
URI Structure
The URI structure for API end points in the standards MUST be implemented as follows:<holder path> / cds-au / <version> / <industry> / <resource>
The components of this URI structure are described as follows:
- Holder Path: The holder path is a base path set by the data holder. It can be any URI desired by the holder. While all authenticated end points must be accessible under the same holder path the data holder may stipulate a different holder path for unauthenticated end points.
- “cds-au”: This is a static string Holderepresenting the end points defined by the Consumer Data Standards for Australia. This static string allows for separation from other APIs available at the same base holder path and also allows for extension if the standards are adopted by another jurisdiction in whole or in part.
- Version: The major version of the high level standards. This is not the version of the endpoint or the payload being requested but the version of the overall standards being applied. This version number will be “v” followed by the major version of the standards as a positive integer (e.g. v1, v12 or v76).
- Industry: A static string used to separate APIs for a specific industry. As standards for new industries are defined the list of industry strings will be extended.
- Resource: The URI for the specific resource requested. This end point URI will be defined as part of the end point definitions for each API group.
Note that the currently accepted values for the Industry component of the base path are:
- banking — for APIs related to banking and potentially wider financial services data
- energy — for APIs related to the energy distribution industry
- telco — for APIs related to telecommunications
- common — for APIs that potentially span industries
Structural standards are shown in a diagram below.
Following table shows the 17 banking APIs on the specification.
Banking APIs
Common APIs
Admin APIs
Supporting API Versions
In the API spec ADR could specify which version of API he is expecting to consume using the “x-v” and “x-min-v” HTTP header. “x-v” HTTP header defines the highest version and “x-min-v” specify minimum version expected.
Open banking solution has to support multiple versions based on a design shown below.
Data holder needs to expose few more APIs / endpoints thats is being used by OIDC hybrid flow interactions. These are shown below.
Interaction with Lead Regulator through APIs
Lead Regulator exposes set of important APIs for Data Holders and Data Recipients as shown below.
The interaction on the Software Product Metadata API have a complex behaviour to maintain an updated cache of metadata (including status) of software products of Data Recipients from the CDR Register as shown below.
The software products of the Data Recipients need to be registered with Register (ACCC). Data recipients will use Software Statement Assertions made available by the Register through APIs or manully to register their product with Data Holder. Data Holder has a trust relationship with Register and will use JKWS endpoint of Register to validate the request. After validating Data Holder will register the Data Recipient and its products within a internal registry. Interaction of this process and the APIs invloved is shown below.
The APIs that data holder exposes need to be secured using supporting OpenID Connect 1.0 (OIDC) code, id_token hybrid flow and further restricted by FAPI-RW profile. Hybrid flow incorporates aspects of the both the implicit flow and authorisation code flow in underlying OAuth 2.0 specification. The private_key_jwt authentication method is enabled through the delivery of an encoded signed using the Data Recipient's private key and thus facilitates non-repudiation. Following diagram shows the standard handshake of the flow.
Data holder must use Two factor (2FA) or Multi Factor Authenitcation (MFA) for consumer authentication as shown on diagram by 01.
- A user’s digital banking Id / member Id is entered to the browser and submitted by the end-user.
- A code or notification is sent to a end-user’s pre-registered mobile/device application (detached authentication device). This step is optional as an end-user’s device application may generate codes in isolation, as is the case for Time-based One-Time Password (TOTP).
- The end-user views the code or event on their detached authentication device.
- One of the following may occur:
- The end-user directly enters the code (or scans a QR Code) into the browser and submits the request. On success, the authorisation process begins.
- The end-user does not enter the code into the browser. The end-user acknowledges the authentication through the device and a secure message is sent from the device to the Data Holder via a backchannel. On receipt of the message, the Data Holder’s website redirects the end-user’s browser to the authorisation page.
Please check the diagram above for the OIDC 1.0 hybrid flow that uses JWT private key mechanism for tokens.
Consent Management Flow
User will be prompted for a consent flow which content is driven by the Data Recipient’s software applications Software Statement Assertion (SSA) and OIDC interaction.
SSA is shown on the background in below image while blue screen is the consent page. (extracted from WSO2 Open Banking Solution)
following diagram shows the ecosystem components of consent management.
ADR and Product Metadata Cache
Data holder needs to maintain a meta data cache which stores the list of ADR’s state and their software products against its state. It needs to be periodically refreshed calling ACCC or product register’s software product metadata API and ADR.
Following diagram shows the standard validations that are performed when an ADR makes an API request.
There are two validations that needs to be performed on ADR status and ADR Product status using meta data cache.
Product Register may call on your Metadata Update Admin API sending a refresh ping when there is an update. When a Software Product is removed or made inactive the consent related to the software need to be revoked.
Serving Data for the APIs
API definitions provide the interaction surface for the Data Holder. Complexity is within making data siloed in core banking systems to be made available to the APIs. Bank need to walk a digital transformation journey to make this happen.
A stronger integration capability is needed to fully support CDS and following diagram shows some of the patterns need to be implemented.
Data Language Standards
Under Consumer Experience Standards a data language standard has been defined to provide descriptions of the types of data to be used by the CDR participants in making and responding to requests. Adherence to this language will help to ensure there is a consistent interpretation and description of the consumer data that will be shared across different CDR implementations. Following table show extract from data language standards for individual consumer.
Maintaining Compliance
CDS Engineering Working Group is producing a number of artefacts to demonstrate the emerging CDR ecosystem. The primary aim of these artefacts is to allow interested parties to create simulations of the target environment which closely represent the implementation of the Consumer Data Standards and it’s associated components. Following diagram shows the ecosystem of artefacts.
Data Holder can maintain their CDS compliance by building an automated CI/CD pipeline which the conformance suite is attached to it as shown below.
Data Holder Categories
Data holders can come in different flavours as shown below.
Data Recipient Side of the Story
The ACCC received 40 expressions of interest from fintech that want to become accredited data recipients on the first trial of CDS for banking and 10 applicants were successful:
- 86400
- Frollo Australia
- Identitii
- Procure Build
- Quicka
- Regional Australia Bank
- Verifier Australia
- Wildcard Money
- Intuit Australia
- Moneytree
