An underwriter opens a broker submission and goes straight to the fields that drive the quote. The prior-loss block is empty, a class code is not on the carrier’s list, or the producer code matches nothing in the system. The file goes back to the sender by email, and the review starts over.
That rework is a front-door problem, not an underwriting problem. A submission that fails the carrier’s own requirements should go back to the sender at receipt, before it joins an underwriter’s queue.
This guide covers how to write down what “complete” means, where to enforce it, what the sender sees when a submission is returned, and how to tell the door is working.
Why do incomplete submissions reach underwriters at all?
Carriers publish submission requirements, yet underwriters still open files that miss them. The gap sits between what the carrier requires and what the intake route checks.
The endpoint accepts the call but not the meaning
An API endpoint defines where data arrives. It does not define what a sender’s data means, so the call succeeds while the payload leaves out fields the carrier needs.
The submission then lands in Guidewire PolicyCenter as a record, and nobody finds the gap until a person reads the file.
Completeness lives in underwriters’ heads
Most carriers hold their definition of complete as habit. Underwriters know which blanks stop a quote, but the intake layer does not know it.
Every file is therefore checked by a person, at the point where a check costs the most.
What does “complete” mean in terms a system can check?
A system rejects only what someone wrote down. The job here is to turn the underwriter’s habit into rules that a gateway applies to every submission.
Mandatory fields
Start with presence. List the fields an underwriter needs before quoting a line of business, and mark each one mandatory.
Keep one list per line of business. The fields a commercial property submission requires differ from those of a personal auto submission.
Valid values
A filled field with the wrong value is as incomplete as a blank one. Class codes, state codes, coverage types and limits arrive in each sender’s own labels, and the carrier accepts only specific codes.
Store the valid values next to the mandatory fields, so presence and correctness are checked together.
Producer and structure checks
Two more checks belong at receipt. The first confirms the producer code is one the carrier recognizes, which is part of submission clearance.
The second confirms the payload has the shape the carrier expects. The table shows the four checks and the reason a sender would see for each.
Check | Question it answers | Example return reason |
|---|---|---|
Presence | Is every mandatory field filled? | Prior loss history is missing |
Valid value | Does the value match a code the carrier accepts? | Class code is not on the carrier’s list |
Producer | Is the producer code one the carrier recognizes? | Producer code not found |
Structure | Does the payload match the expected shape? | Coverage block is missing from the payload |
Who owns the list
Underwriting owns the definition of complete, and the integration team owns enforcement. Assign one owner per line of business, and route every change to the list through that owner.
Without a named owner, the list drifts away from what underwriters actually need.
Where should a carrier reject an incomplete submission?
A gap is found in one of three places: at receipt, in the intake queue, or after an underwriter opens the file. Only the first keeps the gap out of the queue entirely.
Rejecting at receipt
At receipt, the gateway checks the payload against the carrier’s requirements before the data reaches the policy system. A payload with gaps goes back to the sender, and nothing enters the queue.
This is the core job of submission intake for a carrier that takes data from many senders.
Rejecting after the file is opened
Every later checkpoint costs more because a person is already involved. The table compares the three points.
Where the gap is found | Who finds it | What happens next |
|---|---|---|
At receipt | The gateway | The sender completes the payload; nothing enters the queue |
In the intake queue | Intake staff | Staff email the sender while the file waits |
After an underwriter opens it | The underwriter | The underwriter stops, emails the sender, and restarts the review |
How does the sender find out, and how does the sender fix it?
Rejection only works if the sender can act on it. Treat the return as part of the process rather than an error.
Use this four-step door rule:
Define. Write the mandatory fields and valid values for each line of business.
Check. Apply those rules to every payload at receipt.
Return. Send the payload back with the reason for each gap.
Retest. Let the sender fix the payload and test it again before sending real data.
Return the payload with a reason the sender can act on
A return that says “invalid submission” sends the sender back to the carrier’s support desk. A return that names the missing field or the unaccepted value lets the sender fix it alone.
Senders already face one build per carrier, a problem covered in how senders send submission data into Guidewire PolicyCenter without building a connector.
Let senders test before real data moves
A sandbox lets a sender run a payload through the same checks the carrier applies and read the results. Failures show up in testing rather than on a live submission.
Software vendors that send for many MGAs need this most, as shown in how underwriting workbench vendors reach a carrier’s Guidewire instance without a build team.
Handle requirement changes in one place
Requirements change. A carrier adds a mandatory field for a line, or retires a code from the valid list.
If each sender hard-codes the old rule, every change reaches every sender’s build. That is the work behind maintaining a Guidewire connector, and the door should absorb it.
How do you know the door is working?
You know it works when underwriters stop finding gaps themselves. Track where gaps are caught, not only how many exist.
What to measure
Four measures show whether the door is doing its job:
The share of incomplete submissions caught at receipt compared with those an underwriter finds.
The most common return reasons, grouped by sender.
The number of resubmissions a sender needs before a payload passes.
The number of underwriter emails asking a sender for missing data.
A falling count of underwriter emails means the door is catching what underwriters used to catch.
Common pitfalls
Three pitfalls recur. Requirements set too strict on day one return good submissions and frustrate senders, so start with the fields that stop a quote.
Vague return reasons push senders back to the support desk. Rules applied to only one entry point leave a gap, including a single request that carries an account and a submission together, as in policy submission orchestration.
How InsOps Helps
InsOps builds Yazh (Yaal), the InsOps Integration Gateway, a data exchange platform for carriers on Guidewire. A sender maps its payload once, and Yazh translates it to the carrier’s Guidewire format. LiLa, our insurance-trained model, assists the mapping, and a person reviews every mapping before it is used.
As an insurance data exchange layer, Yazh brings inbound data into Guidewire PolicyCenter, ClaimCenter and BillingCenter. It rejects incomplete data, so a payload with gaps goes back to the sender to complete rather than entering your queue. Senders use a self-service portal and a test harness with a sandbox, and a dashboard shows what was sent, what arrived and what was rejected.
Guidewire has its own product called Integration Gateway, which is a developer framework. Yazh adds a place beside it where outside senders map, test and send without a separate build for each partner, with tenant-specific mapping for each carrier’s own fields.
If you are evaluating how to turn your underwriters’ definition of complete into a check at the door without adding another build for each sender, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What does it mean to reject an incomplete submission at the door?
It means checking each submission against the carrier’s mandatory fields and valid values at receipt and returning it to the sender before it reaches an underwriter’s queue. The check happens once, at the point of entry.
Why does rejecting at receipt matter for underwriters?
It removes the work of opening a file, finding the gap and chasing the sender. Underwriters receive only submissions that meet the carrier’s own requirements and spend their time on risk.
How does a carrier set it up?
Write the mandatory fields and valid values for each line of business, assign one owner per line, and apply the rules at the intake gateway. Give senders a sandbox so they test against the same rules before sending real data.
What are the common challenges?
The usual three are rules set too strict at the start, return reasons too vague to act on, and no named owner for the list. Start with the fields that stop a quote and name the specific gap in every return.
What should a carrier measure?
Track the share of gaps caught at receipt compared with those underwriters find, the top return reasons by sender, and the resubmissions each sender needs. The count of underwriter emails requesting missing data shows whether the door works.
How does Yazh assist with this?
Yazh rejects incomplete data at receipt and returns the payload to the sender to complete. LiLa assists the mapping, and a person reviews every mapping before it is used.
Does rejecting at the door replace underwriter judgment?
No. The door checks that a submission is complete and valid, and the underwriter still decides whether to quote the risk.