Underwriting issues
An underwriting issue (UW issue) is raised when a rule finds something that needs review: a young driver with a powerful car, a sum insured above a threshold, prior claims, a risk in a flood zone. Each issue is created from an issue type that defines:
- a code and a description shown to the user,
- the blocking point — how far the job may go before the issue must be resolved,
- whether it compares a value (e.g. sum insured 8M against a limit),
- default approval behaviour, such as how long an approval lasts and whether it survives later changes.
Issues are evaluated again every time the job moves forward. If the data changes so the condition no longer applies, the issue goes away on its own.
Blocking points
The blocking point decides where the job stops:
| Blocking point | Effect | Typical use |
|---|---|---|
| Blocks quote | No premium can be shown until approved | Risks outside appetite that need an underwriter to price them |
| Blocks quote release | Premium is calculated but not shown to the agent or customer | Internal review of price before it leaves the building |
| Blocks bind | Can quote, cannot bind | Most referrals: "quote it, but an underwriter signs off" |
| Blocks issuance | Can bind, cannot issue | Missing documents, inspection still pending |
| Non-blocking | Informational only | Flags for later review or reporting |
Authority profiles
Who may approve an issue is controlled by underwriting authority profiles. A profile lists issue types and, for value-based types, the maximum value the holder may approve. Users get one or more profiles.
Agent profile
Can approve "young driver" up to a car value of 300,000. Can't approve any flood-zone issues.
Senior underwriter
Can approve "young driver" with no limit and "flood zone" up to a sum insured of 10M.
If the current user can't approve an issue, they request approval. PolicyCenter assigns the job to an underwriter (often via an underwriting group queue) and creates an activity. The underwriter can approve, approve with conditions (special approval), reject, or send it back with questions.
A referral end to end
- AgentQuoteRule raises "sum insured above agent limit" — blocks bind.
- AgentRequest approvalAdds a note explaining the risk.
- UnderwriterReviewActivity on desktop; reviews risk, may edit terms.
- UnderwriterApproveOptionally with an expiry or "valid until value changes".
- AgentBindJob continues; approval is stored with the policy.
An approval can be set to survive later jobs (so the renewal doesn't re-refer the same thing) or to be re-evaluated if a value changes beyond a tolerance. Getting this right is what stops underwriters drowning in repeat referrals every renewal.
Where the rules come from
Underwriting rules are typically implemented as Gosu evaluators that check the policy and raise issues by type code. Some releases also offer business-user tools for authoring simpler rules without code. Either way, a good UW requirement says:
- Condition — exactly what data triggers it, at which job types, from which effective date.
- Issue type and blocking point.
- Who can approve, with value thresholds per authority level.
- Approval durability — does it carry over to changes and renewals?
- Message — the short and long description users will see.
Avoid "the system should refer risky cases". Write the threshold as data: "Raise UW-HIGH-SI if Building.SumInsured > 8,000,000 DKK on Submission, PolicyChange and Renewal; blocks bind; Senior UW may approve up to 15M; approval holds while SI changes by less than 10%."
Declines, withdrawals and risk analysis
- The Risk analysis screen on a job lists all UW issues, their status, approvals and history, plus prior losses and policy history.
- An underwriter can decline a submission (the insurer says no) — the job ends with a reason that may be sent to the agent.
- An agent can withdraw a submission or mark it not taken when the customer goes elsewhere. These reasons feed quote-to-bind reporting.