Thoughts on the usage of API’s for

Commercial Insurance Transactions

T​ he abbreviation “API” has entered the insurance lexicon

which has resulted in critical decisions/investment choices
within companies. An Application programming interface (API)
is merely an integration method that allows a client (some
computer program) to use the services (functions) of the other
program. There is no magic, but yet that’s the magic.

I first cut my teeth on the notion of API integrations during my

software development days using CORBA Remote Programming
Calls (RPC) and Distributed Component Object Model (DCOM)
technology to build solutions. While the programming was
somewhat tedious and challenging at times, it was very cool when
it worked but always challenging when it did not work, especially
when the service interface contractor behavior changed. I still
remember arguments over early vs. late binding. I could end
writing here, but as always, I have more to say.

It is likely that the company that defines the API standard for
executing commercial insurance will have a competitive
advantage.

The race is on, but it’s slow​.

Why aren’t API strategies effectively used in the
insurance industry?

W​ ell, ​Conway’s law​ provides some insight, he states

“Organizations which design systems are constrained to produce
designs which are copies of the communication structures of
these organizations.” The implication is that the software
architecture will be a function of the organization structure.
Conway’s law bounds the systems, vendors, and designs we see
within insurance companies.

It sounds dismal, but there is hope.

I believe that Satya Nardella provides some fascinating insight

that is appropriate here. He said “​To truly get the best impact
from our efforts, we will have to push ourselves to transcend
Conway’s law. Having a deep sense of customers’ unmet and
unarticulated needs must drive our innovation. We can’t let any
organizational boundaries get in the way of innovation for our
customers. This is why a growth mindset culture matters​.”

So the challenge remains, are we going to be servants to Conway’s

law or will we seek to get to the boundaries of the constraints and
break out.
I​ have heard a lot of reasons and some poor excuses over the
years as to why one shouldn’t pursue an API driven strategy in
the commercial insurance sector. Generally speaking, the
Property and Casualty sector as slow adopters of technology;
however it is changing given the rise of insuretech investment
and other entrants in the market. I have summarized some of the
comment reasons not to pursue an API driven approach below

● It’s too difficult

● Legacy Systems
● Completeness
● Vendor complicity in maintaining complexity.

Let’s explore these issues using three parties in a market place,

two insurers and a major trading partner (broker)

● LetsTryCo ​is​ ​a mid-size P&C insurance company that

has a legacy system that supports the entire insurance
underwriting life cycle. They realize that they have to
retire the legacy system but chooses to build out an API
named LetAPITransact that integrates with the legacy
core before executing a migration strategy. They believe
that this approach will allow them to support the new
digital era while reducing the technical debt of the legacy
platform over time. The API is well documented and has a
test website with the necessary code generation tools for
users of the API’s
 ● NoTryCo ​is roughly the same size as LetsTryCo and also
has a legacy platform. However, their strategy is to
migrate to a modern platform first and then build out an
API’s based on what partners need. They also feel that the
new platform will provide a competitive advantage in the
market place.
● MiddleCo​ is a significant trading partner of both firms
and is frustrated by the turnaround time from both
companies on quotation, booking transactions and the
quality of policy documents. They are looking to scale up
the policy counts and premium but fully realize that the
scaling up the operation can’t result in significant staff
additions.

With these players in our market place, let see what happens as
we explore the reasons mentioned above.
It’s too difficult

G​ enerally speaking, there is a tendency for technical teams,

and business sponsors in the commercial insurance segment
tend to give up to quickly and seek short term/patch solutions
rather than investing the time and energy in building a robust
solution. The reasons for this vary from time to market pressure
to just poor decision to do it right. A short term/patch approach
differs significantly an incremental delivery approach in which
value is sought in “realizable chunks” in a generally understood
and flexible roadmap.

So let’s look at what our two insurance companies decide to do

given this challenge

● LetsTryCo pursues a strategy of leveraging some

platforms that work to build out an API ecosystem
supported with new technologies (API gateway, rule
engines, insurance-specific components rating engines,
etc.). The approach provides for a Portal for less
sophisticated trading partners and an API interface for
trading partners that seek to own their own Portal. With
this approach, they can efficiently sequence the API
functionality into multiple releases. For example, they
can provide an initial release that fully supports the
insurance life cycle for one-more products or offer an
initial version of the API that only provides quotes for a
specific mix of products.
 ● NoTryCo moves forward starting with a core platform
