INDUSTRY FACT FILE · PAYMENTS & TRANSACTION PROCESSING

Five New Case Studies in Payments and Transaction Processing Security

Original 2026 case studies, each written as a blog post, showing how current threats play out under India's newest payment regulations and how Codec Networks services break the attack chain.

In this document 1.  About these case studies 2.  Case Study 1: The Merchant That Was Never a Merchant 3.  Case Study 2: Skimmed at Checkout, Compliant on Paper 4.  Case Study 3: One API Call Away from Every Borrower's File 5.  Case Study 4: The Wallet Takeover That Beat the OTP 6.  Case Study 5: Six Hours on the Clock

These five case studies were written for this document set and have not been published elsewhere. Each is a composite scenario: it combines attack techniques and control failures that are widely observed in the payments and transaction processing sector with the regulatory obligations that apply in India as of October 2026—including RBI's 2025 Payment Aggregator Master Direction, the 2025 Authentication Directions, the 2024 cyber resilience directions for non-bank PSOs, the Digital Lending Directions, CERT-In's Directions and the DPDP Rules.

Important disclosure The organisations described are fictional and the scenarios are illustrative. They are not accounts of real incidents, and they are not Codec Networks client engagements or claims of achieved outcomes. Their value lies in the method: showing how connected weaknesses form an attack chain, which controls break it, and which services test those controls.

Case study	Segment	Core threat	Regulatory lens	Primary bundles
1. The Merchant That Was Never a Merchant	Payment aggregator	Mule merchants and fraudulent onboarding	PA Master Direction 2025; PMLA / FIU-IND	B4, B7, B8
2. Skimmed at Checkout, Compliant on Paper	Online PA / payment gateway	E-skimming through a third-party script	PCI DSS v4.0.1; PA baseline technology controls	B5, B2, B7
3. One API Call Away from Every Borrower's File	Digital lending platform	Broken object-level authorisation	Digital Lending Directions 2025; CERT-In; DPDP Rules	B2, B6, B8
4. The Wallet Takeover That Beat the OTP	PPI issuer / wallet	Account takeover via SIM swap and remote-access apps	2024 PSO directions; Authentication Directions 2025	B2, B10, B7
5. Six Hours on the Clock	Non-bank PSO	Cloud storage exposure and leaked keys	2024 PSO directions; CERT-In Directions	B3, B7, B8

How a payment aggregator's fastest-growing merchants turned out to be a fraud ring's collection accounts—and what the 2025 PA Master Direction expects aggregators to catch.

At a glance
Organisation	A mid-sized, RBI-authorised online payment aggregator (“Aggregator A”) serving small online sellers
Threat	Mule merchants onboarded with borrowed identities to collect scam proceeds
Why it is new	The 2025 Master Direction's merchant due-diligence and post-onboarding monitoring rules, with existing merchants required to be brought into compliance within one year of the Direction
Codec Networks services	Onboarding controls review, process-bypass testing, mule analytics in the managed SOC, forensic investigation (Bundles B4, B7, B8)

The scenario

Aggregator A was proud of its onboarding speed: small sellers could start accepting payments the same day. Over three months, a group of new merchants—registered as home-décor and electronics resellers with modest declared turnover—passed onboarding using the simplified route for small merchants. Each had a valid PAN, a bank account and a working phone number.

For a few weeks the merchants processed small test transactions. Then volumes jumped. Victims of investment and task scams were told to pay “processing fees” through payment links that led to these merchants. Within days, collections reached many times the declared annual turnover, and settlements were requested as fast as the aggregator allowed.

The pattern surfaced only when the escrow bank flagged unusual inflows and law enforcement sent requests to freeze funds. By then, a large share of the money had already been settled onward.

Figure 8: Illustrative attack path for Case Study 1 and the controls that break it.

What went wrong

• Onboarding checks verified documents, not businesses. PAN and bank account checks passed, but nobody cross-checked GST status, address and web presence against the declared business.
• No link analysis. Several merchants shared devices, IP ranges and contact numbers—signals that were collected but never correlated.
• Monitoring compared transactions to thresholds, not to profiles. A seller declaring a small annual turnover was allowed to collect far more within weeks without review.
• Settlement was instant for new merchants. No graduated settlement or holding period applied during the first months of a merchant relationship.
• Escalation to the Principal Officer was manual and slow, delaying suspicious-transaction reporting to FIU-IND.

The impact

Beyond the frozen funds and customer complaints, the aggregator faced questions from its escrow bank, scrutiny of its merchant due-diligence process and a reputational hit with the platforms it served. Because the 2025 Master Direction requires post-onboarding monitoring of merchant transactions against their business profile, the incident became a compliance issue as well as a fraud loss.

