Money & affordability
Before a loan can be granted, the household has to be able to carry it. The affordability engine takes the same State you have been reading about and turns it into a handful of key figures — how much is left to live on, and how large the debt is against income. This section explains why one application produces many analysis objects, what each figure means, and what the decision does with them.
One calculation, run many ways
An affordability result is an array of HOUSEHOLD_AFFORDABILITY_ANALYSIS objects. It looks like a lot at first — but every object is the same calculation seen from a different angle. Four ideas make the whole array read cleanly.
Two passes: today vs. if-approved
The engine runs a baseline pass — the household as it is today — and a scenario pass for the future being applied for. Comparing the two is the whole point: what does this loan do to the household?
Each pass covers several periods
Affordability is not a single snapshot. Every pass carries a series of periods — this year, a year-by-year projection, and the worstyear — so a good first year can’t hide a tight one later.
Four key figures, one waterfall
From gross income the engine subtracts tax, then fixed costs, then standardised living costs. What survives is the household’s affordability — the money left to live on. A fifth figure, debtDegree, sizes debt against income.
Built from the same State
Nothing new to model: incomes, expenses, assets and loans on root state feed the baseline; the scenario’s changes[] feed the if-approved pass. Affordability is just State, run through a calc.
Baseline × scenario × period
The number of analysis objects is just contexts × periods. Two contexts, a handful of periods each — that is the whole array.
The household as it is today
Current income, current expenses, current debts. No applied-for loan. This is the reference point — where the household stands before anything changes.
The household if this is approved
The same start, with the scenario’s changes[] applied — the new mortgage granted, an old loan redeemed. One scenario pass per proposed future, each tagged context: "SCENARIO".
Each object’s id reads <case>::<context>::<seq> — so FRIDA-NILS::SCENARIO::4 is the fifth analysis of the scenario pass. And within each pass, the affordability[] array holds one entry per period:
The engine reports every period so the decision never rests on one rosy year. The WORST period — the projected year with the least money left to live on — is the one that typically governs the outcome.
From gross income to what’s left to live on
The four keyFiguresare a single waterfall down the household’s yearly money. Here it is for Frida & Nils — two salaries, one household — first with no new loan (baseline), then with the 1 500 000 kr mortgage they are applying for (scenario).
The gap between the two columns is the loan. Income and tax do not move; what changes is the financing cost — 97 500 kr of interest (at the 6.5%calculation rate, not the day’s offer rate) plus 15 000 kr of amortisation — and the extra housing cost of the new home. The money left to live on drops accordingly, and debtDegree rises from 0 to 1.74.
The same figures, in the payload
One analysis object, trimmed to the fields worth reading. Flip between the two passes: the shape is identical — only the numbers, the debt, the financingExpenses and the context tag differ.
Empty branches (wealth, pension, per-person detail) are trimmed here for readability; the real object carries the full breakdown behind each sum. The partyId, assetId and financingId values are the same ids that stitch the rest of the model together — hover one to trace it.
How the decision uses the numbers
Affordability does not decide anything on its own — it produces the figures that the credit rules read. Three of them do most of the work.
Can they carry it?
The money left to live on (liquidityAfterHouseholdExpenses) must stay positive in the worst year — the household can still cover everyday life after the loan. Norway frames the same test as betjeningsevne, a liquidity indicator that must clear a floor.
Is the debt too large?
debtDegree — skuldkvot in Sweden, gjeldsgrad in Norway — sizes total debt against gross income. Norway caps it at 5×; Sweden uses it (with LTV) to set how much extra the household must amortise.
Does it survive a shock?
The figures already use a calculation rate well above the offered rate (6.5%+ in Sweden; the customer rate +3 pp with a floor in Norway), so the household is tested against rate rises up front.
Those thresholds live in the DMN tables on the Decisions & resolvers page — a rule reads keyFigures.liquidityAfterHouseholdExpenses or debtDegreefrom the scenario’s worst period and returns GREEN, YELLOW, BLUE or RED. Affordability supplies the numbers; the decision layer supplies the judgement.