When a catastrophe hits, the first strain is not the adjuster roster. It is the path every first notice of loss takes into ClaimCenter, because each sender delivers records in its own format and all of them arrive at once.
A carrier that has not defined a complete claim record, mapped each sender, and tested the path finds the gaps during the event. They show up as stalled files and rework while the queue grows.
This article covers what the carrier’s data layer needs before a surge: where intake breaks first, what to define and map in advance, how to rehearse, and a five-point check to run before the next season.
How Do Carriers Handle a Claims Surge During a Catastrophe Event?
Carriers handle a surge by scaling two things: the people who work claims and the path data takes into the claims system. The second has to be built before the event, because nobody can build it while volume is arriving.
Guidewire’s March 2026 catastrophe response blog reports that claim volumes can spike tenfold or more within hours of an event. The same post describes ClaimCenter as the operational hub during that period.
That volume does not arrive in one tidy format. It comes from TPAs, field adjusting firms, vendors, portals, and call center systems, each with its own layout.
Staffing Scales, Data Paths Do Not
Adding adjusters is a staffing decision that can be made after the storm. The data path is a design decision that cannot.
A temporary adjuster can start on a claim the day it is assigned. A sender feed that was never mapped cannot start at all, because its records either meet ClaimCenter’s required fields and valid values or they do not.
Your claims intake path therefore needs a written definition of a complete record before volume arrives, not after the first rejected file.
Where Intake Stalls First
Three failure points show up before any adjuster touches a file. Records arrive missing mandatory fields. Sender formats show up that nobody has mapped, and files exceed the size the interface accepts.
Each one is a data layer problem with a fix that exists before the event. The rest of this article takes them in order.
What Must the Carrier’s Data Layer Hold Before a Surge?
Before a surge, the data layer needs three things in place: a written definition of a complete claim record, a reviewed mapping for each sender, and a rule that returns incomplete records to the sender.
Each one is a decision made in advance, and each has an owner.
Define a Complete Claim Record
Claims leaders own this definition. For a catastrophe claim, the mandatory fields and valid values include items such as loss date, loss location, cause of loss, and a claimant contact, set per sender type.
A claim also needs a policy reference, and claims, policy, and billing data live in different systems. Matching them happens at intake or it happens later as manual rework.
Map Each Sender Once
A mapping ties each field a sender uses to the field ClaimCenter expects. Build it once per sender and reuse it on every send, so a new sender does not trigger a new custom connector.
AI can propose the matches, and a person reviews every one before it is used. That is the practical meaning of human-reviewed mapping: the proposal gives the reviewer a starting point, and the decision stays with someone who knows what the field means.
Reject Gaps at the Door
A record missing a mandatory field should go back to the sender with the reason named. The sender corrects it, and no adjuster opens a file that cannot be worked.
Broker submissions fail on first receipt for the same reason, and the fix carries over to claims: return the gap to the sender at the door.
Which Feeds Reach the Data Layer First During a CAT Event?
Surge volume reaches the data layer through the channels a carrier already uses, plus the ones it adds for the event. Each channel needs its own mapping and its own definition of a complete record.
TPAs and Field Adjusting Firms
When a carrier brings in a TPA for a surge, the TPA sends first notice of loss in whatever format its own system exports. That format has to be mapped before it becomes a ClaimCenter claim.
We cover the sender’s side in a separate post on how a TPA sends a flat file of catastrophe FNOL into ClaimCenter. This post covers what the carrier needs ready to receive it.
Flat Files and Structured Payloads
A flat file carries rows. A structured payload carries a claim with its parties and exposures nested inside it, which is the shape ClaimCenter works on, so a flat file needs a mapping before it becomes claims.
Decide per sender which shape it will use, and map that shape before the season. The trade-offs between flat files and structured payloads are worth settling while no event is open.
Large Batches
A surge produces files too large to send as an API request body. The sender places the file at an agreed location and sends that location, and the data layer collects it from there.
This route, sending large payloads by file location, needs rehearsal like any other, because the first oversized file should not be a real one.
How Can a Carrier Rehearse Intake Before the Storm?
A carrier rehearses intake by giving each sender a sandbox, running known payloads through a test harness, and reading the rejections with the sender before real data arrives.
Sandbox and Test Harness
A sandbox accepts a sender’s test data without touching your production Guidewire ClaimCenter. A test harness runs payloads you know the answer to, complete ones and deliberately broken ones, and shows what came back.
Include the routes beyond first notice. A surge also carries claim updates, closures, and reopening, and each rides the same data layer.
Tenant-Specific Fields
Your ClaimCenter has custom fields and valid values that no other carrier shares. Tenant-specific mapping keeps those differences inside the mapping, so each sender’s payload stays the same across carriers.
A claim also touches policy and billing, so tenant rules have to hold across Guidewire products, not only in the claims system.
Changes Between Rehearsal and Storm
Senders add fields, and Guidewire releases change what ClaimCenter expects. Rehearse one change on purpose: alter a payload in the sandbox and confirm the mapping holds or flags the difference.
Do this on a schedule, not once. A mapping that passed in spring has to be proven again before the season opens.
The Surge-Ready Intake Check
The Surge-Ready Intake Check turns the sections above into five checks that a claims leader and an integration architect can run together. Each check has an owner and a visible result.
The Five Checks
Check | What the data layer needs | What fails without it |
|---|---|---|
1. Define | Mandatory fields and valid values written per sender type | Records open with blanks and adjusters chase the gaps |
2. Map | One reviewed mapping per sender | Each new sender waits on a custom connector |
3. Reject | Incomplete records returned to the sender with the reason named | Files that cannot be worked reach adjusters |
4. Rehearse | Sandbox and test harness runs, including one large file | The first test of the path happens during the event |
5. Hold | Mappings that follow payload and Guidewire release changes | Feeds break between rehearsal and storm |
Running the Check
Run it per sender, not per carrier. Take the sender that would send the most records in an event through all five checks, then repeat for the next.
Claims leaders own the first check because it defines what complete means. Integration architects own the other four. Review the results together before the season opens.
How InsOps Helps
InsOps built Yazh (Yaal), the InsOps Integration Gateway, a data exchange platform for inbound data into Guidewire PolicyCenter, ClaimCenter, and BillingCenter. A sender maps its payload once, and Yazh translates it to your Guidewire format. LiLa, the InsOps insurance-trained model, assists the mapping, and a person reviews every mapping before it is used.
Yazh gives senders a self-service portal, a sandbox, and a test harness. It rejects incomplete data, applies tenant-specific mapping, handles changes to a payload or a Guidewire release, and takes large payloads sent by file location.
Guidewire has its own product also called Integration Gateway, which is a developer framework. Yazh sits beside it and adds the mapping editor, the sender portal, and the test harness.
If you are evaluating how to get ready for the next surge without a custom connector for every sender, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What is catastrophe claims intake?
Catastrophe claims intake is the receipt of first notice of loss and related claim data during a CAT event, from every channel that reports losses, and its conversion into claims in the carrier’s system of record. The data layer performs that conversion.
Why does the data layer matter during a claims surge?
Records reach ClaimCenter only if they pass the data layer. Records that fail on missing fields or unmapped formats stop there, and no adjuster sees them.
How should a carrier prepare its data layer before a CAT event?
Define a complete claim record for each sender type, map each sender once with a person reviewing the mapping, reject incomplete records at the door, and rehearse in a sandbox. The Surge-Ready Intake Check in this article lists all five steps.
What breaks first at intake during a CAT surge?
Missing mandatory fields, unmapped sender formats, and files too large for an API request body break first. Each has a fix that is set up before the event.
How does a carrier know its intake layer is ready?
Track four measures: senders with a reviewed mapping, senders who have completed a sandbox run, rejection reasons returned to senders, and whether a large file has passed through the file-location route in test.
How does AI assist with CAT intake mapping?
AI assists by proposing matches between a sender’s fields and ClaimCenter’s fields. A person reviews every mapping before it is used, and the data layer rejects records that fail the carrier’s rules.
How far ahead of CAT season should a carrier start?
Start before the season opens, with one sender and one claim type. Run it through the sandbox, fix what the test harness shows, then add senders one at a time. The pace depends on how many senders you have and how customized your ClaimCenter is, and the first sender sets the template for the rest.