AppSec for Fintech in India: Regulations, Risks, and Reality

Why Fintech AppSec in India Is Different

India's fintech sector is one of the fastest-growing in the world — over 100 million UPI transactions happen every day, and the country has more than 10,000 registered fintech companies. This growth has brought with it a regulatory environment that is simultaneously more prescriptive and more rapidly evolving than most markets.

When I work with fintech teams in India, the security challenge isn't usually technical capability. It's the intersection of three pressures that don't exist in the same way elsewhere:

Regulatory density — RBI, SEBI, NPCI, IRDAI, and CERT-In all publish security mandates. Keeping up with them is a part-time job.
Speed of product iteration — Indian fintech products move extremely fast. Security that adds friction to deployment cycles gets worked around.
Threat actor sophistication — India's fintech infrastructure is a high-value target for both financially motivated attackers and state-sponsored actors.

This post is a practitioner's view of what AppSec looks like in this context — not theory, but what actually matters on the ground.

The Regulatory Landscape You Must Know

RBI Guidelines on Information Security

The Reserve Bank of India is the primary regulator for payments, lending, and banking infrastructure. Key documents every fintech AppSec team must have read:

Master Direction on Digital Payment Security Controls (2021): Mandates specific security controls for payment system operators and prepaid payment instrument issuers. Requirements include:

Mandatory VAPT (Vulnerability Assessment and Penetration Testing) before go-live and annually thereafter
Secure SDLC implementation with documented evidence
Application-level firewall deployment
Real-time transaction monitoring and anomaly detection
Incident reporting to RBI within prescribed timelines

RBI Cyber Security Framework for Banks (2016, updated): For entities licensed as banks or with banking partnerships, this framework prescribes baseline and advanced security controls across six domains. The AppSec-relevant sections cover software development practices, patch management, and third-party risk management.

RBI Guidelines on Outsourcing: Most fintechs use cloud infrastructure and third-party APIs. The outsourcing guidelines require that security controls at third-party providers meet the same standard as internal controls — and that you have the right to audit them. This directly impacts how you assess your cloud provider and critical API dependencies.

SEBI Requirements for Capital Market Fintechs

For companies in the wealthtech, broking, or capital markets infrastructure space, SEBI has issued specific cybersecurity circulars that require:

Annual third-party security audits by CERT-In empanelled auditors
Board-level oversight of the cybersecurity policy
Incident reporting within 6 hours for significant cybersecurity incidents
Business continuity and disaster recovery testing

SEBI's requirements are more prescriptive than RBI's on audit timelines and reporting. If you're operating in this space, the 6-hour incident reporting window is the most demanding operational requirement — your incident response plan must be calibrated to it.

CERT-In Directions (2022) — Often Overlooked

The CERT-In directions of April 2022 are broadly applicable to all organisations, not just financial services. The most operationally significant requirements:

Mandatory log retention for 180 days — all ICT systems logs must be maintained and produced on demand
Incident reporting within 6 hours — any cybersecurity incident must be reported to CERT-In within 6 hours of detection
Accurate system clock synchronisation — all systems must sync to NTP servers

The 6-hour reporting window is aggressive. Most organisations interpret "detection" narrowly — but build your incident response playbooks with this window in mind.

PCI DSS for Payment Processing

Any fintech that stores, processes, or transmits cardholder data must comply with PCI DSS. In India, this is a contractual requirement enforced by payment networks (Visa, Mastercard) and acquiring banks.

PCI DSS v4.0 (the current version) introduced significant changes to web application security requirements:

Requirement 6.4.1: All public-facing web applications must be protected by a WAF or undergo an application security review
Requirement 6.4.3: All payment page scripts must be managed and authorised
Requirement 11.6.1: A change-and-tamper detection mechanism must be deployed for payment pages

The PCI DSS web application requirements are the most technically demanding of any Indian regulatory framework. If you're in scope for PCI, these requirements should drive your AppSec program structure.

The Threat Landscape: What's Actually Targeting Indian Fintech

UPI and Payment API Fraud

The most common application-layer attacks targeting Indian fintech are not sophisticated — they exploit basic authorization failures in payment APIs. Common patterns:

Race condition attacks on wallet top-up flows — concurrent requests to credit a wallet before the payment confirmation is verified
Parameter tampering on payment initiation — modifying amount or beneficiary fields in requests that aren't properly validated server-side
IDOR on transaction history APIs — authenticated users accessing other users' transaction records by enumerating IDs

These aren't novel attack techniques. They're the OWASP Top 10 applied to payment flows. The reason they persist is that payment features are often built under extreme time pressure and don't get the same scrutiny as auth flows.

Account Takeover

India's high mobile-first user base means OTP-based authentication is ubiquitous. This creates a specific attack surface:

