AI rent underwriting that survives a fair-lending review
Adverse-action reasons, disparate-impact testing and per-applicant explainability: what a model-assisted rental or credit decision has to produce before counsel will sign off.
Any product that helps decide who gets a lease, a deposit alternative, a rent advance or a credit line is making a consumer decision. The bar is not "the model is accurate." The bar is that a reviewer can state, for one named applicant on one named day, why the outcome was what it was.
Teams building these features inside a software platform often meet the fair-lending question late, after the model is embedded. It is far cheaper to design for the review than to retrofit an explanation onto a score.
Per-applicant reasons, not cohort narratives
Global feature importance is useful for model risk management and useless in an adverse-action notice. A declined applicant is entitled to the specific principal reasons for that decision, in plain language.
- Produce reasons from the decision logic, not from a post-hoc model explanation the reviewer cannot audit
- Keep the reason codes to a fixed, reviewed vocabulary rather than free-form model text
- Store the reasons with the decision record, not regenerated later from a possibly different model version
- Make the same reason set drive both the applicant notice and the internal audit view, so they cannot diverge
Keep the decision outside the model
The reliable pattern is narrow: the model reads documents and returns structured, cited facts — stated income, verified income, employment status, obligations, document authenticity flags. Deterministic code applies the policy: income multiple, thresholds, exceptions, overrides.
This makes the decision reproducible by construction, makes policy changes reviewable as code changes, and keeps proxy variables out of the scoring path where you can actually enumerate what the decision considered.
Testing you should be running continuously
Fair-lending posture is a monitoring commitment, not a launch checklist:
- Disparate-impact testing on outcomes across protected classes where inference is lawful and appropriate, run on a schedule and after every policy or model change
- Proxy analysis: check whether inputs such as address, school, employer or document source correlate with protected characteristics
- Override tracking: who overrode the system, in which direction, and whether overrides skew
- Champion-challenger comparison against the prior human or rules-based process, so the effect of the change is measurable
The documentation package
Assume a regulator or a customer's counsel will ask for the file. It should contain the intended use and population, the data sources, the policy logic in reviewable form, the pinned model and prompt versions, validation and monitoring results, the human review process, and the change log.
If your platform sells this capability to operators, they inherit the compliance exposure. Shipping the documentation package with the feature is a differentiator, not overhead.