Payment Bank, Payment Gateway & Wallet Licensing

A Payment Gateway is purely a technology layer that routes and encrypts transaction information between the customer, the merchant's website, and the banks involved — it never takes custody of the actual funds. A Payment Aggregator, by contrast, receives the customer's payment into an account it controls (a nodal or escrow account) and then settles the net amount to the merchant after deducting fees. Because a Payment Aggregator briefly holds customer funds, RBI treats it as a payment system operator requiring authorisation under the PSS Act. A pure Payment Gateway that never touches funds generally falls outside that specific authorisation requirement — but in practice, most commercial payment processing platforms in India combine both functions, which brings the combined entity within PA regulation.

Yes, if you are a non-bank entity issuing the instrument. Prepaid Payment Instruments (PPIs) — which include digital wallets, prepaid cards, and gift cards that store value for future purchases or fund transfers — require a Certificate of Authorisation from the RBI under the PSS Act, granted per the Master Directions on Prepaid Payment Instruments. Banks can issue PPIs without a separate authorisation because they are already RBI-regulated entities, but a non-bank fintech or NBFC building a wallet product from scratch must obtain PPI authorisation before issuing instruments to customers, or partner with an already-authorised PPI issuer under a co-branding arrangement.

Technically the framework exists, but practically this is the most constrained licensing category PNPC advises on. RBI issued its Payments Bank licensing guidelines in November 2014 and granted licences to a limited cohort of applicants from that process; RBI has not run a continuous, always-open application window for new Payments Bank licences since. Policy toward new differentiated bank licences is periodically reviewed by RBI, and any prospective applicant should treat this as a multi-year strategic question rather than a routine application process. In most cases, promoters seeking similar commercial outcomes (deposit-like products, payments and remittance services) achieve them faster through a Business Correspondent arrangement with an existing bank, a PPI authorisation, or an NBFC structure.

RBI prescribes a minimum net worth at the time of application, with a requirement to reach a higher, escalating net worth figure within a specified number of financial years thereafter — this structure is designed to ensure only adequately capitalised entities remain authorised as they scale. Because these prescribed figures are revised periodically through RBI Master Direction updates and circulars, PNPC always verifies the current applicable figures directly against the live RBI Master Direction at the time of your engagement rather than relying on a fixed number from a prior year — quoting an outdated threshold is one of the most common errors we see from advisors who have not kept pace with RBI's updates.

