Akahu submissions: Payments between bank accounts

Intro

On 31 July 2023, the Commerce Commission published a consultation document regarding payments between bank accounts.

The 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. The Commerce Commission is now considering setting rules to force banks to deliver open banking payment APIs, and the terms of access to those APIs.

Banks have staved off regulation since 2017, saying it’s unnecessary because bank-owned Payments NZ is coordinating work across banks to deliver consistent open banking APIs.

As early as 2019, the Government started warning banks about their slow progress, making it clear that regulation would be considered if the industry does not deliver acceptable outcomes itself.

In 2023, the industry-led version of open banking has still failed to materialise. The key issues are:

• Early versions of the industry standards are basic and do not support most use cases.
• Most banks have not delivered open banking APIs, even the limited early versions.
• Anyone who wants to use bank APIs needs to negotiate an access agreement with each bank. There is no pressure on banks to present palatable terms, or even to provide access to the APIs if the bank doesn’t want to.
• The industry standards have significant gaps. For example there are no performance requirements for APIs, and each bank has discretion to impose different rules around important components like single payment limits. As a result, there is lack of confidence that the industry-led APIs will deliver a workable foundation to support innovative payment products.

Akahu's written submissions to the Commerce Commission are published below. The numbers correspond to the numbering of questions in the consultation paper (which begin on page 56).

#5 Do you agree with our view that competitive pressure in the payments between bank accounts landscape could be increased by enabling an environment where payment providers develop innovative options to make bank transfers? If not, why not?

Yes, we agree.

#6 Do you agree that we have captured the existing benefits and problems with the traditional method of initiating bank transfers? If not, what other benefits or problems exist?

Yes, the benefits and problems have been captured well. 

We have two additional comments:

• Card details and physical cards are often stolen and used to initiate fraudulent transactions. Payments solutions based on bank transfers tend to have stronger authentication processes.
• Small merchants, and merchants that trade on an infrequent basis, face disproportionate costs in setting up and paying for card payment facilities. Payment solutions based on bank transfers can be more accessible and cost-effective for these merchants.

#7 Do you agree with how we have described and ranked the different methods for payment providers to access the interbank payment network to initiate payments? If not, why?

Yes, we agree with the rankings, and largely agree with the descriptions.

Standardised open APIs

Banks currently have sole discretion to decide whether to grant a third party with access to standardised APIs, and the terms of that access. Therefore we consider that the current industry-led approach falls short of the description in paragraph 3.17.3, as it cannot be considered “open”.

Reverse engineered mobile APIs

We consider that reverse engineered mobile APIs have additional advantages that are not described:

• The connection process involves the registration of a new mobile device. Device registration always requires two factor authentication, which is not always required for other connectivity methods.
• Any actions taken via the registered mobile device are traceable.
• A consumer can revoke an enduring consent by deleting the registered mobile device.
• If a consumer grants an enduring consent, the registered mobile device enables ongoing access without the need to store the consumer’s username and password.
• The mobile channel of a bank typically has more constraints than the web channel, which has the effect of reducing the technical scope of access.

Paragraph 3.21.1 states that a payment provider can “access a consumer’s financial data without the need for consent or formal agreements with the bank”. The reference to “consent” in this statement could be interpreted as applying to either the consumer’s consent or the bank’s consent. If the statement is intended to mean that a payment provider can access data without the consent of the bank then we agree, but if it is intended to refer to consent of the consumer then we disagree with that part of the statement.

Both screen scraping and reverse engineered mobile APIs

A bank and a third party may agree on contractual terms for access to web or mobile interfaces. For example Akahu and Rabobank have agreed on terms that govern Akahu’s use of specific Rabobank APIs. This contract allocates liability in the case of loss, and therefore addresses the point raised in paragraph 3.21.3 regarding consumer redress.

A bank and a third party may agree on ways to clearly identify the third party’s actions. For example Akahu has arrangements with banks to identify our traffic using HTTP request headers, IP whitelisting, and other forms of metadata.

Setting rules for existing methods

If Commerce Commission proceeds with designation, we encourage regulation of existing connectivity methods. For example, the UK implementation of PSD2 acknowledges that fallback methods are necessary until purpose-built APIs are proven to be effective. These fallback methods have been used extensively in the UK due to poor performance of purpose-built APIs.

Paragraphs 17.85 to 17.97 of the FCA guidance contains some requirements that could be considered in New Zealand. We would welcome a dialogue with Commerce Commission on the types of appropriate controls that could be introduced.

