A bank or fintech shipping a mobile app in India has two documents to satisfy at once. OWASP's Mobile Application Security Verification Standard (MASVS) v2 sets out, in eight control groups, what a secure mobile app looks like anywhere in the world. RBI's Master Direction on Digital Payment Security Controls, 2021 sets out, in a dedicated chapter of binding clauses, what a mobile banking or payment app must do for a Scheduled Commercial Bank, Small Finance Bank, Payments Bank or credit card issuing NBFC operating in India. Most testing teams read these separately. This checklist reads them together.
The two documents were not written to reference each other. What they share is subject matter: both address how an app stores data, authenticates a user, talks to a network, resists tampering and handles personal information. Grouping RBI's mobile-app clauses under the MASVS control group they match gives a security or compliance team one list to test against, and one list to hand an auditor.
What follows works through OWASP MASVS v2's eight control groups, what RBI's Chapter IV, "Mobile Payments Application Security Controls," requires clause by clause, and where automated testing and runtime protection tools fit against each one.
What OWASP MASVS v2 covers
MASVS is organised into eight control groups, each with two to four testable control statements. OWASP's companion guide, the Mobile Application Security Testing Guide (MASTG), is "a comprehensive manual for mobile app security testing and reverse engineering" that "describes technical processes for verifying the controls listed in the OWASP MASVS." The eight groups are:
- MASVS-STORAGE (Storage): apps handling "personally identifiable information (PII), cryptographic material, secrets, and API keys, that often need to be stored locally": securely storing sensitive data, and preventing its leakage.
- MASVS-CRYPTO (Cryptography): whether an app uses "current strong cryptography ... according to industry best practices" and manages keys the same way.
- MASVS-AUTH (Authentication and Authorization): secure authentication protocols, secure local authentication (biometrics, PIN), and additional authentication for sensitive operations.
- MASVS-NETWORK (Network Communication): securing network traffic and identity pinning (certificate or public-key pinning) for endpoints under the developer's control.
- MASVS-PLATFORM (Platform Interaction): secure use of inter-process communication (IPC), WebViews, and the user interface.
- MASVS-CODE (Code Quality): an up-to-date platform version, enforced app updates, components without known vulnerabilities, and validated and sanitised untrusted inputs.
- MASVS-RESILIENCE (Resilience Against Reverse Engineering and Tampering): platform-integrity validation, anti-tampering, anti-static-analysis and anti-dynamic-analysis, through "defense-in-depth measures such as code obfuscation, anti-debugging, anti-tampering, and runtime application self-protection (RASP)." OWASP notes "the absence of these measures does not in itself constitute a vulnerability;" they layer on the other seven groups.
- MASVS-PRIVACY (Privacy): minimising access to sensitive data, preventing user identification, transparency about data collection, and giving users control over their data.
What RBI's Master Direction actually requires for mobile apps
RBI's Master Direction on Digital Payment Security Controls is dated 18 February 2021 and applies, in its own words, to "Scheduled Commercial Banks (excluding Regional Rural Banks); Small Finance Banks; Payments Banks; and Credit card issuing NBFCs." It comes into effect "six months from the day they are placed on the official website of the Reserve Bank of India."
Chapter IV, headed "Mobile Payments Application Security Controls," runs from clause 55 to clause 66. Clause 56 alone lists nine controls: device policy enforcement, secure download and installation, phased deactivation of older app versions within six months of a new release, storage of customer data, device or application encryption, minimal data collection and app permissions, sandboxing or containerisation, identifying remote access applications and blocking login where one is detected, and code obfuscation. Later clauses add device binding (clause 60), alternatives to SMS-based OTP where the second factor and the app share a device (clause 61), re-authentication after inactivity and on every launch (clause 62), a ban on storing sensitive authentication data on the device with secure memory wiping on exit (clause 63), limits on writing sensitive data to temporary files (clause 64), and rules for SSL/TLS certificate errors in WebView content (clause 66).
A few clauses are recommendations, not mandates: entities "may consider" validating device and OS compatibility (clause 57), "may explore the feasibility of" root or jailbreak detection before installation (clause 58), and "may consider designing anti-malware capabilities" (clause 65). A checklist should record which controls RBI requires and which it recommends.
Chapter IV builds on an earlier requirement. RBI's 2016 Cyber Security Framework in Banks circular, dated 2 June 2016, already required risk assessments to "reckon the technologies adopted, alignment with business and regulatory requirements, connections established, delivery channels, online / mobile products, technology services, organisational culture and internal & external threats," putting mobile channels in scope five years before the 2021 Master Direction's app-level controls.
Get a 14-day free trial with expert onboarding from SecOpsTool, or compare it with the alternatives first.
Mapping MASVS control groups to RBI's mobile app clauses
Because both documents cover the same underlying risks, most of RBI's Chapter IV clauses sit naturally under one of the eight MASVS control groups. This is the mapping this checklist uses:
| MASVS control group | RBI Master Direction clause(s) | What to test |
|---|---|---|
| MASVS-STORAGE | Clause 56 (storage of customer data), clause 63 (no sensitive authentication data on device), clause 64 (limit data in temp files) | Where customer and authentication data is written, on disk and in temp files, and whether it is wiped on exit |
| MASVS-CRYPTO | Clause 56 (device or application encryption) | Whether data at rest and any local keys use current, correctly implemented cryptography |
| MASVS-AUTH | Clause 60 (device binding), clause 61 (alternatives to SMS OTP), clause 62 (re-authentication on inactivity and launch) | Local authentication, device binding, and re-authentication on sensitive actions |
| MASVS-NETWORK | Clause 66 (SSL/TLS certificate error handling, blocking WebView content on validation failure) | Certificate and identity pinning, and the app's reaction to a failed or expired certificate |
| MASVS-PLATFORM | Clause 56 (identifying remote access applications and blocking login) | IPC exposure, WebView configuration, and remote-access detection |
| MASVS-CODE | Clause 55 and 56 (version verification, phased deactivation of old versions), clause 57 (device/OS validation), clause 59 (published checksum) | Version enforcement, update mechanisms, and whether the binary matches its published checksum |
| MASVS-RESILIENCE | Clause 56 (code obfuscation), clause 58 (root/jailbreak detection, recommended), clause 65 (anti-malware, recommended) | Obfuscation strength, tamper detection, and resistance to static and dynamic analysis |
| MASVS-PRIVACY | Clause 56 (minimal data collection and app permissions) | Requested permissions against actual use, and disclosure of collection |
RBI does not use MASVS terminology; this mapping is this article's own grouping of RBI's clauses under the nearest MASVS control group. Protectt.ai states a version of the same link on its own site: "OWASP MASVS controls align closely with RBI's Digital Payment Security Controls, NPCI guidelines, and PCI DSS mobile security requirements."
Storage, cryptography and authentication: where findings cluster
MASVS-STORAGE's two controls, securely storing sensitive data and preventing its leakage, map onto RBI clause 63's ban on retaining "sensitive personal/ consumer authentication information such as user IDs, passwords, keys, hashes, hard coded references" on the device, and clause 64's limit on sensitive data in temporary files. Check both declared storage locations and any incidental copies left in caches, logs or temp files.
MASVS-CRYPTO asks whether an app "employs current strong cryptography" and manages keys "according to industry best practices." RBI's wording for the same concern is one line under clause 56: "device or application encryption." Testing against MASVS-CRYPTO turns that one-line clause into evidence: which algorithm, what key length, where the key is generated and stored, and whether it sits in the platform keystore rather than hardcoded alongside the data it protects.
MASVS-AUTH's three controls, secure protocols, secure local authentication, and additional authentication for sensitive operations, line up with three RBI clauses: device binding (clause 60), alternatives to SMS-based OTP when the authentication factor and the app share a device (clause 61), and re-authentication "whenever the device or application remains unused for a designated period and each time the user launches the application" (clause 62). A test plan should confirm each independently, since an app can pass one and fail another.
Resilience: obfuscation, root detection and RASP
MASVS-RESILIENCE is the group RBI addresses in the most detail without naming it. Clause 56 lists code obfuscation as a control; clause 58 recommends checking for root or jailbreak before installation; clause 65 recommends anti-malware capabilities. All three sit inside what OWASP frames as defence in depth: obfuscation, anti-debugging, anti-tampering and runtime application self-protection (RASP), additional layers rather than a substitute for the other seven MASVS control groups.
The supplied resilience tools differ in approach. Guardsquare's DexGuard (Android) and iXGuard (iOS) apply obfuscation at compile time: protections are "injected and applied during code compilation" using "data encryption, control flow obfuscation, code virtualization and name obfuscation," so "no two protected builds ever look the same." The same products add runtime defences against "function hooks, dynamic instrumentation, and other code changes," detecting "tampered system libraries, emulators, virtual environments, and root privileges." Guardsquare's AppSweep tests for these issues before release, running "multi-analysis mobile app security testing (static and interactive)" prioritised against OWASP MASVS.
Bugsmirror and Protectt.ai take a runtime-first approach through RASP SDKs embedded in the app. Bugsmirror describes its platform as "using Runtime Application Self-Protection (RASP) to monitor and defend an app from within during actual execution on user devices," and its RunLock page states the tool "is aligned with the latest security standards, including the OWASP MASVS ... SEBI CSCRF ... RBI MDDPSC (Master Direction on Digital Payment Security Controls), and NPCI guidelines." Protectt.ai describes AppProtectt as "Runtime Application Self Protection (RASP)" alongside CodeProtectt for "code obfuscation and polymorphic protection against reverse engineering," stating on its own OWASP-checklist page that "OWASP MASVS controls align closely with RBI's Digital Payment Security Controls, NPCI guidelines, and PCI DSS mobile security requirements."
Network, platform and privacy controls
MASVS-NETWORK's two controls, securing network traffic and identity pinning, correspond to RBI clause 66: web content inside the app "should not be loaded if errors are detected during SSL/ TLS negotiation," and certificate problems, an unrecognised certificate authority or an expired or revoked certificate, "must be displayed to the user." Confirm the app blocks content on a pinning failure rather than only logging it.
MASVS-PLATFORM's controls on IPC, WebViews and UI security map to RBI's requirement in clause 56 to identify remote-access applications and "prohibit login access to the mobile application, as a matter of precaution" when one is detected, since a remote access tool on the device undermines every other control on this list.
MASVS-PRIVACY's four controls, minimising access to data, preventing user identification, transparency, and user control, correspond to clause 56's requirement for "minimal data collection/ app permissions." OWASP notes MASVS-PRIVACY is "not intended to serve as an exhaustive or exclusive reference" for data protection law; the same caution applies to using it as evidence for an RBI compliance file, which still needs the bank's own data-protection review.
Testing across the release pipeline
These controls need testing at different points. Appknox, an enterprise mobile application security testing platform, tests "compiled APK and IPA binaries rather than source code," combining static analysis, dynamic testing on real devices and API testing. Its compliance page states it helps teams "meet the Mobile Application Security Verification Standard v2 requirements," address "critical risks from the OWASP Mobile Top 10 2024," and "meet PCI-DSS v4.0 standards" and HIPAA requirements; RBI is not named on Appknox's compliance page, so any RBI clause mapping for an Appknox scan has to be built by the bank's own team, using a checklist such as this one.
Guardsquare's AppSweep runs earlier, as pre-release static and interactive testing with findings already grouped by OWASP MASVS category. Running a binary-level scanner such as Appknox against a release candidate, and a resilience product such as Guardsquare, Bugsmirror or Protectt.ai for the MASVS-RESILIENCE controls, covers the pipeline end to end: testing before release, runtime protection after it ships.
What to do next
Start by mapping your app's existing test coverage against the eight MASVS control groups in the table above, and note which RBI clauses each group gives you evidence for. A gap, whether unencrypted local storage under MASVS-STORAGE, missing re-authentication under MASVS-AUTH, or no obfuscation and root detection under MASVS-RESILIENCE, is also a clause in RBI's Chapter IV worth flagging to your compliance team before an audit does.
SecOpsTool supplies Appknox for binary SAST, DAST and API testing, Guardsquare's DexGuard, iXGuard and AppSweep for code hardening and pre-release testing, and Bugsmirror and Protectt.ai for runtime application self-protection. Request a scoping call and bring your existing test coverage; we can help you work out what to evaluate first.
Questions Buyers Ask
No, not officially. MASVS is a global testing standard and RBI's Master Direction on Digital Payment Security Controls is a binding rule for Indian regulated entities; neither document references the other. Because they cover the same risks, most RBI mobile-app clauses fit naturally under a MASVS control group, and Protectt.ai states on its own site that "OWASP MASVS controls align closely with RBI's Digital Payment Security Controls," but the mapping is a testing convenience, not an official equivalence.
Chapter IV of the Master Direction on Digital Payment Security Controls, 2021 (RBI/2020-21/74, dated 18 February 2021), headed "Mobile Payments Application Security Controls," runs from clause 55 to clause 66. It applies to Scheduled Commercial Banks (excluding Regional Rural Banks), Small Finance Banks, Payments Banks and credit card issuing NBFCs, and came into effect six months after publication on RBI's website.
RBI's clause 56 lists code obfuscation as a control, while root/jailbreak detection (clause 58) and anti-malware capability (clause 65) are stated as things a regulated entity "may consider" rather than a mandatory requirement. OWASP's MASVS-RESILIENCE group treats obfuscation, anti-tampering and runtime self-protection (RASP) as separate controls that work together; Guardsquare, Bugsmirror and Protectt.ai each publish products that combine compile-time obfuscation with a runtime RASP layer rather than relying on obfuscation alone.
Sources
Primary documents this article is based on. Regulatory clauses and product statements above are taken from these pages.
- OWASP MASVS - Storage
- OWASP MASVS - Cryptography
- OWASP MASVS - Authentication and Authorization
- OWASP MASVS - Network Communication
- OWASP MASVS - Resilience
- OWASP MASTG
- RBI Master Direction on Digital Payment Security Controls, 2021
- RBI Cyber Security Framework in Banks, 2016
- Appknox - compliance
- Guardsquare - AppSweep
- Bugsmirror - RunLock
- Protectt.ai - OWASP checklist