Skip to main content



The FA platform (henceforth referred to simply as "FA") is a modular system which is delivered as software as a service, "SaaS".

The platform is hosted on Azure, and is made up of four main parts:

  • A Kubernetes cluster running a variety of FA's proprietary applications alongside certain open-source applications

  • Microsoft Azure MariaDB SQL Database

  • Azure Servicebus, used for certain communication between applications within the FA platform, and as an optional integration mechanism for external applications

  • Azure Storage accounts, used by FA applications for persistent file storage

The FA platform contains several different applications and services. The main drivers for this development strategy are increased options for scalability and fault-tolerance.



FA Platform is modular and it contains applications, services and managed services.


Applications are used by different types of users for different purposes.


  • FA Back - Main application for all the portfolio management related activities

  • FA Client Portal – A mobile-first open-source portal for investors

  • FA Front - Configurable application to provide limited access to FA Platform for advisors or end-clients

  • FA Fund Management - NAV calculation and shareholder registry


  • FA Admin Console - User and file management

  • FA Developer - Tools for third-party developers working with FA

  • FA Monitoring - Logs and statistics

  • Identity and access management - Advanced configurations related to security and identity management


  • REST endpoints

  • GraphQL endpoints


Business logic

  • FA Core - Core business logic

  • FA Fund Service - Business logic for fund management activities

  • FA Trading - Business logic to support trading

  • FA Report Calculation - Logic to calculate report data

  • FA Analytics service – A service that improves scalability of analytics-related features in the FA Platform


  • FA File manager - File management service

  • FA Navigator - Managing applications in the Global App Bar

  • FA Contact manager - Services for contact management needed in FA Admin Console


  • Connector - Integration application enabling connectivity between FA Platform and external services


  • JSReport - Services to generate reports based on JSReport


  • Keycloak - OpenID server for security

  • ClamAV - Virus scanning services


  • Static HTTP - static file service

  • Prometheus - Support application monitoring

  • Loki - Supports gathering logs from applications

  • Gridgain - Distributed cache and lock management

Managed services by Azure


  • Azure Servicebus - JMS based messaging between services

Data storage

  • MariaDB - database for FA Platform

  • File storage - shared file storage between services

Deployment model


FA Platform is hosted in Microsoft Azure cloud network.


