Spoiler: cloud adoption remains low among investment managers because of …
A lack of suitable cloud products offered by vendors!
Limina was created as a counter-reaction to the slow pace of existing vendors in their cloud transitions. Throughout this article, we will offer full transparency on how far Limina has come in our product development in each area. These comments are clearly marked, so you can easily follow what are general industry points and what points relate specifically to Limina’s Investment Management System.
But it's vendors who are to blame. Here are the 4 most common reasons why there are still cloud adoption challenges among asset managers:
You and I both know that investment management workflows and processes are complex. They are also specific to your individual investment strategies. In other words, you differ in these functions from your competitors - which is not necessarily the case within other functions such as accounting.
Hence, you want your system to support YOUR processes and workflows, whether it’s an Investment Management System, Order Management System, Portfolio Management System, or Investment Book of Record. Traditionally, extending a system's functionality was achieved with custom code or building processes on the side, based on the database of the system. In the cloud, a new approach must be taken through configurability to offer this.
It’s a lot easier to build a standardised product without personalisation ability. Naturally, the first-generation Software-as-a-Service (SaaS) and cloud solutions offered standardised systems. This unfortunately made the systems unfit for most established asset managers (a rough indication of this is above 1 billion euro / dollar in Assets under Management / AuM) leading to limited cloud adoption. Once you grow above this approximate size, it’s common to prioritise oversight capabilities and better decision support for front and middle office teams.
To clarify, when we talk about personalisation of investment workflows and processes, we aren’t talking about the ability to change the colour of a button in the user interface. Rather, we refer to things such as controlling carbon data that is available on an equity instrument before it can be traded in your sustainability fund, and checking the total carbon footprint as a pre-trade compliance rule.
This deep level of configurability is both difficult and expensive for vendors to build (driving upfront investment needs) and maintain (making the price tag of the system higher) resulting in reduced cloud adoption.
Limina note: when we started, we set out to solve the customisation issues in the cloud through personalisation. Hence, we created the system from start to be moldable to your unique situation, something we call Enterprise SaaS. With that said, from time to time we find areas where the further personalisation is required and hence invest heavily in R&D on an ongoing basis. This also means that while we’re rarely the cheapest solution, we’re often the most cost-effective.
In the traditional on-premise world, you could choose at your own discretion when you wanted to upgrade your systems. This had its problems, most specifically that you were sometimes the only asset manager live in production on a specific version of the software. You did all the testing yourself, getting no leverage in terms of more firms or users testing that version at that time.
In a cloud-native application, most of the time the vendor decides when to upgrade the system. The challenge is that you might not want to, or be able to, accept this. There might be governance processes around certain times of year (“freeze periods”) or when markets are going through high volatility.
Limina note: we have created a set menu approach to upgrades, where we offer the option to choose release patterns. We believe this Enterprise SaaS approach is the optimal trade-off between ensuring great governance on one side and cost efficiency and robust releases on the other. Read more about how Enterprise SaaS solves upgrade problems here.
Contrary to popular belief, integration challenges are not solved by moving a system to the cloud. This is especially true if only one system is moved. That system still needs to integrate with all other service providers and systems running on old technology, such as CSV and Excel files sent over SFTP.
The first-generation cloud vendors approached this by managing integrations on behalf of clients, which also comes with drawbacks such as dependency on the vendor for change management. This approach not only delays change management but it often also leads to an increased cost if the vendor charges each time a new interface is required.
For a system to be fully interoperable with other solutions, an open platform approach must be taken. This is however unrelated to the cloud – a system can be open or closed irrespective of if it’s deployed, hosted or cloud-native.
Limina note: We believe in offering a flexible integration engine as well as managed integrations – each approach chosen on an integration-by-integration basis based on when it makes most sense for your business. We also believe in an API-first approach to solve the most challenging integration problems.
This is probably the biggest reason why asset managers remain slow to adopt new technology. Your functional needs are both very deep (complex workflows) and broad (many workflows, e.g. multiple asset classes and varying investment strategies). These must all be supported for a system to be viable in both the short and long term. It doesn’t matter if the other three aspects above are checked or if the solution is the best long-term future-proofed choice. You need something that works for your business today.
Here, the older vendors usually are in the strongest position. All cloud-native and SaaS solutions are “newer” and hence have had less time to build functional coverage.
The way to find out if a vendor has what you need, is to run an RFI/RFP process with a list of vendors that matches your business culture. An additional benefit with cloud-native and SaaS is that it's very likely that the level of technical debt is low.
Limina note: We are building Institutional Portfolio Management Software functionality. Two examples include:
This means we need to build more functionality in total compared to one-size-fits-all SaaS vendors, who are often focused on broad – but not deep – functionality. The best way to decide if we have what you need or not, is probably to reach out to our team today and we can show you in a live demo.
It’s our belief that it’s important to keep the ability to personalise workflows and processes. We also believe the first generation of Software-as-a-Service (SaaS) and cloud solutions didn’t enable you to do this.
At the same time, it is impossible - or at least very painful - to live without all required features. So, any solution must be feature-complete, i.e. both broad and deep enough, for you to consider it in the first place.
Hence, we created an Enterprise SaaS investment management platform that offers concrete solutions to the pains of on-premise solutions while at the same time not bringing the downsides of common cloud systems.
Having been clients ourselves, we've taken the personalised approach beyond the software and into the fabric of our service organisation as well. Listen to the video below to learn how we make sure to offer you top-quality personalised service.