Open Banking Architecture 1 Open Banking Architecture · Form /Report Business Domain X ... Enable developer community and ecosystem based on industry -standard technologies SaaS/BPaaS

1Open Banking Architecture

essential for banking

October 2019

Open Banking Architecture




The pathto the futureNew initiatives such as APIs, microservices and self-contained systems, mobile and browser-based UIs for different user personas and overall digitalization are changing the face of banking. At the same time issues such as data quality, automation and security clearly remain of critical importance. Avaloq’s architecture has been developed to address both these new opportunities and the perennial concerns, while preserving Avaloq’s existing strengths such as consistency and out-of-the-box integration.

In 2017, we announced a major update to our architecture strategy, based on the introduction of self-contained systems with microservices deployed as Docker containers on Kubernetes (K8s). For our clients, the transition to self-contained systems provides both substantial efficiency gains and a versatile platform for future innovation. Alongside the introduction of new Open and Community REST APIs, mobile and browser-based UIs to meet the needs of specific user personas and event-based replication, this enables Avaloq’s clients to make the most of the exciting opportunities offered by a rapidly-changing world.\

• Containerization brings direct efficiency improvements through higher utilization and reduces operations overheads through standardization. Kubernetes allows banks to scale up without expanding their ops teams. As its creators point out, it is designed on the same principles that allow Google to run an astonishing 2 billion containers every week.

• Our new Open and Community APIs open up access to the Avaloq banking platform, paving the way to rapid and robust integration with partners and existing client systems and reducing the costs and risks of bringing new ideas to market.

• Faster and richer browser-based and mobile UIs simplify lightweight UI integration of content from multiple systems and vendors and improve the user experience.

• Default semantics and limited customizability of new solutions as well as standardized semantics for SaaS clients for old and new applications will further reduce the total cost of ownership.

Architecture is about more than just technology. It involves culture, processes and philosophy, too – a holistic approach to the business of meeting our clients’ needs. Avaloq’s architects continue to actively seek to collaborate with clients, partners, and even competitors. We use and contribute to open-source software and support industry standards to facilitate collaboration. Given the choice, we prefer to use third-party software rather than build it ourselves.

We focus on providing a platform on which partners, clients and Avaloq can make an equal contribution towards building banking functionality. Each of our development teams has considerable autonomy, within our architectural framework, to create solutions that will provide agility and add value for our clients. We communicate frequently to ensure that we remain aligned with the needs of our community. And we have a solution-oriented mindset; we’re always thinking about operational practicalities, right from the earliest design stage, and we’ll always do what we can to avoid the need for customization.

We have already made significant progress in line with the plans we outlined in the 2017 architecture roadmap, and the pace of change is steadily accelerating. The primary aim of this document is therefore to confirm the major planks of our architecture strategy, to explain a few of the nuances and refinements that have emerged, and to provide concrete examples to demonstrate how the strategy plays out in practice. The focus of this document is on innovation. In our daily work, of course we put just as much emphasis on maintaining and further improving the strengths of the Avaloq Banking Suite (ABS), such as data quality, security and high STP rates. In all our activities, we respect the investments our clients have already made in customization and processes.

For brevity, we use the word ‘bank’ to mean any type of financial service provider. For SaaS and BPaaS clients, Avaloq service centres take care of certain aspects that are, according to this document, in the responsibility and/or decision of banks.

The later parts of this document are necessarily technical and are targeted at readers with a technical background. In Roadmap 24 you will find a less technical, high-level summary of the Avaloq architecture strategy.



Contents

Architecture evolution overview

Self-contained systems and microservices

Avaloq microservices in production

Deployment as Docker containers on Kubernetes

Event-based replication

REST as foundation of the ecosystem

Browser-based and mobile UIs for specific personas

Standardization and customization

High availability and system performance

Data

Application roadmaps

Public cloud

Required skills

Way forward

About

3

6

8

10

19

20

26

33

37

38

39

41

42

43

45



Architecture evolution overviewFigure 1 shows an overview of the architecture of the Avaloq Banking Suite, as it will be developed over the next few years. The focus of the architecture is on:

• modularization through self-contained systems and microservices, with the preservation of today’s high consistency (e.g. single UX design system), data quality (e.g. clarity of ownership for modification for each data element with event-based replication) and out-of-the-box integration;

• the cooperative ecosystem that gives Avaloq, client and third-party components equal access to a shared platform (PaaS), connected through rich banking APIs;

• persona-specific browser-based and mobile workplaces;

• simplified and standardized deployment on private and public clouds as containers and the option to consolidate all master data into a single database as separate schemas;

• efficient DevOps processes with continuous integration and delivery (CI/CD) pipelines, standardized monitoring dashboards and support for advanced application techniques, such as canary releases.

For reasons of simplicity, the architecture overview shown in Figure 1 omits certain aspects, such as the SmartClient, back-end system integration, and communication between self-contained systems. Please refer to the Roadmap 24 document for functional details of the different platforms.

Figure 1: Architecture overview

Avaloq Core Platform (ACP)

Deploym

ent Managem

ent

Developm

ent Tooling

Object M

odel

Security & Custom

ization

Other C

oncepts

Messaging, Replication & Read Caches

Business Logic

BusinessLogic A

BusinessLogic B

UI A UI B UIUI B

Workplace 1 – Persona X – Channel Y Workplace 2 – Persona R – Channel T

Framework / Chassis REST API

Business Logic

UI

Self-contained system(microservices)

Business Logic

Concept Tooling

Case Management

UI

Business Rules

UI

WildFly

UIs

Customizations & Ecosystem

UI

Channels

Interaction

Analytical

Transaction

Orchestration

…

Containerized Deployment on Private / Public Cloud

Busi

ness

Dom

ain

1

Busi

ness

Dom

ain

2

Busi

ness

Dom

ain

3

…



Figure 2 shows the planned evolution of the architecture of the Avaloq Banking Suite. The architectural approach will be consistent across both SaaS and on-premises offerings.

Figure 2: Evolution of the architecture of the Avaloq Banking Suite

In the rest of this document, we explain the thinking behind Avaloq’s commitment to self-contained systems and introduce two practical examples of the way in which we are using self-contained systems and microservices.

We also delve more deeply into various aspects of self-contained systems, describing what they are designed to deliver, providing concrete examples and listing recommended actions for clients and partners alike.

…

…

• New functionality implemented asmicroservices with complete REST APIs

• REST Open APIs for fintech integration of Avaloq Core (150 endpoints)

• Read cache technology based on business data events

• Over 30 microservices and ACP adapters on Kubernetes

• Rewrite of first existing ACP business logic asself-contained system (standalone wealth management) – existing implementation maintained

• Community APIs for ACP provide access to all data (including object model extensions) and functionality

• UX on Angular 8+ with Material Design• All components except Oracle DB on Kubernetes

• Fully componentized system• Completely independently scalable and

sellable• ACP (functionally reduced to position

keeping) will remain largely built in existing technology and made usable as a self-contained system.

Business Logic A

UI A

Workplace A

ACP

complete functionality is offered as self-contained systems

Business Logic Y

Workplace B

UI YUI X

Avaloq Core Platform(ACP)

AFP Services

BankletsForm /Report

Business Domain XBusiness Domain Y…

Web Banking FWP

BusinessLogic A

Workplace A

new functionality implemented as self contained systembu

sine

ssAP

Is

BankletsForm / Report

BusinessLogic A

UI A

BusinessLogic Y

UI Y

rewrite existing functionality as self-contained systemOld in maintenance mode

AFP Svc

Workplace AFWP Web Banking

Future20202019

Avaloq Core Platform(ACP)

Business Domain XBusiness Domain Y…

UI A

AFP Svc



Kubernetes container platform

Micro frontends (Mobile/Browser UIs)

Private & public cloud – or traditional deployment

Docker

Microservices

Caches

Service mesh

3rd-Party Systems / fintech

REST APIs / API Gateway / Web Application Firewall

Infra

stru

ctur

e

Master Data PersistenceAvaloq Core

…

Fron

tend

/Ac

cess

Docker

Adapters

Data streaming

▪ Material Design as design system▪ Persona-based workplaces based

on micro frontends▪ Angular as JavaScript framework▪ Native iOS and Android apps▪ REST APIs to connect frontends

and 3rd-party systems and UIs

▪ Istio for microservice orchestration▪ Spring Boot microservices▪ NoSQL for read caches▪ Oracle/PostgreSQL for master data▪ Kafka for data streaming to

decouple services at runtime▪ Docker containerisation of

microservices

Back

end

▪ Prometheus and Grafana for monitoring and alerting

▪ EFK for logging▪ Kubernetes / OpenShift▪ Private & public cloud; supporting

multi-cloud and managed services

Opt

iona

l se

nsiti

ve d

ata

sepa

ratio

nFigure 3 shows the key architecture aspects focusing on simplicity and standardization to enable collaboration.

Figure 4 provides an overview of the technology stack.

UX/UIBrowser-based and mobile UIs, Material Design,

intuitive user interfaces to generate seamless journeys for all personas

PlatformProvide platform to build banking solutions with short time to market

Act as the centre and catalyst of an ecosystem. Deploy on-premises or cloud.

Componentization and microservicesModularize into independently scalable systems on all tiers

Deploy and orchestrate in containerized infrastructure

APIs and integrationIntegration at any layer with any technology.

Enable developer community and ecosystem based on industry-standard technologies

SaaS/BPaaSEnhance SaaS and BPaaS capabilities of Avaloq products,

immediate setup and web-based configuration

Digital ecosystem and APIsEcosystem for rapid integration with leading fintechs, complimentary services and other ecosystems

Innovation & dataTokenization, blockchain, crypto assetsInsights through big data, BI, ML, analytics

Banking standardsStandardized and localized customization optimizing for simplicity and high STPUpgradeable product (not just starter kit)Includes third-party systems for output, regulatory reporting, AML, market connectivity, etc.

Agile processes & automationCombining agility with compliance for financial servicesHigh automation and standard design-time tooling

Figure 3: Efficient and trustworthy banking delivered through great user experience

Figure 4: Technology overview



Self-contained systems and microservicesWe are building our new and revised components as self-contained systems based on microservices, because of the many business benefits this architecture provides. Clients can adopt self-contained systems in a modular fashion, providing greater business agility. Self-contained systems, and the more fine-grained underlying microservices, can be upgraded individually to reduce risk and allow for independent release cycles, flexible deployment and almost unlimited technical and organizational scalability.

Figure 5: Target architecture with self-contained systems based on microservices

Each self-contained system handles a single business function, such as advisory or cost and fee simulations. Figure 5 shows the main aspects of a self-contained system:

• The business logic is built with Avaloq’s microservice chassis, can easily be customized and provides default semantics out of the box. The microservice provide REST and asynchronous message APIs.

• The microservices that make up the self-contained systems and auxiliary services (e.g. NGINX web server for static Banklet content) are deployed as Docker containers via Kubernetes onto a private or public cloud.

• Self-contained systems have their own persistence (e.g. schema in an Oracle or PostgreSQL database). To handle digital scenarios efficiently, we are building scalable low-latency read caches (e.g. in-memory DBs and NoSQL) where required.

• The Banklet (micro frontends) UIs for web and mobile sit on top of the REST APIs of the microservices. Each Banklet uses a dedicated experience API (combination of pruned data from multiple related Open API calls) served by a generic API gateway. This backend for frontend approach minimizes data transfers, server roundtrips, and coupling between channels. Depending upon the persona and the channel, Banklets are part of the self-contained system and combined into workplaces, such as Front Workplace, or built as part of an overall experience.

• The Open APIs of the self-contained systems can be consumed by fintech and bank applications.

Scalable Low-Latency Read Caches

Business Logic / Customizationwith REST and message APIs

Experience REST APIsGeneric gateway

Browser / mobile UIsDedicated per persona

Standard Cloud

Container PlatformPersistence

Fint

ech

&Ba

nk a

pps



Self-contained systems don’t rely on the Avaloq Core Platform (ACP) or on any other systems, and they also work in conjunction with third-party core-banking applications. All self-contained systems from Avaloq are fully pre-integrated, providing consistent user interfaces, semantics and operations. This gives our clients the benefits of modularity without the drawbacks of a best-of-breed approach or a collection of applications that another independent software vendor (ISV) has acquired and integrated superficially only. Self-contained systems communicate with other systems through asynchronous messaging and REST APIs.

