How data recipients can implement Open Banking on AWS

On November 26, 2017, the Australian Government announced the introduction of the Consumer Data Right (CDR). Governed by the Australian Competition & Consumer Commission (ACCC), the CDR gives consumers greater control over their data, aiming to improve consumers’ ability to compare and switch between products and services. For example, fintechs can use Open Banking data to help customers find a credit card or loan most suitable for them. There are many use cases like this outlined in AWS Partner Adatree’s Open banking Use Cases report. Transparency driven by CDR will lead to more competitive pricing for banking products like mortgages, personal loans, credit cards, and savings accounts, as well as more innovative products and services that leverage consumer data.

Open Banking is getting launched via a phased approach. Product data was made available in June 2020. On July 1, 2020, the “Big 4” banks (data holders) – ANZ Bank, NAB, Westpac, and CBA – made data available for a range of consumer accounts. Progressively the next 12 months, the Big 4 are required to make data available from business, investment, and other accounts. Finally, on July 1, 2021, all other Australian banks will be required to share their consumer and business transaction data with accredited third parties (data recipients), at a customer’s request.

In this blog, I outline how Data Recipients can set up the Open Banking foundational layer on AWS to accelerate their journey to becoming an Open Banking Data Recipient. This blog focuses on Australia CDR legislation but the concepts and architecture can be extended for Open Banking regulations in other countries.

Open Banking ecosystem

The Open Banking ecosystem consists of data holders (DH), data recipients (DR), and CDR Register (ACCC). An organization that holds customer deposits (Authorized Deposit-Taking Institution, or ADI) is mandated under the CDR to become a data holder. There are 141 ADIs in Australia. Data holders are the “originators” of customer and product data, and must make that data available via Open Banking APIs to data recipients. Data recipients are those organizations accredited by the ACCC to receive or ingest Open Banking data upon a customer’s request. The ACCC performs the role of CDR Register and holds information of both data holders and accredited data recipients, as shown in the following diagram. Each ecosystem entity is supposed to implement respective APIs. The details of APIs can be found here.

Source: Modified version of the ecosystem diagram available at ACCC GitHub repository for CDR.

Data recipient accreditation process

Any organization that wants to become an accredited data recipient (ADR) has to go through the accreditation process outlined by ACCC and following is a screenshot taken from the same guideline document. It’s a five-step engagement process with multiple feedback loops. Once the accreditor is satisfied with the assessment, they inform the applicant of the accreditation. For more details on the process, review the Accreditation Guidelines.

Source: ACCC CDR Accreditation Guidelines.

Consent management process

According to CDR regulation, data holders can share the consumer data only if the consumer authorizes them to do so. Similarly, ADRs can request and use the data only when they have consent from the consumer for a given data holder. Data holders are required to record all the authorizations and ADRs are required to keep track of all the consents.

Let’s take an example to understand how consumer management flow works when a consumer wants to see their account balance across multiple data holders.

Step 1: Consumer/User logs into the ADRs software product.
Step 2: ADR initiates the consent process and asks for consent-related information. For example, which data holder, what kind of data (Personal details, transactions details, payee details, etc.)? Consent until what time (one month, three months etc.)? What happens to the data after expiry of consent (de-identify and retain the data or delete the data)?
Step 3: ADR will pass all the collected information from consumer to data holders’ Pushed Authorization request (PAR) endpoint to get a “request_uri.” The request_uri parameter allows ADRs to send a reference to a request object instead of the request object itself.
Step 4: Consumer is re-directed to the selected data holder’s login page along with the “request_uri” received in previous step. Consumer can log in with their existing credentials. Data holder authenticates the consumer and verifies the request_uri.
Step 5: After successful authentication, data holders confirm if consumer is happy to share the consented data with respective ADR. Consumer authorizes the data holder to share their data with the ADR.
Step 6: Authorization is recorded by the data holder and then the consumer is re-directed back to ADR along with an authorization code.
Step 7: ADR records consent and stores the information in consent database.
Step 8: ADR uses the authorization code given in step 6 to get the access token.
Step 9: ADR uses the access token to call the banking API of data holder to fetch the relevant data from data holder and store it in consumer database, which is managed internally.
*Steps 2–9 will be repeated for each data holder that consumer has an account with.
Step 10: Consumer request for a summary of account statement across all banks and data recipient can provide this information now by querying the internal consumer database.

Consent revocation

Consent can be revoked either through an ADR software product or going to the data holder application. The access token is revoked and data will be deleted or de-identified on ADR’s database based on the original consent. It is complex topic and demands a separate blog in itself. I suggest having a look at the blog post from my AWS colleagues on handling data erase requests and the patterns mentioned in the blog can be used for managing revoke flow.

