RBI Digital Payment Security Controls

Introduction: The RBI Master Direction on Digital Payment Security Controls

On 18 February 2021 the Reserve Bank of India (RBI) issued the Master Direction on Digital Payment Security Controls (Ref. RBI/2020-21/74, DoS.CO/CSITE/SEC.1852/31.01.015/2020-21) under the powers conferred by Section 10(2) read with Section 18 of the Payment and Settlement Systems Act, 2007. The Direction sets out a minimum, technology-and-platform-agnostic baseline of governance, security and resilience controls that regulated entities must implement across the entire life cycle of their digital payment products and channels. It applies chiefly to Scheduled Commercial Banks, Small Finance Banks, Payments Banks and Non-bank issuers of Prepaid Payment Instruments (PPIs), and it governs the security posture of internet banking, mobile banking, card-based payments and PPI-based payment ecosystems.

This guide is an auditor-grade deep-dive built for compliance officers, Chief Information Security Officers (CISOs), heads of digital banking, internal auditors and the QSA/CERT-In assessment teams who must evidence conformance. It walks through every requirement domain of the Master Direction, translates each into what an assessor will actually verify and the typical evidence an entity should retain, and maps the Direction to adjacent frameworks such as the RBI Cyber Security Framework, PCI DSS, ISO/IEC 27001 and NIST CSF. Throughout, the emphasis is on demonstrable, board-owned control ownership rather than paperwork, because the RBI supervisory model treats digital payment security as a continuous, risk-based obligation.

What is the RBI Digital Payment Security Controls Direction

The Master Direction on Digital Payment Security Controls is a principles-plus-prescriptive rulebook that consolidates the RBI's expectations for securing digital payment channels into a single instrument. Unlike a pure standard, it is a legally enforceable Direction: non-compliance can attract supervisory action, monetary penalties, and business restrictions. It is deliberately technology-neutral so that it remains applicable to future payment innovations, but it is prescriptive on outcomes such as multi-factor authentication, secure application development, transaction monitoring and customer protection.

The Direction is organised into a General set of controls that apply across all digital payment products, followed by channel-specific chapters for internet banking, mobile banking (including mobile applications), and card payments. It sits within a broader RBI supervisory stack that includes the Cyber Security Framework for banks (June 2016), the guidelines on Information Security, Electronic Banking, Technology Risk Management and Cyber Frauds (the 2011 G. Gopalakrishna Working Group report), the Master Directions on PPIs, and the Cyber Resilience and Digital Payment Security Controls for Non-bank PSOs (2024). An assessor must therefore read the Direction in concert with these instruments rather than in isolation.

Key thematic pillars of the Direction are: board and senior-management governance; a documented Digital Payment security policy; secure product design and application security; robust authentication (with a strong preference for multi-factor and risk-based/adaptive authentication); protection of the payment infrastructure and data; real-time fraud and transaction monitoring; customer protection, awareness and grievance redress; incident response and reporting; and third-party/outsourcing risk management. Reconciliation, alerting and customer consent (e.g., limits, opt-in for online usage of cards) are recurring control motifs.

Who must comply

The Direction applies to Regulated Entities (REs) that offer digital payment products and services. The following table summarises the primary categories in scope and the nature of their obligations.

• The Regulated Entity retains ultimate accountability even where functions are outsourced to service providers, fintech partners or cloud vendors.
• Applicability is by product and channel: an RE that offers only card payments must comply with the General plus Card chapters; one offering all channels must comply with all relevant chapters.
• Group entities and subsidiaries offering digital payments in India are expected to align with the same baseline.
• Overseas branches must comply with the stricter of the host-country requirements and this Direction where feasible.

Structure of the RBI Digital Payment Security Controls Direction

The Direction is structured as a General controls chapter (applicable to all digital payment products) followed by channel-specific chapters. The table below sets out the principal control domains, the aspects they cover, and representative control themes an assessor will test.

Master assessment checklist

This is the core of the guide. Each control group below is presented with a heading and a two-column table: What to verify (the assessor test) and Typical evidence (what the RE should be able to produce). The groups collectively cover every domain of the Direction. No control area is skipped.

1. Governance and Management Oversight

2. Generic / Common Security Controls

3. Application Security Life Cycle (ASLC)

4. Authentication Framework

5. Fraud Risk Management and Transaction Monitoring

6. Reconciliation Mechanism

7. Customer Protection, Awareness and Grievance Redress

8. Internet Banking Security Controls

9. Mobile Payment Application Security Controls

10. Card Payment Security Controls

11. Incident Response and Reporting

12. Third-Party and Outsourcing Risk Management

Scoping the assessment

