How underwriting works
Comparative underwriting evaluates a case against many products at once instead of one at a time, records the factors behind every decision, and routes a case that does not fit rather than losing it. Written for agents and for buyers who want to know how the answer was reached.
Comparative means all at once, not one at a time
The difference sounds academic until you watch a case get declined for a product it was never the right candidate for.
Traditional underwriting is sequential. A case is submitted to one product and evaluated against that product's rules. If it does not fit, the file comes back and somebody starts again somewhere else, usually days later and usually with a client who has already lost interest.
Comparative underwriting evaluates the case against many products at the same time and compares the outcomes before anything is presented. The engine is not asking whether this case fits this product. It is asking which of the available products this case actually belongs in.
That changes two things. The applicant gets the right fit rather than the first fit, which is a better outcome even when both are approvals. And when the answer is no, the alternative is already known, because the engine was reasoning about it the whole time.
Solved Insurance products are in development and pending state approval. This page describes the underwriting method we are building, not a product you can apply for. No decision rule, decision time, approval percentage, or rate class is published here. Join the waitlist to hear when coverage opens in your state.
The decision path
What happens to a case between the last question and the answer. Described as design intent for a product in development.
-
Intake, cleaned as it is collected
Identity, state, beneficiary, and the health questions. Medication names are recognized rather than taken literally, so a misspelling or a brand name the applicant read off a bottle resolves to the right drug instead of failing quietly and changing the outcome.
-
Adaptive questioning
The next question depends on the answers already given. An applicant who reports no conditions is not walked through a branch built for someone managing several, and an answer that opens a real question gets the follow-up it needs. Shorter for most people, more precise where precision matters.
-
Evaluation against many products at once
The case is reasoned about across the products available for that applicant in that state, in parallel, rather than being submitted to one and then another. The comparison happens before anything is presented, which is what makes the result a recommendation instead of a first hit.
-
The outcome, with its factors attached
The decision is recorded together with the factors that produced it and the alternatives that were considered. This is the part that makes the decision reviewable later, and it is written at the moment of the decision rather than reconstructed when somebody asks.
-
Routing when the fit is elsewhere
If the case belongs in a different product, that is the output. The agent is handed the alternative rather than a dead end, and the applicant hears where to go instead of hearing no. A declined case that nobody follows up on is a failure for the applicant and a lost placement for the agent.
-
Into enrollment without re-keying
What was collected during underwriting pre-fills the application, which is signed by text, tablet, or email through Solved Enroll. The record that produced the decision stays attached to the policy, so a servicing question or a claim years later does not start from a blank file.
A path, not a rulebook. We describe how a case moves and what the engine considers, and we do not publish the rules, the thresholds, or the conditions that change an outcome.
One engine, several kinds of insurance
The reasoning is shared. Only the product knowledge changes.
- Multi-product by design. The same core reasons about life, Medicare, and ancillary lines. A comparison engine that only understands one product is a quoting tool, not an underwriting method.
- Already in production somewhere. This core powers the AI Plan Recommender inside Solved Enroll, in private beta with agencies today. The life products it will underwrite for us are still in development.
- Built on real cases. The people who specified it sold final expense and Medicare for a living, so the awkward parts of a real fact-find shaped the design rather than being discovered after launch.
- One client record across the conversation. The fact-find that underwrote a life case is the record that quotes a Medicare plan, so nobody asks a client the same nine questions twice in one appointment.
- Patented method. The comparative underwriting method is patented. We describe what it does and decline to publish the rules it applies.
Explainability is a requirement, not a feature
An underwriting decision has to survive being questioned by someone who was not in the room.
The decision carries its reasons
Every outcome is stored with the factors that produced it and the alternatives that were weighed. Not a score on its own, and not a summary written afterward by someone trying to remember.
That record is what lets a decision be reviewed, audited, corrected, or defended. It is also what lets a pattern be found. A model nobody can interrogate is a model nobody can improve.
Why compliance requires it
Insurance is a regulated business, and an automated decision that affects a consumer has to be accountable. A department of insurance, a carrier partner, or the applicant can ask why, long after the conversation is over.
If the answer to why is only that the model said so, the method is not usable in this industry no matter how well it performs. Explainability was a design constraint from the beginning rather than a feature added to satisfy a reviewer.
A decision a human can still change. Automation removes the queue, not the accountability. The point of recording the factors is that a person can look at a case, see exactly what drove the outcome, and act on it. A method that cannot be checked cannot be trusted with something a family will rely on decades from now.
What a simplified issue questionnaire evaluates
In general terms, and deliberately no further than that.
| Medications | What the applicant currently takes. Medications are often a clearer signal than a self-reported condition, because people remember the bottle on the counter more reliably than the name of the diagnosis. Names are recognized and normalized rather than matched literally. |
|---|---|
| Conditions and their history | What has been diagnosed, when it was treated, and whether it is currently managed. Recency and management matter to the evaluation; a condition treated years ago and a condition being actively treated are not the same information. |
| Recent hospitalization or inpatient care | Whether there has been recent inpatient care, and in general terms what for. This is standard on simplified issue applications across the industry and is asked in plain language rather than clinical terms. |
| Tobacco use | Asked because it is a material factor in life underwriting everywhere, and answered honestly by an applicant who understands that a misstatement is a problem for their own family at claim time rather than for us. |
| The basics | Identity, state of residence, and the beneficiary. State matters throughout, because what is available and what applies is decided state by state. |
What we will not publish, and why. No knockout list, no condition thresholds, no decision rules, no rate classes, and no scoring logic. Two reasons. The first is that an underwriting manual on a public website teaches people how to answer, which is unfair to every applicant who answers honestly and makes the pool worse for every policyholder in it. The second is that the product is pending state approval, so the terms that will actually apply are the ones filed and approved. Anything published before that would be describing a product that does not exist yet.
Speed is a by-product, and routing is the point
Nobody set out to build a fast underwriter. We set out to build one that does not make a family wait for an answer someone already knows.
Most of the wait is queue, not analysis
In traditional simplified issue underwriting, very little of the elapsed time is spent thinking about the case. It is spent sitting in a queue, waiting on a record request, or waiting for someone to return a call. Removing the queue removes the wait, which is a structural change rather than a clever one.
A queue costs money, and the policyholder pays for it
Manual review of a simplified issue case is a real operating cost, and operating cost is one of the reasons a policy costs what it does. A decision made well without a review queue removes that cost from the process rather than removing it from the coverage.
An answer in the conversation is a better answer
The design target is a decision while the applicant is still in the conversation, because a pending file is where good intentions go to die. Someone who has to be called back next week frequently does not buy anything, from anyone, ever. We are not publishing a number of seconds, and a product pending approval has no measured decision time to publish.
Routed, not declined and lost
This is the outcome the whole method exists for. When a case does not fit, the comparison has already identified what does, so the applicant is pointed somewhere real and the agent keeps the placement. Selective underwriting keeps the risk pool honest, and routing is what makes selectivity fair to the person who was turned down.
Underwriting for products that are in development and pending state approval. What this means for agents
Read further
Final expense
The first product this underwriting is being built for.
ExploreHow it works
The same process, written for the person applying rather than the agent.
ExploreProducts and roadmap
Which lines the same engine is planned to underwrite next.
ExploreSolved Re
Why selective underwriting and persistency are the same conversation.
ExploreFAQs
Questions about underwriting
What does comparative underwriting actually mean?
Traditional underwriting is sequential. A case is evaluated against one product, and if it does not fit, someone starts over with the next one. Comparative underwriting evaluates the case against many products at once and compares the outcomes before anything is presented. The practical difference is that sequential underwriting finds the first fit, while comparative underwriting finds the right fit, and it knows what else the case qualifies for at the moment it decides.
Is any of this already running, or is it all theoretical?
The same underwriting core already powers the AI Plan Recommender inside Solved Enroll, which is in private beta with agencies today. That is Medicare rather than life, which is the point: the engine is multi-product, so the reasoning is shared and only the product knowledge differs. The Solved Insurance products it will underwrite are in development and pending state approval.
What does explainable underwriting mean, and why does it matter?
It means a decision carries the factors that produced it, recorded with the case, rather than arriving as a score with no account of itself. That matters because a regulator, a carrier partner, or an applicant can ask why months later, and the honest answer has to be retrievable rather than reconstructed. Compliance requires that, it does not merely prefer it, and a model that cannot explain itself is not usable in insurance regardless of how well it performs.
What does the health questionnaire look at?
In general terms: current medications, diagnosed conditions and how recently they were treated, recent hospitalization or inpatient care, and tobacco use. What we do not publish is the specific question set, the conditions that matter most, the thresholds, or the decision rules. Publishing an underwriting manual tells applicants how to answer, which is unfair to everyone who answers honestly and makes the risk pool worse for every policyholder in it.
What happens if my case does not fit the product?
It gets routed rather than declined and forgotten. Because the engine is comparative, it is already reasoning about other products while it evaluates the case, so the alternative is known at the moment of the decision. A person who came looking for coverage should leave the conversation with somewhere to go, and an agent should keep the placement rather than lose the case.
Why is an automated decision faster than a human one?
Because nothing is waiting in a queue. Most of the elapsed time in traditional simplified issue underwriting is not analysis, it is the case sitting in an inbox, waiting on records, or waiting for a callback. Removing the queue is what removes the wait. Speed is a by-product of that, not the goal, and we do not publish a decision time for a product that is still pending state approval.
Something else? Contact us
Hear when this underwriting goes to work
The products it is being built for are in development and pending state approval. The waitlist is how you hear when that changes.