An AWS Centric Solution Architecture for Open Banking
Open Banking and Existential Disruption
A huge change is approaching in the regulatory landscape that places banks directly at risk of existential disruption.
Open Banking and PSD2 are British and European legal regulations that are set to open up banking data to consumers over Internet-accessible APIs. Once a bank customer’s account, transactional and product data are exposed through APIs, it becomes easier to move between providers, or even work with existing accounts through third party applications, websites or mobile applications, e.g. comparison shopping sites, the mobile apps used to manage bank accounts, or integrating customer banking details into other sites such as Facebook or Amazon.
All of these uses cases improve consumer choice and control over their financial data, and it is hoped by regulators that this will feed through into a more competitive marketplace for banks.
Crucially for banks, once data is opened up in this way, new fintech providers or market entrants can build better digital experiences in front of the bank’s platform. This reduces the bank to a mere utility or commodity provider who loses the front-end relationship with the customer, and therefore the ability to cross-sell or up-sell.
If banks do nothing, the only possibility is that they will lose business to other organisations and banks that respond faster.
Banks now face a double challenge: they must not only become compliant with Open Banking and PSD2 – a large technical task in and of itself – but then also fight back against the threat of disruption that these bring. They will have to do this by building the best possible APIs with additional valuable features that go above and beyond the basic capabilities that make them compliant. Then, they will also need to improve their own applications and digital front-ends to make them competitive against the alternative options that will be enabled by the new legislation.
This means going toe-to-toe with smaller and more agile fintech organisations. And banks will have to act quickly, as the deadline is approaching fast.
Challenging Timelines
PSD2 will be the law in EU Member States by January 2018, whilst the Competition and Markets Authority have ordered the nine biggest banks in the UK to frame an Open Banking standard in the same timeframe. As these nine banks have a dominant aggregated market share, this will create a de facto mandatory standard for the UK marketplace.
For anyone who has worked in banking environments, they will appreciate that scarcely over a year is a very short period of time in which to design, build and deploy new infrastructure, new applications and new connectivity. Banks are waking up to the incredible urgency and far-reaching implications of the technical ask and are looking at how to deliver on this and their broader API strategy within an accelerated timeframe.
There are also huge commercial and product challenges around how to risk manage an environment or platform through which thousands of parties are interacting with your organisation, sharing financial information or exposing commercial offers or operational processes to their own users. Keeping control of all of the risks in the API economy will also require technical solutions.
To make things worse, Open Banking isn’t just a typical regulatory project with tight timelines. Banks are exposing APIs to legacy back end systems full of transactional data, so integration is complex and security will be very high on the agenda. Banks also haven’t necessarily had the experience of developing APIs for very broad consumption, or know how to manage them at scale in a risk-managed way.
There is a huge amount of technical work that must be done within a very short space of time if banks are to avoid painful legal repercussions or existential disruption from agile startups that will look to exploit this regulatory change.
Why Build Open Banking On Amazon Web Services?
At Contino, we instantly recognised that public cloud was the ideal platform to initially accelerate compliance with Open Banking, and then turn the API economy from a threat into an opportunity.
We all know the inherent benefits of cloud: elasticity, auto scaling, auto-healing virtual infrastructure available immediately at the click of a button under a pay-as-you-go model. The business case and time to market benefits of this are clear, with large enterprises and financial services brands aggressively adopting the cloud.
For a project like Open Banking, however, the real advantage lies in the higher-level platform services for managing APIs and taking control of the high volumes of data that we will generate as partners interact with our APIs. These services will help banks get to market quickly with their APIs and build platforms that are inherently more scalable, robust, secure and easier to iterate on than anything that can be delivered in the data center.
This means that banks are able to not only achieve compliance, but innovate swiftly and repeatedly on their front-end services to maintain competitiveness against potential market disruptors.
Amazon Web Services has a massive market and product lead in the area of API gateway management, big data, analytics and other services that banks should be looking to leverage as part of their API strategy.
Our Proposed AWS-centric Solution Architecture
To demonstrate some of the key concepts, Contino has devised a relatively high-level solution architecture that describes how we would leverage various AWS components to make Open Banking a reality. This is described below.
Environment Design
In line with best practices, a number of secure, segregated application environments are maintained, configured by and deployed to a centralised management environment. Environment segregation at the AWS account level ensures there is no crosstalk between environments -- whether malicious or unintentional -- and separates out the differing needs and controls required by environments from development to production.
To support the requirements around automated application deployment and testing, technologies such as Packer, Terraform and Ansible are used, providing correctness and repeatability throughout the provisioning process, along with an audit trail of actions performed. The use of infrastructure-as-code techniques allows for environments to be provisioned and maintained by way of automation, avoiding error-prone, untrackable and time-consuming manual modifications. Immutable infrastructure means that changes are testable and can be progressed through environments with confidence.
Ease of environment component rebuild and the use of blue/green deployment mean that architecture components can be manipulated as units -- this brings with it the capability to commoditise environment components to rebuild in different regions, for example, along with facilitating more rapid DR procedures, thus shortening recovery time objective (RTO).
Environment Services
Drilling down into each environment, we are proposing a reference architecture that integrates many modern AWS services to provide accelerated time to compliance and innovation, but in a controlled and governed way, as per the diagram below:
Key Features Of This Architecture
Security
Security is key to the design of the platform, employing encryption of data at rest and in flight, and isolation at the network level. A tiered AWS Virtual Private Cloud (VPC) configuration is used to provide a segregated network environment, with NACLs and Security Groups used to provide a layered security model with compartmentalisation between platform components. AWS Direct Connect is used to provide a dedicated network link back to the banking organisation’s networks. An IPSec VPN tunnel is additionally used over this link to provide encryption of data in transit.
API Management
The external user entry point to the platform is built around AWS API Gateway. API Gateway is a scalable and programmatically configurable API Management service offered by AWS that is used at scale by a number of large organisations. This accelerates the time to building and provisioning internet accessible APIs, and adds controls around them. Depending on requirements, a CDN may be used to distribute any assets (for a portal, for example) and provide enhanced protection.
Authentication and Identification
A bank providing these APIs may want to become an identity provider who issues access keys to verified organisations or individuals consuming the APIs. The reference architecture leverages AWS Cognito to provide this capability so that people can sign into third party sites whilst authenticating against the bank under a model similar to OAuth or OpenID. Use of an external, third-party identity provider may be a requirement also.
Front-end Service Tier
As the initial point of user contact within the platform itself, front-end services provide core personalisation and interaction features between the banks APIs and the various web and mobile and clients. As the front door, the security of these services is crucial.
Business Logic Tier
The business logic tier contains the application services that house the bulk of the domain-specific functionality within the platform. It is these services that communicate securely with the banking systems back-ends, and query any data held within the platform. Message queues can be used to decouple services and help with the design of stateless application services. Analytics functions feed back into these services, completing the feedback loop.
Containerisation
Our reference architecture proposes that any code not deployed into Lambda is containerised in order to enhance security and traceability benefits. For instance, containers can allow APIs to be segregated and isolated from one another. For this reason, we would integrate the platform with Elastic Container Service, which would host a number of auto-scaling and self-healing clusters, deployed to avoid tight coupling of services. Alternative container orchestration platforms may be used if a particular bank has existing investment or expertise in those technologies.
Serverless
The reference architecture is designed to incorporate serverless processing using AWS Lambda. Using serverless technologies is a highly efficient and cost-effective model for writing business logic behind APIs, and brings with it the gains of no longer needing to manage underlying infrastructure or host operating systems. This means that teams can focus on writing and enhancing differentiating business logic, with little concern for how that code is executed, scaled and managed.
Data Tier
Open Banking brings with it a big risk management challenge, with banks opening up to a wide user community of third parties to build against their platform. This means that the data and analytics tier plays a key role in security profiling, threat modelling, and analysis of how the platform is being used. Our data is shipped from API Gateway or business logic domain services into a data tier for archiving and audit, and an analytics tier for risk management checks and dashboard visualizations. The data tier includes facilities for traditional relational databases, NoSQL datastores and an in-memory Redis datastore for caching or session management purposes. Not shown in the diagram are any additional supporting services that may be deployed, for example Hashicorp Vault, which is used to securely manage and distribute secrets required to allow services to securely authenticate within the platform.
Management Tier
The management tier contains infrastructure and resources that relate to the correct and continuing operation of the platform. This incorporates services such as infrastructure and OS logging and metrics aggregation, which can be fed into an alerting platform.
Analytics Tier
The analytics tier houses services that are used to drive value and visibility from users’ interactions with the platform. An organisation’s data scientists and machine learning specialists can benefit from a flexible and scalable analytics platform, that may be entirely decoupled from the main platform, as requirements dictate. AWS Elastic Map Reduce (EMR) can be used to run analytics workloads using Hive, Spark, Pig, and many other popular frameworks as well as traditional Hadoop, and store data across a wide range of AWS and Hadoop-native data stores. Machine learning using AWS-intrinsic services or popular frameworks such as TensorFlow can be leveraged to provide both customer and in-house teams with value-added services.
Dashboarding
Our reference architecture incorporates risk management dashboards into the platform based on Splunk – or an open source alternative such as Elasticsearch/Kibana – to give risk managers and product managers visibility of how the APIs are being used and by whom. Any user or organisation stepping outside of governance will be flagged to the risk management board. Dashboards configured for audiences with differing requirements allow domain experts to quickly identify anomalous activity and “bubble up” suspicious activities.
Audit Trail
All traffic passing through an API gateway and the application stack can be tracked and logged to ensure visibility and in such a way that the logs cannot be tampered with. Each application service logs all events to a dedicated audit service, with the audit trail analysed in the Analytics Tier. With alerts configured for suspicious or obviously malicious activity, this audit trail can additionally be leveraged within the built-in platform analytics and machine learning capabilities to provide better personalisation across the services offered.
Code Pipeline and Governance
It is essential that code deployments are controlled throughout the software development lifecycle. Without these controls in place, a banking developer could maliciously or accidentally expose the bank to regulatory or reputational risk through a code change in an API. Therefore, our reference architecture proposes that our platform would integrate with a tool such as Service Now to enforce controls and workflow approval processes.
Integration with Legacy
Though there is significant engineering work here, this is out of scope of the reference architecture. We would propose a direct connection from AWS into the back end environment and then standing up a secure proxy with mutual authentication in the bank’s environment. Behind this secure proxy, the heavy lifting takes place to integrate with transactional or reporting databases, mainframes and other batch systems.
AWS ElastiCache is used in the cloud environments to manage a most recently used cache of data in the client where possible to reduce latency and avoid a avoid highly chatty connection between the AWS-hosted microservices and the back-end.
Supporting AWS Services
The following AWS services are additionally used by platform components:
- ECR: used to store Docker images
- Cognito: API gateway authentication with third party identity store
- S3: versioned object store
- Route53: programmable DNS
- SES: email sending functionality
- KMS: encryption key management service
- CloudHSM: optional cloud hardware security module
AWS for Open Banking
The fundamental problem that lies at the heart of regulatory compliance for banks is the need to increase the complexity of governance and control (e.g. by complying with PSD2) whilst simultaneously learning how to go faster than they were previously, despite the additional complexity.
The solution is to increase the fundamentally increase the rate of change across your software delivery pipeline. Governance requirements can then be more swiftly included in, and maintained through, the software delivery process. Then, when agility increases, governance is brought along with it.
The benefits of AWS can be brought to bear on Open Banking and PSD2 to give banks the agility and flexibility that they need to increase the rate of change and therefore meet compliance requirements whilst accelerating the pace of innovation.
Accelerated Compliance With Open Banking With Continuum
We can help you get to the cloud in days. Our DevOps mature cloud adoption framework Continuum can accelerate the time to an Open Banking deployment for organisations new to the cloud.
Continuum stands up segregated, secure environments that are configuration managed across the stack. Developers can then develop APIs in either a serverless model using AWS Lambda, or containerised microservices. With a click of a button Continuum can create a CI/CD pipeline in AWS in under ten minutes. Using Continuum, a bank could be developing new APIs which both achieve compliance and drive competitive advantage within days.
