Software is always a moving target. Software cannot be tangible at all times but is subject to constant further development and enhancement. Even Microsoft announces a new Windows release after having promised to have a final version 10 with incremental upgrades. In the AML compliance sector, i.e., AML, KYC and transaction screening, after a successful go live the next upgrade or migration project is already in progress since new regulations and security features demand enhanced versions. When selecting a new compliance system, there are many questions to be asked - one of which is the "cloud question", on which we will briefly provide some important aspects for your decision-making process. There are many promises such as lower costs, faster deployments, scalability, flexibility, future proofing and so on - which you can find in different flavors on all cloud software provider's websites.

Depending on the jurisdiction, several restrictions and laws in the context of storing sensitive data in the cloud must be adhered to. We will not even scrape the surface about their details, since this is a separate topic but still name two important regulations: GDPR and all its aspects can easily fill a week full of workshops, whereas MaRisk (see BaFin AT9) makes it more difficult to be compliant. One important aspect is the location of the cloud servers. It might be necessary, or at least favorable, to have the data not leave the country. Commercial cloud platforms like AWS, Google, Azure offer their services in multi-national regions, which could be a deal breaker for businesses in smaller countries. If you have found a suitable region, which is outside of the main areas (such as US or UK), it is possible that not all cloud services are currently on offer.

The next important factor is experience: do you already use cloud software in your company (other than Office365) and is the respective compliance software, e.g. screening, monitoring or research system, cloud ready or preferable cloud native? Because of its overall importance, the compliance department should not be in a position to pilot new technologies, it should rather follow the strategy than lead it. The trickier question is the latter, is the software cloud native? Since most solutions will be closed-source software, here are some indicators on how to determine this:

• Built-in scalability and high availability
• Convincing number of actual installations
• Fully automated deployment pipeline
• Divided into microservices rather than monolithic blocks
• Open-source usage with adequate versions (OpenJDK 12 vs. Oracle Java 8, or PostgreSQL vs. Oracle Database)

In the past, open-source software was often considered a no-go in the banking and compliance sector due to security and support issues. There are controversial discussions whether closed or open-source software is considered to be more secure. Most Linux distributions offer commercial support. Database systems (Mongo, PostgreSQL, Couchbase) also are backed by companies, the business model of which is to provide professional support and which thus can be forced by their customers to patch their systems to protect against any upcoming security vulnerabilities and to close any potential security gaps. In some sense this trend can be seen as the “best of both worlds”, the code is still freely available, but you can still expect enterprise level support.

Having legacy software that run in a cloud environment is possible, but in some sense this combines the worst of both worlds. The setup process can be complex. Dependencies to database and (Windows) operating systems may be in place. The hardware costs could be much higher since virtual machines are used instead of lightweight containers. Cloud environments claim to reduce costs. However, a virtual server with real CPUs and exclusively reserved memory costs much more if you host them yourself or if a third party also wants to have its share. For a quick comparison, just go to some web hosting companies and compare the server costs of e.g. AWS EC2 or Microsoft Azure VM, which do not even include storage. Therefore, one should carefully distinguish between running virtual machines on the "internet" and cloud-native solutions.  The former will never save costs, the latter has the potential to save costs. It is very important to have a concept of the running costs of the solution, which will be paid directly or indirectly by the bank.

Another important aspect is the solution's performance. Does the provider guarantee response times and operating time (and are they covered by the cloud provider in the background)? If you buy Software-as-a-Service, all these aspects are ideally part of the contract and within the area of responsibility of the software provider.

Especially when the backend of the environment is not accessible to the end user or the tech team of the bank, it is important to have good APIs for extracting reports, logs and audit trails. The bank's compliance team is still responsible for compliance, so the available reports should be well established and tested. Nobody ever wants to hear this imaginary conversation:

Q: Dear vendor, can you please provide a report about all alerted transactions of the last 13 months and the respective users working on these alerts?

A: Dear customer, we kindly refer to the standard API package you have ordered, which does not cover any transaction details.

If the solution were to be on-premise, technically skilled consultants could be called and they may be able to produce some ad-hoc extracts from the database to please the auditor. Such a backend access is hardly possible with a real cloud solution - especially not with the assumed time restrictions in the imaginary situation.

While trending towards a cloud implementation, you should consider a potential vendor lock-in. Is it possible and feasible to switch from AWS to Google Cloud, for instance? All major cloud offerings come with hundreds of special services on which the application architecture may be built on. Using those services for developing a cloud solution might be smart and state of the art, but when the cloud provider is turning “evil” or just pricey, it could be difficult or almost impossible to switch providers. There are also software providers for application middleware to have the flexibility of AWS/Google/Azure without the lock-in effect such as dapr.io and similar frameworks.

Hybrid Cloud may be a valid third option, especially for stateless requests such as real time name and transaction screening. In this scenario, the user frontend is hosted on-premises and the CPU/IO heavy lifting is done in the cloud. It also could be a good idea to use the cloud for temporary projects such as parallel run and system migrations due to the almost unlimited flexibility of the hardware.

The answer to the cloud question is most likely "it depends". Newly established businesses are trending to go cloud native from the start. Larger institutes are happy to build their own cloud environments, since cloud does not necessarily mean to buy in one of the large providers but is rather a deployment and software design pattern. In the process of finding a suitable answer, my colleagues and myself from msg Rethink Compliance are well equipped in this domain and have profound experience in cloud, hybrid cloud and on-premise deployments to best assist you in this landmark decision.