A carrier signs a new MGA, TPA, or data vendor, and IT receives a ticket to connect that vendor to policy, claims, and billing. The team has done this before, so it builds another direct connection.
That choice is reasonable once. By the tenth vendor, the carrier owns ten separate builds, ten sets of field mappings, and ten connections that fail on their own schedule whenever a core system changes.
This article explains why point-to-point integrations break as the vendor list grows, which failures appear first, and what to ask before approving the next custom build.
What Is a Point-to-Point Integration, and Where Does It Start to Fail?
A point-to-point integration is a custom-built, direct link between one vendor system and one carrier system, written to move one specific set of data between exactly those two.
Why the first few connections work
With two or three vendors, one team knows every link. Each build takes a few weeks, and the cost of upkeep stays invisible because nothing has broken yet.
Where the connection count outruns the team
Every vendor that needs policy, claims, and billing data adds one build per system. The count grows with each vendor, and so does the repair queue behind it.
The table below shows the arithmetic for a carrier with three core systems, where each vendor needs data from all three.
Vendors | Point-to-point builds | Connections through one shared entry point |
|---|---|---|
2 | 6 | 5 |
5 | 15 | 8 |
10 | 30 | 13 |
20 | 60 | 23 |
Illustrative model. A shared entry point connects to each core system once, and each vendor connects to it once.
Which Failures Show Up First as Vendors Are Added?
Maintenance, mapping, and oversight break first. Each one gets worse with every vendor, and none of them shows up on the day a connection goes live.
Repairs multiply after every core system change
A core system upgrade or a new mandatory field breaks each direct connection separately. One change at the carrier produces ten repairs when ten vendors are connected, and each repair needs someone who knows that build.
These workaround builds are a main source of technical debt in P&C insurance, because each connection depends on whoever built it.
The same field gets mapped ten different ways
No build is reusable, so the policy number, effective date, and coverage fields are mapped again for every vendor. Small differences between those mappings put inconsistent data into the core system.
Nobody sees the whole ecosystem
Direct connections leave no single place to check which vendor sends which data. Security review also varies with whoever built the last connection, so access rules differ from vendor to vendor.
What Do Carriers Do Instead of Another Custom Build?
A shared integration entry point lets every vendor connect once, through one governed route, instead of building a separate connection to each core system.
Carriers that adopt a standardized API gateway model treat vendor onboarding as configuration work instead of a development project. The same logic drives the wider move to composable, API-first systems.
How the main options compare
Custom point-to-point build | Integration platform the carrier operates | Shared entry point with prebuilt connectors | |
|---|---|---|---|
Carrier-side build | Built for each vendor | Built for each connector and mapping | Prebuilt, so the vendor brings its payload |
Reuse for the next vendor | None | Shared connectors, mappings built per vendor | Shared connectors, mappings configured per vendor |
Repair after a core system change | One repair per vendor connection | One repair per connector, shared by all vendors | One repair per connector, shared by all vendors |
Onboarding path | Development project | Configuration plus connector build | Configuration |
What to ask before approving the next build
Does the next vendor reuse any part of this connection?
Who repairs it when a core system adds a mandatory field?
Where does a person review the field mapping before data moves?
Where do PII and PHI go while the data is mapped?
Two or more unanswered questions point to a build that repeats itself with the next vendor.
How InsOps Helps
InsOps builds an insurance-trained AI that assists with moving vendor data into your core platform. LiLa, our insurance-trained LLM, drafts the field mapping from each vendor's payload to your platform's structure, and a person on the vendor's team reviews and confirms every mapping before data moves.
The InsOps Integration Gateway gives MGAs, TPAs, and underwriting vendors a prebuilt route into your policy, claims, and billing systems. Senders register in a self-service portal, bring their payload, and configure it without building their own connector. The gateway runs inside your own environment, so PII and PHI stay in controlled infrastructure.
InsOps is a Guidewire technology partner with prebuilt connectors to the core platforms carriers run. If you are evaluating how to exchange vendor data with your core platform without a custom connector build for each vendor, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What is a point-to-point integration?
A point-to-point integration is a direct, custom-built connection between two systems. It moves one specific set of data from one source to one destination.
Why does point-to-point integration break at scale?
Each vendor adds its own builds, mappings, and repair work, and nothing built for one vendor serves the next. One core system change then triggers a separate repair for every connected vendor.
What is the difference between point-to-point and hub-and-spoke integration?
Point-to-point links each pair of systems directly. Hub-and-spoke gives every system one connection to a central hub, which routes and maps data between them.
When is point-to-point integration still the right choice?
It fits a small, stable set of systems where one team owns every link, such as a single vendor with no plan to add more. Once vendor additions become regular, shared infrastructure costs less to run.
What should carriers track to know whether vendor integration is scaling?
Track the days from a signed vendor to first live data exchange, the number of custom connections the team maintains, and the repair time after a core system change. A rising count on the first two numbers signals a point-to-point pattern.
How does the InsOps Integration Gateway help?
It gives each vendor a prebuilt route into your core platform, with LiLa drafting the field mapping from the vendor's payload. A person at the vendor reviews and confirms every mapping before data moves.
How long does it take to move off point-to-point connections?
Carriers keep existing connections in place and send every new vendor through the shared route first. Older connections retire one at a time as each comes up for repair, so the full change runs as long as the oldest connection stays in service.