Accelerating your way to a CDR solution with ForgeRock Part 1
This article is the first in a multi-part series on the ForgeRock CDR Accelerator.
A new standard has arrived for the Australian banking sector, Consumer Data Right (CDR), which requires all banks to “give consumers greater access to and control over their data”¹. Banking is only the first of many industries to which CDR will apply.
Although CDR is quite complicated to implement, ForgeRock offers a fully-featured platform that can be used to solve many CDR implementation challenges. Futhermore, the ForgeRock CDR Accelerator can help; it solves some of the primary challenges faced during a CDR implementation, including the core consent flow.
Additionally, with the help of a ForgeRock partner and guidance as to how best to use the ForgeRock platform to tackle CDR’s complexity, clients can quickly start and smoothly complete their compliance journey.
This article will give a brief recap of why CDR exists and what it is, followed by a walkthrough of the ForgeRock CDR Accelerator. In the second part of this series, we will explore how you could use it to accelerate (pun intended!) your bank’s CDR implementation project.
Why do I need CDR, and what is it?
If you have ever used an online budgeting application or perhaps filled out an automated loan application online, then you may have been asked to provide the username and password for your bank account. That way, the website could scrape your transaction history. While on the surface this goes against everything we’ve been told about password security — “never share your password with anyone” and “we will never ask for your password” — this is common practice in the financial services industry.
This password-sharing practice is one of the main reasons banks require Multi-factor Authentication (MFA) when adding a new payee. They know their customers share their passwords with online financial tools, which increases the risk of those passwords being obtained by malicious actors. With MFA, if one of these services is breached and customer credentials are exposed, the bank may be able to limit the damage so the attacker would only be able to read transaction histories and transfer relatively small amounts to the customers’ existing payees.
Enter the Consumer Data Right (CDR), a collaboration between:
- The Treasury
- Australian Competition and Consumer Commission (ACCC)
- Consumer Data Standards Program (part of CSIRO’s Data61)
- Office of the Australian Information Commissioner (OAIC)
- and consultation with the industry and other interested parties.
The CDR is essentially a collection of legislation, rules and technical standards that define how consumers may control the sharing of their data. The standards were developed by Data61, with influences from the UK’s Open Banking². In the data sharing process defined by the standards, there are three primary actors:
- Data Holders (e.g. Banks, other industries are coming soon)
- Data Recipients (financial tools: budgeting apps, loan applications, etc.)
- Consumers (customers of the banks wanting to share their data)
The other main actor is the CDR Register, the list of all Data Holders and accredited Data Recipients. However, it is not visible to the consumer when they are sharing their data.
For the banking sector, the CDR high-level process is as follows (shamelessly stolen from the CDR website):
- Consumer request to the Data Recipient to initiate sharing.
- Request from Data Recipient to Data Holder to create a sharing agreement.
- Data Holder authenticates the Consumer.
- Customer authorises disclosure by Data Holder to the Data Recipient.
- Sharing agreement is created, data can be shared.
In this way, data is only shared with Data Recipients after the Consumer has consented and a sharing agreement created. Consumers have control over the accounts that will be visible to the Recipient. Consumers can cancel the sharing agreement using the interfaces provided by the Data Holder, revoking the Recipient’s access.
Most importantly, it means that you no longer have to provide the Data Recipient with your internet banking credentials!
For further reading about the CDR itself, these links are a good starting point:
What core capabilities are required to implement CDR as a Data Holder?
Now that we understand why we need CDR and what it is, the next step is to understand what core capabilities your organisation requires to become a Data Holder.
There are five core capabilities that form the foundation of what is required to start your Data Holder CDR journey:
- CDR Compliant Data Sharing Services that provide Data Recipients with restricted access to Consumer data when an appropriate sharing agreement is in place and also kick-start the creation of sharing agreements.
- Consent Services and user interfaces for use by Consumers to manage their data sharing agreements with Data Recipients.
- Core Internal Banking APIs that can be leveraged to retrieve customer and account data for use by the Data Sharing Services and Consent Services. These may already exist, e.g. to power Internet banking services.
- A Sharing Agreement Data Store that keeps a record of the sharing agreements that have been created between a Consumer and a Data Recipient.
- Metadata Cache (a local copy of the CDR Register) that Data Holders are required to keep up to date within five minutes of the change occurring on the CDR Register.
The above list is not the complete list of components required to become a Data Holder; additional items such as metrics and key management are also required. See the Data Holder components on the CDR Register Design Reference website for further details.
Making use of the ForgeRock CDR Accelerator
Now, let’s get into the exciting part that is, making the most of the ForgeRock CDR Accelerator. As expected, the Accelerator makes use of the ForgeRock platform’s modern identity and access management (IdAM) capabilities.
The CDR accelerator focuses on four key areas:
- Onboarding — Dynamic registration of Data Recipients through CDR Compliant Data Sharing Services.
- Consent — Allowing customers to share their data from the Data Holder to a Recipient using Consent Services and user interfaces and maintenance of agreements in the Sharing Agreement Data Store³.
- MetaData Cache — Fulfills the Metadata Cache capability, and is essentially ready to go with very few customisations required.
- Access Authorisation — Enforcement of the sharing agreements when accessing the CDR Compliant Data Sharing Services.
To help you get started, the accelerator is fully self-contained, removing the need to request developer access to the CDR Register, as the accelerator contains a mocked implementation.
Understanding the CDR Accelerator and its components
The CDR Accelerator consists of a set of six pre-configured Docker containers that are central to the Data Holder implementation:
- CDR Register Mock — A mocked implementation of the CDR Register.
- Identity Gateway (IG/OpenIG) — An API gateway that sits between Data Recipients and the CDR Compliant APIs to enforce the sharing agreements, handle mutual TLS, verify OIDC tokens, etc.
- Access Manager (AM/OpenAM) — Responsible for authentication and authorisation.
- Identity Management (IDM/OpenIDM) — Maintains the Sharing Agreements Data Store. Also synchronises the CDR Register to the MetaData cache.
- Directory Server (DS/OpenDJ) — External DS, which contains the IDM repository, the CDR User Repository (including the sharing agreements) and the Metadata Cache.
- Data Holder Mock — A lightweight mock implementation of the Data Holder API, including the CDR Consent User Interface, CDR Compliant Data Sharing APIs, and Core Internal Banking APIs.
Additionally, the Accelerator provides some supporting containers that implement a mock Data Recipient, including a Consumer-facing application for the Recipient. This inclusion (along with a mock SMTP implementation and the mock CDR Register) makes the Accelerator self-contained — it has everything you need to test the creation of sharing agreements and the movement of data governed by those agreements. This allows you to progressively swap out the services intended to be replaced with their real counterparts while being able to test everything — no need for a big bang integration.
Wrapping Up…
So far, we have seen why the CDR is so important to consumers — it empowers them to control how their data is shared between different entities. We’ve also seen that implementing the CDR is challenging for Data Holders and explored how the ForgeRock Accelerator can significantly speed up (and lower the risk) of implementation.
In part two, we will explore what is needed to take the CDR Accelerator into production as well as some interesting observations about its implementation.
Stay tuned!
[1] https://www.accc.gov.au/focus-areas/consumer-data-right-cdr-0
[2] One surprising thing I discovered about CDR is that some of the standards development appears to have been done out in the open using GitHub issues with banks replying directly with their feedback.
[3] The accelerator solves the initial data-sharing consent request, but not ongoing management of the consent.