Scoping determines which chapters and controls apply to a given Regulated Entity and which systems fall within the assessment boundary. Because the Direction is channel-based, scoping is a function of the digital payment products the RE offers and the infrastructure that stores, processes or transmits payment data or authenticates payment transactions.

• Channel scope: identify whether the RE offers internet banking, mobile banking/apps, card payments, PPIs, or a combination; each pulls in the General chapter plus the relevant channel chapter.
• System scope: include front-end apps, APIs and gateways, payment switches, core-adjacent systems, authentication services, FRM/reconciliation systems, HSMs and key stores, and supporting infrastructure.
• Data scope: include cardholder data, credentials, transaction data, customer PII and consent records; note data-localisation obligations for payment data.
• Third-party scope: include outsourced processing, hosting, fraud, tokenisation and gateway providers where they touch payment data or controls.
• Environmental scope: production plus non-production environments where payment data or code is handled; note segregation requirements.
• Geographic scope: India operations primarily, with data-localisation and cross-border considerations for international card usage.

Implementation approach (phased)

A phased programme lets an RE reach and sustain compliance without disrupting live payment operations. The five phases below each list core activities and deliverables.

Phase 1 — Mobilise and assess (Weeks 1-4)

• Activities: establish governance and a steering committee; appoint an accountable owner (CISO); confirm applicable channels and scope; perform a gap assessment against every domain of the Direction.
• Deliverables: programme charter; scope and data-flow diagrams; gap-assessment report; prioritised remediation backlog; board briefing.

Phase 2 — Design and policy (Weeks 4-8)

• Activities: draft/refresh the board-approved Digital Payment security policy and supporting standards (auth, crypto, ASLC, FRM, IR, vendor); define risk appetite and control ownership.
• Deliverables: approved policy suite; RACI; control catalogue mapped to the Direction; target architecture.

Phase 3 — Build and remediate (Weeks 8-20)

• Activities: implement MFA/adaptive authentication, FRM tuning, reconciliation automation, app hardening, tokenisation, logging/SIEM use-cases, segmentation and hardening; remediate VAPT findings; embed secure SDLC gates.
• Deliverables: configured controls; remediation closure evidence; updated VAPT reports; SIEM use-case library.

Phase 4 — Validate and test (Weeks 20-26)

• Activities: conduct independent VAPT, red-team/scenario testing, IR tabletop and reconciliation dry-runs; validate customer-protection features (alerts, limits, card controls); internal audit review.
• Deliverables: independent test reports; audit report; residual-risk register; management sign-off.

Phase 5 — Operate and improve (Ongoing)

• Activities: continuous monitoring, periodic reviews, rule tuning, patch/VA cycles, awareness campaigns, vendor reassessments, and RBI/CERT-In reporting readiness.
• Deliverables: KPI dashboards; periodic board reports; refreshed risk assessments; audit-trail of continuous improvement.

Maturity / capability model

While the Direction sets a mandatory baseline (compliance is binary at the requirement level), a maturity model helps an RE benchmark the robustness and sustainability of its controls and prioritise investment. The five-level model below is a practical assessment lens.

Assessment and audit approach

An assessment against the Direction should be structured, evidence-led and repeatable. The following steps describe an effective audit lifecycle.

1. Confirm scope: identify applicable channels, systems, data and third parties; obtain current data-flow diagrams.
2. Review governance: examine the board-approved policy, committee minutes, ownership and risk assessments.
3. Walk through each domain: use the master checklist to test governance, generic controls, ASLC, authentication, FRM, reconciliation, customer protection and channel-specific controls.
4. Perform technical validation: review VAPT/SAST/DAST results, configuration and cryptography scans, and inspect live control behaviour.
5. Test operating effectiveness: sample transactions, alerts, reconciliation exceptions, incident tickets and grievance cases over a period.
6. Assess third-party controls: review vendor due diligence, contracts, right-to-audit and monitoring evidence, plus data-localisation.
7. Evaluate incident and reporting readiness: examine IR plan tests and RBI/CERT-In reporting evidence and timelines.
8. Rate and report: document findings, severity, root cause and residual risk; map each to the relevant domain of the Direction.
9. Agree remediation: define owners, target dates and validation criteria; track to closure with retesting.
10. Report to management and board: provide an assurance opinion, maturity rating and prioritised action plan.

Evidence request list

The following categorised list is what an assessor typically requests. Preparing these in advance materially shortens the assessment.

