INDUSTRY FACT FILE · PAYMENTS & TRANSACTION PROCESSING

Cybersecurity FAQs for Payments and Transaction Processing

Forty frequently asked questions and answers in five categories, written for Boards, CXOs, CISOs, compliance heads and technology teams in payments and transaction processing companies.

In this document 1.  Category 1: Cyber risk, governance and strategy 2.  Category 2: RBI regulatory compliance and audits 3.  Category 3: Application, API, mobile and payment-page security 4.  Category 4: Fraud, SOC, incident response and forensics 5.  Category 5: Data privacy, cloud, third parties and emerging technology

Audience: Board members, CEO, CISO, Chief Risk Officer

Q1. Why is cybersecurity a licence-level issue for payments and transaction processing companies?

For authorised entities, cybersecurity is written into the conditions of operation. RBI's Master Direction on Payment Aggregators (2025) requires a Board-approved information security policy, mandatory baseline technology controls and annual cyber security audits; the 2024 cyber resilience directions for non-bank payment system operators require Board oversight, a Cyber Crisis Management Plan and 6-hour incident reporting. Weaknesses can lead to supervisory action, restrictions and loss of partner-bank confidence, so cyber risk is a business-continuity and licence risk, not only an IT risk.

Q2. What are the most significant cyber risks facing payments and transaction processing companies today?

The most consequential risks are account takeover, social-engineering scams, mule accounts and mule merchants, API abuse, e-skimming and malicious third-party code, business-logic abuse, cloud misconfiguration, third-party compromise, ransomware, DDoS, insider misuse, settlement tampering, personal-data leakage and slow detection. Their priority depends on the company's role in the payment chain, its technology stack and its existing controls.

Q3. How does cyber risk differ between a payment aggregator, a wallet issuer and a lending platform?

A payment aggregator's highest-consequence risks sit in merchant onboarding, checkout pages and settlement; a wallet issuer's sit in account takeover, KYC abuse and fraud against customers; a lending platform's sit in API data exposure, borrower privacy and fake lending apps. A good programme starts from the entity's licence, products and money flows rather than a generic checklist.

Q4. What should the Board's information security sub-committee review each quarter?

RBI's 2024 directions for non-bank PSOs allow the Board to delegate oversight to a sub-committee headed by a member with information or cyber security experience, meeting at least once a quarter. Useful agenda items include key risk and performance indicators, results of system audits and VA/PT (which the directions require to be placed before the sub-committee), recurring findings, significant incidents and their root causes, critical vendor risks, DR and backup test results, and progress against the remediation roadmap.

Q5. Who should own cybersecurity inside a fintech?

Ownership is layered: the Board (or its sub-committee) oversees information security risk; a senior executive such as the CISO is accountable for implementation; payment aggregators must also maintain an IT Steering Committee; the Principal Officer handles AML reporting to FIU-IND; and a privacy lead or DPO coordinates data-protection obligations. Clear role definitions matter most during incidents, when decisions must be made within hours.

Q6. How much should a fintech spend on cybersecurity?

There is no regulatory percentage. Spending should follow risk: first close critical exposures and meet mandatory audit and testing cycles, then strengthen detection and response, then improve governance and resilience. Managed services can give smaller entities 24x7 capability without building a full in-house team. The useful measure is reduction in exposure and faster closure of findings, not the size of the budget.

Q7. Do unregulated payment gateways and technology partners need to follow RBI's security requirements?

Payment gateways are outside the PA authorisation regime, but RBI encourages them to follow the baseline technology recommendations in the PA Master Direction. Separately, the 2024 directions require non-bank PSOs to endeavour, through a Board-approved policy and subject to mutual agreement, to extend the directions to unregulated entities in their digital payments ecosystem, such as payment gateways, third-party service providers and vendors.

In practice, regulated partners will push security requirements into contracts and due-diligence questionnaires, so technology partners benefit from being able to demonstrate equivalent controls.

Q8. How can Codec Networks support a payment or fintech company's cybersecurity strategy?

Codec Networks provides VAPT, application and API security, regulatory cyber audits, PCI DSS and ISO 27001 readiness, managed SOC, forensics and incident response, privacy programmes, third-party risk management and Board advisory. Engagements can begin with a focused assessment and expand into a recurring assurance calendar aligned to the entity's regulatory obligations.

Audience: Compliance heads, CISOs, internal audit, Principal Officers

Q9. Which RBI instruments govern cybersecurity for non-bank payment and fintech companies?

