Open Banking framework comes to Australia

Countries across the world are gradually following in the footsteps of in the UK and PSD2 in the EU, given the vast future potential offered by these schemes. In , the federal government has agreed to implement the recommendations made by the Open Banking Review team chaired by Scott Farrell, for the regulatory under which an Open Banking regime would operate. And initially, the four major in Australia have been mandated to make banking data available to TPPs (third-party providers) by June 2019.

It is designed to give customers more control over their information, leading to more choice in their banking and more convenience in managing their money—thus resulting in more confidence in the use and value of an asset mostly undiscovered by customers: their data.

One could consider the UK’s Open Banking technical specification as an example approach. Specific API design principles—such as redirect-based authorization and authentication flow—have been taken as the starting point for setting data transfer and authentication standards in Australia, though these would be adopted only with appropriate considerations.

Highlights of Australia’s Open API framework

  • The scope of data that must be shared by data holders includes customer-provided data, transaction data and product data (e.g., fees and charges).
  • Value-added customer data or aggregated data sets are not required to be shared.
  • The product range included in the scope is very broad across a large range of deposit and lending products for both retail and business customer segments.
  • Data transfer would be completely free of charge.
  • The data recipient can rely on the outcome of an identity verification assessment performed on the customer by data holders.
  • Tiered accreditation system for data holders and data recipients will be based on the risk of data sets and participants—and with regards to existing license regimes for accreditation—would reduce costs for many participants.
  • Multifactor authentication is considered a reasonable security measure. Any authentication measure adopted should be consistent with authentication requirements in direct interaction between the data holders and their customers.
  • Screen-scraping is not restricted, but the alternative access mechanisms will be made very efficient, which will make screen-scraping redundant.

Contrary to PSD2 and UK Open Banking, Open Banking in Australia is part of the Consumer Data Right. The CDR will give consumers greater power to control their data—and banking is the first sector in which it will be applied. So, the focus of all the developments is to form a single, broader framework which is interoperable across sectors apart from banking. The Farrell Review has given special consideration to how Open Banking is going to work with existing laws and systems such as the Privacy Act, Competition and Consumer Act 2010, and Anti-Money Laundering law to avoid any uncertainty and ambiguity.

Other differences include&;

  • Australia’s Open Banking use cases are limited in terms of functionality, as it allows only read access, which limits payments initiation/write-access functionality—unlike UK Open Banking and PSD2, where it is allowed. However, in terms of accounts in scope, Australia includes more accounts (such as lending accounts) while these are not included in UK and PSD2. These are differences in the scope of the use cases:

  • Introduction of Australia Open Banking is divided into phases, starting with four major Australian banks at the outset and the remaining Australian Deposit-taking Institutions (ADIs) to comply within the following year—unless the Australian Competition and Consumer Commission (ACCC) determines a later date for them. In this way, ADIs will be able to benefit from lessons learned through earlier phases. The UK’s Open Banking implementation is not divided and is open to competition for all nine major UK banks from the very beginning. PSD2 is applicable to all banks in the EU that offer online-accessible payment accounts.
  • Australia’s Open Banking framework recommends standardizing APIs for data transfer similar to UK’s framework, while PSD2 leaves it to banks to decide what kind of interface they want to use. For PSD2, initiatives such as the Berlin Group’s NextGenPSD2 aim to close this gap.
  • In Australia, all Open Banking standards (transfer, data, security, and customers’ and participants’ experience) will be set by a Data Standards Body. This is comparable to the UK’s framework with the Open Banking Implementation Entity (OBIE); while in PSD2, standards are not centralized and are comparatively fragmented.
  • In Australia, Open Banking will be supported by multiple regulator models by the ACCC (competition and consumer issues, standards setting), OAIC (privacy protection), ASIC, APRA and RBA and other sector-focused regulators (advice as required). UK is regulated by CMA (for the nine largest banks) with standards set by the UK Open Banking Implementation Entity and regulated by EU’s PSD2 (for all UK banks). In PSD2, National Competent Authorities (NCAs) regulate and control the banks in their national markets with regards to PSD2 compliance.
  • Due to various legal complexities, Australian customers will not have the right to request deletion of their personal information under the Privacy Act, while in UK Open Banking and PSD2, it will be allowed under GDPR implementation.
  • Under the Australian regulation, third parties that participate in Open Banking will also be obliged to share their customer data, which is different from PSD2 and UK Open Banking.

Australia has taken a very structured approach in planning for Open Banking to work with existing regulations and incorporating lessons learned. It has also addressed considerations such as customer education, dispute resolution, the ACCC breach reporting obligation and post-implementation assessment to make Open Banking more effective in Australia.

The post Open Banking framework comes to Australia appeared first on Accenture Banking Blog.

Accenture Banking Blog