RBI’s 2025 Payment Aggregator Directions: Operational Compliance Points Businesses Should Not Underestimate

1. RBI’s 2025 Payment Aggregator Directions: Operational Compliance Points Businesses Should Not Underestimate

For fintech and payment businesses, RBI’s 2025 Payment Aggregator Directions should not be read as a housekeeping document.

Yes, the directions consolidate earlier instructions. Yes, they bring online, physical, and cross-border payment aggregation into a more unified framework. But the real effect is operational. The directions force payment businesses to examine how they onboard merchants, hold and settle funds, classify payment flows, manage governance, and prove compliance.

This matters because payment aggregation is not only a technology business. It is a regulated trust business.

A payment aggregator sits between customers and merchants. It receives, routes, pools, settles, reconciles, monitors, and sometimes becomes the first point of friction when something goes wrong. If the compliance architecture is weak, the risk does not stay inside the legal department. It appears in merchant onboarding, settlement delays, escrow mismatches, fraud exposure, customer complaints, banking relationships, and regulatory scrutiny.

The first point businesses should not underestimate is authorisation.

The 2025 framework makes it important to classify the business correctly. Is the entity acting as PA-Online, PA-Physical, PA-Cross Border, or a combination? Is it a non-bank entity requiring RBI authorisation? Is it already authorised for one category and expanding into another? Is it operating physical point-of-sale aggregation that now needs to be brought within the formal authorisation discipline?

These questions cannot be answered casually by the product team after launch. They should be answered before the business model is scaled.

For fintech founders, this is especially important. A product may begin as a payment layer, checkout solution, marketplace settlement support, QR/POS enablement, or cross-border collection facility. But once the entity is facilitating aggregation of payments between customers and merchants, the regulatory character of the activity must be assessed.

The second point is capital and governance readiness.

Authorisation is not only about filing an application. Non-bank payment aggregators need to meet net-worth expectations and build governance structures that look more like a regulated financial-services business than a pure technology startup. That means board-level policies, risk oversight, fit-and-proper review, compliance ownership, internal controls, and operational accountability.

This can be a cultural shift.

Many fintech businesses move fast because product, sales, engineering, and merchant acquisition work closely. That speed is useful. But under a regulated PA framework, speed cannot come at the cost of control. The business should know who owns compliance, who approves merchant risk exceptions, who monitors settlement discipline, who handles regulatory reporting, and who escalates control breaches.

The third point is merchant due diligence.

\This may become the heaviest operational workload for many payment businesses.

Merchant onboarding is no longer only a commercial acquisition process. It is a risk-control process. Payment aggregators need to know who the merchant is, what 

business the merchant conducts, who beneficially owns or controls the merchant, whether the business model is permitted, whether there are higher-risk indicators, and whether ongoing monitoring is required.

The difficult part is not writing a merchant due diligence policy. The difficult part is applying it across the merchant base.

For new merchants, this means the onboarding workflow must collect and verify the right data before activation. For existing merchants, it means remediation. Legacy merchant records may be incomplete, inconsistent, outdated, or held across multiple systems. Some merchants may not respond quickly. Some may have changed business lines. Some may require enhanced checks. Some may need to be offboarded if compliance gaps remain unresolved.

This is where operations and compliance must work together. Compliance cannot remediate thousands of merchants alone. Sales cannot decide risk exceptions alone. Product cannot keep onboarding flows unchanged if new fields, validations, or approval gates are required.

The fourth point is escrow and settlement discipline.

For payment aggregators, escrow is not back-office bookkeeping. It is the core trust layer of the business. If funds are pooled, held, transferred, refunded, or settled incorrectly, the consequences can be serious.

Businesses should review their escrow account structure, permitted debits and credits, settlement timelines, reconciliation process, refund handling, nodal-bank coordination, chargeback treatment, and reporting trail. The finance team should be able to explain how every settlement cycle works. Operations should be able to show exceptions. Compliance should be able to see whether the process follows regulatory requirements.

A weak reconciliation process is not a finance inconvenience. It is a regulatory control weakness.

The fifth point is cross-border classification.

For businesses touching import, export, overseas merchants, Indian merchants receiving foreign payments, or Indian customers paying foreign merchants, PA-Cross Border treatment needs careful attention. The business must understand whether it is facilitating inward or outward cross-border payment aggregation, what current account transaction restrictions apply, how funds move, what merchant checks are required, and how banking partners are involved.

Cross-border payment businesses should avoid one common mistake: assuming that because a bank partner is involved, the fintech has no independent compliance responsibility. RBI’s direction of travel is clear. Payment businesses must know the regulatory character of the flow they facilitate.

The sixth point is technology and operational controls.

Payment aggregator compliance depends on systems. Merchant onboarding fields, risk flags, settlement reports, escrow reconciliation, transaction monitoring, refund controls, chargeback tracking, complaint records, and audit logs all need system support.

If the compliance team is maintaining manual trackers while the product system continues as before, implementation will be weak.

The right question is: what needs to change in the operating platform?

1. 1. Do merchant onboarding screens need new fields?

2. Does the approval workflow need maker-checker control?
3. Does the risk team need a review queue?
4. Does settlement reporting need new reconciliations?
5. Do old merchants need remediation status tags?
6. Can the system block activation where required documents are missing?
7. Can compliance retrieve records during inspection?

These are practical product and engineering questions, not just compliance questions.

The seventh point is deadlines.

The directions became effective immediately, but some requirements operate with transition timelines. That means businesses cannot wait for the last month to begin implementation. Authorisation, merchant remediation, escrow changes, policy approvals, system development, and bank coordination all take time.

A payment business should maintain a transition tracker with every applicable deadline, internal owner, system dependency, documentation requirement, and evidence status. The tracker should separately cover new merchants, existing merchants, PA-P authorisation or intimation, PA-CB classification, escrow changes, governance approvals, and reporting requirements.

The eighth point is evidence.

RBI compliance is not proved by saying the team has updated the process. The business should be able to show the file: authorisation application, board-approved policies, merchant due diligence records, risk assessments, escrow reconciliation, settlement reports, exception approvals, complaint handling records, outsourcing checks, system audit reports, and management review notes.

This is where many fintechs underprepare. They implement operational changes but fail to preserve evidence in a way that can be reviewed later. That creates problems during audits, bank reviews, investor diligence, or RBI queries.

The practical takeaway is simple.

The 2025 Payment Aggregator Directions convert a fragmented rulebook into a clearer regulatory architecture. But for payment businesses, clarity brings responsibility. Every entity must understand its PA category, authorisation status, merchant risk process, escrow discipline, settlement controls, cross-border exposure, governance structure, and transition deadlines.

The firms that handle this well will not treat the Master Direction as a legal memo. They will treat it as an implementation project.

For fintech and payment businesses, the immediate question should be:

Can we show how our payment aggregation business is authorised, controlled, monitored, reconciled, and evidenced?

If the answer is not clear, the compliance work is not finished.