A wildfire, hailstorm, or hurricane hits, and within days a third party administrator holds one flat file with 20,000 first notices of loss. The carrier runs Guidewire ClaimCenter. The file is a spreadsheet export with its own column names, its own date formats, and no connection to ClaimCenter at all.
Every hour that file waits, policyholders wait for an adjuster. Re-keying 20,000 rows is not realistic, and a script written at midnight sends its errors straight into the adjuster queue.
This guide explains why catastrophe FNOL files fail at the ClaimCenter boundary, how to prepare and validate the data, which options exist for getting it in, and how to confirm the load worked.
What Happens When a Catastrophe Produces 20,000 Claims in One File?
A catastrophe turns claim intake into a bulk data problem. Notices arrive through call centers, portals, and field adjusters, and the TPA consolidates them into one export. The carrier's claims system expects something very different from a row.
Why Does the TPA's File Not Match ClaimCenter's Structure?
Guidewire documents the ClaimCenter Cloud API as a set of REST endpoints that outside applications call to create and change claims. For FNOL, the documented path posts a draft claim and then submits it.
A flat file has none of that shape. One row holds the claimant, the loss location, the cause of loss, and the policy reference side by side. ClaimCenter models contacts, incidents, and exposures as separate, related resources.
How Big Does a Catastrophe File Get?
Swiss Re Institute estimated US insured natural catastrophe losses at USD 89 billion for 2025, which is 83% of the global USD 107 billion total. The figures are preliminary estimates published on December 16, 2025.
At the event level, the California Department of Insurance reported 22,847 residential property claims from the Eaton Fire alone as of July 2026. Those claims spread across every insurer reporting to the department, and each carrier's share still arrives as a file of its own.
Why Does Speed Matter Before the File Loads?
Until a claim exists in ClaimCenter, no adjuster can be assigned, no reserve can be set, and no one can sort it by severity. Practices for triaging claims when volume spikes all start from the same point: the claims must be in the system first.
The data load is therefore the first step of the response, not a back-office task that follows it.
Why Do Catastrophe Flat Files Fail at ClaimCenter's Door?
Most failures come from four places. None of them is exotic, and each repeats at 20,000 rows what a small test file hides at 20.
Fields That Mean Different Things in Each System
A TPA's "cause" column holds free text or an internal code. ClaimCenter expects coded values, which Guidewire documents as typelists. Every cause, peril, and status in the file needs a defined match.
Dates cause the same trouble. A loss date without a time zone, or a time stored as text, lands in the wrong place or fails validation. Addresses split differently across systems, so one street line in the file becomes several fields in ClaimCenter.
Policy Matching
A claim needs a policy. Guidewire documents two paths: a claim against a verified policy, and a claim against an unverified policy that meets stated minimum criteria.
A TPA file needs either a policy number that matches the carrier's records or enough policy detail to meet those criteria. Rows with neither stall until someone resolves them by hand.
Duplicates and Re-Sends
The same loss gets reported twice, once by phone and once by portal. A load that fails halfway gets sent again from the top. Both create duplicate claims, and an adjuster discovers the duplicate after starting work on it.
Guidewire's Cloud API documentation includes a section on preventing duplicate database transactions. The sender still needs a stable claim reference on every row, so a re-send updates a claim instead of creating a second one.
Missing Required Data
Catastrophe intake collects data under pressure. Loss dates, loss locations, and contact details go missing, and a row without them cannot become a usable claim. The question is where the gap surfaces: at the sender before the file moves, or in an adjuster's queue after.
How Do TPAs Prepare Catastrophe FNOL Data for ClaimCenter?
The preparation follows a fixed order. Doing the work in this sequence keeps a large file from turning into a pile of exceptions.
Agree on the Catastrophe Record First
ClaimCenter's Cloud API includes catastrophe resources with zones and perils. The carrier creates the catastrophe record, and the TPA tags every claim in the file to it.
Settle three items with the carrier before the first export: the catastrophe identifier, the loss date window, and the contact who confirms exceptions.
Map Each Field Once
Payload mapping matches each field in a sender's data to the field Guidewire expects, so a submission or claim lands in the right place on the first send.
Build the mapping as a table, with one row per source column. List the target field, the coded value match, and the rule for blanks. Build it once and reuse it for every future event.
Validate Before Anything Moves
Run the full file against the mapping before sending a single row. Check for missing required fields, unmatched coded values, unparseable dates, and rows with no policy match.
Return the failures to the TPA's intake team as a list with the row number and the reason. A fixable gap costs minutes at the sender and hours once it reaches an adjuster.
Send in Batches You Can Reconcile
Guidewire's documentation covers batch requests, composite requests, and asynchronous calls for reducing call volume. A 20,000-row file moves best in batches sized so the counts can be checked after each one.
Record how many rows left the sender, how many claims ClaimCenter created, and how many were rejected. The three numbers must add up after every batch.
What Are the Options for Getting Catastrophe FNOL Data Into ClaimCenter?
A TPA sending claims to a Guidewire carrier has three realistic routes. The table compares them on the factors that decide the choice.
Factor | Carrier-run flat-file load | Custom-built connector | Prebuilt route with configurable mapping |
|---|---|---|---|
Setup effort | Low for the sender, high for the carrier | High: Guidewire learning, build, testing | Moderate: mapping review and confirmation |
Upkeep | Carrier scripts need rework after changes | Sender maintains it through every upgrade | Mapping updates when a target field changes |
Handling of incomplete data | Found after the load | Depends on what the builder wrote | Flagged before data reaches an adjuster |
Fit for catastrophe volume | Repeats manual steps each event | Strong once built and tested | Strong once the mapping is confirmed |
Scales to many carriers | Each carrier needs its own process | Each carrier needs its own build | One setup with a mapping per carrier |
Carrier-Run Flat-File Load
The carrier's team writes a script or batch job that reads the file and calls ClaimCenter. It works for a single trading partner. It strains when five TPAs each send a different layout during the same event.
Custom-Built Connector
The sender builds its own route into ClaimCenter. The build produces full control, and it carries the full cost of learning Guidewire's structures and keeping up with every carrier upgrade.
Prebuilt Route With Configurable Mapping
The sender brings its payload and configures a mapping inside a route that already exists. The learning burden shifts from the sender's engineers to a mapping review that the sender's own administrator confirms.
How to Choose
Count the carriers on Guidewire and the events per year. A TPA with one carrier and one layout can live with a flat-file load. A TPA with several Guidewire carriers needs a route that does not repeat the build each time.
How Do You Know the Catastrophe FNOL Load Worked?
A finished load is not the same as a correct load. Four checks separate the two.
Counts Reconcile and Duplicates Stay Near Zero
Rows sent equal claims created plus claims rejected, with no unexplained difference. This is the first check, and it takes minutes.
Then sample claims by policy number and loss date. Two claims for the same policy and the same date deserve a look before adjusters are assigned.
Rejects Return With Reasons
Every rejected row comes back to the sender with a plain reason and a row number. A reject list that says only "error" produces a second round of guessing.
The Record Survives an Audit
Every request, every response, and every error needs a log entry that someone can read later. When a question comes up about how a claim entered the system, the log answers it.
Time From File Receipt to Adjuster Assignment
Measure the hours between the TPA's file landing and the first adjuster assignment. This is the number that tells the carrier whether the intake path works under catastrophe volume.
How InsOps Helps
InsOps builds an insurance-trained AI that assists with moving claims data into Guidewire. LiLa, our insurance-trained LLM, drafts the mapping, and a person validates it before deployment.
The InsOps Integration Gateway connects to Guidewire ClaimCenter so TPAs and vendors can send FNOL and claim data into your workflow without custom engineering. Senders register in a self-service portal, bring their payload, and configure it. The gateway runs inside your own environment, so PII and PHI stay in controlled infrastructure.
The gateway flags incomplete claim data before it reaches an adjuster, so gaps go back to the sender instead of into the queue. Large payloads travel as a file location, and a dashboard records every request, response, and error.
InsOps is a Guidewire technology partner with prebuilt connectors to Guidewire's core products. If you are evaluating how to take catastrophe FNOL files from TPAs into ClaimCenter without a custom build, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What is catastrophe FNOL data?
Catastrophe FNOL data is the set of first notices of loss that a single event produces, such as a wildfire, hailstorm, or hurricane. It arrives in bulk, often as one export from a TPA, and each notice must become its own claim.
Why do catastrophe claims need a different intake path than routine claims?
Routine intake handles claims one at a time, and a catastrophe delivers thousands at once from several channels. The intake path has to validate, match, and reconcile at file level.
How do TPAs send FNOL data into ClaimCenter?
A TPA maps its fields to the structures ClaimCenter expects, validates the file, and sends it through the ClaimCenter Cloud API in batches. The carrier's team or a prebuilt route handles the call to ClaimCenter, and the TPA reconciles counts after each batch.
What goes wrong when a flat file loads into ClaimCenter?
The common failures are unmatched coded values, dates without time zones, claims with no policy match, and duplicates from re-sent files. Each one surfaces faster when the file is validated before it moves.
Which metrics show that a catastrophe FNOL load worked?
Track rows sent against claims created and rejected, the duplicate count, the share of rejects returned with a reason, and the hours from file receipt to first adjuster assignment. Reconciled counts come first, because every other number depends on them.
How does the InsOps Integration Gateway help?
The InsOps Integration Gateway gives TPAs and vendors a prebuilt route into Guidewire ClaimCenter, with LiLa drafting the field mapping from the sender's payload. A person at the sender reviews and confirms every mapping before any data moves.
What does a realistic timeline for a TPA feed look like?
Plan three stages: mapping and confirmation, a test load with a small sample, and a full-volume rehearsal before the next catastrophe season. The mapping review sets the pace, so start it before an event, not during one.