RBI Compliance for Payment Companies Explained

The payments ecosystem in India has expanded rapidly, and with that expansion, the regulatory scrutiny on payment aggregators (PAs) and payment gateways (PGs) has intensified considerably. RBI compliance for payment companies is no longer a box to check during authorization. It is an ongoing, multi-dimensional obligation that spans data localization, cybersecurity, settlement timelines, grievance redressal, and merchant due diligence. Compliance leaders at these entities must navigate a layered regulatory framework where the cost of gaps is not just financial penalties but potential loss of authorization itself.

This post breaks down the regulatory framework, authorization requirements, key compliance areas, ongoing obligations, and the most common compliance gaps that payment companies encounter.

RBI’s Regulatory Framework for Payment Aggregators and Gateways

The foundational regulation governing payment aggregators and payment gateways is the RBI’s “Guidelines on Regulation of Payment Aggregators and Payment Gateways” issued on March 17, 2020 (updated periodically through subsequent circulars). These guidelines brought PAs under direct RBI regulation for the first time, requiring them to obtain authorization under the Payment and Settlement Systems Act, 2007 (PSS Act).

The framework distinguishes between payment aggregators and payment gateways. PAs are entities that facilitate e-commerce transactions by handling funds between buyers and merchants. PGs, on the other hand, provide the technology infrastructure without handling funds directly. RBI’s regulatory requirements apply primarily to PAs, though PGs are expected to comply with baseline security standards and are governed indirectly through their relationships with banks and PAs.

Beyond the core PA/PG guidelines, payment companies must also comply with RBI’s directions on data storage, the RBI cybersecurity framework, KYC/AML regulations, and various circulars issued to address specific operational risks. This creates a compliance surface that is both broad and deep, requiring payment companies to track obligations across multiple regulatory instruments simultaneously.

Where Payment Companies Sit in the Regulatory Hierarchy

Payment aggregators operate in a unique regulatory position. They are regulated by RBI under the PSS Act, but they also interact with regulations from CERT-In (incident reporting within 6 hours), the DPDP Act 2023 (processing of customer personal data), and SEBI (where merchants include listed entities or capital market intermediaries). This multi-regulator exposure means that RBI compliance for payment companies cannot be treated in isolation. It must be managed as part of a broader regulatory compliance program.

Authorization Requirements for Payment Aggregators

Any entity seeking to operate as a payment aggregator must obtain authorization from RBI. The authorization process involves meeting specific eligibility criteria related to net worth, governance, technology infrastructure, and operational readiness.

Net Worth and Capital Requirements

Existing PAs (those operating before the March 2020 guidelines) were required to achieve a net worth of ₹15 crore by March 2021 and ₹25 crore by March 2023. New applicants must demonstrate a net worth of ₹15 crore at the time of application and ₹25 crore by the end of the third financial year of receiving authorization. These thresholds ensure that PAs have adequate financial backing to manage settlement risks and operational continuity.

Fit and Proper Criteria

RBI evaluates the promoters and directors of the applicant entity against fit and proper criteria. This includes track record, financial soundness, integrity, and the absence of criminal proceedings. The governance structure must include an independent board with adequate oversight over compliance and risk management functions.

Technology and Security Readiness

The authorization application must demonstrate that the entity has robust information security governance, including a board-approved information security policy, a CISO or equivalent function, PCI-DSS certification (version 3.2.1 or later), and a PA-DSS compliant application. RBI expects applicants to provide evidence of security audits conducted by CERT-In empanelled auditors.

Key Compliance Areas for Payment Companies

Once authorized, payment aggregators face continuous compliance obligations across several critical areas. These are not annual exercises. They require ongoing monitoring, evidence capture, and periodic reporting.

Data Storage and Localization

RBI’s circular on storage of payment system data (April 2018) mandates that all data related to payment transactions processed by payment system operators must be stored only in India. This applies to end-to-end transaction data, including full details of customer information, payment-sensitive data, and transaction records. Payment companies must ensure that no payment data is stored, processed, or mirrored in systems located outside India, even temporarily.

Consider a payment aggregator that uses a global cloud service provider for redundancy. Even if the primary data center is in India, any replication to servers outside India violates the localization mandate. The compliance obligation extends to third-party processors, sub-merchants, and technology partners in the transaction chain.

