INDUSTRY FACT FILE · PAYMENTS & TRANSACTION PROCESSING

Threat Landscape: Top Cyber Threats Facing Payments and Transaction Processing

The 18 most relevant cyber threats, attacks and industry challenges for payments and transaction processing companies in India, and the impact each one has on industry players.

In this document 1.  The threat picture in numbers 2.  Top 18 threats, attacks and challenges 3.  Threat relevance by segment 4.  Five priority threats in depth 5.  Impact on industry players 6.  How regulation turns incidents into business events 7.  Questions every leadership team should ask

Payments and fintech companies sit where criminals want to be: at the point where money moves. Public data shows the scale of cyber-enabled financial fraud in India and the response being built across the ecosystem.

₹22,849 cr Reported cyber-fraud losses in 2024 (I4C data)

₹19,813 cr Reported cyber-fraud losses in 2025 (I4C data)

29 banks Using RBIH's MuleHunter.AI (July 2026)

6 hours To report incidents to RBI and CERT-In

These figures, reported from Indian Cybercrime Coordination Centre (I4C) data, cover complaints across all channels, not only payment companies. They nonetheless show why regulators now expect payment entities to detect, report and respond to incidents within hours. The industry response includes RBI Innovation Hub's MuleHunter.AI tool for identifying mule accounts and the Digital Payments Intelligence Platform, which the Government told Parliament in July 2026 had seven banks onboarded in its pilot phase.

The following list is a practical assessment framework for the payments and transaction processing sector. It is not a statistical ranking; actual priority varies by business model, technology exposure and existing controls.

#	Threat / attack / challenge	Typical scenario	Players most exposed	Potential business impact
1	Account takeover (ATO)	SIM swap, OTP interception, credential stuffing or a malicious app gives an attacker control of a wallet, UPI app or lending account	Wallets, UPI apps, lenders	Direct customer losses, reimbursement claims, regulatory complaints
2	Social engineering and authorised push-payment scams	Fake customer-care numbers, investment and task scams, impersonation of officials; the victim authorises the payment	UPI apps, wallets, PAs	Customer harm, grievance load, reputational damage, pressure on liability frameworks
3	Mule accounts and mule merchants	Accounts and merchant IDs opened with borrowed or synthetic identities to receive and move scam proceeds	PAs, wallets, cross-border players	Regulatory scrutiny of onboarding, FIU-IND reporting failures, partner-bank exits
4	API abuse and broken authorisation	Attackers manipulate object IDs, tokens or parameters to read other customers' data or trigger unauthorised actions	All API-first players, especially lenders and AAs	Mass data exposure, transaction manipulation, DPDP liability
5	E-skimming and malicious third-party scripts or SDKs	Compromised analytics, chat or payment scripts on checkout pages copy card data; malicious SDKs in apps	PAs, gateways, merchants	Card-data compromise, network penalties, forensic and reissuance costs
6	Business-logic abuse	Exploiting refund, reversal, cashback, limit or retry logic to extract money without 'hacking' in the traditional sense	PAs, wallets, UPI apps	Silent financial leakage, reconciliation breaks
7	QR-code and collect-request fraud	Fake or overlaid QR codes, malicious collect requests and fake payment-confirmation screens	UPI apps, merchants, PAs	Merchant and customer losses, dispute volumes
8	Fake, cloned and rogue apps	Fake lending apps, cloned payment apps, screen-sharing and remote-access tools used to steal credentials	Lenders, wallets, UPI apps	Brand abuse, customer harm, regulatory action against unauthorised lending
9	Synthetic identities and deepfake-assisted KYC	Forged documents, AI-generated faces or voices used to defeat KYC and V-CIP checks	Wallets, lenders, PAs	Fraudulent onboarding at scale, credit losses, KYC compliance findings
10	Cloud misconfiguration and secrets exposure	Public storage buckets, over-privileged IAM roles, exposed API keys in code or logs	Cloud-native fintechs, PSOs	Data exposure, unauthorised access, 6-hour incident reporting obligations
11	Third-party and technology service provider compromise	A processor, KYC vendor, SDK provider or managed service is breached and used as a path into clients	All players	Downstream breaches across many entities, outsourcing-control findings
12	Ransomware and data extortion	Encryption of systems and theft of data, with threats to publish	PSOs, processors, lenders	Service outage, settlement delays, data disclosure, recovery costs
13	DDoS and availability attacks	Floods against payment APIs, checkout pages or switches, sometimes with extortion demands	PAs, PSOs, networks	Failed transactions, SLA breaches, lost merchant revenue
14	Insider misuse and privileged-access abuse	Employees, contractors or vendor staff misuse access to data, limits or settlement functions	PSOs, PAs, processors	Fraud, data theft, settlement manipulation
15	Settlement, escrow and reconciliation tampering	Altered settlement files, manipulated payout instructions or abuse of reconciliation gaps	PAs, PSOs, cross-border players	Direct loss of merchant funds, regulatory breach of escrow rules
16	Leakage of personal and financial data	Over-collection, weak access controls, logs and exports containing personal data	Lenders, AAs, wallets	DPDP obligations, customer complaints, partner and regulator action
17	Weak detection and slow incident response	Missing logs, untuned alerts and unclear escalation delay detection beyond regulatory reporting windows	All players	Missed 6-hour reporting, larger blast radius, weaker evidence
18	AI-enabled attacks and AI-system abuse	AI-written phishing, voice cloning of executives, prompt injection against AI chatbots and agents	All players using AI in service or operations	Fraudulent approvals, data leakage, unreliable automated decisions