A nodal account (used interchangeably with escrow account in RBI's payment aggregator framework) is a special bank account maintained with a scheduled commercial bank, into which customer payments are received and from which merchant settlements are made, under terms that RBI prescribes to prevent the Payment Aggregator from co-mingling customer funds with its own operating funds or earning undue benefit from holding customer money. RBI mandates this structure specifically to ring-fence customer and merchant funds from the operational or insolvency risk of the Payment Aggregator itself.

Section 4 of the Payment and Settlement Systems Act, 2007 prohibits operating a payment system in India without RBI authorisation, and Section 26 of the PSS Act prescribes penal consequences for contravention, including fines and, in specified circumstances, imprisonment for persons responsible for the contravention. Beyond the direct statutory exposure, an unauthorised operator faces practical business risk: banking partners typically require confirmation of RBI authorisation status before enabling nodal accounts or settlement rails, and investors conduct regulatory due diligence that will surface unauthorised operation as a material finding, commonly a deal-breaker or valuation-reducing issue.

There is no fixed statutory timeline — this is a regulator-paced process. In PNPC's experience, a well-prepared application with adequate governance, net worth, and technology documentation in place typically runs 6–12 months from initial filing to final Certificate of Authorisation, factoring in RBI's query and clarification cycles. Applications with governance or documentation gaps take considerably longer, as each query round can add several weeks. Building the governance and compliance infrastructure before filing — rather than filing early and fixing gaps reactively — is consistently the faster overall path.

Yes, subject to standard FDI and FEMA compliance for the sector, and subject to RBI's promoter fit-and-proper evaluation applying equally to foreign promoters. Foreign investment in payment system operators is permitted under the FDI framework applicable to the relevant category, though specific conditions (including the Press Note 3 (2020) government-route requirement for investment from entities with beneficial ownership in a country sharing a land border with India) must be checked against the current promoter and shareholding structure. PNPC's Chennai, Bangalore, Hyderabad, and Dubai offices allow us to coordinate India entity structuring, FEMA/FDI compliance, and the RBI authorisation application under one engagement for foreign or NRI promoters.

PA-CB (Payment Aggregator – Cross Border) is the framework RBI introduced via its November 2024 circular extending payment aggregator-style regulation specifically to entities facilitating cross-border payment collections for the import and export of goods and services. If your Payment Aggregator business is expanding into, or already handles, cross-border transaction collection — for example, enabling Indian exporters to collect payments from overseas buyers, or Indian consumers to pay overseas merchants — this framework's specific eligibility and authorisation conditions apply in addition to, or in place of, standard domestic PA authorisation, depending on your existing licensing status.

Yes. RBI requires a system audit report from a CERT-In (Indian Computer Emergency Response Team) empanelled auditor as part of the application, covering the technology architecture, data security controls, and business continuity arrangements of the payment system. This audit examines whether the platform meets RBI's expected security and resilience standards — encryption in transit and at rest, access controls, incident response readiness, and data localisation compliance among other areas.

Yes, and it is one of the most operationally significant requirements for any payment system operator. RBI's April 2018 circular on the storage of payment system data requires that the entire data relating to a payment system — the full end-to-end transaction details, and any payment system data collected, carried, or processed as part of the transaction — be stored only in systems located within India. Any foreign leg of the transaction data may be stored abroad in addition to, but not instead of, the mandatory Indian copy. This requirement affects technology architecture decisions from day one — a global SaaS payments platform designed with servers only in another jurisdiction cannot simply add an India authorisation later without a material architecture change.

Yes, subject to obtaining the specific PA or PPI Certificate of Authorisation separately from its NBFC registration — an NBFC licence to carry on non-banking financial business does not itself authorise payment system operation. Many NBFCs pursue a combined lending-plus-payments strategy (for example, a consumer NBFC that also issues a co-branded PPI or wallet), but each regulated activity requires its own specific authorisation and ongoing compliance, and RBI evaluates the group's overall risk and governance posture across both when assessing a combined application.

Ongoing obligations typically include: periodic system audit reports (commonly annual) from a CERT-In empanelled auditor, annual net worth certification confirming continued compliance with the prescribed and escalating threshold, transaction data and MIS returns to RBI's Department of Payment and Settlement Systems in the prescribed format, maintenance of the escrow/nodal account per RBI's conditions, and prior intimation or approval for material changes such as a change in control, shareholding, or business model. RBI also conducts periodic supervisory inspections of authorised payment system operators.

RBI's PPI Master Direction prescribes tiered KYC requirements depending on the type and maximum value of the PPI. Minimum-detail PPIs (issued with limited KYC, typically OTP-based verification for small-value instruments) carry lower balance and usage limits, while full-KYC PPIs — where the customer's identity is verified per RBI's KYC Master Direction, typically through Aadhaar-based e-KYC or equivalent — permit higher balances and broader usage including fund transfers. Issuers must build KYC tiering into the product from the outset, since retrofitting a KYC framework onto an already-scaled wallet customer base is a significant operational undertaking.

No — RBI authorisation under the PSS Act operates at the central, national level; there is no state-by-state payment system licensing requirement. However, GST registration is required in each state where the entity has a fixed place of business or crosses the relevant threshold, and this is a separate, unrelated compliance requirement from the RBI payment system authorisation. Founders sometimes conflate the two — GST is a tax registration, RBI authorisation is a sectoral regulatory licence, and they follow entirely independent processes.

Interoperability refers to the ability of a customer to use their PPI (wallet) balance to transact with, or transfer funds to, instruments or accounts issued by other providers — for example, transferring wallet balance to a bank account via UPI, or between wallets issued by different providers. RBI's PPI Master Direction has progressively mandated interoperability for full-KYC PPIs through UPI and card networks, moving away from the earlier closed-loop wallet model where funds could only be used within the issuer's own ecosystem. PPI issuers must build interoperability into their technology architecture and settlement arrangements as a compliance requirement, not merely a product feature.

RBI's PPI framework historically classified instruments as closed system (usable only for goods/services from the issuer itself, such as a single retailer's gift card — generally outside the need for RBI authorisation since no third-party payment or cash withdrawal function exists), semi-closed system (usable at a group of clearly identified merchant locations under contract with the issuer, but not for cash withdrawal — the most common wallet type, requiring RBI authorisation), and open system (usable at any merchant for goods/services and permitting cash withdrawal, typically issued only by banks). The classification determines both the authorisation requirement and the permissible use cases and limits.

