Introduction
The RBI Master Direction on Digital Payment Security Controls (DPSC), issued on February 18, 2021, sets binding security requirements for mobile banking apps operated by regulated entities in India. The Direction covers everything from device binding and session management to code obfuscation and fraud risk monitoring—leaving no room for interpretation on what constitutes "secure enough."
While the DPSC covers internet banking, card payments, and mobile banking, Chapter IV places specific, mandatory controls on mobile payment applications. These controls are widely referenced in compliance checklists, yet poorly understood at an implementation level.
Many regulated entities treat DPSC as a checklist exercise rather than a security framework — a distinction that creates gaps both auditors and fraudsters can exploit.
If your organization falls into that second category, this article is the course correction. It breaks down exactly what mobile banking apps must do to comply with RBI DPSC, which controls are mandatory versus advisory, and where compliance teams commonly fall short.
TL;DR
- Applies to Scheduled Commercial Banks, Small Finance Banks, Payments Banks, and credit card-issuing NBFCs with mobile banking apps
- Chapter IV targets the app layer: device binding, code obfuscation, session re-authentication, and remote access blocking
- Chapter II controls—MFA, app security lifecycle, fraud monitoring—apply directly to mobile banking
- Non-compliance exposes institutions to regulatory penalties, security breaches, and reputational damage
- Full compliance needs both technical controls built into the app and Board-approved governance policies
What Is RBI DPSC?
RBI DPSC refers to the Reserve Bank of India (Digital Payment Security Controls) Directions, 2021—a Master Direction that mandates a governance structure and minimum security standards for digital payment products offered by regulated entities in India.
The Direction covers five chapters:
- Chapter I: Preliminary definitions and applicability scope
- Chapter II: General controls including governance, application security lifecycle (ASLC), authentication frameworks, and fraud risk management
- Chapter III: Internet banking security requirements
- Chapter IV: Mobile payment application security controls
- Chapter V: Card payment security standards
In July 2024, the RBI extended a parallel Master Direction on Cyber Resilience and Digital Payment Security Controls specifically for non-bank Payment System Operators (PSOs). This reflects the broader reach of the DPSC framework, with tiered compliance timelines:
- Large Non-Bank PSOs: April 1, 2025
- Medium Non-Bank PSOs: April 1, 2026
- Small Non-Bank PSOs: April 1, 2028
The PSO extension covers entities like NPCI, card networks, payment aggregators, and PPI issuers, tightening security requirements across the entire digital payments ecosystem.
Who Must Comply — and Why Mobile Banking Apps Are Central
Regulated entities (REs) covered under the 2021 DPSC include:
- Scheduled Commercial Banks (excluding Regional Rural Banks)
- Small Finance Banks
- Payments Banks
- Credit card-issuing NBFCs
Any RE offering or intending to offer mobile banking or mobile payments to customers is subject to Chapter IV controls. That scope matters — because mobile banking introduces a distinct threat profile that general IT security controls weren't designed to address.
Why Mobile Apps Face Unique Risks
Mobile banking apps operate in a high-risk environment. Unlike internet banking, where the authentication factor (OTP) and the access channel (browser) typically exist on separate devices, mobile banking collapses both onto a single device. This creates attack vectors including:
- SIM swap attacks that redirect OTPs to attacker-controlled numbers
- Device compromise through malware, root/jailbreak exploits, or remote access tools
- Co-residency risk where both the OTP and the banking app reside on the same compromised device
Between October 2023 and March 2024, domestic payment frauds surged 70% to ₹2,604 crore, with UPI frauds alone reaching ₹1,087 crore in FY 2023-24—an 85% increase year-over-year. These numbers reflect a threat environment that general Chapter II controls were not built to contain — which is why Chapter IV mandates mobile-specific requirements that go further.
Chapter IV Decoded — Mobile Payment App Security Requirements
Chapter IV lays out technical and operational controls that regulated entities must implement for mobile payment applications. These are not recommendations—they are mandatory "shall" requirements.
Application integrity and version control:
REs must verify the version of the mobile application before enabling transactions. Older versions must be deactivated in a phased, time-bound manner not exceeding six months from the release of a newer version. This prevents users from running outdated apps with known vulnerabilities.
REs must also actively monitor app stores and the web for non-genuine or unauthorized mobile applications with similar names or features. Given campaigns like the 'Drinik' Android malware—which masqueraded as an Income Tax refund app to steal banking credentials—this monitoring requirement carries real weight.
Device Binding, Session Management, and Remote Access Controls
Device binding requirements:
REs must ensure device binding of the mobile application, preferably implemented through a combination of hardware, software, and service information. Basic SMS-based binding is insufficient. Cybersecurity reports highlight toolkits like "Digital Lutera" that bypass SIM-binding by altering system-level SMS operations without modifying the banking app itself.
Multi-layered device binding should incorporate:
- Hardware identifiers (device fingerprints)
- Software characteristics (OS version, security patch level)
- Service-level validation (SIM verification through carrier networks)
Users must be notified on every new device registration across multiple channels—registered mobile number, email, or phone call.
Session management controls:
The mobile application must:
- Require re-authentication whenever the device or application remains unused for a designated period
- Automatically terminate inactive sessions
- Identify new network connections or connections from unsecured networks (such as open Wi-Fi) and implement appropriate checks before allowing transactions
Remote access blocking (mandatory):
The app must identify and block remote access applications during live sessions. This is a "shall" requirement, meaning it's mandatory—not advisory. The platform must detect, to the extent technically possible, if a remote access tool is active and prohibit login access as a precautionary measure.
CERT-In explicitly warns users: "Never install remote access software on your device: This software gives individuals complete control over your device, creating a significant security risk." Fraudsters routinely exploit screen-sharing apps to steal credentials and OTPs in real time—making this detection requirement one of the most operationally critical in Chapter IV.
Data Storage, Sensitive Information Handling, and Secure Coding
Sensitive data storage prohibitions:
Mobile applications must not store or retain sensitive consumer authentication information—user IDs, passwords, keys, hashes, or hard-coded references—on the device. The app must securely wipe any sensitive customer information from memory when the user exits the application.
Any sensitive information written to temporary files must be suitably encrypted, masked, or hashed. This aligns directly with OWASP Mobile Top 10 vulnerabilities M1 (Improper Credential Usage) and M9 (Insecure Data Storage).
Secure coding requirements:
REs must ensure that:
- Raw SQL queries are not used to fetch or update database data (preventing SQL injection vulnerabilities)
- Sensitive information is written to the database in encrypted form
- Web content loaded within the app is not rendered if SSL/TLS errors are detected
- Code obfuscation is applied to prevent reverse engineering of application logic
Mandatory versus advisory controls:
Some controls use "may" language—anti-malware capabilities and root/jailbreak detection, for example—making them technically advisory. Regulators and auditors now treat these as baseline expectations regardless of the "may" framing. Implementing them as mandatory reduces audit exposure and closes real attack surfaces.
General Controls That Also Govern Mobile Banking Apps
Chapter II establishes general security controls that apply across all digital payment channels, including mobile banking apps.
Authentication framework (Chapter II, paras 33-35):
Mobile apps must implement multi-factor authentication (MFA) for all payment transactions, fund transfers, and account changes. At least one authentication factor must be dynamic or non-replicable—such as OTP, device binding combined with SIM verification, biometric authentication, or PKI-based tokens.
REs must set a maximum number of failed login or authentication attempts before blocking access, with a secure re-activation process.
The DPSC explicitly flags the risk of OTP and mobile app coexisting on the same device: "Considering that the additional factor of authentication and mobile application may reside on the same mobile device... REs may consider implementing alternatives to SMS-based OTP authentication mechanisms."
Alternative authentication mechanisms include:
- Hardware-backed device binding
- Behavioral biometrics
- Risk-based adaptive authentication
- Carrier-based silent verification
Application Security Life Cycle (ASLC) requirements (paras 19-31):
A "secure by design" approach must be embedded from requirements gathering through decommissioning. For mobile apps, this means:
- Vulnerability Assessment (VA) at least every six months
- Penetration Testing (PT) at least annually
- OWASP Mobile Top 10 and OWASP-MASVS must be explicitly tested
- Source code review or third-party certification must be obtained
If the RE does not own the source code, it must obtain a certificate from the developer attesting the app is free of known vulnerabilities and covert channels. The 2024 PSO directions tighten this further for critical processes, requiring "certified assurance from an independent auditor on the vendor's cyber resilience capabilities."
Security testing covers the app itself — but compliance also extends to how the app monitors activity after deployment.
Fraud risk management requirements:
Mobile apps must have parameterized alert systems to detect suspicious transaction behavior using parameters such as:
- Transaction velocity (frequency and amount)
- Geo-locations and IP origin
- Blacklisted mobile numbers or VPAs
- High-risk merchant category codes (MCC)
- Behavioral biometrics
- Transaction origination from point of compromise
Beyond alerts, REs must maintain a real-time or near-real-time reconciliation framework — settling within 24 hours of receiving settlement files — covering all stakeholders: payment aggregators, business correspondents, and card networks.
Customer protection requirements (paras 42-50):
REs must make it mandatory for users to go through secure usage guidelines during onboarding and after each app update. The app must include a clearly accessible grievance reporting mechanism. Customers must only be onboarded to digital channels with explicit, written or authenticated electronic consent—no bundling of digital payment products without the customer's knowledge is permitted.
Common Compliance Gaps in Mobile Banking Apps
Despite clear regulatory mandates, several compliance gaps persist across Indian financial institutions.
Gap 1: Over-reliance on SMS OTP as sole MFA
Many teams treat multi-factor authentication as fully satisfied by SMS OTP alone, without recognising that the DPSC explicitly flags risk when both the OTP and the mobile app reside on the same device. RBI specifically recommends exploring alternatives to reduce single-device attack risk:
- Device binding-based authentication
- Biometric verification
- Hardware tokens
SIM swap frauds have become a documented attack vector, making SMS OTP alone insufficient. REs should implement risk-based authentication that escalates to stronger factors — biometric or device binding verification — when suspicious activity is detected.
Gap 2: Version management and app store monitoring failures
Many REs launch new app versions but fail to enforce deactivation of older versions within the six-month window, leaving users running vulnerable versions indefinitely.
Most REs also have no active mechanism to detect unauthorised lookalike apps on public app stores. CERT-In advisories frequently warn about fake applications that use legitimate company names to trick users into downloading malware. Without automated anti-rogue app monitoring, REs cannot protect customers from phishing campaigns using brand impersonation.
Gap 3: Insecure data handling and weak code protection
Development teams continue to store session tokens, keys, or credentials in insecure local storage, shared preferences, or temp files without encryption. Code obfuscation is either absent or only partially implemented, leaving core transaction logic exposed to reverse engineering and API manipulation.
CERT-In guidelines are unambiguous: "No secret keys used by the application should be stored unencrypted in the application storage" and "User data should not be stored in unencrypted/plain-text form on the device." Yet these remain among the most common findings in mobile app security audits.
Practical Steps to Build an RBI DPSC-Compliant Mobile App
Step 1: Conduct a gap assessment
The first step for any RE is to conduct a gap assessment mapping existing mobile app controls against the specific mandatory requirements of Chapter IV and the relevant sections of Chapter II. Identify:
- Which controls are absent
- Which are partially implemented
- Which require governance documentation (Board-approved policy, ASLC documentation, VA/PT reports) to satisfy the regulatory audit trail
Step 2: Implement technical controls
The technical implementation layer must address:
Code-level controls:
- Code obfuscation to prevent reverse engineering
- Anti-tampering validation
- SQL injection prevention (no raw SQL queries)
- SSL/TLS enforcement for all web content
Runtime controls:
- Root/jailbreak detection
- Remote access app detection and blocking
- Session timeout and automatic termination
- Detection of unsecured network connections
Data controls:
- Encrypted local storage for sensitive data
- Memory clearing on app exit
- Masking of sensitive fields in logs and temp files
Building each of these controls in-house is time-intensive. Protectt.ai's SDK-based platform embeds RASP, device binding, code obfuscation, and runtime threat detection directly into the app — cutting implementation time significantly and letting development teams focus on product rather than rebuilding security primitives.
Step 3: Build compliance into the development lifecycle
Compliance is not a one-time event. DPSC requires:
- Ongoing VA scanning (at least every six months)
- Annual penetration testing
- Periodic review of authentication parameters
- Continuous monitoring for fraudulent app clones
Regulated entities need to treat compliance as an ongoing engineering discipline, not a pre-launch checkbox. In practice, this means:
- Integrating security testing directly into CI/CD pipelines
- Enforcing version control workflows that flag security regressions
- Running automated app store monitoring to detect unauthorized clones
Frequently Asked Questions
What is RBI DPSC?
RBI DPSC stands for the Reserve Bank of India (Digital Payment Security Controls) Directions, 2021: a Master Direction mandating security governance, authentication controls, fraud risk management, and application-level security standards for regulated entities offering digital payment products including mobile banking.
What are the new RBI guidelines for digital payments?
In July 2024, RBI issued updated Master Directions on Cyber Resilience and Digital Payment Security Controls specifically for non-bank Payment System Operators (PSOs), extending DPSC-like requirements to entities such as payment aggregators, PPI issuers, card networks, and ATM operators, with tiered compliance timelines through 2028.
What are the five parameters of DPI?
India's Digital Public Infrastructure (DPI) is built on five pillars: identity, payments, data, consent, and open networks. Within the DPSC framework, mobile payment security is governed by authentication strength, application integrity, data protection, fraud monitoring, and device security — these are not formally labeled "five DPI parameters" but map closely to DPI's payment and identity pillars.
What is the 60/40 rule of RBI?
The RBI 60/40 rule requires card payment networks to process at least 60% of domestic transactions through Indian infrastructure. It is separate from DPSC, but all card and mobile payment data flowing through those systems must still meet DPSC security controls.
Which mobile app controls are mandatory versus recommended under RBI DPSC?
Controls using "shall" language are mandatory: device binding, multi-factor authentication, ASLC security testing, code obfuscation, session re-authentication, and version deactivation timelines. Controls using "may," such as root/jailbreak detection and adaptive authentication, are advisory but auditors increasingly treat them as baseline expectations.
Does RBI DPSC apply to third-party mobile payment apps like UPI apps?
The 2021 Master Direction directly covers regulated entities: banks and credit card-issuing NBFCs. Third-party UPI and payment apps are indirectly impacted because banks must ensure their technology service providers and co-branded app developers also meet applicable DPSC security standards.
