Reinsurance is simple in principle. The goal is for the underwriter to share the risks and premiums of the policies it writes with other underwriters. By spreading the risk around, the damages of a very large claim have limited impact on any one insurance company, and the policy holders can be assured that their claims will be paid in full.
The process of reinsurance involves a primary underwriter entering into reinsurance “treaties” with other underwriters. These treaties have complex terms describing how the primary insurer will share costs and premiums with the other insurers. Sounds simple, but things get complicated fast. First, the other end of a treaty may not be another insurer but rather another treaty that may connect to yet more treaties and eventually to other insurers. This can make it extremely difficult to calculate the effects of any one treaty. Second, the business people who define these treaties can be quite creative in inventing new terms, and their expectation is that the IT systems will quickly implement whatever they come up with, after the fact.
The purpose of the reinsurance sub-ledger application is to calculate the total costs and premiums that are to be shared with each reinsurance partner, as well as to determine profitability for the business people who create and sell the treaties. It is essential that everything be line-item accountable and traceable; otherwise, the reinsurance partners may deny claims made to them.
The story at this industry-leading insurance company is a common one in the industry. They had attempted to build their reinsurance sub-ledger application more than once using standard coding technology and large teams of developers. These were hugely expensive and time-consuming undertakings, and each time, the number and complexity of the rules foiled the project. Each time, the development team had difficulty implementing, testing, and verifying the complex rules using standard coding. Their productivity was insufficient not only to build the application but also to keep up with new rules coming from the business (after all, the business didn’t stop while the app was being built). Inevitably, the project would be canceled and the business team would go back to using spreadsheets and manual labor. It was a disaster.
Finally, a senior VP stuck his neck out and said, “I can get this done with Ab Initio.” Given the company’s history with other technologies, this was a bold undertaking. Normally, a project of this nature could take a large team of developers anywhere from 5 to 7 years to implement. In this instance, the customer put together a team of developers, much smaller this time, and Ab Initio provided 2 consultants.
Ab Initio projects often go beyond conventional limits when it comes to data volumes, transaction rates and interoperability. In this case, the volumes were very modest (even the largest insurance companies don’t process that many claims), and all the data was straightforward and readily available. The challenge was dealing with the large number of rules and their complexity, and dealing with business requirements that were changing dynamically. High productivity and complexity management are key Ab Initio strengths that were vital on this project.
The project lasted just 18 months, during which the team implemented and tested about 15,000 rules. Critical to the success of the project, and an ongoing business requirement, is Ab Initio’s ability to graphically trace logical computations from final results all the way back to the original inputs. In this way, all the results are auditable – if in doubt, the users can display all logic that the data went through with a click. The application finally gives full itemization on all information going through all the treaties. Now, when a bill is submitted to a reinsurance partner, there are no more questions about what has to be paid. No more spreadsheets and no more manual work.
The gentleman who stuck out his neck still has his head on his shoulders... and even a new title to show for his efforts.