The main instruments are the Master Directions on Cyber Resilience and Digital Payment Security Controls for non-bank PSOs (30 July 2024); the Master Direction on Regulation of Payment Aggregators (15 September 2025); the Authentication Mechanisms for Digital Payment Transactions Directions, 2025 (in force from 1 April 2026); the Digital Lending Directions, 2025; the Master Directions on Prepaid Payment Instruments (2021, as updated); and the 2018 circular on Storage of Payment System Data. CERT-In's Directions of April 2022 and the DPDP Act and Rules apply alongside them. Applicability depends on the entity's licence and category.

Q10. What audits does a payment aggregator need under the 2025 Master Direction?

The Master Direction requires an annual system audit that includes a cyber security audit by CERT-In empanelled auditors, submitted to the relevant RBI regional office within the prescribed timelines; annual external IS audit and cyber security audit reports with corrective actions and closure dates; half-yearly VAPT reports; and quarterly internal audit reports to the IT Committee. Escrow balances must also be certified by auditors at defined intervals.

Q11. When must non-bank PSOs comply with the 2024 cyber resilience directions?

Compliance is phased by category: large non-bank PSOs (including NPCI, card payment networks, non-bank ATM networks, White Label ATM operators, large PPI issuers, TReDS operators, BBPOUs and payment aggregators) by 1 April 2025; medium non-bank PSOs (inbound MTSS operators and medium PPI issuers) by 1 April 2026; and small non-bank PSOs (small PPI issuers and instant money transfer operators) by 1 April 2028. Entities that move to a larger category receive defined transition periods.

Q12. What does the 6-hour incident reporting requirement mean in practice?

Under the 2024 directions, non-bank PSOs must report unusual incidents—such as cyber-attacks, outages of critical systems, internal fraud and settlement delays—to RBI in the prescribed format within 6 hours of detection, and report cyber security incidents to CERT-In. CERT-In's Directions independently require specified incidents to be reported within 6 hours of noticing them. Meeting this reliably requires 24x7 monitoring, a designated point of contact, pre-agreed classification criteria and rehearsed playbooks.

Q13. What is the payment data storage requirement and how is compliance demonstrated?

RBI's April 2018 circular requires payment system providers to ensure that the entire data relating to payment systems operated by them is stored in systems only in India, with defined treatment for the foreign leg of cross-border transactions. Compliance is demonstrated through a Board-approved System Audit Report prepared by a CERT-In empanelled auditor. A data-flow mapping exercise across applications, backups, logs and vendors is the usual starting point.

Q14. What changes under RBI's Authentication Directions from 1 April 2026?

Domestic digital payment transactions must be authenticated with at least two factors, at least one of which is dynamic, subject to specified exemptions. RBI does not mandate any particular factor, which allows alternatives to SMS OTP such as biometrics or device-bound tokens, and issuers may apply additional risk-based checks. Card issuers have specific obligations for cross-border card-not-present transactions from 1 October 2026. Authentication flows, device binding and fallback paths should be re-tested against the new rules.

Q15. How do the Digital Lending Directions, 2025 affect security for lending platforms?

The Directions consolidate the digital lending framework from 8 May 2025. Regulated lenders must report the digital lending apps they use on RBI's CIMS portal (from 15 June 2025) and remain responsible for their LSPs; multi-lender LSPs must present offers transparently (from 1 November 2025); and the framework restricts how DLAs and LSPs collect, store and share borrower data. This creates demand for API and app security testing, data-flow and privacy reviews, and lender oversight of LSP controls.

Q16. Can Codec Networks perform audits that must be conducted by a CERT-In empanelled auditor?

Yes. Codec Networks is empanelled by CERT-In for information security auditing services. The scope, methodology, reporting format and any independence requirements are agreed in the engagement proposal so that the report meets the expectations of the regulator and the entity's Board.

Audience: CTOs, engineering heads, application security teams

Q17. How often should payment and fintech companies conduct VAPT?

Frequency depends on the entity's obligations and risk. Payment aggregators submit VAPT reports half-yearly under the 2025 Master Direction. The 2024 directions require non-bank PSOs to conduct security testing—including source code review, vulnerability assessment and penetration testing—at least annually in authenticated mode, and to complete security audits including VA/PT before deploying new or significantly changed critical services. Additional testing is advisable after major releases, cloud migrations or new partner integrations.

Q18. What is authenticated testing and why does it matter?

Authenticated testing is performed with valid user credentials and roles, the way a logged-in customer, merchant or administrator would access the system. It finds the authorisation flaws, business-logic weaknesses and data-exposure issues that unauthenticated scans cannot reach—the issues that most often lead to real financial loss in payment platforms.

Q19. What should mobile application security testing for a UPI or wallet app cover?