Settlement Timelines and Escrow Requirements

PAs must maintain the amount collected from customers in an escrow account with a scheduled commercial bank. The PA/PG guidelines specify strict settlement timelines. For marketplace transactions, the amount must be transferred to the merchant within T+1 business day of the delivery confirmation or service completion. For non-marketplace transactions, settlement must happen on a T+1 basis from the date of capture of funds.

The escrow account cannot be used for any purpose other than settlement to merchants. PAs must reconcile escrow accounts daily and ensure that the balance accurately reflects unsettled merchant payables. Any deviation in settlement timelines triggers reporting obligations and potential regulatory action.

Merchant Due Diligence and Onboarding

Payment aggregators are responsible for conducting due diligence on merchants before onboarding them. This includes KYC verification, assessment of business legitimacy, website/app review, and background checks on the merchant’s promoters. RBI expects PAs to maintain a risk-based approach to merchant classification, with enhanced due diligence for high-risk categories (gambling, crypto, adult content, and similar verticals where permitted).

Ongoing monitoring of merchant activity is equally critical. PAs must have systems to detect unusual transaction patterns, velocity anomalies, and potential misuse of the payment infrastructure for money laundering or fraud. This requirement directly overlaps with PMLA (Prevention of Money Laundering Act) obligations.

Grievance Redressal Mechanism

PAs must establish a grievance redressal framework that includes a designated nodal officer, clear escalation matrices, and defined timelines for resolution. Customer complaints related to failed transactions, delayed refunds, or unauthorized debits must be resolved within specific timeframes prescribed by RBI. If the PA fails to resolve the complaint within 30 days, the customer can escalate to the RBI Ombudsman under the Integrated Ombudsman Scheme.

The grievance mechanism must be accessible, transparent, and documented. RBI inspections specifically examine complaint resolution data, average resolution time, and the adequacy of the escalation framework.

Cybersecurity and Information Security

RBI’s expectations for cybersecurity in payment companies are substantial. PAs must implement a board-approved cyber security policy, conduct regular vulnerability assessments and penetration testing (VAPT), maintain a Security Operations Center (SOC) or equivalent capability, and report cybersecurity incidents to RBI and CERT-In within prescribed timelines.

The RBI cybersecurity framework outlines specific controls covering network security, access management, application security, and incident response. Payment companies must also ensure compliance with PCI-DSS standards and undergo annual audits by qualified security assessors. For entities processing high transaction volumes, the cybersecurity obligations extend to real-time fraud monitoring, behavioral analytics, and continuous threat intelligence integration.

PA/PG Guidelines: Ongoing Obligations

Authorization is the starting point. The ongoing obligations under the PA/PG guidelines create a continuous compliance workload that requires structured governance.

Periodic Reporting to RBI

Payment aggregators must submit periodic reports to RBI covering transaction volumes, settlement data, escrow account status, merchant base changes, and cybersecurity incident summaries. The frequency and format of these reports are prescribed by RBI and updated through circulars. Missing reporting deadlines or submitting inaccurate data constitutes a compliance breach.

Tracking these circular-level obligations across multiple reporting windows is a structural challenge for compliance teams. When RBI issues a new circular modifying reporting requirements, the compliance function must identify the change, assess its impact, update internal workflows, and ensure execution within the prescribed timeline. This is where a system for RBI circular tracking becomes operationally essential.

Annual System Audit

PAs must undergo an annual system audit conducted by CERT-In empanelled auditors. The audit covers information security governance, access controls, network architecture, encryption practices, incident management, and data storage compliance. The audit report must be submitted to RBI along with a compliance statement from the PA’s board.

Board-Level Oversight

RBI expects that the board of the PA takes active ownership of compliance and risk management. This includes board-level review of cybersecurity posture, fraud metrics, complaint resolution statistics, and regulatory correspondence. Board meeting minutes must reflect substantive discussion on compliance matters, not perfunctory acknowledgments.

Inspection and Audit Expectations

RBI retains the right to inspect payment aggregators at any time, either directly or through appointed agents. Inspections can be triggered by specific events (a data breach, customer complaints, or market intelligence) or as part of routine supervisory activity.

What Inspectors Examine

