How WSO2 Open Banking 1.5 Supports Compliance with Australia’s CDS Version 1.2

WSO2 Open Banking is a leading open banking technology provider, supporting the UK’s Open Banking Standard, the Berlin NextGenPSD2 XS2A framework, and other regional specifications. With the latest iteration, version 1.5.0, we are proud to introduce full compliance with Australia’s Consumer Data Standards (CDS) specification version 1.2.

Support for CDS Features and Functionality

WSO2 Open Banking 1.5 meets all the requirements of Australia's latest Consumer Data Standards (CDS). Let's look at several key feature additions and enhancements in detail.

CDR APIs

CDR APIs are the gateway that enables the CDR open banking system. Once the authorization and consent are verified via the methods detailed further below, the user’s data is accessed by data recipients through the APIs exposed by the data holder.

WSO2 Open Banking provides API templates for several types of APIs, as defined in the CDS.

1. Common APIs that have customer and API-related resources
2. Banking APIs that relate to typical accounts, balances, and transactions
3. Admin APIs used by the CDR Registry to communicate changes

These APIs can be deployed and managed on the fly and version upgraded with ease using WSO2 Open Banking’s API Publisher. The required security and certification validation feasibility are built-in to the system and provide fine-grained customization options.

Banks are now able to enable third parties to make use of consumer data and offer more services through these protected APIs. Banks can develop their own applications as third-party providers and provide extended services as well. This means that without resorting to screen scraping or making complex extensions to access banking data, data recipients can, legally and with little effort, gain access to user data from data holders. This helps them build feature-rich products. Consumers no longer have to rely on traditional banking services and are able to obtain more focused services thanks to these APIs.

Dynamic Client Registration

Dynamic client registration (DCR) allows a financial application, which needs access to a consumer’s financial data, to register with a bank. This capability is fulfilled via an API that is exposed through our open banking solution. A bank will be able to ensure that consumer data is accessed by a trusted party owing to additional security validations—such as signed payload validations involved with registering via the DCR API vs. filling up a sign-up form.

Figure 1: The dynamic client registration process

DCR ensures a more secure manner to onboard data recipients, and, by eliminating the need to fill up details manually, automates the client registration process. Using this system, banks are able to subject data recipients and their applications to an effective verification process that relies on certificates and software statements issued by the Australian Competition and Consumer Commission (ACCC) and doesn’t require time-consuming and error-prone manual interventions. Signature verification and mutual TLS at the transport level further ensure the system is secure. This enables consumers to place more trust in how third-party applications access their data. 

Authorizing Consent

Figure 2: A typical consent journey in line with CDS requirements

After a data recipient, such as a fintech application, is registered with the bank as a trusted entity, the next step will be to obtain the consumer’s financial data. For this, the consumer’s authorization should be granted first. The consent authorization involves redirecting the consumer from the data recipient's application to the bank’s digital authentication portal, where the consumer will be prompted to log-in to his or her online account with the required security provisions. The recommendation from the CDS is to use an identifier that is unique to the consumer followed by an OTP mechanism, such as email or SMS OTP, as the basic authentication step when logging into the bank’s authorization portal.

These may include second-factor authentication to further safeguard consumer privacy.

Figure 3: Consent authorization

WSO2 Open Banking comes with the required security mechanisms to validate the authorization request, such as support for request objects and the bank can easily plug-in authentication mechanisms already used by the bank, such as biometric systems. The solution also provides a consent display page, where the consent authorization is captured. Finally, the consumer will be redirected back to the data recipient application. The consent authorization allows a bank to verify that the consumer is aware of the request for data from the application and is willing to share the data with the data recipient application.

After the consumer grants consent to access the requested data, the data recipient has to obtain an access token from the data holder.

Figure 4: Token generation

WSO2 Open Banking provides token issuing and management capabilities adhering to the OAuth2 framework. In order to securely expose consumer data, access tokens are presented in the retrieval data request to provide a means of proof that the calling party is authorized to obtain the requested details.

Figure 5: The retrieval of CDS data

Using these principles and technology, banks can now expose new services and adopt new business models. For example, monetizing new APIs sharing consumer data based on express consent. Consumers benefit from having access to a broad range of new applications and services. These applications provide insights into their finances and the ability to easily connect with different banks. Others may give consumers the ability to access all their financial information in one place.

Consent Management Applications

After consent is granted by a consumer, consent is valid for the requested period of time, known as the “sharing duration”. The data recipient is allowed to access the relevant data of the consumer within this period of time. If the consumer wants to stop sharing his or her data with the data recipient, consent needs to be revoked.

