TL;DR for founders
If your fintech partners a bank for UPI, wallets, internet banking or card issuance, that bank is bound by the RBI (Digital Payment Security Controls) Directions, 2021 dated 18 February 2021. The bank's diligence will demand: Board-approved product policy, PCI-DSS where card data touches you, multi-factor authentication on every electronic payment, device binding plus jailbreak/root detection in your mobile app, SAST/DAST in your SDLC, half-yearly Vulnerability Assessments and annual Penetration Tests, and reconciliation within 24 hours. The 2024 RBI extension also pulls non-bank PSOs (PPI issuers, payment aggregators) into a parallel regime. First step this week: ask your partner bank's CISO for their Digital Payment Security Controls compliance questionnaire and the latest Paragraph 22 threat-model template.
Who this playbook is for
In scope — Regulated Entities ("REs") directly bound by the Master Direction (Clause 2, Chapter I):
- Scheduled Commercial Banks excluding Regional Rural Banks — public sector, private sector, foreign
- Small Finance Banks (SFBs)
- Payments Banks
- Credit-card-issuing NBFCs
In scope — by the 2024 extension (separate Master Direction):
- Non-bank Payment System Operators (PSOs) — PPI Issuers, Payment Aggregators, card networks, cross-border PSOs — brought under a parallel Cyber Resilience and Digital Payment Security Controls framework in 2024, indexed on the RBI Master Directions page and aligned with the 2021 bank directions.
Contractually in scope (non-REs):
- Fintech partners, neobanks, merchants, payment gateway integrators, co-branded card partners, mobile app vendors — caught through the RE's IT Outsourcing Policy under Chapter V of the RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices dated 7 November 2023 ('IT Governance MD').
- Source-code licensors of digital payment applications — Paragraph 23 requires source-code escrow where the application is licensed.
Key definitional anchor: Clause 3 imports definitions from the Banking Regulation Act, 1949, the Reserve Bank of India Act, 1934, the Payment and Settlement Systems Act, 2007 and the Information Technology Act, 2000 / IT (Amendment) Act, 2008. "Regulated Entity" for the purposes of the 2021 Master Direction is limited to the four categories in Clause 2; the 2024 extension adds non-bank PSOs via a separate instrument.
Not in scope:
- Regional Rural Banks (explicitly excluded under Clause 2(a))
- Local Area Banks not in the enumerated categories
- Pure peer-to-peer fintechs without a bank or PSO relationship — though every such fintech should monitor because merchant / API onboarding into a bank now turns on this Master Direction.
Prerequisites
Everything below must be in place before a Regulated Entity's Board can credibly attest compliance. The Master Direction is a controls instrument whose evidence sits in architecture diagrams, code pipelines, SOC dashboards, reconciliation reports and customer-grievance SOPs.
Documents needed:
- Board-approved Digital Payment Products and Services Policy under Paragraph 4, covering Functionality, Security and Performance (FSP); reviewed at least annually
- Product-level security risk limits and documented security objectives with quantitative benchmarks (Paragraph 6)
- Risk and Control Self-Assessment (RCSA) register with payment-data protection as a specific control category (Paragraph 8)
- Threat model per digital payment application (Paragraph 22) and for every co-branded / co-developed application
- Secure SDLC standard covering requirements, design, development, testing (with source code review), implementation, maintenance, monitoring and decommissioning (Paragraph 21)
- Source-code escrow agreement where the digital payment application is third-party licensed (Paragraph 23)
- Board-approved IT/IT-Security architecture review mechanism with periodic technology-platform overhaul (Paragraph 11)
- PCI-DSS current attestation of compliance where card data is processed (Chapter V, Paragraph 67)
- Customer protection SOP including unauthorised-transaction handling aligned with RBI circular DBR.No.Leg.BC.78/09.07.005/2017-18 dated 6 July 2017
- Online Dispute Resolution (ODR) system per RBI circular RBI/2020-21/21 DPSS.CO.PD No.116/02.12.004/2020-21 dated 6 August 2020 (Paragraph 44)
Roles required:
- Board and Senior Management — responsible for policy implementation (Paragraph 4 last line); set KPIs for operational and security norms (Paragraph 5)
- Chief Information Officer (CIO) and Chief Information Security Officer (CISO) — under the RBI IT Governance MD 2023; the CISO must be functionally independent of IT operations
- Board-level IT Strategy Committee — convened under the IT Governance MD 2023, reviewing this Master Direction's compliance quarterly
- Fraud control function — trained per Paragraph 39; staffing with fraud-control tools, investigative techniques, cardholder/merchant education and scheme/card operating regulations
- 24x7 Security Operations Centre — for transaction surveillance under Paragraph 72 (24x7 monitoring including weekends and long holidays)
- Grievance Redressal Officer — under Paragraph 43 with defined response timelines
Approvals needed:
- Board resolution approving the Digital Payment Products and Services Policy
- Product Approval Committee sign-off for every new digital payment product (covering Paragraphs 4(a)–(g) and 8(a)–(l))
- External assessment engagement for Application Security Life Cycle (ASLC) as articulated in the policy requirement at Paragraph 4
Step-by-step compliance process
Step 1: Governance — establish the Board-approved digital payment policy
What: Under Paragraph 4, formulate a Board-approved policy for digital payment products and services that explicitly addresses Functionality, Security and Performance (FSP) from seven angles (controls to protect customer data confidentiality and process integrity; availability of infrastructure; secure-by-design assurance; scalability; minimal customer service disruption; dispute resolution; review mechanism).
Where: Board meeting; policy document maintained by the CISO under the IT Governance MD.
How: Define the product lifecycle starting point, critical intermediate stages, end point, security validations until settlement, pictorial digital path, exception handling, UAT cadence (multi-stage), sign-off from multiple stakeholders post-UAT, data archival requirements, and the need for external assessment of logic, build and security. Review annually.
Common mistakes: Policy reads as an IT wishlist rather than a product-security policy; FSP angles collapsed into a single "security" section; no external assessment requirement articulated; no UAT sign-off matrix.
Step 2: Risk management — operate product-level security limits and RCSA
What: Under Paragraphs 5–8, operate an IT risk management programme that sets product-level acceptable security risk limits, documents security objectives with quantitative benchmarks, periodically compares actual results, and runs an RCSA spanning twelve risk factors including third-party dependencies, integration risk, customer experience, reconciliation, interoperability, data privacy, operational risk, business continuity, compliance with cyber security requirements and compatibility.
Where: Enterprise Risk Management framework; RCSA register; Board Risk Management Committee dashboard.
How: Maintain a database of every system and application storing customer data in the payment ecosystem, with PCI-standard compliance for each (Paragraph 8 footnote). Evaluate risks before service establishment and regularly thereafter; re-evaluate after incidents, before major infrastructure changes and when new threats emerge (Paragraph 9). Document residual risk acceptance at the Board or Board Risk Management Committee.
Common mistakes: RCSA run annually at a holding-level without product-line granularity; customer-data database not maintained; residual risk acceptance undocumented.
Step 3: Secure SDLC and Application Security Life Cycle (ASLC)
What: Under Paragraphs 19–27, implement multi-tier application architecture with presentation / application / database segregation, 'secure by design' development, threat modelling, source-code escrow for third-party licensed applications, SAST/DAST/SCA testing including OWASP, and half-yearly Vulnerability Assessment plus annual Penetration Testing.
Where: Development pipelines; SAST/DAST/SCA tooling; VAPT vendor panel.
How: Define security objectives at each SDLC phase (Paragraph 21). Source-code testing on an annual basis if changes were made (Paragraph 24(b)). Vulnerability Assessment at least half-yearly; Penetration Testing at least yearly; additional VA/PT on any new IT infrastructure or digital payment application or on major change (Paragraph 24(a)). Continuous automated VA scanning on critical, public-facing or customer-sensitive-data systems (Paragraph 25). Include penal provisions in third-party contractual arrangements for any non-compliance by the application provider (Paragraph 24(b) last bullet).
Common mistakes: SAST/DAST tooling present but not wired into the CI pipeline as a gate; VA cadence quarterly internal scanning mistaken for Paragraph 24 half-yearly compliance; no source-code certificate from the developer when the RE does not own the source code.
Step 4: Application security — WAF, DDoS, data storage, logging
What: Under Paragraphs 13–18, secure the digital payment ecosystem with encryption, WAF and DDoS mitigation, digital certificate lifecycle, prohibition on sensitive data in HTML hidden fields / cookies / client-side storage, and effective application logging and monitoring.
Where: Perimeter security stack; web application firewall; digital certificate management system; SIEM.
How: Implement internationally accepted and published encryption standards not deprecated or insecure (Paragraph 16); renew digital certificates in time (Paragraph 17); prohibit storage of sensitive information in HTML hidden fields, cookies or other client-side storage (Paragraph 14); mandate effective logging and monitoring for user activity, security changes and anomalous behaviour for both internet banking and mobile payment applications (Paragraph 18).
Common mistakes: TLS 1.0/1.1 still accepted on legacy endpoints; digital certificate lapse events; authentication cookies carrying sensitive values; logging enabled but anomaly detection not tuned.
Step 5: Authentication — mandatory MFA with dynamic or non-replicable factor
What: Under Paragraph 33, implement multi-factor authentication for payments through electronic modes and fund transfers — including cash withdrawals from ATMs/micro-ATMs/business correspondents — through digital payment applications. At least one of the authentication methodologies shall generally be dynamic or non-replicable.
Where: Authentication stack; risk-based engine; customer-side alerts channel.
How: Dynamic or non-replicable methodologies include One Time Password, mobile device binding (hardware + software + service), biometric / PKI / hardware tokens, or EMV chip card for Card-Present Transactions with server-side verification (Paragraph 33). Paragraph 34 encourages adaptive authentication based on risk assessment, user profile and behaviour. Paragraph 34(c) mandates MFA + alerts (SMS, email) for all payment transactions (debits and credits), creation of new account linkages, changing account details or revision of fund transfer limits. Paragraph 34(d): OTPs and alerts should identify the merchant name, wherever applicable, not the payment aggregator. Paragraph 34(e): measures against man-in-the-middle, man-in-the-browser and man-in-the-application attacks. Paragraph 35: set a maximum number of failed log-in / authentication attempts after which access is blocked; implement a secure re-activation procedure.
Common mistakes: OTP sent only on debit without alert on credit / beneficiary addition; merchant name not surfaced in the alert (Paragraph 34(d) violation); failed-login threshold not documented.
Step 6: Fraud Risk Management — parameterised alerts and real-time monitoring
What: Under Paragraphs 36–40, document and implement configuration for identifying suspicious transactional behaviour, parameterised real-time alerts, fraud analysis and trained fraud control staff.
Where: Real-time fraud-risk engine integrated with the core banking / payments switch; fraud case management system; SOC.
How: Parameterise alerts on transaction velocity, fund transfers, cash withdrawals, additions of new beneficiaries (especially on accounts that have never used mobile/internet/card), high-risk merchant category codes, counterfeit card parameters (String of Invalid CVV/PINs), new account parameters, time zones, geo-locations, IP address origin, behavioural biometrics, transactions from points of compromise, transactions to suspect VPAs/mobile numbers, declined transactions and transactions with no approval code (Paragraph 37). Train staff in fraud-control tools, investigative techniques, cardholder/merchant education, scheme/card operating regulations and data processing (Paragraph 39). Maintain updated stakeholder contact details and formulate specific SOPs for payment-ecosystem incidents (Paragraph 40).
Common mistakes: Fraud rules batched overnight rather than real-time; behavioural biometrics cited in policy but not deployed; no fraud-control-staff training record.
Step 7: Reconciliation — near-real-time or within 24 hours
What: Under Paragraph 41, implement a real-time / near-real-time reconciliation framework — and in any event not later than 24 hours from receipt of settlement files — for all digital payment transactions between the RE and payment system operators, business correspondents, card networks, processors, aggregators, gateways and third-party technology service providers.
Where: Reconciliation engine; settlement file handlers; monitoring dashboard.
How: Reconciliation must detect and prevent suspicious transactions. Implementation and effectiveness must be independently monitored.
Common mistakes: End-of-day batch reconciliation with a 48-hour SLA; no visibility into aggregator settlement timing; exceptions report dropped without adjudication.
Step 8: Customer protection — zero-liability, 10-day refund, ODR, awareness
What: Under Paragraphs 42–50, incorporate secure usage guidelines and training materials into every digital payment application, mandate customer acknowledgement, establish a grievance registration channel, and align unauthorised-transaction liability with the 6 July 2017 RBI circular.
Where: Mobile and internet banking applications; customer support channels; ODR portal.
How: Per RBI circular DBR.No.Leg.BC.78/09.07.005/2017-18 dated 6 July 2017, where the customer notifies within three working days the RE must shadow-reverse the entry within 10 working days; zero customer liability where the contributory fraud / negligence is by the RE or a third party. Implement the Online Dispute Resolution (ODR) system per RBI circular RBI/2020-21/21 DPSS.CO.PD No.116 dated 6 August 2020 (Paragraph 44). Paragraph 50: provide a customer-facing mechanism within the mobile/internet banking application for the customer to mark a transaction as fraudulent with immediate notification to the RE and seamless onward notification to counterparty REs.
Common mistakes: Zero-liability SOP exists but the 10-working-day shadow reversal is not automated; fraud-flag button buried three screens deep; no customer acknowledgement captured on application updates that change security features.
Step 9: Internet Banking Security (Chapter III)
What: Under Paragraphs 51–54, apply additional controls to internet banking channels — adaptive authentication, strong CAPTCHA with anti-bot features and server-side validation, DNS cache poisoning prevention, secure cookie handling, virtual keyboard, automatic session termination after inactivity, secure password delivery with forced first-login change, and uniform authentication look-and-feel where the internet banking application is accessed through external websites.
How: Session termination mandatory after a fixed period of inactivity (Paragraph 52); password delivered by the RE must be valid for only a limited period from creation; first-login password change compulsory (Paragraph 53).
Common mistakes: CAPTCHA client-side only; session timeout configured but not applied to API sessions; tax-payment / e-commerce redirect flow using a different visual template than the RE's internet banking.
Step 10: Mobile Payments Application Security (Chapter IV)
What: Under Paragraphs 55–66, apply additional controls to mobile payment applications — anomaly-triggered reinstall, device policy enforcement, secure download/install, older-version deactivation within six months (Paragraph 56(c)), data storage and device encryption, minimal app permissions, sandboxing/containerisation, remote-access-app detection, code obfuscation, rooted/jailbroken device check, checksum publication (Paragraph 59), device binding (Paragraph 60), alternatives to SMS-OTP where app and OTP reside on the same device (Paragraph 61), re-authentication on device/app inactivity and new/unsecured network detection (Paragraph 62), no persistent storage of sensitive data on device (Paragraph 63), encrypted/masked temp files (Paragraph 64), anti-malware capability (Paragraph 65) and protection against SQL injection (Paragraph 66).
How: Device binding preferably through a combination of hardware, software and service information (Paragraph 60 footnote). Multi-device registration: notify on every new registration across channels and provide a disable facility.
Common mistakes: Old versions still installable beyond six months post-release (Paragraph 56(c) violation); no rooted-device check; code obfuscation disabled in release builds; SMS OTP used as the second factor on the same device as the mobile banking app.
Step 11: Card Payments Security (Chapter V)
What: Under Paragraphs 67–73, apply PCI family standards (PCI-DSS, PCI-PIN, PCI-PTS, PCI-HSM, PCI-P2PE, PA-DSS / PCI SSS); validate merchant terminals under PCI-P2PE; use PCI-PTS approved PIN-entry PoS terminals; implement UKPT or DUKPT / Terminal Line Encryption on card acceptance; lock down HSMs (Paragraph 70) with tamper-proof logs, ACL-based access, PIM, application-level isolation, PIN block format integrity; harden ATMs (BIOS password, USB disable, auto-run disable, patching, anti-skimming, whitelisting, supported OS versions only — Paragraph 71); operate 24x7 card transaction surveillance including weekends and long holidays (Paragraph 72); and secure card-data-scanning-tool use (Paragraph 73).
How: Transaction limits set at the card network switch itself — at Card, BIN and RE level, with domestic and international limits separately, and Board-approved policy review (Paragraph 72). Card details must never be stored in plain text at the RE or vendor locations, systems or applications.
Common mistakes: Plain-text PAN in audit/log tables; card-data scanning tool exported results beyond the RE's premises (Paragraph 73(d) violation); international transaction limits defaulted to maximum.
Step 12: Incident reporting and cross-framework alignment
What: File CERT-In, RBI, customer and — where personal data is involved — DPDP notifications in parallel.
Where: Incident response runbook; 24x7 SOC escalation tree.
How: Per Direction (ii) of the CERT-In Directions dated 28 April 2022 (No. 20(3)/2022-CERT-In) issued under Section 70B(6) of the Information Technology Act, 2000, a payment-system attack (Annexure I category xiv) or any of the other twenty categories must be reported to CERT-In within 6 hours of noticing, independently of RBI reporting. File the RBI report through the DoS/DPSS/CSITE channels as applicable. Personal-data breach: intimation under Section 8(6) of the Digital Personal Data Protection Act, 2023 to the Data Protection Board under Rule 7 of the DPDP Rules 2025 (G.S.R. 846(E), 13 November 2025). Customer notification per Paragraph 50 in parallel.
Common mistakes: CERT-In filing treated as discharging RBI; DPDP Rule 7 intimation delayed beyond what CERT-In triggers; no NPCI chargeback coordination when the incident affects UPI or IMPS (cross-reference NPCI UPI OC-184-B of 15 February 2025 and IMPS OC-124 for fraud chargeback).
Timeline
| Milestone | Statutory deadline | Realistic timeline |
|---|---|---|
| Master Direction effective | 18 August 2021 (six months from 18 February 2021 placement on RBI website) | — |
| Gap assessment against Chapters I–V | — | Month 1–2 from kick-off |
| Board-approved Digital Payment Policy (Paragraph 4) | Annual review | Month 2–3 |
| CIO/CISO reporting lines aligned with RBI IT Governance MD 2023 | From 1 April 2024 | Month 2–4 |
| MFA with dynamic/non-replicable factor rolled out on every electronic payment (Paragraph 33) | On deployment of every product | Month 3–5 |
| Secure SDLC + SAST/DAST + threat model | Ongoing; VA half-yearly, PT yearly | Month 4–7 |
| Real-time fraud risk monitoring live (Paragraphs 36–40) | Continuous | Month 5–8 |
| Reconciliation within 24 hours of settlement file (Paragraph 41) | Continuous | Month 5–8 |
| Customer protection flows — zero-liability SOP + 10-working-day shadow reversal + ODR | Continuous | Month 6–9 |
| First Paragraph 50 fraud-flag mechanism live on every mobile and internet banking app | Continuous | Month 6–9 |
| Annual independent IS assurance per RBI IT Governance MD | Annually | Month 9–12 |
| Ad-hoc cyber incident notification — CERT-In | 6 hours from noticing | Hour 4 internal buffer |
| Backed-up data and application half-yearly testing (Paragraph 12) | Half-yearly | Month 6 and Month 12 |
The Master Direction does not provide a grace period beyond the six-month initial effective date (Clause 1(b)). Instructions already issued by DPSS / DoR / DoS by circular or advisory apply with immediate effect or per the timeline in the original instruction.
Template clauses / language
Template A — API Security Addendum for Merchant / Fintech Partners
Clause [X] — RBI Digital Payment Security Controls Compliance (API Partners)
1. Partner acknowledges that Bank is a Regulated Entity within the scope of
the Reserve Bank of India (Digital Payment Security Controls) Directions,
2021 issued vide RBI/2020-21/74 DoS.CO.CSITE.SEC.No.1852/31.01.015/2020-21
dated 18 February 2021 ('DPSC Directions'). Partner shall comply with all
controls flowed down by Bank from time to time, including Paragraphs 13-
18 (Generic Security Controls), 19-32 (ASLC), 33-35 (Authentication), 36-
40 (Fraud Risk Management), 41 (Reconciliation), and 42-50 (Customer
Protection).
2. Partner shall: (a) implement multi-factor authentication with at least
one dynamic or non-replicable factor on every electronic payment integrated
through the API, consistent with Paragraph 33 DPSC Directions; (b) transmit
all payment data over TLS 1.2 or higher using cipher suites not deprecated
by accepted international standards, consistent with Paragraph 16 DPSC
Directions; (c) never store sensitive customer information in HTML hidden
fields, cookies or other client-side storage, consistent with Paragraph 14
DPSC Directions.
3. Partner shall conduct, at its own cost, Vulnerability Assessment of the
API and related systems at least once every six months and Penetration
Testing at least annually, plus an additional VA/PT on any new
infrastructure or any major change, consistent with Paragraph 24 DPSC
Directions. Partner shall share the executive summary and remediation
plan with Bank within thirty (30) days of each exercise and shall close
all High-severity findings within thirty (30) days followed by validation
testing.
4. Partner shall source-code-certify the API as free of known vulnerabilities,
malware and covert channels where Bank does not own the source code
(Paragraph 24).
5. Partner shall reconcile with Bank in near-real time and in any event
within twenty-four (24) hours of receipt of settlement file(s), consistent
with Paragraph 41 DPSC Directions.
6. Partner shall report any cyber incident to Bank's Chief Information
Security Officer within two (2) hours of noticing, so that Bank can
discharge its 6-hour notification obligation to CERT-In under Direction
(ii) of the CERT-In Directions dated 28 April 2022 (No. 20(3)/2022-CERT-
In) issued under Section 70B(6) of the Information Technology Act, 2000,
and any parallel reporting to RBI and — where personal data is involved
— to the Data Protection Board under Section 8(6) of the Digital Personal
Data Protection Act, 2023.
Template B — Customer Unauthorised-Transaction SOP (Paragraphs 42-50 + 6 July 2017 Circular)
SOP — Customer-Reported Unauthorised Electronic Banking Transaction
Step 1. Customer reports the unauthorised transaction through the in-app
fraud-flag mechanism (Paragraph 50 DPSC Directions), branch, call
centre, SMS-based reply or email. Capture: customer details, account
reference, transaction reference, channel, customer-reported
notification time.
Step 2. Acknowledge receipt within 1 hour with a unique grievance reference
number.
Step 3. Determine the customer's liability category per RBI circular
DBR.No.Leg.BC.78/09.07.005/2017-18 dated 6 July 2017:
- Zero liability: if loss is on account of Bank's contributory
fraud / negligence, or third-party breach with customer notifying
within 3 working days.
- Limited liability (cap of ₹5,000 / ₹10,000 / ₹25,000 depending
on account type): if customer notifies within 4-7 working days.
- Beyond 7 working days: as per Bank's Board-approved policy.
Step 4. Shadow-reverse the disputed entry within 10 working days from the
date of customer notification, where zero or limited liability
applies.
Step 5. Fire parallel notifications: counterparty RE (Paragraph 50),
card network where applicable, and Online Dispute Resolution system
under RBI circular RBI/2020-21/21 DPSS.CO.PD No.116 dated 6 August
2020 (Paragraph 44).
Step 6. Close the grievance with written communication to the customer
stating the outcome and the recourse path (Banking Ombudsman under
the Reserve Bank - Integrated Ombudsman Scheme, 2021).
Internal audit checklist
Run before the Audit Committee of the Board tables the annual IT Assurance Report under the RBI IT Governance MD.
- Board-approved Digital Payment Policy — current within 12 months; covers Paragraph 4(a)–(g) FSP angles; UAT sign-off matrix present.
- Product-level security risk limits — documented with quantitative benchmarks; periodic actual-vs-benchmark review on record.
- Threat model — per application; refreshed on any material change.
- Source-code escrow — in place for every third-party licensed digital payment application.
- SAST/DAST/SCA — wired as CI pipeline gates; source-code review evidence for Paragraph 24(b) annual cadence.
- VA half-yearly + PT yearly — Paragraph 24(a) cadence met; high-severity findings closed within 30 days with re-test.
- Automated VA scanning — continuous mode on critical/public-facing/customer-data systems (Paragraph 25).
- Multi-factor authentication — with at least one dynamic/non-replicable factor on every electronic payment; alerts on debits, credits, beneficiary changes and limit revisions; merchant name in alerts.
- MITM/MITB/MITA mitigation — Paragraph 34(e) controls in place.
- Failed-login threshold + secure re-activation — Paragraph 35.
- Fraud risk engine — real-time parameterised alerts on velocity, geolocation, MCC, counterfeit-card patterns, new-account anomalies, suspect VPAs, declined transactions.
- Reconciliation — near-real-time; worst case within 24 hours of settlement file.
- Customer protection — zero-liability SOP with automated 10-working-day shadow reversal; ODR integrated.
- Mobile app controls — older version deactivated within 6 months; device binding; rooted/jailbroken check; no plain-text sensitive data on device; anti-malware capability; SSL pinning; SQL injection defences.
- Card channel controls — PCI-DSS attestation current; PCI-PTS PIN entry terminals validated; UKPT/DUKPT/TLE on acquiring; HSM hardened; ATM hardened with supported OS only; 24x7 card transaction surveillance including holidays.
- Incident response integration — CERT-In 6 hours + RBI + customer + DPDP where personal data is involved.
- Cross-framework map — DPSC Directions / RBI IT Governance MD 2023 / CERT-In Directions 2022 / DPDP Act 2023 + Rules 2025 / NPCI UPI and IMPS Operating Circulars / SEBI CSCRF where group entity is also SEBI-registered.
What if things go wrong
Failure 1 — Reconciliation breach of 24 hours (Paragraph 41)
- Symptom: Settlement-file reconciliation routinely running 30–40 hours on long-weekend cycles.
- Cause: Batch schedule misaligned with payment-system-operator settlement windows; no monitoring of effectiveness per Paragraph 41 second sentence.
- Action: Move reconciliation to near-real time; insert a monitoring KRI at the CISO dashboard; brief the IT Strategy Committee; submit a time-bound remediation plan to RBI CSITE if pattern detected during supervisory review.
Failure 2 — MFA bypass on a specific payment API (Paragraph 33)
- Symptom: A partner fintech's legacy API accepts username/password only.
- Cause: Boilerplate onboarding; flow-down clause omitted.
- Action: Turn off the affected API immediately; issue a partner breach notice; remediate under the API Security Addendum template; document at the ISRMC/ITSC; file CERT-In if any unauthorised transaction occurred and RBI notification if supervisory reporting thresholds triggered.
Failure 3 — Mobile app older version still active beyond 6 months (Paragraph 56(c))
- Symptom: v3.x installable on iOS App Store even after v4.0 released seven months ago.
- Cause: App Store listing not updated; phased deactivation schedule slipped.
- Action: Force upgrade on all v3.x sessions; sunset v3.x within 30 days; publish a checksum of the current active version per Paragraph 59.
Failure 4 — Cyber incident affecting customer accounts; 6-hour window missed
- Symptom: Ransomware on a payment adjunct system discovered overnight; CERT-In notified at 11:45 AM next day.
- Cause: 24x7 CERT-In PoC not in place; on-call escalation chain broke down between 22:00 and 08:00.
- Action: File the CERT-In notification immediately with a transparent cover note; file the RBI report via DoS CSITE; fire Paragraph 50 customer notifications; where personal data was exposed, file the DPDP Rule 7 breach intimation to the Data Protection Board under Section 8(6) DPDP Act 2023; brief the Board within 72 hours.
Failure 5 — PCI-DSS lapse concurrent with a card incident
- Symptom: PCI Attestation of Compliance expired three months ago; a card-data exposure incident surfaces.
- Cause: Certification engagement not renewed on schedule.
- Action: Emergency PCI re-attestation engagement; interim compensating controls with daily monitoring; notify RBI and card networks; consider cross-framework exposure under Section 43A IT Act and Section 33 DPDP Act.
Founder checklist
- Map every bank / PSO partner by 30 June 2026 — each bank and non-bank PSO you integrate with treats you as an IT Outsourcing engagement under Chapter V of the RBI IT Governance MD 2023; request their Paragraph 22 threat-model template, Paragraph 33 MFA specification and Paragraph 50 fraud-flag API specification.
- Assemble a "DPSC-ready" security dossier — PCI-DSS (if you touch card data), ISO 27001 or SOC 2 Type II, latest VA within 6 months and PT within 12 months, MFA flow diagram, reconciliation architecture (within 24 hours), threat model, mobile app jailbreak/root detection attestation, source-code certificate for any third-party-licensed component.
- Wire the 6-hour CERT-In rule into your runbook with a 2-hour internal SLA to your bank partner — your bank cannot discharge its 6-hour obligation if you take 5 hours to notify it; your contractual SLA must be 2 hours or tighter.
- Build a mobile app security posture that covers device binding, jailbreak/root detection, code obfuscation (in release builds, not just debug), SSL pinning, SQL injection defences, no plain-text sensitive data, and older-version deactivation within 6 months.
- Budget ₹12–25 lakh/year for continuous PCI compliance, quarterly VAPT (half-yearly statutory plus additional cycles on material changes), fraud-risk engine licensing and a CERT-In-empanelled incident-response retainer. The downstream cost of a single missed Paragraph 41 reconciliation or Paragraph 33 MFA bypass is materially higher.
FAQ
Does this Master Direction apply to neobanks?
A neobank is typically a technology front-end on a licensed bank partner. The Master Direction, by its text at Clause 2, applies to the licensed Regulated Entity (the SCB / SFB / Payments Bank / credit-card-issuing NBFC). The neobank's exposure is contractual — the sponsor bank will flow down every control in Chapters II–V through its IT Outsourcing Policy under Chapter V of the RBI IT Governance MD 2023. In practice the neobank must be able to produce the same evidence pack (SDLC, MFA, fraud-risk monitoring, reconciliation within 24 hours, customer protection flows) that the sponsor bank relies on for its own RBI filings.
PCI-DSS vs the RBI Master Direction — which governs?
Both. PCI-DSS is a card-industry scheme standard; the Master Direction is a statutory Direction under the Payment and Settlement Systems Act, 2007, the Banking Regulation Act, 1949 and the Reserve Bank of India Act, 1934. Chapter V (Card Payments Security) of the Master Direction explicitly requires REs to follow PCI-DSS, PA-DSS (or its successor PCI Secure Software Standard), PCI-PIN, PCI-PTS, PCI-HSM and PCI-P2PE "as per applicability/readiness of updated versions" (Paragraph 67). The Master Direction is the floor and PCI scheme rules are an additional industry baseline — both apply simultaneously.
How does this interact with the NPCI UPI Operating Circulars?
The Master Direction sets the Regulated Entity-level governance and controls baseline. NPCI Operating Circulars — such as UPI OC-184 and the OC-184-B addendum effective 15 February 2025 on chargeback modifications, and IMPS OC-124 on fraud chargeback implementation for FY 2025-26 — provide the scheme-level procedural rules for specific products. Where both apply (e.g., fraud risk management and chargeback), the RE must comply with the stricter requirement. Reconciliation under Paragraph 41 of the Master Direction (near-real-time or within 24 hours of receipt of settlement file) must be aligned with NPCI settlement-file SLAs.
What is the 10-day rule for unauthorised electronic transactions?
The Master Direction at Paragraphs 42–50 (Customer Protection, Awareness and Grievance Redressal) requires REs to implement the RBI customer-protection framework for unauthorised electronic banking transactions. The separate RBI circular dated 6 July 2017 ("Customer Protection — Limiting Liability of Customers in Unauthorised Electronic Banking Transactions", DBR.No.Leg.BC.78/09.07.005/2017-18) establishes zero liability where the unauthorised transaction is due to RE fault or third-party breach with customer notification within three working days, and limited liability (up to ₹25,000 depending on account type) where the customer notifies within four to seven working days. Where the customer notifies within three working days, the RE must shadow-reverse the entry within 10 working days. The Master Direction anchors this framework into digital-payment-channel controls.
How does this map to the CERT-In 6-hour reporting rule?
CERT-In reporting under Direction (ii) of the CERT-In Directions dated 28 April 2022 issued under Section 70B(6) of the Information Technology Act, 2000 applies to every body corporate including REs: any of the twenty Annexure I cyber incident categories (including payment-system attacks at category xiv) must be reported to CERT-In within 6 hours of noticing, separate from the reporting to RBI. Paragraph 40 of the Master Direction requires REs to maintain updated contact details of stakeholders for coordination in incident response and to formulate specific SOPs for payment-ecosystem incidents. The runbook must fire CERT-In, RBI (DoS/DPSS/CSITE), the customer, and — where personal data is exposed — the Data Protection Board under Section 8(6) of the Digital Personal Data Protection Act, 2023 in parallel.
Sources
Reserve Bank of India (Digital Payment Security Controls) Directions, 2021 — notification RBI/2020-21/74 DoS.CO.CSITE.SEC.No.1852/31.01.015/2020-21 dated 18 February 2021. RBI landing: https://rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=12032
RBI Master Directions on Cyber Resilience and Digital Payment Security Controls for non-bank Payment System Operators — 2024 extension. Index: https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx
RBI Master Direction on IT Governance, Risk, Controls and Assurance Practices — 7 November 2023, effective 1 April 2024. Available at https://www.rbi.org.in/scripts/BS_ViewMasDirections.aspx?id=12562
RBI Customer Protection — Limiting Liability of Customers in Unauthorised Electronic Banking Transactions — DBR.No.Leg.BC.78/09.07.005/2017-18, 6 July 2017. Available at https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11040
RBI Online Dispute Resolution System for Digital Payments — RBI/2020-21/21 DPSS.CO.PD No.116/02.12.004/2020-21, 6 August 2020. Available at https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11946
CERT-In Directions under Section 70B(6) of the IT Act, 2000 — dated 28 April 2022 (No. 20(3)/2022-CERT-In). Available at https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf
NPCI UPI Chargeback Circular OC-184-B — effective 15 February 2025. Available at https://www.npci.org.in/PDF/npci/upi/circular/2025/UPI-OC-No-184-B-FY-2025-26-Addendum-to-OC-184-Modification-in-UPI-chargeback-rules-and-procedures.pdf
Payment and Settlement Systems Act, 2007 — Sections 30 and 31 (penalties and compounding). Available at https://www.indiacode.nic.in/
Banking Regulation Act, 1949 — Sections 46 and 47A. Reserve Bank of India Act, 1934 — Section 58G. Available at https://www.indiacode.nic.in/
Information Technology Act, 2000 — Sections 43A, 70B and 81. Available at https://www.indiacode.nic.in/handle/123456789/1999
Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023), Sections 8, 10 and 33; DPDP Rules 2025 (G.S.R. 846(E), 13 November 2025).
This playbook is prepared by Veritect Legal Intelligence for general informational purposes and does not constitute legal advice. Regulated Entities should consult qualified counsel for institution-specific advice. Statutory citations are current as of 21 April 2026.