Pattern: fair-lending platform

Financial services — fair-lending platform pattern. Bias scorer shared across product teams, variant comparison, continuous monitoring.

A bank deploys AI in many places — fraud detection, underwriting, customer service, marketing personalization. Each product team owns its own model, but fair-lending exposure cuts across all of them. A platform team owns that cross-cutting risk.

This pattern shows how the platform team standardizes fair-lending evaluation across product teams using a single org-scoped Stratix configuration that every team consumes.

What's at stake

Risk dimension	Magnitude	Framework
ECOA / fair-lending civil enforcement	Per-violation civil penalties + consent-decree cost	CFPB / DOJ enforcement actions
Per-declined-legitimate-transaction friction	~$25 per false positive	Card-network industry benchmarks
Annual US card fraud (the upside the model targets)	$4.2B	Federal Reserve / Nilson Report data
Brand and customer-trust impact under public consent decree	Multi-quarter remediation cycles	Public consent-decree filings
State DOI / state regulator exposure on insurance and lending products	State-by-state penalty bands	State regulator actions

The evaluation pattern

A single org-scoped Stratix configuration every product team uses:

1. Bias scorer (custom code) — computes per-segment false-positive disparity ratios against protected-class proxies (ZIP code, surname-derived demographics, age band). Flags any segment exceeding the 1.25× threshold derived from regulatory adverse-impact guidance.
2. Compare models — when a product team proposes a new model, the platform team's bias scorer runs against it. Teams pick the variant that minimizes disparity without sacrificing primary-task performance (fraud recall, underwriting accuracy, etc.).
3. Continuous trace evaluation — production traffic from each product team is sampled hourly; bias trends are visible to the platform team's dashboard with per-team and per-feature breakdowns.
4. Shared judge library — helpfulness, faithfulness, safety judges curated centrally and GEPA-tuned against pooled labels (≥50 per judge, contributed across the 12 product teams); reused everywhere. See Bootstrap a judge before GEPA for what to ship before the labels are there.
5. Per-feature tolerances — different features have different bars; tolerance configured per evaluation space.

Onboarding: new product teams get the bias scorer pre-wired into their CI from day one.

Configuration in code

# Python (SDK) — shared bias scorer used across product teams
from layerlens import Stratix
client = Stratix()

bias_scorer = client.scorers.create_code(
 name="fair-lending-disparity",
 code="""
groups = group_by_segment(input, output, segments=['zip_tier', 'surname_demographic'])
ratios = {g: false_positive_rate(g) / false_positive_rate('baseline') for g in groups}
result = {'passed': max(ratios.values()) <= 1.25, 'ratios': ratios}
""",
)

# Each product team consumes the shared scorer in their own evaluation
evaluation = client.evaluations.create(
 name="fraud-model-with-bias-check",
 model_id=os.environ["MODEL_ID"],
 dataset_id="fraud-labeled-v3",
 scorers=[bias_scorer.id, primary_recall_scorer_id],
)
result = client.evaluations.wait_for_completion(evaluation.id)

// TypeScript (REST) — same eval from a CI runner
const r = await fetch("https://stratix.layerlens.ai/api/v1/evaluations", {
 method: "POST",
 headers: {
 "X-API-Key": process.env.LAYERLENS_STRATIX_API_KEY!,
 "Content-Type": "application/json",
 },
 body: JSON.stringify({
 name: "fraud-model-with-bias-check",
 model_id: process.env.MODEL_ID,
 dataset_id: "fraud-labeled-v3",
 scorers: [biasScorerId, primaryRecallScorerId],
 }),
});

What you get

• Bias becomes a measurement, not a discovery. Every product team sees the same scoreboard.
• Cross-team conversations stop being "your team's eval said it was fine" and start being "the org's quality bar didn't move on this PR."
• Regulator-readable evaluation history quantifies disparity and tracks remediation per release.
• Platform team curates ~5 cross-cutting judges; product teams add their own task-specific judges as needed.

Stratix capabilities used

• Custom code graders — bias-disparity computations
• Compare models — variant selection with bias-aware criteria
• Trace evaluations — continuous sampled production scoring
• Multi-tenancy + shared org library — judges and scorers reusable across teams
• Standardize judges across teams

Replicate this

• Industry → Financial services
• Workflow: Govern
• Cookbook: GitHub Actions integration
• Use case: AI quality gates in CI/CD