The eccentricities of the London insurance market are well known to policyholders. When things are working smoothly, policyholders may not see much of a difference between a London Market policy and one issued by a U.S.-based insurer. Claims are submitted, and once agreed, paid by the London Market insurers, typically in one check. However, insolvencies, run-offs, schemes of arrangement, and corporate transactions have led to fractured dealings when attempting recovery from older London Market policies. Policyholders typically end up trying to recover from a number of different companies under each policy.

Therefore, responsible policyholders must understand who is responsible for which pieces of their London Market portfolio. A $5 million policy is only worth $5 million if the insurer whose name is on the policy can pay; a $5 million London Market policy is only worth what the solvent and active participants can pay. Each policy could have dozens of participants taking different shares for each year of a policy.

If you’ve read the previous posts in this series, you can guess what comes next: a relational database.

In Part 3 of this series, we built a robust policy database structure and created a unique identifying number for each policy and period of a policy. In our London Market tables, we will want to capture these data points as foreign keys to create a link between these and the policy tables. This will allow us to link any other policy-level information, such as limits, dates, language, provision values, hyperlinks to electronic policy documents, etc., to each relevant London Market participant. Like with insurance companies, it is prudent to store our unique London Market participant company names and solvency status in a separate table to ensure consistency. Policyholders should also strongly consider capturing underwriting agencies and pools, reference numbers, and stamp information, as these can be necessary when submitting claims to schemes of arrangement.

Reviewing London Market policies can involve long hours attempting to decipher handwritten documents; capturing the necessary information correctly the first time can save policyholders the headache and expense of going back through the policies all over again. In our final post of this series, we’ll explore why policy exhaustion is best tracked in a relational database and how to extract the most useful data from loss runs.

How do you prefer to track London Market participation in your policies? What issues have you encountered with putting the data to use?