The role of open source code in Actuarial transformation
Open source is here to stay. The rise of open source applications, predominantly R and Python, in financial reporting processes is hard to miss. While some companies are at the experimental stage, others are looking for a strategic perspective on where, when, how and by whom the code should be built and maintained. Aside from the obvious licence fee savings, using open source code to build bespoke applications often provides an opportunity for process improvement, performance improvement, strengthened control frameworks and allows companies to incorporate their own commercial intellectual property.
Used well, open source can improve controls and automation. Vendor solutions of course have a place for many Actuarial and Finance use cases. However, where a need becomes too specific, too localised or heavy customisation of a vendor system is required, Actuaries have (sometimes too happily!) drawn on their ingenuity to build a solution, with Excel the natural tooling default.
Open source has now emerged as a strong challenger to this default as, built well, it can overcome long-standing control issues with Excel, whilst delivering an enhanced calculational capability and enabling continuous improvement and agile development.
No longer is open source the preserve of heavy statistical use cases such as assumption calibration. Its low cost, flexibility and accessibility has proven attractive for solving a host of Actuarial systems problems. Asset modelling, proxy modelling and integration/automation layers over legacy systems have been particularly fertile ground where neither vendor solutions nor Excel particularly satisfy.
In addition, when using open source for internal purposes, there is no need to re-share your code back to the open source community meaning that you can retain the IP.
In our experience, it is when controls, integrated process flow, automation and insightful management information are required alongside Actuarial calculations, that open source really comes into its own.
Open source is a key tool for transformation initiatives. Growing cloud technologies are making it easier and cheaper to create scalable, well controlled and computationally powerful processes which deliver similar functional and non-functional requirements to those of vendor solutions.
Recommended by LinkedIn
With a large community developing and maintaining open source code, open source is in effect future-proofed as new developments are continuously being released to accommodate the latest technologies. The low barriers around license restrictions also enable firms to quickly take advantage of these developments and promote innovation. This does however pose risk as individual open source developers will most likely have less stringent testing and security protocols than vendors. To mitigate this, firms need to establish a change control process around the use of third party code as well as their own open source code.
Many of the latest vendor solutions that are successfully entering the market across Actuarial and Finance are recognising the growing role of open source. Most have connectors for R and Python code, meaning R and Python code can be utilised within their solution. This is hugely powerful as it gives users the best of both solutions and allows for immediate integration, reducing effort associated with porting from one solution to another.
Furthermore, the introduction of open source code on several Actuarial exam syllabuses is also creating a scalable resource pool within the Actuarial community. This will help to alleviate key person risk of specialist system resource and help to reduce recruitment costs.
It is however organisational choices that are at the heart of sustainable success. Fast development time, flexibility and emerging practice brings with it the twin risk of complexity and impenetrable code. The main challenge we see is not so much bringing in or upskilling staff or deciding where to house them but rather the tension between building a culture where teams feel empowered to investigate and initiate change but are simultaneously bound by the structure, control and governance appropriate for regulated entities. Our view on a structured approach to successfully achieve this can be seen below.
The Actuarial teams that start now to build experience recruiting and managing teams that mix Actuaries with data and computer scientists, encourage proof of concept experiments, while establishing coding, testing and deployment standards will be best placed to take advantage of what is perhaps one of the biggest transformation opportunities available.
The views reflected in this article are the views of the author and do not necessarily reflect the views of the global EY or its member firms.
Hi James - great blog However I think that the use of open source programming environments (not applications) such as R and Python risks perpetuating and potentially exacerbating the problems of traditional actuarial modelling/programming environments (including Excel) in terms of code version control, bad coding practices, code maintenance and understanding, regression and unit tests, key person risk, insurer specific models, infrastructure integration etc. So whilst it is valid to compare costs and what the languages offer (vs proprietary modelling languages) in terms of capabilities, flexibility, code version control, scalability etc for each particular modelling exercise etc, I think that is it somewhat misleading so suggest that open source code languages address many of the issues you have raised. In all cases actuaries are building code that needs to be maintained. An alternative approach is "Analytics as a Service" in which actuaries access and use built and maintained models on hosted scalable infrastructure.
Couldn’t agree more James - great blog.
Once again James is absolutely right. the key aspect for myself is the future proofing, and don't forget that alongside that, the code is continually being improved in terms of end user utility. Personally, in my work as an Environmental professional analysing the carbon inputs of new battery technology I have used Anaconda and found it to be fast, streamlined and highly system empathetic.
Very well said!