replacement approach with Portals and determines that
API’s will be a secondary focus. They have concluded that
they will get some competitive advantage from the core
platform replacement. Given the approach, NoTryCo
release levers are somewhat little limited to state, product
mix options. For example, a release that targets the
Property line of business in 15 states, etc

Which approach seems riskier and has a lack of optionality?

W​ ell, all I will say is that the technology project graveyard is

full of core platform projects that fail given size, scale, and data
conversion issues. The data conversion issues tend to be a
project unto itself with a broad set of complex challenges to
tackle. I believe that an incremental delivery value has benefits.
LetsTryCo approach will likely provide a quicker path to value
creation.

Jeff Bezos famously issued an ​API mandate in 2002 ​which drove

the company forward in a material way. Some of this stuff resides
in the lore of Silicon Valley but the points he outlined as follows

● All teams will henceforth expose their data and

functionality through service interfaces.
● Teams must communicate with each other through these
interfaces.
● There will be no other form of inter-process
communication allowed: no direct linking, no direct reads
of another team’s data store, no shared-memory model,
 no back-doors whatsoever. The only communication
allowed is via service interface calls over the network.
● It doesn’t matter what technology they use.
● All service interfaces, without exception, must be
designed from the ground up to be externalizable. That is
to say, the team must plan and design to be able to expose
the interface to developers in the outside world. No
exceptions.

I​ am sure the path for Amazon teams seeing this was difficult,
but it provides a way for commercial insurance companies to
adopt. Bezos’ memo has a simplicity and elegance and yet
powerful ideas. It boils down to write your solutions anyway you
want but they must have API endpoints for integration and thou
shall not provide a database or shared memory-model approach
for integration.

Just imagine what your firm could do if all

systems had defined API’s for internal and
external consumption
Legacy Systems

Y​ es, the industry has a lot of older systems that have been
around since the late 70 and early 80s. However, these platforms
have some advantages that are overlooked. While I don’t have
any evidence to support my statement, I do believe the term
“legacy system” was created by vendors to sell more software.

Software like any asset will age over time

but that shouldn’t curtail your innovation.

What is a legacy system? Some people will that a legacy platform

is anything over 20 years, so the platforms are written in Java
circa 2000 legacy? Why is a vendor system created 20 years ago
isn’t considered legacy but a homegrown system is? Others will
say that all COBOL platforms are legacy platforms, I am not sure,
but I heard that some large personal lines carrier that is highly
innovative and competitive has COBOL systems at its core. But
this is only speculation and rumor.

In some cases, there is nothing better than the old working code
because it works. Yes, these mature systems have challenges, but
the capability offered in these systems shouldn’t be discounted
without a lot of thought.

I think that the more relevant question to ask regarding “legacy”

platforms is, what strategic outcomes are limited by platform?
Depending on the answer, you may take the approach of a full
platform replacement, but that should be an exception, not the
rule. If you have no core systems, you need one in place before
pursuing any API driven strategy.

One of the often themes, we hear in commercial insurance is the

time taken to introduce new products. In many cases, the legacy
system is viewed as the impediment to speed to market for new
products.

I believe that a little more in-depth analysis is needed. Per a

recent Novarica Study, “Speed to Market for Property/Casualty
Insurers” they state that the average speed to market is about
seven months for new products and around 2.7 months for
modifications to existing products. In many cases, companies will
focus on the IT time for implementing the product in the system
but fail to account for the effort/timelines that occur outside of
the implementation process.

The study showed that the IT delivery time was highly correlated
to when the IT team was engaged in the product development
lifecycle.
Most companies even with modern systems, only engage the
technology teams once the rates are ready to file and the filing
processes have started. As a reference point, the time to market is
average four months for Workers Compensation when the
technology team is engaged at product ideation vs. eight months
when they are engaged later. The sample size used in the study
was 29. I am sure that all 29 didn’t have modern core systems to
achieve that result. Although this is a process example, it speaks
to need to think about the problem differently.

An API wrapping strategy isn’t necessarily the most exciting thing

