The Federated Data Model
By Adrian Rands, Chairman, Quantemplate
Download the article
A federated data model can efficiently bring together disparate data across all delegated authorities, and unify the information from multiple risk, exposure and claims bordereaux into the ultimate, consistent data format.

Coverholders have long been a critical component of the London market’s business strategy, but underwriting through delegated authority is not without challenges. Perhaps the greatest is the acquisition of data. Under the Solvency II regime, detailed exposure calculations are essential, but the longstanding bordereaux system is struggling to provide sufficient granularity in a consumable format.

The London Market Group (LMG) has therefore made straight-through processing for delegated authority underwriting a priority and has begun to work on a solution, but so far its attempts have not provided the panacea desired. However, a solution exists which can unlock this critical exposure information.
Enter the federated model
A federated data model can efficiently bring together disparate data across all delegated authorities, and unify the information from multiple risk, exposure and claims bordereaux into the ultimate, consistent data format. It can then be harnessed for company-level or central analysis. The cost, learning curve and daily effort involved are minimal, the data reconfiguration automated and the lag between original input on primary systems and population of the central database measured in seconds.

Solutions adopting this model have already been designed and implemented. Aegon Group is a €36bn ($40.16bn) multinational composite insurance business. Its group reinsurance company underwrites quota-share and excess-of-loss treaties for group subsidiaries, comprising numerous independent companies brought into the Aegon fold over decades of organic and acquisitive growth.

Each subsidiary possesses a unique information system and structure employing its own data standards. A federated model allows the company effortlessly to combine the risk information generated from the full range of group companies underwriting life, property/casualty, commercial and consumer covers.

Aegon’s structure – and its consequent information challenge – are remarkably similar to that faced by London companies and syndicates, which source business from diverse agencies. On a macro level, the challenge matches that faced by the London market.

Aegon, like its London parallels, had two choices: change the underlying systems of its subsidiary companies (a costly, high-risk solution which would have taken years) or centrally harmonise the disparate datasets. The selected alternative was achieved in just six months, creating an invaluable additional central resource.

For London and Lloyd’s, at the market level, adopting any solution is more complicated. Central bodies desire a central service, but have no concrete rights over data, and cannot force action. Businesses within the market possess vastly different resources, and pursue incompatible business strategies. The level of control they wish to hand off may be entire or entirely limited. A federated data model provides the solution. Data from divergent systems is imported and reconfigured – without rekeying – according to the schema used by the data recipient.

In the case of the syndicates this schema is defined by their internal exposure data warehouse. For Lloyd’s and the Prudential Regulation Authority the schemas are defined by the class specific data schemas drafted by the Target Operating Model (TOM) committee.

In a federated data model the syndicate schema and TOM class schema may be one and the same, but all importantly they do not need to be as the transform takes place at the point of communication between the data provider and recipient. This is a highly flexible and hence incredibly effective method for achieving convergence of data formats as data is harmonised into the correct, usable format at each node in the data network. It is fed into the centrally managed meta-database and updated in real time.

Delegated Authority Entity Relationships and movement of data
The web-based system is completely scalable and almost effortless to maintain. It is secure, since access to individual data blocks is controlled. Perhaps most importantly, it requires no-one to change their existing policy and claims administration systems.

At the core of the federated model is a high-performance, expandable, “private cloud” architecture which provides a single system for the London market. It can house as many tenants as demand requires. It delivers controlled but instant data availability, rapid processing speeds and massive capacity. Users can converse with the data, and among themselves within the closed system. To ensure all the data joins, mapping and transforms are correct for both data sender and recipient.

Federated model, meet TOM
In a recent briefing entitled Delegated authority straight-through processing, the LMG’s TOM initiative set out five objectives and five strategies to meet them:

TOM objective
What the federated model offers
To tackle the lack of consistency in processes and data requirements across the London market
The model’s standard schema accomplishes this by harmonising disparate data structures, without the need for intervention in existing underwriting processes
To meet the growing need for more detailed and timely information, fuelling improved management and reporting
A federated model, incorporating straight-through processing, accomplishes this through real-time updating. As soon as data is entered into the source system, it can be interrogated at any time by anyone with access to the specific data in question, to produce a tailored output
To streamline processes to drive out costs and make it easier to work with London
The implementation and maintenance costs are low as the communications and transformations are conducted by the agent and underwriter who have intimate knowledge of their data and systems
To improve the timeliness, quality, and availability of management information
A federated model ensures all data is available from inception in a single, understandable place and can be manipulated to meet any end
To address the lack of a centralised London data system
A centrally managed federated model is the answer, but it meets the objectives without forcing market companies to adopt new systems, sign up to costly new physical infrastructure, or change the way they operate
TOM’s strategies to achieve these objectives are met by a federated model. TOM seeks: one-touch data entry at the coverholders; consistent data requirements; more frequent submissions from coverholders, removing the need for monthly bordereaux; tools for market participants creating a single, central place in London to submit data, with the templates and standard processes that allow companies to continue to use their own systems; and central London data services to ensure that underwriters, exposure and claims managers, and those responsible for tax and regulatory reporting have access to data. The federated data model has it covered.

Implementing a federated data model will not be effortless but its collaborative framework will enable rapid adoption. Each underwriter and bordereaux manager will have the ability to transform the data to the recipient’s format with coverholder and underwriter working together to this end.

This is the beauty of a crowdsourced solution and in this case harnessing the power of the 3,941-strong Lloyd’s network of coverholders and syndicates with the goal of reducing to zero any errors in the data translation process. This approach shares the workload, and as “many hands make light work”, the harmonised dataset will be reached fast, as is the way of internet-powered solutions. Some costs will be involved, but they will be much lower than creating a new physical central infrastructure and much less than the cost of imposing a new system on every risk carrier and coverholder in the market.

The federated model is no Kinnect. Lloyd’s ill-fated electronic trading platform can be summed up by its single fateful flaw: it did not make anyone’s job easier. A federated data model makes life easier for everyone. The approach is tried and tested. It can be implemented rapidly, deployed with relative ease and the inevitable wrinkles ironed out very swiftly. This is the occasion to embrace innovation.
The Federated
Data Model
Taming the complexity of
regulatory reporting
Insurance models
for the technology age
Understanding changing
distribution channels
Making each business
line count
Brokers as
risk consultants
Four steps to
data-driven reinsurance
Portfolio steering
in the soft cycle
What is
responsive reserving?
The price is tight,
but is it right?
Improving data capture
through collaboration