AI Fraud Detection Governance for Banking: Why a Model Can Have Acceptable Aggregate FPR While Simultaneously Over-Detecting and Under-Detecting by Segment, and What RBI FREE-AI Requires

Why aggregate false positive rate hides segment-level fraud model failures

A fraud model can clear every number your model risk committee asked for and still be hurting a specific set of your customers every single day. That's not a hypothetical. It's the normal failure mode of aggregate-only governance.

Here's the pattern. A bank's fraud detection model reports an overall false positive rate that sits comfortably inside the bank's approved tolerance. The model risk report goes to committee, gets a green status, and moves on. Meanwhile, the same model is blocking three times as many legitimate transactions from rural customers as it blocks from metro customers — and missing more actual fraud in that same rural segment. Aggregate governance says pass. Fairness governance says fail. Both are correct, because they're measuring different things.

This happens because aggregate metrics are weighted averages. If your metro segment carries most of your transaction volume, it dominates the aggregate number and effectively buries whatever is happening in smaller segments. A model that is excellent for 80% of your base and bad for the other 20% can still produce an aggregate number that looks fine. The committee never sees the 20%, because nobody asked for the number broken out that way.

If you've sat in one of those committee meetings, you know the uncomfortable part isn't the math — it's explaining why "the model passed" is true and irrelevant at the same time. You're not reporting a bug. You're reporting that the governance process itself asked the wrong question.

The illustrative example: how a model passes aggregate governance and fails fairness testing

Take a representative bank fraud model, here illustrated with example figures rather than a specific institution's live numbers.

Read that table the way an examiner reads it, not the way a dashboard presents it. The aggregate FPR of 0.8% is within the bank's own approved threshold — not because SR 11-7 specifies 0.8%, or any number at all; SR 11-7 is a principles-based supervisory framework and does not set a numeric false-positive-rate ceiling. The 0.8% figure here is the bank's own internal risk appetite, set through its own model validation process. What the aggregate hides is that rural customers face a false positive rate six times higher than metro customers, and simultaneously experience more missed fraud. One number says "pass." Five seconds of disaggregation says "this model treats customers differently depending on where they live and how they bank."

This is also where governance teams usually get their first field signal that something is wrong, long before it shows up in a quarterly report: a rural branch manager calls to say the same handful of regular customers keep getting blocked trying to withdraw their own money, and nobody can tell them why.

What RBI FREE-AI actually requires for fair and reliable fraud detection

Segment-level reporting of this kind is squarely what RBI's FREE-AI fairness principles are built to surface. A model that produces a materially worse false positive rate and a materially worse false negative rate for a defined customer segment — rural, migrant-worker, senior-citizen, whatever the segment is — is not a fairness edge case. It is the exact scenario the Fairness and Equity Sutra exists to catch, because an aggregate-only report would never show it.

What this means operationally: the aggregate FPR/FNR you report to your board is necessary but not sufficient evidence of a compliant model. Model risk teams need segment-level breakdowns as a standing part of the validation and monitoring package, not as a special request pulled together after an examiner asks. This example model passes aggregate governance and fails fairness examination — and under FREE-AI's framing, "fails fairness examination" is the finding that matters.

Segment-level fraud model monitoring: the table every model risk team needs

Aggregate dashboards group everyone together. A usable fraud model monitoring table doesn't. Below is the structure a model risk function should be running every reporting cycle, broken out by customer segment rather than by portfolio-wide average.

A table like this doesn't need to be exhaustive on day one. It needs to exist, be reviewed on a fixed cadence, and have an owner who can answer "what are we doing about the rural row" without needing three weeks to pull the data.

Why elevated FNR alongside elevated FPR is the real tell

The combination in the rural segment — FPR up and FNR up at the same time — is the detail that separates a tuning problem from a data problem, and it's worth spelling out because the two require completely different fixes.

If a segment only had an elevated FPR, the fix might simply be a higher decision threshold for that segment: the model is "too trigger-happy" there, so you dial it back. But that's not what's happening here. FNR is also elevated, meaning the same model is missing more real fraud in that segment while simultaneously blocking more legitimate transactions in it. A single threshold adjustment can't fix both directions of error at once — moving the threshold to cut false positives will push false negatives higher, and vice versa. That's a mathematical property of any single-threshold classifier, not a configuration oversight.

