RBI Payment Aggregators & Payment Gateways (PA-PG)

Introduction: The RBI PA-PG Guidelines and Why They Matter

The Reserve Bank of India (RBI) Guidelines on Regulation of Payment Aggregators and Payment Gateways, first issued on 17 March 2020 (circular DPSS.CO.PD.No.1810/02.14.008/2019-20) and progressively amended through subsequent circulars, fundamentally reshaped how online payment intermediaries are supervised in India. For the first time, entities that had operated in a lightly regulated grey zone, holding merchant funds, routing card and account credentials, and settling proceeds, were brought squarely under the direct authorisation and prudential oversight of the RBI under the Payment and Settlement Systems Act, 2007 (PSS Act).

The guidelines draw a clear regulatory line between two roles that historically overlapped. Payment Aggregators (PAs) are entities that onboard merchants, receive payment instructions from customers on behalf of those merchants, pool the collected funds into an escrow account, and settle net proceeds to merchants after a defined period. Because PAs handle and control the flow of money, they require RBI authorisation and must maintain minimum net worth thresholds. Payment Gateways (PGs), by contrast, provide the technology to route and facilitate a transaction between the merchant, the acquirer and the payment networks, but do not handle settlement funds; they are treated as technology providers or outsourcing partners and are subject to the baseline security guidelines rather than the authorisation and net-worth regime.

This distinction is central to every compliance exercise. An entity that touches settlement money is a PA and carries the full regulatory burden, including escrow discipline, governance, merchant due diligence, data storage restrictions and periodic reporting to the RBI. An entity that only routes technical messages is a PG and must chiefly satisfy the baseline technology and security recommendations. The 2021 and later amendments extended the framework to Payment Aggregators for Cross-Border transactions (PA-CB, via the October 2023 circular) and, through the RBI's tokenisation and Card-on-File (CoF) mandates, tightened the rules around card data storage. This guide provides an auditor-grade, end-to-end interpretation of the PA-PG framework as it applies to entities operating in India, structured so that a compliance team, an internal audit function or an external assessor can plan, execute and evidence a full readiness assessment.

What Are the RBI PA-PG Guidelines

The RBI PA-PG Guidelines are a principles-plus-prescriptions regulatory framework that governs the authorisation, capital adequacy, governance, conduct, data security and settlement discipline of online payment intermediaries. They are not a voluntary standard like ISO 27001; they are binding regulatory requirements enforced by the RBI, and non-compliance can result in refusal or revocation of authorisation, monetary penalties, directions to wind down operations, and reputational consequences for the entity's directors and promoters.

The framework operates across several intertwined dimensions. First, it establishes an authorisation regime: existing non-bank PAs had to apply for authorisation, and new PAs must obtain a Certificate of Authorisation before commencing operations. Bank PAs do not require separate authorisation as the activity is treated as part of normal banking business, but they must comply with the operative instructions. Second, it imposes prudential requirements, most notably a minimum net worth of INR 15 crore at the time of application, rising to INR 25 crore by the end of the third financial year and to be maintained thereafter. Third, it prescribes governance and fit-and-proper standards for promoters and directors. Fourth, it mandates escrow-based fund management with strict timelines for merchant settlement. Fifth, it sets out merchant onboarding, KYC and due-diligence obligations. Sixth, it imposes baseline technology and security requirements covering the entire card and payment data lifecycle, including the prohibition on PAs and merchants storing customer card credentials (CoF data) beyond the limited exceptions permitted, and the promotion of tokenisation.

Crucially, the security recommendations of the guidelines are risk-proportionate and reference established baselines. They expect PAs and PGs to align with recognised security standards such as PCI DSS, to conduct regular vulnerability assessment and penetration testing (VAPT), to obtain periodic system audits from CERT-In empanelled auditors, and to implement fraud prevention, incident response and business continuity controls. This is why a PA-PG readiness engagement frequently runs alongside a PCI DSS assessment and a CERT-In system audit; the three exercises share substantial control overlap.

Who Must Comply

Applicability turns on the role an entity plays in the payment flow and whether it handles settlement funds. The following table summarises the principal categories of entities and the extent of their obligations under the framework.