#8 Are there other key features of the payment initiation network access methods you would like to draw to our attention?

Screen scraping

Paragraph 3.23.1 states that “banks may not prefer this method as it can be less secure than using APIs, can put a strain on the bank’s systems and the payment provider does not pay the bank for access.” 

We agree with that statement, but note that all New Zealand retail banks use screen scraping extensively in their own lending operations (either via suppliers that use screen scraping, or using screen scraping services directly).

Write-access versus read-access

We have observed some commenters drawing a distinction between “read-only” and “write-access” screen scraping. This comment is usually made in support of using screen scraping for lending purposes, while criticising its use for other purposes such as initiating payments.

This purported distinction between “read-only” and “write-access” screen scraping is misleading. If a consumer is sharing web login credentials with a third party, those credentials, if misused or leaked, enable payment initiation. So the same issues apply to all uses of screen scraping, regardless of whether the consumer proposition is related to data or payments.

Demonstrating consumer demand

In our view, the global trend towards open banking regulation has clearly been triggered by the rise of the non-regulated methods described in the consultation paper. Without those participants demonstrating consumer demand, and putting pressure on banks to provide purpose-built APIs, the trend towards open banking regulation would not have begun.

We think it’s important to retain this pressure in order to promote competition and innovation. If a regulated system is well-designed, then the existing participants will be incentivised to migrate to the regulated system instead of using the current methods.

We strongly recommend that non-regulated methods are not restricted in any way, at least until equivalent functionality is proven to be working effectively in a regulated system.

#9 Do you agree that these API related requirements are sufficient to enable an environment where payment providers can develop innovative options to make bank transfers? If not, why?

We agree that the three requirements are correctly identified at a high level. However it’s the details that will dictate whether innovative payment solutions are enabled.

To provide an example on each of the three requirements:

• API standards: Current industry standards (even the most recent published version) do not deliver sufficient functionality to support most of Akahu’s customers that use our payments API. So the standards would need to develop significantly in order to support many innovative solutions.
• Delivery: When banks have delivered against standards in other countries, there has typically been a multi-year period before the performance of those APIs becomes equivalent or better than alternative methods. So there can be a large gap between delivery and acceptable performance.
• Terms of access: Accreditation and terms of access need to be centralised and managed by an independent body in order to be effective.

#10 Do you agree with our view of the long-term benefits to merchants and consumers from the development of innovative options to make bank transfers?  If not, why?

We agree with the described benefits.

The consultation paper focuses on in-person scenarios. We think there are significant additional benefits in online scenarios. For example:

• Investment platforms offering consumers the ability to fund their online account. 
• Toll roads offering consumers the ability to fund their online account.
• On-demand transport services offering consumers the ability to set a default payment method.
• Parking services offering consumers the ability to pay in-app.
• Fuel and battery charging services offering consumers the ability to pay in-app.

The dollar amount of open banking payments initiated via Akahu has increased by 172% over the 12 months to 31 August 2023, and the vast majority of this volume relates to online scenarios. The benefits and problems described in tables 3.1 and 3.2 apply to these online scenarios as well, and the proposed regulatory action would enable innovative payment solutions to address them.

#11 Do you consider that the existing industry open API standards are a good starting point to enable innovative options to make bank transfers?

Yes, they are a good starting point. 

It’s important to note that the standards will need to be developed significantly to enable sufficient functionality for many innovative payment solutions. For example Akahu has 44 accredited app customers, and 24 of those apps use our payment API. Zero of those 24 would be able to continue their current payment use cases via v2.1 of the API Centre payment initiation standard that some banks have committed to delivering in May 2024. The main constraints are:

• Enduring payment consent functionality is non-mandatory in v2.1.
• Banks intend to impose different limits on the value of a payment that can be initiated via these APIs, and we understand that some banks intend to impose a low limit. The average value of an open banking payment initiated via Akahu during August 2023 was $1,122.92, and therefore low limits would be prohibitive for many of our app customers.
• Some of our app customers require a combination of both account data and payment initiation functionality. For example, a peer-to-peer payment app would consider it essential to display the available balance of a connected bank account to the user. Most account data, such as the balance of an account, is non-mandatory for the May 2024 release.
• Non-functional performance such as API availability, response times, and throttling are important for adoption of new APIs. The industry standards do not specify mandatory requirements on these non-functional matters.
• We understand that two banks intend to support the “decoupled flow”, but not the “redirect flow”, for v2.1. This will block consumers that don’t use their bank’s mobile app. We think that the redirect flow is an important fallback to ensure accessibility to open banking services.
• From what we’ve observed with the consumer experience of authenticating and granting consent with a bank, the bank screen designs are not conducive to conversion, and would therefore make it more difficult for a payment service to gain adoption through industry APIs.