Reference architecture

An accredited data recipient is responsible for doing consent management, integrating with data holders, ACCC, building the application logic to work with the CDR data and existing data. To simplify it, ADRs can isolate the banking integration and consent management functionality from their business logic functionality. They can further isolate their CDR data environment with existing data environment as security controls requirement of CDR might be different from what they are already using in their organization.

The following architecture is focused on the foundational environment required for integrating with banks, ACCC, managing consent, and hosting the business application. For setting up the foundational layer, a multi-account approach is recommended as it provides the highest level of isolation. The consent management account hosts the consent management and integration of APIs exposed by both data holders and ACCC. And, the business application account will host application-specific APIs and consumer data. Having two separate AWS accounts leads to isolation of workloads and effective management of AWS resources. This also makes it easier for a data recipient to bring in an AWS Partner for implementation and management of consent management account that can easily integrate with business application account.

Credit: Special thanks to Shane Doolan, CTO of Adatree for providing useful inputs to the reference architecture.

In the following section, I highlight below some major components of the architecture:

• Number 1 and 2 represent the consumers and the software product developed by an accredited data recipient.
• Number 3 represents data holders and ACCC who are the other entities of the Open Banking ecosystem.
• Number 4 represents an API management layer, which is implemented using Amazon API Gateway. It can be also integrated with AWS Web Application Firewall to protect against common web exploits.
• Number 5 represents the implementation of consent management related microservices using AWS Lambda hosted in a private subnet. AWS Lambda is chosen to meet the dynamic nature of the workload and to reduce the management effort required in managing servers.
• Number 6 represents the storage layer where consumer consents can be stored in Amazon QLDB to track consents and maintain a complete and verifiable history of changes over time. Amazon Aurora can store the necessary configuration and data required for consent management.
• Number 7 represents the application-specific microservices using AWS Lambda hosted in private subnet.
• Number 8 represents the storage layer where Amazon Aurora can be used for storing consumer data fetched from banks as well as any aggregated data. As the data is well-defined and structured, a relational database is chosen.
• Number 9 represents Private Amazon API Gateway. This API Gateway is used by the application-specific microservices to access the APIs hosted by the consent management account. Private API is used in this case as both the source and destination are internal and all the network calls happen on the AWS backbone and not through public internet. This results in enhance security and performance.
• Number 10 represents the AWS products that can be used for logging and monitoring. AWS CloudTrail, Amazon CloudWatch, and AWS X-Ray can give the desired observability required by the application. Amazon OpenSearch Service (September 8, 2021: Amazon Elasticsearch Service has been renamed to Amazon OpenSearch Service) can be used to aggregate all the logs and monitor the application and send notifications using Amazon Simple Notification Service. Amazon Simple Storage Service (Amazon S3) can be used to store static content of the web or mobile application and can also store all the logs with the right lifecycle policies in place.
• Number 11 represents the AWS products that can be used for security and compliance. AWS Config can be used to govern security controls mandated by ACCC, AWS Secret Manager for storing security assertions given by ACCC.  AWS Key Management Service (AWS KMS) for managing keys that is required to encrypt and de-crypt the data. AWS Certification Manager can be used to provide certificates to the Amazon API Gateway customer domain. AWS Shield can be used for DDoS protection and Amazon GuardDuty for intelligent threat detection.
• Number 12 represents further insights and analytics into the consumer data. For example, data recipients can build budget monitoring, credit decisioning use cases using this data.

Security and compliance controls

As part of the accreditation process, it is critical to understand which controls you as an ADR will operate and which you will inherit from AWS – we call this the Shared Responsibility Model. It is important to carefully consider your responsibility based on the services you choose, the integration of those services into their IT environment, and applicable laws and regulations.

The ACCC has released guidance for data holders and accredited data recipients on the Consumer Data Right Conformance Test Suite which can be found here.

Conclusion

CDR is a game changer and a step toward Open Data economy in Australia. It will give consumers greater control of their data and will encourage ADRs to build amazing innovative products for consumers. In this blog, I outlined how data recipients can be integrated with banks and build innovative use cases on top of CDR data. The reference architecture will help prospective ADRs to quickly start setting up the foundational structure for setting up consent management and business application account. The architecture covered in the post is designed for Australia CDR regime but can be extended for Open Banking regulations in other countries as the fundamentals of consent management remains same. If an ADR decides to build their own consent management platform, AWS has the right services to help them build it quickly. For those looking for support on this journey, AWS has the right partner network. For further details, contact your Account Manager or AWS Sales team.