Testing should cover device binding and registration, authentication and session handling, secure local storage, communication security and certificate pinning, root and jailbreak detection, tamper and repackaging resistance, detection of screen-sharing and remote-access apps, transaction-signing logic and backend API security. RBI's 2024 directions specify mobile controls such as device binding, automatic session termination, lockout after failed logins and a 12-hour cooling period after a change of registered mobile number or e-mail. OWASP MASVS provides a useful test baseline.

Q20. Why is API security a top priority for fintech companies?

Payment, lending and account-aggregation services are built on APIs, and a single authorisation flaw can expose many customers' records or allow unauthorised actions. The OWASP API Security Top 10 highlights broken object-level authorisation, broken authentication and excessive data exposure as leading risks. APIs should be inventoried, tested in each significant release and monitored for abuse.

Q21. What are PCI DSS requirements 6.4.3 and 11.6.1, and why do they matter?

Requirement 6.4.3 requires that every script loaded on a payment page is authorised, its integrity assured and its purpose documented. Requirement 11.6.1 requires a mechanism to detect unauthorised changes to payment pages and their HTTP headers. Both became mandatory on 31 March 2025 and directly address e-skimming attacks that steal card data from checkout pages.

Q22. If we use tokenisation, do we still need PCI DSS?

Tokenisation reduces the amount of card data an organisation stores, which can reduce PCI DSS scope, but it does not automatically remove it. Scope depends on whether systems store, process or transmit card data or could affect its security. RBI's 2024 directions require PSOs that store card data to be PCI DSS certified, and the PA Master Direction requires merchant infrastructure to comply with PCI DSS and PCI SSF where applicable. A scoping assessment confirms what remains in scope.

Q23. How should we secure third-party SDKs and scripts?

Maintain an inventory of every SDK and script with an owner and business purpose; review new components before integration; pin versions and verify integrity; restrict what each component can access; monitor for unexpected changes and outbound connections; and include security obligations in vendor contracts. Supply-chain security testing and software composition analysis help identify vulnerable or malicious components.

Q24. What is a secure software development lifecycle, and does RBI expect one?

A secure SDLC builds security into requirements, design, coding, testing and release—through threat modelling, secure coding standards, code review, SAST/DAST and controlled deployment. RBI's 2024 directions for non-bank PSOs call for a secure-by-design approach and multi-tier application architecture, and require PSOs to obtain source code or put escrow arrangements in place for critical applications procured from vendors.

Audience: Chief Risk Officers, fraud heads, SOC managers, incident response teams

Q25. Do non-bank payment system operators need a Security Operations Centre?

The 2024 directions list a Security Operations Centre with SIEM-based correlation among the network security measures expected of non-bank PSOs, alongside real-time or near real-time fraud monitoring. Entities can build an in-house SOC, use a managed SOC, or run a co-managed model in which their own tools are operated by a provider's analysts.

Q26. How can a SOC help with payment fraud, not just cyber attacks?

A payment-aware SOC correlates security events with fraud signals: new device registrations, SIM-change indicators, login anomalies, remote-access app detection, sudden changes in merchant volumes and unusual refund or payout patterns. Combining these signals helps detect account takeover and mule activity earlier than either the security team or the fraud team could alone.

Q27. What is a mule merchant, and how can aggregators detect one?

A mule merchant is a merchant account opened—often with borrowed or synthetic identity documents—to receive and move fraud proceeds. Warning signs include transaction volumes inconsistent with the declared business, many low-value test transactions after onboarding, collections from geographically dispersed payers, rapid settlement requests and links to other suspicious merchants. The 2025 PA Master Direction requires post-onboarding monitoring of merchant transactions against their business profile.

Q28. What fraud-monitoring capabilities do RBI's 2024 directions expect?

The directions expect real-time or near real-time fraud monitoring, a 24x7x365 manned facility for fraud resolution and responses to law enforcement, multi-factor authentication for electronic debit transactions unless specifically relaxed, and subscription to anti-phishing and anti-rogue-app services. Customers must also be able to report fraudulent transactions through the entity's app or website.

Q29. What should our incident response plan include?

It should align with the Board-approved Cyber Crisis Management Plan and define incident classification, roles and decision authority, escalation paths, containment and recovery steps, evidence preservation, internal and external communications, and the reporting workflow to RBI, CERT-In and other authorities within the required timelines. Payment aggregators should also plan for the monthly cyber incident reports with root-cause analysis required by the 2025 Master Direction.

Q30. How long must we retain logs?

CERT-In's Directions require covered entities to maintain logs of their ICT systems securely for a rolling 180 days within Indian jurisdiction. RBI's 2024 directions for non-bank PSOs require audit logs to be retained for at least five years. Retention policies should also consider other applicable requirements and investigation needs.

