QuickLend: ZIP Codes, Purchased Life Events, and a Black-Box Credit Model

Risks by principle:

• Lawfulness and purpose limitation. The broker's data was collected under a general privacy policy and is being reused for credit scoring, a materially different and high-impact purpose. A general policy may not provide a valid basis. Inferred pregnancy and health interests are sensitive data and require a stronger condition.
• Data minimisation and necessity. ZIP code, device type, and life-events data must be shown to be necessary and proportionate for credit risk. Device type may proxy for income or disability; life events are highly intrusive and plausibly unnecessary.
• Fairness / non-discrimination. ZIP code is correlated with race in the lender's market, and the denial rate in three ZIP codes is more than double the rest. This is a red flag for disparate impact, even if ZIP code is not a protected characteristic itself. A proxy can produce unlawful discrimination.
• Transparency and explainability. Applicants need meaningful reasons for adverse decisions. A model with an AUC of 0.81 does not satisfy a requirement to explain the logic merely because it performs well.
• Retention and accountability. Indefinite retention of application data violates storage-limitation principles and increases breach impact. There is no named owner for model risk.

Start with necessity and impact testing, not with a defence of AUC. For ZIP code, run a disparate-impact analysis by protected group, remove ZIP code and test the performance drop, and examine whether less discriminatory alternatives (income, debt-to-income, repayment history) capture the legitimate signal. If performance depends on the proxy, that is evidence the variable is doing discriminatory work. For the broker data, obtain the actual source, consent language, and legal basis; if the broker cannot document it, do not use the data. Drop pregnancy and health-interest fields outright unless a specific lawful basis and necessity case exist. For device type, test whether it proxies for disability or income and whether it is necessary.

The 'black box' position is untenable for a regulated credit decision. Use an interpretable model or post-hoc explanation (for example, reason codes, SHAP values with human review) and validate that explanations are stable and plausible. Document the choice, the trade-off between performance and explainability, and the residual risk. Options include: rebuild without the contested features; keep the model but restrict features and add human review for declines; or do not launch until the fair-lending analysis is complete.

The regulator should expect:

• Model documentation: purpose, scope, features, target definition, training data sources and dates, sample construction, validation method, performance by group, and known limitations.
• Feature justification: necessity and lawfulness for each feature, especially ZIP code, device type, and life events; documentation of the broker's legal basis and any data-processing agreement.
• Fairness testing: disparate-impact analysis, thresholds, remediation, and monitoring. Include the ZIP-code denial rates and the alternatives considered.
• Explainability: how adverse-action reasons are generated, whether they are understandable to applicants, and how they are checked.
• Retention schedule: defined periods by data type, deletion process, and legal hold. 'Storage is cheap' is not a retention policy.
• Vendor management: audit rights, purpose restrictions, breach notification, sub-processor list, and the right to delete.
• Accountability: a named model owner, independent review, change control, and periodic revalidation. Board or senior committee oversight.
• Data-subject rights: access, correction, and objection processes.