• Any non-bank entity that onboards merchants and pools customer funds before settling them is a Payment Aggregator and must be authorised.
• Pure technology routers that never touch settlement money are Payment Gateways and follow the baseline security guidelines only.
• Cross-border collection and settlement (import/export payments) falls under the separate PA-CB approval track with its own thresholds.
• Marketplaces that centralise collection for multiple independent sellers are frequently caught by the PA definition and cannot rely on a technology-provider exemption.
• Banks providing aggregation do not need a fresh authorisation but are not exempt from the conduct and security expectations.

Structure of the RBI PA-PG Guidelines

For assessment purposes it is helpful to decompose the framework into logical domains. The RBI circulars do not present a formal numbered control catalogue in the way ISO 27001 Annex A or the PCI DSS requirements do; instead the obligations are distributed across the body of the guidelines and their annex on baseline technology-related recommendations. The table below organises those obligations into assessable domains and control families that an auditor can systematically test.

Master Assessment Checklist

This is the core of the guide. Each control family from the structure above is expanded into a set of verification points and the typical evidence an assessor should collect. Work through every group; do not skip a domain merely because it appears less relevant to a particular business model, as the RBI expects demonstrable coverage across the whole framework. Evidence should be current, dated, version-controlled and, where relevant, independently certified.

D1. Authorisation & Legal Status

D2. Prudential & Net Worth

D3. Governance & Fit-and-Proper

D4. Escrow & Settlement

D5. Merchant Onboarding & Due Diligence

D6. Customer Grievance & Dispute Resolution

D7. Data Storage & Card-on-File (CoF)

D8. Baseline Information Security

D9. Access Control & Identity

D10. Cyber & Fraud Risk Management

D11. Vulnerability & Audit Assurance

D12. Incident Response & Business Continuity

D13. Outsourcing & Third-Party Risk

D14. Reporting & Regulatory Compliance

Scoping the Assessment

Correct scoping determines both the cost and the credibility of a PA-PG assessment. The scope must encompass every system, process, third party and data flow involved in receiving payment instructions, authorising transactions, holding funds in escrow, and settling merchants. A common and costly error is to scope only the cardholder data environment (as one might for a narrow PCI DSS engagement) while omitting the escrow reconciliation systems, merchant onboarding platforms, grievance systems and reporting pipelines that the RBI framework equally cares about.

• People: employees and contractors involved in payment operations, merchant onboarding, fraud, treasury/escrow, security and compliance.
• Processes: transaction authorisation and routing, settlement and escrow reconciliation, merchant KYC, grievance handling, incident response and regulatory reporting.
• Technology: the CDE, payment switch/gateway, token vault, merchant portal, escrow reconciliation systems, fraud engine, logging and monitoring stack.
• Data: card and payment credentials, tokens, merchant KYC data, transaction records, settlement data and personal data subject to data-localisation.
• Third parties: payment gateways, acquiring banks, escrow bank, cloud/hosting providers, KYC vendors and any outsourced operations centre.
• Locations: data centres and cloud regions (must be within India for card/payment data), disaster recovery sites and any offshore support access paths.

Where a Payment Gateway (technology-only) is being assessed rather than a full PA, the scope narrows to the baseline security domains (D7 through D13) and the contractual controls that flow down from the authorised PA, but the assessor should confirm through data-flow analysis that the PG genuinely never touches settlement funds, otherwise it is a de facto PA.

Implementation Approach

A structured, phased programme moves an entity from an initial gap position to authorisation-readiness and sustained compliance. Each phase below lists indicative activities and the deliverables an assessor or programme manager should expect to see produced.

Phase 1: Discovery and Gap Assessment

• Activities: map the entity against the PA vs PG definitions, inventory systems and data flows, and perform a control-by-control gap assessment across all fourteen domains.
• Activities: assess net worth position, escrow arrangement and current security posture (including any existing PCI DSS status).
• Deliverables: current-state data-flow diagrams, PA/PG classification memo, gap-assessment report with prioritised findings, indicative remediation budget.

Phase 2: Governance and Policy Foundation