Yes, and this is a common and often commercially sensible path — a co-branding or program manager arrangement with an already RBI-authorised PPI issuer allows a startup to offer a wallet or prepaid-instrument feature to its customers without independently obtaining RBI authorisation, since the licensed partner remains the regulated entity issuing the instrument and bearing the compliance obligations. The trade-off is reduced control over product features, commercial terms, and the underlying compliance posture, since these remain governed by the licensed partner's own risk appetite and RBI relationship.

RBI-authorised payment system operators — including PAs and PPI issuers — are 'reporting entities' under the Prevention of Money Laundering Act, 2002, obligated to maintain records of specified transactions and report suspicious transactions, cash transactions above prescribed thresholds, and certain other transaction categories to the Financial Intelligence Unit-India. This runs alongside, and is enforced in parallel with, RBI's own supervisory framework — a payment system operator's AML/CFT (Counter Financing of Terrorism) compliance is scrutinised both by RBI during inspections and can independently attract FIU-IND action for reporting failures.

PNPC scopes and quotes this engagement based on the specific authorisation sought (PPI, PA, PA-CB, or Payments Bank feasibility), the promoter group's current readiness (existing governance and technology maturity versus a from-scratch build-out), and whether the engagement covers the full application lifecycle or a defined phase (such as classification and feasibility only, versus full application management through to authorisation). We provide a written scope and fee proposal before any engagement begins — this is not a service PNPC prices as a flat, one-size-fits-all package given the material variation in starting readiness between applicants.

Many fintech-focused consultancies are strong on technology architecture and product strategy but do not have the underlying Chartered Accountancy, FEMA/FDI, and corporate law depth that an RBI application actually requires — net worth certification, promoter due diligence documentation, escrow account structuring, and the ongoing statutory compliance calendar all sit squarely in CA-firm territory, not pure technology consulting. PNPC combines both: we understand the payment system technology and business model questions well enough to classify your product correctly, and we have the CA-firm infrastructure to certify net worth, structure FDI-compliant shareholding, and manage the RBI relationship as an ongoing regulatory matter — not just get you to the application filing.

A typical full-scope engagement includes: business model classification and authorisation-category determination, feasibility assessment (particularly important for Payments Bank enquiries), promoter and group due diligence readiness review, corporate governance and policy documentation build-out, net worth structuring and capital-raise sequencing advisory, escrow/nodal account coordination with a scheduled commercial bank, technology and CERT-In system audit coordination, application compilation and filing, RBI query response management through to authorisation, and post-authorisation compliance calendar setup. The exact scope is confirmed in writing before engagement based on your specific starting point.

The Companies Act itself does not prohibit a virtual or shared office address as a registered office, and RBI's payment system authorisation guidelines do not separately mandate a specific type of premises. In practice, however, RBI's promoter and operational due diligence for PA/PPI applications does examine the substance of the applicant's operational infrastructure — a registered office alone with no demonstrable operational capability (staff, systems, governance function) raises questions during the fit-and-proper and technology review stages, even if the address itself is not disqualifying.

A Business Correspondent (BC) is an agent appointed by a licensed bank to provide banking services — account opening, cash deposit/withdrawal facilitation, remittances — on the bank's behalf in locations or customer segments the bank does not serve directly, under RBI's BC guidelines. Operating as a BC does not require the agent itself to hold an RBI payment system or banking authorisation, because the BC acts under the principal bank's licence and supervision. For promoters seeking a payments and financial-inclusion-style business model without pursuing the demanding and largely closed Payments Bank licensing route, a BC partnership with an existing bank is frequently the faster, lower-capital commercial path to a similar customer-facing proposition.