The critical point here is evidence. RBI inspectors do not accept verbal assurances or high-level policy documents as proof of compliance. They expect granular evidence: logs, timestamps, audit trails, acknowledgment records, and version-controlled documentation. Payment companies that rely on manual processes or scattered documentation across email threads and shared drives face significant risk during inspections.

Post-Inspection Remediation

Inspection findings typically come with remediation timelines. RBI tracks whether identified gaps are closed within the prescribed period. Failure to remediate findings can result in restrictions on operations, directions to wind down specific activities, or revocation of authorization in severe cases.

Common Compliance Gaps in Payment Companies

Having worked with compliance frameworks across regulated enterprises, certain patterns of non-compliance recur across payment companies. These are not always gaps in intent. More often, they result from fragmented systems, rapid growth outpacing compliance infrastructure, or insufficient clarity on regulatory expectations.

Incomplete Data Localization Implementation

Many payment companies achieve data localization for their primary systems but overlook ancillary systems. Analytics platforms, customer support tools, CRM systems, and marketing automation platforms that process transaction-related data may store information offshore. RBI’s mandate covers all payment system data, not just the core transaction database. A thorough data mapping exercise across the entire technology stack is essential to identify and remediate these gaps.

Inadequate Evidence Management for Audit Readiness

Payment companies often perform the required compliance activities (policy reviews, VAPT exercises, board reporting) but fail to maintain structured evidence repositories. When an RBI inspection occurs, the compliance team scrambles to locate artifacts across email archives, shared drives, and individual laptops. This creates both operational stress and the risk that legitimate compliance efforts cannot be demonstrated effectively.

This is precisely the problem that platforms like eQomply are designed to address. By consolidating evidence capture, policy attestation records, and audit trails into a unified system mapped to regulatory requirements, payment companies can maintain inspection-ready documentation as a byproduct of their daily compliance operations rather than as a separate exercise conducted under time pressure.

Settlement Timeline Violations During Disputes

The T+1 settlement obligation is straightforward in normal scenarios. Complications arise during merchant disputes, chargebacks, or fraud investigations where the PA may wish to withhold settlement. RBI’s guidelines provide limited flexibility here, and PAs must ensure that their dispute resolution processes do not inadvertently violate settlement timelines. Clear policies on withholding conditions, pre-approved by legal and compliance functions, are necessary.

Weak Ongoing Merchant Monitoring

Initial merchant due diligence is typically robust because it is part of the onboarding workflow. Ongoing monitoring, however, often degrades over time. Merchants may change their business model, start processing transactions in restricted categories, or exhibit suspicious patterns. Without automated monitoring systems that flag anomalies in merchant transaction behavior, PAs risk being found non-compliant with their ongoing due diligence obligations.

Cybersecurity Incident Reporting Delays

CERT-In mandates reporting cybersecurity incidents within 6 hours. RBI has its own reporting expectations for payment system operators. Payment companies sometimes lack clarity on which incidents trigger reporting obligations, who is authorized to report, and what constitutes a reportable event versus an internal security alert. This ambiguity leads to either over-reporting (creating noise) or under-reporting (creating regulatory risk). A defined incident classification matrix, pre-approved by the CISO and the compliance function, resolves this gap.

Policy Document Versioning and Attestation Gaps

RBI expects that policies are not just created but reviewed periodically, updated when regulations change, approved by appropriate authority, and attested by relevant stakeholders. Many payment companies have policies that are outdated, lack clear version histories, or cannot demonstrate that employees and board members have reviewed and acknowledged them. This is a documentation gap that is easily avoidable with the right compliance infrastructure in place.

Bringing It Together

RBI compliance for payment companies is a continuous discipline, not a periodic project. The regulatory framework is detailed, the obligations are multi-layered, and the consequences of non-compliance range from operational restrictions to authorization revocation. Payment aggregators operating at scale must invest in compliance infrastructure that matches the complexity of their regulatory environment.

The companies that manage this well share common characteristics: they have centralized compliance workflows mapped to specific RBI obligations, they maintain always-ready evidence repositories, they track circulars and regulatory changes systematically, and they ensure board-level visibility into compliance posture without relying on manual report compilation.

If your payment company is navigating these requirements and looking to consolidate your compliance operations into a system built for India’s regulatory landscape, it is worth exploring how eQomply supports payment companies in managing RBI obligations end to end. You can schedule a demo here to see the platform in the context of your specific compliance requirements.