A rating or pricing vendor wins a carrier as a customer, then learns the carrier's core platform has no connector for the vendor's product. Rated premiums and pricing data have to land in policy, claims, and billing records, and every field needs a home in the carrier's structure.
That work blocks go-live. The vendor's engineers stop building the product and start learning a platform they do not own, while the carrier's IT team waits on a schedule neither side controls.
This guide explains what the connection involves, why it stalls, and the four ways to build it. It closes with a build vs buy table, a four-step mapping sequence, and the checks that keep the connection running after go-live.
What Does It Mean to Connect a Rating Vendor to a Core Platform?
Connecting a rating vendor to a core platform means sending quote data and rated premiums into the carrier's policy, claims, and billing systems in the structure those systems expect.
Where rating logic lives
Rating logic lives in one of two places. It sits inside the carrier's policy administration system, or it sits in an external engine or vendor service that the policy system calls when it needs a price.
Pricing vendors add a third pattern. They deliver models, factors, or scores that feed the rate, and those outputs need a path into the carrier's records too.
All three patterns end the same way. A number computed outside the platform has to be written into a policy, quote, or endorsement record that the platform recognizes.
What data moves in each direction
A quote request carries risk details, coverages, limits, and deductibles out to the vendor. The response returns premium, rating factors, fees, and referral flags.
Endorsements, cancellations, and reinstatements send the same data again with a change attached. Each of these exchanges is a form of dynamic data exchange, and each one needs a defined structure on both sides.
Claims and billing systems read the resulting policy record. An error at rating time surfaces later in a different department.
Who sends, who receives, who owns the work
Senders are the rating, pricing, and workbench vendors, along with MGAs, TPAs, and brokers whose carrier customers run a core platform. Receivers are the underwriters and adjusters who work from the records that arrive.
The technology owner at the carrier, the CIO or equivalent, decides what connects to the core platform and how.
Why Do Rating Vendor Integrations Stall Before Go-Live?
Integrations stall for structural reasons, not for lack of effort. Three causes show up repeatedly: the mapping work, the split in ownership, and the upkeep that follows the build.
The mapping work is larger than it looks
Every field in the vendor's payload has to match a field the platform expects. Names differ, code lists differ, and one vendor field often feeds several platform fields.
Package products raise the stakes. A single rated source maps to many coverages, so one wrong match shows up on the quote an underwriter reviews.
Ownership sits in two organizations
The vendor owns the payload and the carrier owns the platform. Neither team owns the mapping between them, so each waits for the other to define it.
Carrier executives describe the gap in their own data. In a June 2026 survey of 400 insurance executives across Australia, Europe, the UK, the United States, and Canada, 30% said they can quickly get the information they need, and 46% said their technology gives them adequate speed for decisioning.
Upkeep outlasts the build
A hand-built connector needs upkeep through every platform upgrade and every carrier upgrade. A new mandatory field in the platform stops requests that passed the day before.
The vendor then repeats the diagnosis for each carrier. A vendor with several carrier customers owns several connectors, each with its own mapping and its own upgrade calendar.
What Are the Options for Connecting a Vendor to a Core Platform?
Four routes exist. The table compares them on who builds, what the vendor owns afterward, and where each route fits.
Build vs buy: four routes compared
Option | Who builds it | What the vendor owns afterward | Where it fits |
|---|---|---|---|
Custom connector per carrier | Vendor engineers | The build, the mapping, and every upgrade | One carrier, one platform, deep platform skills in house |
Carrier-built integration layer | Carrier IT | Payload format and testing | A carrier with a large integration team and an open slot on its schedule |
System integrator project | Third-party integrator | Change requests and handoffs | A carrier that mandates a specific integrator |
Prebuilt gateway route | Gateway provider supplies the connectors, vendor configures | Payload and mapping review | Several carriers, several platforms, limited platform skills |
How to compare the options
Five criteria separate the routes: the number of carrier customers, the number of distinct platforms, the upgrade calendar, the data residency requirements, and the platform skills the vendor's team already holds.
One carrier on one platform favors a custom build. Several carriers on several platforms turn each custom build into a repeating cost.
Questions to ask the carrier before choosing
Answers to five questions settle most of the decision. Ask them before any engineering starts.
Which platform products receive the data: policy, claims, billing, or all three?
Is the platform on-premises or in the cloud, and which APIs are open to outside senders?
Who at the carrier approves a new sender, and what does approval require?
Does PII or PHI travel in the payload, and where must it stay?
How does the carrier handle platform upgrades that add mandatory fields?
How Do You Map Rating Data Into a Core Platform, Step by Step?
Payload mapping matches each field in a sender's data to the field the target platform expects, so a submission or claim lands in the right place on the first send.
The Map, Validate, Send, Trace sequence breaks that work into four steps. Each step has a person accountable for it and a record that proves it happened.
Step | Question it answers | Who is accountable | Evidence it leaves |
|---|---|---|---|
Map | Does each payload field have a platform field? | Sender's administrator | A confirmed mapping |
Validate | Is the payload complete and well formed? | Sender, with the platform's checks | A list of flagged gaps |
Send | Did the record reach the right place? | Sender | A response from the platform |
Trace | What happened to every request? | Sender and carrier IT | A request, response, and error log |
Map the payload to the platform structure
The vendor supplies a JSON payload with its rated fields. The mapping lists, for each field, the platform field it feeds.
An AI-drafted mapping speeds the first pass, but accountability stays with a person. A person reviews and confirms every AI-drafted mapping before data moves, which keeps accountability with the sender's administrator.
Validate before any data moves
Validation runs at three points. Syntax errors in the payload surface immediately, incomplete records are flagged before they reach an underwriter or adjuster, and a submission passes a producer code check before it is sent.
Flagged gaps go back to the sender. They never land in the carrier's work queue.
Send, then trace every request
Large payloads travel as a file location instead of an inline body. The platform returns a response, and the sender reads it before treating the record as delivered.
A log of every request, response, and error closes the loop. When an underwriter asks why a premium looks wrong, the log answers in minutes instead of days.
How Do You Keep the Connection Running After Go-Live?
Go-live is the start of the upkeep, not the end of the project. Three practices keep the connection healthy through platform upgrades, new carriers, and changing payloads.
Plan for platform upgrades
A platform upgrade adds a mandatory field, and requests that carried the old structure begin to fail. Without an alert, the first signal is an underwriter asking where a quote went.
Set up an alert that fires when the platform adds a mandatory field, and keep the existing flow running while the sender updates the mapping.
Serve several carriers without rebuilding
Each carrier names coverages and codes in its own way. Tenant-specific mappings let one vendor payload serve several carriers, with a separate mapping held for each.
This keeps the vendor's product stable. The carrier-specific differences live in the mappings, not in the product code.
Measure what matters
Four measures show whether the connection works: the share of records accepted on the first send, the number of mapping edits per carrier, the time to resolve a flagged record, and the share of requests that arrive incomplete.
Review them monthly with the carrier's IT owner. A rising edit count points to a mapping that needs rework before the next upgrade.
How InsOps Helps
InsOps builds an insurance-trained AI that assists with moving rating and pricing data into your core platform. LiLa, our insurance-trained LLM, drafts the field mapping from your payload to the carrier's platform structure. A person on your team reviews and confirms every mapping before data moves.
The InsOps Integration Gateway gives rating vendors, pricing vendors, and workbench providers a prebuilt route into the carrier's 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.
The gateway handles authentication, validation, and request logging, and it flags incomplete data before it reaches an underwriter or adjuster. Tenant-specific mappings let one vendor serve several carriers, and alerts fire when the platform adds a mandatory field while the flow keeps running. Your engineers spend their time on your product instead of on platform APIs.
InsOps is a Guidewire technology partner with prebuilt connectors to the core platforms carriers run. If you are evaluating how to exchange rating data with a carrier's core platform without a custom connector build, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What is a rating engine integration?
A rating engine integration is the connection that sends quote data to a rating engine or pricing service and writes the rated premium back into the carrier's policy system. It covers the field mapping, the validation checks, and the request log.
Why does connecting a rating or pricing vendor to a core platform take so long?
The vendor and the carrier each own half of the problem, and neither owns the mapping between them. Field names, code lists, and coverage structures differ, so every field needs a confirmed match before data moves.
How do you connect a rating vendor to a policy administration system?
Define the vendor's payload, map each field to the platform structure, and validate the payload before sending. Send the record, then read the platform's response and keep a log of every request. A person at the sender confirms the mapping before any data moves.
What are the most common challenges in vendor integrations?
Mapping package products to many coverages, waiting on carrier IT schedules, and keeping the connection working through platform upgrades. Each upgrade that adds a required field forces a mapping update.
What should a vendor track to know the connection works?
Track the share of records accepted on the first send, mapping edits per carrier, time to resolve a flagged record, and the share of requests that arrive incomplete. These four measures show problems before an underwriter reports them.
How does the InsOps Integration Gateway help?
The InsOps Integration Gateway gives senders a prebuilt route into a carrier's core platform, with LiLa drafting the field mapping from the sender's payload. A person at the sender reviews and confirms every mapping before data moves.
How long does a vendor integration take, and what slows it down?
The timeline follows the number of mapped fields, lines of business, and carrier platforms, not the size of the vendor's engineering team. Delays come from waiting on carrier approvals, learning platform APIs, and reworking mappings after a first failed send.
Does a vendor need a separate integration for every carrier?
A vendor needs a separate mapping for each carrier, because each carrier names coverages and codes in its own way. A custom build repeats the whole project per carrier, while a prebuilt route repeats only the mapping review.