RBI cyber resilience directions, 5 November 2026: 6-hour reporting, 12-hour hold

Summary. On 5 November 2026 the Reserve Bank of India issued revised Master Directions on Cyber Resilience and Digital Payment Security Controls for non-bank Payment System Operators, reference RBI/DPSS/2026-27/475. The headline controls are not new. Six-hour incident reporting to RBI, a cooling period of at least 12 hours after a registered mobile number or email change, and device and SIM binding for payment apps carry over unchanged in substance from the 30 July 2024 directions, which already bound large PSOs from 1 April 2025 and medium PSOs from 1 April 2026. What is new is one rulebook: the November text absorbs the 2019 cyber controls for third-party ATM switch providers and the 2020 system audit scope, and repeals six circulars dated 2009 to 2020. It applies from publication to large and medium non-bank PSOs, a group that includes NPCI, card networks, payment aggregators, large PPI issuers, BBPOUs, TReDS platforms and white-label ATM operators, and from 1 April 2028 to small PPI issuers and instant money transfer operators. There is no fresh grace period. The engineering work sits in five places: an incident pipeline that meets RBI's six hours and also feeds CERT-In, an identity-change hold, device binding with remote-access checks, five-year audit logs, and an annual system audit report due by 1 June for April to March filers.

About this article. For engineering, security and compliance leads at payment aggregators, wallets, card networks and ATM operators, and the vendors that serve them. We read the full RBI text of 5 November 2026, compared it paragraph by paragraph with the July 2024 directions, and checked the related CERT-In directions and advisories, the DPDP Rules and DoT's SIM-binding directions against the issuing bodies' own pages on 11 November 2026. This is general information, not legal advice: your counsel should interpret the directions for your entity, and no company paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

What RBI issued on 5 November 2026

The cover letter is addressed to the chairman, managing director or chief executive of every authorised non-bank PSO and is signed by Chief General Manager Saurabh Nath. It carries the references RBI/DPSS/2026-27/475 and CO.DPSS.CSD.No.S825/01-01-078/2026-2027 and is issued under Section 10(2) read with Section 18 of the Payment and Settlement Systems Act, 2007. RBI's notifications page lists it under 5 November 2026; as of 11 November 2026 no later notification, FAQ or amendment on it had been posted.

The letter gives its reason as a single reference point for regulated entities. Two older instruments are folded in: the 31 December 2019 circular on cyber security controls for third-party ATM switch application service providers (ASPs), and the 10 January 2020 circular on the scope and coverage of system audits of payment systems under the PSS Act.

Paragraph 3 sets commencement. Large and medium non-bank PSOs are bound from the day the directions were placed on RBI's website; small non-bank PSOs from 1 April 2028. The letter also keeps existing security instructions for cards, PPIs and mobile banking in force, and says this Master Direction prevails where they conflict.

What changed against the July 2024 text

We compared the two texts paragraph by paragraph. Sections II to IV (governance, baseline controls and digital payment controls, paragraphs 7 to 35) match the July 2024 wording almost exactly; the edits are added sub-paragraph letters, renumbered footnotes and small typographical fixes. The differences are structural, as the table shows.

Two points follow. The July 2024 directions are not in the repeal list, and the cover letter calls the new text the revised Master Directions, so read it as a new edition rather than a new subject. And if your entity is large or medium, the controls in Sections II to IV were already due: the consolidation does not restart the clock. It does put the audit scope and the ATM switch controls in the document an inspector will open first.

Who is covered, and from when

Paragraph 4 applies the directions to all authorised non-bank PSOs, and footnotes 1 to 3 sort them into size bands.

PPI issuers are banded under RBI's Oversight Framework for Financial Market Infrastructures and Retail Payment Systems, published in June 2020. Under footnote 3, a PPI issuer that moves up a band takes on that band's timeline, and a small issuer that becomes medium or large has one year from the new categorisation to comply.

Three groups that are not named still feel this.

Vendors and gateways. Paragraph 5 has PSOs secure adherence to these directions from the unregulated entities in their payment chain, naming payment gateways, third-party service providers, vendors and ATM switch ASPs, subject to mutual agreement and under a Board-approved policy. If you sell software or hosting to a PA or wallet, expect these controls in your contract.

