On 22 June 2023, The Ministry of Business, Innovation and Employment (MBIE) opened consultation on an exposure draft of the Customer and Product Data Bill, which will allow customers to safely access and exchange data held about them.
Here's a link to our general commentary on the proposed legislation.
Akahu's formal submissions are published below. The numbers correspond to the numbering in MBIE's response template, which can be found on this page.
We strongly support the approach of relying on the Privacy Act wherever possible. This approach simplifies participation in the CDR regime and will significantly help to drive adoption.
Extending the Privacy Act principles via the CDR regime
In our view, there are two ways in which the Privacy Act principles could be explicitly extended through the bill or regulations:
These two extensions would represent a significant extension to the Privacy Act boundaries. However in Akahu’s experience, organisations that collect sensitive information tend to treat all such information in the same way, rather than siloing personal information and applying a higher standard to that data alone. We’re unaware of any operational difficulties that organisations would face if they were required to comply with the suggested extensions.
Privacy Act and ethical standards
Extending the Privacy Act principles as suggested above would also address the issue of whether to apply ethical standards to participants in the CDR regime.
In our view, it’s inappropriate to develop ethical standards in parallel with the constraints that are defined in the Privacy Act. The proposed extensions would provide appropriate protections for all relevant CDR data, and would enable a clear and consistent approach to data protection in New Zealand.
If the Privacy Act is extended as suggested above, we think that section 35 would be unnecessary because the Privacy Act provides appropriate protection around the collection of data.
Ongoing consent is important
Ongoing customer consent is critical for many use cases. To provide some data from Akahu’s operations:
Limited duration is sometimes appropriate when requesting consent
The duration of a customer consent should be tailored to the use case. If there is no purpose in collecting data for an extended period of time, then it would be appropriate for the accredited requestor to limit the duration of the consent request. The Privacy Act Principle 1 provides a guardrail on this point. Accredited requestors should be able to define a limited duration of an ongoing consent.
However we rarely see use cases where limited consent duration is apparent at the time of granting consent. The appropriate duration of consent is usually related to use of a product, and a customer usually won’t know how long they’ll use the product for at the time of granting an ongoing consent.
Using notifications for non-expiring consents
In the absence of a regulatory framework, Akahu developed our own rules around ongoing consents that we enforce with our app customers. These rules evolved over time, and during 2022 we landed on an approach that now gets high satisfaction from both customers and apps.
Non-expiring consents are important for adoption of the CDR regime
We believe that enabling non-expiring consents is important to encourage uptake of the CDR regime. For example, if a merchant such as an energy retailer is comparing direct debits which don’t expire, versus a CDR consent that will expire each year, it’s hard to imagine that the energy retailer will choose to use the CDR regime for customer payments.
We believe that the Privacy Act contains the necessary countermeasures to protect customers from over-collection of data via a non-expiring consent, especially if the Privacy Act principles are extended as we suggest in response number 1.
Accredited requesters should be able to terminate an authorisation under clause 31.
For example if a customer switches their tier of subscription with an accredited requester’s product, and CDR data is no longer required, the accredited requester should be able to terminate the authorisation. This will allow the accredited requester to align with the Privacy Act Principle 1 around the purpose for collection of information.
We provide comments in relation to intermediaries and consent in response number 11.
When referring to modification of a consent in section 30(3)(d), we assume that the technical process would involve revoking an existing consent and creating a new consent.
If deemed necessary to include consent modification requirements in lower level regulations, those requirements should be limited to:
In our experience, many use cases require "all or nothing" consent. It would be difficult for many accredited requestors to deliver a product that caters to a range of consent scopes, other than varying limits to duration or changes to connected accounts.
Similarly, we don’t think it’s feasible to enable a customer to modify an ongoing consent via a data holder’s consent dashboard. It would be very difficult for a data holder to convey the impact of modifying a consent, as the data holder won’t have context about the accredited requestor’s product. We support the ability to view and revoke consents through a data holder’s consent dashboard, but not the ability to modify them.
We think it’s important to retain flexibility as to how consent obligations are delivered. For example, it may be beneficial for a data holder or accredited requestor to deliver consent-related information via both apps and email. This approach may help customers to avoid consent fatigue, retain more information, and more easily search for details such as consent management and dispute information.
We do not see any related issues with the draft bill, so this comment regarding consent flexibility is intended for consideration with lower level regulations.
We note the intent to consider delegating standards development to relevant entities such as industry bodies.
We support the adoption of existing work where relevant. For example we support the adoption of the API Centre standards into the CDR regime.
However we have concerns about delegating standards development to industry bodies due to potential conflicts. In our experience, industry bodies tend to be biased towards industry incumbents, which will often sit in tension with the customer-centric intent of the CDR regime. This bias is often covert rather than overt, naturally flowing from the weight of participation from incumbents with deep resources. It can show up in subtle ways, such as the level of ambition with standards, or the prioritisation of functionality, or the service levels.
If standards development is delegated to industry bodies, we think it should be simple and quick for the regulator to step in and block, modify, or make its own decisions regarding standards. The regulator should also be able to set parameters around any entity with delegated authority, such as ownership, representation, and decision making processes. These controls will protect the ability to develop standards that align with the intent of the CDR regime.
We think that any other sector will require standards that are significantly different from the API Centre standards.
In the banking sector, most customers have login credentials to online accounts, and many customers have downloaded mobile apps that can be used by data holders to simplify authentication by a data holder.
Data holders in other sectors that are considered for designation may not have the same ease of authenticating a customer. For example if DIA (passport-related data) or NZTA (driver licence-related data) or IRD (income, KiwiSaver, and tax-related data) became data holders in a designated sector, the draft bill would currently require those organisations to authenticate customers directly. That is a departure from the current methods of interacting with those organisations as third parties, where the third party obtains customer consent and the data holder trusts their accreditation of the third party instead of directly authenticating the customer.
We recommend modifying the wording in clause 37 so that lower level regulation can enable appropriate authentication requirements for a sector. For example, section 37(2) could be modified to “Before the data holder provides the service, the data holder must verify the identity of the accredited requestor, and must be satisfied that the customer’s identity has been verified (either directly by the data holder, or by the accredited requestor).” Then the current wording of section 37(5) enables lower level regulation to contain further requirements for a designated sector.
Intermediaries and outsourced providers
Intermediaries typically represent the majority of requests in an open banking ecosystem.
We strongly support the simple accreditation framework, which does not create a special tier for intermediaries. However this could lead to potential issues where an intermediary (as an accredited requestor) is required to carry out all obligations of an accredited requestor, even if certain obligations would be better delivered by a downstream service.
For example, an intermediary should not be required to provide a dashboard to enable customers to manage ongoing consent. If an intermediary could not pass on this obligation to a downstream service, it would have to collect and verify information about each customer so that it can authenticate the customer when granting access to the dashboard. It would also be more intuitive for the customer to manage the ongoing consent with the relevant downstream service where they have the primary relationship.
These potential issues would be resolved if an intermediary is able to satisfy CDR obligations through the existing outsourced provider provisions, which would enable an intermediary to delegate delivery but remain responsible for meeting an obligation. If the outsourced provider provisions already intend to capture these scenarios, then no further action is required.
Other issues relating to intermediaries
There are some technical issues that arise when an intermediary is acting as the accredited requestor for a downstream service. For example:
These types of issues are best dealt with in lower level regulation, but it’s important that there are no blocking provisions in the primary legislation.
We think that the bill should enable insurance requirements to be set in lower level regulation. This will enable any requirement to evolve more rapidly to reflect commercial availability and developments in protectable risks.
In our experience, cyber policies contain the most relevant protections against foreseeable risks for our business. We don’t see meaningful protection from professional indemnity, theft, or other policies that we have reviewed, however the risks will be different for each accredited requestor.
We strongly support the decision to not create a separate class for intermediaries.
We strongly support the simple approach to accreditation tiers. There can be a temptation to create more tiers, but extra tiers only make sense to the extent that there are meaningful differences in the accreditation requirements for each tier.
With one-off consent, we think that customers have a reasonable intuition about the trust they’re placing in the accredited requestor, regardless of whether the consent relates to data or payments. For example, with one-off data consent for a loan application, or one-off payment consent for an online purchase, the customer can make a relatively straightforward assessment about whether they trust the accredited requestor to carry out the proposed actions.
In our experience, there is a meaningful difference in risk between:
We strongly support the inclusion of businesses in the CDR regime. We don’t consider that specific use cases need to be considered in the draft bill.
As discussed in response number 1, we strongly support the approach to rely on the Privacy Act wherever possible.
In our view, there are two ways in which the Privacy Act principles could be explicitly extended through the bill or regulations:
With these extensions, CDR data would have appropriate protection. Separate ethical requirements would be unnecessary and undesirable.
We think that 1(a) should refer to “customer” instead of “individual” so that the scope of that purpose includes all legal persons.
It’s appropriate for data holders to have the ability to exercise judgement and decline a valid request if they have reasonable grounds for doing so.
For example if a data holder has reasonable grounds to suspect that a valid request is fraudulent, then the data holder should be able to reject that request.
It’s important that this flexibility is not abused by data holders. So there should be appropriate penalties to deter behaviour that does not align with the intent of the legislation.
We support the ability for data holders to apply these considerations for refusing access to CDR requests.
We strongly encourage reliance on the Privacy Act. We think that customers will benefit from consistency in disclosure, rather than unusual data policy disclosure.
We think that data holder compliance should be externally monitored and reported on. This will deliver better accuracy and accountability.
We think that it’s appropriate to include a cap.
We agree that disputes between customers and data holder or accredited requestors should be dealt with as proposed.
However a dispute between a data holder and an accredited requestor should be dealt with via MBIE or a relevant entity that is granted delegated authority under the CDR regime.
We question whether the inclusion of product data is:
We think it’s useful to retain the ability to include product data in a sector designation, but we think that power should be used carefully.
The discussion document states an intention to include "derived data, and data derived from derived data".
We think that data a customer has "provided" or"generated' should be in scope, but derived data can be problematic. For example:
We think it’s useful to retain the ability to include derived data in a sector designation, but we think that power should be used carefully.
Non-functional requirements, such as API availability, response times, data caching/recency, and throttling, are important for adoption of the CDR regime. These factors have a material impact on the value of the CDR regime for accredited requestors and customers.
If non-functional requirements are not set appropriately and enforced, there is less incentive for participants to migrate from alternative access methods that may offer better performance.
This risk is heightened if standards development is delegated to industry bodies, where there may be an incentive to simplify implementation for data holders to the detriment of accredited requestors and customers. For example the API Centre standards do not contain mandatory requirements regarding caching and throttling. This enables banks to serve old data while still being considered compliant with the standards.
We recommend that non-functional requirements are given careful consideration in lower level regulation.
We expect that intermediaries will adequately address demand from customers that want direct access. For example Akahu provides “personal apps” free of charge to customers that want programmatic access to their own accounts. We expect to continue providing customers with this type of direct access (provided that the costs of doing so via the CDR regime are not prohibitive).
We think it’s useful to retain the ability to include direct access in a sector designation, but we think that power should be used carefully to avoid delaying the rollout of higher priority functionality.
Current connectivity methods
There are a number of existing methods for third party services to interface with bank systems in New Zealand, with the most common being screen scraping, reverse engineered integrations, and SFTP file sharing.
The most common applications of these methods are:
We estimate that around two million New Zealand customers have connected a bank account to a third party service over the last two years.
Statement of support for existing connectivity methods
Many organisations in New Zealand are interested in building enhanced functionality that relies on customers connecting their bank accounts.
However some of this innovation is currently being stymied due to lack of clarity as to whether existing connectivity methods, particularly screen scraping and reverse engineered integrations, will be discouraged by regulators.
In Australia, during the development of their CDR regulations, ACCC and ASIC were questioned on this topic during a Senate hearing. They responded that they had not seen evidence of consumer harm from the existing methods of screen scraping and reverse engineering, and they did not plan to block or discourage them. That statement gave participants in Australia more confidence to continue innovating while the Australian CDR regime was being developed and phased in.
There are comments to this effect in the discussion document on pages 4 and 23. We think that further public statements reinforcing this position would encourage competition and innovation in New Zealand while our own CDR regime is being developed, resulting in better outcomes for customers. We think that it’s reasonable to consider discouragement of existing connectivity methods at a point in time when the CDR regime has demonstrated a viable alternative system.
Our team is here to answer any questions that you may have.