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 schema 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 massive torrents of data in different ways.  

Those different approaches help insurers make useful 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 a specific application makes that application more efficient, in a broader context having a proliferation of formats and schema is only inhibiting the insurance industry. Some of the consequences may 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. Like the example at the top, 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.
• 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.

At QOMPLX, we firmly believe that an insurance-specific language 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 encapsulating an insurance risk, we can describe the whole elephant and not just the trunk.

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.
   

A language differs from formats and schema 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. With the right syntax, anything can be described accurately.
• 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 word to describe it can simply be added to the vocabulary.  
  

“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.