What Payment Aggregators Must Report to RBI After a Data Breach

A data breach at a payment aggregator triggers obligations that don't exist for an ordinary business — and most of them run on a clock that starts the moment the incident is noticed, not once it's understood. Getting the sequence wrong is a compliance failure layered on top of the breach itself, and it's one of the most common mistakes fintech compliance teams make under pressure.

Who counts as a payment aggregator for this purpose

RBI's authorisation framework for Payment Aggregators covers entities that facilitate e-commerce merchants in accepting payments without directly handling the funds themselves — the category sits alongside payment gateways, PPI issuers and other payment system operators regulated under the Payment and Settlement Systems Act. If your entity holds or has applied for PA authorisation, or operates as a payment system participant more broadly, the reporting duties below apply to you regardless of how the breach originated — your own systems, a vendor, or an API partner.

The two reporting tracks that run in parallel

A breach at a regulated payment entity typically triggers two separate reporting obligations that must be tracked side by side.

The first is to CERT-In, under its directions on reporting of cyber incidents. Specified categories of incidents — unauthorised access to systems, data breaches involving financial information, targeted scanning of critical systems, and several others — must be reported within a fixed window measured from the time of noticing the incident, not from when root cause is established.

The second is to the RBI, under its cyber security and IT governance framework for the relevant category of regulated entity. This reporting is separate from, and in addition to, the CERT-In report, and the RBI's expectations around incident classification, containment steps taken, and customer impact are often more detailed than what CERT-In's format requires.

Treating these as one report filed twice is a common error. They ask different questions, go to different authorities, and a gap or inconsistency between the two is itself something a subsequent audit or enforcement action can pick up on.

What actually has to be reported

Across both tracks, the core information generally includes: the nature and timeline of the incident, systems and data categories affected, the number of customers or accounts impacted (even as a preliminary estimate), containment measures already taken, and the entity's assessment of root cause where available. A preliminary report filed on time, with an express note that investigation is ongoing, is treated far better than a complete report filed late.

Customer notification — a separate question

Reporting to CERT-In and the RBI does not automatically satisfy any obligation to notify affected customers. Depending on the nature of the data involved, contractual terms, and — once its breach-notification provisions come into force — the Digital Personal Data Protection Act, 2023, a separate customer communication may be required or advisable. This should be drafted and legally reviewed before it goes out; a hastily worded customer notice is frequently what triggers the FIRs and consumer complaints that follow a breach, more than the breach itself.

Where this intersects with a criminal complaint

If the breach was caused by an external attacker, filing a police complaint under the IT Act and the Bharatiya Nyaya Sanhita is usually advisable — both to trigger investigation and to create a documented record that supports the regulatory disclosures already made. Where the breach originated with an insider — an employee or vendor with database access — the criminal complaint and any internal disciplinary or contractual action need to be sequenced carefully so that one doesn't undermine the evidentiary basis for the other. This is covered in more depth at cyber crime cases generally, and the fuller picture of fintech exposure — including what happens if customers respond to the breach by filing FIRs of their own — is at cyber crime legal services for fintech companies.

If a settlement account gets frozen during investigation

Where the breach is tied to a fraud pattern rather than pure data exposure, it's not unusual for an investigating agency to seek a lien on the entity's settlement or nodal account while it traces the money — even where the aggregator itself did nothing wrong. Getting funds belonging to unconnected merchants released, at least partially, while the freeze is contested is addressed at frozen bank account release.

Building the reporting timeline into your incident-response plan

The single most effective fix most compliance teams can make is procedural: decide in advance who owns the CERT-In and RBI reporting decision the moment an incident is confirmed, keep template language pre-approved so notifications don't need to be drafted from scratch during an active incident, and involve legal counsel at detection — not once the internal post-mortem is finished.

Frequently asked questions

What happens if we report a breach to CERT-In but miss the RBI deadline, or vice versa?

They are assessed independently, so meeting one obligation does not excuse missing the other. A missed regulatory deadline is treated as a compliance lapse in its own right, separate from any liability arising from the breach itself.

Do we have to report a breach that only affected our own internal systems, with no customer data exposed?

Possibly — CERT-In's specified-incident categories are broader than "customer data breaches" and include several categories of unauthorised access and system compromise regardless of whether customer data was touched. This is worth confirming against the current CERT-In directions for the specific incident type.

Can we wait until the forensic investigation is complete before reporting?

No. The reporting clock runs from when the incident is noticed. A preliminary report noting that investigation is ongoing, filed on time, is the correct approach — not a complete report filed after the deadline has already passed.

Should we file a police complaint even if we don't yet know who caused the breach?

Often yes, particularly where the breach involves unauthorised external access. An early complaint preserves the investigative trail and supports the regulatory disclosures already made, even before the source is fully identified.

For advice on an active incident or a regulatory notice already received, call +91 82954 13475 at any hour, or send the details of your matter.