Different segments experience the same threat with different intensity. The matrix below is a qualitative guide for prioritising the first round of security reviews.

Figure 5: Qualitative threat relevance by industry segment (Codec Networks assessment).

4.1 Account takeover and authentication bypass

Account takeover combines technical and human weaknesses: SIM swaps, OTP sharing under pressure, malware or screen-sharing apps, reused passwords and weak device binding. RBI's 2024 directions for non-bank PSOs require device binding, session time-outs, lockouts after failed logins, blocking of transactions while remote-access apps are active and a 12-hour cooling period after a change of registered mobile number or e-mail. From 1 April 2026, the Authentication Directions require two factors, at least one of them dynamic.

• Questions to test: Can a new device be bound without a strong second factor? Are SIM-change and remote-access signals used in risk scoring? Do customer alerts reach the customer before the money leaves?
• Relevant services: mobile application security testing, authentication flow review, IAM & MFA bypass testing, fraud-scenario simulation, SOC fraud-signal monitoring.

4.2 Mule merchants and fraudulent onboarding

Scam proceeds need somewhere to land. Merchant IDs and accounts opened with borrowed, rented or synthetic identities give criminals a way to collect and move money. The 2025 PA Master Direction strengthens merchant due diligence: CKYCR-based retrieval, a simplified route for small merchants with Contact Point Verification, background checks and ongoing monitoring of transactions against the merchant's business profile.

• Questions to test: Do onboarding checks cross-verify PAN, GST, bank account and address? Are velocity limits and settlement holds applied to new merchants? Are suspicious patterns escalated to the Principal Officer for FIU-IND reporting?
• Relevant services: onboarding controls review, process-bypass testing, mule-merchant analytics, forensic investigations.

4.3 API abuse and broken authorisation

Payments and lending platforms are API-first, and APIs are where most serious data-exposure findings occur. Broken object-level authorisation—trusting an ID sent by the client—can expose every customer's records through a single flaw. Excessive data in API responses and missing rate limits compound the problem.

• Questions to test: Is every API tested for object- and function-level authorisation in each release? Are partner and internal APIs inventoried? Are tokens scoped and short-lived?
• Relevant services: API security testing (REST, GraphQL, SOAP), secure code review, API gateway assessment, DevSecOps integration.

4.4 E-skimming and the software supply chain

A checkout page often loads scripts from many third parties. If any one is altered, card data can be copied silently. PCI DSS v4.0.1 requirements 6.4.3 (inventory and authorisation of payment-page scripts) and 11.6.1 (detection of unauthorised changes to payment pages) became mandatory on 31 March 2025. Mobile SDKs raise the same issue inside apps.

