Open banking is a game changer for the financial services industry in Australia. Securely opening up banking data in a standardized form with the intent of improving customer experiences is the main goal of the Consumer Data Right (CDR). This notion is backed by the Treasury and the Australian Competition and Consumer Commission (ACCC). The idea of opening up data through APIs to be consumed by accredited third parties may pose several security concerns to banks. However, comprehensive research has been undertaken to make sure the open banking ecosystem functions effectively, with no security breaches.
There are 3 pillars that the CDR is centered around: API standards, the security profile, and consumer experience. These pillars facilitate financial organizations to interact with third-party providers effectively by covering all aspects of communication:
- Efficiency offered by API standards
- Reliability offered by the security profile
- Usability offered by consumer experience guidelines
With the first working draft released in November 2018, the Data61 Consumer Data Standards team is working on finalizing the first version of the API standards to effectively transform the way Australians will be handling financial data exchange. Introducing a robust and sophisticated face of open banking to Australians will be a significant achievement which would be the first step of an evolutionary journey.
API Standards
The API standard is the backbone of CDR which defines the data structures utilized during API communication. The endpoint definitions, resources, and data structures are encircled by a list of principles categorized as outcome principles and technical principles. As the names suggest, the outcome principles define the qualities that should be delivered by the API definitions and the technical principles articulate the technical features of the API definitions.
 |
| Source: MuleSoft |
The outcome principles denote that APIs:
- Are secure - ensures the protection of customer data
- Use open standards - reaches a wider audience of industries
- Provide a good customer experience - is easy to use
- Provide a good developer experience - allows developers to understand and implement effortlessly
The technical principles denote that APIs:
- Are RESTful - adhering to statelessness and resource orientation
- Are implementation agnostic - the implementations should be independent of the API standards
- Are simple - to reduce implementation costs
- Are rich in capability - to cover a wide range of scenarios
- Are performant - to minimize repetition and issues with heavy payloads
- Are consistent - by using common data structures wherever possible
- Are version controlled and backward compatible - the evolution of the APIs should not break previous implementations
- Are extensible - to accommodate future use cases
In addition to the API definitions, the Consumer Data Standards presents comprehensive details about the auxiliary concepts of any API specification such as versioning, HTTP headers, response codes, and pagination. Even though the API definitions are categorized as banking APIs and common APIs, the latter only includes two endpoints about customer details which could be used to obtain basic or detailed information on the customer that authorized the current session.
The banking APIs are the highlight of the API standards which encompasses a list of endpoints defined to facilitate third parties to communicate with the banks and retrieve access to the pre-defined resources.
The banking API resources include:
- Accounts - basic or detailed information about accounts
- Get Accounts
- Get Account Detail
- Balances - balances of multiple or specific accounts
- Get Bulk Balances
- Get Balances for Specific Accounts
- Transactions - basic or detailed information about transactions of multiple or specific accounts
- Get Transactions for Account
- Get Transaction Detail
- Get Transactions for Multiple Accounts
- Get Transactions for Specific Accounts
- Direct debits - direct debit authorizations for multiple or specific accounts
- Get Direct Debits for Account
- Get Bulk Direct Debits
- Get Direct Debits for Specific Accounts
- Payees - basic or detailed information of pre-registered payees
- Get Payees
- Get Payee Detail
- Products - basic or detailed information of products openly offered to the market
- Get Products
- Get Product Detail
Unlike other open banking specifications, CDR does not currently define consent APIs which controls consent creation, retrieval, and revocation functionalities. The current list of API definitions is focused only on accommodating the access to the pre-defined resources, however, more details about consent management are expected to be introduced in the near future.
Information Security Profile
 |