OTP brute-force — 4 or 6-digit OTPs with insufficient rate limiting can be brute-forced in minutes
SIM swap fraud — attackers social-engineer telecom operators to transfer victims' numbers, then use OTP auth to take over financial accounts
Phishing with real-time relay — sophisticated phishing pages that relay credentials to the real site in real-time, including OTPs

For AppSec teams, the mitigations for OTP brute-force are straightforward: rate limiting per phone number, exponential backoff, and OTP expiry under 5 minutes. The SIM swap problem is harder — it requires working with telecom partners and implementing additional binding signals (device fingerprint, registered IP range).

Supply Chain Risk

The Indian fintech ecosystem is highly interconnected — most fintechs use 5–15 third-party SDKs and APIs for KYC, credit scoring, payments routing, and fraud detection. Each integration is a potential supply chain risk.

The practical controls:

Software Composition Analysis (SCA) scanning in CI for known CVEs in dependencies
Vendor security assessments for critical third-party integrations
Network-level controls limiting what third-party SDKs can access (mobile apps should use certificate pinning)
Regular review of third-party SDK permissions (location, contacts, camera access in mobile SDKs is frequently over-broad)

What a Mature AppSec Program Looks Like for Indian Fintech

Secure SDLC That Satisfies RBI

RBI requires documented evidence of Secure SDLC implementation. "Documented evidence" means your security practices need to leave an audit trail. In practice:

Design reviews → Threat model documented in Confluence/Notion with sign-off
SAST in CI → Semgrep or SonarQube results in PR checks, findings tracked in Jira
Pre-release VAPT → Formal pentest report from a CERT-In empanelled firm, tracked to remediation
Post-deployment monitoring → WAF logs, anomaly detection alerts with response runbooks

The key word is documented. A control that exists but has no evidence trail doesn't satisfy a regulator.

VAPT: Doing It Right

RBI mandates VAPT before go-live and annually thereafter. Most fintechs treat this as a checkbox — hire a firm, get a report, close findings. Done.

The fintechs that get real value from VAPT treat it as a learning exercise:

Scope it for risk, not breadth — a focused pentest of your payment flows and authentication mechanisms is more valuable than a broad scan of your entire surface area
Use CERT-In empanelled auditors — required for regulatory validity, but also use the engagement to get genuine findings, not a clean report
Track remediation in your engineering backlog — findings go into Jira as bugs with severity, owner, and due date. Closure is verified by the pentest firm in a retest.
Run internal assessments between annual tests — an internal AppSec review of new features quarterly keeps your risk posture current between formal engagements

Data Localisation and PII Handling

RBI's data localisation requirements mandate that payment system data (transaction data, KYC data) be stored in India. This has direct AppSec implications:

Your cloud architecture must store sensitive financial data on India-region instances
Logs shipped to SIEM or analytics platforms must also comply — you can't stream Indian payment data to a US-region Splunk/Datadog instance without controls
Data classification must map to localisation requirements — know what data is subject to localisation and audit your data flows

For PII specifically, India's Digital Personal Data Protection Act (DPDPA) 2023 introduces consent-based processing requirements and breach notification obligations. Your incident response plan must include a data breach assessment step.

Incident Response at Regulatory Speed

The 6-hour CERT-In reporting window requires that your incident response plan have very short detection-to-triage cycles. The practical requirements:

Centralised logging with alerting (CloudWatch, Datadog, or equivalent) — you cannot detect in 6 hours what you can't see
An on-call rotation with clear escalation paths for security incidents
A pre-written incident report template that can be populated and submitted quickly
Legal/compliance on the distribution list for incident notifications — they need to assess whether regulatory reporting is triggered

A tabletop exercise simulating a data breach is worth running annually. Discovering that your incident response process takes 48 hours during a real incident is significantly worse than discovering it during a drill.

Practical Starting Point for a Fintech AppSec Team

If you're building an AppSec function at an Indian fintech from scratch, this is the sequence I'd recommend:

Map your regulatory obligations — which RBI/SEBI/NPCI guidelines apply to your license type? Build a controls matrix.
Secure your payment flows — IDOR, race conditions, parameter tampering on payment APIs are the highest-risk surface. Audit these first.
Implement SAST in CI — Semgrep with a focused ruleset on secrets, injection, and authorization failures
Commission your first VAPT — use a CERT-In empanelled firm, scope it around authentication and payment flows
Build your incident response runbook — calibrated to the 6-hour CERT-In reporting window
Start the SOC 2 / ISO 27001 process — enterprise B2B and banking partnerships will ask for this

The Indian fintech security landscape is demanding, but it's also maturing rapidly. The companies that build security into their foundations — rather than bolting it on before an audit — are the ones that close enterprise partnerships, satisfy regulators, and avoid the incidents that destroy customer trust overnight.