A microservice is an application that implements narrowly focused functionality. Microservices are organized around business capabilities; they are not technical layers. They are tightly scoped (bounded context), loosely coupled applications that control all access to their data. Their sizes vary by business domain: Big enough that most use cases are within the scope of one or very few microservices; small enough to avoid the problems of a huge monolith. There is no prescribed size. That said, the scope of the ACP corresponds to a couple hundred microservices. Microservices extend modularity to runtime and the database, without making the later an implicit API. At Avaloq, we further standardize microservices for efficient development and operations as described below.

One or more microservices microservices (and some infrastructure components like containerized web servers) make up a self-contained system. The Avaloq Banking Suite is the set of all self-contained systems from Avaloq.

The broader ecosystem of Avaloq fintech partners, avaloq.one, extends Avaloq’s offering with third-party solutions.

The banks’ own solutions are also considered as part of the ecosystem here. Concepts apply at different levels:

• Standardization is at the highest sensible level to provide a consistent user experience and efficient operation. For example, Avaloq adopts Material Design for all its UIs (except iOS native) and has defined REST guidelines and standardized microservices through a chassis for the whole ABS. We recommend that the community also adopt these standards.

• Adoption by banks/sales is at the level of self-contained systems. In addition, some microservices are sold as add-ons.

• Updates (bug fixes, minor enhancements) are at the level of microservices. Major upgrades are at the level of self-contained systems.

• Technical deployment and horizontal scalability are at the level of microservices.

• Persistence (database schema, technical transactions) are at the level of microservices.

• Domain-driven design and bounded contexts are at the level of self-contained systems.

• Banklets are at the level of microservices. Workplaces out of the box mostly contain content from one self-contained system and are typically enriched with content from the whole ecosystem to build experiences.



Browser

Oracle Server

GBWMApplicationFrame

Orchestration& Resources

Web Application Firewall (WAF)

Banklet

AMI Web ServicesGoal Monitoring(Business logicmicroservice)

swissQuantAdapter

Schema Schema

GBWM Self-contained System

ACP

KubernetesCluster

ACP Adapter

Business event replication (over Kafka)

Synchronous Service to Service Communication (REST)

Goal Management (Business logicmicroservice)

Identity and AccessManagement (IAM)

Avaloq microservicesin productionExamples of microservice-based systems that are already live with Avaloq clients are Goal-based Wealth Management, Front Workplace Global Search, and PSD2 Berlin Group. These provide clear demonstrations of the benefits of containerization. We describe the first two here and PSD2 in the REST API section later in this document. One Avaloq client already runs 36 different Avaloq containers.

Figure 6: Goal-Based Wealth Management