| Source: DZone |
The CDR Information Security Profile (CDR-SP) is built on top of the Financial-grade API Read Write (FAPI-RW), Client Initiated Backchannel Authentication (FAPI-CIBA) and OpenID Connect (OIDC) standards in order to ensure secure data exchange between the entities involved.
| Entity | Description | OIDC Role |
|---|---|---|
| Data Holder (Bank) | The entity that authenticates the resource owner (the customer) and grants access to consumer's data. | Role of OIDC Provider |
| Data Recipient (Third-party Providers) | The entity that is authorized to access consumer resources. | Role of OIDC Relying Party (Client) |
| Registry | Data Holders and Data Recipients must be registered as members of the CDR Federation. The Registry functions include management of identities and access, management of certificates, discoverability and search. | Maintained by ACCC |
Similar to the API standards, the security profile is encircled by the core principles of CDR:
- Should be consumer focused
- Should encourage competition
- Should create opportunities
- Should be efficient and fair
When exploring the technical aspects of the security profile, it can be noticed that, compared to other open banking specifications, the flexibility given to the organizations is limited, since most of the mechanisms and definitions are straightforward and compulsory. On the other hand, it could also reflect the attention given to enhancing developer experience, which allows data holders to minimize decision-making processes and adopt the standard easily.
For example, the authentication flows that should be supported by data holders are limited to the mandatory support of OIDC Hybrid Flow and the optional support of FAPI-CIBA. The Hybrid Flow is a mechanism of redirecting the consumer to the data holder’s authorization server to authenticate the consumer, which should be supported by default. The only optional support is expected with regard to FAPI-CIBA, which is a mechanism to authenticate a user through a decoupled approach.
Similarly, other components of the security profile are comprehensively explained, most of which are directly referenced from the OIDC standard: “private_key_jwt” client authentication, types of tokens supported, scopes, claims, request object, consent management and levels of assurance.
Consumer Experience
 |
| Source: InTouchCRM |
The CDR has drawn special attention to enhancing consumer experience when implementing the API standards. This allows consumers to manage ‘informed’ and ‘explicit’ consents, and allows organizations to competently comply with the standards of ACCC.
The Draft Rules Framework of ACCC proposes the following practical guidelines to meet consent-based requirements:
- Consent should be freely given by the consumer
- Consent should be expressed
- Consent should be informed (with the ACCC making rules in relation to information that must be provided by accredited data recipients as part of seeking consent)
- Consent should be easy to understand
- Consent should be specified as to the intended use of data
- Consent should be time limited
- Consent should be easily withdrawable
While the published list of use cases is not quite detailed as one would hope, the criteria for prioritizing the use cases cover a broad range of topics such as test variants of consent including consent duration and payload breadth. The high-level use cases are:
- Managing finances (personal budgeting, debt management)
- Accounting/taxation (business reporting)
- Applying for credit (credit cards, loans)
- Account switching
- Product/service comparison
Currently, this topic is under research that is focused on investigating consumer expectations, especially data language. The data language requirements include data clustering and granularity, which cater to the level of comfort on how the consumers acquires information. The ultimate goal of the consumer experience workstream is to come up with design requirements and guidelines that would enable organizations to provide their customers with services that are both reliable and easy-to-use. The roadmap of the consumer experience workstream focuses on building phase two on the foundations of the research outcomes of phase one. They aim to finalize the first version of the consumer experience guidelines a couple of months prior to the CDR deadline.
Summary
Since July 2018, Data61 has been working on delivering the working drafts of CDR embodied in three sectors: API standards, the security profile, and consumer experience. While the three sectors focus on different qualities of CDR, the final goal is common to all — to enable easier and safer platforms for consumers to access data through banking APIs, thus promoting competition between financial organizations to offer improved services to consumers.
All three work streams are still under progress, making financial organizations, banks, and third-party developers anticipate the finalized decisions about the Consumer Data Standards. Introducing open banking to Australia at a time when European banks have just started to embrace it, may have its own advantages in attracting the positive attitudes of the financial organizations.
WSO2 is committed to helping Australian banks on their open banking journeys. We have submitted a response report to be reviewed by open banking Australia. Since then, we have worked closely with Data 61 to contribute to the development of the API standard for open banking in Australia. More information on WSO2 Open Banking is available here.
