Velogica was one of, if not the first point of sale, instant life underwriting system, and you’ve been the technical expert behind the system from the beginning. What’s the biggest surprise to you in the way this has played out?
I thought the adoption rate of automated underwriting would rise more quickly than it did, and that the availability of instant sources of data to bring into that process would increase at a faster pace. I think the industry has hit the tipping point on both… the information available now, along with the innovative ways of analyzing it and applying it to the underwriting process will make instantly available underwriting decisions the new normal.
What are some of the unexpected benefits of automated underwriting? Unexpected challenges?
The first Velogica cases were processed in 2005. Everyone has learned so much about these programs since then that what was unexpected then seems obvious now. Two things stand out as having been unexpected at the beginning but obvious in retrospect.
On the challenge side, the degree to which distribution may attempt to manipulate an underwriting process was unexpected. As the volume of business picked up we were able to identify that sort of manipulation by analyzing the patterns of business and implement sentinel controls to protect against it.
From the benefit side, we underestimated the value of consistency in the underwriting decisions. If you give a lengthy, complex data profile to 10 underwriters you might get five different opinions. With an automated system you’ll get back the same answer for the same demographics and data profile every time.
From a systems perspective, what’s the biggest challenge in developing and maintaining a fully automated underwriting system?
There are a lot of challenges but the biggest is probably ensuring that the system is robust enough to handle unusual cases. For example, if one in a thousand cases has an unexpected value in the drivers’ license status field, we might see six of these in a single day. The logic, monitoring, and error resolution facilities must be extremely resilient. The number one concern is to ensure that there are no incorrect underwriting decisions. Close behind that is to prevent any adverse impact on downstream customer systems. So keeping the system robust while making improvements is the biggest challenge.
What are some recent upgrades? Planned upgrades?
Upgrades range from the relatively minor (enhancing scoring templates to incorporate additional applicant information as rule criteria) to the purely technical (migrating our back-end database platform) to major enhancements of underwriting requirements for use in fully underwritten programs. From our customers’ perspective, the most notable are:
- Rewritten logic supporting our reflexive questionnaire
- Added ability for traditional evidence (e.g., blood and urine lab results, APS summaries and electronic inspection reports) to be submitted to Velogica for correlation with the instantlyavailable evidence. This facilitates “triage” decisions, avoiding expensive and lengthy evidence for cases that cannot be offered at the desired premium class. It also provides underwriter efficiency, allowing them one “touch” – and not until all evidence has been acquired.
- Criminal history has been added as a new data source.
Changes in progress now include support for clinical lab histories (going live in fourth quarter with our initial rule set) and credit-based mortality scores (first half of 2018).
How do you test the effectiveness of the Velogica underwriting engine? How good an indicator are these results?
For existing programs, the underwriting can be evaluated with an experience study (just like a traditionally underwritten program). An advantage of an automated underwriting program that is data driven, though, is that you can identify and implement rule changes
early in the process (without waiting for mortality to emerge).
For changes to underwriting rules we have an extensive quality process (over 30 quality checks ranging from requirements review at the start of a new change to a post-release audit at the end), but the most protective of these is what we call our “retrospective
rescore”. For each release which touches the underwriting logic a retrospective rescore will be performed (typically on a six-month block of business).
The results of this rescore will be compared to production, and variances from the production outcome will be examined. The Product Owner and Underwriting team will examine the rescore to determine if the outcome in the rescore matches the baseline
For variances, explanation is provided as to whether the change was intentional based on the work done in the release. Unexplainable variances are investigated and resolved prior to release. It may sound like a slow process, but we’ve gotten the rescore process down to just a few days.