What produces both errors going up together is usually insufficient rural transaction history in the training data. If rural transaction patterns are underrepresented relative to urban/metro patterns, the model never learns a sharp decision boundary for that segment — its risk scores for rural transactions cluster closer to the decision boundary than its scores for metro transactions, regardless of where that boundary sits. A blurry decision boundary produces more errors on both sides simultaneously. That is a data coverage and feature representation problem, and it needs more representative training data, segment-aware model architecture, or a separate calibration layer for underrepresented segments — not a threshold slider.

This is the finding that's hardest to deliver to a committee that wants a quick fix. "Move the threshold" is a five-minute action item. "Retrain with better rural transaction coverage" is a multi-quarter data program. The honest answer is usually the second one, and saying so is the job.

Explainability under confidentiality constraints: what you can disclose, when, and to whom

Fraud model explainability runs into a real tension: disclosing exactly why a transaction was blocked can hand fraudsters a map for evading detection next time. The resolution isn't "disclose everything" or "disclose nothing" — it's different disclosure for different audiences and different moments.

• Real-time blocking. The customer sees a general category only ("unusual activity flagged for review"), with no specific feature values disclosed. Specific thresholds and feature weights stay confidential to prevent evasion engineering.
• Post-hoc, via a verified channel. Once the customer authenticates through support, they're entitled to a specific explanation. Forensic Replay retrieves the actual feature values and SHAP attributions that drove that decision, so the explanation is grounded in what the model actually did, not a generic script.
• Examiner access. A regulator or internal audit function gets full feature-level explanation on demand. Confidentiality protections that apply to customers and the public do not apply to examiners — this access should not require a special request process.
• Aggregate pattern disclosure. For public-facing transparency reporting, general signal categories can be disclosed without exposing specific weights or thresholds that would help an adversary reverse-engineer the model.

The practical risk here isn't the framework — it's a support agent improvising an explanation under pressure from an angry customer and accidentally disclosing a specific threshold value that ends up on a fraud forum within a week. The verified-channel step needs a hard script, not agent discretion.

DPDP Act grievance redress: what customers can demand and how to be ready

Under the DPDP Act, a customer has a grievance-redress right to know which of their personal data features drove an adverse decision about them, exercised through a verified and authenticated channel rather than an open request. For a fraud-blocking decision, that means a customer who was wrongly blocked has standing to ask specifically what data about them triggered it.

This is where Forensic Replay earns its place in the architecture rather than being a nice-to-have logging feature: it has to retrieve the exact feature values and model state for a specific past decision, on demand, for a decision that may be weeks old. If your fraud model's audit trail only stores the final decision and not the inputs that produced it, you cannot satisfy this request when it comes — and it will come, usually from the customer who was most inconvenienced and is now also the most persistent.

Action checklist for fraud and model risk teams

Treat this as the minimum standing process, not a one-time audit:

1. Break out FPR and FNR by customer segment every reporting cycle — not just on request from an examiner. If you don't have defined segments yet (digital-primary, mixed-channel, cash-primary, UPI-primary, branch-primary, at minimum), define them before your next validation cycle.
2. Flag any segment where FPR and FNR are both elevated as a data-coverage investigation, not a threshold-tuning ticket. Route it to the model development team with the training-data representation question first.
3. Build the verified-channel explanation path now, with a fixed script for what a support agent can and cannot disclose, so Forensic-Replay-style feature retrieval is available before a DPDP grievance request arrives, not after.
4. Give examiners full feature-level access by default — don't gate it behind the same confidentiality process built for customers and the public.
5. Report segment-level findings to your model risk committee in the same document as aggregate metrics, not as a supplementary appendix that's easy to skip.

Zytra's own platform runs this segment-level monitoring and Forensic Replay workflow natively — in our own benchmark testing, Zytra measured 0.5% aggregate FPR at 11.6ms latency on the deployment we tested. That's our own measured result on our own stack, not an industry or regulatory benchmark, and we'd rather you treat it as a starting point for your own validation than as a number to cite in a filing.