The Technology Foundation needed for Open Banking Compliance
There's a misconception that 'open banking' involves financial service providers opening their systems to allow anyone to view their customers' data. This is simply not true.
In the previous article in this series, we explored how open banking was on its way to becoming a reality for financial institutions in Australia. This is being driven by the Australian Government, which is mandating that all financial institutions adopt open banking by 2020.
Earlier you might have read that some Australian banks are expressing concern over the new regulations because of the questions it raises around security for customer data. Meanwhile, other banks were equally concerned by the investment cost required to ensure compliancy, when the Australian Government's open banking hits the biggest banks in July 2019.
There's a lot of confusion for banks on how they can comply to the regulations, without the risk of losing customers. While open banking seems to be a daunting task, it really comes down to how you adapt your technology, systems to meet open banking requirements.
This new environment will require financial institutions to have the ability to securely share data with accredited third parties with the customer's consent; as well as aggregate, manage and analyse data – this will become increasingly important. According to Seshika Fernando, head of financial solutions, WSO2, Australian banks can start their open banking journey by getting their hands dirty with an open banking setup that was designed for the UK (as the Australian Data Standards Body is using the UK version as a base).
"This will enable banks to understand what services need to be exposed from their core banking system — which is half the battle towards compliance," Fernando said.
Professional services group, Deloitte Touche Tomatsu, states the initial scope for open banking will be limited to active online customers, with offline customers and historical customers coming into scope in future releases. Australian Authorised Deposit-taking institutions (ADIs) will need to consider how they match and merge data across these potentially fragmented data sets within their organisations.
Deloitte writes the Australian Competition and Consumer Competition (ACCC) has selected the initial release of the new Consumer Data Rule to not include 'derived data,' and will not permit fees for data requests. ADIs will have to consider whether they want to include these capabilities within their baseline designs to minimise cost and rework; or position themselves to commercialise their data and analytical capabilities.
- ADIs will also have a streamlined registration process to become accredited data recipients, and so will likely need to comply with the obligations of data recipients as well as data holders.
- The data architecture for both data holders and data recipients will need to manage the complexities of consent; including authorisation, authentication, expiry and withdrawal. This may include destroying or de-identifying data in near real-time, once it is redundant, or can no longer be used for a purpose or for a period for which consent has been received.
- ADIs will need to tailor consent management capabilities (authorisation and authentication) for accounts with multiple authorised parties in contrast to those accounts with a single signatory.
- Customer facing capabilities will need to be developed by both data holders and data recipients to assist customers in managing their data requests and usage; and in the case of data holders, will likely need to integrate into their online banking capabilities.
WSO2's Fernando believes when it comes to the technical aspects, open banking involves securely opening up data via APIs. The most key components banks will need are an API management platform and a robust identity and access management (IAM) platform.
The major features their API management platform should enable are:
- Data recipient (i.e. Third-Party Provider [TPP]) onboarding
- Data recipient accreditation validation
- Sandbox environments and production access
- Tooling for data recipients
- API Lifecycle management, creation and versioning
- API Security
The major features that an IAM platform should enable are:
- Strong customer authentication: Secures access by way of multi-factor authentication (including SMS, One Time Passwords, FIDO devices, etc.).
- Comprehensive consent management: Allows users to provide data sharing consent based on data sets, for a specific period, to a specific set of recipients. Users can also revoke or update consents as and when they need to.
- Integration with the API platform: support for tokens and API authentication alongside and in conjunction with customer authentication.
Fernando said these points form the basis of a regulatory compliant open banking system, with several other aspects, such as an integration layer to allow new technology to connect with the existing tech stack.
We can see an effective example of this working in the UK, on which the Australian Government's policy is based. In the UK, the open banking sector has defined the open banking Read/Write API Standard in a way that fully complies with the PSD2 regulation. In addition, the API management system will need to be connected to a bank's core banking system via some integration technology such as a message broker or Enterprise Service Bus (ESB).
The above capabilities are the bare minimum required to securely open up core banking via APIs. The next step for banks is to ensure that the new solution also provides great customer experiences. This could be by:
- Providing strong authentication exemptions by way of adaptive authentication for low risk data accesses.
- Fixing customer pain points through detection and analysis of delays within the customer journey.
- Identifying fraudulent attempts at accessing data without permission and DDOS attacks that can bring down the system.
To meet these requirements, banks need a real-time data analytics platform which can easily collect, correlate, and analyse the data, and provide notifications and outputs in real time.
According to Fernando, WSO2 worked with various banks in UK and Europe, including Societe Generale, when the regions needed to comply with PSD2.
WSO2 open banking for Australia is a purpose-built solution for meeting all the technology requirements driven by the Australian regulation. This includes API management, third-party onboarding, strong customer authentication, consent management, regulatory reporting and anomaly detection. These requirements are preconfigured in WSO2 open banking for complete compliance.
"We ensure that regulatory obligations are fulfilled without having to dedicate large teams to follow the regulation and implement the compliance strategy. The solution's componentised architecture helps reduce costs by allowing banks to mix and match technology requirements as necessary. Additionally, WSO2's open banking training programs can get banking staff up-and-running with the technology in record time," Fernando said.
According to Fernando, Australian banks won't face the same costs as UK open banking projects (GBP150-200 Million), because the Australian model will be a phased implementation. This will give banks time to plan, prepare and set budgets accordingly.
Australian banks have the luxury of learning from their UK and EU counterparts on how to become compliant without blowing out their budgets. They'll also be able to work with organisations such as WSO2 - who have created proven products with established financial organisations - as they progress through this regulatory journey.