AI Mortgage Tools
Two personal proof-of-concepts exploring AI-assisted mortgage processing with a locally-hosted Gemma model — document summarisation and affordability assessment, both built to run entirely offline.
Mortgage underwriters spend a lot of time on two repetitive tasks: reading long documents — application packs, valuation reports, offer condition letters, payslips — to extract what actually matters, and running affordability calculations against a moving target of UK income tax bands, National Insurance thresholds, and cost-of-living data that shifts every tax year. AI summarisation and AI-assisted affordability checks are the obvious answer to both.
The complication is that UK regulated financial services (FCA, GDPR, Consumer Duty) makes it hard to casually send customer financial data to a third-party API. Both tools exist to test a narrower question: can a fully local, offline model do this work well enough to be useful, without that data ever leaving the network?
Mortgage underwriters and processors handling long document review and affordability checks — the personas these were built to test, not a live product with real users yet. Proof-of-concept stage; production path would depend on a real employer's model-governance sign-off, which is outside the scope of a personal project.
Solo engineering team, alongside a full-time product role at TCS in UK mortgage technology — the day job gave me the problem context, but both of these are independent personal builds, not TCS deliverables.
These are two separate services sharing a theme, not one product — kept as one case study because the interesting parts (offline inference, structured domain data) are the same story told twice.
AI Summariser — one UI, two interchangeable backends. A shared demo UI toggles between a Node.js/Ollama backend (the easier path to run locally — adds document verification via PDF/DOCX upload and PDF export of summaries) and a Python/FastAPI backend using llama-cpp-python with Metal GPU offload on Apple Silicon for faster in-process inference, plus a mock mode for testing the API without loading the model at all. Both ultimately run Gemma 4 — the Node path calls it through the Ollama API, the Python path loads the GGUF weights (Q4_K_M, ~5GB) directly in-process. Prompts are domain-specific per document type: mortgage application, valuation report, offer conditions, payslip verification.
AI Affordability — rules as data, not as prompt strings. The Node.js/Express backend's promptBuilder.js detects application type (residential / buy_to_let / holiday_let) from the loan and property data, then filters a set of affordability rules down to the ones that actually apply before building the prompt. UK income tax bands (England & Wales and Scotland separately), employee and self-employed National Insurance thresholds, personal allowance tapering, and ONS household cost-of-living data all live as structured reference data pulled in via referenceData.js, not hardcoded into the prompt text. When a tax year changes, updating the tool is a data change, not a code change.
import { getAll } from './referenceData.js';
function fmt(n) { return Number(n).toLocaleString('en-GB'); }
function detectAppType(data) {
const purpose = data?.loan?.purpose;
const propType = data?.property?.type;
if (purpose === 'holiday_let' || propType === 'holiday_let') return 'hl';
if (purpose === 'buy_to_let' || propType === 'buy_to_let') return 'btl';
return 'residential';
}
function filterRules(rules, appType) {
return rules.filter(r => {
const t = r.applicable_to || ['all'];
return t.includes('all') || t.includes(appType);
});
}
function formatRules(rules) {
return rules.map(r => `[${r.category}] ${r.title}\n${r.text}`).join('\n\n');
}Both stayed at proof-of-concept — that decision belongs to whichever employer's model-governance process would need to sign off on production use, not something a personal project gets to decide on its own. What they did prove out: a Gemma 4 GGUF model with Metal GPU offload runs fast enough on a laptop for interactive document summarisation, and encoding UK tax and lending rules as structured reference data rather than prompt text makes the affordability tool's yearly maintenance trivial — swap a JSON file, not the code.