Information from the London Market reaches an insurer or a broker by more than one route. Contracts are placed on one platform, accounts and claims move between market parties, and the organisation’s own systems must keep up with all of it.
Two routes matter here. Whitespace publishes its activity to a managed queue, which gives a direct connection to that platform. ADEPT, the ACORD Data Exchange Platform and Translator, works as a gateway: one connection that brings in information from several sources, Whitespace among them.
Which route is right is a decision for the client. We built both routes, behind one integration layer that presents the same internal view of the data, whichever route the client chooses.
The route into the market is a business decision. The way the organisation sees its own data should not depend on it.
Two routes into the market
A client uses one route or the other. The two routes work in different ways.
| Direct route (Whitespace queue) | Gateway route (ADEPT) | |
|---|---|---|
| What it connects to | One platform | Several sources through one connection |
| How information arrives | As a stream of activity messages on a managed queue | Through a programmatic interface, with notifications when something changes |
| Suits an organisation that | Works mostly on one platform and wants the closest connection to it | Deals with several sources and wants one connection to manage |
| What the integrator must handle | Order, duplicates and the confirmation of every message | Secure sign-in, access that expires, retries and notifications |
Neither route is better in every case. A queue suits a platform that must never lose an action. A gateway suits an organisation that wants to reach many sources without building a separate connection to each.
Other options in the market
The market offers other options too. We were aware of two of them.
- PPL, an alternative placing platform. Insurers can also place London Market business through PPL, as an alternative to Whitespace. At the time of this project it was not an option for an integration: PPL offered a web interface for submitting placements, but no REST API that a system could call. PPL now has a REST API, so it is an option for future integrations.
- WebConn Ltd (WCL), an alternative gateway. WCL offers a gateway API, as an alternative to ADEPT, for sharing placements, submissions and claims data in the London Market. It is a second gateway option for a client that wants one connection to several sources.
The existence of these options is one more reason why the choice of route is a business decision, and not a technical default.
One integration layer, whichever route
The integration layer sits between the route and the organisation’s internal systems. Each route has its own adapter. Everything after the adapter is the same.
| Capability | What it does | Business purpose |
|---|---|---|
| Source adapters | Handle the details of one route: the queue, or the gateway with its sign-in and notifications | Hide the differences between routes from the rest of the organisation |
| Mapping and validation | Convert what arrives into one internal model and check it | Internal systems see one format, whatever the route |
| Workflow and state tracking | Follow each contract, account and claim through its stages | One answer to “where is this item now?” |
| Reconciliation | Compare what the market side holds with internal records | Differences are found early, not at month end |
| Audit and monitoring | Record every message and decision, and raise alerts | Every outcome can be explained and every failure is visible |
| Configuration | Keep platform settings and credentials outside the code | A change of setting needs no new release |
How one business event travels
An action in the market starts a chain of steps. The same chain applies to both routes. Only the first steps differ, because a queue delivers a message and a gateway delivers a notification.
The event is confirmed only at the end. If anything fails on the way, nothing is lost: the same work can be tried again safely.
Designing for reliability
A connection to the market is only as good as its behaviour on a bad day. We designed for the bad days first. The same rules apply to the queue and to the gateway.
The main principles were:
- Order is respected. Events are processed in the order in which the actions happened, so the internal picture matches the real one.
- Each event is processed once. An event that arrives twice is recognised and skipped.
- Failures are never silent. A failed step is retried after a delay. If it still fails, the event moves to a review queue and an alert is raised, so a person can decide.
- Credentials stay outside the code. Access details are held separately and can change without a new release.
- Change is absorbed in one place. When a platform changes, the adapter or the mapping changes. Internal systems do not.
Choosing the route
The choice of route belongs to the client. It is a business decision, and it comes before the integration work starts.
- The direct route to Whitespace suits a client whose market activity sits mostly on that platform, and who wants the closest connection to it.
- The route through ADEPT suits a client who wants one connection that brings in information from several sources, Whitespace among them.
We built both routes, so that the decision can follow the needs of the business and not the limits of the technology. Whichever route the client chooses, the internal model, the workflow and the reports work in the same way.
Working with the partner platforms
Each route has its own onboarding, its own test environment and its own rules for access. We built and tested each route against the platform’s test environment before it went live.
What the organisation gains
- One internal view of each contract, account and claim, whichever route supplies it.
- A real choice of route. The client decides on business grounds, without a technical penalty for either answer.
- Failures that are visible and recoverable, in place of silent gaps.
- Calmer change. An update by a partner platform is handled in one place, without disturbing internal systems.
Measuring success
Success should be measured in operational terms.
| Dimension | Example measure |
|---|---|
| Timeliness | Delay between an action in the market and the update in internal systems |
| Completeness | Share of events processed without manual action |
| Accuracy | Differences found when market data is reconciled with internal records |
| Reliability | Number of events in the review queue, and the time to clear them |
| Effort | Manual re-keying time removed |
| Onboarding | Time taken to connect a new source or participant |
A baseline taken before the integration makes these measures meaningful.
The larger opportunity
The market will keep changing. New sources, new interface versions and new participants are normal. The organisations that cope best treat integration as a layer they own: a place where change is absorbed, every step is traceable and the business keeps one consistent view.
That layer lets the organisation choose the route that suits it, and keep one consistent view of its data.