AWS for Industries

Defining an AWS multi-account strategy for a digital bank

Background

The global banking landscape has been experiencing significant transformation over recent years, as customers increasingly expect an always-on, fully digital and personalized experience, triggering changing expectations around their banking services. While evolving consumer expectations and technology advancements have been primary drivers in the growth of digital banking, regulatory support through the introduction of open banking regulations (PSD2 in the EU) and dedicated digital banking licenses across the Asia Pacific region have provided a framework to nurture this journey.

The digital banking space continues to attract a diverse range of industry players, from incumbent banks building digital banking off-shoots, including Mox by Standard Chartered Bank, Marcus by Goldman Sachs, and TNEX by MSB in Vietnam, to emergent new challenger banks, including GrabBank, N26, and NuBank. There are 249 digital banks as estimated by Boston Consulting Group (BCG). You can learn more about building a digital bank on AWS on the AWS digital banking website.

For the purpose of this blog post, I will focus on digital banks looking to stand up technology stacks from scratch that are secure, resilient, and compliant, but also agile and scalable. However many of the principles explained in the blog are also applicable to other types of digital banks, such as digital bank off-shoots.

Why should you set up a multi-account AWS environment?

Many financial services institutions face the challenge of having teams with different business processes that require isolation from other workloads and have varying requirements for security and network controls. With an AWS Account, organizations can achieve the highest level of isolation for their workloads. Use of multiple AWS accounts plays an important role in how you meet your business, governance, security, and operational requirements.

Following are some of the benefits of setting up multi-account AWS environment:

  • Rapid innovation with various requirements – You can allocate AWS accounts to different teams, projects, or products within your company ensuring that each of them can rapidly innovate while allowing for their own security requirements.
  • Simplified billing – Using multiple AWS accounts simplifies how you allocate your AWS cost by helping identify which product or service line is responsible for an AWS charge.
  • Flexible security controls – You can use multiple AWS accounts to isolate workloads or applications that have specific security requirements or need to meet strict guidelines for compliance such as for HIPAA or PCI.
  • Easily adapts to business processes – You can easily organize multiple AWS accounts in a manner that best reflects the diverse needs of your company’s business processes that have different operational, regulatory, and budgetary requirements.

More guidance can be found in the Organizing Your AWS Environment whitepaper which shares guidance on organizing multi-account architecture. We will use the guidance in the whitepaper and apply it to define the multi-account strategy of a digital bank. You can also review the core concepts of the AWS Organizations terminology and concepts including Organization, Root, Account, Organization unit (OU) that are key to understanding this post.

Setting up a multi-account digital bank

An Organization Unit (OU) is a container of accounts within a root. An OU also can contain other OUs, enabling you to create a hierarchy that resembles an upside-down tree. Let’s consider what account groupings or OUs you can create for a digital bank. An OU should be based on function or common set of controls rather than mirroring your company’s reporting structure. AWS recommends that you start with security and infrastructure in mind. Most businesses have centralized teams that provide services to the entire organization. As such, AWS recommends creating a set of foundational OUs for these specific functions. The following diagram shows the recommended OU structure for a digital bank.

Figure 1: Digital Bank OU Structure

We have added two workload OUs, ‘Banking Applications’ and ‘Data and Analytics’, to the existing Infrastructure, Security, Deployment, Policy Staging, Sandbox and Suspended OUs that are recommended in the “Organizing Your AWS Environment Using Multiple Accounts” whitepaper.

  • Banking Applications OU: This will be used for running banking applications. It will have accounts for hosting workloads such as core banking, payments, on-boarding, credit decisioning, and regulatory reporting. This OU can be further divided into Retail OU (for Retail Business Unit) and Corporate OU (for Corporate Banking) based on the bank’s business interests. This is useful when you want to isolate business unit workloads and apply different policies to them. We will cover the account structure in detail in the next section.
  • Data & Analytics OU: Many customers have separate OU for analytics. A separate OU provides the security, governance and cost controls on the analytics functions. It will have accounts for data and analytics and machine learning workloads. We will cover the account structure in detail in the next section.

AWS account structure for a digital bank

After settling on the OU structure, we look at the AWS accounts that will be part of each OU. The following diagram shows the recommended foundational AWS accounts that are required to set up a digital bank. However, this might vary based on the product offerings provided by the digital bank.

Figure 2: Digital Bank OU & Account Structure

 In following sections, I will cover AWS accounts under Banking Applications OU and Data and Analytics OU. For AWS accounts under other OUs, you can refer the “Organizing Your AWS Environment Using Multiple Accounts” whitepaper.

 AWS Accounts under Banking Applications OU:

