Most of the argument about broker data is about how to get it out of the system. Almost all of the value is in getting it in.

Brokers have spent years being told that their data is their own, and in principle it is. In practice, it normally sits inside a system that was designed to keep a record rather than to do very much with it. The difference shows up in fairly mundane places. The new business team keeps a pipeline somewhere and somebody types it into the broking system. At month end, somebody spends three days proving that the policy records and the ledger agree. A client fills in a form on your website on Monday and gets a quote on Thursday because the answers landed in somebody’s inbox rather than against a risk.

The data obviously exists, but the problem is moving it.

It helps to separate the two directions, because almost the entire conversation in this market is about one of them. Ask a broker about data portability and you will usually get an answer about leaving. Can I get my book out of the system if I go, and what will it cost me?

This is obviously a fair question. If getting your own records out requires a negotiation and an extraction fee, then the price of the platform is not the licence. It is the licence plus the cost of ever changing your mind, except that you don’t find out the second number until the day you most need to know it.

But changing a core broking system is something a broker does once a decade. Everything else is something they do on a Tuesday.

What data going out is actually for

In normal use, brokers need information out of the system all the time. They want a reporting tool pointed at the live book so that retention, income by producer and exposure by class are numbers on a screen rather than a workbook somebody rebuilds every month. They want invoices, commission and client money appearing in the accounting package without somebody having to arbitrate between the two systems. They want bordereaux built from the underlying records rather than assembled in Excel by somebody who is also meant to have another job.

They want aged debt in front of whoever chases it. They want audit trails, fair value work and conduct evidence to be things they can look up rather than exercises they have to undertake. Increasingly they also want to give an AI tool something useful to read, which means live structured records rather than whatever happened to be exported last fortnight.

None of this is very futuristic, as brokers already do all of it. The interesting question is why so much of it still requires a person to move the information around.

The other direction gets less attention and, I think, matters rather more.

Take the least glamorous example. Your new business people keep a pipeline somewhere, marketing keeps a list somewhere else, and neither touches the broking workflow, so somebody types it across. The time spent doing that is annoying but it probably is not the biggest cost. The bigger problem is that every re-key is another chance to put the wrong renewal date or the wrong premium in front of a broker. Once a broker has been caught out by his own system a couple of times, he stops trusting it and starts keeping his own notes instead.

At that point you have two books. One is in the platform and one is in the broker’s head, and the second one walks out of the building when he does.

The same problem affects whether you win the straightforward, quick business. Online forms, introducers and affinity partners all depend to some extent on how quickly you reply. If the risk appears in the workflow when the client presses send, somebody can start work on it immediately. If it arrives as an email, you start when somebody sees the email.

There is no great strategic difference between those two brokers. One of them just has better plumbing. The client does not particularly care why it took three days to get back to them – they’ve already gone to another broker.

Renewals are the same thing in reverse. Last year’s answers should come out of the system, go to the client to confirm or amend, and come back against the same record. Nobody in commercial insurance seriously believes it is sensible to send a blank proposal form to a client you have insured for six years. It happens anyway, because in a lot of systems there is no straightforward way for the data to make the round trip.

Acquisitions are where this becomes expensive rather than irritating. You buy a broker and inherit its system, its filing habits and its particular way of describing a trade. If you can move that book into the rest of the business through an interface, there is at least a plausible route to integration. If you can’t, you run two businesses and call them one integrated whole in the board pack.

Why are we still doing this?

There is not much mystery to it - most of the systems in this market were designed at a time when the principal job of a broking system was to store information accurately. Anything else asking for that information was an edge case. They did that job well, and many of them still do.

What changed was the number of other things a broker now wants to connect to the record. CRMs, accounting packages, portals, data providers, introducers, insurer systems, reporting tools, document tools and now AI. The broking system went from being more or less the end point for the data to being one component in a much larger set of things that need to use it.

For quite a long time, the answer was simply to employ people to bridge the gaps. In most brokers that is still, to a greater or lesser extent, the answer.

I have watched a version of this happen before. At Codat, our last business, the initial problem we were trying to solve was that small businesses had perfectly good accounting and transaction data sitting in their financial software, while the lenders who needed it were asking them to download things, send spreadsheets and generally act as a fairly inefficient API between two computer systems.

A lot of the early debate around Open Banking and Open Finance was about the principle of giving companies access to their own data. That mattered, but it turned out not to be the most interesting bit. Once the data could actually move, people started building things with it. Lending decisions which used to take weeks could take minutes. Products could be built for small businesses which were either too expensive or too cumbersome when every application involved collecting and checking the same information again.

Commercial insurance is several years behind banking on this. We still spend quite a lot of time debating whether the records can be exported, while brokers employ substantial numbers of people to move data into and out of systems which are sitting next to each other.

What I would ask

The standard I would want is fairly simple. Every meaningful object in the system, clients, policies, endorsements, claims, documents, invoices and so on, should be available through an interface. I should be able to read it and write to it. The interface should be live, not an overnight dump, and access to it should be part of the product rather than an additional piece of software I have to buy from the same vendor.

If I want to connect another system to my broking platform, I should be able to do it without asking permission or starting a professional services project. And yes, if I decide to leave, I should be able to take everything with me.

So I think there are five fairly useful questions to put to any vendor, preferably in writing while the demo is still fresh in everybody’s mind:

1. Can I read every object in the system, or only the ones you have chosen to expose?

2. Can I write into the system as well as read from it?

3. Is the access live, or is it a scheduled export?

4. Is it included in the licence?

5. If I leave, what does it cost to take my data with me, and who decides that price?

The first instinct of most vendors will be to answer the last one. That is understandable because it is the question brokers have traditionally asked. It is also the easier question.

Getting data out when you leave tells you whether you are locked in. Getting data in and out while you stay tells you what you can actually do with the system.

Your book is probably the most valuable thing you have built. It is the product of years of relationships, renewals and accumulated information. It seems reasonable that the software you put it into should let you use it.

----------------------

Recorder is an API-first system of work for commercial insurance brokers and MGAs. Every object in Recorder is available through an API as standard, with no extraction fees or separate commercial terms.