Simplify Integration, Configuration, and Testing with Ready-to-Use Avaloq Model Bank in the Cloud
By Bilal Karaduman, Sr. Partner Solutions Architect – AWS
By Alejandro Balzarro, Solutions Architect – AWS
The world of banking and wealth management is undergoing a major transformation.
Most financial institutions are at different stages of their cloud journey. Many are challenged with delivering new and enhanced services, providing services faster, and driving operational efficiencies while facing increasingly competitive markets.
Changes are occurring at lightning speed, and in many use cases a playground environment is needed to test the delivery of new services and lay the foundation for agile implementation.
Avaloq has laid a good foundation to help businesses ease the journey of testing and integrating new solutions by managing the complexities across various phases utilizing Avaloq’s sandbox solution powered by Amazon Web Services (AWS).
The Avaloq sandbox is a model bank that runs on the Avaloq Core Platform (ACP), an automated system that simplifies and transforms digital banking with capabilities covering the full range of financial products and services, transactions, and processes.
The sandbox enables institutions to perform integration testing between the ACP and third-party solutions in a controlled and cloud-based setting.
Avaloq.one’s REST API technology enables seamless integration into the Avaloq Banking Suite and provides comprehensive test functions for users. User interface is available through a browser session in order to access all ACP functionalities.
In this post, we’ll highlight some of the features of Avaloq’s sandbox, cover the architectural and security principles, and dive into the sandbox lifecycle and infrastructure. We’ll also discuss how it can help you create a model bank to test, configure, and integrate in a controlled environment—all in one place.
Features and Benefits of Avaloq Core
The biggest asset of Avaloq Core is that it has one unified data model that goes across the core banking system and spans to Avaloq’s standalone, core-agnostic platforms.
The data model helps to reduce labor and operational costs by facilitating a high degree of automation in all processes. Key operations like accounts and payments, securities trading, and lending and credit facilities are handled efficiently. Manual processing or other labor-intensive tasks are eliminated in almost all back-office work.
The Avaloq sandbox provides a model of your bank that runs Avaloq Core Platform. It has all of the modules and functionalities you need to meet the mid- and back-office personas to run the daily operation. That means it covers all processes from trading over treasury to the back-office with accounting and compliance.
Within the sandbox, all capabilities are exposed through ACP REST APIs and via the ACP user interface.
Figure 1 – Avaloq Core capabilities.
Avaloq provides a number of tools to master the complexity of the banking system. Whether you’re in the design or build phase, there are tools that support customization, packaging, testing, and the deployment to production.
If you’re in the run phase, there are frameworks for monitoring, auditing, and scheduling to help to ensure a safe and stable operations.
Avaloq built a new cloud-native architecture using AWS to allow their banking customers to better serve clients while also giving those customers the opportunity to keep pace with rapid improvements in cloud services, application development, and integration.
ACP and the Avaloq sandbox are built around APIs using a microservice architecture. This makes the platform highly maintainable and testable, publishing loosely-coupled components that are independently deployable when needed and organized around API products.
Avaloq built a governance framework using AWS Control Tower to make sure all accounts are managed from a central management account and a new sandbox account is created for clients in an automated fashion when requested.
The sandbox account includes private subnets to host Envoy reverse proxy, Avaloq Container Platform Reference (ACPR), and Avaloq Core Platform products. They are exposed through Network Load Balancer and Application Load Balancer.
Figure 2 – Component diagram.
The Avaloq sandbox has a modular and feature-complete orchestrator built around the Ansible Tower on AWS automation tool. It achieves strong boundaries across tenants and a reliable structure by leveraging multiple AWS accounts.
Avaloq has an enterprise setup on AWS, which allows you to manage organizations and generate multiple accounts for different use cases. It makes use of AWS Organizations quite extensively in the sandbox platform.
The accounts are structured in organizational units (OU), similar to a folder structure.
It has a “Sandbox OU” which contains the different stages. Per stage, Avaloq has the account for the management zone, as well as the OUs for the customer accounts:
- Pool: Contains a number of prepared accounts ready to be used for a customer account.
- Customers: The accounts of active customers.
- Expired: The deleted accounts. There’s a garbage collection process, which deletes the expired accounts after a while.
Figure 3 – Organization structure.
When talking about the management and customer accounts, we often like to split the architecture in half, referring to control plane and data plane.
The Management Account consists of the tooling, logic, and all of the components Avaloq developed to orchestrate the deployment process of sandboxes, providing a great user experience while doing so.
Customer Accounts run the actual “sandbox,” which is the same Avaloq software that operates as software-as-a-service (SaaS), or that customers run on premises.
Figure 4 – Management account.
In AWS terms, an account is the most basic multi-tenancy structure. Virtual private clouds (VPCs) are the most fundamental boundary to separate resources. Each tenant gets one AWS account and one VPC with the sandbox resources deployed.
Having a multiple-account structure has its own unique advantages such as:
- Identity and access management (IAM): This means that a security breach in one account cannot compromise or purge resources of other clients.
- Billing: While tags can be used to group costs produced by certain resources, accounts are the ultimate way to ensure all billable items—such as the cost of bandwidth—are allocated to their real users.
- Quotas: This is often overlooked but important when designing environments with many users and automated deployments. For cloud-based workload architectures, there are service quotas, which are also referred to as “service limits.” These exist to prevent accidentally provisioning more resources than you need, and to give you full control over them.
Designing by being aware of the service quotas and constraints is a reliability best practice as per the AWS Well-Architected Framework.
The Avaloq sandbox implements a state machine-based approach for managing the lifecycle of the system that’s more suited for the interactive nature of digital banking systems than traditional workflow systems.
The lifecycle is defined by an enumerated set of states known at the time of implementation. The following diagram shows the allowed transitions between states, including failure transitions.
Figure 5 – Lifecycle diagram.
The initial started state is reached after a sandbox creation request. It starts in the initializing state, runs through a series of states during its lifecycle, and finally ends up at deleted state, when it may receive a shut-down signal that causes it to complete its behavior.
Creating a sandbox makes it possible for you to run your model bank in an isolated environment and test your implementations without effecting the existing code or current users. It follows a series of steps in an automated fashion to create a sandbox environment.
Figure 6 – Sandbox creation process.
- It starts with a user request which triggers a sandbox creation workflow.
- The workflow registers its state in the state machine database as initializing.
- A message is sent to the Ansible Tower on AWS adapter via REST API interfaces.
- Some of the resources used to create a sandbox are stored in the management account. These resources are shared with customer account:
- Amazon Machine Images (AMIs) for Avaloq Core Banking Platform and the OpenShift Cluster Platform (OCP).
- Elastic container registries of all Docker containers.
- Once the resources are shared, sandbox-specific subnets and security groups are created. Each sandbox is put into its own subnets and security groups to ensure they are properly encapsulated and connections between sandboxes are prevented.
- Virtual machines of the sandboxes are created utilizing the given AMIs in the management account:
- ACP – The virtual machine on which Oracle is installed and running Avaloq Core Platform.
- OCP – A single node OpenShift cluster on which constellations are deployed.
- A network address translation (NAT) gateway is set up to allow the connection of sandboxes to internet.
- An ingress is set up to route the traffic to the sandboxes. It consists of the following components:
- Application Load Balancer.
- Network Load Balancer that’s only created if a sandbox with Apache Active Message Queuing (AMQ) exists, for which a layer 4 traffic routing is needed.
- Two open-source Envoy proxy instances to act as a reverse proxy.
- Amazon AppStream 2.0 is set up to spin up a fleet of Windows Servers which host the Smart Client and integration server. This is only created if a sandbox with Smart Client exists.
- Constellations on the OCP instance are installed by triggering the Avaloq Installer over AWS Systems Manager. During this process, a certain set of configuration values are set matching the environment of the sandbox.
- Once the process is complete it sends a feedback message back to Ansible Tower on AWS.
- On receipt of the message, the backend microservice updates the state as started in the database and completes the workflow.
Besides the creation of sandbox, AWS infrastructure is set up if needed.
The sandbox follows a series of steps to start, beginning with a user triggering the start of an existing sandbox. Sandbox state is then set as starting in the database.
The backend microservice sends a message via RabbitMQ to the Ansible Tower on AWS adapter, which picks up the message and calls the REST APIs of Ansible Tower on AWS to trigger the start of the sandbox.
Amazon Elastic Compute Cloud (Amazon EC2) virtual machines for the sandbox are triggered to run. A feedback message is sent back to the backend microservice, and finally the sandbox is marked as started in the database.
Figure 7 – Sandbox start process.
Similar to starting the sandbox, stopping the sandbox triggers a workflow as follows.
Figure 8 – Sandbox stop process.
When a sandbox is no longer needed, tearing it down is as easy as starting it. Users can request the deletion of a sandbox which triggers a workflow to remove all of the resources associated with the sandbox.
Similar to the creation, start, and stop workflows, teardown uses the same application workflow to dispatch the message to Ansible Tower on AWS over RabbitMQ and trigger the workflow.
All virtual machine instances, sandbox-specific subnets and security groups, ingress resources such as the load balancers and Envoy proxies, AppStream fleet and stack, and NAT gateway are deleted.
Finally, the state of the sandbox is registered as deleted in the state machine.
Figure 9 – Sandbox deletion process.
A high-level view of the layers of the infrastructure landscape is depicted with an onion skin architecture. This represents a way to structure and clearly separate organization, operations, and underlying technologies that implement the solution.
Figure 10 – Onion skin architecture.
The Avaloq sandbox is deployed to a customer-dedicated AWS account in a multi-region, multi-server infrastructure utilizing Amazon VPC.
For each sandbox account, you can create and set up an individual AWS account which has advantages with respect to security, access control, cost optimization via distribution of costs, and flexible management.
Each account has its own infrastructure to route traffic to the sandboxes. It also includes Envoy instances as a reverse proxy (an open-source proxy project), and AppStream fleet if Smart Client is offered.
Deployments of the infrastructure resources that are billable on a time-basis are only created when they’re needed, meaning they will be provisioned when you have running sandboxes in an account.
This optimizes the resource usage and brings down the cost significantly. The goal is that when no sandboxes are running, none of those resources exist and such an “empty” account will have no cost implication. Therefore, when a sandbox is created or started, the setup process detects the state automatically spins up the resources.
Avaloq has separate playbooks that control the provisioning and decommissioning of the resources and the infrastructure. For that to work, the same playbook cannot run in parallel for the same customer account to avoid playbooks to clash when resources are being created because it might be torn down by another playbook.
To ensure that a playbook does not run in parallel, Ansible Tower on AWS offers a Boolean flag on the respective job templates to disable concurrent runs.
The AWS components and services required to build up the sandbox infrastructure can be demonstrated as follows.
Figure 11 – AWS components and services.
The Avaloq sandbox provides security and management capabilities that exist\s in every stage, from identity management to application communication and operating system provisioning. It evaluates all threats from both sandbox administration and sandbox usage aspects and takes appropriate measures to mitigate them.
- All accessible endpoints are protected behind AWS WAF, a web application firewall which mitigates denial of service (DoS) attacks and unauthorized access.
- It implements authentication and authorization so only authenticated users can access to sandbox APIs.
- Programmatic access is also protected with application-level security.
- Overloading an account by trying to create many sandboxes is limited to avoid such attacks.
- Customer accounts are segregated from each other by using AWS Organizations.
- Instances are running in their own subnets and within their own VPCs.
- Security groups are in place to control access to instances in both directions.
The Avaloq sandbox implements OAuth2 and OpenID Connect standards for securing access to information and resources.
Developers can request a valid bearer token from KeyCloak in management account by providing the sandbox user credentials and client credentials, thus following the Resource Owner Password Credential Grant.
Figure 12 – Authentication process.
The Avaloq sandbox is a model bank that runs on the Avaloq Core Platform (ACP). You can easily perform integration testing between ACP and third-party solutions in a controlled and cloud-based setting.
Once onboarded—whether you’re a fintech or developer in a financial institution—you can start testing in your individual sandbox environment and swiftly develop your applications, integrate, and test functions against the Avaloq Banking Suite. All of this is enabled using Avaloq REST APIs.
Based on a cloud infrastructure built on top of a wide range of AWS services, the Avaloq sandbox enables financial institutions to fast-track their ecosystem integration strategy on top of an Avaloq Banking Suite.
Avaloq – AWS Partner Spotlight
Avaloq is an AWS Partner and global leader in digital banking solutions, core banking software, and wealth management technology.
*Already worked with Avaloq? Rate the Partner
*To review an AWS Partner, you must be a customer that has worked with them directly on a project.