#12 Do you consider the future of industry open API standards will enable innovative options to make bank transfers?

We think that industry-led API standards will enable some innovation. 

However we are concerned that some innovation will be hampered if standards development remains controlled by industry. For example, many implementations of bill payment services, peer-to-peer payment services, payroll payment services, request-to-pay, refunds, and automated payouts require an enduring payment consent which is not limited to specified destination accounts. We are concerned that banks may choose to not support this functionality through industry-controlled standards development.

We think that more value will be unlocked for consumers if standards development is managed independently from industry.

#13 What gaps are there in the open API standards for innovative options to make bank transfers?

We address this question in our responses to questions 11 and 12.

#14 Do you agree that the key barrier preventing payment providers from gaining efficient access to the interbank payment network is that the banks have not universally built open APIs?  If not, why?

We consider the barriers to be a combination of all three components that are identified in question 9 of the consultation paper.

#15 Do you agree that the main reason the banks have not universally built open APIs is due to the uncertainty of commercial incentives for them to do so? If not, why?

Yes, this is consistent with the comments we hear from bank personnel. 

As an example, Akahu is now offering services to assist banks with the design and delivery of their open banking solutions. When we first announced these services, we offered to deliver an open banking solution for free to a smaller bank in order to demonstrate our capability to the market. Even with the offer of a free open banking solution, that bank decided not to proceed at that time because there is currently a lack of commercial incentive to do so.

#16 Do you consider that the industry implementation plan creates sufficient certainty that the banks will build the open APIs? And do you consider that the minimum delivery dates are appropriate? If not, why?

Limited certainty

The implementation plan increases confidence in the delivery of payment initiation functionality for five banks. 

However it does not create certainty for third parties that are looking to build new payment solutions because:

• There are insufficient consequences if dates are missed.
• The other banks have not committed to dates, so a material segment of consumers are not supported.
• There are insufficient controls around the performance and other non-functional aspects of the APIs.
• Most importantly, the current system requires third parties to enter a bilateral contract with each bank. There is no certainty that a bank will agree to a contract, or that the terms will be reasonable.

Delivery dates

Due to the limited functionality available in v2.1 of the standards that we describe in responses 11 and 12, the current delivery dates will not be a meaningful milestone for Akahu. We are interested in delivery dates for subsequent versions of the standards which will enable us to migrate some of our existing customers.

#18 What do you consider are the main barriers to negotiating agreements between banks and payment providers for access to the interbank payment network (assuming open APIs are built)?

Historic and current issues

The consultation document links to Akahu’s blog post, which details the difficulties that we’ve experienced when attempting to access standardised APIs via a bilateral contract. The issues discussed in that post are still relevant today. Third parties have very little negotiating leverage, so we’re at the mercy of whether a bank wants to support a particular use case.

Enabling existing participants to transition to standardised APIs

As noted in the consultation paper, there is significant existing consumer adoption of alternative bank account connectivity methods. The biggest opportunity for a regulated open banking system is to migrate that existing activity across to the regulated system.

Recently we’ve been told by one bank that they won’t provide access to their standardised APIs unless we desist from using any other connectivity methods, not only for this particular bank, but for all banks. That position means that Akahu, and all other users of alternative connectivity methods, have no way of transitioning to the industry-led APIs over time as each bank delivers standardised APIs.

Intermediaries typically represent the majority of traffic in an open banking ecosystem, even in countries with a regulated form of open banking. Blocking intermediaries from transitioning to standardised APIs would severely inhibit competition and innovation.

We consider it unacceptable that a bank can block existing participants from transitioning to standardised APIs, which has the effect of preventing the bank’s own customers from using this more optimal method. We see this posture as a way to further slow the progress of open banking, and allow banks to control the timing and terms.

Independent management of accreditation and access terms

The only way to enable fair access to standardised APIs is for an independent body to manage third party accreditation and to set the terms of access.

We strongly support Commerce Commission’s proposal to manage these components of the open banking ecosystem.

#19 Does the API Centre’s partnering project enable efficient partnering between banks and payment providers? If not, what would be required to enable efficient partnering?

