Last September the CAS issued its members a challenge: Use your actuarial skills to develop novel risk engineering solutions. The CAS Hacktuary Challenge entrants had to create an end-user application that would be actuarially grounded but address relevant risk management problems for the typical consumer. Another requirement of the contest was that all application code be made publicly available on the CAS’s GitHub site.
Because the quality of the submissions was so outstanding, the selection panel chose to award the prize to two submitters, Caesar Balona and Michaël Bordeleau-Tassile, FCAS, who will split the cash prize of $15,000 equally.
Balona’s Risky Router allows users to enter start and destination points for a driving route that shows just how risky that path is. The estimate changes based on weather conditions, time of day, year of the car, whether the driver is impaired and other factors.
Bordeleau-Tassile’s entry, Consumer Vehicle Toolkit, compares the insurance costs of cars by make, model, color and other aspects to help the user decide which car they should buy next. In addition, it shows the places in Toronto and Montréal with the highest likelihood of vehicle collision and theft. Finally, it illustrates the way that time of year, time of day, road surface and other considerations add to the risk of vehicular accidents.
CAS Research Actuary, Brian Fannin, ACAS, interviewed each of the winners to learn more. Also, see AR Web Exclusives for Fannin’s talk with the winners and demonstrations of their apps.
Brian Fannin: How did you come up with your idea for the app?
Caesar Balona: I had heard of a delivery company that developed their GPS routing software to prioritize left turns (when driving on left hand side) to reduce time spent waiting at traffic lights. The additional consequence of this was reduced vehicle accidents, as the vehicles were crossing oncoming traffic less. I liked the idea and thought, “what if we could extend this to avoid high frequency accident areas as well?” From there, I naturally extended the idea to include assessments of severity and the impact of other factors such as weather and time of day.
Michaël Bordeleau-Tassile, FCAS: The challenge had a large scope — “Use open data, be interactive and be relevant to auto insurance.” To be honest, I initially had a heavy blank page syndrome and felt caught up in a mental Catch-22. It’s difficult to come up with an idea when you don’t know what data is available. On the other hand, it’s difficult to find relevant data when you don’t know what your end goal is.
To get things rolling, I tackled both simultaneously for a couple of weeks, browsing the internet for data until I settled on this idea: to create an app that would help the user along its vehicle relationship cycle, mainly the shopping and driving.
Fannin: How do you hope that a consumer will use your app?
Balona: Initially I hope they will just use it to understand the risks of driving, which I think are often underestimated. We all think we are better than the average driver, but hopefully some cold hard stats can convince us otherwise. Consumers could use the app to convince themselves to alter their behavior by travelling at safer times, reducing speed in the rain or opting for safer transport. Outside of the general consumer, I hope the app generates thought and ideas on how to use data to improve road safety.
Bordeleau-Tassile: The shopping tool will help consumers consider vehicles that weren’t on their shopping lists. It will help differentiate among various key elements. Who actually looks at insurance costs before purchasing a vehicle? It’s not something that is readily available without filling out multiple insurance quotes. The driving tool will help consumers plan their itinerary and assess the various risks involved with driving and parking.
Either my app replaces Google Maps, or Google Maps gets inspired and integrates risk assessments as a layer. Am I hearing royalties?
Fannin: What do you want an actuary to learn from using your app?
Balona: I’d like to demonstrate how the power of programming and other software skills can be used to enhance actuarial work and broaden our impact. Essentially the app takes an actuarial idea (frequency and severity of road accidents, typically used in insurance pricing) and couples it with modern ways of displaying and interacting with data. So, our pricing ideas are not only useful for understanding the premium of a policy but can be used in other ways. I’d also like actuaries to learn to branch outside of Excel or traditional software. This type of analysis and app is simply not possible in Excel, and the data work would be extremely difficult and time consuming. Further, I hope the way I have structured the work, and the technologies used, can demonstrate how we should be structuring our work to maximize efficiency and reduce error. It is certainly not the best way to do it (given the time constraints), but it is one of many examples.
We all think we are better than the average driver, but hopefully some cold hard stats can convince us otherwise.
Bordeleau-Tassile: About generalized linear model (GLM) pricing algorithms, I find that we often put in limited effort into integrating interactions. My shopping tool calculates vehicle affinity based on a broad population. Would affinity concepts perform well as an interaction proxy in a GLM? That’s something I’d love to see results from.
On the itinerary risk assessment, the last decade has seen significant sophistication with the rise of telematics. However, I believe more can be done besides the standard braking, acceleration, speeding, etc. How about we integrate collision heat maps, road geometry, configuration, lighting, weather patterns?
Fannin: Where did you learn the skills you used to create the app?
Balona: Outside of the actuarial knowledge, I learned programming, web development, web hosting and deployment skills by working on many similar projects over several years. I would have an idea in my head, then I would research what I need to know to build it, then I would learn those skills. For example, to learn web development, I’d start with watching YouTube videos of someone developing a website, then I’d read a few books on the technologies they used, then I would start trying it out and building a website myself. That last part is the hardest part and where most of the magic sits. I’d spend countless hours building, encountering problems, researching how to solve them and then continuing. It is not quick or easy, but that’s how you learn to do it, by doing it.
Bordeleau-Tassile: For more than a decade, I had been working in home and auto insurance, using proprietary software for both data preparation (VBA/SAS) and modeling (Emblem). Being part of an R&D team, I was fascinated by my colleagues’ various projects. In 2020 I embarked on a journey to self-learn the open-source R programming language and use machine learning algorithms.
The spark came from an insurance pricing competition hosted by aicrowd.com (similar to kaggle). I did finish in the top participants as a prize-winner. I then repeated my success story in a similar machine learning competition, related to detecting Alzheimer’s disease. Both accomplishments were the result of my curiosity, ingenuity, love for innovation and strong self-taught capacities. Then came this Hacktuary challenge where I saw the opportunity to develop new skills.
Actuaries should use technology to better deliver results.
As far as website building goes, I had basic HTML knowledge from the 1990s. (Is my GeoCities website still up? Ha ha!)
Throughout the challenge, I taught myself (lots of trial and error!) on Shiny [an R package] that can build interactive web apps straight from R.
Fannin: What are some of the best ways that actuaries could use technology to improve their work product?
Balona: The most immediate benefits are increased efficiency and reduced errors. Writing scripts to perform repetitive manual work saves hours and reduces human error. This allows actuaries to focus on more important work. This naturally feeds into improved quality. How many times have you wanted to do some great, interesting, and valuable additional analysis, but there simply is no time because the data process is so time consuming and cumbersome? If you could take your data work from two weeks to two hours, you now have two weeks extra to add value. These opportunities exist everywhere, and they become more apparent the more you apply technology. Further, if you find an error in your work the day before the deadline, with a well put together process using the right technologies, means you can run the full analysis again in hours, instead of having to find a sub-optimal workaround because the process is too time consuming to fix.
Bordeleau-Tassile: Actuaries should use technology to automate stuff. We all make mistakes, and manipulating spreadsheets might be the biggest source of mistakes. Actuaries should use technology to better deliver results. From interactive dashboards to enhanced model explainability, I find actuaries sometimes struggle when near the finish line of an analysis.
Fannin: What barriers, if any, exist in the use of technology and what can actuaries and their employers do to overcome them?
Balona: I think the biggest barrier is time. Often actuaries simply don’t have time to learn new technologies, especially students who are still balancing work with their primary studies. If employers could provide actuaries with uninhibited time to explore and learn these technologies, then I think we would see a lot more actuaries take them up. Few people have the luxury of having enough free time, or even energy, to pick up these skills after hours or on weekends, after a busy week of work, or after needing to care for families, or study, etc. Before I worked in a data science-focused role, all my learning was done at night and on weekends. As soon as data science became part of my role, the pace of my learning increased greatly. If employers can offer a percentage of each week to spend on learning new technologies, I think this will certainly help.
Bordeleau-Tassile: Actuaries are often met with a dismissal from IT security. The discussion should pivot into a dialogue where both parties understand the concerns of each other and have both parties work towards a common goal.