A carrier on Guidewire that takes data from MGAs, brokers, TPAs and software vendors builds a separate way in for each Guidewire application. A partner that sends policy, claims and billing data needs three connections. Each one carries its own mapping, its own testing and its own upkeep.
The cost does not show at the first partner. It shows when the next sender arrives and the carrier opens another set of builds. It shows again when a Guidewire release lands and every connector needs a second look.
This article explains what changes when policy, claims and billing data enter through one intake layer. It covers what the layer does, how ownership shifts, how each data type travels, and what to check before you commit.
What does intake look like when each Guidewire application has its own way in?
Each application gets its own connector, mapping and test cycle for every sender. The number of builds grows with senders multiplied by applications.
A carrier that takes policy, claims and billing data from outside partners ends up with a grid of connections. The grid gains a full row each time a partner joins.
One sender, three builds
Follow one partner through the grid to see where the work lands.
A TPA or servicing platform that sends policy changes, cancellations and reinstatements into PolicyCenter needs one connector. The same partner sending claims into ClaimCenter needs a second. Billing data into BillingCenter needs a third.
Each connector carries its own mapping logic, its own mandatory fields and valid values, and its own failure points. A mapping built for one application does not carry over to the next, because each expects different structures.
Why the cost lands on the next partner
The first partner hides the pattern. Upkeep is what accumulates.
Every Guidewire release sends the team back to each connector to confirm that no mandatory field or structure changed. A change on the sender side triggers the same review.
The next partner then competes with that upkeep for the same developers. This is where the connector backlog starts to set how many distribution partners the carrier takes on.
Where the gaps open between applications
Separate intake also leaves seams between the three applications.
A cancellation that has not reached PolicyCenter leaves other systems showing a conflicting status. A payment that arrives before its policy has nowhere to post, so the billing system holds it in suspense.
Claims data has its own seam. First notice of loss records, loss details and party information must match what ClaimCenter expects before the data is usable.
What is a single intake layer, and what stays with Guidewire?
A single intake layer is one carrier-side entry point where a sender maps its payload once. The layer translates that payload to the carrier’s Guidewire format, and a person reviews every mapping before it is used.
It adds a front door. It does not add a new system of record.
What the layer does
The layer takes data from outside senders and places it in the right Guidewire application. Three steps cover the path.
The sender registers in a self-service portal and brings its payload in its own format.
The sender maps that payload once, and a person reviews the mapping before it goes live.
The layer translates each transaction to the carrier’s Guidewire structure and rejects incomplete data before it lands.
A sender that serves several carriers needs its payload mapped differently for each one, since no two carriers configure PolicyCenter identically. The mapping is tenant-specific, not one mapping reused everywhere.
What stays with Guidewire
PolicyCenter, ClaimCenter and BillingCenter remain the systems of record. Each application keeps its own business rules and its own data model.
The layer does not replace any of them. It brings outside data to their door in the format each one expects.
How it differs from Guidewire’s own Integration Gateway
Guidewire has its own product called Integration Gateway. It is a developer framework that hosts integrations your developers write and maintain.
An intake layer starts from the other end. It gives outside senders a place to map, test and send, so your developers do not write a new integration for each one.
What changes for the carrier when one layer takes in all three?
Mapping moves to the sender, validation moves to the door, and Guidewire releases land in one place instead of many. The carrier keeps the review step and the rules that define complete data.
The intake ownership shift
The table compares who does what under each model. Read it row by row against your own estate.
Question | Separate intake per application | One intake layer |
|---|---|---|
Who maps a sender’s data? | Carrier developers, once per sender and per application | The sender maps once, and a person reviews each mapping |
Where is incomplete data caught? | After it reaches a Guidewire application | At the door, before it reaches Guidewire |
What does a Guidewire release trigger? | A review of each connector | One place absorbs the change |
How does the next partner start? | A new build for each application | Portal registration, sandbox testing, then sending |
Where do you see what happened? | Logs scattered across connectors | One dashboard of every request, response and error |
What the Guidewire team no longer carries
The team no longer writes a mapping for each new sender. It no longer rechecks every connector after a release.
Senders test in a sandbox before real data moves, so a failed mapping shows up before a transaction fails in production. The review step is where the carrier’s people spend their attention.
What the carrier still owns
Three things stay with the carrier. It defines the mandatory fields and valid values that make a transaction complete, and it decides which senders to admit. Its people also review the mappings.
The layer enforces those rules at the door. It does not set them.
How do policy, claims and billing data travel through the same layer?
Each data type enters through the same route and lands in its own Guidewire application. Policy data lands in PolicyCenter, claims data in ClaimCenter and billing data in BillingCenter.
Policy transactions
New submissions and mid-term transactions share the route.
Policy updates travel the same way submissions do. A sender connected for submissions needs no second integration for amendments, cancellations and reinstatements.
The policy system applies each change to the correct policy. Every request is validated and logged, with its response and audit entries on the dashboard.
Claims data
Claims data enters ClaimCenter through the same route. A sender maps its first notice of loss payload once, a person reviews that mapping, and the layer translates each record to the structure ClaimCenter expects.
Large payloads are sent by file location instead of in the request body. A carrier with a large batch of claims does not push it through an API call.
Billing data
Billing data follows the same route into BillingCenter. Payments and billing changes come from policy systems and payment sources, and each source names its fields differently.
The layer maps those fields to the format BillingCenter expects. Billing updates then do not need a connector of their own.
What should a carrier check before putting all three behind one layer?
Check six things, in order. Each one separates a layer that holds up from one that turns into another maintenance project.
Six checks for the architect
Run these against any option you evaluate, including a build in-house.
Does it reach PolicyCenter, ClaimCenter and BillingCenter, or only one of them?
Who maps the data, and does a person review every mapping before it goes live?
Does it reject incomplete data before the data reaches a Guidewire application?
What happens when Guidewire ships a release or a sender changes its payload?
Can senders test in a sandbox before real data moves?
Does the mapping differ by carrier tenant, or does one mapping serve every carrier?
What one layer does not cover
An intake layer brings outside senders’ data into the three applications. It is not a reporting store, and it does not connect every internal application to every other.
Keep those jobs with the tools built for them. The layer takes the intake job off your developers and leaves the rest of your estate as it is.
How InsOps Helps
InsOps builds an insurance-trained AI that assists with mapping sender data into Guidewire. Yazh (Yaal), the InsOps Integration Gateway, is a data exchange platform for carriers on Guidewire. A sender maps its payload once, and Yazh translates it to each carrier’s Guidewire format.
LiLa, our insurance-trained model, assists the mapping, and a person reviews every mapping before it is used. Yazh handles inbound data exchange into Guidewire PolicyCenter, ClaimCenter and BillingCenter. It rejects incomplete data, handles changes to a payload or a Guidewire release, supports tenant-specific mapping, and accepts large payloads by file location.
Senders get a self-service portal and a test harness with a sandbox, so they test before real data moves. Guidewire’s own Integration Gateway is a developer framework. Yazh adds a place beside it where outside senders map, test and send without a separate build for each partner.
If you are evaluating how to take policy, claims and billing data through one route without a connector build for each sender, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What is a single intake layer for policy, claims and billing data?
It is one carrier-side entry point for data from outside senders. A sender maps its payload once, the layer translates it to the carrier’s Guidewire format, and a person reviews every mapping before it is used.
Why does one layer matter for a carrier on Guidewire?
Without it, builds multiply with every sender and every application. One layer moves mapping to the sender and keeps validation and release handling in a single place.
How does a carrier put one layer in place?
Define the mandatory fields and valid values for each data type first. Then register senders in a self-service portal and have each one map its payload. A person reviews each mapping, senders test in the sandbox, and real data follows.
What is the most common challenge?
Senders describe the same data in different ways, and each Guidewire application expects its own structure. A mapping reviewed for policy data does not carry over to claims or billing data, so each data type needs its own reviewed mapping.
What should a carrier track to know it is working?
Track rejected payloads by sender and by reason, and the number of senders onboarded without a new build. Also track the gap between a Guidewire release and the first failed transaction.
How does AI assist with this?
An insurance-trained model such as LiLa suggests how a sender’s fields line up with the carrier’s Guidewire structures. A person reviews and confirms every mapping before it goes live.
Does an intake layer replace Guidewire’s own Integration Gateway?
No. Guidewire’s gateway is a developer framework for integrations your team writes. An intake layer sits beside it and serves outside senders who map, test and send on their own.