This is facilitated through the consent management web application as well as the Customer Care Portal offered as a part of the WSO2 Open Banking Solution. The consent management application allows a consumer to log in and view the details of the granted consents and the status of the consent (active or revoked). If the consumer wishes to revoke an active consent, it can be done via the consent management application. The customer care portal allows a bank employee with the necessary permissions to search for a consumer’s consent and revoke the consent on behalf of the consumer. This ensures that the consumer has control over his or her data and prevents a data recipient from accessing data against the will of a consumer.

Using this functionality, a bank can allow consumers to stop the permission given to share their financial information. By doing this, data recipients can ensure the data they receive is based strictly on consumer consent, and consumers are able to take effective control of how their data is used in the open banking ecosystem.

URI and Endpoint Versioning

The CDS notes two versioning strategies: URI and endpoint versioning. While URI versioning is used to address major changes in CDS APIs, endpoint versioning allows every single endpoint to have independent versions of each other. For a single major API version, each endpoint can have separate versions. A data recipient may request a specific endpoint version; the bank has to check whether the requested version is supported and respond accordingly. Validations for the requested versions are done by the solution and the selected version is sent in the “x-v” header. Endpoint versioning enables flexibility for minute changes to API endpoints to be applied without having to migrate to a whole new API version.

Figure 6 - Endpoint versioning

Banks can now avoid the hassle of maintaining new APIS for a minor change. Moreover, data recipients can now request a specific data format by sending the endpoint version. This functionality brings a higher degree of agility to how stakeholders may use and benefit from Australia’s open banking system, boosting the space for innovation and added ROI.

Metadata Caching

Available only in the Australian specification, metadata caching is a feature to communicate data recipient status changes in the CDR Register to the data holders.

Figure 7 Metadata Caching

Data holders are expected to poll the active statuses of data recipients and their software products and use this information to provide access to user’s data. If for any reason the accreditation of a data recipient is compromised, then data holders get this information from the registry and restrict access. To avoid overburdening registry servers, data holders are required to cache these status changes for a specified time. WSO2 Open Banking offers this capability with customizable poll duration and configuration.

Prior to this, banks took on the risk of allowing unaccredited data recipients to continue to access user data if it was accredited only at the initial onboarding stage. With the status update component, they can now check the validity in real-time improving data security. Data recipients benefit from this as they do not have to inform data holders about surrendering accreditation—it will be automatically updated from the registry. Consumers benefit as they no longer have to worry about unaccredited or fraudulent data recipients accessing their private information with the system responding in real-time to their changing preferences on who may access their data.

Metrics APIs

Under the CDR Rules, the CDR Registry is to be provided with access to operational statistics on CDS implementations by data holders. Data holders are expected to provide these metrics, such as availability, performance, response time, and general API health checks, through an API that can only be queried by the ACCC. WSO2 Open Banking provides this feature through its business intelligence server.

Through this ongoing monitoring of performance and other metrics, data holders are encouraged to make their open banking solutions more efficient, while the regulator is able to compile data on how the open banking system is being utilized in practice, thus providing better insight for stakeholders to improve Australia’s open banking implementation in the long run.

Beyond Compliance

Standard and Rapid Deployment Options

By October 1, 2020 banks outside the Big Four, building societies, and credit unions in Australia will be required to complete stage-1 of complying with their Consumer Data Right (CDR) obligations. To help these organizations, WSO2 Open Banking provides a standard deployment option is also available for banks that want a more customized solution to fully leverage the potential of open APIs for new business opportunities and digitalization, and a unique rapid deployment option that provides a quick, easy, and cost-effective option for deploying compliant Product Reference Data (PRD) APIs by the deadline for banks looking to minimize open banking investments to compliance alone at this stage. The rapid deployment options enable deployments to be completed in less than a week.

Non-Regulatory APIs

WSO2 Open Banking now supports publishing APIs beyond those mandated by the CDR regulatory framework. This allows banks to publish any custom APIs that they wish to expose using the technology provided by the WSO2 Open Banking solution. This means banks can now access the full functionality of the WSO2 API Manager component at the core of our open banking solution, enabling a rich and mature API management framework that supports the entire API lifecycle, from creation to deployment.

Conclusion

As the CDS continues to grow with the introduction of new concepts, such as concurrent consent management, multi-authorization, and new rules to ensure more security, banks will have to incorporate changes to their systems. WSO2 Open Banking will continue to update our solution with these changes as we closely monitor the CDS space for the latest updates.