UPI and card participants. Paragraph 31 requires a PSO that provides, facilitates or processes mobile payments to follow the mobile controls and to make sure the participants in its payment system do too. On our reading, that is how device binding and the 12-hour hold reach third-party apps through the scheme operator, even where the app is not itself an authorised PSO. Check that reading with counsel.

Banks and NBFC lenders. These directions cover non-bank PSOs only. Lenders have their own RBI instructions: for example, the amendment directions on loan recovery issued on 6 August 2026, which cover technology-based recovery through financed mobile devices, take effect on 1 January 2027. Our device-locking guide for lending apps covers that work.

The three headline rules

Six-hour incident reporting (paragraph 22(d))

Paragraph 22(d) requires unusual incidents, such as cyber-attacks, outages of critical systems or infrastructure, internal fraud and settlement delays, to be reported to RBI in the Annex 1 format within 6 hours of detection. Annex 2 gives an indicative list of incident types, and every cyber security incident must also go to CERT-In.

Three details are easy to miss. The scope is wider than cyber: an outage, internal fraud or a settlement delay all count. The clock runs from detection, so your record of when you detected something becomes compliance evidence. And the format is fixed: RBI's page links Annex 1 as a spreadsheet file dated 5 November 2026, where the July 2024 page linked one dated 30 July 2024. We could not open either file, so compare your template with the current one before your next filing.

The 12-hour cooling period (paragraph 31(g))

When the registered mobile number or email ID linked to a payment instrument changes, paragraph 31(g) bars any payment transaction through online modes or channels for at least 12 hours.

Twelve hours is a floor, so a PSO can set a longer hold. The rule covers every online mode or channel, so the hold cannot live only in the mobile app: web checkout, APIs and any other online channel attached to the same instrument must respect it.

Device and SIM binding (paragraph 31(c) and footnote 8)

Paragraph 31(c) requires device binding or fingerprinting of the mobile application with both the device and the SIM, and a fresh binding when the app has been unused for longer than a period the PSO sets in policy. Footnote 8 says binding should preferably combine hardware, software and service information.

RBI leaves the inactivity period to you, which means you have to write one down and enforce it. This payment-app control is separate from the Department of Telecommunications SIM-binding directions of 28 November 2025 for messaging apps, covered in our SIM binding guide, though the device signals overlap.

Deadlines and recurring obligations

Every row below comes from the 5 November 2026 text.

What engineering and operations teams have to change

The directions describe outcomes. The list below is our engineering reading of what each outcome needs in a typical PA, wallet or switch stack. Your auditor's reading may differ.

1. An incident pipeline that meets two six-hour clocks

RBI wants Annex 1 within 6 hours of detection. CERT-In's directions of 28 April 2022 separately require specified cyber incidents to be reported within 6 hours of noticing them or being told about them, and CERT-In's FAQs let an entity report what it knows inside that window and send the rest later within a reasonable time. Two regulators, two formats, one window.

What to build:

• A single incident record with an immutable detected_at timestamp written by the system that raised the alert, not by the person who opened the ticket.

• Severity rules that map your alert categories to RBI's Annex 2 list, including outages, settlement delays and internal fraud, so the on-call engineer does not have to decide at 2 a.m. whether something is reportable.

• A pre-filled Annex 1 draft generated from the incident record, plus a CERT-In draft, both reviewed by a named approver.

• A countdown visible on the incident channel, with escalation at three and five hours.

2. An identity-change service that enforces the 12-hour hold

Most stacks let profile services update a phone number or email and move on. Paragraph 31(g) turns that update into a payment-risk event.

• Emit an identity_changed event with instrument ID and timestamp on every registered mobile or email change.

• Have the authorisation service check a payments_blocked_until value (change time plus at least 12 hours) before any online debit, across app, web and API.

• Tell the old and new contact points that a hold is active, and feed blocked attempts to the fraud engine as a takeover signal.

3. Device binding, rebinding and remote-access detection

Paragraph 31(c) asks for binding to device and SIM, and paragraph 31(f) adds a control to detect remote access applications, as far as possible, and to block the payment app while remote access is live.

