A broker sends a submission and an underwriter opens it. The first task is to find out what is missing. The named insured is there, the requested limits are not, and the state field says “Texas” where the policy system expects “TX”.
Nothing in the file says whether this counts as complete, because most carriers never wrote the definition down. Each underwriter applies a private checklist, and brokers learn the rules one returned file at a time.
This article shows how underwriters define a complete submission with three tests, how to choose mandatory fields, how to set valid values for each one, and how to enforce the definition at the door.
What Makes a Broker Submission Complete?
A complete submission is one an underwriter can quote without a follow-up to the broker: mandatory fields are present, values are valid, and fields agree with each other.
That standard is a rule the carrier writes down, not a judgment each underwriter forms after reading the file. Without the written rule, two underwriters can open the same submission and reach opposite verdicts.
What an Unwritten Definition Costs
The cost shows up in volume. Submissions that stall on missing information never reach a quote.
In Canadian commercial lines, about 60% of submissions an insurer or MGA receives never get quoted, according to a July 2026 Canadian Underwriter handbook article that names incomplete submissions as the leading reason.
One underwriting executive quoted in the same piece points to a common gap: submissions that arrive with no requested limits or coverages.
The Three-Test Definition of Complete
A written definition needs only three tests. Each has a yes-or-no answer a system can check, so no underwriter judgment is needed at the door.
Test | Question it answers | Example of a failure |
|---|---|---|
Presence | Is every mandatory field filled? | Requested limits left blank |
Validity | Is each value one the policy system accepts? | “Texas” where “TX” is required |
Consistency | Do the fields agree with each other? | Expiration date earlier than effective date |
A submission is complete only when it passes all three. A file that passes two and fails one goes back to the sender.
Which Fields Should Be Mandatory?
Mandatory means the underwriter cannot quote without the field. Every other field is a request, not a requirement, and mixing the two makes forms long and invites placeholder answers.
Start From What Stops a Quote
Your own history gives the best starting list. Work from the submissions underwriters already sent back to brokers.
Pull the submissions underwriters returned to brokers.
Record the field the underwriter asked for in each case.
Group those requests by line of business.
Mark a field mandatory when its absence stops a quote.
Mark every other field optional.
The result is a list built from real quoting needs, not from the layout of a form.
Mandatory, Conditional, and Optional Fields
Three tiers keep the mandatory list short. A conditional tier handles fields that matter only in some cases.
Tier | Rule | Example |
|---|---|---|
Mandatory | Always required | Named insured, effective date, line of business, requested limits |
Conditional | Required when another field triggers it | Loss history on new business, not on a renewal |
Optional | Helpful, never blocks a quote | The insured’s website |
Line of Business Changes the List
One mandatory list for every line forces either gaps or noise. Write one list per line instead.
Property needs construction, occupancy, protection and exposure details, often shortened to COPE. General liability needs a description of operations and a revenue or payroll basis. Commercial auto needs a driver and vehicle schedule.
What Counts as a Valid Value?
A field can be filled and still be wrong. A valid value is one the policy system accepts without a manual fix, in the format and from the list the carrier defines.
Why Values Fail Even When Fields Are Filled
Brokers describe coverage in their own words, and the policy system expects a code. “Bldg & Contents” is a fair label to a broker and an invalid value to a system that expects a coverage code from its own list.
Each carrier keeps its own lists, so a broker sending to five carriers faces five sets of valid values.
Write Each Rule So a System Can Check It
A rule such as “use a standard date” cannot be checked. A rule such as “calendar date in YYYY-MM-DD format” can.
Field | Valid value rule | Example of a failure |
|---|---|---|
State | Two-letter code from the approved list | “Texas” |
Effective date | Real calendar date in the required format | A day that does not exist |
Coverage type | Code from the carrier’s coverage list | A broker’s own label |
Producer code | Active code the carrier issued | A retired or mistyped code |
Every row names the rule and a failing example. Brokers can test their own data against a rule written this way before they send anything.
How Do Underwriters Write the Definition Down?
A definition only works when senders can read it and systems can check it. Underwriting owns the content, and the format has to suit both audiences.
One Spec, One Owner
Keep one field dictionary. Each entry holds the field name, its tier, the valid values, one example, and the underwriter who owns the rule.
Publish the dictionary at the point where senders deliver data, which is submission intake. A definition kept in a shared drive reaches nobody.
Test the Spec on Real Submissions
Before publishing, run last quarter’s submissions through the three tests. Every disagreement either fixes the spec or exposes bad data.
Include submissions underwriters accepted. If the spec rejects a file an underwriter quoted without trouble, the spec is too strict.
Update the Spec Before Anything Else Changes
A new mandatory field, a retired code, or a policy system release each change what complete means. Update the dictionary first, then tell senders.
Version every change with a date, so a broker can see which rule applied to a given submission.
What Happens When a Submission Fails the Definition?
The definition matters only if it is enforced where data arrives. A failed file that still reaches an underwriter’s queue costs the same time as having no rules.
Return the Gaps at the Door
Reject a failing submission before an underwriter opens it. The sender gets the file back with the gaps listed, and the underwriter never sees it.
The same rule holds for claims intake, where a claims system will not create a claim against a policy that was not in force on the loss date.
Tell the Sender Exactly What to Fix
“Incomplete” is not a useful message. Each rejection names the field, the rule it broke, and the values the carrier accepts.
A sender who gets that message fixes the file once and resubmits. A sender who gets a generic note writes to the underwriter.
Track First-Pass Completeness
Three numbers show whether the definition works: the share of submissions that pass all three tests on the first send, the fields that fail most often, and the time between receipt and a quotable file.
A field that fails often is either badly worded in the spec or badly understood by senders. Either way, it is the next thing to fix.
How InsOps Helps
InsOps builds an insurance-trained AI that assists with moving partner data into Guidewire. Yazh (Yaal), the InsOps Integration Gateway, lets a sender map its payload once, and Yazh translates it to your Guidewire PolicyCenter format. LiLa, our insurance-trained LLM, drafts the field mapping, and a person reviews every mapping before it is used.
Your mandatory fields and valid values become the rules the gateway enforces. Payloads with gaps are rejected and returned to the sender to complete, and each sender’s values are mapped to the codes your policy system expects.
Senders register in a self-service portal and test in a sandbox with a test harness before they send real data. When a payload or a Guidewire release changes, the mapping changes in one place, so your definition of complete stays intact.
If you are evaluating how to enforce your own definition of a complete submission without building a connector for every sender, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What is a complete submission?
It is a submission an underwriter can quote without asking the broker for anything further. It passes three written tests: every mandatory field is present, every value is valid, and the fields agree with each other.
Why do mandatory fields and valid values matter?
They turn an underwriter’s private checklist into a rule every broker can read and every system can check. Submissions then fail at the door, not after an underwriter has spent time on them.
How do you decide which fields are mandatory?
Start from the submissions underwriters sent back to brokers and record which field each one lacked. Mark a field mandatory only when its absence stops a quote, and group the list by line of business.
What are the common challenges in enforcing the definition?
Brokers use their own labels, each carrier keeps its own value lists, and the spec drifts when forms or policy system releases change. Naming one owner and versioning every change addresses the drift.
Which metrics show the definition is working?
Track the first-pass completeness rate, the most frequently failed fields, and the time from receipt to a quotable file. A falling count of follow-up requests to brokers confirms the same trend.
How does InsOps assist with enforcing mandatory fields and valid values?
Yazh gives each sender a self-service portal and a sandbox, and LiLa drafts the mapping from the sender’s payload to your Guidewire format. A person reviews every mapping, and payloads with gaps go back to the sender to complete.
How is Yazh different from Guidewire’s own Integration Gateway?
Guidewire’s Integration Gateway is a developer framework for building integration apps. Yazh is a data exchange route where a sender maps once and the carrier receives data in its Guidewire format, with human-reviewed mapping.
How long does it take to put a definition in place?
Begin with one line of business and the sent-back submissions you already hold, then test the draft on real files before publishing. The common pitfalls are making every field mandatory, naming no owner, and skipping version control.