Certificates of Authorisation issued under the PSS Act are not typically granted for a fixed expiry date in the way some other statutory licences operate, but they remain conditional on continuous compliance with the authorisation conditions, and RBI retains the power to suspend or cancel an authorisation for non-compliance under the PSS Act. In practice, this makes ongoing compliance — not a renewal date — the operative discipline: an authorisation that is technically perpetual can still be revoked at any point if the operator falls out of compliance with net worth, reporting, or governance conditions.

RBI structures net worth requirements for PA and PPI authorisation as an initial threshold at application, rising to a higher figure within a prescribed number of subsequent financial years, rather than a single flat number, because it wants applicants to demonstrate a credible entry-stage capital base while also committing to build institutional-grade capital adequacy as transaction volumes and systemic importance grow. This mirrors a broader RBI regulatory philosophy applied across NBFC and payment system categories — proportionate initial entry barriers paired with escalating requirements tied to scale and maturity.

Following RBI's November 2024 circular, entities facilitating cross-border payment collection for the import or export of goods and services are brought within the PA-CB (Cross Border) framework, which imposes its own eligibility and authorisation conditions distinct from, or in addition to, domestic PA authorisation depending on the entity's existing status. An entity handling meaningful cross-border collection volume without assessing PA-CB applicability risks operating outside the scope of its existing domestic authorisation for that specific cross-border activity.

FEMA governs the cross-border capital flow dimension — any foreign investment into the applicant entity (FDI via share allotment, reported through FC-GPR), any foreign shareholder or promoter, and any cross-border fund flow the payment system itself facilitates, are all subject to FEMA in addition to the PSS Act authorisation for the payment system activity itself. These are two distinct and separately-administered regulatory frameworks — RBI's Department of Payment and Settlement Systems oversees the PSS Act authorisation, while FEMA compliance (FDI reporting, sectoral caps, pricing guidelines) is assessed against the RBI's separate foreign exchange regulatory framework, even though both ultimately sit within the RBI as regulator.

In PNPC's experience, the most common causes are: governance and policy documentation that exists only as templates without operational substance behind them, net worth or capital structure that does not hold up under RBI's specific computation method, escrow/nodal account arrangements that do not conform to RBI's prescribed terms, and incomplete or inconsistent promoter due diligence disclosure that raises fit-and-proper concerns during review. Technology and system audit gaps are also common, particularly around data localisation compliance and business continuity planning.

Yes — this is a specific strength of PNPC's structure. With an operating office in Dubai alongside Chennai, Bangalore, and Hyderabad, we coordinate the full engagement for UAE-based fintech and payments companies entering India: Indian subsidiary incorporation, FEMA/FDI structuring and FC-GPR reporting for the capital inflow, RBI payment system authorisation (PA, PPI, or PA-CB as applicable), and the India-UAE tax and DTAA considerations for the group structure — as one coordinated engagement rather than a UAE advisor and an unconnected Indian advisor working in isolation from each other.

This depends on the actual structure of your fund flow, not simply on whether merchants are 'third party' in a legal sense. If your marketplace collects customer payment into an account it controls before paying out to sellers or service providers on the platform — even if those sellers are onboarded directly onto your own marketplace rather than being external clients of a separate payment product — that fund flow can itself constitute Payment Aggregator activity requiring RBI authorisation, because RBI's PA/PG guidelines look at the substance of the payment collection and settlement mechanism, not merely the commercial label of the underlying marketplace relationship.

RBI does not always issue a formal rejection on record; in many cases, where an application has material gaps, RBI's DPSS will informally indicate the application is unlikely to succeed in its current form, giving the applicant the option to withdraw and reapply once the gaps are addressed, rather than carrying a formal rejection in its regulatory history. Where a formal rejection does occur, reapplication is possible, but the applicant should expect heightened scrutiny on a subsequent attempt, making it especially important to remediate the specific issues that led to the earlier outcome rather than reapplying with only cosmetic changes.

RBI's Department of Payment and Settlement Systems issues circulars, Master Direction amendments, and FAQs on an ongoing basis — the PA/PG guidelines alone have been substantively updated multiple times since their original 2020 issuance, most recently with the PA-CB framework in November 2024. PNPC's FEMA/RBI advisory team tracks DPSS circulars as part of standing practice, and retainer clients receive proactive advisories when a regulatory change affects their specific authorisation or business model, rather than discovering the change only when it affects an inspection or filing.