The regulatory lens

• The PA Master Direction (15 September 2025) requires customer due diligence on merchants under the KYC Master Direction, background and antecedent checks, and monitoring of post-onboarding transactions against the merchant's business profile. Merchants onboarded by 31 December 2025 have one year from the date of the Direction to be brought into compliance.
• Non-bank PAs must register with FIU-IND and meet reporting obligations under the PMLA.
• The 2024 cyber resilience directions expect real-time or near real-time fraud monitoring by non-bank PSOs, including PAs.

How Codec Networks would help

Need	Codec Networks response	Bundle
Prove onboarding controls work	End-to-end onboarding controls review and process-bypass testing using realistic synthetic merchant profiles	B4, B10
Detect mule patterns early	SOC use cases correlating device, network, contact and volume-versus-profile signals; alerts to the fraud and compliance teams	B7
Investigate and preserve evidence	Forensic investigation of the merchant cluster and preparation of evidence for regulators, banks and law enforcement	B8
Close the loop	Remediation tracking, re-KYC prioritisation of the existing merchant base and retesting	B4

Key lessons Verify the business, not just the documents. Monitor merchants against their declared profile, from day one. Graduate settlement limits for new merchants. Automate escalation so suspicious activity reaches the Principal Officer the same day.

A single altered analytics script on a hosted checkout page—and why PCI DSS requirements 6.4.3 and 11.6.1 were written for exactly this situation.

At a glance
Organisation	An online payment aggregator (“Aggregator B”) offering hosted checkout pages to thousands of merchants
Threat	E-skimming through a compromised third-party script
Why it is new	PCI DSS v4.0.1 payment-page script and tamper-detection requirements became mandatory on 31 March 2025; many organisations still treat them as paperwork
Codec Networks services	Payment-page security assessment, PCI DSS readiness, supply-chain testing, SOC monitoring of outbound connections (Bundles B5, B2, B7)

The scenario

Aggregator B's hosted checkout loaded several third-party scripts for analytics, chat support and A/B testing. A small vendor that supplied one analytics script suffered a breach of its own content-delivery account. The attacker added a few lines of obfuscated code that activated only on pages containing card-entry fields.

For several weeks, card numbers, expiry dates and security codes typed into the checkout were copied and sent to a look-alike domain. Payments still succeeded, so neither customers nor merchants noticed anything unusual. The problem came to light when card networks identified Aggregator B's checkout as a common point of purchase for a cluster of fraudulent card transactions.

Figure 9: Illustrative attack path for Case Study 2 and the controls that break it.

What went wrong

• The script inventory existed only on paper. A list had been prepared for an assessment, but scripts were added later without review.
• No integrity controls. Scripts were loaded without Subresource Integrity checks or a restrictive Content Security Policy.
• No tamper detection. Nothing alerted the team when the content of the payment page changed as delivered to browsers.
• Outbound traffic was not monitored. Data leaving customers' browsers for an unknown domain went unnoticed.

The impact

Aggregator B faced a forensic investigation, card reissuance costs passed through the card ecosystem, potential penalties under card network rules, partner-bank reviews and a difficult conversation with thousands of merchants. Because the 2025 PA Master Direction requires card credentials never to be stored on merchant-accessible systems and requires merchant infrastructure to comply with PCI DSS and PCI SSF where applicable, the incident also raised questions about the aggregator's oversight of merchant integrations.

The regulatory and standards lens

• PCI DSS v4.0.1 requirement 6.4.3: every script on a payment page must be authorised, its integrity assured and its purpose documented.
• PCI DSS v4.0.1 requirement 11.6.1: a change- and tamper-detection mechanism must alert personnel to unauthorised modifications of payment-page scripts and security-impacting HTTP headers.
• PA Master Direction (2025): mandatory baseline technology recommendations, incident reporting to RBI and monthly cyber incident reports with root-cause analysis.
• CERT-In Directions (2022): reporting of specified cyber incidents within 6 hours.

How Codec Networks would help

Need	Codec Networks response	Bundle
Know every script	Payment-page discovery, script inventory with owners and justification, PCI DSS 6.4.3 gap closure	B5
Make tampering visible	Design and validation of tamper detection for payment pages and headers (PCI DSS 11.6.1), CSP and SRI review	B5, B2
Reduce supply-chain exposure	Third-party script and SDK risk review, supply-chain security testing	B2, B9
Detect exfiltration	SOC monitoring of unexpected outbound connections and look-alike domains	B7

Key lessons Compliance is a state that must be maintained, not a document. Treat every third-party script as code running inside your payment flow. Detect changes as the customer's browser sees them. Watch where data goes, not just where it comes from.

