Most PA license applications that stall do not stall because the RBI rejected them.
They stall because the RBI keeps asking questions. Clarification request after clarification request, each one adding four to eight weeks to a process that was already moving slowly.
The fintechs this happens to are not careless operators. They hire the right legal counsel, hit the net worth threshold, and put genuine effort into the submission. What they consistently underestimate is what the RBI is actually evaluating.
The RBI is not running a document review. It is running an operational maturity assessment. That distinction changes everything about how you should prepare.
The Master Directions on Payment Aggregators - issued in March 2020 and updated through 2025 - lay out a framework that most applicants misread as a financial eligibility test.
The Rs 15 crore net worth threshold is the entry condition. The actual review covers six dimensions: governance, technology, risk management, merchant onboarding, AML compliance, and operational resilience.
If your application demonstrates eligibility but not maturity across these six areas, the RBI will keep asking until it sees maturity. Most clarification cycles trace back to that gap.
This is the pattern. Not rejection. Delay by observation.
Ownership records, financial projections, org charts, and technology descriptions all get read together. When they tell different stories about the same organization, clarifications follow.
Each round adds four to eight weeks. A single inconsistency in a beneficial ownership declaration can stall an otherwise strong application.
Map every key fact across every document where it appears. Resolve every discrepancy before filing. Have someone read the full submission as if they have never met your company.
The RBI does not want a list of committee names. It wants evidence that those committees make decisions, document them, and report independently to the board.
Board minutes that address compliance risk. Internal audit covering payment operations. A compliance function that reports to the board - not to the revenue team.
Structure without function is a governance document. It is not governance.
A company confirms net worth, appoints the right directors, and files. Without having demonstrated operational capability across any dimension the RBI actually examines.
Eighteen months of genuine merchant risk monitoring looks different from sixty days of policy creation before submission. Regulators have seen both. They know which is which.
Plan your preparation timeline before you plan your filing date.
Secure payment processing is the floor, not the ceiling. The RBI goes further: authentication controls, privileged access management, encryption at rest and in transit, incident response aligned with CERT-In's six-hour mandatory reporting window, and PCI-DSS compliance for card-processing environments.
Self-assessed documentation carries less weight than an independent penetration test or ISO 27001 certification. Third-party validation addresses that credibility gap directly.
Regulators recognise borrowed risk policies. Banking frameworks adapted for payment operations. Enterprise templates with the logo changed.
A PA risk framework needs to address risks the PA model actually creates: settlement timing mismatches against escrow balances, merchant concentration exposure, accommodation merchant fraud, operational dependency on outsourced infrastructure. Risk appetite thresholds, escalation triggers, board reporting that connects to both. A policy that floats free of operational decisions is not a risk framework.
Strong onboarding documentation is common. Ongoing monitoring frameworks are not.
The RBI wants to understand how merchant risk is managed throughout the relationship, not just verified at entry. Under PMLA rules, beneficial ownership verification applies where a natural person holds 25% or more of equity. Higher-risk sectors - online gaming, digital lending outside the RBI framework, pharmaceutical e-commerce, foreign exchange - require enhanced due diligence and documented periodic review.
The gap regulators find most often: meticulous onboarding, invisible ongoing monitoring. Payment aggregators that invest in continuous merchant monitoring infrastructure before filing - with alert histories, escalation trails, and documented review decisions already running - produce substantially more convincing applications. Not because the documentation looks better. Because the operations are actually working.
The Master Directions require PAs to hold merchant settlement balances in an escrow account with a scheduled commercial bank - segregated from operating funds, released within defined timelines, and never used for the PA's own operational purposes.
Naming the bank is not enough. Regulators want daily reconciliation procedures, settlement authorisation controls, and a documented exception management process for discrepancies. The arrangement described without the surrounding control framework is an incomplete answer.
Payment aggregators are reporting entities under the Prevention of Money Laundering Act, 2002. That is statutory and exists independently of the PA licensing framework.
An AML policy filed as a standalone document - disconnected from merchant onboarding procedures and transaction monitoring systems - signals that compliance exists on paper rather than in practice.
A Principal Officer must be formally designated for FIU-IND reporting. Transaction monitoring scenarios must reflect merchant-level fraud patterns. STR filing procedures must have clear internal escalation paths. Siloed compliance produces siloed applications.
The connection the RBI is looking for is an operational loop: fraud signals that reach the compliance officer, decisions that get documented, STRs that get filed because a system surfaced the pattern. Connected fraud and AML investigation infrastructure is what turns a compliance policy into a compliance operation.
Cloud providers, payment gateways, KYC vendors, fraud detection platforms - the regulator does not penalise outsourcing. It penalises the absence of oversight.
Material vendor contracts should preserve the RBI's right of access, define service levels, and specify exit arrangements for vendor failure. Concentration risk - all KYC through one vendor, all processing through one gateway, no documented alternatives - raises resilience questions most applicants do not anticipate until the observation arrives.
Recovery time objectives, backup infrastructure, incident communication protocols - all documented, none tested.
Annual disaster recovery testing is the minimum. Semi-annual is a stronger signal for critical payment infrastructure. Test records matter: what was tested, what it revealed, how gaps were closed. The element most commonly missing is merchant communication - a plan that restores systems without addressing how merchants are notified during an outage is incomplete.
Policies with no version history. Training records dated only to the application period. AML programs with no prior STR filings or transaction monitoring alert history.
These are recognisable signals. Regulators have seen retrospective documentation many times before. Six to twelve months of real compliance activity before filing is a realistic window. Sixty days produces documentation. It does not produce maturity.
A structured pre-submission assessment is the most cost-effective investment available to a PA applicant. It should examine five things: documentary completeness, regulatory alignment, operational evidence beyond policy documents, governance demonstration through actual decisions and escalations, and narrative coherence across the full submission.
Most reviews surface three to seven gaps. Closing them before filing is faster than responding to RBI observations after. Every time.
The RBI PA license is not the end of a project. It is the beginning of an ongoing compliance obligation - continuous merchant monitoring, connected fraud and AML signal management, and audit-ready investigation records for every risk decision made by your team.
At Verafye, we built our platform specifically for payment aggregators, PSPs, and regulated fintech platforms operating under exactly this kind of scrutiny. The platform connects your merchant risk signals, transaction surveillance, fraud alerts, and AML workflows into one investigation-ready platform - with full audit trails that satisfy both operational and regulatory requirements.
What that means practically: when a merchant risk pattern surfaces in transaction monitoring, it connects to the AML review queue. When an investigation is opened, the case context is already assembled from across your signal sources. When an examiner asks for the investigation trail, it exists - in one place, traceable from the original signal through to the documented decision.
If you are building toward the RBI PA license and want to understand how your current risk signal coverage compares to what the RBI expects to see, the Verafye Risk Shadowing Review is a practical starting point - a scoped pilot that surfaces network risk gaps across your existing signal coverage. No commitment required.
The RBI is not asking whether your documents are in order.
It is asking: if we grant this license and something goes wrong - a merchant fraud, a settlement failure, a cybersecurity incident - does this organisation have the governance, the controls, and the operational maturity to have caught it, contained it, and reported it?
Every document in your application is evidence toward or against that answer.
Applications that understand this question answer it well. Applications that treat the process as a compliance checklist generate the clarification cycles that turn a six-month process into a fourteen-month one.
File when you are ready to answer the actual question. Not before.
Abhishek Tuppada
Founder & CEO, Verafye
Verafye is a graph-native network risk intelligence platform built for lean fraud, AML, and risk teams at payment aggregators, PSPs, MSBs, and regulated fintech platforms.
See where your monitoring stack has blind spots
The Risk Shadowing Review maps your current coverage against relationship-level gaps.
