Risk-based pricing for lending with ML

Risk-based pricing sets each borrower’s rate from the estimated cost to serve them: probability of default, loss given default, funding cost, and a margin. Price with a model and you take on two jobs. You price accurately, and you explain to a regulator why one applicant pays more than another without that gap tracking a protected characteristic. Most of the engineering goes into the second job.

The temptation is to treat pricing as a single optimization: maximize expected margin subject to a booking-rate target, hand the objective to a gradient-boosted model, and let it find the rate. That produces a number no one can defend. A fair-lending examiner does not ask what your AUC is. They ask why this applicant, in this ZIP code, with this thin file, was quoted 240 basis points over the shelf rate, and they expect the answer to decompose cleanly.

Separate the risk price from the demand price

Keep the two forces apart in the architecture, not only in the write-up. Risk-based pricing has a floor set by expected loss and funding: that is the price you must charge to break even on the credit. On top of that floor sits the demand question, which is how much margin the market will bear before the applicant walks. These are different models with different inputs. Collapse them into one objective and trouble starts.

• The risk price comes from a PD model, an LGD model, and the funding curve. Its inputs are credit variables you can defend line by line, and it is the same for two applicants with the same risk regardless of who they are.
• The demand price comes from an elasticity estimate: how booking probability responds to the rate you quote. This is where price optimization lending actually happens, and it is where a proxy for a protected class can sneak in if you feed the demand model raw geography, device, or channel data without thinking.

The reason to split them is legal as much as technical. Under ECOA and Regulation B, disparate treatment and disparate impact are assessed against the price the applicant receives. If your elasticity layer marks up the rate for a segment that correlates with a protected class, you cannot cure it after the fact by pointing at the PD model. The markup has to be traceable to a permitted, business-justified variable. So we constrain the demand model’s feature set deliberately and log which features moved each quote.

Get the training data right before you touch the model

Point-in-time correctness matters more in pricing than in a pure risk score, because a pricing model is trained on booked loans, and booked loans are a censored sample. You only observe repayment for applications you approved and priced, at the price you happened to offer. That selection is structural, not sampling noise you can average out, and it biases elasticity estimates toward whatever your old pricing policy did.

A few things we insist on in the data layer:

• Reconstruct every feature as of the decision timestamp. A credit-bureau attribute pulled today is a lookahead into repayment behavior the model would not have had at quote time. Leakage here inflates offline metrics and collapses in production.
• Keep lineage from each training row back to the raw application and the exact price offered. When an examiner questions a decision eighteen months later, you need to reproduce the inputs, not approximate them.
• Correct for the censoring. Randomized price tests inside a narrow, approved band give you the cleanest elasticity signal. Where you cannot randomize, inverse-propensity weighting on the historical offer policy is the fallback, and you document its assumptions.

Quarter-end reprices and funding-cost moves also break naive training splits. If your funding curve shifted in March, a model trained across the shift learns an average that fits neither regime. Segment by funding environment or feed the funding cost as an explicit input rather than letting the model infer it from the calendar.

Make every quote decompose and log it

The pricing system should output a rate plus a decomposition of it: this many basis points of expected loss, this much funding, this much operating cost, this much margin, and the margin itself split into a base component and an elasticity-driven one. If you cannot produce that breakdown for an arbitrary historical quote, the system is a black box that happens to emit numbers, and it will not survive a review.

We build the decomposition as a first-class artifact, written to the audit trail on every decision alongside the model versions and feature values that produced it. That record is what a fair-lending review runs on. It also lets you monitor for the drift that matters here: whether the distribution of margin is widening for any segment over time, which tells you more than a headline accuracy metric ever will.

The monitoring side deserves its own budget. Set a tolerance for disparity in outcomes across protected classes, measure it continuously on booked loans, and treat a breach as a production incident with a rollback path rather than a line item in a quarterly report. A pricing model that passed review at launch can drift into a problem as the applicant mix changes, and the first sign is usually in the margin decomposition, not the headline booking rate.

None of this makes the model less profitable. It makes the profit legible. A rate you can take apart in front of an examiner is a rate you can also take apart in front of your own risk committee when they ask why bookings fell in one channel. The decomposition earns its keep on both sides of that table.