FA is deployed using Kubernetes (, which is a system originally developed by Google Inc. and currently developed by CNCF ( Microsoft Azure has its own implementation of Kubernetes named as Azure Kubernetes Service (AKS, AKS is used to achieve high availability for the application with enterprise-grade security and governance.


As Microsoft Azure states, the nodes use Azure Managed Disks. For most VM node sizes, these are Premium disks backed by high-performance SSDs. The data stored on managed disks are automatically encrypted at rest within the Azure platform.

For more information about AKS security go to

For more information about Azure Database for MariaDB go to


Azure Database for MariaDB automatically creates server backups and stores them in geo-redundant storage. Azure Database for MariaDB takes full, differential, and transaction log backups. These backups allow you to restore a server to any point in time within your configured backup retention period. The default backup retention period is seven days. All backups are encrypted using AES 256-bit encryption. In this case, the secondary location for backups would be TBD as TBD is the primary location for the services.

Backup frequency

Generally, full backups occur weekly, differential backups occur twice a day, and transaction log backups occur every five minutes. The first full backup is scheduled immediately after a server is created. The initial backup can take longer on a large restored server. The earliest point in time that a new server can be restored to is the time at which the initial full backup is complete. Other options for Backup content and frequency are available.


In Azure Database for MariaDB, performing a restore creates a new server from the original server's backups.

There are two types of restore available:

Point-in-time restore creates a new server in the same region as your original server.

Geo-restore allows you to restore your server to a different region.

The estimated time of recovery depends on several factors including the database sizes, the transaction log size, the network bandwidth, and the total number of databases recovering in the same region at the same time. The recovery time is usually less than 12 hours.

Point-in-time restore

Independent of your backup redundancy option, you can perform a restore to any point in time within your backup retention period. A new server is created in the same Azure region as the original server.


Geo-restore is the default recovery option when your server is unavailable because of an incident in the region where the server is hosted. If a large-scale incident in a region results in the unavailability of your database application, we can restore a server from the geo-redundant backups to a server in another region. There is a delay between when a backup is taken and when it is replicated to a different region. This delay can be up to an hour, so, if a disaster occurs, there can be up to one-hour data loss. For more general information about Azure Database for MariaDB Backups go to

Disaster recovery

DR cluster will be setup to be running in the secondary region in the case of primary region failure. Database will be recreated from backup to secondary region. Cluster that is started in the procedure will connect to the created database. This procedure is done manually. File data has been automatically backed up to the DR regions Azure File share. Secondary region's IP addresses are different from the primary region and DNS record changes will be done during the manual failover.

As disaster recovery is manual, it is done within the service-level agreement (SLA) specified in the contract between the parties.

Example scenarios

Loss of network / power in Netherlands primary location datacenter.

Every situation is evaluated to achieve the functionality back as soon as possible. After noticing the abnormality DR procedure is started. First FA will determine if it is possible to achieve normal function in primary region. If it is seen that it is not possible within two hours or it is failed to do so, secondary region is activated. The primary region may be back before the DR environment is up and running. In this case the primary location will be used.

For more general information about Azure Database for MariaDB Backups recovery go to


As stated above, main monitoring is handled by Kubernetes. Kubernetes cluster will be linked to Datadog ( for modern monitoring and analytics. Datadog is trusted as monitoring system by many notable IT companies and financial institutions. System collects information about system abnormalities and alerts in such possible cases.


Authentication and authorization


Secure authentication ensures systems data is safe. FA's Authentication provides tools to flexibly control who can log in to FA, track when and where users have logged in, and what they have done within the system. Options for two-factor authentication, IP restrictions, and tracking unsuccessful login attempts provide an extra layer of security. In addition, flexible user roles and permissions allow to extensively control which features users can use and what data they can see when they log in.


Manage user, user roles and permissions

Flexible configuration of user and user roles which can be set up for different types of permissions in Back, UI config in Front etc. User permissions are to be decided within the project.

Control security of logging in

Two-factor authentication and IP restrictions may apply.

Freezing the account in case of unsuccessful login attempts; increasing time if user types in the password incorrectly.

Audit trail on who has logged in, when, IP, FA version

Tracking users login with IP address and full audit trail of any changes made in the system.

FA user access

Only dedicated FA deployment team will be given access to the client environment during deployment phase. FA administrators provide access to consultants working with the deployment. All FA employees have a unique login and all changes are tracked via audit logs. Once deployment is complete, only FA support team will access the environment.

Using FA Platform

FA is a server-side application that is used by a web browser. The user interface is built upon Vaadin Framework ( All the traffic between the browser and the server is encrypted using SSL (i.e. HTTPS). If FA is running as SaaS, there are optional IP restrictions or VPN tunnel limiting the connection to the internet as well.

Swedish tech company Bitsec has conducted a black-box penetration test against FA in SaaS environment and they did not find any security problems. In 2020 projects began to further improve the security and risk of penetration including becoming ISAE 3402 Type II certified. See separate document describing our security projects.

Infrastructure security

Physical security

Microsoft takes a layered approach to physical security, to reduce the risk of unauthorized users gaining physical access to data and the datacentre resources. Datacentres managed by Microsoft have extensive layers of protection: access approval at the facility’s perimeter, at the building’s perimeter, inside the building, and on the datacentre floor. Layers of physical security are:

  • Access request and approval. You must request access prior to arriving at the datacentre. You're required to provide a valid business justification for your visit, such as compliance or auditing purposes. All requests are approved on a need-to-access basis by Microsoft employees. A need-to-access basis helps keep the number of individuals needed to complete a task in the datacentres to the bare minimum. After Microsoft grants permission, an individual only has access to the discrete area of the datacentre required, based on the approved business justification. Permissions are limited to a certain period, and then expire.

  • Facility’s perimeter. When you arrive at a datacentre, you're required to go through a well-defined access point. Typically, tall fences made of steel and concrete encompass every inch of the perimeter. There are cameras around the datacentres, with a security team monitoring their videos at all times.

  • Building entrance. The datacentre entrance is staffed with professional security officers who have undergone rigorous training and background checks. These security officers also routinely patrol the datacentre and

  • The video cameras inside the datacentre are monitored at all times.

  • Inside the building. After you enter the building, you must pass two-factor authentication with biometrics to continue moving through the datacentre. If your identity is validated, you can enter only the portion of the datacentre that you have approved access to. You can stay there only for the duration of the time approved.

  • Datacentre floor. You are only allowed onto the floor that you are approved to enter. You are required to pass a full body metal detection screening. To reduce the risk of unauthorized data entering or leaving the datacentre without our knowledge, only approved devices can make their way into the datacentre floor. Additionally, video cameras monitor the front and back of every server rack. When you exit the datacentre floor, you again must pass through full body metal detection screening. To leave the datacentre, you are required to pass through an additional security scan.

Microsoft requires visitors to surrender badges upon departure from any Microsoft facility.

For more information about physical security of Azure go to

Data Encryption

As Microsoft Azure states, the nodes use Azure Managed Disks. For most VM node sizes, these are Premium disks backed by high-performance SSDs. The data stored on managed disks are automatically encrypted at rest within the Azure platform.

For more information about AKS security go to

Database Security

Connection between FA and the database is encrypted with TLS connection.

The Azure Database for MariaDB service uses storage encryption for data at-rest and is FIPS 140-2 compliant. Data, including backup data, is encrypted on disk. (Temporary files that are created by the engine when it runs queries are not encrypted on disk.) The service uses AES 256-bit cipher, which is included in Azure Storage encryption. The keys are system managed. Storage encryption is always on and can't be disabled.

For more information about Azure Database for MariaDB

Technology stack for FA Applications

The FA Platform makes extensive use of reliable and credible open-source technologies. This section lists the main technologies that we use, but is by no means exhaustive.

Programming languages


Back-end services in the FA Platform, as well as certain older applications (FA Back, FA Core, FA Front) are built with and run on Java version 11.


TypeScript is our language of choice for front-end application development.

Programming frameworks


React ( is a JavaScript library for building UIs. Aside from our older Vaadin-based applications, React is the framework that we use to develop our front-end applications.


Prior to React (see above), FA applications were developed using the Vaadin framework ( Vaadin is a robust and secure open-source java-based web user interface framework for business applications. The user interfaces in FA Back and FA Front are written using the Vaadin framework. For more information, see

Spring framework

The Spring Framework ( is an application framework and inversion of control container for the Java platform. Many of our back-end services and Vaadin-based applications make extensive use of various Spring (and Spring Boot) features.


The Quarkus framework ( is an application framework that allows us to build particularly lightweight backend services using Java.


Hibernate ORM ( is our primary technology of choice when our back-end services require access to data from our relational database (MariaDB).


GraphQL ( is a modern API technology that allows for flexible data querying and manipulation. Through our GraphQL APIs, the FA Platform allows you to integrate external applications with your data in FA. For more information, refer to the API integrations section in FA Developer guide.

Other technologies

The FA Platform includes many technologies that are used for extending and customizing the behavior of the platform. These include the Apache Camel integration framework, the Flowable process engine, the jsreport reporting platform, the Drools rule engine, and more. For more information about how you can utilize these technologies to tailor the FA Platform to your needs, refer to FA Developer Guide.