Your claims system receives data from senders who each chose their own delivery style. A TPA drops one large file after a storm, a vendor calls an API for every claim change, and a source system fires an event when a status flips.

ClaimCenter applies its rules to every record, no matter how the record arrived. What changes is when each rule fires, how many records are in play at once, and who finds out when one fails.

This article gives Guidewire architects and claims leaders a way to choose. It compares the three arrival styles, shows where each fits claims and policy data, and sets out what the receiving side must handle for each.

Which arrival style fits which kind of claims and policy data?

Batch files fit large volumes the receiver can wait for, real-time APIs fit changes a person is waiting on, and events fit one change that must reach several systems. Most carriers need all three, because claims and policy data do not behave alike.

The sections below start with what each style delivers, then give a three-question test for choosing between them.

What does each style deliver?

The three styles differ in who starts the transfer and how much arrives per delivery. The table sets them side by side.

How do you choose? The Arrival Fit Test

The Arrival Fit Test is three questions asked about one data flow, in order. The answers point to a style for that flow, not for the whole carrier.

1. Who is waiting? If an adjuster or policyholder needs the result now, use a real-time API. If nobody reads the result until morning, a file is acceptable.

2. How big is one delivery? If a single send holds thousands of records, a file location beats an API body. If each send is one claim or one policy, a call per record fits.

3. What happens to one bad record? If a single failure must be visible and fixable at once, use an API. If the sender can correct a rejected line and resend only that line, a file works.

Where do claims and policy data split?

Claims data is bursty. Volume sits low for weeks and then jumps after a storm, so claims flows need both a per-record path and a large-drop path.

Policy data is steadier, but its timing controls claims. A claim cannot be created against a policy that was not in force on the loss date, so a reinstatement waiting in a nightly file leaves the policy out of force in the claims system when the FNOL arrives. Policy changes that gate claims belong on the faster path, even when the rest of the policy feed runs in batch.

When does a batch file still beat an API call?

A batch file wins when one delivery carries more records than a call-per-record loop handles cleanly. The size of the delivery, not the age of the technology, decides it.

The two subsections below cover large drops and what a batch hides from you.

Why does a catastrophe drop favor a file?

After a storm, a TPA holds a large set of FNOL records and wants to send them together. Looping one API call per record multiplies network calls, retries and rate-limit exposure at the worst possible moment.

Passing a file location instead of an API body keeps the call small, while the receiver pulls the content. This is the same logic behind TPAs sending catastrophe FNOL data in a flat file.

What does a batch hide from you?

A file arrives as one object, but ClaimCenter judges it as many records. One rejected line among thousands is easy to lose if the only signal is “file received.”

A batch design needs a per-record result, not a per-file result. Without it, the sender learns about failures when an adjuster calls to ask where a claim went.

Does a batch suit stale-checksum updates?

A batch built overnight carries the claim versions that existed when it was built. Claims systems use checksums to stop lost updates, so an update built on an outdated version is rejected.

A file holding several changes to the same claim repeats the problem inside one delivery. Batch is the wrong style for fast-changing claims and the right one for large, settled sets.

What does real-time API arrival demand from the claims system?

A real-time API gives each record its own answer, and that is also its cost. Every rule the claims system enforces becomes a response the sender must read and act on.

The subsections below follow a claim through intake and later change, then cover the policy side.

Why is FNOL more than one call?

Creating a claim can take several calls, such as creating a draft and then submitting it. Each sender has to build and maintain every step, and the claims system rejects submissions that do not reach the required validation level.

This is the work behind claims intake from TPAs, brokers and vendors. An API sender that skips one step produces a draft that never becomes a claim.

What goes wrong with updates, closures and reopenings?

Claims keep changing after first notice of loss. Claim updates, closures and reopenings each run into their own rule, and an out-of-order call returns an error instead of a result.

A claim usually cannot close while exposures or activities remain open. A claim must be reopened before its exposures, and a reopening can require a reason and a note in a format the system accepts.

What changes for policy data over an API?

Policy changes such as endorsements, cancellations and reinstatements arrive one at a time and must land in sequence. PolicyCenter accepts a change against a policy period, so a sender that sends a cancellation before the endorsement it depends on gets a rejection.

The API style gives the sender an immediate answer, which suits policy changes that gate claims. It also puts the sequencing burden on the sender.

Does deployment change what an outside sender can call?

Yes. On-premises and cloud APIs differ in what an outside integration can reach and how it authenticates and versions its calls.

A carrier on one deployment model cannot hand the same sender instructions that work on the other. Settle this before you publish an arrival specification to senders.

