Analysing the Impact of Automated Straight Through Processing on Time to Resolution in Life Insurance

Abstract

Although Straight-Through Processing (STP) has been adopted in many U.S. Life Insurance claim departments to decrease Time to Resolution (TTR), increase throughput, and reduce manual processes involved in resolving claims, most studies have reported only a reduction in TTR while failing to address the potential effects of the database and/or the processing substrate involved in these systems. This paper will present a reproducible substrate-resident decomposition technique to decompose TTR into four distinct operational stages: Intake-to-Staging Latency, Staging-to-Decisions Feature Build Latency, Decisions-to-Payment Batch Window Latency, Payment-to-System-of-Record Reconciliation Latency. The authors will implement this technique in PL/SQL to ensure the ability to make comparisons between two different substrates (IBM DB2 LUW and Oracle 19c). A synthetic first notice of loss (FNOL) to the payment pipeline consisting of 50,000 death benefit claims will be used as the basis of our benchmarking. We will also test the effect of varying the size of our data-replication latency via the use of varying sizes of replication windows (1 minute, 5 minutes, and 15 minutes) provided by Qlik. In addition, we will vary the frequency at which payments are scheduled through the use of hourly, four-hour, and end-of-day batch modes. Our results indicate that when compared to the manual process (baseline), the average TTR can be decreased by up to 71% using STP. However, a stage-by-stage analysis indicates that only 4% of the total TTR can be attributed to the latency associated with making decisions using artificial intelligence. On the other hand, approximately 78% of the TTR is due to either the time it takes for the claimant's data to be replicated and available for use or waiting for enough claims to be processed so they can be paid. Finally, the remaining 18% of the TTR is due to the time required for the system-of-record to reconcile the payment information. Additionally, moving from an end-of-day batch mode to an hourly batch mode resulted in an additional 28% reduction in TTR without affecting the decision layer. Finally, as expected, we found that there were no significant differences in timing between DB2 and Oracle with respect to each of the stages. Therefore, we conclude that, unlike what many researchers have concluded, in realistic life insurance STP implementations, much of the remaining TTR after STP is implemented is caused by delays related to replicating data and batching payments as opposed to delays related to how quickly one can decide whether to pay a claim.