Timing is everything: Lessons from the intersection of insurance and technology
By Corey Forrieter, Lead Software Developer, Apollo Insurance
It might sound like an understatement to say that insurance has been around for a long time, but compare it with how long digital technology has been around and it would look like a peanut next to an elephant.
As with any institution that has withstood the test of time, insurance has developed a defined process for accomplishing certain tasks, and there are very specific ways that things are done. There are certain processes in place that, for good or bad, have to be accounted for.
As Apollo’s lead software developer, it’s my job to transfer those analog processes — many of them firmly ingrained — to a digital interface. Our platform is able to quote, bind, and issue policy documents on behalf of the broker, completely digitally and in real-time. That is a complex process, and when problems come up, my team has to be able to respond quickly.
Of course, that’s common in any industry. What’s important for my team is that when that work is done and that problem is solved, that it is solved forever. Every process we have has to be scalable and repeatable. The principle is applied across every application to get maximum efficiency. We never want to solve that problem again.
This is a common sentiment in programming, but less common in the world of insurance. As with any digital translation, some problems are only revealed through use and testing.
Here are two interesting glitches we found in the platform, how we found them, and how we fixed them — forever.
When in the world?
What day is May 1st? Well, it really depends. When the platform was built, the date picker tool that the insured uses to select their coverage date to begin was set up to record a full timestamp of the transaction, including the date and the time. By default — and this is common in programming — when you save timestamps, you use a UTC format so that it’s consistent. (UTC is basically the same thing as GMT, or Greenwich Mean Time). The reason for that is because the end user’s time is going to be different depending on what region they’re in, but the system typically needs to know exactly when something happens, regardless of what timezone it happens in.
Initially, I didn’t question that. If a policy is being sold as coverage for an entire year, that’s great — we now know exactly when that year is over, down to the second. What I did modify, for consistency, was the actual timestamp itself. We made each one automatically set to 07:00 UTC.
That’s not a bad solution — as long as every policy is sold generally within the same time zone, or at least on the same side of the International Date Line.
Then, someone on the other side of the world bought a policy. For two dollars.
When we first saw what had happened, we weren’t exactly sure how it was possible. This particular insurance product had a fixed renewal date of May 1. We had done extensive testing on the date selection beforehand, making sure the user was unable to pick any date before May 1, so it didn’t make sense to us that anyone would be able to pick April 30. And yet, there it was: a policy starting April 30 and ending May 1 of the same year. A two-dollar policy.
We launched an investigation to find the reason.
The debugging process always starts with trying to reproduce the issue, otherwise there’s really no way to confirm you’ve fixed anything. The timezone idea was a hunch of mine — I have enough experience to know that time zones are generally the root of all problems when you’re dealing with time.
Sure enough, by changing my time zone I was able to reproduce the problem.
In a way, it was a relief to know it was a completely different edge case than we had initially feared, there was no way for the user to select April 30 themselves.
This was an easy fix: eliminate the timestamp entirely. We simply save the date, and the date picker tool uses the user’s local date. This way, even if you’re past the Date Line, it doesn’t matter, because the only thing the system saves is whatever date the user has picked.
The data is less precise, but since we don’t actually need to know the time, that was a bit of over engineering to begin with.
The leap year problem
When the system was set up, someone had made the assumption that policies would be valid for 365 days. It would take the effective date and add 365 days to that, and that was the policy end date. Seems simple enough, right?
There’s just one small problem with that, a bug in the Julian calendar known as the leap year — like the one occurring next year in 2020 — actually has 366 days.
(I maintain that the main problem here is actually the insurance industry standard for calculating a year as opposed to how a year actually works, but I’ll get into that later.)
Once a policy was purchased that extended over February 29, 2020 (the extra day in next year’s leap year), the computer counted 365 days, expiring the policy a day shorter than expected.
This was a pretty easy fix. We simply adjusted the system so that instead of counting a certain number of days ahead, it matches the date to the same day of the next year.
One argument I would make is that technically, on a leap year, the insured is paying the same amount of money, but getting an extra day of coverage for free. So in terms of business, we’re losing out on the value of that one extra day of premium. So ultimately, in light of that, I think the computer was right to begin with.
Solving a problem once and for all
Throughout my career as a developer, I’ve had a lot of experience dealing with date edge cases and timezones, so these problems were relatively easy to find and solve. The point of running through these problems is to illustrate that once a problem is solved in development, it’s really solved. The key is to make sure you’re solving the right problem.
In the case of the timezone problem, we had actually anticipated this problem by setting the timestamp at the beginning of the day. Our thought process was: this will resolve the issue of someone buying insurance from anywhere in Canada.
But this half-measure didn’t resolve the global problem of what happens if the user is in a completely different date at that point of time when it gets converted back. Now that that larger problem is solved, there’s no more edge cases with timestamps, we just removed the timestamp complexity entirely out of the equation.
The same is true of the leap year problem. Now the system adds a year to each policy, no matter what. But rather than adding a year’s amount of days to the policy, we simply add a year to the date, and it’s done. It’s a very small difference, but an important one. And until we are able to change the foundations of how the centuries-old insurance industry approaches leap years, this is a solid fix.
About the Author
Corey Forrieter is Lead Software Developer at Apollo Insurance. He is a full stack developer with a passion for writing beautiful code. Coming from a background in the high volume world of AdTech, he has a history of building projects designed to scale and loves turning business ideas into working products.
About Apollo Exchange
Apollo Exchange is a free eCommerce marketplace that enables brokers to instantly bind insurance products. For more information, or to sign up today and start selling insurance online, please visit xe.apollocover.com.