The government has been talking about regulating access to financial data since 2019. Draft legislation was recently released for public consultation (Akahu's submissions are published here).
This article summarises the proposed law, and provides some commentary on the contentious areas.
The Customer and Product Data Bill is colloquially referred to as a “consumer data right” or “CDR”.
CDR will make it simple to access your data that’s held by an organisation (like a bank). You’ll also be able to approve a 3rd party to access your data on your behalf.
CDR is a high level legislative framework that sets out general rules. A sector can be “designated” under this framework through secondary regulation. The government has confirmed that banking will be the first sector to be designated.
When a sector is designated, detailed rules will be developed to define the data holders in that sector, and the data that must be accessible.
Other sectors like energy, telco, insurance, and health may be designated at some point.
You might want to connect your Kiwisaver, investment, and bank accounts into a single app so that you can see an aggregated view of your financial life.
You might want to connect your bank account to MSD before receiving a payment in order to prove that you are the holder of that bank account and to verify the account number.
You might want to connect your transaction data to a budgeting app in order to automate your household budget.
You’re not wrong.
If you’ve applied for a home loan within the last 10 years, your broker probably invited you to connect your bank accounts to automate most of the application process.
If you’ve bought flights from Air New Zealand or renewed your car rego online at Waka Kotahi, you may have noticed the option to pay from your bank account via a 3rd party service.
If you’ve used accounting software like Xero or Solo, you’ll have noticed that your bank transactions magically show up every day without needing to manually import them.
The current methods of data connectivity can be improved.
Remember that example above where your broker invites you to connect your bank accounts to automate your home loan application? The broker will outsource that job to another 3rd party service, who will need your bank login credentials in order to fetch the relevant data on your behalf. Sharing your login credentials is suboptimal. No one likes this aspect of the current methods. Banks certainly don’t like this method either (but they like getting home loan applications from brokers, so you don’t hear them complaining about this particular use case). CDR will enable consumers to authenticate directly with their bank, so that login credentials don’t need to be shared with a 3rd party.
That’s the main upgrade that CDR will deliver. But there’s a laundry list of additional value that CDR will provide to consumers if it’s designed well:
There are similarities, because the Privacy Act gives us the right to request access to our personal information that's held by other organisations. But there are some very important differences.
So CDR covers some of the same ground as the Privacy Act, but it goes much further. You could see CDR as a bundle of enhanced consumer rights that are fit for our modern data-rich world.
Submissions were due on the draft bill by 24 July 2023. The bill is expected to be enacted within a year.
After that will come detailed rules for the banking sector, along with implementation deadlines for the banks to comply with those rules. We expect these deadlines to be phased in over time.
This is a similar pathway to Australia which introduced its own version of CDR in 2018, with a phased rollout in the banking sector that continues to this day.
We guesstimate that it will be 3+ years before the CDR regime delivers better functionality for consumers than the current methods of accessing and sharing data.
If you’ve got this far, then let’s quickly cover the mechanism for exchanging data under CDR.
Data holders will be required to provide APIs to comply with the rules. An API is an “application programming interface”, which is a defined system for enabling computers to communicate with each other. Each data holder (like a bank) will have an API that sits there patiently waiting for CDR requests. When the API receives a valid request, it will respond to that request in real time. So CDR requests and responses will be processed by computers rather than humans.
If you want a deeper understanding of APIs, here’s a great intro article.
First, a round of applause to the team at MBIE that have written the bill. The legislation strikes a good balance between achieving the desired objectives and limiting the compliance costs for data holders. For example, unlike the CDR regulation in Australia, our New Zealand bill relies on existing law such as the Privacy Act where possible. That will significantly simplify things for organisations that participate in the CDR system.
However there are always areas of contention. Here are some of the key ones.
Product data
Everyone agrees that consumers should have access to their own data. But the bill also enables generic “product data” to be designated within the scope of sector rules. For example in the banking sector, banks might need to deliver information about interest rates and fees via APIs.
We question whether this is necessary. In a sector like banking, product data can often be scraped from public websites without any need for consumer consent.
We also question whether it’s desirable. These types of prescribed product disclosures could have unintended negative consequences. For example they could encourage data holders to optimise for the prescribed features instead of innovating their products holistically.
Derived data
Data that has been “collected” from a consumer, such as name and address, will be in scope. Data that has been “generated” by a consumer, such as transaction data, will be in scope. None of this is contentious.
But the bill also leaves open the possibility for “derived” data to be in scope. This was a surprise to many that have been following the development of consumer data rights around the world. An example of derived data is an affordability assessment that has been carried out by a data holder as part of a loan application process. It’s more difficult to argue that a consumer should be able to collect and share this type of derived data with a competitor. And it’s hard to imagine how to prescribe the format of derived data, since data holders will have different processes and outputs.
We think it's ok for the bill to contain the flexibility to designate derived data if it’s warranted for a sector, but we don’t see a strong case to designate that type of data in the banking sector at this point in time.
Ongoing consents
Many important use cases involve a consumer granting ongoing access (rather than one-off access) to a 3rd party service. The bill envisages a maximum duration for an ongoing consent.
A maximum duration sounds sensible, and has some merit. But in practice, expiring consents are annoying for most consumers, and make it difficult for products like accounting software or budgeting tools to “catch up” seamlessly when data feeds are reconnected.
We think that enabling the option of non-expiring consents is important to encourage uptake of CDR. This aligns with non-expiring consents that are commonly used in other systems, such as direct debit consents with your bank, and tax agent consents with IRD. And we think that the Privacy Act contains the necessary countermeasures to protect consumers from over-collection of data by 3rd party services.
To ensure that consumers remain aware of the ongoing consents that they have granted, we suggest an annual notification to consumers regarding their active ongoing consents, with a simple mechanism to revoke any consents that are no longer wanted.
This is an important piece of legislation that will have a growing impact as sectors are designated over time. If you have something to contribute to the conversation, now’s the time.
MBIE's official information is available on this page.
.png)