Goal-based Wealth ManagementGoal-based Wealth Management (https://youtu.be/fABlDwmwhO8) went live at Thurgauer Kantonalbank in October 2018. With Goal-based Wealth Management, the adviser can focus on the client’s goals and at any moment knows the probability of achieving them. From the client’s point of view, the outcome is optimized to consider possible risks and ensure that the goals are highly likely to be satisfied.

Figure 6 shows the architecture of Goal-based Wealth Management,which follows our blueprint for self-contained systems. The main business functionality is implemented in two microservices, Goal Management and Goal Monitoring, both deployed as Docker containers – like all other components.

Each microservice has its own schema on an Oracle or PostgreSQL database. In the case of Oracle, the schemas can be on the ACP, the Avaloq Front Platform (AFP) or any other database to reduce the number of databases to operate. Additional microservices and containers are responsible for the UI and for the interface to swissQuant (or another quant service) and the ACP (or another core banking system). All the microservices involved communicate only via REST APIs and asynchronous messaging between themselves and other systems.

https://youtu.be/fABlDwmwhO8



Figure 7: Front Workplace Global Search

Front Workplace Global SearchFront Workplace Global Search went live at Raiffeisen in May 2018, providing the predictive person search functionality for a Google-style single field search in Front Workplace. We decided to implement this microservice-based solution (Figure 5) to achieve better search quality, scalability and response times compared to the PL/SQL-based solution that it replaced. The whole project, from the initial idea to production, took only three months, including development of the code and deployment of an OpenShift (Kubernetes) cluster at Raiffeisen.

Relevant person data is replicated by two microservices from the ACP via Kafka to Elasticsearch, an open-source full-text search engine and data store. Search requests from Front Workplace are sent to a microservice that queries Elasticsearch.

Multiple instances of each container can be started in Kubernetes, providing flexible scalability and high availability. Raiffeisen scales a single Kubernetes cluster across two data centres.

In Front Workplace Global Search, we implemented several best practices for migration to microservices and the associated upgrades. For example, we made it possible to switch between the old and new implementations at runtime – individually for each Front Workplace presentation server. This feature toggle allowed us to separate deployment from activation. We also have automatic fallback to the old implementation and a circuit breaker to avoid unnecessary calls to the new implementation if repeated failures occur. Thanks to the real-time metrics and dashboards implemented with Prometheus and Grafana, as well as complete logging, we know that no fallback has ever occurred in production.

Global Search is technically a group of microservices, rather than a self-contained system, since it wouldn’t make sense to use it by itself without the ACP. Such microservices as extensions of ACP and AFP already now provide our clients many benefits, such as standardized deployment and horizontal scalability.

With the next major upgrade of Front Workplace at Raiffeisen in 2020, the whole Front Workplace will be deployed as containers in Kubernetes, achieving further standardization with the associated benefits.

More self-contained systems and microservices are on the waySeveral other self-contained systems and groups of microservices, such as IFRS 9 impairment (expected credit loss), consolidation via PSD2 (multi-banking), and pain.001 are already being tested by various clients. Others, such as the new Avaloq Wealth Platform, are under active development. Please refer to the functional detail in Roadmap 24 for further examples.

Recommended actions for clients and partners• Ask your Avaloq key account manager for a presentation on

Avaloq’s microservice-based solutions.

UI L

ayer

Pres

Lay

erAP

PL L

ayer

Cor

e La

yer

Web Application Firewall

Optional Firewall

TaskServices

FWPGlobal Search

Services

Task Services

FWPGlobal Search

Services

Front Workplace UI

KubernetesZone

TASK_EXEC_WS FWP_OBJ_SRCH_WS BDEQUEUE

JBoss

Search and result UI

AvaloqCoreZone

ACP

http(s)http(s)

http(s)http(s)

Oracle Net Oracle Net

KubernetesIngress

Global SearchMicroservice

Elasticsearch

KafkaBDE FeederMicroservices

Kubernetes Cluster / Namespace

Oracle Net

http(s)

JBoss

AvaloqFrontZone



Deployment as Docker containers on KubernetesThe industry standard solution is to deploy microservices as Docker containers onto Kubernetes, to avoid the need to deploy, start and monitor hundreds of microservices manually.

For those who are not fully familiar with all the jargon associated with containers, here’s a quick explanation of the technical terms involved:

• A container image is a lightweight, standalone executable package of a piece of software that includes everything needed to run it, including all the dependent libraries. Avaloq uses Docker containers for Linux because this is the most widely used format.

• A container platform is a system to automatically deploy, scale and manage containerized applications. Avaloq uses Kubernetes as the container platform because it is the most widely adopted and most suitable option for our requirements. Kubernetes is an open-source project built on Google’s 15 years of experience of running production workloads, combined with best-of-breed ideas and practices from the community. Kubernetes, like many other container-related projects, is under the umbrella of the Cloud Native Computing Foundation (CNCF).

• There are many distributions of Kubernetes, just as there are for Linux. To improve efficiency, Avaloq has standardized on a single supported Kubernetes distribution. To select the best-suited distribution, we conducted a survey among Avaloq clients, issued an RFP among preselected providers of Kubernetes distributions together with Global Logic, performed in-house PoCs with all the finalists and deployed Kubernetes at various Avaloq clients. We selected Red Hat OpenShift as the single supported Kubernetes platform for running Avaloq applications. We avoid the dangers of vendor lock-in by abstaining from proprietary extensions and testing frequently against another Kubernetes distribution. The open-source versions (Kubernetes, OKD) are not viable options for production deployment because of the absence of enterprise integration (for networking and security), timely security fixes in released versions and consistent worldwide support.



Business benefitsOur decision to create microservices and containerize our software is based on the many business benefits this can provide for our clients, particularly in terms of efficiency gains and rapid innovation. Microservices and containers are interdependent, which is why they must be considered together, as a single strategy.

We aim to bring our clients the following business benefits, which are mostly based on the modularization and use of standard technologies:

• Shorter time to market, increased business agility, and lower risk are achieved with modular adoption of self-contained systems, smaller units of deployment requiring less regression testing and having a smaller impact in case of problems, shorter time to repair for the same reasons, same binary container in development, test, and production, canary releases for testing with a subset of users in production, and standardized deployment.

• More innovation is achieved with developers trying out new ideas and technologies in containers of the existing infrastructure (instead of ordering and waiting for new infrastructure) and the shorter time to market of innovation as described above.

• Higher organizational scalability is achieved with full modularization, faster on-boarding of new employees and externals thanks to standard technology, and higher employer attractiveness with modern technologies.

• Better performance, UX, and availability is achieved with easier horizontal scaling, the usage of the most suitable technology (including data stores and caches) for different use cases, and automatic scheduling by the container platform.

• Higher quality and lower impact of errors in production is achieved with the usage of proven open-source components, better modularization, and faster feedback cycles.

• Lower cost is achieved with faster onboarding of new employees and external based on standard technologies and modular understandability, more efficient development using industry-standard development methods, tools, and frameworks, standardized semantics, and lower run cost due to higher infrastructure utilization and standardized deployment and operations with software optimized for operability.

• Cloud readiness is achieved by using containerized deployment and following CNCF best practices.

The payoffs can be even greater when a bank decides that it will also deploy internal and third-party software as containers, allowing legacy processes and environments to be decommissioned. Of course, this bank-internal and third-party software can be deployed onto the same OpenShift cluster (separate worker nodes recommended for some cases) to maximize utilization/consolidation. The new approach must be followed through and implemented in full by Avaloq and its clients, if we are to collectively obtain all these benefits. For example, infrastructure must be treated as code, instead of being administered manually (lower cost of immutable infrastructure where VMs are replaced rather than fixed), and all applications must be written using container best practices.

Different clients of Avaloq are keen on adopting microservices for different reasons for different components. Achieving all client goals requires changes beyond architecture. For example, several clients are interested in faster time-to-market in the digital layer. This also requires the correct mindset, process, and test automation rather than just expecting microservices/containers to be a panacea. As a case in point, some banks deploy ACP customization and kernel changes daily or weekly with lead times of a few hours to a few days and no downtime or downtime of less than one hour, whereas other banks have only monthly or quarterly deployments to production.

On the other hand, microservices introduce the challenges of distributed systems and require change. We describe below how we handle these challenges.



Efficiency, regulatory compliance, and ISV modelSelecting self-contained systems/microservices as the architecture pattern and Kubernetes/OpenShift as the deployment platform is not enough to achieve the above goals. Additional standardization and capabilities are required to provide a solution that complies with regulatory requirements for banks, that can be developed and operated efficiently, and that works in an independent-software-vendor (ISV) model. Most presentations on microservices are from companies like Netflix, who operate their own software in a DevOps model. The fact that Avaloq also provides software to its clients to run on-premises adds further challenges: Different clients run different sets of microservices in different versions with different configurations, and the people who configure, deploy and operate the software are not the authors of the software. We address this in the platform and the microservices.

Platform extension and standardization

We add capabilities – preferably by selecting third-party open-source components – and standardize our Kubernetes platform in multiple dimensions. This is not unique to Avaloq; Kelsey Hightower, author of multiple books on Kubernetes, put it as follows: ‘Kubernetes is a platform for building platforms. It’s a better place to start; not the endgame.’ In this section, we list some of these capabilities and elements of standardization in the domains of cluster setup, application deployment, observability, and security.

We will provide a tool to verify that the OpenShift cluster has been configured according to Avaloq’s technical requirements, like we have provided a checker for the setup of the ACP Oracle database since 2012.

To address the selection of self-contained systems/microservices and the determination of compatible versions (based on semantic versioning of required and provided APIs) as well as required ACP stream solutions, we have built the Avaloq Constellator (Figure 8). The Constellator is integrated with the existing Delivery Tool. It can also be used to manage components provided by third parties and developed by banks without storing the meta data or the actual software in Avaloq repositories. The Constellator is a typical example of a tool that is required in an ISV setting only, which explains why we had to create it ourselves.

Figure 8: Screenshot of the Avaloq Constellator



Figure 9: Workflow of the Avaloq Installator

We use a standard Docker registry to provide containerized software to our clients. We suggest that they create a proxy repository.

We have created the Avaloq Installator to scaffold and validate the configuration, create standard Kubernetes configuration files, and generate the list of commands to apply to the cluster to bring it in line with the configuration (Figure 9). We recommend that the configuration be maintained in Git and that a Jenkins-based deployment pipeline with a GitOps workflow be adopted. We have built our own Installator instead of using Helm because Helm falls short of our requirements. Tiller in Helm v2 is a security problem in a regulated environment. Helm doesn’t provide support for the automatic restart of pods after ConfigMap changes and for canary releases. Helm doesn’t provide validation of configurations and doesn’t support multi-cluster deployments. We are however monitoring the development of Helm v3 and future releases.

Many microservices require a schema in a relational database (Oracle and PostgreSQL supported by Avaloq). To automate this process in a secure manner, we have created a Kubernetes operator. Avaloq’s database operator creates database schemas (or the DDL statements necessary to manually do so) for individual microservices from custom resources. This is another example of a functionality required in an ISV setting.

For observability, we rely on open-source solutions. We use the Elasticsearch-Fluentd-Kibana (EFK) stack for centralized logging and Prometheus (open-source time series database) and Grafana (open-source software for time series analytics) for monitoring. We have standardized the usage (e.g. JSON as log format and consistent metrics), created a Kubernetes operator for the deployment of Grafana dashboards, and provide Grafana dashboards for all microservices.

We will further enhance observability with and overview service and distributed tracing based on Istio. We will also use Istio to secure network connections (mTLS), to provide circuit breakers (replacing language-specific solutions like Hystrix in the Front Workplace Global Search) and other traffic control, and to intelligently route traffic for canary releases.

We are waiting with the introduction of Istio until we can do so in a secure manner. On OpenShift 3.11, Istio requires pods to run with a user with elevated privileges, which is not acceptable for banks. OpenShift 4.x still requires an internet connection for installation, which isn’t acceptable from a security perspective either. We will introduce a secure deployment of Istio on OpenShift 3.11 in Q4 2019 and switch to OpenShift 4.x in 2020 when the latter supports disconnected install.

Security is a paramount requirement in everything we do. Therefore, we scan container images for security vulnerabilities, sign them, work with closed network policies (default: deny any connection between any two pods), and perform runtime scanning in our service centres.

We will introduce better support for the protection of secrets (likely https://www.vaultproject.io) and a central auditing service in 2020.

To optimize supportability, Avaloq provides actual Docker container images that all clients run without modification (except for static UI content as described below). Configuration is performed using Kubernetes standards such as ConfigMaps and Secrets, which is more efficient than allowing clients to build their own container images based on Avaloq-provided software, images or Dockerfiles.

Because Avaloq delivers the container images, we take responsibility for deciding which specific configuration parameters should be exposed to clients and for setting the correct values for hundreds of JVM and other parameters. Delivering complete container images means that Avaloq will make new versions available whenever security fixes are needed in the underlying Docker images (e.g. JVM), as we have done in the past for embedded third-party software such as AngularJS. The main burden of the work and responsibility is borne by Avaloq, making operation and support even easier for on-premises clients.

We recommend that clients also use Avaloq’s patterns for operating their own containerized solutions on the Avaloq cluster.

• Fetches YAML templates

• Scaffolds configuration directory structure

• Pre-generates requiredparameters

• Generates documentation

• The user provides all thenecessary configuration

• The configuration is checked in and versioned

• Validates the configuration

• Processes YAML templates

• Creates Kubernetescompatible YAML configuration files

• Informs the user about the difference between the target configuration and the live version

• Creates list of kubectlcommands to bring the cluster into the target state and optionally applies them

fetch configure deployProvide values



Microservice chassis

We have created a microservice chassis to allow our developers to focus on the business logic. This results in standardized microservices that can be operated efficiently and effectively. Our chassis defines general architecture patterns and solutions for typical banking problems (the types of problems we solve in the ACP with process queues, ATRX, classifications, etc.). Furthermore, the chassis provides templates, guidelines and best practices for elements such as the development environment, technology stack, persistence, security, configuration, logging and much more.

Our chassis is based on Spring Boot and the microservices are designed to be deployed as Docker containers on Kubernetes. We expect that GraalVM native images will significantly reduce the RAM requirements of Spring Boot over the next 18 months. Our chassis is mostly a selection of open-source libraries and configuration options, avoiding any attempts to reinvent the wheel. For logging, for example, we use SLF4J as façade, JSON as the format and standard out as the location and we define a consistent minimum set of information that must be logged. We have not created our own proprietary logging library.

The benefits of microservices listed above come at the price of the complexity of distributed systems. Many of these challenges are addressed by the container platform. In addition, there are two key challenges that we address with our chassis. First, a banking/ERP environment has high requirements on data consistency, which in a monolith is solved to a large degree by a single database transaction across multiple business domains stored in the same relational database. With microservices, we solve this with sagas and other asynchronous processing patterns that we have successfully used

in the existing core (e.g. process queues, messaging, ATRX-based update). Second, microservices require loose coupling with backward-compatible interfaces to prevent a distributed monolith where the update of a single microservice requires many other microservices to be updated.

All our existing microservices, including Goal-based Wealth Management and Front Workplace Global Search, are based on this chassis. We are continuously evolving the chassis and updating our existing microservices. To avoid organizational reliance on a framework team and reduce coupling, we decided to create a chassis with few proprietary Avaloq libraries, rather than with many libraries and frameworks that every microservice must use. We plan to open source parts of our chassis in 2020 so that clients and partners alike can use it and contribute to it. We have found that Chris Richardson in his book Microservice Patterns: With examples in Java (Manning, 2019) takes very similar approaches to most challenges.

We are also monitoring the development of serverless computing (aka function as a service and lambda) such as Knative and will use this approach, when mature, where beneficial in the future. Because most Avaloq applications have a base load and run on infrastructure (private cloud) where scale down to zero has no cost benefit, and because tail latency of serverless is a problem in many Avaloq use cases, there is no urgency to rush and introduce further complexity. Likewise, we are careful with permitting other programming languages and frameworks such as Python (used only in our analytics platform), Node.js and Go (both not permitted in Avaloq production code) because we need to master our tools, ensure 24x7 support for most solutions with a limited number of people on call, and maintain a coherent culture.



Avaloq components provided as containersAvaloq adopts a containerized deployment model for most of its software components (e.g. microservices, adapters, infrastructure components like centralized logging), and creates new containerized software components. The following table provides an overview of new components delivered as containers:

Component Minimum ACP release

Availability

Goal-based Wealth Management

4.2 Now

Front Workplace Global Search

4.3 Now

REST Open APIs with read cache

4.5 Now

PSD2 Berlin Group 4.5 Now

Multi-banking (con-solidation based on PSD2)

4.8 Now

IFRS.9 impairment 4.8 Now

SEPA LSV (pain.008)

4.8 Now

SEPA Payment initi-ation (pain.001)

4.8 Now

FinTS (German standard)

4.8 Now

Community APIs 4.8 Q1 2020

Major new function-ality (e.g. standalone Wealth Platform, standalone Crypto Platform)

4.8+ Continuously

The first version of our crypto trading solution coupled to the ACP is in production. The above-mentioned Crypto Platform is our next-generation self-contained system for crypto trading, tokenization with blockchain, and sidechain handling. Please refer to our Roadmap 24 for details.

We do a stepwise migration of existing components to containers to minimize the risk and satisfy client schedule requests. Existing products will require Kubernetes as follows:

Applications Minimum ACP Release

Date

ACP adapters 4.8 – 4.10 April 2019 – 20

Front Workplace 4.8 Q1 2020

Web Banking (see below for detailed roadmap)

4.8 H2 2020

Other AFP modules 2020

As of the above dates, new releases of the named applications will only be supported on top of Kubernetes. The ACP adapters are an exception to this rule: ACP adapters, such as JMS Adapter and FIXBridge, are supported both on Kubernetes and with traditional deployment on ACP 4.8 – 4.10. This allows clients ready for containerization to standardize and give other ACP-only clients more time to deploy the container platform. Furthermore, clients can stay on older releases without Kubernetes within the limits defined in the maintenance contract.

The following components are excluded from containerization:

• Components running on Microsoft Windows. Kubernetes/OpenShift also supports containers on Microsoft Windows. Nevertheless, Avaloq will only containerize server components deployed on Windows (e.g. IntegrationServer, SOFiE adapter) if there is significant demand to do so.

• Oracle database. Whereas the Oracle database can run in Kubernetes, the database proper still requires a large block storage, and the disadvantages of a containerized deployment currently outweigh the advantages for most use cases.

• MQBridge. Because most Avaloq clients deploy MQBridge on AIX and Solaris SPARC, which are not supported by Kubernetes, and because XA 2PC requires deployment on the same server as IBM MQ, we don’t support MQBridge on Kubernetes.



Figure 10: Containerization overview

Avaloq is encouraging all our partners to provide their software as containers for deployment on Kubernetes. For example, Airlock IAM is available as Docker container and Avaloq CCM powered by Assentis will soon be available for Kubernetes.

Figure 10 provides an overview of the steps towards containerization. In addition to the code and deployment changes, both clients and Avaloq need to implement integrations and adapt processes. For example, Avaloq is adapting its CI/CD pipeline, dependency management, Delivery Tool, and security assurance, updating its documentation, and widening its consulting offering. On-premises clients need to integrate OpenShift into their network, storage, automation and monitoring, build up the skills in their run organization, and optionally move their own and third-party solutions to containers.

Avaloq experience with KubernetesInternally, Avaloq has been managing several Kubernetes clusters and Docker registries since 2016. These are now available to all Avaloq developers wishing to build containerized solutions. ADAI has been enhanced to install containerized solutions, and we have held readers’ circles and other training for staff. We have already deployed our OpenShift-based container platform in our SaaS/BPaaS service centres, at several on-premises clients, and in three public clouds for the developer sandbox.

During the Raiffeisen, Thurgauer Kantonalbank, ASSL, and apoBank deployments, we learned a lot about what it means to deploy a Kubernetes cluster on a bank’s infrastructure. We learned, for example, how to integrate into a bank’s network, use the existing Microsoft Active Directory for authentication and authorization, define back-up and recovery, size the environment, handle security and work with requirements such as certain agents running on each VM. We provide these lessons learned to our community in various formats, such as the ACPR documentation at https://docs.avaloq.com/acpr/.

ACPOracle

PL/SQLDSLs

Linux

ACP

Adap

ters

JBoss

AFP

Kubernetes

Mic

rose

rvic

es

UNIX / Linux Linux(infrastructure as code)

ACP Adapters

Kubernetes

AFP(modular)

Micro-services

Base

d on

M

S ch

assi

s

Linux(infrastructure as code)

ACP Adapters

Kubernetes

Microservices

UNIX / Linux

ACPOracle

PL/SQLDSLs

2019 Future2020

ACP(Oracle, PL/SQL, DSLs)

ACP

Adap

ters

https://docs.avaloq.com/acpr/



Client implementationAvaloq provides the full container infrastructure for its BPaaS and SaaS service centre clients. Clients with on-premises deployments of Avaloq software need to install the Red Hat OpenShift cluster when they upgrade to ACP Release 5.1, AFP 2020 releases (see above for details) or when they deploy a new containerized add-on module. Typically, clients will want to set up three clusters as shown in Figure 11.

To facilitate deployment, Avaloq, together with its partners, provides a full reference implementation, complete with scripted infrastructure setup on AWS and on vSphere, documentation, and consulting services (Figure 12).

Figure 11: Separate clusters, projects, and worker nodes for optimal consolidation and segregation

Clients don’t need to adapt their business customization (e.g. workflow, CSS) as part of the containerization of existing functionality with AFP and ACP Release 5.1. The only change required is for the deployment mechanism to be adapted for newly containerized components.

Figure 12: Container reference platform

Cont Cont

Namespace/Project: Multiple virtual clusters in one single physical cluster.

PROD DB

UAT DB

PROD

Workers Prod

Workers Pre Prod

Cont Cont

EDU

Cont Cont

UAT

Kubernetes(CID)

Cont ContPerf DB

Performance Tests

Workers Performance

Workers Default

Cont Cont

Test 1 .. n

Cont Cont

Dev 1 .. n

Kubernetes(anon)

Cont ContTest

Test

Workers Default

Kubernetes(Infrastructure)

Test DBs

Dev DBs

ADAI

Cluster for all deployments with anonymized/ synthetic data

Cluster for all deployments with customeridentifing data

Cluster totest infrastructure changes

EDU DB

Development• Guidelines• Libraries

Build & Deployment• CI/CD Pipeline (for own containers)• Tooling• Dependency Management

Security• Security Best Practices• Hardening

Infrastructure• Sizing & Clustering• Hardware & Virtualization

Operations & Automation• Setup & Upgrades• Monitoring & Logging• System Integration• Images Management

Customization• Guidelines• Identity & Access

Management Container Platform

CCoonnttaaiinneerr PPllaattffoorrmm

Container Platform



Recommended actions for clients and partners• Plan the introduction of OpenShift and training for all functions at

an early stage and engage an experienced Kubernetes consultant who knows the Avaloq specifics. Invest in the change and benefit from the savings that will follow in the run. The savings will be greatest if the new approach is followed completely, with infrastructure being treated as code, for example, rather than being administered manually.

• Contact your Avaloq key account manager for licensing of Red Hat OpenShift. Avaloq acts as an embedded reseller for Red Hat OpenShift.

• If you purchase hardware for OpenShift, we recommend that you add more RAM per CPU core than in the past for in-memory databases and Java-based microservices.

• Consider repackaging your own middle-tier functionality as Docker containers with Kubernetes configuration files to get the benefits of a single, consistent deployment.

• Ask third-party suppliers to provide their software as Docker container images with Kubernetes deployment descriptors.



Event-based replicationDistributed and containerized applications bring many benefits, but also new challenges. Components will often need to access functionality provided by another component or data for which another component is the master. We use asynchronous replication and synchronous REST APIs to achieve this. Replication provides better performance and looser coupling, which in turn means higher availability. On the other hand, REST APIs are simpler.

For replication, we use the event-carried state transfer pattern. Whenever a system of record changes data that other systems may be interested in (e.g. person data for the ACP and goals for Goal-based Wealth Management), it emits an event. The event is distributed via Apache Kafka, an open-source component that provides a unified, high-throughput, low-latency platform for handling real-time data feeds. Other components, such as microservices, dedicated read caches and the ACP, can act on these events and locally build up their representations of the data they are concerned with in the formats that are most suitable for them.

We call our events ‘business data events’ (BDE). They contain the complete new state of the changed entity, rather than just a delta or change notification as with event sourcing. To avoid a slowdown of transactions that make modifications, BDEs are constructed asynchronously with a typical latency of less than 50 ms. We encode BDEs as Google protocol buffer because of their efficiency and backward compatibility.

We have configured Kafka to retain the last message per key (e.g. ACP person ID) forever (log compaction without time-based deletion), which would not be possible with event sourcing and which is not supported by a message broker like IBM MQ and ActiveMQ. This enables new consumers to get the complete state, and existing consumers to rebuild the state. It even allows some consumers to keep only an in-memory representation and to fetch all data from Kafka at startup. In the Avaloq setup, all systems of record (ACP and self-contained systems) can resend all events, and all consumers can refresh from Kafka. In this way, we can also support reconciliation. Nevertheless, we make Kafka highly available in the container platform and require it to be properly backed up to reduce downtime. We require the Red Hat AMQ distribution of Kafka and also use the included supported version of Apache ActiveMQ Artemis (based on HornetQ, not to be confused with the original ActiveMQ) as message broker for other integrations.

The event format and the event bus are private to Avaloq to allow format changes without following external de-release processes. We will let clients and partners access events once the format and change processes are stable. For the time being, clients and partners can only access the replicated state through APIs of the various Avaloq components. Clients who want their own replication may continue to use the document logger as an implementation base.

Replication itself brings many challenges, such as update latency and consistency (within appropriate partitions), and imposes additional requirements in terms of information lifecycle management, anonymization and cloning. Avaloq provides solutions for these requirements. For example, we will introduce a data classification for sensitive data. We explicitly define the guaranteed consistency (e.g. bookings within a business partner at any given point in time and read after write for a single API) and where we have opted for performance and robustness over global consistency. Asynchronous replication is not new to the Avaloq Banking Suite, as pillars, order pools, AFP Web Banking and Sensitive Data Separation (SDS) have used similar forms of replication for years, and we are building the new solution based on the lessons learned in these implementations. Likewise, Avaloq is familiar with eventual consistency from person – business partner propagation and pillars. And Avaloq has used domain-driven design with derived classifications per business domain in the ACP since 2002. Event-based replication will eventually replace some of the older replication mechanisms, such as Web Banking and SDS replication.

Goal-based Wealth Management, Front Workplace Global Search, as well as our Open and Community APIs use events to replicate states among microservices and between the ACP and microservices.

BDEs are also used by Avaloq for event notification with consumers that accept that they may not receive all intermediate states if an item is modified multiple times.



REST as foundation of the ecosystem

REST with JSON payload is the de facto standard for synchronous communication among microservices and for providing data to mobile and browser-based UIs. With callbacks and fire-and-forget, REST can even be used for asynchronous communication. REST is replacing CORBA, SOAP and other RPC mechanisms.

REST is the current focus of the industry and Avaloq. Avaloq has provided out-of-the-box REST APIs for all its new self-contained systems and for existing ACP functionality and data since 2018.

All Avaloq REST APIs have the following features in common:

• OpenAPI 3 specification. OpenAPI 3 (the successor to Swagger) has become the de facto standard for describing REST APIs. Avaloq provides an OpenAPI 3 specification for all its REST APIs.

• System performance. Avaloq APIs are built on state-of-the-art read caches to provide great response times, cost-effective scalability, and high availability for read where appropriate.

• No Avaloq Script. There is no need for clients to write any Avaloq Script.

• Developed and maintained by Avaloq. Avaloq APIs are developed and maintained by Avaloq.

• Operated by the bank/Avaloq service centre. The actual API ‘runs’ at the bank, or the Avaloq service centre.

• Managed lifecycle. Like all other Avaloq products, Avaloq APIs have a managed lifecycle with long-term backwards compatibility. Many components support multiple versions of the same API to support a smooth transition.

Open and Community APIs for the ACPAvaloq provides two sets of REST APIs for the ACP:

• Open APIs are targeted at fintechs. Their specification and content are standardized across all Avaloq banks and in line with general industry standards such as BIAN. This allows fintechs to integrate once and deploy against any Avaloq bank. This ensures a thriving ecosystem, which benefits banks by giving them many pre-integrated fintech solutions. Open APIs include industry standard REST APIs like PSD2 Berlin Group and Avaloq-defined APIs like robo advisory.

• Community APIs are targeted at banks and their implementation partners. Unlike Open APIs, they make all client extensions, such as additions, classifications and relations, available to the consumer of the API. This is frequently required for bank-internal integration but wouldn’t work as a basis for the ecosystem because the API looks different at each Avaloq bank. That is, each API, such as person, has a common part that is identical at all banks and a clearly separated extension part that is different based on the object model extensions.

The following table provides a comparison of Open APIs and Community APIs as well as APIs developed by the bank using the AMI Web Services (AMI WS) framework.



Benefit Open APIs Community APIs Self-developed with AMI WS

API provider (actual runtime)

Banks Banks Banks

API consumer Fintechs (and banks, if it suits their needs)

Banks (and their implementation partners)

Banks for special purposes

Integration Same API at all Avaloq banks. Integrate once, deploy to whole community.

Bank-specific because most APIs contain extensions generated from the bank’s customization

n/a if developed by bank and deployed only there, depends on definition if developed by partner

Access to all client data model extensions (e.g. classifications and keys)

No Yes Depends upon definition

Terminology BIAN or other external standard (e.g. account)

Avaloq (DDIC), e.g. BP Depends upon definition

Modelling BIAN or other external standard Avaloq enterprise-wide object model (EWOM)

Depends upon definition

API specification in OpenAPI 3 Yes Yes Yes (or RAML)

Fast and scalable at low cost as well as highly available thanks to read caches

Yes (most) Yes (most) No

API developed by Avaloq Yes Yes No

Mapping to model extensions in customization required (e.g. SWIFT)

In some cases, e.g. avq.intf.swift.secevt2 cont_classif_us_tax_wtax

No Depends upon definition

Knowledge required by API consumer

Banking, external standard Banking, Avaloq model Depends upon definition

Knowledge required by API provider (bank)

Banking, own model extensions for mapping

None (optional Avaloq model for shapes and default workflow actions for write)

Banking, Avaloq Script

Full flexibility in definition for the client

No (fully defined by Avaloq) No (defined by Avaloq except for model extensions)

Yes

Mode Read and write Read and write Depends upon definition

Shapes for retrieving only select attributes

Some Most Usually not

Optional references (HATEOAS) No Yes Usually not

Paging No Yes Usually not

Optionally included referenced items

No Yes Usually not

Coverage Select functionality Objects, orders (except static data, which are covered through objects), bookings, code tables, pillars, messages, file metadata, reports with limited caching

Specific functionality

Definition Dedicated handwritten Kernel Community APIs largely derived from DDIC to provide large coverage. Some complex APIs handwritten.

Mostly handwritten



Benefit Open APIs Community APIs Self-developed with AMI WS

Consistency Eventual, additional guarantees for select APIs (e.g. bookings per BP)

Eventual, read-after-write Depending upon access items

Lifecycle De-release announcement at least 2 years before de-release

De-release announcement at least 2 years before de-release

n/a

Requires Kubernetes container platform

Yes Yes With ACP 5.1

Availability ACP Release 4.5 and newer ACP Release 4.8 and newer (Q1 2020)

ACP Release 4.1 and newer

The OpenAPI 3 specifications for Avaloq’s Open APIs are available at https://avaloq.one. avaloq.one is a documentation hub and development-time ‘matchmaker’ between banks and fintechs but isn’t involved at runtime; API calls from fintechs go directly to the banks. All APIs, including Open APIs, ‘run’ at the bank. The Community APIs are specific to each customization; they are available on avaloq.one sandboxes.

Community APIs support GET of single items and lists with filtering based on attribute values. Most Community and some Open APIs support shapes to retrieve only a subset of the attributes (horizontal pruning). For example, a client may only be interested in the name and ISIN key of an asset rather than in all 891 attributes. With shapes, the client can specify this and, thereby, greatly improve performance (response time, amount of data transferred). Figure 13 shows the result of a sample Community API GET with shapes and other features.

Figure 13: Result of sample Community API GET

Optional shapes (predefined or directly specified, returning only required fields)

Optional references(for exploration/HATEOAS)

References by intl_id and keys

All extensions are available

All sub-listsare part of the entity

Familiar DDIC names in standard CamelCase

Single item specified by ID or lists including filtering and paging with limit and offset

https://avaloq.one



We have documented our best practices for REST APIs on https://docs.avaloq.com. Our best practices consist of a selection of industry standard best practices, augmented with instructions for handling Avaloq-specific constructs such as objects and orders. We recommend that clients and partners also follow these conventions.

REST APIs are not per se superior to APIs implemented with other technologies/architecture styles. It is important to define them correctly so that loose coupling, e.g. upgrading the API producer without the consumer or vice versa, is possible, so that multiple versions of the same API can be deployed. Avaloq’s APIs and our REST API documentation address these aspects.

New APIs developed after 2019 will be provided for ACP Release 4.8 and newer only.

It is possible for banks to use Open and Community APIs in the same application. However, this requires the client to deal with different terminologies.

The distinction between Open APIs and Community APIs only exists for ACP APIs. For microservices, which are based on domain-driven design with a bounded context, we only provide Open APIs. These Open APIs also include the object-model extensions of our clients; however, extensions are rarely needed in self-contained systems because of the richer object model standard provided by Avaloq.

Open APIs

Some Open APIs are only applicable for certain types of banks or geographies. For example, PSD2 Berlin Group is only relevant for parts of the European Economic Area.

Open APIs are fully standardized for the API consumer. On the other hand, they may require a mapping in the ACP, like SWIFT and FIX, if a functionality is not standardized in the kernel. Hence, what can be provided as an Open API depends upon the business domain rather than the split of functionality between kernel and customization in the ACP.

Avaloq Open APIs fully model the domain, instead of exposing generic lists of classifications, additions and keys. For example, we have a fully modelled creditor object in the API with attributes ‘ID’ and ‘VAT number’, rather than a generic ACP representation of a business partner (‘BP’) with the classification ‘credr’ and two keys, ‘symbol’ and ‘VAT identification number’. We have designed our Open APIs with an intent instead of providing generic CRUD APIs for the underlying object model.

Edition Community APIs

The Avaloq banking standards (ABR/S masters) provide additional Edition Community APIs based on the respective customization. Edition Community APIs belong to the respective functionality. Hence, some Edition Community APIs are present in multiple editions. Edition Community APIs are only available to clients who use the corresponding, upgradeable customizations.

https://docs.avaloq.com



Read caches for the ACPDigitalization leads to many more read requests via APIs. To ensure fast response times, cost-effective scaling and high availability, read requests for most Avaloq Open and Community APIs are served by dedicated caches.

Figure 14 shows the overall architecture of ACP Open and Community APIs with read caches. We separate write and read by implementing the command-query-responsibility-segregation pattern (CQRS). Writes go to the ACP via AMI Web Services and to the cache of the respective API for read-after-write consistency. Reads are served from read caches. The state is replicated through Kafka using events, as explained above. Read caches (typically individual microservices per API) are just additional consumers of business data events. For example, when a person is changed, the ACP emits a person event. Both the Front Workplace Global Search and the read cache of the party data Open API read this event from Kafka.

For items for which the ACP is the master data visibility security is replicated from the ACP to a dedicated security cache. The query APIs use this cache to guarantee the same data security as Oracle RLS in the ACP without redundant customization.

Special logic ensures the explicitly specified consistency. Read caches are only available for Open and Community APIs provided by Avaloq, but not for custom APIs built with AMI Web Services.

To keep the sizes of the caches reasonable, we only cache current

items (e.g. orders, bookings, pillars, message meta data) and don’t cache certain large items (e.g. full message texts).

For selected functionality, Avaloq will also provide write-back caches.

Figure 14: CQRS, event-based replication and read caches

Web Application Firewall (WAF)

Event Bus (Kafka)

API 1

In-MemoryIn-

MemoryIn-Memory

DocumentDocument

Command(Write, reads for not replicated data)

Transform Transform

AMI WS

Meteor

ACP(Business logic)

Security CacheSecurity

Cache

API 2

Query (Read, cache invalidation/update)



Core SystemAuthorisationPayment Consent

Kubernetes Cluster

Kafka

NextGenPSD2 Service (BG)Confirmation of

FundsPayment Initiation

Account Information

Account Information Service

TransactionAccount Balance

Consent Management Service

Consent Authorisation

AMI Webservice

Security Policy Service

REST Call (Microservce) REST Endpoint (RAML, OpenAPI3) Asynchronous Event (BDE)

Security• Authorisation of PSU and

TPP ensured by IAM• IAM generate JWT token• Communication between services

via HTTPS (Istio)

• Reuse of existing services• Ensure data security by access

keys as in core system• Export data (account, bookings,

payments) via Kafka & make it available for services (async)

Core• Payment core component

re-used. • Write access via AMI Web

Service (synchronous)

• Persistence of consent data in core system

TPP Access (Rest API) PSU Access (GUI+Rest API)

WAF IAM

SecurityIdentity propagation (authentication) is performed according to industry standards with JWT tokens, which may originate from OAuth2. For PSD2 Berlin Group and UK Open Banking, we have already implemented fine-grained consent handling so that the banking client can decide who is able to see an account and what can be done with the information (Figure 15).

API gatewaysAvaloq focuses on providing good banking APIs and leaves standard API gateway functionality, such as throttling, to specialized third-party products. As stated above, we integrate Istio/Envoy into our container platform as service mesh/API gateway sidecars. We require a Web Application Firewall (WAF) to ensure that only requests with valid API keys/authenticated sessions reach the container platform.

We are considering support for an open-source GraphQL gateway (likely https://www.apollographql.com) on top of our Open and Community APIs.

Clients may deploy an API management platform like Mulesoft or Apigee for documentation, as an additional gateway for their own and third-party clients (not Avaloq clients), and for other management functionality.

Other integration typesThe current industry focus is on REST APIs. However, Avaloq continues to support many other integration types, such as asynchronous messaging via AMI, file export and import, table APIs such as custom pillars and the migration API, and Web Banking SOAP APIs. We generally recommend asynchronous APIs for looser coupling, i.e. if one system is not available or overloaded. We generally recommend file, table, and up to a certain size asynchronous message interfaces for bulk data. We are considering gRPC for internal communication, but not as an API for clients and partners.

Avaloq has always provided Avaloq Script APIs (DDICs), implementations of industry standards, such as SWIFT and FIX as well as toolkits, such as AMI and AMI Web Services, for clients to build their own interfaces. We will continue to support these.

Recommended actions for clients and partners• Use Avaloq’s Open APIs and Community APIs for the integration of

third-party and proprietary bank solutions. Minimize the creation of custom APIs with AMI Web Services to reduce maintenance issues, risks and performance problems. Contact Avaloq to request additional Open and Community APIs, if necessary.

• Actively participate in the API user groups and share your API requirements with Avaloq.

Figure 15: PSD2 architecture overview

https://www.apollographql.com



Browser-based and mobile UIs for specific personasPersona-based UIs, user journeys and design-driven development are becoming increasingly important, as described in Roadmap 24.

Different personas have different requirements. For example, banking clients expect a simple ‘quick-to-learn’ experience in Web Banking, while bank employees want a ‘quick-to-use’ and feature-rich UX in Front Workplace. Avaloq’s unified UI framework for browser-based applications can be used to build both types of UX. Avaloq prefers persona- and device-specific Banklets (business UI components) even though reuse across UIs is technically possible.

For the desktop, we prefer browser-based HTML5 UIs to native clients because browser-based UIs require no local deployment, support immediate upgrades, and enable simple UI integration of content from multiple sources. SmartClient will be retained for the time being, especially for the back-office operations of existing clients.

Upgraded browser UX based on Material Design and Angular 8+We are in the midst of a major overhaul of all our browser-based UIs, which we will complete by mid-2020. The trigger for this overhaul is the end of the support for AngularJS, Google’s web framework that we use as basis for our current browser-based UIs, in June 2021. Existing AngularJS-based widgets (e.g. drop-down list with search, table with in-place editing, etc.) don’t work with Angular. Hence, the migration of Avaloq’s UI content (e.g. payment Banklet, Front Workplace frame) from AngularJS to Angular requires an upgrade of our Front Development Kit (UI components, Banklet architecture, etc.) and all browser-based UIs. We use this upgrade to bring additional benefits to our clients while focusing on a smooth upgrade.

Together with clients, we set the following goals:

1. Best possible UX, including system performance, ease of adoption, efficient usage, attractiveness, suitability for mobile browsers, and accessibility.

2. Short time-to-market for future innovation and security fixes.

3. Organizational scalability with sourcing options for the whole community and support for the fintech ecosystem thanks to standard open-source components.

4. Security and compliance.

5. Low run and future upgrade cost.

6. Feasibility for the whole community based on timeline (complete production rollout before the end of support of AngularJS), project cost, and available skills.

We explicitly prioritize the above over runtime composability, flexibility in styling, and local optimizations. That is, while there is value in these items, we value the goals more.

The chosen solution consists of the following elements, which are described in detail below:

• Design system: Material Design

• Web framework: Angular

• UI components and styling: Angular Material with theming augmented by third-party and own widgets

• Banklets: Micro frontends with standardized APIs

• Application: Choice between single Angular application and Web Components

• Application frame: Choice between SPA in plain HTML and a portal

• Runtime orchestration: Defaults from Avaloq with selective override by clients

• Configuration and localization: Declarative with design-time validation

• Security: No iFrames for trusted content; third-party content optionally in iFrames

• Migration: Big bang per application



Design system: Material Design

A design system is a collection of rules, constraints and principles that define a UI and the behaviour/interaction patterns (aka UX). For example, a design system defines navigation, how it can be triggered, and how it is animated. The main goals of a design system are to optimize usability through consistency and quality and to make the design and development processes efficient.

We have chosen Material Design (https://material.io) because it is the most mature and most widely used design system. Most users can work efficiently with UIs based on Material Design because they are already familiar with it from Google applications, such as Gmail, Search, and Android. Furthermore, most design agencies know Material Design. Several banks and ERP companies have already proven that great UX with good differentiation/branding can be built with Material Design.

Web framework: Angular

A web framework is a software framework that provides a standard way to build and deploy web applications. A web framework provides solutions for common requirements, such as model-view separation, server interaction and data binding, modularization, and internationalization.

We have chosen Angular (https://angular.io) because it is well suited for banking applications (lots of data, enterprise capabilities such as well-defined support), provides great performance, has a large ecosystem, and is known by millions of developers. Furthermore, it provides the smoothest transition from the current AngularJS.

Angular provides a mostly backward-compatible major release every 6 months (https://angular.io/guide/releases). Major releases are supported for 18 months. Avaloq generally rolls out new software on the latest Angular major release available 1 month before the rollout of the Avaloq release. To avoid disruption, we don’t change the Angular major release on fix packs of Avaloq components. This results in an active support for 12–17 months for browser-based Avaloq UI versions. Angular simplifies and automates the update between major versions with tools and documentation (https://update.angular.io).

Angular itself and most Angular documentation uses TypeScript, which improves quality and productivity with static typing. Hence, Avaloq is switching from JavaScript to TypeScript. Clients and partners may continue to use JavaScript or switch to TypeScript because the two languages are fully interoperable.

UI components and styling: Angular Material with theming augmented by third-party and own widgets

A UI component library provides reusable UI components (aka widgets) for developers. These UI components include input elements such as date pickers and drop-down lists, navigation elements like buttons and menus, and layout elements like tables and expansion panels. Furthermore, a UI component library may define a styling API.

We have chosen Angular Material (https://material.angular.io) because it provides components that comply with Material Design, it is backed and supported by the Angular core team, is well documented, and is very fast and consistent. Angular Material, like any other UI component library, doesn’t provide all the components that are required for banking applications. For example, there is no drop-down list with search, no date picker that accepts date expressions like ‘eom’ (for end of month), and no table that has all the functionality of the tables in the current AFP-JS. Therefore, we will in addition use third-party components that comply with Material Design and Angular Material and build our own, if necessary. Of course, we will make our own components available to our clients and partners as we have done in the past with AFP-JS.

Angular Material provides a managed API for styling called themes. This ensures that the styling of our clients continues to work after an upgrade. This is a major improvement over the current styling approach, with some styling as part of the styling scaffold and other styling directly with CSS selectors requiring significant rework with each application upgrade. The backward compatibility of our clients’ styling comes at the cost of minor restrictions in styling.

To test and prove that our clients can still implement their unique user experience in line with their corporate identity, we have created mock-ups of selected screens of several clients with Angular Material and styled them.

Let’s summarize: The web framework, design system and UI component library are three separate items. The web framework handles technical aspects behind the scenes. The design system is a set of rules without a concrete implementation. The UI component library provides components that implement certain aspects of a design system. For a whole application to comply with the rules of a design system, the individual components must be composed correctly. Therefore, Avaloq employs UX designers and works with external design agencies to build UIs that comply with Material Design and provide best-in-class UX.

https://material.io

https://angular.io

https://angular.io/guide/releases

https://update.angular.io

https://material.angular.io



Banklets: Micro frontends with standardized APIs

Banklets are coarse-grained user interface building blocks with business functionality. Banklets can provide information (e.g. wealth overview) and be used to perform transactions (e.g. payments).

Banklets are independent modules with respect to code, configuration, and translation. Banklets interact with their environment through multiple APIs, including business configuration, localization, styling and orchestration events described below. Compliance with the standardized runtime APIs makes a micro frontend a Banklet.

Avaloq implements Banklets as Angular modules using Angular Material compliant with Material Design.

We strongly recommend that clients and partners also adhere to Material Design if they want to combine Banklets from Avaloq and others in the same UI. We suggest that clients and partners also use Angular and Angular Material for the most consistent UX and highest performance. Banklets are developed using the standard Angular tools and Angular Material components along with the Avaloq extensions.

It is possible to write Banklets with other frameworks and/or UI components, but Avaloq doesn’t provide active support. Wherever a Banklet can be displayed, any HTML content can be displayed without the benefits of Banklets, such as orchestration.

Application: Choice between single Angular application and Web Components

There are two ways to build complete web applications from Banklets:

1. A single Angular application incorporating the Banklets as Angular modules

2. Banklets as Web Components in an arbitrary application

Web Banking can be implemented in both ways. Front Workplace and Goal-based Wealth Management are provided by Avaloq as single Angular applications. The two approaches have different benefits as described below.

Single Angular application

For Web Banking to be built as a single Angular application, Avaloq provides the Banklets and various libraries (e.g. orchestration) as Angular modules packaged as NPM modules, and a minimal Angular application in source code (< 500 lines) as starter kit. Clients and third parties can contribute additional Banklets as Angular modules. Non-Angular content (e.g. CMS and arbitrary HTML) can be included securely via iFrames. The client then builds the final Angular application (ng build) which bundles the application into optimized JS files. Finally, for containerized deployment, the client creates the Docker container image (docker build) based on an Avaloq-provided base image in their CI pipeline in a new pre-deployment step. This is shown in Figure 16. Avaloq shipping the minimal Angular application in source code and clients running the final build is required to get the optimal runtime performance and UX also for Banklets developed by clients and partners.

Figure 16: Deployment of UI as single Angular application

Angular app as starter kitas source code

Bankletsas npm or source code

Bankletsas npm

Banklets and librariesas npm

Aval

oqC

lient

& srentraPmetsysoce

Angular app

Translation overrides

Configuration overrides

Styles

Container imagewith app and Web

Server

CompilePackage

Running containers

Deployon K8s

Container imagewith app and Web

Server

Bankletsas npm or source code

Development Pre-Deployment Deployment



The UI remains modular at design time; we don’t create a UI monolith. The different UI components are glued together only in the new pre-deployment step. Hence, it is possible to upgrade just a single Banklet or a subset of Banklets by building a new application version with the modified Banklets. This new version can even be deployed as a canary release. Hence, the only significant challenge is that all Banklets must be based on the same Angular version – which we have already managed to do most of the time in the past six years. We consider this an acceptable price for getting the best UX and performance in accordance with the priorities defined above.

The cacheable static Banklet content is served by a horizontally scalable container based on a hardened NGINX web server.

In summary, the main benefits of this approach are:

• Best UX and performance. Full optimization (e.g. tree shaking) can be performed during the pre-deployment build and Angular is loaded only once, if non-Avaloq content is also provided as Angular modules or plain HTML.

• Simplicity. We build a single, standard Angular application as it is widely documented and understood.

• Scalability. By removing the runtime definition of the application, the containers are stateless. This simplifies horizontal scaling.

• Reproducibility. The web application is fixed at the pre-deployment phase. The same complete binaries are deployed in different environments (development, test, production).

The main challenges of this approach are:

• Strong coupling through Angular version. All Banklets must be based on the same version of Angular to get the full performance benefits. Banklets based on other versions of Angular or other web frameworks can still be included via iFrames.

• Build by clients. Avaloq clients need to build the final Angular application and Docker container. Thus, they need to deploy a CI pipeline including internet access (e.g. via an Artifactory proxy). Avaloq provides a sample CI pipeline based on Jenkins.

• Banklets fixed at deployment time. The set of Banklets is fixed at deployment time. It remains, however, possible to add additional content at runtime inside iFrames. This is a theoretical concern. Because of security, no Avaloq client dynamically integrates content after deployment into their Web Banking.

Web Components

Instead of building a single Angular application, Avaloq clients can use Avaloq Banklets as Web Components. Web Components (https://www.webcomponents.org) are an emerging standard that provides a framework for modular UIs. Web Components solve some of the same problems as iFrames, but with distinct benefits:

• Usability. It is much easier to provide a good UX with Web Components than with iFrames. Components are not constrained to a rectangular frame, there is no risk of nested scroll bars, links don’t open in the sub-window, etc.

• Modularity. Both technologies allow different components to be combined at runtime and use different web frameworks and versions thereof. However, Web Components have some restrictions because of the shared global scope.

• Performance. Web Components have better performance than iFrames. However, neither iFrames nor Web Components provide the same performance as a single Angular application because web frameworks like Angular are loaded for each component.

• Maturity. Whereas iFrames are mature and work well in all browsers, Web Components don’t yet.

• Security. iFrames, especially with the sandbox attribute, provide much better isolation of components from each other.

Avaloq will later provide its Web Banking and select other Banklets as Web Components packaged as NPM modules using Angular Elements. It is up to the clients who want to use Web Components to build the application and orchestration; the sections below on application frame and orchestration do not apply to the Web Components approach. Avaloq makes a reasonable effort to provide well-behaved Web Components but cannot guarantee to solve all problems due to the inherent restrictions of the current Web Components standard. We are cautious regarding Web Components in the next 12 months but expect Web Components to become a desirable direction in the long run and will, then, also provide additional support for them.

Recommendations

We recommend that clients deploy Web Banking as a single Angular application to get the best possible performance and the simplest solution. Only clients with many third-party components in the form of Web Components and profound expertise in Web Components should use the Web Components approach.

https://www.webcomponents.org



Application frame: Choice between SPA in plain HTML and portal

Avaloq web applications built as single Angular applications can be deployed as single-page applications (SPA) with a plain HTML page or inside a portal (e.g. Liferay DXP). The choice is entirely with the client. In both approaches, browser navigation (back/forward), performance, general UX, and development efficiency are achieved if the guidelines are followed.

Plain HTML frame

Deployment as a plain HTML page (index.html) means that the navigation menu is provided by the Angular application. The filter of available menu items for a specific user in a given context (e.g. login from a different country) is provided by the IAM. Figure 17 shows this approach.

Figure 17: Plain HTML frame for SPA

Figure 18: The portal provides the navigation for Web Banking as SPA without full-page reloading

Most clients who currently deploy a portal use it to provide navigation, content management, and campaign management functionality. These aspects are separate. That is, clients may use the Angular application for the navigation and other content and campaign management systems (CMS). Such CMS content can be displayed in place of a Banklet. A CMS without portal functionality may be cheaper and simpler.

Portal

When Web Banking is deployed in a portal (e.g. Liferay DXP), the portal provides the navigation menu including the filtering for the user and context (Figure 18). For optimal performance, navigation in the portal triggers a message to the Web Banking SPA to display the corresponding context instead of performing a full reload. That is, the Web Banking SPA displays different Banklets over time in the same frame. This includes the possibility to show multiple Banklets at the same time. Avaloq support Web Banking in a portal, but does not provide support for a portal itself.Angular Top Menu

AngularSideMenu

Show one or more banklets(single route)

Portal Top Menu

PortalSideMenu

Web Banking SPA

Show different banklets / views over time without full page reload.

Show one or more banklets(single route)



Runtime orchestration: Defaults from Avaloq with selective override by clients

Avaloq provides secure customizable orchestration directly in the browser without server roundtrips for optimal performance. Orchestration is a separate module based on a state machine implemented with Redux. Avaloq provides default actions (e.g. display trading Banklet when selecting ‘sell’ on a position in the wealth overview), which clients can override. Banklets send events to the orchestrator and receive messages. Banklets don’t include hard-wired orchestration.

For Front Workplace, orchestration and the associated customization have been moved from ACP code tables to JavaScript and JSON in the middle tier and browser. We have decoupled the action definition (e.g. ‘Call phone number 123’) from the action result (Banklet declaring that it can handle ‘Call phone number’) through a JSON-based UI-command language following the Android intent pattern. The Front Workplace forwards the message, respecting the declared security rules. The concepts of views, work area tabs and display modes remain. The Front Workplace orchestrator decides the view proxy in which a Banklet is displayed, based on the extended Banklet descriptor. Additional actions may be provided by external action services called through a REST SPI.

Configuration and localization: Declarative with design-time validation

Most configuration is now purely declarative. Configuration is validated at design time (like ACP code table compilation) to detect typos, illegal values, properties in wrong files, and other common mistakes at design time. This reduces configuration and upgrade cost and risk.

As part of the upgrade to the new architecture, we mostly maintain the current business configurability but reduce the UX configurability to ensure compliance with Material Design and reduce the cost for further updates. We follow the general approach of eliminating mandatory configuration and reducing optional configuration.

Furthermore, we will add multi-layer configuration capabilities for our pre-defined banking standards.

Localization, such as translations as well as number and date formatting, follows industry standards formats. Hence, third-party products can be used to support the translation process.

Security: No iFrames for trusted content; third-party content optionally in iFrames

As stated above, Banklets are no longer displayed in separate iFrames, which greatly improves performance and UX. We still support sandbox iFrames to securely embed third-party content, such as market news.

Migration: Big bang per application

We will migrate each application (e.g. Web Banking, Front Workplace, Goal-based Wealth Management) separately in a big bang per application. That is, up to version n, all Banklets of a given application are based on the old AngularJS stack, and in version n+1 all Banklets are based on the new Angular stack. All fix packs of version n will also be based on the old stack. This gives Avaloq clients a year during which they can freely schedule their upgrade.

A migration Banklet by Banklet is not desirable because a UI combining old and new would be highly inconsistent, would require two sets of CSS styling, and would rely on iFrames.

Summary and conclusions

The new UX architecture brings Avaloq’s clients many benefits:

• Optimal performance based on Angular, a single Angular application, and no iFrames

• Ease of adoption, efficient usage, attractiveness, suitability for mobile browsers, and accessibility based on Material Design, Angular, and Angular Material

• Short time-to-market for future innovation based on backward-compatible styling with Angular Material themes and standard technology with powerful tools

• Access to a large talent pool thanks to the use of a widely known design system, UI components, and web framework as well as a simple, standard application architecture

• Security and compliance based on well-supported Angular. The lower upgrade cost also makes it cheaper to update more frequently to the latest version with the latest security fixes.

• Low costs for future upgrades as a result of backward-compatible styling with Angular Material themes, adoption of a framework that is supported for several years to come, and support for a more continuous framework upgrade



In addition, Avaloq ensures a smooth upgrade from the old to the new architecture. The cost of this upgrade will already be amortized by the next upgrade, which will be much cheaper for our clients thanks to the backward-compatible styling API.

The following table summarizes the old and the new architecture/technology stacks:

Property Old New

Design system Implicit Material Design

Web framework AngularJS 1.x Angular 8+

UI components AFP-JS (third-party and own)

Angular Material, third-party, own

Banklets Angular applications Angular modules/Web Components

Tools Proprietary wrappers around standard tools

Standard Angular tools with additional schematics

Application Custom orchestra-tion of Banklets in iFrames

Choice between single Angular application and Web Components

Frame Liferay (Web Bank-ing),

standalone HTML (FWP, others)

Choice between standalone HTML and any portal (Web Banking)

Runtime orches-tration

Fully owned by client, 3-way merge on upgrade

Defaults from Avaloq with client overrides

Configuration Imperative without validation

Declarative with de-sign-time validation

Security iFrame iFrame with sandbox for some third-party content only

In summary, we maintain the open modular UI and the flexible orchestration, we adopt even more open-source and industry standards, eliminate proprietary tooling, simplify the architecture, upgrade to the latest versions of third-party tools and ensure more frequent smooth future upgrades, and prioritize performance and UX over some flexibility.

Mobile applicationsWe follow a mobile-first approach for applications for our clients’ clients. In our mobile apps we implement most content native in iOS and Android, because this approach provides the best UX and trumps other approaches with respect to security, new features, and longevity of the software. Non-native approaches could be cheaper only if we gave up on UX, performance, security, and offline capability but would be more expensive than native implementations if optimized for UX. Many companies who have tried cross-platform frameworks like Xamarin, progressive web apps (PWA), and HTML rendered in an embedded browser reverted to native content. This may change in the future (e.g. with Flutter or better support for PWA) and we periodically review this.

Because a large percentage of mobile users access the content provided by the banks through the browser of their smartphone instead of installing the app, we also optimize browser-based applications for the banks’ clients (e.g. Web Banking) for mobile.

On iOS we use Apple’s Human Interface Guidelines as the design system instead of Material Design to provide a true Apple experience.

Recommended actions for clients and partners• Introduce Front Workplace for your client-facing employees and

Avaloq Web and Mobile banking for your clients.

• For the upgrade of Web Banking, Front Workplace, and Goal-based Wealth Management our clients must perform the following tasks: Create a new CSS and update the CI/CD pipeline. We strongly recommend that clients and partners also upgrade their banklets to the new design system and technology stack. Clients may also want to update their documentation with new screenshots.



Standardization and customization

Standardization and customization are generic requirements for standard software like the Avaloq Banking Suite. In that sense, this section describes mostly the guiding principles that we apply to all our development rather than a concrete roadmap.

Customizability is the ability to adjust the software so that it behaves the way the client wishes. Or in other words, customization allows a business to buy standard software without forcing the business to be 100% standard.

Less is moreOur approach to customizability is ‘as little as possible, as much as absolutely required’ because flexibility incurs a high cost over the lifecycle of the software (initial customization, upgrades, regression testing, etc.).

The required flexibility of customization depends upon the business domain. Back-office processes can be highly standardized (in many cases even across jurisdictions), whereas the front office and UIs for the banks’ clients require more differentiation.

All types of customization are not created equal either. For example, adaptation in an imperative language is costly and error-prone and, therefore, something we try to minimize. On the other hand, personalization at runtime by the user and the combination of ecosystem solutions are types of customization we promote.

Configurability is not always the best solution. For example, a highly configurable UI never provides best-in-class UX. Hence, we reduce configurability in UIs and reuse of a given Banklet in multiple contexts. Instead, we recommend creating separate dedicated UIs.

The better we understand the business, the better we can standardize. For this we also need multiple banks as sparring partners, their willingness to co-define a standard, and the time to do so.

Where there is no global standard for all banking segments, we provide options in the kernel or create different solutions with different banking standard editions. We also use the banking standards to increase standardization for new clients in existing components where standardization in the kernel is difficult to achieve without adversely impacting existing clients.



Customization of self-contained systems and microservicesIn self-contained systems and microservices, we standardize semantics and avoid mandatory customization wherever possible. For example, Goal-based Wealth Management runs out of the box without any business customization – just a few server names and passwords need to be defined. Most banks will want to adapt the styling and goals, but this is purely optional. Furthermore, we keep optional customization to a minimum to minimize cost.

With the Installator described above, we have taken the first steps towards standardized customization of microservices, largely adapting proven patterns from the ACP:

• All customization is stored in sources (transport, diff).

• The git source code repository is master. This differs from SAP and Salesforce, where much customization is done on production or on a clone thereof and then transported.

• We validate the customization at design time instead of waiting for odd errors at runtime. This corresponds to code table compilers and base parameter consistency checks in the ACP.

• Customization is in explicit customization points only, rather than permitting injection in any place or overwriting of kernel sources as SAP and others do.

• We define a CI/CD pipeline.

We are working on extending this customization concept and tooling along the following lines through to the end of 2020:

• Wherever possible, we provide customizability in the form of an API/SPI instead of customizability inside the microservice, especially if customization wouldn’t be purely declarative.

• We want a rich standard object model in the microservice kernel to avoid cases like in the ACP, where Open APIs like PSD2 and robo-advisory require custom mappings to object model extensions. Nevertheless, we’ll support object-model extensions where necessary.

• We use open-source industry standards like DMN- and JVM-based languages instead of defining our own. This is different from the ACP, where we had to invent our own Avaloq Script language in 2001.

• We will build up capabilities like workflow and rule inside self-contained systems/microservices and for overall orchestration. That said, not every self-contained system needs a full-blown workflow engine and its internal workflows to be configurable, but every workflow needs an audit log.

• Where appropriate, our microservices are multi-entity capable and support customization per entity.

Banking standards as upgradeable productsABR/S is now an upgradeable product rather than just a starter kit for new SaaS clients. Thus, our clients continue to benefit from Avaloq improvements also after going live: kernel release upgrades are simpler because most of the effort is handled for all clients by Avaloq in the banking standards. Second, regulatory changes and the use of new functionality are much simpler to implement. This is a major advantage over model banks that only serve as starter kits.

We achieve this with the introduction of a client contribution layer to create multi-layer customization in separate ice clients (repositories) with clear separation between edition master (ABR/S maintained by Avaloq) and client-specific customization with an API between them (Figure 19). The client layer contains client-specific selections (e.g. accumulators/decumulators), overrides (e.g. deactivation of salutations), and extensions (e.g. interfaces to client-specific third-party systems).

Figure 19: Upgradeable banking standards and client contribution layer

APIsAvaloq core

Contribution layerClient specific selection, overrides, and extensions

Avaloq market editions(functionality, integrations, 3rd party systems, processes, documentation, journeys for market.)

APIs

Banking standard ABR/S editionsfunctional configurations AP

Is

Ecos

yste

m

aval

oq.o

ne

Stan

dard

inte

grat

ion

Specificintegration

Shared by all customers

Maintained by Avaloq6-month functional release cycleon-demand fixes



To ensure that we can evolve the edition masters with seamless upgrades, we strictly limit what is possible in the client layer. As an added benefit, new client implementation projects based on ABR/S are faster because more functionality is built into the master and we can support more ABR/S projects in parallel than with just the pre-processor approach. New clients who want full flexibility at the cost of not getting the aforementioned benefits after go live can still opt to use ABR/S as a starter kit and maintain the full customization in their own single ice client.

Figure 20 illustrates the technical implementation of features that are shared by multiple banking standards editions and the selection of these features for a specific client.

This section describes the implementation of banking standards in the core. We are also extending our banking standards to microservices and AFP, where the same benefits are realized with different solution approaches.

Business process managementWe continue to innovate in business process management.

In the ACP workflow, we are focusing on further improvements to STP rates, standardization and efficient reporting. With our domain-specific languages for workflows and the standardized representation of order types, workflows can now be delivered within the kernel. The new order pools (ACP Release 4.3 and newer) support efficient reporting for custom subsets of orders, such as ‘All stock exchange transactions of my clients over the past two days’.

Figure 20: Selection and combination of individual features

Avaloq has developed the Business Rule Engine (BRE), which provides both business abstraction and design-time tooling for rules. We support industry standard DMN (decision model and notation) so that our clients can import third-party rules, covering aspects such as investment suitability. Our BRE also allows clients to define, via customization, their own rule engines for use cases where the kernel doesn’t provide a rule-based customization. Examples are use cases, such as order validations and value dates for foreign exchange, that change often, that businesses want to understand and possibly maintain themselves, that involve significant business complexity and that lend themselves to being expressed declaratively. Most new rule engines built by Avaloq are based on our BRE, and we are continuing to enhance both the design-time tooling and the runtime engine. For select rule sets, such as derived classifications, we are making it possible to use BRE instead of the old rule format. We don’t plan to derelease the old format to avoid upgrade cost for our clients.

Avaloq has used the edoras one/Flowable case management engine (CMMN) since 2013 to orchestrate flexible workflows, such as in Client Lifecycle Management (CLM). We are changing the way we interface with the engine:

• We use the Flowable engine exclusively in a headless mode through REST and Java APIs. We no longer use the edoras one UI to indicate the case and process state. This reduces complexity and improves performance. Of course, FlowableDesign (previously edoras vis) is still used at design time to visualize the workflow.

• The Flowable engine interfaces with the ACP mostly through Community REST APIs rather than airBOL. This also reduces complexity.

Furthermore, we are in the midst of the upgrade from edoras one 1.x to FlowableWork for CLM.

Master source code repository

@

Source code repository

Selection “Full”

Selection ASIA (HK, SG, MY)

Selection DE

Selection (DE, SG, +), overrides, extension

System instances

Full

ASIA

DE

CLT

Feature AFeature BFeature C

Accu/DeccuGerman TaxIslamic Banking

Description & key benefit

Faster deployment, given only necessary artifacts deployed

No unwanted side effects (e.g., security and system performance issues inherently prevented)

Client edition can leverage selections of master source code repository, override and extend

Legend:

2,500 configuration items• Products / functionality• Languages• Integration • Business units• Pre-configured options

Client requirements• Developed either as extension of

existing configurations or as new configurations

Client configuration



Compilers in Xtext and JavaWe are rewriting all our ACP compilers for domain-specific (e.g. Avaloq Script) and industry standard (e.g. XML Schema) languages in Xtext and Java (previously PL/SQL). This will help us produce faster code, reduce compilation duration during installation, and allow for greater innovation. For example, in ACP Release 4.8 we introduced deterministic functions that are evaluated at compile time (e.g. resolve object references).

Recommended actions for clients and partners• Stick to standards instead of asking for flexibility with high cost.

• Use the Avaloq Business Rule Engine to create your own rule engines.

• Implement CLM to digitalize your client lifecycle management.



High availability and system performance

24x7 availabilityWe have several initiatives aimed at increasing the availability of different capabilities.

With ACP Release 4.4, we introduced online installation of kernel and customization changes. We will add support for additional source types if there is a demand. Our goal is to ensure that most small modifications can be installed quickly and easily, without downtime and delays. Online installation of major releases (every 6–24 months) is not envisaged, due to the greater levels of risk and testing that would be involved.

Several Avaloq clients use clones (Oracle Data Guard or storage split mirrors) to serve read-only requests during ACP database maintenance. Open and Community APIs with read caches are a new alternative for read-only access at these times. Furthermore, we are implementing persistent write-back caches for dedicated functionality, such as payment.

AFP Web Banking allows read and limited write transactions – such as payments – during ACP database maintenance.

We are building microservices and self-contained systems with support for canary releases to support 24x7 availability based on our clients’ business requirements.

System performance and scalabilityAvaloq has made many performance and scalability improvements to support over 8,000 concurrent Front Workplace and SmartClient users of 252 Raiffeisen banks (business units) on a single ACP instance. Avaloq clients will get many of these enhancements when they deploy the corresponding release (stream solutions). Other enhancements, such as order pools, require clients to adapt their customization to benefit. Key improvements are in reporting and stateless sessions, which are used in Front Workplace and AMI Web Services. Most large Avaloq clients have the potential to reduce average response times and CPU requirements by 30%.

Two clients switched to Oracle Exadata and reported significant performance improvements compared to a latest-generation server with a different architecture, including a reduction of the time required for the 700 nightly batch jobs by a factor of two, to process corporate actions and to load the securities master data from messages by a factor of four as well as significant positive feedback from happy end users.

Recommended actions for clients and partners• Try out online installation and share your additional online upgrade

requirements with Avaloq.

• Implement the performance and scalability improvements possible with new ACP releases.



Data

According to The Economist, the world’s most valuable resource is no longer oil, but data. We help our clients to improve the quality of their data, protect it, and use it for the benefits of their clients.

We help our clients maintain and improve the quality of their data with our Client Lifecycle Management module, person model 2, clear ownership for each data element and modification only in the master, and the usage of transactional data stores and sagas in microservices.

We help our clients protect their data with sensitive data separation (SDS), anonymization of data in clones, as well as synthetic and synthesized data for clones.

We help our clients comply with privacy laws with data wiping, our new GDPR module, and various information lifecycle management (ILM) functionalities. As part of ILM, Avaloq has supported the deletion of most old entities, including pillars, messages, audit logs, and static data orders as well as transactional orders and bookings for payment transaction banks since 2008. Until mid-2020 we’ll add support for the deletion of transactional orders and bookings of select retail banks and will continuously extend the scope to cover all business transaction types.

We help our clients use their data with Open and Community APIs, events (future), pre-built use cases (like notifications of mortgage renewal and available cash for investment in our upcoming RM Cockpit and banking standards), and the upcoming analytics platform for SaaS and BPaaS clients.

Recommended actions for clients and partners• Implement our GDPR module if you are affected by the regulation.

• Upgrade to the person model 2, if you haven’t already done so.



Application roadmapsThis section describes the architecture roadmap of selected Avaloq applications. Please refer to the Roadmap 24 for the functional roadmap and our new platforms.

2020Changes• Individual containers• Migration to Angular / Material Design

and SPA• Separate container for first business

modules (e.g. E-Documents)• JWT for security

Benefits• Standardized deployment (no need to

order individual VMs)• Easier scaling (start additional containers

instead of ordering additional VMs)• Operations «built in»: new container

based applications include dashboards, etc. for monitoring

• Better performance (SPA)

2021Changes• Modularization (separate container

for all business modules)• Merge REST and SOAP layer• Additional self-contained systems

(e.g. E-Documents)

Benefits• Smaller components lead to fast-

er-time to market, lower risk for updates, and better horizontal scaling

FutureChanges• Capabilities provided by self-contained

systems with Open APIs• Web Banking as channel / experience

Benefits• Best experience and highest agility• Consistent architecture for content from

different Avaloq platforms• Easy to integrate own UX components

based on Open APIs

Figure 21: Roadmap of Web Banking

Web BankingFigure 21 shows the roadmap for Web Banking.

2019

JBoss

JBoss

ACP

AFP AMI Web Services

WAF / IAM

PortalLiferay (optional)

Banklet API(REST)

3rd partyservices

Business API(SOAP)

Kubernetes

Multibanking

File Processing(PAIN.001, PAIN.008)

…

Sync Server

JBoss

Changes

• Individual containers

• Migration to Angular / SPA

• Separate container for first business modules (e.g. E-Documents)

Benefits

• Standardized deployment (no need to order individual VMs)

• Easier scaling (start additional containers instead of ordering additional VMs)

• Operations «built in»: new container based applications include dashboards for monitoring

• Better performance (SPA)

2020

WealthBanklets

PaymentBanklets

E-DocumentBanklets

Community APIs

WAF / IAM

AMI Web Services

AFPBusiness API

(SOAP)

…

…

…

Other Services (Multibanking, …))

E-DocumentREST API

Banklet API(REST)

Sync API(SOAP)

ACP

3rd partyServices

3rd partyBanklets

Liferay(optional)

UserJourney / SPA

2021

Banklet API(REST)

Kafka

WealthBanklets

PaymentBanklets

E-DocumentsBanklets

Community APIs

WAF / IAM

AFP

Banklet API(REST)

Changes

• Modularization (separate container for all business modules)

• Merge REST and SOAP layer

• Additional self-contained systems (e.g. E-Documents)

ACP

AMI Web Services

E-Documents REST API

Other Services (Multibanking, …))

Sync API(SOAP)

…

…

3rd partyServices

3rd partyBanklets

Liferay(optional)

UserJourney / SPA

WealthUX

PaymentUX

E-DocumentsUX…

WealthBanklets

PaymentBanklets

E-DocumentsBanklets

WAF / IAM

…

WealthSCS

PaymentSCS

E-DocumentsSCS

3rd partyBanklets

3rd partyservices

Liferay(optional)

UserJourney / SPA

2019 Future

2020 2021



Sensitive Data SeparationAvaloq’s Sensitive Data Separation (SDS) module stores all sensitive data (e.g. names, addresses, birthdates) in a separate data store, which can be in the jurisdiction of the legal entity and/or secured with additional measures. Despite the automatic exchange of financial account information (AEOI), SDS has attracted growing interest due to data privacy laws, back-office outsourcing, and plans for a public cloud.

We plan the following architectural enhancements for SDS:

• 2019: Strict SDS. Sensitive data in messages can be separated out in the sensitive data area (e.g. individual jurisdictions) so that it isn’t even in-memory in the core area. This is supported with the JMS Adapter and AMI Web Services running in the sensitive data area and separating out sensitive data.

• 2020: Containerization of all SDS components

• 2021: Replication based on Business Data Events instead of AFP replication

• Continuous: Support for SDS in additional applications (e.g. for data mastered in self-contained systems) and in banking standards

Avaloq CoreAs well as creating new functionality in the new architecture, we are also be rewriting selected elements of ACP functionality. We prioritize functions where the new architecture brings the greatest benefits, such as digitalization, simulation and responses to complex regulatory changes. We start above the transaction layer (e.g. advisory, simulation, CRM, reporting, etc.), then tackle bank management (e.g. accounting, risk) followed by the transaction layer and book keeping.

We will continue to maintain existing implementations in the old architecture at least until 2025, or as long as our clients need it, but we will focus innovation on the new implementations. We give clients the choice for each functionality we rewrite, whether they want to use the old ACP implementation or the new self-contained system, and when they want to migrate. That is, we don’t follow the strangler pattern.

We will discuss changes with our clients in knowledge groups and other forums and announce them early. Please refer to the Roadmap 24 for our current plans. We will offer smooth migration paths from the old to the new implementation, not least because trouble-free migration, with minimized transition costs, is critical to our own interests, as Avaloq’s service centres own and manage more customization than any on-premises client.

Recommended actions for clients and partners• Actively participate in knowledge groups.

• Discuss your own roadmap and requirements with your Avaloq key account manager.

Figure 22: Roadmap of Front Workplace and Client Lifecycle Management

Front Workplace and Client Lifecycle Management Figure 22 shows the roadmap for Front Workplace (FWP) and Client Lifecycle Management (CLM).

• Upgrade to Flowable / headless engine• REST APIs for communication with ACP• Angular / Material Design

• Containerization• JWT for security

• Angular / Material Design• More non-ACP content and

deployment w/o ACP

FWP

CLM

Front Workplace

Client lifecycle management

Q1 2020 mid 2020 TimeProduct

• Containerization• JWT for security



Public cloud

Avaloq clients have used AWS for elastic capacity for ACP customization since 2015. Avaloq introduced its avaloq.one developer sandbox on public cloud in 2018. We run the complete Avaloq Banking Suite, including the ACP, AFP Web Banking and Front Workplace, and our containerized solutions in public cloud for integration testing and presentations. We look forward to the first Avaloq client getting the approval from the regulator and its internal compliance department to put production (possibly with sensitive data on SDS elsewhere) onto a public cloud and/or cloud at client (e.g. Google Anthos, AWS Outposts, Azure Stack).

Avaloq builds on industry standards, such as Kubernetes, to run on any cloud and avoid vendor lock-in. We support the optional usage of managed services with the same API, e.g. Google Cloud SQL PostgreSQL, Amazon MQ, and Azure Windows Virtual Desktop.

Avaloq has several Google Cloud- and AWS-certified engineers and is streamlining the deployment of its software products on public cloud (e.g. networking, storage for databases including cloning, high availability).

Deployment of ABS on public cloud has legal restrictions; please check with your Avaloq Key Account Manager before doing so. Any deployment must be properly secured (e.g. no public IP for test and development) to avoid intellectual property rights violations and security problems of providing hackers a testbed.

For clients interested in private cloud, we plan similar initiatives on the VMware stack with Terraform.



Required skills

We recommend that clients and partners build up the following skills, if not already available:

• Banking and Avaloq concepts

• General software engineering

• Configuration and operation of a CI/CD pipeline (e.g. git with Bitbucket/GitLab/Gogs, Jenkins, artefact repository like Artifactory/Nexus)

• Operation of OpenShift/Kubernetes for the installation and operation of the OpenShift cluster

• Material Design, Angular, Angular Material, and TypeScript for the development Banklets and the build of browser-based applications

• For the development of own microservices: Java/Spring Boot or the language/framework of choice

• Security: Airlock WAF configuration, JWT, Web security, etc.



Way forward

General implementation approachWe will implement the new architecture via an evolutionary approach, with small projects that all individually add value for our clients. We will split most of the implementation into functional modules and address major aspects such as Community and Open APIs and containerization across every module.

We are serious about respecting and protecting your existing investment in the Avaloq Banking Suite. All current ACP functionality will be maintained at least until 2025 or as long as our clients need it. We will communicate changes clearly and at an early stage to the Avaloq community, and we expect the community to be keen to learn about the new concepts and technologies that will bring them so many substantial benefits. Some improvements where this will maximize business value, such as rewriting selected elements of ACP functionality as microservices, will necessarily require adaptations of some existing customization.

Our general principles are simplification, productization and agility. We expect most clients to adopt a multi-speed architecture and more frequent upgrades – annually for transaction processing (ACP) and quarterly, or more often, for interactive functionality. This will require good deployment and testing automation for all components. ITO and back-office operation cost reduction is a key requirement. We measure the benefits of changes and take decisions based on data.

Avaloq is introducing industry standard semantic versioning for all components outside the ACP database. This approach will support a healthy, vibrant ecosystem in which components from different vendors can evolve separately and compatibility is governed by a well-documented scheme. To avoid unwanted ripple effects, we will retain backward compatibility of APIs for even longer than we did previously. Back branching will be reduced to improve stability and reduce dependency problems.

We are investigating the simplification, coordination and clarification of the release models of the different products, such as the ACP, ABR/S, Web Banking, self-contained systems, and tools. Our goals are improved plannability and quality, reduced regression risk and testing cost, lower cost of innovation, and faster time-to-market.



The 12-month roadmapWithin the next 12 months, we expect that most Avaloq clients will have deployed Kubernetes and installed new containerized applications such as Goal-based Wealth Management and pain.001 or will be in the process of upgrading to an AFP or ACP release that requires Kubernetes.

Avaloq will roll out Community APIs with read caches on ACP Release 4.8 and above. Many fintechs will be introducing innovative solutions, integrated via our Open APIs, and testing these on developer sandboxes in the public cloud. By mid-2020, we expect several clients to have Open and Community APIs beyond PSD2 in production.

Our browser-based UIs will be faster and better than ever before, thanks to the elimination of iFrames, the adoption of Material Design, and the upgrade to Angular 8+. Our mobile apps will get even higher ratings, thanks to the addition of more native content.

The 12 to 24-month roadmapWe expect that most Avaloq clients will run containers on Kubernetes in production. Self-contained systems providing improved versions of selected ACP modules, such as Wealth Management, as well as new platforms like the upcoming Avaloq Engage will be live. The old PL/SQL implementation of modules for which there is a new implementation as self-contained system will be in maintenance mode.

In the longer termLooking further ahead, we plan to continue optimizing our architecture, adapting to new requirements and making the most of newly available technologies. We will be rewriting parts of the existing ACP with new self-contained systems, in line with our clients’ needs and priorities.

Our objective is to keep on innovating – always with a special focus on doing it the right way, and always respecting and protecting your existing investment in the Avaloq Banking Suite. This is how we see Avaloq better serving its clients every year, attracting the best staff and partners to work with us and enabling our clients to recruit the best talent for their own teams.



Roadmap disclaimerThe content of this paper is for information only and is intended to outline the general product direction; accordingly, it should not be relied upon for the purpose of making purchasing decisions. The information provided is not a commitment, promise, or legal obligation to deliver any material, code or functionality.

Any references to the development, release, and timing of any features or functionality described for these products are for information purposes only, and Avaloq has sole discretion to make changes to any of these parameters at any time, for any reason or no reason. Product capabilities, timeframes and features are subject to change without notice. Avaloq neither represents nor warrants the accuracy or completeness of the information. This document is provided ‘as is’, without any warranty of any kind, nor any implied warranty of merchantability or fitness for a particular purpose.

That said, it is our goal to deliver what we outline in this roadmap.

About

FeedbackWe welcome feedback on the content of this document via your Avaloq key account or partner manager.

VersionFirst published: 10 September 2019 Last update: 28 October 2019



Avaloq is driving the digital transformation and automation of the financial services industry. Based on our fully integrated banking software, we create powerful digital experiences provided through a standardized Business Process as a Service (BPaaS) or Software as a Service (SaaS) model to banks and wealth managers. Our solutions give financial institutions the freedom to focus on channel and product innovation, client service, client trust and growth, while Avaloq ensures a seamless operation behind the scenes.

158 banks and wealth managers – with more than CHF 4,000bn in assets managed worldwide – trust Avaloq, our products and our experience. Our clients are the leading banks of today and tomorrow.

About Avaloq: Essential for Banking

Avaloq is the only independent provider for the financial services industry to both develop and operate its own software, which makes us a world leader in efficient banking solutions. To further spur innovation, we work with clients, other fintechs, universities and hundreds of third-party developers in a uniquely collaborative way we call the Avaloq Ecosystem.

Headquartered in Switzerland, Avaloq has more than 2,000 employees; three R&D centres in Zurich, Edinburgh and Manila; and three service centres in Switzerland, Singapore and Germany. We also have a presence in the world’s most demanding financial and innovation centres, including Berlin, Hong Kong, London, Luxembourg, Madrid, Paris, Singapore and Sydney. More information is available at www.avaloq.com


www.avaloq.com