Financial servicesIndia

RBI CTRRAF 2026 - Payments Banks

Keep payments-bank resilience work connected

Organise technology-risk decisions, security tasks and evidence around the services your customers rely on.

Full title
Reserve Bank of India (Payments Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026
Issued by
Reserve Bank of India, Department of Supervision
Issued and in force
31 July 2026, with immediate effect. Text updated as on 1 October 2026.
Applies to
Payments Banks. Digital payment security is covered by separate Payments Bank Directions of the same date.
Nature
Binding regulatory Directions, reviewed through RBI supervision and the bank’s own information systems audit
Structure
Eight chapters, with 31 baseline cybersecurity and resilience requirement areas in Chapter V

Overview

What the Directions require

These Directions are RBI’s technology and cyber risk rulebook for Payments Banks. They cover Board accountability, IT governance, IT and information security risk management, 31 baseline security and resilience areas, a Cyber Security Operations Centre and information systems audit. Issued by the Department of Supervision on 31 July 2026 with immediate effect, they repeal the earlier cybersecurity framework and IT governance directions for Payments Banks, while saving actions already taken under them.

The requirements do not ease for a smaller balance sheet. A Payments Bank needs the same Board-level IT Strategy Committee, the same independent CISO reporting to the Executive Director in charge of risk, and the same testing, drill and six-hour incident reporting rules that RBI set for Small Finance Banks and commercial banks. There is no comply-or-explain route. Proportionality works through the bank’s own identification of critical systems and a risk-based approach for everything else.

CTRRAF is one of several RBI instruments a Payments Bank works under. On the same date RBI issued the Payments Banks Digital Payment Security Controls Directions, 2026, which govern the security of digital payment products and services and need their own scope review. The CTRRAF third-party paragraphs also step aside for arrangements covered by the Payments Banks Managing Risks in Outsourcing Directions, 2025. The update as on 1 October 2026 substituted paragraph 7, on Board review of policies, following the Payments Banks Governance Amendment Directions, 2026.

A Payments Bank’s operations depend on always-available digital channels and on technology partners. The work is to keep every obligation owned, keep evidence current across the bank and its providers, and show the Board and supervisors where things stand without assembling a file each time.

Who it applies to

Paragraph 3 makes the Directions applicable to Payments Banks. In practice they reach:

  • The Board, the IT Strategy Committee and the Audit Committee of the Board
  • Senior management, the IT Steering Committee, the Information Security Committee, the Head of IT and the CISO
  • All information systems, with stricter requirements for critical systems and customer-facing DMZ systems
  • IT and cybersecurity third-party arrangements outside the scope of the Payments Banks Managing Risks in Outsourcing Directions, 2025
  • Any third-party ATM Switch Application Service Provider, through a list of baseline controls

Digital payment security controls sit in separate Payments Bank Directions and are not covered on this page. Other entities’ CTRRAF Directions: Commercial Banks, Small Finance Banks, Urban Co-operative Banks, NBFCs, Credit Information Companies and All India Financial Institutions. See also CERT-IN guidelines.

Structure

How the Directions are organised

Eight chapters. The 31 baseline areas of Chapter V, lettered A to EE, are grouped here by what they protect.

Chapter I

Preliminary

Commencement, applicability to Payments Banks and 32 definitions, most taken from the FSB Cyber Lexicon. Undefined terms take their meaning from the governing Acts and RBI’s glossary.

Chapter II

Role of the Board

Strategies and policies
The Board approves strategies and policies for IT, information assets, business continuity, information security and cybersecurity, including incident response and crisis management.
Annual review
Review is at least annual. Under the substituted paragraph 7, the Board may delegate it to the IT Strategy Committee, but material amendments come back to the Board for approval.
Committees
An IT Strategy Committee of the Board, with the Audit Committee of the Board overseeing IS audit.
Chapter III

IT governance and oversight

Governance framework
Structures, roles and oversight for strategic alignment, risk, resources, performance and continuity.
Two distinct policies
An information security policy and a separate Board-approved cybersecurity policy.
IT Strategy Committee
At least three directors, chaired by an independent director with at least seven years’ experience in managing information systems or leading technology or cybersecurity initiatives. Members must be technically competent. Meets at least quarterly.
IT Steering Committee
Senior management from IT and business. Meets at least quarterly, supports strategic IT planning, oversees continuity and recovery processes and updates the ITSC and the MD and CEO.
Information Security Committee
Constituted by the IT Strategy Committee, including the CISO, and headed by an official from the risk management vertical.
Head of IT
A senior, technically competent official acting as the first line of defence for IT controls.
CISO
Preferably General Manager rank or equivalent, appointed for a reasonable minimum term, with staff commensurate with business volume. No direct reporting to the Head of IT and no business targets. Reports directly to the Executive Director overseeing risk and reviews cyber risk before the Board, RMCB or ITSC at least quarterly.
Projects, architecture and services
IT project management, an architecture reviewed by the ITSC at least annually, and IT service management.
Chapter IV

IT and information security risk management

Periodic review
IT-related risks reviewed periodically.
Framework
An IT and information security risk framework. The bank may define a separate information security or cybersecurity risk framework.
Assessment and documentation
Risks identified, assessed and documented as low, moderate, high and very high, or on a similar scale the bank chooses, with risk-cost trade-off decisions recorded.
Chapter V

Baseline controls: systems and data

Inventory and data protection
An information asset inventory, a data leak prevention strategy and data migration controls.
Software and configuration
Preventing unauthorised software, secure configuration, and patch, vulnerability and change management.
Facilities and capacity
Physical and environmental controls, with data centre and recovery sites geographically well separated, and capacity assessed annually or more often.
Networks and applications
Network management and security, and security across the application life cycle.
Logs, cryptography and processing
Audit log monitoring and analysis, cryptographic controls and controls over straight through processing.
Chapter V

Baseline controls: users, customers and channels

User access
Need-based access, two-factor or multi-factor authentication based on risk, and logging and monitoring of privileged access to critical systems.
Teleworking, mail and media
Controls on remote working, secure mail and messaging, and removable media.
Customer authentication
An authentication framework for customers.
Transaction monitoring
Risk-based transaction monitoring across all delivery channels as part of fraud risk management, and customer alerts through an alternate channel for transactions above a value the customer sets.
Customer education
Raising customers’ awareness of cyber risks.
Chapter V

Baseline controls: detection, testing and recovery

Surveillance and threat defence
Continuous surveillance, advanced real-time threat defence and anti-phishing.
VA and PT
Critical systems and customer-facing DMZ systems: vulnerability assessment at least every six months, penetration testing at least every 12 months. Non-critical systems on a risk basis. Closure reported to the ITSC and ISC at least quarterly.
Red teaming
Permitted, not required.
Business continuity and DR
Practice such as ISO 22301, half-yearly drills for critical systems with the DR site run as primary for at least a full working day, periodic restoration of backups, ITSC-approved minimal recovery time and near-zero data loss for critical systems.
Incident response and crisis management
Response and recovery arrangements and a Cyber Crisis Management Plan covering detection, containment, response and recovery. Incidents reported to RBI on DAKSH within six hours of detection, with proactive notice to CERT-IN.
Forensics and metrics
Forensic and DDoS mitigation support on standby, and key performance and risk indicators including recovery objectives for critical systems.
Chapter V

Baseline controls: third parties and people

Third-party arrangements
For IT and cybersecurity arrangements outside the outsourcing directions: proportionate controls including concentration risk, a bank right to audit, RBI inspection rights and access to information resources, location of infrastructure, and mandatory background checks and non-disclosure agreements.
ATM Switch Application Service Providers
Baseline controls the provider must implement, including PCI DSS and PCI SSF where applicable, and sharing VA/PT reports with the bank or RBI on request.
Awareness
Annual training for the Board and senior management and for lower and middle management, and mandatory awareness for new recruits.
Chapter VI

Cyber Security Operations Centre

Governance
A framework sized to the bank’s risk profile, with threat briefings and dashboards for the Board or ITSC.
Capabilities
SIEM-based monitoring, root-cause analysis, collection of indicators of compromise, forensic tools and honeypot services.
Staffing
Three tiers, from round-the-clock monitoring to advanced analysis, staffed for 24x7 operation through in-house or managed-service models.
Chapter VII

Information systems audit

IS Audit Policy
Approved by the Audit Committee of the Board and reviewed at least annually.
Function and approach
A separate IS audit function or skilled resources within internal audit, with continuous auditing of critical systems to be considered wherever possible.
Chapter VIII

Repeal and other provisions

Repeal of the earlier cybersecurity framework and IT governance directions for Payments Banks, a saving clause, application of other laws and interpretation.

Implementation roadmap

How to implement it, step by step

A sequence suited to a Payments Bank, where digital channels and partners carry most of the operation.

  1. 1

    Draw the regulatory boundary

    Separate what falls under CTRRAF from what falls under the Digital Payment Security Controls Directions and the outsourcing directions, so that each control has one home and one owner.

    OutputsScope note across RBI directionsOwnership matrix
  2. 2

    Confirm governance

    Check the IT Strategy Committee’s chair and composition, the IT Steering and Information Security Committees, and the CISO’s rank, term and reporting line. Record the Board’s decision on delegating policy review under the substituted paragraph 7.

    OutputsCommittee chartersBoard resolution
  3. 3

    Identify critical and customer-facing systems

    List critical systems through risk assessment, along with DMZ systems that face customers, since testing and recovery rules attach to them.

    OutputsCritical systems register
  4. 4

    Bring partners into the programme

    Classify technology partners, update contracts for audit, inspection, location and personnel clauses where CTRRAF applies, and check any ATM switch provider against its baseline list.

    OutputsPartner classificationContract updates
  5. 5

    Close baseline gaps

    Work through the 31 areas by risk, with customer authentication, transaction monitoring and customer alerts given early attention given the bank’s channel exposure.

    OutputsGap registerRemediation plan
  6. 6

    Test detection, response and recovery

    Schedule six-monthly VA, annual PT and half-yearly DR drills. Confirm the operations centre model and rehearse the six-hour DAKSH report.

    OutputsTesting calendarCCMPDrill reports
  7. 7

    Establish assurance and reporting

    Approve the IS Audit Policy and plan, and put quarterly CISO and VA/PT closure reports before the committees.

    OutputsIS Audit PolicyCommittee packs
  8. 8

    Stay current

    Track amendments to all applicable RBI directions, repeat annual reviews and training, and keep evidence fresh between inspections.

    OutputsAmendment logEvidence library

Audit and evidence guide

What auditors look for, and the evidence to keep

RBI supervision and the bank’s own IS audit test whether the Directions operate in practice. Expect reviewers to sample records against the frequencies in the text.

What reviewers look for

  • Committee composition and quarterly meeting records
  • Annual policy review, delegation to the ITSC and Board approval of material amendments
  • CISO independence and direct reporting to the Executive Director overseeing risk
  • How critical systems and customer-facing DMZ systems were identified
  • VA and PT reports and quarterly closure reporting
  • DR drills run on the recovery site as primary for a full working day
  • Incident detection times and DAKSH reports within six hours
  • Customer alerting and risk-based transaction monitoring across channels
  • Third-party contracts and ATM switch provider controls
  • IS audit coverage and closure of findings

Recurring obligations and timelines

Board-level policy reviewAt least annually
IT Strategy Committee meetingsAt least quarterly
IT Steering Committee meetingsAt least quarterly
CISO cyber risk reviewAt least quarterly
VA of critical and customer-facing DMZ systemsAt least every 6 months
Penetration testing of the same systemsAt least every 12 months
VA/PT closure status to ITSC and ISCAt least quarterly
DR drills for critical systemsAt least half-yearly
IT architecture review by the ITSCAt least annually
Capacity assessmentAnnually or more often
IS Audit Policy reviewAt least annually
Board and senior management trainingAnnually
Cyber incident report to RBI on DAKSHWithin 6 hours of detection

Evidence to keep, by area

Examples to guide your evidence library. Your auditor or regulator decides what is sufficient.

Governance

  • Committee minutes and charters
  • Policy approvals and review records
  • CISO appointment and reporting line

Risk

  • IT and information security risk register
  • Critical systems register
  • Risk-cost trade-off records

Channels and customers

  • Customer authentication design
  • Transaction monitoring rules and alerts
  • Customer alert configuration
  • Customer awareness material

Testing and recovery

  • VA and PT reports
  • Closure tracker
  • DR drill reports
  • Backup restoration records

Incidents

  • Incident register with detection times
  • DAKSH and CERT-IN submissions
  • Cyber Crisis Management Plan

Partners

  • Partner classification by regime
  • Contracts with audit and inspection rights
  • ATM switch provider evidence

IS audit

  • IS Audit Policy
  • Audit plan and reports
  • Finding closure records

Areas that often need attention

  • Overlap between CTRRAF and payment security controls with no single owner per control
  • Partners not classified between the outsourcing directions and CTRRAF
  • Committees meeting irregularly
  • CISO reporting through the technology function
  • Customer-facing systems missing from the VA and PT schedule
  • DR drills that never run a full day on the recovery site
  • Incident detection time not captured
  • Evidence held by partners and not retrievable at inspection

How Netra helps

Where each part of the work lives in Netra

Netra loads the Payments Banks Direction as requirements, tasks and policies, and keeps the bank’s own work and its partners’ evidence on one record.

An owner for every obligation

Task Engine

Requirements arrive as tasks with owners and due dates, and recurring tasks carry the quarterly, half-yearly and annual work.

One control serving several frameworks

Compliance Centre

One completed task can satisfy several frameworks, such as CTRRAF, CERT-IN and ISO 27001 where they overlap, with status derived from the work and evidence, never typed in.

Policies and their annual review

Policy Hub

A policy library generated at onboarding, with review dates and a policy score tied to the work behind each policy.

Technology partners

Third-Party Risk

Vendors found from what Accounts and Purchase pay, assessed through a vendor portal, with each decision recorded with a rating.

IT and information security risk

Risk Manager

A risk register with inherent and residual heatmaps, reduced as linked tasks complete.

IS audit and supervisory reviews

Audit Centre

Internal and regulatory audits run end to end with findings and corrective actions, using evidence held in a tamper-evident vault.

Critical systems

Asset Management

Assets linked to tasks, so testing and recovery work shows against the right systems.

Board and committee reporting

Dashboard & Reports

A live Posture Score and a one-click board report for the Direction.

Netra organises the work, evidence and reviews. It does not monitor transactions, run an operations centre, act as a SIEM or report incidents to RBI or CERT-IN, and it does not by itself establish compliance. The bank remains responsible for implementation and regulatory interpretation.

Common questions

More questions about Netra

See RBI CTRRAF 2026 - Payments Banks in Netra

See how Netra connects your framework requirements with tasks, evidence and audit follow-up.