How to Deploy Product Reference Data APIs for Open Banking in Australia in Two Days
Table of Contents
Open banking solutions for Australian banks have to date involved complex integrations, dedicated IT resources, months of planning and deployment work, and high costs. As large banks have discovered, this is a difficult process. For smaller banks, credit unions and building societies, this process is even more of a challenge especially in the current uncertain economic climate. Detailed below is an alternative—a simplified rapid deployment model to give smaller Australian banks a quick, easy, and cost-effective option to deploy compliant Consumer Data Right PRD APIs by October 1, 2020.
A new approach to PRD APIs - ‘PRD compliance in a box’
While deploying APIs to share consumer data in 2021 will inevitably be a complex process, this does not have to be the case with deploying the Product Reference Data (PRD) APIs due by October 1, 2020. This arises from the simple fact that PRD APIs, as mandated by Australian regulations, use unauthenticated endpoints as they only provide generic product data. This means the PRD APIs are not subject to privacy and consent management concerns associated with APIs for sharing consumer data. What’s more, as product reference data is in reality a static data set, they do not necessarily need to be accessed from a bank’s core banking system and databases.
Using this insight, and drawing from our experience of working with the Australian Competition and Consumer Commission (ACCC), Data61, and our open banking customers in Australia, WSO2 Open Banking offers a simplified, rapid deployment model for PRD APIs. The pre-configured, production-ready APIs delivered using this model are fully compliant with the Consumer Data Right (CDR) and the Consumer Data Standards (CDS) regulatory framework for PRD APIs. As the model uses a managed cloud-based deployment of templated standard-format technology, it enables:
- Rapid deployment within two days,
- No commitment of IT resources personnel, and,
- A significant cost saving over alternative solutions.
What is delivered with the solution?
Banks, credit unions and building societies will receive a fully managed ‘out-of-the-box’ PRD API solution hosted on AWS within the Asia Pacific (Sydney) region by WSO2 Open Banking. The solution includes true end-to-end management for the bank with WSO2 Open Banking providing:
- The entire setup process,
- Logging, monitoring and alerting,
- Securing the solution, and
- Updates to ensure compliance with the latest versions of the CDS.
Unique pre-production and production environments are made available to each bank. These are provided with independent user stores, providing access to the bank’s employees if required. Once subscribed to the solution, the banks would only be required to upload a spreadsheet containing static product data to the hosted solution via the provided user accounts. Once the solution is tested and moved to production, the bank is provided with PRD APIs that are fully compliant with the CDR regulatory regime. The API store is customisable to include the bank’s branding. The bank can ensure product data is up-to-date by simply uploading an updated spreadsheet to the system using a non-technical process.
The bank is able to opt-in to additional AWS-native tools for DDOS attack mitigation tools, file integrity (host) tools, and network intrusion detection (IDS) with third-party tools considered on a case-by-case basis.
Shown in this image is the API store that is provided with the solution. The API store may also be skinned to include customer branding.
Shown in this image is the API store that is provided with the solution. The API store may also be skinned to include customer branding.
How is rapid deployment achieved?
In essence, since PRD compliance is basic and straightforward; WSO2 has designed a basic and straightforward standard-format solution to expose any bank’s PRD data. This simplified and rapid deployment model is made possible by the design parameters of the PRD APIs under the CDS.
PRD APIs are mandated to only share static generic product data. This eliminates the need for integrations with existing core banking systems and databases. As long as the bank can provide the data in the required format, this data can be exposed via APIs.
PRD APIs only need to share publicly available generic data. With no consumer data being shared, the need for technologies on privacy and consent management associated with accessing consumer data in the bank’s databases are also eliminated.
With the use case for the APIs fixed, and no custom integration required to the existing tech-stack within banks, PRD APIs can be built using a standard format for all customers. This eliminates the time, complexity, and cost of building a custom solution. Further, with the solution being provided on the cloud, there is no need for setting up environments on the bank’s side together with related prerequisite technology installations. Banks are literally able to access their pre-configured PRD API solution with their own user store for access management within hours of purchase. Additionally, training for maintenance and upgrades is also eliminated owing to the managed cloud deployment and as keeping the database up to date only requires an action as simple as updating a spreadsheet.
What isn’t provided with this deployment model?
Drawing from the sections above highlighting what is provided with the solution, and how rapid deployment is achieved, the table below sets out what may not be achieved with this rapid deployment option.
Where banks are looking for a more customised solution that allows for a fuller participation in the CDR regime earlier on, they may opt for the standard deployment model of the WSO2 Open Banking solution.
|WSO2 OPEN BANKING 2-DAY RAPID DEPLOYMENT MODEL||WSO2 OPEN BANKING STANDARD DEPLOYMENT MODEL|
Only as a managed cloud deployment to allow for accelerated deployment and full management by WSO2 Open Banking.
Deployment only on Amazon Web Services on accounts operated by WSO2 Open Banking in the Asia Pacific (Sydney) Region.
Available for on-premises, cloud, and managed cloud deployments.
Any form of cloud deployment is possible (e.g., cloud hosting services maintained by the bank).
Customizations possible are:
||Broad customisations of the design, deployment, management, and evolution of the solution, and its functionality may be incorporated in the solution. Read more here.|
|Integration||There are no integrations made to the bank’s existing systems and user store. This solution is a fully independent technology deployment designed and deployed specifically to meet phase 1 CRD obligations. All integration work would be conducted with the phase 2 deployment in 2021 under the standard timelines and costing for CRD consumer data service technology deployments.||The steps required to integrate to the bank’s core banking systems and other legacy systems as required for the use cases identified by the bank are commenced from phase 1 itself.|
|Management||The solution is fully designed, deployed and managed remotely by WSO2 Open Banking.||While full support and management services are available with the solution, the bank may opt to operate the solution at any degree of independence it chooses.|
Does it really deliver compliant PRD APIs?
Does it match the requirements in the CDR Rules?
The Competition and Consumer (Consumer Data Right) Rules 2020 (CDR Rules) mandated that Product Data Requests are made using a Product Data Request Service “ … in accordance with the data standards”. This means that PRD APIs must comply with the specific design requirements set out in the CDS. These are set out below.
Does it match the requirements in the CDS?
The Consumer Data Standards (CDS) version 1.2 sets out the two Banking APIs that make up the PRD APIs due by October 1, 2020 as the Get Products API and the Get Product Detail API. Both of these API endpoints have been upgraded to version 2 under CDS 1.2. It is important to note here that both PRD APIs have been clearly marked with the note that “This operation does not require authentication.” This means that as long as the product reference data parameters listed under each PRD API defined in the CDS are duly included in the database accessed when providing responses, the PRD APIs comply fully with the CDS and, thereby, the CDR Rules as well. The spreadsheet set out below has been structured to incorporate all these necessary parameters.
What is needed from the customer?
As set out above, the entire solution is provided and maintained on behalf of the customer. All that is required from banks are (i) providing a URL address (and associated certificate) chosen by the bank that would be used to route the PRD API traffic, and (ii) a spreadsheet setting out the mandated product reference data to be accessed by the solution database. The spreadsheet could be uploaded to the managed cloud solution using a simple, non-technical process by the bank to upload the necessary product reference data for access by the APIs.
The following table is an indicative format for the Get Product API. At each point where banks are required to share product data on new product phases, the bank would be provided additional spreadsheet tables by WSO2 Open Banking to include that data in the solution database. The solution supports sharing data on products from all three product phases of the CRD from the outset if the bank opts to do so.
|Data required||Product 1||Product 2||Product n|
|productId - specific unique identifier for this product|
|effectiveFrom - The date and time from which this product is effective|
|effectiveTo - The date and time at which this product will be retired and will no longer be offered|
|lastUpdated- The last date and time that the information for this product was changed|
|productCategory -The category to which a product or account belongs|
|name - The display name of the product|
|description - A description of the product|
|brand - A label of the brand for the product|
|brandName - An optional display name of the brand|
|applicationUri - A link to an application web page where this product can be applied for.|
|isTailored - Indicates whether the product is specifically tailored to a circumstance.|
|overviewUri - A URL to obtain a general overview of the product.|
|termsUri - A URL of terms and conditions for the product.|
|eligibilityUri - A URL of eligibility rules and criteria for the product.|
|feesAndPricingUr i- A URL for fees, pricing, discounts, exemptions and bonuses for the product.|
|bundleUri - URL of a bundle that this product can be part of|
|cardArt.imageUri - A link to a PNG, JPG or GIF card art images with proportions defined by ISO 7810 ID-1 and width no greater than 512 pixels|
* The Get Product Detail API requires additional fields and would be included in the final spreadsheet shared with each bank.
How much time is needed to deploy the APIs after the customer bank provides its product reference data?
Production-ready PRD APIs under the standard configuration can be provided to the bank within two days of receiving the subdomain URL, to which the API endpoints would be configured, and the spreadsheet containing the mandated product reference data. This two-day period includes all timelines for deploying the pre-production environment, uploading data, testing, moving to production and testing the production APIs. Download the step-by-step guide for a breakdown of these timelines.
How does this impact cost?
The annual subscription cost of simplified rapid deployment of PRD APIs is significantly lower than a custom deployment. This is achieved by eliminating custom integrations to core banking systems and databases; eliminating services costs for deployment, maintenance, and upgrades; and by using templated standard format technology. Annual subscriptions costs are limited to the cost of the preconfigured open banking technology components, the managed cloud service, and the cost of infrastructure.
To request a quote, please contact us.
How does this affect the deployment of APIs to share consumer data?
As set out above, deploying APIs for sharing consumer data under the CDR regime (mandated as at now for non-major banks for 2021) does require additional work. This includes adding integrations to the bank’s existing core banking system, consent management, API security with FAPI R/W compliance, consumer authentication with LoA 3 assurance, API usage metrics, Data61 registry integration with dynamic client registration, and metadata cache management. The integrations would include linking to the customer’s existing user store for online banking and re-using existing bank customer authentication mechanisms to access consumer data. At this point, the customer bank could opt to keep the solution as a managed service or to move to either a cloud or on-prem deployment. Remaining with a managed service would, of course, result in a more seamless and cost-effective transition for the bank. However, with either deployment option, be it either managed cloud, cloud, or on-prem, the WSO2 Open Banking solution for CDR stage 2 consumer data APIs includes extensive advisory and technical services to help guide and support the bank in deploying secure Consumer Data Service APIs.
Deploying open banking technology is a journey through mere compliance towards making effective business use of the mandated and non-regulatory APIs. It is important that banks incorporate best practices right from the outset to avoid cost overruns and ill-suited technology deployments. Flowing from these best practices, and keeping current market realities in mind, the approach to PRD APIs set out above provides a practical option for smaller banks to set off on this journey on the right foot. This is achieved by securing accelerated regulatory compliance with minimal investment and a modern technology layer, which enables the full spectrum of open banking use cases.Download Step-by-Step Guide & Effort Estimate Contact us for more information
WSO2 Open Banking is a complete single-vendor solution designed to help banks of varying sizes and technology needs progress on a faster and hassle-free path towards full regulatory compliance. We partner closely with you through technology and services to take your projects beyond compliance to help you deliver digital banking experiences that delight your corporate and consumer banking customers. Our experience runs deep with core open banking technologies such as API management, identity and access management, enterprise integration and analytics built on the WSO2 integration platform. We combine this with regulatory expertise on the OBUK specification, Berlin Group NextGenPSD2, the Consumer Data Right and several other regional regulations. We currently serve banks in locations including Australia, the UK, the EU, and the Gulf.
For more details about our solutions or to discuss a specific requirement contact us.