RBI Compliance for Payment Aggregators: What Custom Software Teams Need to Architect For

TL;DR: RBI's consolidated 2025 Master Direction on Payment Aggregators reshaped the compliance bar for anyone touching merchant settlement in India, with several deadlines landing squarely in 2026 — including a September 15, 2026 cutoff for re-verifying merchants onboarded before the new due diligence rules took effect. This isn't primarily a legal or finance exercise; most of the actual requirements — escrow-based fund flows, T+1 settlement, data localization with 24-hour foreign-copy purging, PCI-DSS certification, and layered KYC — are architecture and engineering decisions. This guide walks through what a compliant payment aggregator stack actually has to look like, where teams most often get the technical details wrong, and the deadlines that make this a 2026 priority rather than a someday project.

Why this matters now, not eventually

The RBI's regulatory history with payment aggregators has moved from light-touch guidance to a full consolidated Master Direction, issued in 2025, that draws a sharp regulatory line between a Payment Aggregator (PA), which actually handles and settles funds, and a Payment Gateway (PG), which is purely the technical conduit for transaction data and never touches money (FIDC India Master Direction PDF; PhonePe Business). That distinction matters because it determines which set of rules — and which architecture requirements — apply to your platform.

The deadlines are not distant. Non-bank PAs that failed to submit their license application by December 31, 2025 were required to wind down PA operations by February 28, 2026. Separately, the RBI granted an extended window until September 15, 2026 for PAs to complete re-verification of merchants onboarded before December 31, 2025 under the new, stricter due diligence requirements — a leeway that does not extend to any merchant onboarded after January 1, 2026 (AuthBridge). For any team maintaining a merchant onboarding pipeline right now, that September deadline is the operational crunch point of the year.

The core architectural requirements

1. Escrow-based fund flow, not a shared operating account

This is the single most consequential architectural requirement in the Master Direction, and it's the one that most fundamentally changes how a payment aggregator's backend has to be designed. All non-bank PAs must maintain merchant and customer funds in an escrow account held with a Scheduled Commercial Bank — separate from the PA's own operating capital entirely (IncorpX). When a customer pays a merchant through the PA's platform, the funds flow into this escrow account, not into the PA's current account, and the PA then settles the net amount (after its commission) to the merchant's bank account within T+1 working day (IncorpX).

For engineering teams, this means the ledger and reconciliation system has to model at least three distinct money states — funds in escrow pending settlement, PA commission accrual, and merchant payout — with strict segregation enforced at both the database and the actual bank-account level. Cross-border transaction funds must additionally be held in a separate escrow account from domestic transaction funds, and inward and outward transaction funds must be kept segregated within that structure (PhonePe Business). A reconciliation engine that can't cleanly distinguish these fund states at any point in time is a compliance failure waiting to surface during an audit, not just a bookkeeping inconvenience.

2. Net worth and capital adequacy — a finance requirement with architecture implications

Non-bank PAs must demonstrate a minimum net worth of ₹15 crore at the time of licence application, rising to ₹25 crore by the end of the third financial year after authorization (AuthBridge; IncorpX). While this is fundamentally a finance and legal requirement, it has a direct engineering consequence: your platform needs reliable, auditable financial reporting infrastructure capable of demonstrating net worth calculations on demand for regulatory review, not just internal management reporting.

3. Merchant KYC and due diligence, layered by classification

Every merchant onboarded through a PA must complete KYC before going live, with onboarding flows required to collect business registration documents, PAN, GST registration, bank account proof, and beneficial ownership details (Business PhonePe). PAs are classified as either PA-O (Online) — covering e-commerce and app-based transactions where payment and acceptance aren't in physical proximity — or PA-P (Physical/Offline) — covering face-to-face or proximity-based payment flows — with each classification carrying its own specific requirements around net worth, KYC depth, and escrow handling (IncorpX).

For engineering teams, this means the merchant onboarding flow needs configurable due diligence depth based on merchant classification and risk profile, document verification and storage that meets data localization rules (see below), and — critically, given the September 2026 deadline — a mechanism to re-run due diligence against the new rules for every merchant onboarded before the cutoff, not just new merchants going forward.

4. Data localization: stricter than most teams initially assume

The 2025 Master Direction enforces what several legal analyses describe as effectively 100% data localization for payment data, with a specific and unusually strict operational detail: any foreign copies of transaction or merchant data must be purged within 24 hours of processing (Strobes). This is significantly tighter than a general "store data in India" requirement — it implies active monitoring and automated deletion workflows for any data that transiently touches infrastructure outside India, which is a common blind spot for platforms using global CDNs, international payment processor integrations, or cloud services with cross-region replication enabled by default.

Architecturally, this means: primary data storage and processing infrastructure located in India, explicit audit logging of any cross-border data movement (even transient, such as through a third-party fraud-scoring API hosted abroad), and automated purge jobs — not manual processes — enforcing the 24-hour deletion window.

5. PCI-DSS certification as a prerequisite, not a post-launch task

PCI-DSS (Payment Card Industry Data Security Standard) certification is required for handling payment card data securely, and — importantly — it functions as a prerequisite for licensing, not something a PA can obtain after launch while operating under a provisional status (Strobes). Teams that treat PCI-DSS as a certification to pursue in parallel with launch, rather than a gate that must clear before go-live, consistently underestimate both the timeline (a proper PCI-DSS assessment typically takes months, not weeks) and the architectural changes it can force late in a build — such as network segmentation for the cardholder data environment that's far more expensive to retrofit than to design in from the start.

Compliance requirements at a glance

Where teams get this wrong