Let us look at the high level functional layers of a digital bank which help us in arriving at AWS accounts required by a Banking Application OU. It will look like the following diagram (for simplicity, I have omitted horizontal services such as Networking, Security, DevOps other infrastructure and management layers).

Figure 3: High Level Functional Layers

The Core products layer will host all the core products such as core banking and will be abstracted using custom built microservices, which in turn will be consumed by the Experience APIs.  The Experience layer is a purpose built API for user interfaces hosted using digital channel and customer engagement applications. Customer and core banking life cycle changes will emit events to ‘Event Hub’ and subscribers of these events can orchestrate necessary actions.

The following section covers each of these layers in detail and including how you can run these layers in multiple accounts. Following are the recommended accounts under Banking Application OU and account segregation is based on ownership and different security requirements of each workload.

  1. Core Products Account: A digital bank will have multiple core products deployed such as Core Banking, Credit Decisioning, Payments system, Card Management, Risk and Compliance systems, Accounting software, Treasury, etc. Some digital banks want to build some of these capabilities themselves and others rely on Independent Software Vendors (ISV). The choice is driven by the organizational culture, available skill sets and resources, and how quickly a digital bank wants to release their products and services to the market. Depending on the software, the customer will have a choice to deploy ISV solutions on their AWS account or to use a SaaS version to reduce management and operation efforts. Refer to the list of AWS Financial Services Competency partners to find an AWS partner who can help you accelerate in providing core capabilities. For increased security and isolation, we recommend that you have separate AWS Accounts for core systems. The number of accounts you need will also depend on the choice of core products you develop. For example, certain core banking software products available in the market come with core banking, payments, wealth management and treasury modules whereas other core banking providers simply provide modules only for core banking and payments.
  2. Core Microservices Account: This account will host the microservices to create an abstraction and aggregation layer on top of core products which will then be exposed to the bank’s Experience API layer. It will have integrations with the core products over multiple protocols and data models. It will have microservices for retrieving account information, customer profile, setting payment instructions, etc. AWS services such as Amazon API Gateway, AWS Fargate, Amazon Elastic Kubernetes Service (Amazon EKS), and Amazon Elastic Container Service can be used for building container based microservices with databases such as Amazon DynamoDB and Amazon Relational Database Service (Amazon RDS).
  3. API Management Layer Account: Core microservices will be exposed to end consumers using Experience APIs. These APIs are purpose built APIs that orchestrate multiple microservices calls based on requirements of mobile, web and other channels. This layer will also have the API Management capabilities such as rate limiting, throttling and API protection capabilities like web application firewall and application layer Distributed Denial of Service (DDoS) protection. APIs can be exposed using Amazon API Gateway with AWS Web Application Firewall (AWS WAF) to provide protection against common web exploits. AWS Shield provides managed DDoS protection against all known infrastructure (layer 3 and 4) attacks, safeguarding applications running on AWS. AWS AppSync can be used for building APIs with GraphQL, which is a common pattern to deploy experience layer APIs aggregating data from various underlying domain centric microservices.
  4. Digital Channel Application Account: A digital bank may have various channels to deliver the banking experience, for example web and mobile application for their customers and partners. These applications provide customer/partner origination and on-boarding journeys and will be part of this account. Some of the services that AWS offers in this space are AWS Amplify to quickly build mobile and web apps, Amazon Step functions to create workflows, Amazon Simple Storage Service (Amazon S3), and Amazon Elastic Compute Cloud (Amazon EC2) to host any third-party software.
  5. Customer Engagement Account: In the absence of physical branches, customer engagement is key for a digital bank. The Customer Engagement account will have functionalities around providing omnichannel contact center support over voice and chat, marketing and loyalty products, Customer Relationship Management (CRM) software, and campaign management software. Some of the services that AWS offers in this space are Amazon Connect, Amazon Pinpoint, and Amazon Lex.
  6. Events Management Account: Event driven architectures help digital banks scale and also offer near real-time processing capabilities. Any events in the core transaction system should be emitted and captured in this account so that subscribers of the event can orchestrate necessary actions such as sending a transaction notification to a customer or performing anti-money laundering checks. Some of the services that AWS offers in this space are Amazon Managed Streaming for Apache Kafka (Amazon MSK), Amazon Kinesis and Amazon Simple Notification Service (Amazon SNS).
  7. Open Banking Account: This account will host the APIs required to meet a country’s regulatory requirements and it integrates with the microservices accounts to fetch required information. This account also hosts consent management, sandbox and developer portals for partners consuming the Open Banking APIs.
  8. Data Bunker Account: A data bunker is a secure account which will hold data such as data backups, snapshots, AWS CloudFormation templates, and Amazon Machine Images (AMI) in a secure location within the primary AWS region. The data will be encrypted at rest using services such as AWS Key Management Service (AWS KMS) and in transit using TLS. In the unlikely event of any data loss in the primary account, this account is used to recover the bank’s data and backups. Least privilege is granted to the members of the digital bank’s security team to access this account. Here is guidance on granting least privileges.

