Fraud Model Degradation, a Black-Box Challenger, and Contested Feature Provenance
A payments processor's production fraud model has run unchanged for 26 months. Detection recall has fallen from 0.71 to 0.58 and the false-positive rate has risen from 2.1% to 3.4%, generating merchant complaints. Operations wants the decision threshold loosened to cut false positives; risk wants it tightened because missed-fraud chargeback liability sits with the processor. Data science has a challenger: a gradient-boosted ensemble that raises recall to 0.69 at the same false-positive rate, but it relies heavily on a device-fingerprint feature built from a signal the privacy team says has no documented consent basis, and the team cannot produce per-decision explanations because it plans to use SHAP post-hoc attributions only. A regulator requires that merchants receive an explanation of the principal reason when a transaction is blocked, and a supervisory review of the payments line is scheduled in five months. Retraining the incumbent on recent data is estimated at six weeks; the challenger is estimated at ten and has never been run in production.
1. Operations wants a threshold change; risk wants it tightened. How do you decide, and what analysis settles it?
Read the worked answer
Neither threshold change is justified yet, because the proposed fix treats a symptom. A simultaneous recall drop and false-positive rise is not a threshold problem - moving the threshold trades one error for the other along the same curve. The curve itself has moved, which means the model's ranking quality has degraded, most likely because behaviour and the feature distributions shifted while the model stayed frozen for 26 months. Threshold changes will not restore ranking quality.
The analysis that settles it is a current-period performance rebuild: score a recent held-out window, plot the full precision-recall and cost curve rather than reporting one operating point, and overlay the incumbent's curve from 26 months ago. If the old curve still passes through today's data, the model discriminates as well as ever and the operating point drifted - a threshold fix is legitimate. If today's curve sits strictly below the old one, discrimination has decayed and no threshold recovers it; the decision is retrain or replace.
Convert to money before negotiating. The false-positive rate rise is quantifiable in merchant friction and manual-review cost; the recall loss is quantifiable as expected chargeback exposure at current volume and average loss. Put both on one axis. That is the only way to resolve a disagreement between two functions with different loss functions, and it converts an opinion contest into an arithmetic one.
Immediate action independent of the model question: if the curve confirms decay, apply an interim compensating control - a rules-based overlay targeting the fraud typologies the model now misses, and a lower manual-review threshold for high-value transactions. Do not leave the degraded model unmitigated for ten weeks while the challenger is validated.
2. The challenger performs better but is unexplainable and rests on a contested feature. How do you weigh those against the recall gain, and what must be true before go-live?
Read the worked answer
Treat the three problems separately; they have different owners and different remedies, and bundling them is why the debate is stuck.
The contested device-fingerprint feature is a stop, not a trade-off. A feature with no documented consent basis is a legal and privacy defect that exists whether or not the model is accurate, and better recall does not cure it. This is the binding constraint. Remedy it before anything else: establish the lawful basis and document it, or drop the feature and re-measure. Critically, re-measure without it - if performance collapses to the incumbent's level, the entire challenger case rested on data the firm may not lawfully use, and the question is settled.
Explainability is a regulatory requirement, not a preference. The obligation is that merchants receive the principal reason for a block. Post-hoc SHAP is a candidate mechanism, not a demonstrated one. It must be tested against the actual obligation: generate explanations for 200 real declined transactions, have reviewers judge whether the top attribution is a genuine principal reason and whether it is stable (same transaction, small input perturbation, same explanation), and check whether it is actionable for a merchant - 'your device fingerprint score was high' is technically true and practically useless. A regulator will test merchant-facing usefulness, not method choice.
The recall gain then gets weighed honestly. A 0.11 recall improvement with a compensable review burden is worth a lot, but it is being offered in exchange for a legal defect and an unproven obligation. Fix those, and the comparison becomes straightforward.
Go-live gates, all mandatory: lawful basis documented or feature removed with performance re-measured; explanation mechanism validated against the 200-transaction test; shadow-mode run for at least four weeks comparing decisions and misses against production; a defined rollback with the incumbent kept warm; and documented monitoring for feature drift on the new inputs. Independent validation sign-off before, not after, the supervisory review window.
3. You have five months until the supervisory review and a ten-week build for the challenger. Sequence the work and state what you will be able to tell the regulator versus what you will have to concede.
Read the worked answer
Sequencing. Weeks 1–2: ruling on the contested feature - this gates everything and cannot run in parallel, because dropping the feature changes the model. Weeks 1–3 concurrently: complete the performance rebuild and cost curve on the incumbent, and deploy the interim rules overlay so the degraded model is not unmitigated during the programme. Weeks 3–8: challenger rebuilt without the contested feature and re-evaluated; incumbent retrain in parallel as a lower-risk fallback, since six weeks fits and gives you an option if the challenger fails its gates. Weeks 6–10: explanation mechanism built and tested against real declined transactions. Weeks 8–12: shadow-mode comparison. Weeks 12–16: independent validation, then staged rollout with a rollback path. Weeks 16–20: evidence pack assembled and dry-run against likely supervisory questions.
What you will be able to tell the regulator. That degradation was detected by monitoring, that the detection led to a documented decision rather than an unmanaged threshold tweak, that an interim control limited customer and merchant harm during remediation, that a replacement was validated against defined gates including an explanation test, and that the contested data use was identified and resolved before, not after, deployment. That narrative - detect, decide, control, validate - is what a supervisory review is actually assessing.
What you must concede. If the timeline slips, concede the slip rather than compressing validation: state the current model version, its measured degradation, the compensating control in force, and the dated milestone for replacement. What is not survivable is presenting the challenger as validated when it went live without the explanation test, or leaving the 26-month-old model in place with no overlay and describing the review as on track.