The most common architectural mistake is designing the fund-flow ledger around a single "merchant balance" abstraction that doesn't cleanly distinguish escrow-held funds from settled funds from PA commission — this works fine until an audit or a dispute forces a precise accounting of exactly where a given rupee sits at a given moment, and a poorly segmented ledger can't answer that cleanly.

The second most common mistake is treating data localization as a storage-location question rather than a data-lifecycle question. Storing the primary database in an Indian data center satisfies part of the requirement, but the 24-hour foreign-copy purge rule requires actively tracking every place data might transiently land — third-party APIs, logging pipelines, backup replication — which is a monitoring and governance problem, not just an infrastructure placement decision.

The third is underestimating the September 15, 2026 re-verification deadline. For a PA with an established, sizable merchant base, re-running due diligence on every merchant onboarded before December 31, 2025 under the new rules is a significant operational lift if the onboarding pipeline wasn't built with a "re-verify at scale" mode from the start. Building that capability now, rather than in Q3 2026 under deadline pressure, is meaningfully cheaper.

Enforcement is not theoretical — the RBI has already levied penalties for escrow-related and PPI-norm violations against major players, a reminder that compliance gaps surface in audits and get penalized in practice, not just in principle (Business Standard).

Where Syslabs fits in

Building or re-architecting a payment aggregator platform to meet these requirements touches ledger design, merchant onboarding workflows, data localization infrastructure, and security architecture — usually all at once, and usually against a hard regulatory deadline. Syslabs works with fintech teams on exactly this kind of build: designing escrow-compliant fund-flow ledgers, building merchant KYC and re-verification pipelines that can scale to an existing merchant base, and architecting data localization and PCI-DSS-ready infrastructure from the ground up. If your team is facing the September 2026 re-verification deadline or planning a new PA platform from scratch, it's worth getting an architecture review now rather than discovering gaps during a regulatory audit.

Conclusion

RBI's consolidated Master Direction turned what used to be a patchwork of payment aggregator guidance into a specific, testable set of architectural requirements — escrow segregation, T+1 settlement, layered KYC, strict data localization, and pre-launch PCI-DSS certification. None of these are optional add-ons to bolt on after a platform is live; each shapes core decisions in ledger design, data infrastructure, and onboarding workflows that are expensive to retrofit. With the September 2026 merchant re-verification deadline approaching, teams operating an existing PA platform have a concrete, dated reason to audit their architecture against these requirements now.

Sources

• RBI Master Direction on Payment Aggregators (via FIDC India)
• PhonePe Business — RBI Approved Payment Gateway Compliance Rules
• AuthBridge — RBI's Updated Guidelines for Payment Aggregators 2025
• IncorpX — RBI Payment Aggregator Licence Guide 2026
• Strobes — RBI Guidelines for Payment Aggregators and Payment Gateways
• Business Standard — RBI fines PhonePe for escrow shortfall

A practical implementation checklist for engineering teams

Given how many of these requirements touch core system design rather than surface-level configuration, it helps to work through them as a concrete checklist during architecture review, rather than treating "RBI compliance" as a single monolithic workstream:

Ledger and settlement:

• Does your data model represent at least three distinct fund states (escrow-held, settled, commission-accrued) with clear, auditable transitions between them?
• Can your system produce a point-in-time report showing exactly where every rupee in the platform currently sits, broken down by merchant and transaction?
• Is cross-border transaction escrow fully separated — at the bank-account level, not just the application layer — from domestic escrow?
• Does your settlement engine reliably hit T+1 even under peak transaction volume, with clear alerting if a settlement batch is at risk of missing the window?

Merchant onboarding and KYC:

• Can your onboarding flow adjust due diligence depth based on PA-O versus PA-P classification and merchant risk profile?
• Do you have a dedicated re-verification pipeline that can process your existing merchant base against the new due diligence rules, distinct from your standard new-merchant onboarding flow?
• Is document storage (PAN, GST, bank proof, beneficial ownership records) encrypted, access-controlled, and localized per the data residency rules?

Data localization:

• Have you mapped every system — including third-party integrations like fraud scoring, analytics, and customer support tools — that could cause payment data to transiently leave India?
• Do you have automated (not manual) purge jobs enforcing the 24-hour foreign-copy deletion window, with logging to prove compliance during an audit?
• Are backup and disaster recovery systems included in your data localization architecture, or are they a gap?

Security and certification:

• Is your cardholder data environment segmented from the rest of your infrastructure in a way that will hold up to a formal PCI-DSS assessment?
• Have you scheduled PCI-DSS certification early enough in your build timeline that it functions as a design constraint rather than a late-stage blocker?

How this compares to payment gateway (PG) obligations

It's worth being explicit about where PG obligations differ from PA obligations, since teams building a pure payment gateway sometimes over-build compliance infrastructure meant for aggregators, or conversely underestimate their own requirements if they cross the line into fund handling. A pure PG — one that only routes transaction data and never touches settlement — is not subject to the escrow and net worth requirements described above, since those exist specifically because a PA holds and moves customer and merchant funds. However, a PG still needs to meet data security and PCI-DSS obligations for the payment data flowing through it, and the moment a "gateway" product starts consolidating merchant funds or managing settlement — even informally, as a convenience feature — it has functionally become a Payment Aggregator in the RBI's eyes and needs to meet the full PA compliance bar, regardless of how the product is marketed. This is a genuinely common trap: a product team ships a "payment gateway" that quietly grows fund-holding functionality over successive releases without anyone flagging that the regulatory classification — and the corresponding architecture requirements — has shifted underneath them.