All accounts should follow AWS security best practices. The same account structure can be followed for Development and Test environments under Banking Application OU. You can have multiple test environments such as one for User Acceptance testing and one for System Integration Tests.

AWS Accounts under Data & Analytics OU:

Digital banks are innovating and giving personalized offerings to customers, looking for cross-selling opportunities, and providing better customer services. To achieve all of these, digital banks require a secure, flexible and scalable analytics platform.

A multi-account architecture for Data & Analytics OU is a comprehensive topic with a number of variations and could be a dedicated blog in itself. A multi-account architecture for a data environment supports a Lake House architecture providing data at scale, the best price-performance, seamless data access to solve business challenges, and unified governance. We recommend three accounts to start with an easy-to-set up configuration that can be extended as the environment scales.

  1. Data Ingestion Account: An intermediary account that enables data ingestion from a variety of sources into the Lake House storage account (data-lake-house-storage-account). This account provides the ability to connect to internal and external data sources over a variety of protocols. For example, data from different LOBs, ERP applications, CRM applications, and web and mobile applications will be delivered to the lake house storage account through this account. This account will leverage AWS Services such as Amazon Simple Storage Service (Amazon S3), Amazon Kinesis, Amazon Managed Streaming for Apache Kafka, AWS Database Migration Service and AWS DataSync.
  2. Data Lake House Storage Account: This account provides durable, scalable, and cost-effective components to store and manage vast quantities of data. In a Lake House Architecture, the data lake, data warehouse and other purpose built stores natively integrate to provide an integrated, cost-effective storage layer that supports unstructured as well as highly structured and modelled data. The storage layer can store data in different states of consumption readiness, including raw, trusted-conformed, enriched, and modelled. This account will also have the processing layer components to transform data into a consumable state through data validation, clean-up, normalization, transformation, and enrichment. This account will leverage AWS Services such as Amazon S3, Amazon Redshift and Amazon Elasticsearch service for storage; Amazon Elastic Map Reduce (Amazon EMR) and AWS Glue for data processing; and AWS Lake Formation for governance.
  3. Data Consumption Account: This account provides scalable and performant components that use unified lake house interfaces to access all the data stored in lake house storage account and all the metadata stored in the lake house catalog. This account will be accessed by the data scientist and data analyst teams. There can be multiple consumer accounts based on the usage and security controls. There can be one for machine learning and one for standard analytics. This account will leverage AWS Services such as Amazon Sagemaker Studio, AWS Glue DataBrew, Amazon QuickSight and Amazon Athena.

The same account structure can be followed for Development and Test environments under this OU

How can AWS help to set this up?

Creating and managing multi-account structure requires security, governance and cost controls along with the right automation steps in place. AWS Control Tower provides the easiest way to set up and govern a secure, multi-account AWS environment, called a landing zone. AWS Control Tower creates your landing zone using AWS Organizations, bringing ongoing account management and governance as well as implementing best practices based on AWS’s experience working with thousands of customers as they move to the cloud. You can implement AWS Control Tower, extend governance into new or existing accounts, and gain visibility into your compliance status quickly. You can do it by yourself or you can leverage AWS Professional Services, or you can choose from one of our AWS partners.

Conclusion

In this post, we covered the benefits of using a multi-account strategy for a digital bank and the important factors a digital bank should look at while defining an AWS account structure. It is important to set up the landing zone with thought to the types of workloads that you will want to operate so that it can be easily extended for future requirements. We are helping digital banks across the globe to run on AWS and you can reach out to us if you need any help. For more information on running financial services workload on AWS you can have a look at the following web pages, blogs, and whitepapers.

TAGS:
Akash Jain

Akash Jain

Akash Jain is a Financial Services Specialist Solutions Architect and has been with AWS for 5 years. He leads the technology initiatives for Digital Banking, Open Banking and Core banking modernizations across APAC. He has 16+ years of experience in architecting and implementing critical workloads across industries and has been the author of a dozen external publications. He is a regular speaker at AWS and other FSI events.