Financial services · Lending

A clearer view of lending decisions.

Machine-learning loan scoring inside the lender’s own application workflow, saving about $24,000 a year, with a five-view dashboard for seeing how lending decisions play out.

PROJECTTill

MY ROLESoftware Engineer · Manifold

STAGEIn production · scoring API and dashboard

A dark dashboard with eight headline figures in two rows

The dashboard’s Overview. A local run of the dashboard’s own code with invented applicants, sources and figures; none of the numbers are the lender’s.

The context

A problem worth solving.

Loan scoring needs to fit into an existing application process, while the team needs visibility into scoring activity and loan performance.

My contribution

What I brought to the work.

Built a machine-learning scoring service that the lender’s application system calls, plus a dashboard for reviewing scoring activity, policy settings, lead sources and loan performance.

The product

What it makes possible.

Five parts follow, one per view of the dashboard. The scoring service itself has no screen; the dashboard shows what it decides. Each screen is a local run of the dashboard’s own code with invented applicants, sources and figures.

Machine-learning API · about $24K a year saved

Machine-learning scores returned inside the existing loan application workflow, saving about $24,000 a year.

Overview · see the activity

Review scoring activity and decision patterns in one place.

Policy settings · a recorded history

Review policy settings, with a recorded history of changes.

Lead Sources · compare channels

Explore where applications come from and how each source performs.

Funded History · follow performance

Review funded-loan history with clear reporting periods and funding definitions.

Scenario analysis · explore tradeoffs

Explore modeled exclusions alongside observed outcomes. Scenarios support investigation; they do not prove the effect of a policy change.

At a glance / simplified product view

01Loan application
02Machine-learning scoring
03Decision & reporting

Overview · see the activity

Live scoring, and the decision behind each number.

The Overview compares the chosen period with the one before: applications scored, accept rate and average score, then how funded loans went on to perform. Any recent decision opens to what was asked for, the credit scores, the score and the threshold it was held to.

A table of recent decisions with one row expanded into three panels — **One decision, opened**A recent decision with its application, its credit scores, the score and the threshold. Local run of the dashboard’s own code with invented applicants, sources and figures.

Five state cards above a daily bar chart in red and green — **By state, and day by day**Accept and deny counts and accept rate by state, above the daily volume scored, with the 30 days before shown for comparison. Local run of the dashboard’s own code with invented applicants, sources and figures.

Two line charts above two histograms — **Rate, score and margin**Accept rate and average score by day, with the previous period dashed, then the spread of scores and their margin to the threshold. Local run of the dashboard’s own code with invented applicants, sources and figures.

Cards per state above two multi-line charts — **How loans performed**Matured loans by state: observed net, first-payment misses and the share that were profitable, then both by month. Local run of the dashboard’s own code with invented applicants, sources and figures.

Policy settings · a recorded history

A threshold per state, and a log of every change.

Each state has one minimum score. A change is saved as a recorded action with who made it and when, and the log shows what was observed among loans funded before and after it, with a plain note on what that comparison can and cannot show.

Five state cards with a number each and a save button — **The policy editor**One value per state, changed with plus and minus and saved together, above the start of the change log. Local run of the dashboard’s own code with invented applicants, sources and figures.

A dated list of threshold changes with stricter and looser tags — **The change log**Every saved change with its date, who saved it, and whether it made the bar stricter or looser. Local run of the dashboard’s own code with invented applicants, sources and figures.

An expanded log entry with before and after figures and a caveat — **A change, opened**Missed first payments among loans funded before and after a change, with the dates compared and the limits of the comparison stated. Local run of the dashboard’s own code with invented applicants, sources and figures.

Scenario analysis · explore tradeoffs

Replay history against a stricter threshold.

Moving a state above its current threshold counts what the past would have looked like: loans excluded, profit forgone and losses avoided, and which lead sources the excluded band came from. It is historical evidence, not a forecast.

Four sliders above four headline figures and a list of sources — **The replay**Four states moved above their live thresholds: the loans excluded, the profit forgone and the losses avoided, then which lead sources the excluded band came from. Local run of the dashboard’s own code with invented applicants, sources and figures.

A heading above two explanatory notes and a period selector — **What the replay can and cannot say**The page states its own limits before any number: it replays loans that were funded and observed, it never writes a threshold, and it is historical evidence, not a forecast. Local run of the dashboard’s own code with invented applicants, sources and figures.

Lead Sources · compare channels

Where applications come from, and what each source is worth.

Lead Sources follows each source from volume to matured outcomes, and says how much of that volume has an observed result before it ranks anything.

Six source cards with a figure and a small trend line each — **Source financial trend**Each source’s observed net on matured loans, with how many of its funded loans have matured, its first-payment miss rate and a twelve-month trend. Local run of the dashboard’s own code with invented applicants, sources and figures.

A horizontal bar chart with one bar per source — **Volume and acceptance**Scored volume and acceptance by source. Local run of the dashboard’s own code with invented applicants, sources and figures.

A table of lead sources with counts, rates and state ticks — **Every source**Every source: volume, weekly accepted history, the latest seven operating days and the states it sends to. Local run of the dashboard’s own code with invented applicants, sources and figures.

A table of sources with volume, coverage and outcome columns — **The scorecard**Volume, maturity and realised outcomes by source in one table, with filters for source, year and state. Local run of the dashboard’s own code with invented applicants, sources and figures.

A dot-and-interval chart per source above a table — **Who comes back**Which sources’ customers go on to a second funded loan within a year, with the interval around each rate. Local run of the dashboard’s own code with invented applicants, sources and figures.

Funded History · follow performance

How funded loans performed over time.

Funded History separates a customer’s first loan from their later ones and follows both by month, state, sequence and timing, with the maturity rule stated on the page.

A large heading above two panels of figures — **First funding against later funding**The two populations side by side, with the share of loans that have a stable customer identity stated first. Local run of the dashboard’s own code with invented applicants, sources and figures.

Two line series above a monthly table — **Month by month**Average observed net per matured loan by month for both groups; months without matured outcomes are marked as unavailable. Local run of the dashboard’s own code with invented applicants, sources and figures.

Two bar charts above a table by funding sequence — **By funding sequence**Observed net and missed first payments by how many loans the customer has had. Local run of the dashboard’s own code with invented applicants, sources and figures.

A rising curve beside four status bars, above two tables — **When the next loan appears**How long after a first loan a second one appears, and the status the earlier loan was in. Local run of the dashboard’s own code with invented applicants, sources and figures.

Engineering choices

The decisions behind the interface.

Protect policy changes from conflicting edits.

The policy editor checks the latest saved state before applying a change, preserves unrelated edits and keeps a change history. An adjustment is a recorded action, not an invisible replacement.

Separate observation from simulation.

The analysis distinguishes observed funded outcomes from modeled exclusions. A scenario helps explore a decision; it is not presented as proof that a policy change caused an outcome.

These are documented implementation choices. Private policy settings, borrower information and model details are intentionally omitted.

Where it stands

In production, with clear next steps.

Scoring activity updates independently from imported loan-history data. Next steps focus on repeatable data refreshes and more precise links between policy changes and affected loans. The savings figure is my own estimate, not an audited number, and it is one part of the value: the dashboard’s five views show the team how scoring, policy settings and lead sources play out across funded loans.

Keep exploringStorefront requests