India runs the world’s largest real-time payments rail. The Unified Payments Interface (UPI) now processes well over 18 billion transactions a month, and that scale has made it the single most attractive target for fraud and application-layer attacks in the country. Regulators have responded. With the NPCI UPI Information Security Compliance Framework 2025 and circular OC-215/2025-26, vulnerability assessment and penetration testing (VAPT) is no longer a best-practice nicety for banks, PSPs, TPAPs and fintechs it is a hard, audited, pre-onboarding gate with an annual deadline.
This guide breaks down exactly what the new mandates require, the layers your UPI penetration testing scope must cover, and the specific security test cases that separate a checkbox audit from one that actually stops fraud. If you operate anywhere in the UPI value chain, this is the playbook your December compliance report depends on.
Why VAPT is now a mandatory part of UPI compliance?
The NPCI UPI Information Security Compliance Framework 2025 standardises security expectations across every participant in the ecosystem. Its audit obligations are unambiguous:
- A comprehensive security audit is mandatory — as a pre-onboarding activity and annually thereafter.
- The audit must be conducted by a CERT-In empanelled auditor, and the entity bears the cost.
- Findings must be fully closed. A final compliance report with *no open findings* must be submitted to NPCI before an entity can be onboarded.
- Once onboarded, an annual compliance report with no open findings is due on or before 31 December every year.
- Scope is total — the audit must cover the entire UPI infrastructure and the UPI application, including both frontend and backend.
The framework applies to the full cast of the UPI ecosystem: Remitter/Issuer Banks, PPI and PSP Banks, Beneficiary/Acquiring Banks, Third Party Application Providers (TPAPs), Technology Service Providers (TSPs), Voice-Based Service Providers (VSPs), IVR providers and Application Service Providers (ASPs). If you touch a UPI transaction, you are in scope.
How is the UPI security framework structured?
The UPI InfoSec Compliance Framework 2025 organises its controls into three pillars. A credible VAPT engagement maps directly onto all three rather than testing the application in isolation.

