WSO2Con2025 Logo

March 18-20 | Barcelona, Spaain

 
bfsi
2019/01/03
3 Jan, 2019

Cost-effective Open Banking Compliance for Australia

  • Seshika Fernando
  • Vice President/Field CTO - WSO2

The content of this post was updated on February 28, 2020 to reflect the current regulatory position.

Open Banking at Westpac is estimated to be around AU$200 million, according to Westpac CEO Brian Hartzer's address to the House of Representatives Standing Committee on Economics. He further explained that this can be attributed to the complexity of the existing environment of systems as well as the need for specialized skills in order to implement open banking. What’s alarming about this statement is that if an open banking implementation comes at such a large cost, then it’s going to be economically prohibitive for a majority of the 134 Authorized Deposit-taking Institutions (ADIs) in Australia.

Our experience with banks that have adopted open banking in different regions has shown us that Open Banking in Australia can be achieved with just a fraction of Westpac’s estimated cost. This article will outline several cost-effective practices that can be followed for open banking implementations

Understanding the Costs Involved

The first step in trying to understand the costs involved is to understand what an open banking project entails both in terms of technology components as well as technical skills. The diagram below maps out the regulatory requirements to technology components:

1. Open APIs

The API will need to conform to the specification provided by Data61. The technical standard is an evolving document with product types added in a phased approach. So banks need to be able to update the APIs even after compliance.

This requirement will be met by the creation of services from the core banking system along with an API gateway that manages the access to the API in real time.

2. Third party/Data Receiver onboarding

Many banks already have an API gateway that is used by certain stakeholders to access the bank’s APIs for various purposes. The main difference between existing APIs and the Consumer Data Right (CDR) APIs is that the latter will be consumed by parties that are completely independent of the bank.

These are typically data recipients that have been accredited by ACCC to consume certain types of data. When banks onboard such third parties, they now have to go through a verification step that identifies whether the request is coming from an accredited data recipient, and if so, what their current accreditation status is. Banks need to ensure that data recipients are able to consume only the relevant API resources that are specific to their accreditation status.

In order to achieve this, the bank would need to set up a data recipient onboarding process that complies with the Dynamic Client Registration processes set out by the ACCC. This enables them to preferably upload a digital certificate, which then gets validated via a service provided by ACCC (to check accreditation), and then finally allows the data recipient access according to their current accreditation status.

Once the data recipient is onboard, they require a Developer Portal that allows them to connect the APIs to their applications. Next, they can test out the flow in a sandbox environment and request access to the production environment once they are satisfied with the full flow.

3. Lifecycle management

Since the CDR is carried out in a phased approach and the APIs themselves are constantly evolving as a result of continuous extensions to the data standards, banks will need to manage the API lifecycles on a continuous basis. This involves

  • Keeping up with version upgrades
  • Notifying existing users of upcoming API versions in a timely manner
  • Providing documentation and sandbox access to the upcoming versions while supporting the existing version in the production environment
  • Enabling Data Recipients to upgrade their applications to the newer versions

All these require a comprehensive API management component.

4. Authentication

Since the main goal of CDR is to give consumers more control over their data, one of the main requirements is the ability to ascertain their consent for a third party to access data on their behalf. In order to achieve this, the bank needs to identify and verify the authenticity of the consent. This will be done via multi-factor authentication (MFA) since this instruction will be received electronically.

Banks will require an identity management component to perform this authentication. This requirement too will evolve, to cater to more user-friendly authentication approaches such as app-to-app authentication and decoupled authentication.

5. Authorization (consent management)

Banks will need to capture fine-grained consumer consent for each data access. These consents need to specify which subset of data, can be shared with which Data Recipient for which period of time. Since many of the consumer consents will apply prospectively and continuously for a certain period, banks need to provide the capability for consumers to update or revoke consents that they have already provided. This could be done directly by the consumer through their online banking portal or mobile application or by calling the bank and getting a bank employee to change it on behalf of the consumer.

A comprehensive consent management component which provides APIs to connect it to existing systems is therefore required.

6. Regulatory reporting

Banks will be required to report statistics of the new open banking channel to the ACCC on a regular basis. These reports will have to conform to the frequencies and formats that have been specified by the standards bodies and will include data regarding performance, availability and third-party adoption.

A data analytics component will be useful in both capturing the data as well as collating them and pushing out to the relevant stakeholders in the required format.

This same data analytics component could be used to analyze the API invocation data to capture insights on trends and market opportunities.

Fast Track to Compliance with WSO2 Open Banking

Combining technology specialized for open banking with a team of regulatory experts, WSO2 Open Banking has been successful in delivering compliance projects within 3 months. This estimate is for an onsite implementation with two open banking experts

Task Duration (days)
Discovery 5
Deployment
  • Setup
  • Deployment automation
  • Deployment cloning
  • Documentation
10
Implementation
  • Core banking integration
  • Third party onboarding
  • Strong Customer Authentication
  • Consent management
  • Branding
25
Testing (DEV/TEST, PROD)
  • Functional
  • Integration
  • Security
  • Performance
  • User Acceptance Testing (UAT)
15
Training 5
Total 60

Choosing a phased-deployment model for your WSO2 Open Banking solution enables you to comply with the Product Reference Data deadline of July 1, 2020 within 1 month.

Best Practices for Cost-effective Compliance

It's important to understand that open banking does not require you to create technology systems from scratch. Here are a few tips and best practices to adopt for compliance that does not break the bank:

  1. Repurpose or reuse
    Once the regulatory requirements are well understood, the first step is to analyze your current technology stack and identify which components can be reused to meet the requirements. This will save a significant portion of your budget since it eliminates the need to duplicate technology as well as the cost of maintaining two different technologies that essentially do the same functions for different projects.

  2. Fill the gaps
    Once you have identified which components can be reused, you simply need to fill the gaps that cannot be serviced by existing technology by investing in purpose-built components that are pre-configured for Australian Open Banking compliance. This ensures that you save money on lengthy configurations and modifications and eliminates maintenance costs for those custom modifications.

  3. Invest in a good integration layer
    This will allow you to easily introduce new technology components while leveraging the capabilities of your existing technology.

  4. Invest in a technology partner
    When looking for the right technology, try to get all the components from a single platform to reduce the number of expensive evaluation rounds you need to do for each requirement. This also eliminates the need for multiple procurement processes that are usually lengthy and cumbersome. Finally, you don't end up with a vendor who supplies piecemeal components, but a technology partner who understands and supports your vision towards open banking

  5. Work with domain and regulatory experts
    Work with a technology provider that is well acquainted with the regulation. They should ideally undertake the task of keeping the technology up-to-date with the evolving regulatory requirements. This eliminates the cost of hiring and maintaining specialized staff to follow the regulatory changes and implement them.

Conclusion

At first glance, open banking may seem like it could break the bank. But once you have carefully evaluated the existing IT infrastructures and mapped it to what can be reused for open banking and what cannot, it simplifies the process and helps you get a good sense of what new costs will be involved for open banking. Further, working with technologists who have experience in open baking implementations and can support you with technology, regulatory and domain expertise you can further simplify the open banking process and do so with budgets that don't burn a hole in your pockets.

Contact us for more information on your specific needs on open banking and CDR compliance.

Get a free evaluation from an open banking expert
 

About Author

  • Seshika Fernando
  • Vice President/Field CTO
  • WSO2