• Governance: board-approved Digital Payment security policy; committee charters and minutes; org chart and RACI; product risk assessments.
• Architecture: network diagrams; data-flow diagrams; asset/API inventory; segmentation and firewall rulesets.
• Application security: secure coding standards; SAST/DAST/SCA reports; VAPT reports and closure evidence; change-management records; code-signing.
• Authentication: MFA and adaptive-auth configuration; session-management settings; device-binding logs; credential-handling design.
• Fraud and monitoring: FRM rule catalogue and tuning records; alert samples; cooling-period config; fraud MIS and RBI reporting.
• Reconciliation: reconciliation SOPs and reports; exception/ageing registers; failed-transaction reversal and TAT evidence.
• Customer protection: alert configuration and logs; limit and card-control features; awareness collateral; grievance MIS and liability handling.
• Cryptography and keys: crypto standard; TLS/cipher scans; certificate inventory; HSM and key-rotation records.
• Logging and SIEM: log-retention policy; SIEM use-case list; sample correlated alerts; NTP configuration.
• Incident response: IR plan and playbooks; tabletop/test records; incident reports with RBI/CERT-In timestamps; RCA and CAPA.
• Third-party: vendor risk assessments; executed contracts with security and audit clauses; vendor scorecards; data-localisation attestations.
• Compliance overlays: PCI DSS AoC/RoC (card environment); ISO 27001 certificate; prior RBI inspection observations and closure.

Roles and responsibilities

KPIs to track

• Percentage of digital payment transactions covered by real-time fraud monitoring.
• MFA/AFA coverage rate and adaptive-authentication step-up conversion and false-decline rate.
• Number and ageing of open critical/high VAPT findings on payment applications.
• Patch SLA adherence for payment infrastructure (percentage patched within window).
• Reconciliation exception volume, ageing and time-to-resolution; failed-transaction TAT adherence.
• Fraud loss rate (basis points of transaction value) and fraud detection precision/recall.
• Customer complaint volume and grievance TAT adherence; limited-liability shadow-reversal timeliness.
• Incident count, mean-time-to-detect and mean-time-to-respond; RBI/CERT-In reporting timeliness.
• Percentage of customers with active card-control and transaction-limit settings.
• Vendor assessments completed on schedule and open vendor risk findings.
• Awareness campaign reach and phishing-simulation failure rate.
• Data-localisation compliance status for payment data storage.

Readiness checklist

• Board-approved Digital Payment security policy is current and covers all offered channels.
• Data-flow diagrams and asset/API inventory are complete and up to date.
• MFA and adaptive/risk-based authentication are enforced across channels.
• Additional Factor of Authentication is applied per RBI norms with a documented exemption register.
• Real-time fraud monitoring with tuned rules and cooling periods is operational.
• Automated reconciliation with exception tracking and TAT adherence is in place.
• Customer alerts, transaction limits and card on/off controls are live and logged.
• Secure SDLC with SAST/SCA and pre-release VAPT is embedded, with findings remediated.
• Card data environment is PCI DSS compliant with tokenisation implemented.
• Cryptography, TLS and HSM-backed key management are validated.
• SIEM logging, retention and correlation use-cases are operational.
• Tested incident response plan with RBI/CERT-In reporting timelines is documented.
• Vendor contracts include security, right-to-audit and data-localisation clauses.
• Payment data is stored in India in line with localisation requirements.
• Independent testing and internal audit reports are available with closure evidence.
• Grievance redress and limited-liability framework operate within defined TATs.

Common gaps

• A generic information-security policy exists but no distinct, board-approved Digital Payment security policy mapped to the Direction.
• Adaptive/risk-based authentication is missing; authentication is static MFA only, with weak session management.
• Fraud monitoring is batch or rule-poor, lacking behavioural analytics and beneficiary/limit cooling periods.
• Reconciliation is partly manual, with ageing exceptions and inconsistent failed-transaction TAT compliance.
• Card controls (switch on/off, default-disabled online/international) are incomplete or not logged for consent.
• Card-of-file tokenisation and PCI DSS scope are not fully implemented or evidenced.
• Mobile apps lack root/jailbreak detection, secure storage, attestation or certificate pinning.
• Secure SDLC gates are informal; VAPT is annual only and not tied to major changes; findings linger.
• Incident-reporting timelines to RBI/CERT-In are not rehearsed; forensic readiness is weak.
• Third-party contracts omit right-to-audit and data-localisation clauses; vendor monitoring is one-off.
• Payment data localisation is assumed rather than evidenced.
• Customer-protection features exist but grievance TATs and limited-liability shadow-reversal are not consistently met.

RBI Digital Payment Security Controls mapped to other frameworks

The Direction shares substantial common ground with other security frameworks. The mapping below helps REs leverage existing certifications and avoid duplicate effort. Mappings are indicative, not one-to-one.

How CyberSigma helps

Frequently asked questions

Need help with RBI Digital Payment Security Controls?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.