Underwriting decisions that hold up when someone asks why
Two audiences with opposite questions: a tenant asking whether they qualify, a landlord asking whether the cover is real.
Context
Renting in the UK usually requires a guarantor who owns property here, which shuts out plenty of people who can comfortably afford the rent: students, people new to the country, the self-employed. guarantor4you stands in as that guarantor, which means assessing applicants at volume and carrying the cost when a tenancy goes wrong.
The problem
What happens when an applicant asks why they were declined, a year later? Three constraints pulled in the same direction. A decision has to be reconstructable long after the person who made it has moved on, which rules out anything that quietly overwrites. It has to be exact, because a borderline case settled by a rounding error is one nobody can defend to the applicant it affected. And UK data protection law gives people the right not to be subject to a purely automated decision that significantly affects them, being declined a home qualifies, so a website that quietly decides is a legal exposure rather than a design preference.
What we did
We put each rule at the level that can actually enforce it, on the principle that a rule everyone agrees to is a rule that holds until somebody is in a hurry. The record of decisions cannot be edited by anyone, the client included; a correction is a new entry that says so. The person who checks a claim can never be the person who approves it. Money is handled exactly rather than approximately, so a threshold means what it says. And the public site stops short of deciding on purpose: it tells a visitor whether they look likely to qualify, and a person makes the decision.
What we built
A public site, an applicant journey, an underwriting console, a rules engine, an exposure ledger and the claims process behind them.
Eligibility check
Four questions on the public site return Likely, Possible or Unlikely, with the thresholds used to reach it shown in money. The multipliers are configuration rather than literals, so they move with the rulebook. It runs in the browser, stores nothing, and is labelled as an indication rather than a decision.
Five applicant categories
Student, recent graduate, employed, self-employed and not currently working. The category is derived from the applicant’s answers and drives the paperwork they are asked for and the rules applied to them. The list is configuration, so adding a sixth is additive.
Document requirements by situation
Each category has its own document list, so an applicant sees only the papers their situation calls for rather than a generic checklist.
Application journey and account
Applicants sign in with a six-digit code sent by email, complete the application, upload their documents and follow the status of their case from the same account.
Document handling
Uploads go to object storage. File type is validated on the server rather than trusted from the browser, and documents are not reachable from a public URL.
Underwriting console
Cases arrive in a worklist for the underwriting team with the application, the documents and the rule results attached, and are reviewed and decided from there.
Rules engine with bands and decision traces
Twelve rules, A1 to A12, place a case in a band. Each assessment records a trace of which rules ran, what they returned and which values they used, so any outcome can be reconstructed later. A case landing within ten per cent of a threshold is referred to a person rather than decided automatically.
Exposure ledger and portfolio caps
Every guarantee issued is recorded against total exposure, and caps limit how much the book carries in any one segment. Amounts use exact money arithmetic with their own rounding rules.
Issuance, arrears, claims and recovery
Approved cases produce a signed guarantee. Arrears are tracked against it, claims are validated and approved separately, and recovery is followed through to settlement.
Fraud checks and document extraction
Submitted documents are read for the values the rules need, and checked for the common signs of alteration and reuse before a case reaches assessment.
Staff access control
Roles deny by default, two-factor authentication is required to sign in, and the person who reviews a case cannot be the person who approves it. Conflicts are detected rather than left to process.
Append-only audit log
Every decision, issuance and payment is recorded and cannot be updated or deleted, enforced by the database itself. Corrections are recorded as new entries.
Landlord and letting agent pages
Separate explanations of the guarantee, what it covers, the cap and how a claim works, written for the landlord rather than the tenant.
Results
An applicant finds out in about a minute whether applying is worth their time, and is told which papers to send. The underwriting team works from a queue rather than an inbox, and every decision carries the trace that produced it. Guarantees, arrears and claims are tracked against a single exposure ledger, and the record of what happened cannot be rewritten.
More work
All case studies
Got a project that looks like this?
Tell us what you're trying to build, or what has stalled. We'll tell you honestly whether we're the right people for it.