A digital lending app trusted the loan ID sent by its own front end. That one assumption exposed borrower documents—and illustrates why API authorisation testing belongs in every release.

At a glance
Organisation	A lending service provider (“Lender Platform C”) operating a digital lending app for two NBFC partners
Threat	Broken object-level authorisation (BOLA) in a loan-status API
Why it is new	Combines the 2025 Digital Lending Directions, multi-lender platform obligations and upcoming DPDP breach duties with the most common real-world API flaw
Codec Networks services	API security testing, secure code review, DPDP privacy programme, incident response and forensics (Bundles B2, B6, B8)

The scenario

Lender Platform C added a feature that let borrowers download their loan documents, Key Fact Statement and repayment schedule. The mobile app called an API with the loan ID. The API checked that the user was logged in—but not that the loan belonged to that user.

A security researcher noticed that changing the loan ID in the request returned another borrower's documents, including KYC images and bank statements collected for underwriting. The researcher reported the issue responsibly, but screenshots began circulating on social media before the fix was deployed. The platform now had to establish whether anyone else had exploited the flaw.

Figure 10: Illustrative attack path for Case Study 3 and the controls that break it.

What went wrong

• Authorisation was checked at the session level, not the object level. Being logged in was treated as permission to read any record.
• Security testing happened annually, not per release. The new endpoint went live between test cycles.
• Responses returned more data than needed, including full document links that did not expire.
• API logs lacked user-to-object detail, making it hard to determine quickly which records had been accessed.
• No vulnerability disclosure channel, so the researcher's report took time to reach the right team.

The impact

Lender Platform C had to notify its NBFC partners, who remain responsible for their LSPs under the Digital Lending Directions. It had to assess whether the event was a reportable cyber incident under CERT-In's 6-hour requirement, and prepare for the obligations that will apply under the DPDP Rules once the breach provisions commence in May 2027. Borrower trust and partner confidence were both at stake.

The regulatory lens

• RBI (Digital Lending) Directions, 2025: regulated entities remain responsible for their LSPs and DLAs, and the framework restricts how borrower data is collected, stored and shared.
• CERT-In Directions (2022): reporting of specified incidents—including data breaches and data leaks—within 6 hours, and retention of ICT logs for 180 days in India.
• DPDP Act and Rules: once the relevant provisions commence, intimation to the Data Protection Board and affected Data Principals, with a detailed report within 72 hours, and reasonable security safeguards.

How Codec Networks would help

Need	Codec Networks response	Bundle
Find authorisation flaws before release	API security testing against the OWASP API Top 10 in each significant release; authenticated testing with multiple user roles	B2
Fix the root cause	Secure code review, threat modelling and authorisation design patterns for the engineering team	B2
Reduce the data at risk	Data minimisation, expiring document links, data-flow mapping and DPIA	B6
Respond and prove scope	Log analysis and forensic review to establish which records were accessed; reporting support	B8

Key lessons Every API must ask: does this user own this object? Test what you release, when you release it. Return the minimum data, with links that expire. Log enough to answer “who accessed what” within hours.

How a SIM swap and a screen-sharing app defeated SMS OTP at a wallet issuer—and how the 2024 mobile security controls and the 2025 Authentication Directions change the playbook.

At a glance
Organisation	A full-KYC PPI issuer (“Wallet D”) with a large consumer base and a linked credit-line partnership
Threat	Account takeover through SIM swap, social engineering and a remote-access app
Why it is new	From 1 April 2026, at least two factors (one dynamic) are required and alternatives to SMS OTP are explicitly allowed; the 2024 directions already require device binding and a 12-hour cooling period
Codec Networks services	Mobile application security testing, IAM & MFA bypass testing (SIM swapping, OTP attacks), fraud-signal monitoring, awareness simulation (Bundles B2, B10, B7)

The scenario

A customer received a call from someone claiming to be from Wallet D's support team, warning that the account would be blocked unless the customer completed a “security update”. The customer was persuaded to install a screen-sharing app. Separately, the attacker had arranged a SIM swap using forged documents.

With OTPs now arriving on the attacker's SIM and the customer's screen visible, the attacker changed the registered mobile number, bound a new device and began transferring the wallet balance. Because the wallet was linked to a partner credit line, the attacker also drew down available credit before the customer realised what had happened.

Figure 11: Illustrative attack path for Case Study 4 and the controls that break it.

What went wrong

• SMS OTP was the only dynamic factor, so a SIM swap defeated it.
• Device change was too easy: a new device could be bound with the same OTP, without a cooling period or a step-up check.
• Remote-access apps were not detected, even though the app could have blocked transactions while one was active.
• Risk scoring ignored SIM-change and device signals available from telecom and device-intelligence sources.
• Alerts went to the compromised channel, so the customer did not see them in time.

