Everyone talks about submission extraction. The harder problem — and the one where the operational value is actually larger — is appetite automation. Knowing what the submission contains is the first step. Knowing whether that submission fits your book, and routing it accordingly in seconds rather than days, is where the competitive advantage lives.
Appetite rules are the filters a carrier applies to incoming submissions: the parameters that determine whether a risk is a candidate for quoting, should be referred to senior underwriter review, or should be declined without further analysis. For a specialty lines carrier, these rules encode the accumulated judgment of the underwriting team about which risks they write, under what conditions, and at what limits.
Why appetite rules are hard to formalize
The challenge with appetite automation is that carrier appetite rules exist in three forms, and only one of them is easily machine-readable.
The first form is written policy: the formal underwriting guidelines document that specifies authorized operations, ineligible classes, binding authority limits, required information for specific risk types, and so on. Most carriers have some version of this document. It's a reasonable starting point for appetite formalization, but it is not complete.
The second form is institutional knowledge: the things every underwriter on the team knows about what the carrier will and won't write, which aren't in the guidelines because they've never been written down. "We don't write frame construction habitational in coastal Georgia" might be in the guidelines. "We'll quote frame construction habitational in coastal Georgia if the insured has a documented hurricane mitigation program and the prior carrier issued without claims for five years" probably isn't — it's judgment that lives in the heads of the senior underwriters who have learned the exceptions to the rules from experience.
The third form is current market signal: appetite that's shifted in response to loss experience, reinsurance cost changes, or regulatory developments that haven't yet made it into updated guidelines. A carrier that experienced adverse loss development in a specific contractor class in 2024 may have told their underwriting team to hold back on that class, but hasn't issued a formal guideline update. New submissions in that class are being declined on an undocumented basis.
The documentation problem in practice
Consider the practical situation when building an automated appetite triage system for a mid-size E&S casualty carrier: asking the underwriting team to describe their appetite rules for a specific class — say, hospitality GL — the first response is a page of formal guidelines. The second conversation, digging into edge cases, reveals fifteen additional rules based on experience that aren't in any document: "we don't write hotels with bars unless the bar revenue is under 25% of total revenue," "we'll quote motels with weekly rates but not daily rates unless they're in a tourist corridor," "any loss history with an assault and battery claim gets a senior underwriter review, not a standard quote." These rules are real and consistently applied — they just weren't written down.
Building a useful automated triage system requires going through that elicitation process for every significant risk class. It typically takes weeks of structured conversations with the underwriting team, multiple rounds of refinement as edge cases surface that the initial formalization missed, and an ongoing update process as appetite evolves.
We're not saying this process is straightforward or that it's a one-time effort. It is not. Appetite is a living body of knowledge that changes with market conditions, loss experience, and reinsurance economics. Any automated appetite system needs a governance process for keeping the rule set current — which itself requires underwriter engagement on an ongoing basis.
What rule representation looks like technically
Appetite rules for specialty lines aren't simple boolean conditions. They have structured patterns that require different technical representations:
Hard stops: Classes or conditions that always result in declination regardless of other factors. "NAIC 81219 (Other Personal Services) not eligible" or "Prior carrier non-renewal for underwriting reasons requires SVP Underwriting approval." These map cleanly to rule conditions.
Conditional qualifications: Rules that apply in combination with other conditions. "Restaurants with liquor sales exceeding 50% of gross revenue require assault and battery coverage review." These require structured expression of the conditional relationship — not just a flag for the risk class, but a flag for the risk class when a specific numeric condition is met.
Soft flags for referral: Conditions that don't decline but route to a different workflow. "Frame construction habitational over $5M TIV requires senior underwriter pricing sign-off." These require workflow routing logic, not just accept/decline outputs.
Loss history pattern rules: "More than two losses exceeding $50,000 in a three-year period requires SVP review." These require the extracted loss run data to be analyzed structurally before the appetite rule can be evaluated.
That last category is why extraction quality matters for appetite automation. An appetite rule that depends on loss history pattern analysis is only as good as the extraction that feeds it. If the loss run extraction produces unreliable figures for large-loss identification, the rule produces unreliable routing decisions.
The market signal problem and model freshness
Appetite that's changed but hasn't been formally documented represents a specific technical challenge. An automated triage system running on month-old guidelines that doesn't reflect a recent appetite shift will approve submissions for classes the carrier has pulled back on — effectively letting business into the underwriting queue that senior underwriters will decline, wasting everyone's time.
The practical approach to this problem combines two mechanisms. First, a lightweight guideline update workflow — when appetite changes, the update gets captured in the automated system's rule set promptly, not only in a quarterly guidelines document revision cycle. Second, monitoring of referral patterns: if the automated triage is approving submissions for a risk class that underwriters are consistently declining on their own judgment, that pattern signals a gap between the automated rules and current appetite that needs to be addressed.
The referral queue as accuracy signal
The most valuable output of an automated appetite triage system isn't the declines — it's the referrals. A well-designed triage system pushes clearly ineligible submissions out of the queue quickly, routes clearly eligible submissions to the appropriate underwriting tier, and creates a referral queue for submissions that fall in the gray zones where the documented rules don't give a clear answer.
That referral queue, and how underwriters resolve the submissions in it, is the data that improves the rule set over time. If a specific condition consistently generates referrals that senior underwriters resolve the same way (always quote with a specific endorsement, always decline), that resolution pattern should be captured as a new rule rather than leaving the same routing decision to human judgment indefinitely.
Appetite automation done well is a feedback system, not a static filter. The rules improve as decisions are made, as long as the system captures those decisions and makes the improvement process tractable. That feedback loop is why appetite automation has more long-term value than extraction alone — extraction accuracy has a ceiling, while appetite rule quality improves continuously as the carrier's underwriting team uses the system and the system learns from how they work.