Where do events fit when your system is the receiver?

An event is a trigger, not a delivery format. A sender’s system announces that something changed, and some other mechanism then moves the data.

The subsections below explain what an event does and does not carry, and where it sits in a wider architecture.

What does an event carry?

An event carries a notice, often an identifier and a status, and not the full claim or policy. The receiver still needs a call or a file to get the data that the notice describes.

A sender can use an event on its own side to decide when to call your API or drop a file. From the carrier’s side, what reaches the claims system is still a payload.

What do events require from the receiver?

Event systems commonly deliver a notice more than once, and not always in order. A receiver that applies each notice as a new instruction creates duplicate claims or applies a closure before the update it follows.

The receiver needs a way to recognize a repeat and to hold a change until its predecessor lands. This is the same ordering discipline the claim closure and reopening rules already demand.

How does this fit a composable architecture?

Events earn their place in composable, API-first architectures, where many services react to one change. A single policy issuance can notify billing, document and reporting services at once.

Guidewire also has its own product called Integration Gateway, which is a developer framework. It is separate from Yazh, the InsOps gateway, which adds a self-service portal and a test harness for the people who send you data.

How should a carrier choose and run the mix?

Choose per data flow, not per carrier, and put one contract in front of every flow. Senders can then pick the arrival style that suits their volume while the claims system sees consistent data.

The subsections below cover the contract at the door, the effect of siloed systems, and the measures that show whether the mix works.

What is the one contract at the door?

The contract states mandatory fields, valid values and sequencing rules, and applies the same way to a file line, an API call and an event-triggered send. A record that fails the contract is rejected at the door and returned to the sender.

This matters most on the policy side, where submissions fail on first receipt because required data is missing, not because of the delivery style.

Why do silos change the answer?

Policy, claims and billing data often live in different systems, and each system has its own tolerance for lag and its own validation rules. Data silos in P&C insurance explain why one arrival style rarely fits all three.

Map each system’s tolerance first. Then assign styles to flows, so a reinstatement and a bulk claim file do not compete for the same path.

What should you measure?

Track the share of records rejected at the door by sender, the time from a sender’s send to a confirmed result in the claims system, and the count of records that failed without anyone noticing. Add the number of senders that need a custom build to deliver.

A rising unnoticed-failure count is the clearest sign that a batch flow lacks per-record results.

How InsOps Helps

Yazh (Yaal), the InsOps Integration Gateway, is a data exchange platform for inbound data into Guidewire PolicyCenter, ClaimCenter and BillingCenter. A sender maps its payload once, and Yazh translates it into your Guidewire format, whether the payload arrives in an API body or as a file location for large payloads.

LiLa, our 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, handles changes to a payload or a Guidewire release, and supports tenant-specific mapping.

Senders get a self-service portal, a test harness and a sandbox, so they test before real data arrives. If you are deciding how claims and policy data should reach your Guidewire instance without a new connector for each sender, contact us to talk through what this could look like for your operation.

Frequently Asked Questions

What is the difference between batch file, real-time API and event-driven data transfer in insurance?

A batch file delivers many records in one transfer, a real-time API delivers one record or change per call, and an event delivers a notice that something changed. The first two move data, while the third usually triggers a move.

Why does the arrival style matter for claims and policy data?

The style decides when the claims system’s rules fire and who sees a failure. It also decides whether a late policy change leaves the claims system working from stale policy status.

How do I decide between a batch file and an API for claims data?

Ask who is waiting, how big one delivery is, and what happens to one bad record. Large settled sets with a corrective path for single lines suit files, and changes a person is waiting on suit APIs.

What is the biggest challenge with batch files into ClaimCenter?

A file is one object but ClaimCenter judges it as many records, so a single rejected line is easy to miss. You need a per-record result returned to the sender, not only a file-received signal.

What are the common challenges of real-time API delivery for claims?

Senders must make several calls to create one claim and must handle checksum rejections on updates, closure rules and reopening order. Each rule returns an error that the sender’s code has to interpret.

Do events replace batch files and APIs?

No. An event announces a change but rarely carries the full record, so a call or a file still moves the data. Receivers also have to handle repeated and out-of-order notices.

What should we measure to know the arrival mix is working?

Measure rejection rate by sender, time from send to a confirmed result, records that failed unnoticed, and senders that still need a custom build. Falling counts on the last two show the contract at the door is doing its job.

How does Yazh assist with different arrival styles?

Yazh takes a mapped payload from a sender, in an API body or as a file location for large payloads, and translates it to your Guidewire format. LiLa assists with the mapping and a person reviews every mapping before use.