.png)
Note: This article was first published by Deloitte and FintechNZ in the New Zealand Fintech Pulsecheck report which was released on 7 July 2022. A webinar was held at the same time and a recording can be viewed here.
No.
This article identifies 5 key friction points between open finance stakeholders, and presents some spiky views on how these issues should be addressed.
I lead the team at Akahu - an intermediary that provides open finance infrastructure for New Zealand. We give consumers a simple way to connect their financial accounts to trusted products.
To deliver open finance infrastructure, we maintain a suite of data integrations with financial institutions. This work began in 2013. Over the last 9 years, our team has had a front row seat as open finance has developed in New Zealand.
Let’s get into the nitty gritty.
In the late 2010s, pressure started mounting on banks to “open up” and make APIs available to customers. This pressure came from international trends, and from products like Xero where customers were clearly seeing value from having connected bank feeds.
The major New Zealand banks own a company called Payments NZ (PNZ), which is tasked with managing payment clearing systems. In 2018, work began to develop common API standards for New Zealand, and this work transitioned to a new PNZ subsidiary called API Centre in 2019. A generous interpretation is that the banks wanted to proactively develop open banking in New Zealand for the benefit of consumers. A sceptical interpretation is that the banks wanted to proactively develop open banking to control the process and avoid the rules being dictated to them through legislation.
Then the Government turned up the heat. In late 2019, the Minister of Consumer Affairs warned banks of “concerns that the current pace and scope of progress risk not delivering the full benefits that could be realised with open banking for consumers”. In 2020, the Government began public consultation around potential “consumer data rights” (CDR), which would set legislative account connectivity rules for banking and other sectors. In 2022, the Government confirmed that it will implement CDR.
Now that it’s clear that rules will be set through CDR, the banks are advocating for the API Centre standards to be folded into CDR.
I agree that CDR should largely adopt the latest version of the API Centre standards. It makes sense to leverage the good work that’s already been done by API Centre to develop these standards, and by some of the participating banks that have been developing APIs to meet them.
But some aspects of the standards need to be changed. For example the payment consent rules require the destination bank account to be defined at the time a consumer grants consent. This excludes some valuable use cases that have sprung up overseas such as peer-to-peer payments, payouts, and marketplace payments.
We should use the API Centre standards as a starting point for banking CDR rules, but should make sure to understand and correct any aspects that will prevent important use cases.
There’s an open question regarding the entities that will govern CDR in New Zealand.
In Australia, where a similar CDR regime began rolling out in 2020, the responsibilities are shared across the Office of the Australian Information Commissioner (OAIC), the Australian Competition and Consumer Commission (ACCC), and the Data Standards Body (which is part of Treasury).
I don’t have a strong view on who should govern CDR in New Zealand. But here are the important attributes:
I think it'll be about 3 years before CDR offers a viable connectivity option. This rough estimate is based on time required to:
API compliance deadlines may be phased in over time, like in Australia and the UK. If that’s the case, then it may take even longer for CDR to cover payment initiation, joint accounts, business accounts, and other functionality that tends to be pushed back into later phases.
While we wait for CDR to rollout and mature, there are 2 traditional methods to deliver account connectivity that don’t rely on purpose-built functionality from banks:
People grumble about these traditional methods, because they require consumers to share their login credentials in order to connect their accounts. The grumblings are fair - sharing login credentials is a suboptimal solution, and it means that consumers need to have high trust in the intermediary and the product they’re connecting their accounts to. The problem is that there’s no better alternative available in New Zealand yet.
In Australia, the topic of screenscraping and reverse engineered integrations was explicitly discussed in Senate hearings as the Australian CDR rules developed. Australian regulators made it clear that there was no intention to restrict or block those existing methods, and that gave fintechs more confidence to get started or keep going, rather than waiting for CDR. I think that the Government should take a similar public stance in New Zealand.
That’s a self-serving point, given that most of Akahu’s account connectivity relies on these methods. But here’s why I think it’s a defensible position.
First, these methods have operated in New Zealand for over a decade without evidence of consumer harm. Estimates run as high as 1 in 3 Kiwis having used a screenscraping service. For example:
.png)
Second, we should pay attention to countries that already have a thriving open finance ecosystem. For example in the US, more than 1 in 4 adults have connected bank accounts to other products like Venmo, Cash App, Coinbase, and Robinhood using traditional methods. International experience points towards positive outcomes through traditional methods (which matches the New Zealand experience to date).
Third, the most important way to bring open finance to life in New Zealand is through great products like Xero, where bank account connectivity was harnessed to significantly improve the UX of accounting. We’ll hold back our local fintech market if we don’t continue to build momentum before CDR.
Consumers should be very clear about how these traditional methods work. And where possible, products should provide alternative options alongside account connectivity. But these methods should not operate in a grey zone, and Government acknowledgement would clear that up.
Bank’s may choose to offer API access through a contractual arrangement. Xero is an example of an organisation that grew big and powerful enough to negotiate contractual access with New Zealand banks.
Contractual access can be better than connecting via the web apps or mobile APIs of the banks. The key reason is that the end user completes authentication and authorization directly with the bank, rather than via an intermediary like Akahu.
From Akahu’s perspective, there are two prerequisites to arranging contractual access with banks.
1. The bank's APIs must be feature-complete
There’s no point switching from traditional methods to contractual access if it’s a backwards step in terms of functionality.
The banks are all at differing stages of API-readiness. Only one of the major New Zealand banks has a suite of APIs that we consider to be somewhat functional (shoutout to BNZ). Most fintech products are not viable with that patchy coverage. So right now, we can’t support our app customers through contractual access alone.
2. The bank's contractual terms must be reasonable
Even if a bank has feature-complete APIs, contractual access can be prohibitive for Akahu and our app customers if the terms are unreasonable.
These are the difficult aspects that we’ve experienced:
Direct contractual access will be largely swept away by CDR, which will install an accreditation process and set the terms of access. But in the interim, these issues make it difficult to provide account connectivity through contractual access.
These are some of the current issues that we’re seeing debated (publicly or privately) at the coalface. If you’ve read this far, I hope I’ve delivered on the promise of spiky views and a non-wafty opinion piece.
To the innovators in this space, I can’t wait to see what you build.