No, it does not currently enable efficient partnering.

Akahu participates in the API Centre working groups and Council, and we have supported plans to try and work through partnering issues as an industry group. However we have also expressed our concerns with this approach:

• The important issues have not yet been discussed due to concerns regarding competition law.
• If the API centre seeks Commerce Commission authorisation, it will take time to work through that process. 
• If authorisation is obtained, it would take significant time to work through the process of trying to agree on common requirements for accreditation and terms of access.
• There is no certainty that agreement will be reached on these matters. If a bank is not comfortable with decisions that are made, there is nothing to prevent it from leaving as a member of the API Centre.
• Even if agreement is reached with all banks, there is no certainty that the requirements will be economically viable for third parties.

Non-banks do not have enough influence to ensure reasonable terms of access to bank APIs through an industry forum. 

Effective partnering for standardised APIs will only occur through an independent body that manages third party accreditation and sets the terms of access.

#27 Do you consider that a designation of the interbank payment network is a useful first step towards enabling an environment where payment providers can launch innovative new options to make bank transfers in New Zealand? If not, why?

Yes, we support the proposed designation.

Over the next 3 years, we think it would significantly assist by:

• Applying regulatory pressure on the delivery of APIs.
• Setting timeframes for delivery from banks that have not yet committed to delivering APIs.
• Setting the requirements for third party accreditation and terms of access.
• Providing independent governance of standards development.
• Setting requirements for API performance and consistency that are not currently addressed in industry standards.

As acknowledged in the consultation paper, the Customer and Product Data Bill is likely to address the same issues that are targeted through the proposed designation. If the incoming regulation delivers its intended outcomes in due course, we think that Commerce Commission should consider whether its designation is still required.

#28 How effective do you consider our regulatory powers would be at addressing the barriers set out in this paper?

We think they would be very effective.

#29 Do you consider that a designation of the interbank payment network, and the subsequent use of our regulatory powers, would promote competition and efficiency in the retail payment system for the long-term benefit of merchants and consumers in New Zealand? If not, why?

Yes, we agree that the proposed designation would deliver those benefits.

Table 5.1 mentions the potential to prohibit the use of screen scraping as a means of accessing the interbank payment network. We strongly recommend that non-regulated methods are not restricted in any way, at least until equivalent functionality is proven to be working effectively in a regulated system. Our view is based on the following points:

• No evidence of direct harm: Screen scraping has been used in New Zealand for over 20 years. There are risks with this method as described in the consultation paper, but we are unaware of consumer harm that has been directly caused by this method to date.
• Potential impact on data use cases: Screen scraping is used extensively in New Zealand, including for purposes relating to data rather than payments, such as when applying for a home loan or automating the use of budgeting tools. Any use of screen scraping provides the third party with technical access to the interbank payment network, even if that access is not used for payment initiation. So the issues raised in this consultation paper apply to all uses of screen scraping, regardless of whether the consumer proposition is related to data or payments.
• Some benefits being delivered now: We note that countries with the highest consumer adoption of open banking functionality, such as the US, are using non-regulated forms of open banking that have enabled market innovation. In New Zealand, screen scraping is currently delivering some of the benefits described in question 10. Any restrictions could block these existing benefits.
• Building momentum: As described in our response to question 8, we think it’s important to maintain momentum and pressure to develop innovative payment solutions. Many payment use cases are not well supported by industry standards, so a lot of the innovation will continue to occur outside of the industry standards until they are further developed. It’s important to retain this pressure in order to promote competition and innovation. This innovation will also help to inform future versions of API standards. 
• Incentives to design the regulated system well: When purpose-built regulation and systems were developed in the UK and Australia, the initial adoption was very low. A major reason is because those systems delivered insufficient practical value for third party services that were using alternative methods. If New Zealand’s regulated system is well-designed, then the existing participants will be incentivised to migrate to the regulated system instead of using alternative methods. This approach of incentivisation, rather than restriction, will apply appropriate pressure to ensure that the regulated system performs well.

As described in our response to question 7, we encourage regulation of existing connectivity methods. Applying rules to existing methods has been described as “screen scraping plus” in the UK (paragraph 8.5) because the rules require relevant sharing of information between the bank and third party, and include appropriate expectations of third parties. 

We strongly encourage the Commerce Commission to support the transition of existing activity across to a regulated system over time. We believe that setting rules around existing connectivity methods will both enable competition and innovation in the near term, and support the transition to a regulated system as it develops.