Q31. When should we bring in a forensic team?

Early—ideally as soon as a material incident is suspected. Forensic specialists help preserve evidence before it is overwritten, establish what happened and when, determine whether data or funds were affected, and support regulatory reporting, partner communications and any legal action. An incident response retainer agreed in advance avoids procurement delays during a crisis.

Q32. How should we test our response and recovery readiness?

Use a mix of tabletop exercises for leadership, technical simulations such as ransomware or account-takeover scenarios, and recovery tests. RBI's 2024 directions require backups to be tested for recovery at least half-yearly and DR drills at least half-yearly, with the DR site in a different seismic zone from the primary data centre. Lessons learned should be tracked to closure.

Audience: Data Protection Officers, cloud and infrastructure heads, procurement and vendor management, innovation teams

Q33. When do the DPDP Act obligations apply to fintech companies?

The DPDP Rules, 2025 were notified on 13 November 2025 with phased commencement. Provisions relating to the Data Protection Board took effect immediately; consent-manager provisions take effect after 12 months; and most data-fiduciary obligations—including notices, security safeguards and breach intimation—take effect after 18 months, in May 2027. Fintechs should use the remaining time to map personal data, review consent and notices, strengthen safeguards and prepare breach workflows.

Q34. What will a personal data breach require under the DPDP Rules?

Once the breach provisions commence, a data fiduciary must inform affected Data Principals and intimate the Data Protection Board without delay, followed by a detailed report to the Board within 72 hours (or a longer period if allowed). These obligations run alongside the existing 6-hour reporting timelines to CERT-In and, for regulated payment entities, to RBI.

Q35. Can payment data be hosted on public cloud?

Yes, provided the regulatory conditions are met—in particular, payment system data must be stored in systems only in India under RBI's 2018 circular. RBI's 2024 directions also expect cloud service providers to undergo independent security audits at least annually, reviewed by the Board sub-committee. Entities remain responsible for configuring and monitoring their cloud environments under the shared-responsibility model.

Q36. What cloud security issues do fintechs most commonly face?

Frequent issues include publicly exposed storage, over-privileged IAM roles, long-lived access keys, secrets in code repositories or logs, missing encryption, weak network segmentation, untracked test environments and incomplete logging. Continuous cloud posture monitoring, regular configuration reviews and least-privilege access address most of these risks.

Q37. How should we manage third-party and vendor cyber risk?

Classify vendors by criticality and access, perform due diligence before onboarding, include security and incident-notification obligations in contracts, review evidence periodically and monitor high-risk vendors continuously. The 2024 directions refer PSOs to RBI's 2021 framework for outsourcing of payment and settlement-related activities and require critical vendors to provide certified assurance from an independent auditor on their cyber resilience.

Q38. What security risks come with using AI in onboarding, credit decisions or customer service?

Risks include manipulation of AI models, leakage of personal or confidential data through prompts or outputs, prompt-injection attacks against chatbots and AI agents, excessive permissions granted to agents, and unreliable automated decisions. AI systems should be inventoried, tested with AI-specific techniques, governed under a framework such as ISO/IEC 42001 and monitored in production.

Q39. How do deepfakes affect KYC and video-based customer identification?

Synthetic faces, manipulated video and cloned voices can be used to impersonate customers during video-based KYC or to impersonate executives and staff in social-engineering attacks. Defences include liveness detection, document and device checks, risk-based escalation to human review, staff awareness and periodic deepfake simulation testing of onboarding and approval workflows.

Q40. How can we start an engagement with Codec Networks?

Begin with a scoping discussion covering your licences and categories, products and money flows, critical systems, existing audit calendar and immediate concerns. Codec Networks will then propose a scope, methodology, timeline and deliverables—often starting with a regulatory gap assessment or a VAPT and API security assessment—and a roadmap for recurring assurance.

Contact Codec Networks Pvt. Ltd. New Delhi: 507, 5th Floor, New Delhi House, Barakhamba Road, Connaught Place, New Delhi – 110001 Gurugram: 707, 7th Floor, Silverton Tower, Golf Course Extension Road, Sector 50, Gurugram – 122018, Haryana Landline: 011 430 496 96 | 011 437 522 99   Mobile: +91 99716 76124 | +91 88007 88220 | +91 88003 31124 Email: mktg@codecnetworks.com   Web: www.codecnetworks.com

Note: These FAQs provide general cybersecurity guidance as of October 2026 and do not constitute legal or regulatory advice. Regulatory applicability depends on each entity's authorisation, category and activities; confirm obligations against the current official instruments, including amendments and FAQs issued by RBI, NPCI, CERT-In and MeitY.