• Questions to test: Is there an authorised inventory of every script on payment pages? Would a change be detected within days, not months? Are SDKs reviewed before integration?
• Relevant services: payment-page security assessment, PCI DSS readiness, supply-chain security testing, SOC monitoring of outbound connections.

4.5 Cloud misconfiguration and the 6-hour clock

Cloud-native fintechs move fast, and misconfigurations—public storage, wildcard IAM policies, keys in code repositories—are among the most common real-world causes of exposure. When an incident occurs, CERT-In's Directions and RBI's directions for non-bank PSOs both require reporting within six hours, which is only realistic if logging, ownership and playbooks are in place beforehand.

• Questions to test: Is cloud posture monitored continuously? Are ICT logs retained for 180 days in India and audit logs for at least five years where required? Has the 6-hour reporting process been rehearsed?
• Relevant services: cloud security posture assessment, secrets and IAM review, managed SOC, incident response retainer, tabletop exercises.

The consequences of a cyber incident in this sector extend well beyond IT. The table summarises the most consequential impacts for each player type.

Player type	Threats to prioritise	Main impact
Payment aggregators	Mule merchants, e-skimming, API abuse, settlement tampering, DDoS	Merchant and partner-bank trust, escrow integrity, authorisation standing
PPI issuers and wallets	Account takeover, social engineering, synthetic KYC, rogue apps	Customer losses and complaints, KYC findings, brand damage
PSOs, networks and switches	Ransomware, DDoS, insider misuse, third-party compromise	Systemic outages, participant confidence, supervisory action
Digital lending platforms	API data exposure, fake lending apps, synthetic identities, data leakage	Borrower harm, lender-partner exits, privacy liability
Account Aggregators	API abuse, consent bypass, data leakage	Ecosystem trust, regulatory standing
Cross-border players	Mule flows, partner compromise, settlement tampering	AML exposure, correspondent and AD-bank relationships
Technology service providers	Supply-chain compromise, cloud misconfiguration	Simultaneous impact on many regulated clients, contract losses

For a payment entity, an incident immediately becomes a regulatory and partner event:

• Reporting clocks: unusual incidents to RBI within 6 hours of detection under the 2024 directions for non-bank PSOs; specified cyber incidents to CERT-In within 6 hours; payment aggregators also submit monthly cyber incident reports with root-cause analysis.
• Evidence expectations: ICT logs for a rolling 180 days in India (CERT-In) and audit logs retained for at least five years (RBI 2024 directions for non-bank PSOs).
• Customer liability: from 1 January 2027, RBI's revised framework for fraudulent electronic banking transactions places the burden of proving customer liability on banks—raising the stakes for fintech partners whose channels carry those transactions.
• Privacy obligations: once DPDP breach provisions commence (May 2027), personal data breaches must be intimated to the Data Protection Board, with a detailed report within 72 hours.
• Partner reactions: sponsor banks, escrow banks and networks may restrict or review the relationship after a material incident.

Insight The most damaging incidents in this sector are usually chains, not single failures: a weak onboarding control lets a mule merchant in, weak monitoring lets the money out, and a slow response turns a fraud case into a regulatory finding. Assessments should test the chain end to end.

• Which of our products and partners would hurt us most if compromised, and when were they last tested?
• Can we detect, triage and report a material incident to RBI and CERT-In within six hours—today, at 2 a.m.?
• Do we know every third-party script, SDK and API partner that touches payment or customer data?
• How quickly would we spot a merchant or account behaving outside its declared profile?
• Are our cloud environments monitored continuously for exposure and misconfiguration?
• Is our Board sub-committee receiving risk indicators that show control effectiveness, not just activity?

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: Threat descriptions and relevance ratings are general guidance, not findings about any specific organisation. Loss and complaint figures are as reported from I4C data in public reports and cover all channels. Regulatory obligations summarised here depend on the entity's authorisation and category; confirm against official instruments.