What RBI asks of payment aggregators on security and data.

Who these Directions are for

The Reserve Bank of India issued the Regulation of Payment Aggregators Directions, 2025 on 15 September 2025. A non-bank aggregator needs RBI authorisation under the Payment and Settlement Systems Act, 2007 to operate, and holding that authorisation is what brings these Directions into force for it. The rulebook records them as the current governing instrument, superseding the earlier guidelines of 17 March 2020, though the exact repeal clause is unverified.

One point of scope matters before anything else. The Directions cover payment aggregators. Payment gateways are excluded, and are only encouraged, not required, to follow the technology baseline in Annexure 1. If you run a gateway and not an aggregator, the rulebook reads these clauses as something you are encouraged to follow, not required to.

Most of the security and data duties sit in paragraph 9 and in Annexure 1. This article reads them in the order a compliance head would meet them: the policy, the data, the audits, the incident reports and the people you rely on.

A Board-approved security policy

The rest of the security programme hangs from this document. The Directions ask for a policy the Board has approved, not one a technology team keeps to itself, and they ask for it to be kept alive.

An auditor will ask for the approved policy and for the record of the latest annual review. A policy that was approved once and never revisited does not meet the second clause.

Where payment data may sit

The Directions deal with where payment data may be stored in two places.

The first clause points to the earlier circular rather than restating it, so the detail of what must stay in India is in that circular. The second is a separate control in the Annexure, and it is about preventing storage abroad and controlling access. Evidence for both is a record of where your payment data actually lives, reviewed against these two clauses.

A related rule in the same Annexure is about cards. Card credentials must not be kept on a database or server that merchants can reach.

Card-data standards and the merchants you onboard

The Directions reach into the merchant's own systems, because the aggregator must ensure that the merchants it onboards comply.

PCI-DSS is the card industry's data security standard and PCI-SSF is its software security framework. The practical question is how you will know your merchants comply. The Annexure also asks for a security assessment at the moment of onboarding, and for a review of each merchant's PCI-DSS status as part of it. The evidence is a merchant checklist and the compliance records you collect, kept for each merchant.

Audits and reports

The Directions ask for several layers of independent checking, at different intervals. The first is the annual audit of the whole system.

The rulebook records the cadence as annual. The exact date by which the report must reach RBI is left to RBI's own prescription and is not a fixed number in the text we read, so we do not state one here. Annexure 1 adds an internal rhythm for what goes to the IT Committee.

VAPT means vulnerability assessment and penetration testing. AuditSahi does none of it, because it never scans, probes or tests any system. What matters for readiness is that the reports exist, that they reached the committee, and that the findings were tracked to closure.

Annexure 1 also asks for a comprehensive security risk assessment covering people, IT and business process, through an annual internal audit or one by a CERT-In empanelled external auditor, with risk, compliance and incident reports presented to the Board. Paragraph 9(e) adds that payment aggregators are also governed by RBI's separate Master Directions on Cyber Resilience and Digital Payment Security Controls for non-bank payment system operators, dated 30 July 2024, as amended. This Direction points to that instrument without restating its detailed controls, so those controls are found in that instrument and not here.

Reporting an incident to RBI

The monthly report is stated plainly. The time allowed for reporting an individual incident is not given as a number in the text we read, so we do not give one. Your incident procedure should name each route you report through and the deadline that applies to it.

The people and vendors you rely on

Many payment aggregators run on outsourced technology. The Annexure does not let the contract be silent on audit.

A related clause asks that technology-support agreements, including business continuity, disaster recovery and data management, allow the regulator access to the vendor's set-up. When you review a vendor contract, look for both. The evidence is the clause itself, or the vendor's annual audit report.

What we could not confirm

Some things are not settled in the rulebook, and we would rather say so than guess. The date by which a payment aggregator must be fully compliant is unverified. So is the penalty for failing to comply. The rulebook notes that the full Directions could not be downloaded because RBI's document store blocked automated access, and marks those two points unverified for that reason. The clauses cited above are each marked verified in the rulebook. The rulebook also records a further RBI draft on payment aggregators at physical point of sale, dated 22 April 2026. It could not read that draft and could not confirm whether it has since been finalised, so treat it as an unverified draft and not as a rule.

What this looks like as evidence

For the policy, the Board-approved Information Security Policy and its annual review record. For data, a record of where payment data is stored, checked against the storage circular and the clause on external jurisdictions. For merchants, a security assessment and PCI-DSS or PCI-SSF records for each. For audits, the CERT-In empanelled auditor's report, the quarterly and annual audit reports, and the VAPT reports with their corrective-action tracking. For incidents, the report to RBI and the monthly report with its root-cause analysis. For vendors, the audit clause or the annual third-party report. These are the documents an auditor asks for, and they are what AuditSahi asks you to upload for this rulebook.