Integration, integration, integration

With software vendors increasingly adopting API integrations, the era of seamless system connectivity in the London Market is well underway, says James Pring, Sales Director at Ebix Europe

Integration, the connection of systems through interfaces to enable data exchange, prevents the tedious task of rekeying information across applications. And in fact, although you are largely unaware of it, almost every application you use in day to day life is integrated to something else - banking systems to credit reference agencies, online hotel comparison sites to online hotel booking sites, motor insurance company portals to the DVLA licence plate database, online shopping sites to the national postcode & addresses database. And so on.?

So integration is highly beneficial and allows complex ecosystems to be formed from a collection of smaller, less complex applications working in harmony.

The primary operational benefits of integration are reduced costs, increased speed and accuracy. Without integration, data has to be transferred between systems using arcane methods and users rekeying information from paper printouts or adjacent screens. This is highly inefficient, expensive and prone to significant error rates.

Look me in the API and say that

It used to be said that the complexity of a system increased by the square of the number of interfaces, such was the difficulty of building and maintaining bespoke interfaces and protocols between incompatible systems. More modern integrations, however, make use of APIs (Application Programming Interfaces) to achieve this, where the API dictates and manages the protocol and structure of the exchange, freeing the developer from that complex aspect of the work, and making integration easier and cheaper.?

And as a lot of API development is now standardised using a small number of recognised global methodologies, which are widely recognised by the software developer community, integration has become far more cost effective to undertake.

So, APIs are used to enable communication between systems. These can be systems that are operated within the same company, for example to connect invoicing and accounting systems together, or remote systems such as those operated by a company’s trading partners. In this latter case, the content, format and protocol of the data exchanged might be defined by a standards organisation dedicated to that specific industry such as, in the Insurance market, ACORD and the Data Council.

Pass me the remote control

APIs can also be used to operate a system remotely whereby, for example, one system can execute another’s functions “headlessly”, i.e. without needing to use that system’s user interface.

Multiple trading partners within any industry can benefit significantly from integrating their systems to effect the day-to-day transactions that occur between them. The London market is an excellent example of one such industry. With more than just a few participants, however, direct integration between each combination of trading partners (known as peet-to-peer) is not usually preferred.?

Instead, in industries like the London Insurance market, integration through a centralised hub reduces the complexity of connections among multiple trading partners. This “hub”, “exchange" or “trading platform” sits in the middle and is surrounded by the market participants in a “hub and spoke” configuration Thus, each market participant only needs to carry out a single integration to the central hub (i.e. their spoke), significantly reducing the number of connections in the marketplace.

As the London Insurance market’s sprawling estate of legacy administration software, dating back to the 1980s in many cases, slowly gets replaced by modern systems, integration becomes easier. This is in part due to the fact that most modern systems use APIs to communicate internally with themselves already - a system’s modules/components will exchange data and functional instructions among themselves using APIs and many of those can be used as the basis for externally-facing APIs.

A must-have, not a nice-to-have

All electronic trading platforms need to provide APIs to give market participants a simple means of uploading data to, or downloading it from, the platform. Brokers are primarily the providers of data and documents to the placement process and it is they who most need APIs to begin with to mitigate the considerable effort (and risk of errors) involved in rekeying submission data and dragging and dropping documents from their placing administration systems onto the platform.

APIs must be provided, therefore, to enable a broker’s system to create new submissions, endorsements and other transaction types on the platform. It is also highly desirable, but not essential in the first instance, to provide APIs to enable the remote operation of certain aspects of the platform’s functionality, thus allowing the broker’s system to “drive” the platform headlessly. In this way, for the most part of a user’s day they would not be required to log into the platform at all.

Underwriters are primarily receivers of data and documents in the placement process and need, therefore, to be provided with APIs to retrieve submission data from the platform and pass it into their workflow, administration and quotation systems. Underwriters also supply quote information to the platform (for onward transmission to the brokers) so they must be provided with APIs to achieve this without manual rekeying,

In both broking and underwriting cases, there are multiple systems involved - brokers with, for example, policy administration, slip creation and work in progress systems, and underwriters with policy administration, quoting/rating, document management, workbench and workflow systems, to name but a few. Therefore, for a single transaction on a placement platform, multiple APIs at either end of the broker/underwriter conversation might be employed to coordinate the transfer of data to/from multiple sources and destinations.

Open your APIs and Seeeee…

The vast majority of systems used in our market are provided by software vendors and it is, more often than not, their responsibility to develop API integrations with the common systems and platforms. Old-style integrations, for example, to the market’s central bureaux and claims systems were undertaken decades ago by the policy administration system vendors. So integration to the markets’ new placing platforms, and to the Blueprint 2 services, will be no different.

It is becoming imperative for software companies to have APIs on their products. And we’re very happy to report that not only do we have APIs on both PlacingHub and ExposureHub, but we also have a growing number of software vendors who have successfully integrated their applications to ours.?

Watch this space for further updates!

Get in touch to find out more about our API roadmap, connecting ExposureHub, PlacingHub and our growing suite of vendor partners.?