Background

On 31 July 2023, the Commerce Commission published a consultation document regarding payments between bank accounts. This initial consultation paper cites a lack of payment innovation compared to other countries, and slow progress from industry-led attempts to develop an open banking ecosystem. Using powers pursuant to the Retail Payment System Act 2022, the Commerce Commission has been considering potential designation of the interbank payment network. Practically speaking, this would enable the Commerce Commission to create rules for open banking payment APIs.

On 22 February 2024, the Commerce Commission published an update on its work. Akahu's commentary on this update can be found here.

On 27 March 2024, the Commerce Commission released a consultation paper, which is seeking feedback on it's recommendation to proceed with designation of the interbank payment network. If the Commerce Commission decides to proceed with its recommendation, the decision will go to the Hon Andrew Bayly, Minister of Commerce and Consumer Affairs, for a decision.

Akahu strongly supports the recommendation to designate the interbank payment network. We think that regulation is clearly required in order to create a thriving open banking ecosystem.

Our written submissions to the Commerce Commission are published below. The question numbers below correspond to the numbering in the consultation paper (we have skipped questions that we did not respond to).

‍1. Do you agree with our preliminary position that designation of the interbank payment network will promote competition and efficiency in the retail payment system for the long-term benefit of consumers and merchants? If not, why not?

Yes, we agree.

However, we think that intervention is clearly necessary to address the known issues that are highly unlikely to be resolved by industry, even with a greater threat of regulation.

So instead of proceeding with designation and then waiting to see if regulation is required, we think that the Commerce Commission should plan to immediately consult on proposed interventions after an Order in Council has declared the retail payment network to be a designated network.

‍2. Do you agree that there are features  of the interbank payment network that are reducing or likely reducing  competition and efficiency of the network or the system?

Yes, we agree.

‍3. Do you agree that there is conduct of participants of the interbank payment network  that are reducing or likely reducing competition and efficiency of the  network or the system?

Yes, we agree.

In our view, it’s clear that a regulator needs to step in and set the rules for open banking in New Zealand. There are many issues that industry has been unable or unwilling to resolve over the last seven years, such as:

1. Control of access to standardised APIs: Banks have sole discretion over which third parties are provided with access to standardised APIs. Bank control of access to standardised APIs constrains competition and innovation because a bank is not incentivised to provide access to organisations which are seen as a threat to the bank.
2. Control of use cases: Banks have sole discretion over which use cases are supported. This constrains competition and innovation because a bank is not incentivised to provide access to services which are seen as a threat to the bank.
3. Payment limits: Banks set variable (and often low) payment limits that do not cater for many use cases that exist today. For example if one or more banks have low payment limits, then a product like automated payroll payments or automated tax payments will not be viable. In our experience, the bank-imposed open banking payment limits are significantly lower than payment limits for other bank channels, which limits the viability of the open banking channel.
4. ‍Control of payees: Banks may require manual approval of any new destination payment account. This is not required when a customer initiates a payment in bank-owned channels, and it limits the viability of the open banking channel.
5. Control of fees: Banks set fees, which in our experience can be economically unviable. This constrains competition and innovation because a bank can use fees to prevent adoption of services which are seen as a threat to the bank.
6. Control of other contractual terms: Banks can set other contractual terms which are not possible for a third party to comply with, such as insurance requirements that are not commercially available. This constrains competition and innovation because a bank can use non-financial terms to block services which are seen as a threat to the bank. As another example, in the bank contracts that we’ve seen, API access can be terminated by the bank upon notice and without cause, which makes it highly risky for third parties to invest in building a service that relies on standardised APIs.
7. Control of the customer experience: Banks provide authentication and consent flows, which in our experience can be visually unappealing and overly complex for customers. This will make it harder for third party services to gain consumer adoption. This constrains competition and innovation because a bank can take steps to decrease consumer adoption of services which are seen as a threat to the bank.
8. Conformance and performance: Banks are not bound by meaningful commitments in relation to the conformance and performance of their APIs. For example the current industry implementation plan has a non-binding target API availability of 99.5%-99.9%, which is far too low for a payment service and would not be acceptable for a bank’s own channels. This constrains competition and innovation because a bank is not incentivised to provide high quality APIs to services which are seen as a threat to the bank. To enable consumer adoption, API performance should be equivalent to the performance of APIs that are serving bank-owned channels, and non-conformance should be penalised.

4. Are there any other features of the interbank payment network or any conduct of  participants that are relevant to our consideration to propose designation?

Without a regulatory framework, each third party needs to negotiate a bilateral contract with each bank in order to use that bank’s APIs.

There is a philosophical difference at the heart of many issues with bilateral contracts. Banks tend towards the view that they are  “partnering” with third parties to deliver approved services to their customers. In contrast, the premise of open banking is to give customers enhanced access to their financial data, with the consumer in control of that access rather than the bank.

A regulator is required in order to resolve this philosophical divide. Without regulation, some or all banks will feel obliged to vet and manage third parties in order to discharge a duty of care to their customers. Historically this has given banks a reason to reject third parties or use cases on the basis of risk management. In our view, this position has been used to slow and block progress with open banking.

Regulation can solve this issue by introducing centralised accreditation and a framework for liability. We support the high level design of these components in the Customer and Product Data Bill.

9. Do you  agree with our definition of the proposed designation? If not, why not? 

Sub-clause 1(d)(ii) refers to “Third party payment providers”. We encourage the Commerce Commission to ensure that this definition is broad enough to enable different participants, such as payment service providers, technical service providers, and direct participation from merchants.

10. Do you agree New Zealand has not implemented a thriving API enabled payment ecosystem?

Yes, we agree.

