A carrier signs a TPA to handle a book of claims, and the first notice of loss (FNOL) arrives in a format ClaimCenter cannot use. Fields are missing, loss codes do not match the carrier’s valid values, and the claim opens with gaps an adjuster chases by phone.
The cause is rarely the TPA’s effort. The carrier handed over a field list, not a specification, so nobody wrote down what a complete, acceptable FNOL looks like.
This guide is for claims leaders and Guidewire integration architects. It sets out six clauses to put in writing before a TPA sends routine FNOL into Guidewire ClaimCenter. Catastrophe surge is out of scope.
What should a carrier specify before a TPA sends its first FNOL into ClaimCenter?
Specify six things in writing: what one payload represents, how it matches the policy, which fields and values are mandatory, how parties and files travel, what comes back, and how the TPA proves it is ready.
Each of these decisions belongs to someone on the carrier side. Leaving any of them open means the TPA decides it for you, and each TPA decides differently.
Why a field list is not a specification
A field list names what the TPA should send. A specification also names the rules: which fields block the claim from opening, which values ClaimCenter accepts, and what the sender sees when a payload fails.
Many TPAs send FNOL from a vendor platform rather than their own code, so the document has to bind the workbench vendors behind the TPA as well. Write it for the system that sends the payload, not only the team that signed the contract.
The six-clause FNOL feed specification
The table below is a working checklist. Each row is one clause, with the decision it settles and the carrier role that owns it.
Clause | What it settles | Owner |
|---|---|---|
1. Scope and identity | What one payload means, the claim reference, the duplicate rule | Claims lead |
2. Policy and loss match | Policy lookup keys, the loss date rule, what happens on no match | Claims lead and architect |
3. Mandatory fields and valid values | Required content, accepted codes, carrier-specific fields | Claims lead |
4. Parties and documents | Contact roles, file delivery, large attachments | Architect |
5. Response contract | Acknowledgement, claim number returned, rejection reasons | Architect |
6. Test and change rules | Sandbox, sample payloads, payload and release changes | Both |
How should the FNOL payload identify the claim, the policy and the loss?
A payload should carry one loss, one TPA claim reference, and the keys ClaimCenter needs to find the policy. These three identifiers decide whether the claim opens cleanly or lands in a manual queue.
Settle them first, because every later clause depends on them.
One payload, one claim, one reference
State that each payload creates exactly one claim and carries the TPA’s own claim number. That number travels with every later message, so updates, closures and reopenings land on the claim they belong to.
Write down who owns the number once ClaimCenter issues its own. The spec should say the carrier claim number is returned to the TPA and stored beside the TPA reference.
Matching the policy and the loss date
Name the lookup keys. A policy number alone often fails when formats differ, so list the fallback keys, such as insured name and loss location.
Then state the loss date rule. The loss date must fall inside the policy period, and the spec should say what the sender receives when it does not.
Handling duplicate FNOL
The same loss reaches the carrier from the insured, the broker and the TPA. Define the duplicate rule in the spec, naming the fields that mark two reports as one loss.
Catastrophe surge is a different design problem, covered in how TPAs send catastrophe FNOL data into ClaimCenter. This guide stays with routine daily volume.
Which fields are mandatory, and which values does ClaimCenter accept?
Mandatory fields are the ones without which an adjuster cannot work the claim. Valid values are the codes ClaimCenter accepts for each field, and they rarely match the TPA’s internal codes.
Settle both in the spec, field by field, with the claims lead signing off.
Mandatory fields by group
Group the required content so the TPA can check its own payload before sending. The table lists the groups most carriers require at FNOL.
Group | Required content |
|---|---|
Loss details | Loss date, loss type, loss cause, description of the loss |
Loss location | Street address, city, state, postal code |
Reporter and insured | Name, role, contact details |
Policy reference | Policy number and any fallback keys |
Involved party or item | Claimant, vehicle, property or injured person, by line of business |
Valid values and code translation
ClaimCenter validates loss type and loss cause against its own lists of accepted values. A TPA that sends “WTR” where the carrier expects a named water-damage cause gets a rejection.
Publish the accepted values in the spec, or state the translation rule. Without one of the two, every TPA invents its own mapping and every error becomes a support ticket.
Carrier-specific fields
Most carriers add fields beyond the standard set, such as a program code or a handling-office flag. List these as separate, labeled items so a sender can tell required carrier fields from standard ones.
This keeps carrier differences visible. A second TPA then reads the same spec and sees which fields are yours alone.
How should the spec handle parties, documents and large attachments?
Name every party role the carrier requires, and state how files arrive. Both decisions shape the payload more than any single field does.
Parties and contact roles
List the roles an FNOL must carry: insured, reporter, claimant, and any witness or provider the line of business needs. For each role, state the minimum contact details.
State what happens when a person appears twice under different roles. Silence here produces duplicate contacts in ClaimCenter.
Documents, photos and large payloads
FNOL often arrives with photos, police reports and estimates. The spec should name accepted file types, a naming rule, and the point where a file stops travelling inside the payload and travels by file location instead.
A payload that carries a pointer to a file, not the file itself, keeps the request small and the response fast. Define the pointer format in the spec.
Where your Guidewire environment shapes the spec
Endpoints, authentication and release timing differ between Guidewire cloud and on-premises APIs. Record which environment the TPA is sending into, so its architect does not guess.
Add the release schedule too. A sender that knows when your instance changes can plan its own testing around it.
What should ClaimCenter send back, and how does a TPA prove it is ready?
The response contract tells the sender what happened to every payload. The readiness test shows the carrier that the sender can meet the spec before real claims arrive.
The response contract
Specify three outcomes: accepted with the carrier claim number, rejected with a named reason, and held for a duplicate review. A rejection should name the failing field and the rule it broke, in words the TPA’s staff can act on.
Incomplete data should stop at the door. A rejected payload costs the sender a correction; a half-filled claim costs an adjuster a phone call.
Sandbox and sample payloads
Give the TPA a place to test before real data moves. The spec should list the sample payloads the carrier expects to see pass: a clean claim, a claim with a missing mandatory field, a claim with an unaccepted code, and a duplicate.
Agree the pass criteria in writing. The TPA then knows exactly when its feed is ready, and the carrier knows exactly what it approved.
Payload changes and Guidewire releases
Payloads change when a TPA adds a field, and Guidewire changes with each release. The spec should say who tells whom, how far ahead, and where the change is tested first.
Carriers that skip this clause end up maintaining a custom connector for each sender, which is the cost a written spec exists to avoid. The wider question is how senders send data into Guidewire without building a connector for every carrier they serve.
How InsOps Helps
Yazh (Yaal), the InsOps Integration Gateway, lets a TPA map its FNOL payload once. Yazh translates it into the format your ClaimCenter expects. LiLa, the InsOps insurance-trained model, assists with the mapping, and a person on your team reviews every mapping before it is used.
Yazh rejects incomplete data at the door, so a gap is reported to the sender instead of becoming a half-filled claim. Senders use a self-service portal and a sandbox with a test harness to test before real data is sent. Carrier-specific fields are handled through tenant-specific mapping, and large attachments travel by file location.
Yazh handles inbound data exchange into ClaimCenter, PolicyCenter and BillingCenter. It sits beside Guidewire’s own Integration Gateway, a developer framework for building integrations, and adds the mapping, review, test and rejection steps so no separate connector is written for each sender.
If you are defining what a TPA must send into ClaimCenter without building a new connector for each one, contact us to walk through your FNOL feed requirements.
Frequently Asked Questions
What is an FNOL feed specification?
It is the written agreement between a carrier and a TPA on what one FNOL payload contains, which fields and values are mandatory, and what the carrier returns. It covers rules and responses, not only field names.
Why does a TPA’s FNOL need a written specification before go-live?
Without one, each TPA decides for itself how to match policies, fill codes and handle duplicates. The carrier then finds out at the first live claim, when an adjuster is already waiting on a complete file.
Which fields should be mandatory in an FNOL payload?
Require the loss date, loss type, loss cause, loss location, reporter, and a policy reference with fallback keys. Add the involved party or item for the line of business, since an adjuster cannot start work without them.
How should a carrier handle codes that differ from the TPA’s?
Publish the accepted values for each coded field, or state the translation rule. The TPA maps its codes to yours once, and a person on the carrier side reviews that mapping before any live claim uses it.
What should ClaimCenter return when an FNOL is rejected?
It should return the failing field, the rule it broke, and a reason the TPA’s staff can act on. A reason such as “validation error” sends the sender back to the carrier for help.
Which metrics show the feed is working?
Track the share of payloads accepted on first send, rejection counts by field, claims opened with missing data, and duplicate claims created. A falling rejection count on one field points to a clause in the spec that needs rewording.
How does Yazh assist with a TPA’s FNOL feed?
LiLa suggests how the TPA’s fields map to your ClaimCenter format, and a person on your team reviews each mapping before it is used. Yazh then rejects incomplete data and lets the sender test in a sandbox first.
What does a realistic rollout look like?
Start with one TPA and one line of business. Agree the spec, run the sample payloads in the sandbox, confirm the pass criteria, and only then open the feed to live claims. Add the next TPA by reusing the same spec.