bfsi
2019/03/31
31 Mar, 2019

APIs and Beyond - Getting Your Technology in Place for Open Banking Australia

  • Kushlani De Silva
  • Product Marketing Manager, WSO2 Open Banking - WSO2

Open banking is now a much talked about topic in Australia. Brought in to create a more competitive financial ecosystem, it aims to deliver products, services, and experiences that customers will keep wanting more of. Although there has been some speculation about implementation delays, by July 2020 all banks in Australia (referred to as data holders) will need to provide read access to customer data via APIs to data recipients.

The Big 4 banks of Australia will lead the implementation by opening up their APIs by February 2020. In advance of this deadline, the Big 4 need to have their APIs open and ready for testing by July 2019. This is quite similar to the March 2019 deadline for PSD2 and open banking in the EU and UK. We wrote a blog post on how to meet this deadline within a month.

Open banking is the perfect example of technology taking center stage of a customer experience initiative. It requires you to create a technology ecosystem that is secure and doesn't deter user experience. Additionally, it forces you to take a look at the architecture you have relied on for several years and decide how you should reuse or replace each component to support Open APIs. This article examines the key technology components required for open banking and how to build your technology vision to stay true to your open banking goals.

Technology for Open Banking: Why, What and How?

Open banking is, in essence, an integration scenario. Although the underlying technology is API management, in order to create a secure ecosystem between data holders and data recipients, banks need to evaluate several other technology areas before they start open banking. Here are the 4 key areas you should think about when evaluating technology requirements for open banking:

1. Make sure your APIs are superstars


Most banks regardless of size will already use some form of APIs. This could simply be for exposing data internally, for example between different departments in the bank, or externally to facilitate mobile or digital banking.

Open banking APIs have to be treated a little differently. For starters, they need to adhere to the Open API standard that is mandated by Data 61. Data 61 is the standards body that sets the technical specifications that any open banking implementation needs to follow. They issued a draft of the API standard last December and V 1.0 is expected in April this year.

Another key component of open banking APIs is the ability to enable seamless onboarding and access to data recipients. Features such as data recipient accreditation validation, a sandbox environment for data recipients to test out APIs, and API analytics should be provided. A solid API ecosystem guarantees that more data recipients will consume your APIs over those of your competition.

2. Think security every step of the way


The Australian Open Banking movement creates an ecosystem that exposes sensitive data to parties inside and outside the financial services domain. So, it goes without saying that security is a top priority for open banking. You should evaluate your existing identity and access management platform to see if it can support the following functionality for open banking APIs.

Strong Customer Authentication (SCA) - SCA is put in place to ensure that behind every data access is a genuine customer who is initiating the data transfer. SCA is supported by means of multifactor authentication through SMS one-time passwords and other methods. Since SCA can sometimes deter user experience, you should consider implementing adaptive authentication which sets exemptions for SCA based on the sensitivity of the data that is being accessed.

Consent Management - Consent management empowers your customers to decide how they want their data to be accessed and by whom. Consent can be provided for specific data sets, for a specific time period or to a specific set of recipients. It can even be a combination of all three factors. The ability to revoke and update consent is also vitally important since it puts the customer in total control of exactly who has access to their data at any point in time.

Fraud Detection - As more data recipients start to access your APIs, the chances of fraudulent activities increase. This will be extremely detrimental to customer experience, therefore banks must be prepared to have fraud detection mechanism in place. This can be done by implementing rules for API consumption and having alerting mechanisms that trigger when these rules are violated. Additionally, dashboards that track API usage patterns can be customized to detect anomalies and send out alerts in real time.

3. Make your legacy system work for open banking


One of the first questions you may ask before you start your open banking journey is “Can my legacy system handle the requirements of open banking? And if it doesn't, how will I invest the time, effort and budget to make the change?” The best way to approach this is to figure out how the two can come together. While legacy systems may not be completely adaptable to open banking there are always ways around it.

The first thing to do is to add an integration layer which will mediate between the legacy system and Open APIs. It will allow you to expose the required services to the open banking solution, which will, in turn, expose them as APIs with the required security measures in place.

The benefit of bringing together legacy systems with your open banking infrastructure is that it provides the perfect opportunity to digitally transform your bank’s architecture. This way, you don’t completely discard the systems you have worked with all along and you don’t have to restructure everything to suit the open banking implementation. Our whitepaper explores a step by step approach to how you can reuse and modernize existing legacy architectures for open banking.

4. Create a technology vision for open banking


Throughout this article, various components of technology that are essential to open banking were discussed. The important thing is, if you view technology only as a support role in your business, your open banking implementation will not be successful. What is important to understand is that all those components add up to a bigger picture - technology doesn’t just play a support role in financial services. Technology is now taking the lead in determining how effectively you open your APIs, the measures you have taken to guarantee data security and the commitment you have put in to deliver the best possible open banking experience to your customers. Therefore, a technology vision should be at the heart of your open banking implementation. It is this vision that will translate into a customer experience that can set you ahead of your competition.

Conclusion

Your IT strategy and vision is only as good as the actual technology you use. So while you may have a foolproof strategy, it is critical to build technology partnerships with stakeholders that are able to support your vision. Since open banking is a journey, make sure you plan for the future when embarking on technology partnerships. WSO2 Open Banking was created to empower Australian banks who set out to open up APIs and create history in financial services. For more information on how WSO2 Open Banking has helped global customers on their open banking journeys and for solution details please visit our open banking page.

 

About Author

  • Kushlani De Silva
  • Product Marketing Manager, WSO2 Open Banking
  • WSO2