The impact

Wallet D faced customer losses, a dispute over liability with its credit partner, complaints escalated to regulators and wider media attention on wallet security. The case also showed how adding credit to payment apps raises the value of every account takeover.

The regulatory lens

• 2024 cyber resilience directions for non-bank PSOs: device binding, automatic session termination, lockout after failed logins, blocking of transactions while remote-access apps are active, a 12-hour cooling period after a change of registered mobile number or e-mail, and cooling periods for PPIs after loading.
• Authentication Directions, 2025 (in force from 1 April 2026): at least two factors, one of them dynamic, with flexibility to adopt stronger alternatives to SMS OTP and risk-based additional checks.
• Fraud monitoring: real-time or near real-time monitoring and a 24x7 facility for fraud resolution.

How Codec Networks would help

Need	Codec Networks response	Bundle
Test the controls attackers target	Mobile app testing of device binding, cooling periods, remote-access detection and session handling	B2
Simulate the real attack	IAM & MFA bypass testing including SIM-swap and OTP-interception scenarios; social-engineering simulation for support teams	B10
Catch takeovers in progress	SOC use cases combining SIM-change, device, login and transaction signals	B7
Prepare for new authentication rules	Review of authentication design against the 2025 Directions, including fallback and recovery paths	B2, B4

Key lessons Treat a device or mobile-number change as a high-risk event. Do not rely on SMS OTP as the only dynamic factor. Block payments while remote-access apps are active. Send alerts through a channel the attacker does not control.

A cloud migration left a log archive open to the internet. The exposure was serious; the real test was whether the operator could detect, decide and report within six hours.

At a glance
Organisation	A non-bank payment system operator (“Operator E”) running bill-payment and payout services on public cloud
Threat	Publicly readable storage bucket containing transaction logs and API keys
Why it is new	Tests the 6-hour reporting requirement to RBI (2024 directions) and CERT-In together, in a cloud-native environment
Codec Networks services	Cloud security posture assessment, secrets and IAM review, managed SOC, incident response retainer, tabletop exercises (Bundles B3, B7, B8, B10)

The scenario

During a migration to a new cloud account, an engineer created a storage bucket for log archives and, to fix a permissions error during testing, temporarily made it publicly readable. The change was never reverted. The bucket accumulated application logs that contained masked transaction details—and, because of a logging bug, unmasked API keys for an internal service.

Security researchers scanning for exposed buckets found it and e-mailed Operator E's general support address on a Friday evening. The message reached the security team on Saturday morning. Meanwhile, the exposed keys had already been used to call an internal API from an unfamiliar IP address.

Figure 12: Illustrative attack path for Case Study 5 and the controls that break it.

What went wrong

• No continuous cloud posture monitoring, so a public bucket went unnoticed for weeks.
• Secrets in logs: a logging defect wrote API keys into files, and keys were long-lived.
• Over-privileged keys: the exposed key could call more functions than its service needed.
• No security contact for external reports, delaying awareness by hours.
• The 6-hour reporting workflow had never been rehearsed, so time was lost deciding who should decide.

The impact

Operator E had to rotate keys, investigate API activity, assess what data was exposed, and report to RBI and CERT-In within the required windows—while partner banks and billers asked for assurances. Supervisory follow-up questions focused on cloud governance, secrets management and vendor oversight.

The regulatory lens

• 2024 cyber resilience directions: reporting of unusual incidents to RBI within 6 hours of detection and of cyber incidents to CERT-In; annual independent security audits of cloud service providers; audit logs retained for at least five years; encryption of data at rest and in transit.
• CERT-In Directions (2022): reporting of specified incidents within 6 hours, a designated point of contact and retention of ICT logs for a rolling 180 days in India.
• Storage of payment system data (2018): payment system data must be stored in systems only in India, which cloud migrations must preserve.

How Codec Networks would help

Need	Codec Networks response	Bundle
Find exposure before others do	Cloud security posture assessment and continuous assurance, including public-exposure checks	B3
Protect secrets	Secrets management, key rotation and least-privilege IAM review; log hygiene testing	B3, B2
Detect misuse	SOC correlation of cloud audit logs and API activity	B7
Meet the 6-hour clock	Incident playbooks with pre-filled RBI and CERT-In reporting templates, tabletop exercises and a forensic retainer	B8, B10

Key lessons Assume misconfiguration will happen; monitor for it continuously. Keep secrets out of logs and rotate them automatically. Publish a security contact for external reports. Rehearse the 6-hour decision, not just the technical fix.

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