As noted in the consultation paper, there is already widespread uptake of payment options that rely on suboptimal  methods. This existing activity is important, because it demonstrates the consumer demand for open banking-enabled services, and it demonstrates some of the key use cases. Without this existing market activity, both in New Zealand and offshore, there would have been no global movement towards open banking regulation because the consumer value would have remained hidden from view.

However, we don’t consider this existing market activity to be “thriving” because all participants would prefer to be  using purpose-built APIs that enable customer authentication in a bank environment. We support the migration of this existing market activity to purpose-built APIs when they are fit for purpose and accessible on appropriate terms.

11. Do you agree new payment methods through API enabled payment ecosystems are becoming more prevalent overseas? And, do you agree with how we have characterised the nature and benefits of these systems?

Yes, we agree.

12. Do you agree there is significant unmet demand in New Zealand for innovative new payment methods enabled by a thriving API enabled payment ecosystem?

Yes, we agree.

13. Do you agree with our characterisation of the minimum requirements for a functional API enabled payment ecosystem?

Yes, we agree.

We think that regulation is necessary to address some of these components, which we describe in our response to questions 3 and 4.

14. Do you agree with our concerns regarding the timeliness, partnering, transparency, and reasonableness of fees of the API enabled ecosystem that use any undesignated interbank payment network?

Yes, we agree.

As discussed in our response to questions 3 and 4, we don’t think that designation alone will solve some of the known issues. And nor will Payments NZ’s authorisation application (if approved), as we discuss in our submission[1].

We think that regulation is required in order to create a thriving API enabled ecosystem.

[1] https://comcom.govt.nz/__data/assets/pdf_file/0036/344898/Akahu-Submission-in-response-to-Payments-NZ-Authorisation-Statement-of-Preliminary-Issues-26-February-2024.pdf

15. Do you agree with how we've characterised the innovative new products and services for businesses within an API enabled ecosystem? And are there any other products and services for businesses you would like to draw our attention to?

Yes, we agree.

As noted in the consultation paper, we expect new payments services for subscription payments (like Functional Fitness[1])and bill payment solutions (like SortMe[2]).

We also expect to see seamless in-app bank payments (like Uber[3]),foreign exchange services (like Freedom Pacific[4]), peer to peer payment services, QR code payment services, refund functionality, and other services that will be enabled through a thriving API enabled ecosystem.

[1] https://functionalfitnessauckland.nz/

[2] https://www.sortme.com/bill-payments

[3] https://help.uber.com/riders/article/pay-with-a-bank-account-using-link-by-stripe?nodeId=9565452d-f503-4b33-85e0-650eb9c63415and https://support.stripe.com/questions/bank-payments-on-link

[4] https://apps.apple.com/nz/app/freedom-pacific/id1672005623

16. Do you have any other comments you would like to make?

"First mover disadvantage"

The consultation paper refers to a potential "first mover disadvantage"for banks that deliver APIs first.

Given the significant existing open banking activity that has relied on suboptimal connectivity methods for more than 15 years, we think that a bank should naturally be incentivised to meet this consumer demand with purpose-built APIs that enable authentication in that bank’s environment. This would be an advantage (rather than a disadvantage) for the bank’s customers.

For a bank to consider that being a first mover with open banking APIs is a disadvantage, it must consider that the value of providing its customers with amore secure authentication process is not sufficient to outweigh the costs involved with delivering APIs.

We see the resistance to delivering open banking APIs as an example of the lack of investment in fundamental technology that is referenced in the CommerceCommission’s draft market study report. 

Pricing

The Commerce Commission states in its update[1] that pricing “should enable commercially viable business models for both parties to create incentives for both parties to develop, iterate and use APIs and should be competitively neutral.”

We think that this objective will be unachievable if open banking APIs are assessed as a standalone business unit of a bank. Instead, we think that payment APIs should be seen as part of the fundamental payment services of a NewZealand bank.

Banks make the bulk of their profits by paying low rates of interest to retail depositors, and lending those deposits out at much higher rates. As noted in the Commerce Commission’s draft market study report, “Combined, the major banks and Kiwibank hold in excess of $58b in deposits not bearing interest.”

If these deposits were held in an ESAS account earning interest at the official cash rate, it would currently generate $3.19 billion in “risk-free” gross profit each year for our largest five banks. This does not include the margins which are generated from deposits in savings and term deposit accounts (which pay some level of interest to consumers), which we estimate to deliver risk-free gross profit of around $3.8 billion each year for our largest five banks.

So this deposit business generates around $7 billion of risk-free gross profit for our largest five banks each year. Payment services are a cost of operating this deposit business. If a bank did not offer payment services, consumers would not deposit their money with that bank, and that bank would lose its primary driver of profitability.

We think that a bank’s cost recovery for providing open banking payment APIs needs to be considered in the broader context of its deposit business, which is how bank payment services are currently cross-subsidised, rather than as a standalone business. 

[1] Annex A, paragraphA13, https://comcom.govt.nz/__data/assets/pdf_file/0017/344132/Retail-Payment-System-Update-on-our-Payments-Between-Bank-Accounts-work-22-February-2024.pdf

Scenarios where open banking APIs are unavailable

We suggest following the UK[2]in requiring banks to support existing connectivity methods if a bank’s open banking APIs are unavailable or insufficient.

Applying rules to existing connectivity methods has been described as “screen scraping plus” in the UK, because the rules require relevant sharing of information between the bank and third party, and include appropriate obligations for third parties. 

We think that setting rules around existing connectivity methods would support the transition of existing activity across to purpose-built APIs over time, and incentivise the timely delivery and quality of those purpose-built APIs, while still enabling competition and innovation in the near term.

[2] For example see paragraph 17.91 from the Financial Conduct Authority, https://www.fca.org.uk/publication/finalised-guidance/fca-approach-payment-services-electronic-money-2017.pdf