Part 1: How to not get lost in translation

It’s a fun game to play: Type some phrase in Google Translate, turn it into another language, then translate it back to the original and see what you get. If you render “To be or not to be, that is the question” from English into Mandarin and back again, you get “Yes or no, this is the problem.” Suddenly, Hamlet’s examination of whether to kill himself and the nature of existence becomes the title of a game show.

The insurance industry faces similar language and translation issues caused by a proliferation of different data formats and schemas related to the insured, their property, and its contents, for example. Agents must capture that data, insurers rate it, reinsurance brokers structure based on that data, and reinsurers manage portfolios on it. Each entity stores and formats data in different ways - the old approaches don’t scale for the massive torrents now becoming available.  

Those different sources and uses of data help the value chain make useful or important decisions; for example, the data needed to feed a catastrophe model is different from that needed to inform an accounting ledger, which in turn is different from that needed to drive the claims process.

But while having a specific format for each specific application makes that individual application or section of the value chain more efficient locally, in a broader context having a proliferation of formats and schema is severely inhibiting the insurance industry’s necessary and urgent modernization. Some of the consequences  include:

• Bad Translation: The simple act of having one insurance process talk to another (say accounting talking to claims) often involves conversion between different data formats and standards. This is time-consuming, sometimes confusing, and often leads to a lack of fidelity or extensive and unnecessary costs. Like the aforementioned example, information is simply lost in translation.
• Lack of Completeness: Having different versions or formats of data from the same insured leaves us in the same situation as the parable of the blind men and the elephant: each process (claims, accounting, modeling) describes part of the whole, but creating a complete view is virtually impossible. Additionally, brokers and insurers often can’t view information about a single insured holistically across multiple lines.
• Not Extensible: Data formats and schema are fixed at a moment in time. If, for example, a new item of data is captured by an agent, incorporating that in all the various formats and schema is a tremendous amount of work; databases have to be changed, software needs to be re-coded, processes may alter. Today’s ecosystem is too rigid and slow to adapt sufficiently.

At QOMPLX, we firmly believe that an insurance-specific language for encoding information about insureds, coverage, and even portfolios of risks will enable the accurate and complete exchange of insurance information. That does not mean that, for a specific use, parts of the “‘chapter”’ describing an insurance risk cannot be taken out used in a specific format or schema to drive a catastrophe model, or accounting software. But, with a language and formal ontology for encapsulating an insurance risk, we can describe the whole elephant and not just the trunk or the tail.

Other financial service industries have solved this problem through the use of domain-specific languages. These languages provide a common way for entities to swap data and information. Three examples are:

1. SWIFT. The Society for Worldwide Interbank Financial Telecommunication (SWIFT), provides a network that enables financial institutions worldwide to send and receive information about financial transactions. Moreover, SWIFT has become the industry standard for syntax in financial messages. Messages formatted to SWIFT standards can be read by, and processed by, many well-known financial processing systems, regardless whether the message traveled over the SWIFT network.
2. FpML. FpML (Financial products Markup Language) is the open source XML standard for electronic dealing and processing of OTC derivatives. It establishes the industry protocol for sharing information on, and dealing in, financial derivatives and structured products. The standard was developed under the auspices of ISDA (International Swaps and Derivatives Association), using the ISDA derivatives documentation as the basis.
3. LexiFi/MLFi. LexiFi has developed a language, MLFi, to describe financial contracts that can be used to describe all structured products and derivatives, from the simplest to the most complex which emerged from well founded academic and commercial research to improve interoperability and consistency - improving marketplace performance and accuracy for all parties.
   

A language for declaring insurance contracts, risk transfer, and exposures differs from current data formats and schema-based approaches to limited interoperability in fundamental ways:

• Flexible: A language that can be used to write The Cat In the Hat can also be used to write War and Peace. A language can adapt to describe a policy term, an element of exposure, or a claim outcome in a structured syntax that can allow both humans and machines to reason about the encoded knowledge.
• Translatable: Whether you have read the words “The sky above the port was the color of television, tuned to a dead channel” before, you understand what they mean. So long as the structure of the language and the vocabulary is understood, anything expressed in that language can be understood. An unfamiliar or brand new policy term can be understood if it is represented in the language correctly.
• Extensible: If a word doesn’t exist, it can be invented without completely rewriting the language. Before Shakespeare invented them, the words addiction, eventful, and inaudible, among many others, didn’t exist. Likewise, if we need to describe a hitherto unseen property characteristic, the means to describe it can simply be added to the language specification (either by modifying the lexicon or a conceptual construct).  
  

“Words - so innocent and powerless as they are, as standing in a dictionary, how potent for good and evil they become in the hands of one who knows how to combine them.” - Nathaniel Hawthorne

In part 2, we’ll describe just how we built our own insurance-specific language to support the underwriting of cyber and terror risk.