Contact us
contact us
The Aptitude Blog

Is the answer always SaaS? A cloudy topic for regulatory software!

June 11, 2020
Posted by Tristan Atkins

With the world moving to a Software as a Service (SaaS) based model for applications used across business units, it’s interesting to look at why we are seeing insurers opt for a public/private cloud or on-premise deployment for IFRS 17 implementations.

When we look across our global insurance client base for example, we see more organizations opting to implement our software in their own private instance of a public cloud over any other option, including SaaS. While this appears to buck the rising trend for SaaS, there are several reasons why insurers have made this decision when working towards IFRS 17 compliance. Here are some of the main reasons we are seeing:


The main reason why insurers are not choosing a SaaS solution for IFRS 17 is related to data aspects including integration, storage, management, accessibility, or governance. If you have started your journey to IFRS 17 compliance – or any other complex regulation for that matter – you will have almost certainly come up against data challenges. With IFRS 17 specifically, the size and volume of the data, as well as the granularity and complexity of the data required to comply is significant and often comes from many different systems – actuarial and accounting for instance. The more global or siloed the insurer is, the more of a challenge data poses.

Depending on the architecture, integrating and managing data can be simpler when done within self-hosted environments. Data proximity can play a role too. In situations where there is a lot of data coming from multiple systems and flowing downstream to other systems, managing the integration process in a self-hosted environment can be a simpler and quicker approach.


Once you have your data housed, you need to be able to manage, access, and use it for reporting and analytics. Many regulations, including IFRS 17, could potentially require billions of transactions and events to be pushed between systems in small batch windows or overnight.  The data then needs to feed into downstream systems.  Knowing the data will grow over time, having the ability to quickly scale is important. Using a private cloud or on-premise deployment can give insurers more control over performance, including how quickly and efficiently the data can be pushed through the system.

Risk & Governance

Insurers, by nature, are very risk averse and hence their governance policies are very strong. Holding data in their own private cloud environment means their internal teams have complete control over aspects like security, access, and configuration. While security policies and controls such as SOC and ISO can be put in place for SaaS solutions managed via a third party, the client is still dependent on the supplier to uphold these controls. Sometimes this is not considered appropriate when a strict adherence to protocols and policies is required, especially for industries like financial services and insurance.

For some organization’s, an overall governance policy can also guide the decision between using a SaaS solution or one deployed on-premise or in a private cloud. For example, a company may require that everything be hosted by a single, strategic cloud vendor. So, whether using a private or public instance of AWS, Azure or other, they put applications and data platforms together in an effort to maintain consistent control, in line with their corporate governance policy. Essentially that means hosting anything anywhere else, (e.g. via SaaS provider) is therefore not aligned to internal governance rules.

Another approach is to split applications over two cloud instances, each from a different vendor to reduce the overall risk. For example, an organization may choose to have all core back office systems in one cloud instance and all data management systems in a different cloud instance. Again, this would tend to be a private cloud or a private instance of a public cloud rather that SaaS. The one thing any organization taking either of these approaches has in common is a very transparent and clear policy as to where systems and data should reside.

Cloud Strategy

Lastly, some organizations are further along in their cloud strategy than others. Financial Services has tended to be later to the cloud game than other industries, largely due to higher levels of scrutiny on where their data is held and managed. And perhaps because of that, the one thing they have done very well is thoroughly consider their cloud strategies in detail and then stuck to them.

Not having a holistic cloud strategy in place can lead to many siloed point solutions with no cohesive, consolidated guidelines around data governance. Putting in point SaaS solutions may work well for some organizations but for those with scaling, performance, M&A activity and regulatory reporting to consider, this can end up leading to higher overall costs, high maintenance overhead in terms of budget and resources, increased risk, and lack of consolidated infrastructure. Having a solid, cohesive cloud strategy in place can result in significant savings in infrastructure costs, especially when hosting a number of systems with one vendor.


Overall, it seems that those with a holistic, company-wide governance strategy around data management, risk management, and cloud are more likely to choose a non-SaaS solution for their regulatory compliance initiatives. I am sure there are many additional reasons and individual cases for organizations to choose a delivery model but what we have certainly seen is that for insurers, a one-size fits all SaaS solution is not the answer for IFRS 17.

As Aptitude and other software providers continue to focus on a ‘SaaS-first’ delivery model for product portfolios it is important to keep the client in mind and deliver a solution and a deployment model to fit their world, their strategy, and their business objectives.

More IFRS 17 resources visit our resource library


Back to blog

This blog post was written by:

Tristan Atkins
Read More