- Governance Controls — covers policy, compliance, roles, audit, legal and risk; Board oversight; and CISO accountability and independence (referencing CERT-In, NCIIPC and NPCI guidelines). VAPT plugs in through evidence review, policy/exception validation, and segregation-of-duties and access governance testing.
- Security Measures / Controls — covers data security, identity & access management, network security, the application security lifecycle, incident response, fraud risk, data privacy, infrastructure security and APIs. This is where the core technical VAPT sits — app, API, network, device-binding, encryption and fraud-control testing.
- Operational Review — covers infrastructure resiliency, VAPT testing & re-assessment, source code review, application security assessment, logging & monitoring, BCP/DR, and architecture review against ISO 27001 / PCI DSS. VAPT plugs in through testing, secure code review, configuration/architecture review, and re-test-to-closure.
3. What UPI / banking transaction VAPT must actually cover?
Because the framework demands frontend-to-backend coverage, a compliant engagement is multi-layered. A single mobile-app scan leaves the majority of the real risk untested. The scope below reflects what NPCI, RBI and PCI DSS expectations converge on for banking and fintech penetration testing.
- Mobile application (Android & iOS): binary/APK-IPA analysis, runtime instrumentation, local storage, SDK handling and device binding — tested against OWASP MASVS L2, MASTG and the Mobile Top 10.
- APIs (UPI & supporting): authentication, authorization (BOLA/IDOR), rate limiting/TPS, business logic and OC-215 quota controls — tested against the OWASP API Top 10 and NPCI OC-215.
- Web / browser-based UPI: session management, XSS/CSRF and browser-specific transaction vectors — tested against the OWASP Top 10.
- Network, server & infrastructure: segmentation, TLS/routing, hardening & patching, and external/internal exposure — aligned to CERT-In, PCI DSS and ISO 27001.
- Cloud & backend: configuration review, key management/HSM, identity, and logging & monitoring aligned to CIS Benchmarks and PCI DSS.
4. What your UPI VAPT should actually test?
This is where audits are won or lost. The test cases below are grouped by control area and aligned to the framework’s Security Measures and Operational Review pillars. They combine NPCI-specific requirements with OWASP MASVS/MASTG and API Top 10 coverage plus the business-logic and fraud-bypass cases that automated scanners consistently miss.
4.1 Mobile application security (OWASP MASVS Level 2)
Banking and UPI apps process sensitive financial data and therefore demand MASVS Level 2 — the highest tier adding reverse-engineering resilience and tamper detection on top of the Level 1 baseline. Highest-yield test cases:
- Insecure data storage (MASVS-STORAGE): PIN, tokens, PAN or session data leaking to SharedPreferences, SQLite, logs, keyboard cache, screenshot/recents cache, analytics or crash reports.
- Weak or missing certificate pinning (MASVS-NETWORK): MITM interception of UPI traffic via a proxy and user-installed CA.
- Missing root / jailbreak detection and anti-tampering (MASVS-RESILIENCE): running the app on a rooted device, Frida/Objection runtime hooking, and repackaging.
- Hardcoded secrets (MASVS-CODE): API keys, encryption keys or endpoints embedded in the binary.
- Insecure deeplink / intent handling: crafted deeplinks that trigger payment flows or leak parameters.
- Screen-overlay & accessibility-service abuse, screen-recording and clipboard exposure of UPI PIN.
- Insufficient code obfuscation enabling straightforward reverse engineering of payment logic.
4.2 Device binding & SIM binding
Device and SIM binding are UPI’s foundational anti-fraud controls and a favourite target. The framework explicitly calls out SDK handling and device binding under Application Security.
- Device-binding bypass via response manipulation: tamper with the binding-confirmation response to register an unauthorised device when server-side validation is weak.
- Binding-attempt throttling: verify the 3-attempts-per-day limit and 24-hour device-ID lock on excessive registration tokens are enforced server-side, not just in the client.
- SIM-swap / duplicate-SIM resilience: confirm re-registration requires an active registered SIM plus debit-card details, and that transactions from an unbound device are rejected.
- New-account cooling period: validate the transaction cap (e.g. ₹5,000) and limits applied to freshly registered accounts within the first 24 hours.
- Binding rebinding on device/SIM change cannot be silently inherited or replayed.
4.3 Authentication, UPI PIN & session
- Multi-factor authentication enforcement and bypass attempts across registration, login and transaction.
- UPI PIN handling — brute-force protection, lockout thresholds, and no PIN material in memory/logs.
- OTP validation: predictability, reuse, rate limiting, and SMS-spoofing/auto-read abuse.
- Session management: token strength, fixation, concurrent-session and logout invalidation.
- Privileged identity and role/access controls (least privilege, whitelist mechanisms).
4.4 API security (OWASP API Top 10 + NPCI OC-215)
Circular OC-215/2025-26 added prescriptive API controls with a hard implementation deadline. VAPT must verify each is enforced server-side:
- Broken Object Level Authorization (BOLA/IDOR): access another customer’s account, balance or transaction by manipulating identifiers.
- Rate limiting & TPS controls: throttling, exponential backoff on retries, and dropping of excessive/redundant calls.
- Daily usage quotas (listed below) enforced per user/app, not bypassable by client manipulation.
- AutoPay scheduling windows — mandates blocked during peak windows are honoured.
- Mass assignment, excessive data exposure and improper inventory (Swagger/OpenAPI completeness).
- Penny-drop / account-validation consent: explicit customer consent enforced before the call.
- Sensitive-field masking: PAN, mobile number and account data masked in responses and logs (DPDP Act 2023).
The key OC-215 usage quotas to validate are:
- Balance check — 50 calls per user per day: verify the quota is enforced server-side and cannot be reset by client manipulation.
- Linked-account view — 25 calls per day: verify the throttle holds under burst traffic and replay.
- Transaction-status check — 3 per transaction, minimum 90 seconds apart: verify the minimum interval cannot be bypassed.
- List verified merchants — 1 call per day, off-peak, at least 1,000 records per batch: verify the peak-hour and frequency restrictions hold.
4.5 Transaction & business-logic abuse
These cases require human-led testing — they are invisible to automated scanners and are where real financial loss originates.
- Amount / parameter tampering: modify transaction amount, currency or beneficiary VPA in flight.
- Race conditions & double-spend: concurrent requests to debit beyond balance or breach limits.
- Transaction-limit bypass: circumvent per-transaction, daily, or new-account caps.
- Collect-request abuse: fraudulent collect/pull requests, social-engineering-driven approvals, and auto-approval flaws.
- Replay & idempotency: replaying signed transaction messages or reusing reference IDs.
- Beneficiary/VPA manipulation and account-enumeration through validation endpoints.
4.6 Encryption, key management & data security
- Data encryption in transit (TLS configuration, weak ciphers, downgrade) and at rest.
- Cryptographic key storage — HSM-backed where required — with restricted access and rotation.
- Data masking, secure storage, retention and deletion controls.
4.7 Network, infrastructure & fraud-control validation
- Network segmentation, firewall/VPN posture, anti-malware and secure routing.
- System hardening and patch currency across servers, OS, database and web tier.
- Fraud-engine validation: velocity checks, behavioural analytics, risk scoring and real-time alerting actually trigger on anomalous patterns.
- Logging, monitoring, alerting, retention and regulator-ready audit trails.
5. Additional test cases that elevate an audit beyond compliance
Meeting the framework is the floor, not the ceiling. The engagements that genuinely reduce risk — and that mature CISOs now ask for add the following:
- Secure source code review of payment, authentication and crypto logic (called out explicitly under the framework’s Operational Review).
- Threat modelling & architecture review of the UPI transaction flow against ISO 27001 and PCI DSS.
- Assumed-breach testing: start from a compromised device, token or insider position and measure blast radius.
- Social engineering & UPI-fraud phishing simulation: vishing, fake-collect and SIM-swap pretexting against staff and support flows.
- DDoS / resilience testing of payment endpoints and validation of BCP, DR drills, RTO and RPO.
- AI/abuse-case testing of chat, voice (IVR/VSP) and emerging UPI features.
- Re-assessment to closure — every finding re-tested and validated, because NPCI accepts only a zero-open-findings report.
6. Mapping the framework to your VAPT scope
Use this mapping as a coverage checklist when scoping your next engagement or reviewing a vendor proposal.
- Application Security Lifecycle: mobile + web app pen test, secure code review, SDK & device-binding tests (NPCI Framework, OWASP MASVS).
- APIs: API pen test, OC-215 quota & rate-limit validation (OC-215, OWASP API Top 10).
- Identity & Access Management: auth/MFA, PIN, session, privilege & access testing (NPCI Framework, ISO 27001).
- Data Security & Privacy: encryption, masking, key management/HSM, storage review (DPDP Act 2023, PCI DSS).
- Network & Infrastructure: network pen test, segmentation, hardening & patch review (CERT-In, PCI DSS).
- Fraud Risk Management: fraud-control & business-logic abuse testing (NPCI Framework).
- Incident, Logging & Monitoring: log/alert validation, detection-coverage review (NPCI Framework, NCIIPC).
- Operational Resilience: VAPT re-assessment, BCP/DR validation, architecture review (ISO 27001, PCI DSS).
7. Remediation and re-assessment: closing to zero
NPCI’s “no open findings” rule changes the economics of testing. A report full of criticals is not a finish line — it is the start of a remediation-and-retest cycle that must complete before 31 December. Plan for: prioritised, developer-ready remediation guidance; fix verification; and a final validated report suitable for CERT-In and NPCI submission. Building this cycle into the engagement from day one is the difference between onboarding on schedule and missing a regulatory deadline.
Closing thoughts
UPI has become the backbone of India’s digital payment ecosystem, making security testing more critical than ever. The NPCI UPI Information Security Compliance Framework 2025 and OC-215 guidelines have raised the bar by requiring comprehensive VAPT, complete remediation, and annual compliance with zero outstanding findings.
For banks, PSPs, TPAPs, fintechs, and technology providers, the objective should extend beyond regulatory compliance. A well-executed VAPT program uncovers business logic flaws, API weaknesses, mobile application vulnerabilities, and fraud pathways before attackers exploit them. Combining technical testing with secure code review, architecture assessment, and remediation validation helps organizations strengthen customer trust while ensuring uninterrupted compliance with evolving regulatory expectations.
Security is no longer just about passing audits—it’s about protecting customers and maintaining confidence in every transaction. Best Cybersecurity & Payment Security Services Company, ValueMentor provides cybersecurity and payment security services that help enterprises to secure systems, protect transactions, and reduce cyber risks effectively.
Sources & further reading
- NPCI / KPMG in India — Unified Payments Interface (UPI) Information Security Compliance Framework 2025 (July 2025).
- NPCI Circular OC-215/2025-26 — UPI API security guidelines (rate limiting, quotas, AutoPay windows, masking).
- CyberCube — NPCI UPI Audit scope and security testing focus areas.
- OWASP Mobile Application Security (MASVS / MASTG) and OWASP API Security Top 10.
- RBI / CERT-In / NCIIPC payment-security and audit directives; ISO 27001 and PCI DSS.
FAQs:
UPI VAPT is a security assessment that identifies and validates vulnerabilities in UPI applications, APIs, and supporting infrastructure.
2. Who needs to conduct UPI VAPT?
Banks, PSPs, TPAPs, fintechs, TSPs, ASPs, and other UPI ecosystem participants.
3. Is UPI VAPT mandatory?
Yes. NPCI requires VAPT before onboarding and annually thereafter.
4. How often should UPI VAPT be performed?
At least once a year and after major application or infrastructure changes.
5. What does a UPI VAPT cover?
Mobile apps, APIs, web applications, networks, cloud, backend systems, and business logic.
6. Why is API security testing important?
It helps detect authorization flaws, rate-limit bypasses, and other API vulnerabilities.
7. Which standards are followed during UPI VAPT?
NPCI, CERT-In, OWASP, PCI DSS, ISO 27001, and applicable RBI guidelines.
8. What happens if vulnerabilities are found?
They must be remediated and retested before submitting the compliance report.
9. How does UPI VAPT improve security?
It helps prevent fraud, data breaches, and unauthorized transactions.
10. Why choose ValueMentor for UPI VAPT?
ValueMentor delivers end-to-end VAPT, remediation support, and compliance readiness for UPI and banking systems.