• Bind on a combination of hardware attestation, an app-generated key held in the platform keystore, and a SIM or subscriber signal verified server-side, which matches the hardware, software and service mix in footnote 8.

• Record last_active_at per binding and force a fresh binding once your policy period lapses.

• Check for known remote-access and screen-sharing tools and active accessibility-service abuse at session start and before each payment, and block while they are live.

• Treat a SIM swap or a new device as both a binding event and an input to the fraud score.

4. Sessions, lockouts and notifications

Paragraphs 31(b), (d) and (e) require sessions that end on interference or when the customer closes the app, with affected transactions resolved or reversed; automatic time-outs after a fixed period of inactivity; and a cap on failed log-in attempts with a secure re-activation process. Customers must be told about failed log-in or authentication attempts immediately, which rules out a daily digest.

5. Alert content: merchant name, masking and OTP position

Paragraph 29 sets the content of SMS, email and other alerts. Account and card numbers are masked as far as possible. Alerts for online payments name the merchant, not the payment gateway or aggregator, plus the amount; alerts for fund transfers name the beneficiary and the debit amount. Where an OTP is an authentication factor, it goes at the end of the message, and the message refers to the specific transaction.

For payment aggregators this is a data problem as much as a template problem: the name must come from the system of the entity that maintains the beneficiary account, so the SMS pipeline needs the sub-merchant's name from that source.

6. Fraud monitoring, a 24x7 desk and a fraud-marking button

Paragraph 27 asks for multi-factor authentication on all electronic debits unless explicitly permitted or relaxed, real-time or near real-time fraud monitoring, and a manned 24x7x365 facility for customer fraud reports and law-enforcement requests. Paragraph 28 has PSOs make sure their members and participants run online alerts on parameters such as velocity, geo-location, IP origin, behavioural biometrics and payments to wallets, mobile numbers or VPAs already linked to vishing or other fraud. Paragraph 30 adds an in-app or web facility for an authenticated customer to mark a transaction as fraudulent, with immediate notice to the instrument's issuer.

7. API controls (paragraph 24)

The API paragraph is short. PSOs must cover authentication and authorisation (establishing the identity of communicating applications), confidentiality, integrity, and availability with threat protection, meaning anomalous activity is detected and acted on. They must also follow recognised standards and frameworks on API security. Read it next to CERT-In's payout-API advisory of 9 October 2026, which describes attackers using stolen aggregator and partner-bank credentials to call disbursal and fund-transfer APIs directly, and its 4 November 2026 update naming the actor CRAFTY FALCON. Our CRAFTY FALCON payout API guide covers that side.

8. Logs, backups and disaster recovery

• Audit logs must identify the user, the action and its parameters, with controlled access, and be kept for at least five years (paragraph 27(e)).

• Backed-up data is tested at least half-yearly to show recovery without losing transactions or audit trails (paragraph 20(f)).

• The DR site sits in a different seismic zone from the primary data centre, with a defined reconciliation method so no data is lost on failover, DR drills at least half-yearly and an aim of near-zero RPO (paragraph 23).

At switch volumes, five years of logs needs tiered storage with integrity protection.

9. Vendors, source code and cloud

Paragraph 17(c) requires PSOs to obtain the source code of critical applications bought from third-party vendors, or an escrow arrangement where that is not possible. Where the PSO does not own the code, paragraph 18(b) asks for a developer certificate that the application is free of vulnerabilities, malware and covert channels, renewed with every code change. Paragraph 19(c) asks for independent assurance on the cyber resilience of vendors in critical processes, and paragraph 26 requires a cloud operation policy and at least annual independent security audits of the cloud provider.

10. The system audit report

Section V carries over the 2020 audit scope. Paragraph 36 requires an annual System Audit Report from a CERT-In empanelled auditor, a CISA registered with ISACA, or a holder of ICAI's DISA qualification, within two months of the financial year end: by 1 June for April to March entities and by 1 March of the following year for calendar-year entities. Paragraph 37 bars a firm, or its sister concerns, that provided any service to the entity in the previous two financial years. Paragraph 38 lists 20 audit areas, each tested for design and operating effectiveness, including online systems security (which names APIs) and mobile online services. Paragraph 41 sets a maximum of three months for corrective action on each open observation, reported to RBI, and an observation closes only when the auditor accepts the closure.

