The Limit-Increase Feature and the Fraud Spike

Do not ship as proposed. The ₹25,000 new-device cap is currently the only control catching this pattern; raising the ceiling to ₹1 lakh in-app removes it and increases the maximum loss per compromised account fourfold. The 6% conversion gain is small against ₹38 lakh in 11 days and rising.

Conditions under which it could ship:

1. Device binding and step-up authentication at the point of limit increase - liveness check, device fingerprint, and a 24-48 hour cooling period before the higher limit becomes active.
2. Beneficiary and mule risk: new beneficiaries capped, first-transfer cooling period, graph-based mule detection on account age, device reuse and shared IPs.
3. Behavioural and velocity rules: SIM-swap detection via telco events, impossible-travel, transaction-time anomaly.
4. Staged rollout: 5% cohort, kill switch, daily fraud-loss review, automatic rollback at a defined loss threshold.
5. Account eligibility: at least 90 days of history, KYC-verified, no recent SIM or device change.

Must not ship if: mule detection is not live, the complaint TAT is still seven days, or fraud rules cannot be changed without a full release.

The product team is optimising conversion; the fraud team owns loss. The decision needs both, with the loss threshold written down in advance.

Triage by evidence, not by complaint date.

• Segment A - proven SIM swap: the telco record shows a SIM swap before the disputed transaction and the OTP was delivered to the new SIM. Strong zero-liability case; refund and pursue recovery from the mule accounts.
• Segment B - device or credential compromise without customer negligence: device ID mismatch, malware on the handset, or a bank-side breach. Zero liability.
• Segment C - customer negligence indicators: OTP shared with a caller, remote-access app installed, screen-sharing, or a link clicked that captured credentials. Liability may be shared; decide on documented evidence.
• Segment D - insufficient evidence: provisional credit within the statutory timeline, then resolve.

Evidence to collect per case: transaction logs, device fingerprint, IP and geolocation, OTP delivery logs, telco SIM-swap record, beneficiary account opening date and KYC, call recordings, and the customer's written statement.

TAT: the three-day requirement is statutory; the seven-day average is a compliance breach. Add temporary staff, publish a tracked queue, and report the backlog to the risk committee weekly. Pay provisional credit where evidence is incomplete rather than let the clock run.

Redesign around the attack, not the channel.

1. Device binding: bind each account to a trusted device at onboarding; new devices trigger step-up and a cooling period.
2. SIM-swap awareness: ingest telco swap events and suppress OTP to a newly swapped SIM; fall back to in-app or branch verification.
3. Behavioural biometrics: typing cadence, swipe patterns, session anomalies; useful for account takeover, but only with a tuned threshold.
4. Mule detection: graph analysis linking accounts by device, IP, beneficiary and opening cohort; block outgoing transfers from accounts with mule characteristics.
5. Beneficiary cooling period and first-transfer limits.

Metrics to report to the board, monthly:

• Fraud loss per 10,000 transactions, split by attack type.
• False-positive rate and challenge rate (friction).
• Drop-off at the challenged step.
• Average complaint resolution TAT against the statutory limit.
• Recovery rate from mule accounts.
• Detection latency (time from first fraudulent transaction to block).

Run the rules as champion-challenger, with a documented threshold that balances loss against friction. A rule set that blocks nothing has zero false positives and no value; the board needs to see both sides of that trade-off, along with the residual loss the bank is choosing to accept.