• Activities: draft and obtain board approval for the required policies (information security, KYC/AML, merchant onboarding, grievance redressal, outsourcing, incident response).
• Activities: establish the escrow arrangement with a scheduled bank and define settlement timelines; appoint the nodal/compliance officer.
• Deliverables: board-approved policy suite, escrow agreement, governance and committee structure, fit-and-proper declarations.

Phase 3: Technical and Security Remediation

• Activities: remediate the CDE to PCI DSS, purge stored card data, implement tokenisation, enforce data-localisation, and close VAPT findings.
• Activities: deploy MFA, PAM, fraud monitoring, logging/SIEM and encryption/key-management controls.
• Deliverables: PCI DSS AOC/ROC, tokenisation implementation evidence, data-purge certificates, VAPT retest reports, hardened configuration baselines.

Phase 4: Operationalisation and Assurance

• Activities: run the merchant onboarding, grievance, fraud and reconciliation processes in production and generate operating evidence; conduct a CERT-In empanelled system audit.
• Activities: perform BCP/DR drills, incident-response tabletop exercises and internal audit of the framework.
• Deliverables: CERT-In system audit report, DR drill and IR exercise reports, operating MIS, internal audit report.

Phase 5: Authorisation, Reporting and Continuous Compliance

• Activities: compile and submit the authorisation application (or maintain authorisation), establish the compliance calendar, and file periodic RBI returns.
• Activities: institute ongoing monitoring, annual re-audit and management review cycles.
• Deliverables: RBI application/renewal pack, compliance calendar, periodic returns, annual assurance reports and management review minutes.

Maturity and Capability Model

Although the RBI framework is a pass/fail regulatory regime, a maturity model is invaluable for internal programme management, board reporting and prioritisation. The following five-level model can be applied to each of the fourteen domains to produce a heat-map of readiness.

Assessment and Audit Approach

An auditor-grade engagement should follow a disciplined, evidence-led methodology so that conclusions are defensible before the RBI, the board and external auditors.

1. Confirm classification: through data-flow analysis, determine whether the entity is a PA, a PG, a PA-CB or a hybrid, as this drives the applicable control set.
2. Define and freeze scope: agree the systems, processes, data flows, locations and third parties in scope, and document exclusions with justification.
3. Plan the assessment: build a control matrix mapping each of the fourteen domains to test procedures and required evidence.
4. Collect documentation: obtain policies, agreements, certificates, prior audit reports and MIS ahead of fieldwork.
5. Conduct interviews and walkthroughs: validate that documented processes reflect operating reality for escrow, onboarding, fraud, grievance and incident handling.
6. Perform technical testing: review PCI DSS status, VAPT results, data-storage scans, tokenisation, access controls and encryption.
7. Test settlement and escrow: reconcile escrow balances to merchant payables and verify settlement timeliness on a sample basis.
8. Evaluate third parties: assess PG and other vendor contracts, due diligence and right-to-audit provisions.
9. Rate and report findings: assign severity, map to domains, and produce a gap report with prioritised, time-bound remediation.
10. Validate remediation: retest closed findings and issue a final assurance statement or readiness opinion, with a schedule for periodic re-assessment.

Evidence Request List

The following categorised list is the evidence an assessor should request. Providing this upfront materially accelerates fieldwork and reduces back-and-forth.

• Authorisation and legal: Certificate of Authorisation or in-principle approval, Certificate of Incorporation, MoA/AoA, RBI correspondence.
• Prudential: CA-certified net worth certificates (application and latest), audited financial statements, net worth computation working.
• Governance: board-approved policies, committee charters and minutes, fit-and-proper declarations, nodal officer appointment.
• Escrow and settlement: escrow agreement, bank confirmations, daily reconciliation statements, settlement-timing MIS.
• Merchant: merchant onboarding checklist, sample KYC files, MCC assignment records, prohibited-merchant screening evidence, merchant agreements.
• Grievance: published grievance policy, grievance register, TAT and ageing MIS, chargeback SOP.
• Data and card security: data-storage scan results, tokenisation architecture and vault evidence, data-purge certificates, data-localisation attestation.
• Information security: IS policy, PCI DSS ROC/AOC and ASV scans, network diagrams, hardening baselines, patch reports.
• Access and identity: RBAC matrix, MFA and PAM configuration, access-review and JML records.
• Fraud and cyber risk: fraud engine rules, alert and loss MIS, AFA configuration, AML/STR records.
• Assurance: VAPT reports and retests, CERT-In empanelled system audit report, SAST/DAST reports.
• Resilience: IR plan and exercise reports, BCP/DR plan and drill reports, backup and restore-test logs.
• Third party: outsourcing policy, vendor register, PG contracts, vendor risk assessments.
• Reporting: RBI return submissions and acknowledgements, compliance calendar, incident-reporting records, retention policy.