11. White-label ATM operators and their switch providers

Section VI requires a WLAO that runs its ATM switch through a shared third-party ASP to make the ASP contractually bound to a set of controls and to give RBI on-site and off-site supervisory access. The controls include unauthorised software, patching, network separation, secure configuration, secure coding, access management, audit logs, VA and PT, forensics support on standby, a cyber security operations centre and PCI-DSS and PA-DSS compliance.

Worked example: one weekend, two clocks

A payment aggregator's SIEM flags unusual settlement-API traffic at 23:40 on a Saturday. The on-call engineer confirms it at 00:25 on Sunday.

• If the system alert at 23:40 is treated as detection, the RBI Annex 1 report is due by 05:40 on Sunday (23:40 plus 6 hours).

• If the team argues detection was the 00:25 confirmation, the deadline moves to 06:25. That 45-minute gap (23:40 to 00:25) is exactly what an inspector will ask about, so write your detection definition into the incident policy before the incident, not after.

• The CERT-In report runs on its own six-hour window from noticing. Plan to file both from the same record.

Now the identity side. A customer changes the registered mobile number on a wallet at 10:15 on Monday. Under paragraph 31(g), no online payment from that instrument may be allowed before 22:15 the same day (10:15 plus 12 hours). If your policy sets 24 hours, the hold ends at 10:15 on Tuesday. A web checkout attempt at 18:00 on Monday must be declined even though the change was made in the app.

India context: CERT-In, DPDP and the payout-API campaign

Three instruments now overlap. RBI wants 6-hour incident reports under these directions. CERT-In wants 6-hour reports and logs kept for a rolling 180 days within India under its 2022 directions, and its CIAD-2026-0046 advisory again recommends retaining logs for at least 180 days. The DPDP Rules add breach intimation to affected individuals and the Data Protection Board, with a detailed report to the Board within 72 hours, once Rule 7 starts 18 months after the Rules were published on 13 November 2025, which is 13 May 2027. Our DPDP Rules checklist covers that side. Build one incident record and one evidence store that every report draws from.

30-day gap check

The paragraph references below are to the 5 November 2026 text.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. For payment aggregators, wallets and their vendors, our cybersecurity services team builds the engineering side of these directions: incident pipelines with defensible detection timestamps, identity-change holds in the authorisation path, device binding with remote-access checks, and five-year log retention. Talk to us at /contact-us/.

Last updated: 11 November 2026.

References

1. Master Directions on Cyber Resilience and Digital Payment Security Controls for non-bank Payment System Operators, RBI/DPSS/2026-27/475, 5 November 2026 — Reserve Bank of India

1. Master Directions on Cyber Resilience and Digital Payment Security Controls for non-bank Payment System Operators, RBI/DPSS/2024-25/123, 30 July 2024 — Reserve Bank of India

1. Notifications (listing checked 11 November 2026) — Reserve Bank of India

1. Reserve Bank of India publishes the Oversight Framework for Financial Market Infrastructures and Retail Payment Systems, 13 June 2020 — Reserve Bank of India

1. RBI Issues Amendment Directions on Conduct of Regulated Entities in Recovery of Loans and Engagement of Recovery Agents, 6 August 2026 — Reserve Bank of India

1. DoT's directions for SIM binding for prevention of misuse of telecommunication identifiers, 1 December 2025 — Department of Telecommunications (copy of PIB release)

1. Directions under sub-section (6) of section 70B of the IT Act, 2000, No. 20(3)/2022-CERT-In, 28 April 2022 — CERT-In

1. FAQs on Cyber Security Directions of 28.04.2022, May 2022 — CERT-In

1. CERT-In Advisory CIAD-2026-0046, Threat Actors Exploiting Payment and Disbursement APIs for Unauthorized Fund Transfers in BFSI Entities, 9 October 2026 — CERT-In

1. CERT-In Advisory CIAD-2026-0058, Escalation of AI-Driven Attacks on BFSI Entities by Threat Actor CRAFTY FALCON, 4 November 2026 — CERT-In

1. Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), 13 November 2025 — Ministry of Electronics and Information Technology