Affordability and lending decisions

A blueprint for a lender’s affordability dashboard. Use it when a request combines average income and expenses, adjustable affordability thresholds and a decision workflow for applicants. Adapt the names and policy rules; keep the shape.

The page has three tabs that share one filter bar (product, region, channel):

Tab	Shows
Overview	Six headline cards with change and trend; income vs expenses by month and region; spending by income band; approval rate by credit band; a product table
Thresholds	Sliders for the policy; counts of applications passing and breaching each rule; the passing population’s figures
Decisions	A board of open applications by stage; an applicant file with checks and actions; pipeline and underwriter scorecard

Data model

One fact view at application grain, joined from an applicants table and a decisions table, plus an events table for the audit trail. Generate mock data in the warehouse when none is supplied, with realistic distributions (log-normal income, regional uplift, product-specific amounts and terms) so the charts have shape.

Store in the view, computed in the warehouse:

• Monthly net income and each expense category; essential and total expenses.
• Proposed repayment and a stressed repayment at a higher rate.
• Per-row ratios the sliders compare against: debt-to-income, expenses ÷ income, disposable income after the new repayment, and the same after the stressed repayment.
• 0/1 flags for counted states: approved, decided, open, passing the default policy.
• A month label, a quarter label, and bands with labels that sort in order.
• Workflow fields: stage, proposal, underwriter, approver, outcome, days open, days to decision.

Semantic layer

• Measures: applications (distinct count), averages of income and each expense, ratio measures such as debt-to-income as (SUM(debt) + SUM(repayment)) / SUM(income), approval rate as SUM(approved) / SUM(decided), lending requested, open applications, proposal-upheld rate, days to decision.
• Dimensions: product, region, channel, bands, month, quarter, stage and underwriter.
• Business questions: one per object family — headline figures, monthly trend, region, spending mix, credit band, product table, passing breakdowns, stage, underwriters, and one period comparison question each for month and quarter.

Build every object from those questions as described in Governed objects.

Thresholds tab

Sliders for maximum debt-to-income, minimum disposable income, minimum credit score and maximum expenses share, and a stress-test toggle that switches the disposable-income column to the stressed one. Each slider writes a range selection into a policy group; each rule also has its own group holding its breach range. The product, region and channel filters are mirrored into the policy group and every rule group, so all the counts cover the same applications. See Thresholds as selections.

Decisions tab

• Board. Columns for each open stage. Each card shows the applicant, product, amount and a pass, marginal or fail badge that compares the applicant’s stored ratios with the current slider values.
• Applicant file. A dialog with the request, the monthly budget, each check against the current thresholds, a suggested action and the audit trail queried from the events view for that applicant.
• Maker–checker actions. An underwriter proposes approve, decline, refer or a counter-offer with a required rationale. A different person with a large enough lending mandate approves, rejects or returns it. Nobody approves their own proposal.
• Persistence. A Data App can only read metadata and run queries (see Querying the engine), so actions taken on the page cannot be written to the warehouse from it. Keep them in the browser for a demonstration and say so on the page, or post them to a backend you own.

Verify

Beyond the acceptance checks, compare the passing count, the breach counts and the headline changes with direct warehouse queries at the same thresholds, and check that the latest month is complete before presenting its change.