Roles and Responsibilities

Clear accountability across the RACI dimensions is essential; the RBI expects named ownership for each obligation, not diffuse responsibility.

KPIs to Track

• Net worth headroom above the applicable INR 15/25 crore threshold, reported quarterly.
• Percentage of merchant settlements completed within the mandated timeline (Tp+1/Ts+1).
• Daily escrow reconciliation break count and time-to-resolution.
• Merchant onboarding KYC completion rate and pending-KYC ageing.
• Grievance resolution turnaround time and percentage resolved within SLA.
• Fraud rate (basis points of transaction value) and net fraud loss trend.
• Percentage of card data purged and share of transactions using tokenised credentials.
• VAPT and system-audit findings: count, severity mix and mean-time-to-remediate.
• PCI DSS control compliance percentage and days to AOC/ROC renewal.
• Cyber-incident reporting timeliness against CERT-In/RBI deadlines.
• Third-party/vendor reassessments completed on schedule.
• Regulatory returns filed on time as a percentage of total due.

Readiness Checklist

• Entity correctly classified as PA, PG or PA-CB with data-flow evidence.
• Valid RBI Certificate of Authorisation held or application prepared.
• Net worth of at least the applicable threshold demonstrated and CA-certified.
• Single dedicated escrow account established with a scheduled commercial bank.
• Merchant settlements consistently within mandated timelines.
• Board-approved policy suite in force with version control.
• Merchant KYC, MCC assignment and prohibited-merchant screening operating.
• Grievance policy published with named nodal officer and Ombudsman disclosure.
• No card credentials stored beyond permitted fields; tokenisation live.
• Card and payment data localised within India with attestation.
• Current PCI DSS AOC/ROC covering the cardholder data environment.
• MFA, least privilege and PAM enforced for privileged access.
• Real-time fraud monitoring and AFA operating.
• Periodic VAPT and a CERT-In empanelled system audit completed with findings closed.
• Tested incident response, BCP and DR plans with CERT-In/RBI reporting readiness.
• Outsourcing and PG contracts carry security, data-localisation and right-to-audit clauses.
• Compliance calendar in place and periodic RBI returns filed on time.

Common Gaps

• Mis-classification: operating as a de facto PA (touching settlement funds) while claiming to be a technology-only PG to avoid authorisation.
• Escrow discipline failures: co-mingling merchant funds with own funds, or breaching settlement timelines.
• Residual card data: incomplete purge of previously stored CoF/card data despite the storage prohibition.
• Weak tokenisation adoption: recurring and stored-credential flows still relying on raw PAN.
• Data-localisation gaps: card or payment data processed or stored, even transiently, outside India via cloud regions or offshore support.
• Stale assurance: PCI DSS AOC or CERT-In system audit lapsed, or findings left open beyond SLA.
• Thin merchant due diligence: superficial KYC and no ongoing risk monitoring or MCC governance.
• Governance gaps: policies not board-approved, no named nodal officer, or missing fit-and-proper declarations.
• Vendor blind spots: PG and cloud contracts lacking right-to-audit, security and RBI-access clauses.
• Reporting lapses: late or inaccurate RBI returns and missed cyber-incident reporting deadlines.
• Fraud control gaps: absent velocity checks, AFA not enforced for card-not-present, or unmonitored fraud losses.

RBI PA-PG Guidelines Mapped to Other Frameworks

Because much of the PA-PG security expectation is expressed by reference to established baselines, an entity can reuse control evidence across multiple frameworks. The mapping below highlights the principal correspondences an assessor can leverage.

Frequently asked questions

Need help with RBI PA-PG Guidelines?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.