Banking & financial services

Every bank already has scorecards, alert engines and thresholds. The difficulty is rarely building another model — it is that the ones in production generate more work than they resolve, and the ones that would resolve more work cannot get through model risk.

An AML engine that raises twelve hundred alerts on one corridor, of which almost all have historically been false, is not a detection problem. It is a triage problem, and triage is a ranking task with an evidence requirement attached. Equally, a fraud model that cuts loss by declining more good customers has not helped anybody; the constraint is the false-decline rate, not the catch rate.

So the useful question for a bank is not can a model do this but can this model be explained to somebody whose job is to doubt it — a validator under SR 11-7, an investigator writing up a case, a customer entitled to know why they were declined.

Where a decision has to be reproducible and defensible, the model is deterministic by design — scorecards, gradient-boosted classifiers, anomaly detectors, survival and time-series models, graph networks and regulatory calculation engines. The same input gives the same output, the attribution is mathematical, and a model-risk team can take it apart without calling us.

The frameworks these were designed against ship mapped with them:

• SR 11-7 and TRIM model-risk expectations, with validation workflows and versioned configuration
• Basel III/IV and IFRS 9 for capital, provisioning and the numbers behind them
• BCBS 239 for risk data aggregation and lineage
• FATCA/CRS, MiFID II and MAR where the obligation is reporting and conduct
• EU AI Act, NIST AI RMF and ISO 42001 across the model estate itself

Adverse-action reason codes are native to every scoring model — which is not a feature so much as a legal precondition anywhere a declined applicant has a right to an explanation.