to do, but it gets you downfield. A potential scenario could get
played out as follows

1. So LetsTryCo launches into the market with the first

version and offers a 2% commission increase if partners
leverage the platform to the transaction. I know that
many will eschew offering 2%, but incentives drive
companies and the people that work within firms. The
incentive model could be just access to information that is
more challenging to get, but commercial terms seem to be
most effective.
2. Intrigued by the increased commission incentive,
MiddleCo integrates with LetsTryCo using the
LetUsTransact API. LetsTryCo learns how to shape the
direction of API and based on real usage. The policy
acquisition and servicing costs are lower in comparison to
intensive human methods.
3. NoTryCo embarks on a core platform replacement which
involves data migration and a new platform. The program
runs for four years with four releases, and the API’s are
targeted for year 3.
4. MiddleCo enjoys the increased commission, and faster
turnaround time of quotes, they start sending more of the
share of NoTryCo business to LetsTryCo. LetTryCo can
leverage models within it’s API framework to select risks
with its appetite which puts NoTryCo in a potential
adverse selection position. Besides, the NoTryCo has to
increase the commission offering to MiddleCo in
response to LetTryCo’s approach.
5. In year 3, NoTryCo in done with it’s APIs. The APIs are
superior in structure, content, and richness to LetsTryCo.
However, they face an adoption issue; over the three
years, LetTryCo has gotten multiple trading partners to
adopt the LetUsTransact and is pushing it to become a
standard. So MiddleCo is asking NoTryCo to build rebuild
it’s API’s to mimic the LetUsTransact interface. So now
that LetsTryCo is in the catbird seat do they license the
API or push it as the open source standard? who knows
Completeness

T​ he delivery of version 1 of any programming interface is

never the end; it’s only the beginning of a journey to provide a
comprehensive set of services. For reference, the ​Google Maps
SDK for iOS 1.0​ supported the following

● Initial release alongside Google Maps for iOS.

● Support for 3D maps, rotation, tilt, 3D buildings,
markers, polylines.
● Satellite and terrain tiles, traffic data, and other features.

That initial release doesn’t seem like a lot but let’s look at one year
later

Version 1.0.2 — January 2013

“Features

● GMSCamera was changed to GMSCameraPosition

● …
● Added Ground Overlays

Resolved issues:

● Fixed: GMSMapViewDelegate’s ….
● …
 ● Polylines now render at a constant size regardless of the
zoom level.”

Now they are on ​Version 2.7.0 — April 18, 2018

My point here is that if you expect to have a complete set of API’s

on day one, the journey will not be successful.

So back to our companies, LetsTryCo launches with version 1 and

iterates from real world usage of the APIs while NoTryCo depends
on a model of building out all functions before usage and engages
in conversations regarding the priority of features which isn’t
informed by consumers of the API.

“The man who moves a mountain begins by

carrying away small stones.” Confucius,
Confucius: The Analects
Vendor complicity in maintaining complexity.

I​ won’t say much here, but many vendors (software and

services) offer solutions with “lock-in” to drive additional
revenue opportunities. The incentives between the customer
(insurance company) and the technology partner aren’t
necessarily aligned. Many insurance companies want technology
that works at a reasonable price point and is flexible in
responding to the changing business climate. Vendors are
focused on selling the next solution or deriving some perpetual
fees based on premium or usage.

● LetsTryCo designed and builds it’s own API’s given that

they see a strategic advantage in doing so. As more
premium flows via the integration approach, there isn’t a
license fee flowing to the vendor based on premium or
usage charges Also; they have control over the sequence
of features/offerings within API’s. They might even get
drunk with power and license it to core platform vendors.
● Contrast that with NoTryCo which licenses an API from a
vendor. The licenses are indexed to usage or premium as
premium flows into the platform the license fees increase.
They can only move as fast or innovate as quickly the
vendor moves. NoTryCo was considering an acquisition
of a competitor and is realizing that API licenses fees will
grow considerably. Innovation/changes to the API’s has
to be coordinated with the Vendor to ensure that
upgrades will support customer specific changes.
 Who do you think gains from competitive
advantage? The old adage rings true..
Fortune favors the bold

I am still working on my time machine, but I think it is fair to

declare that the next generation insurer will have mastery over
API integration-based methods.