Need for a Dedicated Coding Language
Updated: Feb 1
Why Actuaries Need a Unified, Dedicated Programming Language
By Barak Bercovitz, Atidot Co-Founder & CTO
Insurance is rooted in data innovation. Wide swaths of modern statistics and probability were first devised to accurately price, predict and manage risk. But insurance’s pioneering position has faltered in recent years.
While today’s economy is ablaze with revolutionary advancements in big data and computation, the insurance industry has been uneven in its adoption and application of cutting-edge data technologies. One study found that just 20 percent of the data collected by insurance companies is usable for strategic analysis. Current attempts to incorporate big data and machine learning into insurance products tend to occur on an in-house and ad-hoc basis.
High financial stakes and strict regulations already complicate big data adoption, but beyond that, the lack of a formalized system or computer language for interfacing with the available tools, technologies and data can prove one of the biggest obstacles to progress. This is why the life insurance industry as a whole, and actuaries, in particular, are in dire need of their own unified, dedicated programming language. As the CTO of a startup working with big life insurance companies, my team recognized this pressing need and committed ourselves to authoring an insurance and actuary focused programming language to help fill the gap.
To understand the distinct challenges of applying technical innovations to the insurance industry, it is essential to first peel back the complex layers behind computer applications in general. Computers have come a long way since their earliest days as room-sized mainframes with punch-card readouts. But at their core, all modern computers still reflect this legacy, hard-wired roots. Graphical interfaces and polished applications might make today’s computers more user-friendly, but every action and instruction must still be translated and abstracted into binary machine code in order to be computed on.
Now, this is not to say that developers sit typing their code as zeroes and ones. Rather, modern programming languages use their own, distinct shorthand, which is then compiled into code readable by hardware. However, the particular output logic required varies by computer architecture. GPUs operate differently than CPUs, which operate differently than cloud computing frameworks. Therefore, the trend has been to author general purpose languages (GPL) that focus on accommodating the widest range of uses to a particular machine or architecture. Instead of optimizing for a specific problem or use-case, GPLs ask the programmer to learn a new language and apply it to their given domain.
While this complicates developing specialty applications of any kind, the unique contours of the life insurance industry add an additional layer of difficulty. Regulations governing insurance are among the strictest and most byzantine of any industry. And beyond the issues of compliance come the extraordinary financial and social stakes riding on the integrity of insurance products. Core pillars of the private and public sector are propped up by the accurate, reliable management of risk. Insurance models running on shaky code could turn a tiny software bug into tens of millions in losses, the eventuality of which is only amplified by the enormous complexity of accurately calculating risk five, 10 or even 25 years into the future.
Seeing these issues firsthand inspired development of the Atidot LIA (Language for Insurance and Actuaries). What my team and I realized when approaching this challenge was that what initially looked like one problem was actually three distinct but interrelated issues.
The first issue was the substantial technical demands of carrying out the tasks actuaries would demand of big data. Cleaning and anonymizing raw data, modeling it properly, testing and executing on a laptop or workstation and ensuring all code passed formal verification – these intricate operations would be a baseline requirement of any function.
After addressing the fundamental complexity of insurance operations, the next issue was simplifying the syntax and optimizing legibility for domain experts who might not be professional developers. By building in insurance-specific entities, data models and analytics models for several use-cases, LIA allows actuaries to speak the language of insurance instead of memorizing the arbitrary variables of Python, Visual Basic, or C++.
Lastly, the unification of all necessary functionality into a syntactically legible framework would enable frictionless integration with machine learning models and accelerate time-to-market for new actuarial products. In other words, it would allow actuaries to write, debug and deploy big data in terms they could easily understand. Harmonizing function and syntax would help resolve some of the major roadblocks facing data integration.
The current tension between the enormous promise of big data for the life insurance industry and the difficulty of developing dedicated software contribute to a compromise worse than the sum of its downsides. Today, actuaries looking to incorporate big data or machine learning are forced to cobble together homegrown solutions using a patchwork of languages and tools. Otherwise, they must rely on dedicated developers who lack the domain expertise to fluently translate actuarial needs into proper code. This disconnect creates friction and stilts progress.
However, by empowering actuaries to translate their domain expertise into instructions usable by cutting-edge technologies, a dedicated programming language will help align the existing talent in the industry with the untapped potential of data innovation. Modeling insurance is increasingly becoming a multi-disciplinary challenge, and a more precise, specialized programming language will help foster collaboration and jump-start innovation. In other words, our vision is to help big data and life insurance finally speak the same language