On September 15, 2025, the Reserve Bank of India issued its comprehensive Master Direction on Regulation of Payment Aggregators. It replaced every previous guideline on PA regulation with a single, binding document.
Most of the industry commentary focused on one thing: the January 1, 2026 onboarding deadline. From that date, every new merchant must be onboarded under full due diligence requirements without exception.
That deadline has passed.
What has received considerably less attention is what the document actually requires from a payment aggregator’s merchant compliance infrastructure — not just at onboarding, but continuously, at scale, and in a form that a CERT-In empanelled auditor can evaluate.
This post is a precise reading of those requirements. Not a summary. Not a commentary. A clause-by-clause breakdown of what the RBI is now asking for and what it means operationally for every licensed PA in India.
What the Document Actually Says
The Ongoing Monitoring Mandate
The clause that changes everything is not the onboarding deadline. It is Chapter IV, Clause 13(h):
“The PA must also monitor transactions subsequently undertaken by the merchants to ensure that these transactions are in line with the latter’s business profile and ensure adherence to other aspects of MD on KYC while conducting its operations.”
Read that carefully. This is not a one-time check at onboarding. This is a continuous obligation. A merchant’s business profile is declared on their website — their stated products and services, their refund policy, their terms of business, their grievance mechanism. If that profile changes after onboarding, the PA is required to detect it and act on it.
A merchant who onboarded as a clothing retailer and starts processing payments for a different category has a changed business profile. A merchant whose refund policy disappears from their website has a changed compliance posture. A merchant whose terms page returns a 404 has a documentation gap that affects the PA’s due diligence record.
None of this is visible without continuous monitoring of the merchant’s web presence. And at the scale that licensed PAs operate — hundreds of thousands of merchants — none of this is possible manually.
The Background and Antecedent Obligation
Chapter IV, Clause 13(c) states:
“A PA shall undertake background and antecedent check of the merchant.”
The present tense is deliberate. This is not “shall have undertaken at onboarding.” It is an ongoing obligation. Background and antecedent includes the merchant’s digital presence — their website, their stated policies, their compliance posture as represented on their web assets.
A merchant whose website was compliant at onboarding and whose website has materially changed six months later represents a changed antecedent. The PA’s obligation to that merchant does not end at the point of approval.
The Onboarding Security Baseline
Annexure 1 of the Master Direction, Clause 1.4 states:
“The entities shall undertake comprehensive security assessment during merchant onboarding process to ensure these minimal baseline security controls are adhered to by the merchants.”
Comprehensive security assessment at onboarding includes review of the merchant’s website infrastructure — PCI-DSS compliance signals, data handling declarations, policy page validity, and terms standing. This is a baseline requirement, not a recommended best practice.
Clause 1.18 adds:
“Payment applications shall be developed as per PA-DSS guidelines and complied with as required. The entities shall review PCI-DSS compliance status as part of merchant onboarding process.”
The merchant’s website is the surface on which these signals are most directly observable. A payment aggregator whose onboarding process does not include structured website compliance assessment is not meeting the baseline Annexure 1 requires.
The Annual Audit Requirement
Chapter III, Clause 9(d) states:
“An annual system audit, including cyber security audit, conducted by CERT-In empanelled auditors shall be carried out and report thereof shall be submitted to the respective Regional Office of DPSS, RBI.”
This audit covers the PA’s merchant onboarding and monitoring systems. A CERT-In empanelled auditor evaluating a PA’s merchant compliance stack will ask: how are merchants assessed at onboarding, how are they monitored after onboarding, and what documentation exists to demonstrate both.
If the answer is a manual process assembled by an ops team in the weeks before the audit, that is what the auditor evaluates. If the answer is a continuously-generated, timestamped, structured compliance record for every merchant, that is a different conversation entirely.
The audit is annual. The requirement is continuous. These two facts together define the compliance infrastructure problem precisely.
The January 2026 Hard Deadline
Chapter IV, Clause 13(j) states:
“A PA, including an existing PA whose application is pending with Reserve Bank of India for authorisation, shall ensure that merchants onboarded till December 31, 2025, comply with the above due diligence requirements within one year from the date of this MD. From January 1, 2026, merchants should be onboarded in accordance with due diligence requirements prescribed in this MD.”
The deadline for new merchants has passed. Every merchant onboarded from January 1, 2026 must meet full due diligence requirements at the point of onboarding. Every merchant onboarded before that date must meet the same requirements by September 15, 2026 — one year from the direction’s issue date.
For a PA with 500,000 merchants, that means a compliance review of the entire existing merchant base within a defined window, conducted under the full requirements of the Master Direction.
What This Means Operationally
Take each obligation and apply it to a real merchant population.
Ongoing monitoring at scale. A mid-sized PA has 100,000 merchants. Each merchant has a website. Each website has policy pages — refund, terms, privacy, grievance. Those pages change. Merchants update their websites, let their domains lapse, change their business models, or simply stop maintaining their policy pages. The PA’s obligation under 13(h) is to know when this happens.
At 100,000 merchants, manual review is not a strategy. If an ops team reviews 100 merchants per day — an optimistic number for thorough manual review — it takes 1,000 working days to review the full merchant base once. That is nearly four years. The requirement is continuous.
Audit-ready documentation. A CERT-In auditor does not want to see a spreadsheet assembled last week. They want to see a compliance record that demonstrates the PA has been monitoring its merchant base continuously, that changes have been detected and acted upon, and that the documentation exists to support every compliance decision made.
Timestamped, structured, continuously-generated records are the difference between a clean audit and an audit finding. An audit finding at a PA is not a fine. It is a licence risk.
The onboarding baseline. Every new merchant from January 2026 requires a comprehensive website compliance assessment as part of onboarding. If that assessment is manual, it takes time and introduces human error. If it is automated and returns structured results in under 5 seconds, the onboarding process is compliant, fast, and defensible.
The Two Kinds of Payment Aggregators
When a CERT-In auditor walks in, there are two kinds of PAs in the room.
The first kind spent the week before the audit getting their compliance team to pull data, clean spreadsheets, and reconcile what was checked against what changed since the last check. They can demonstrate compliance for a sample of their merchant base. The gaps in coverage are papered over or explained away. The auditor sees the effort.
The second kind hands the auditor a complete, timestamped, continuously-updated compliance record for every merchant — generated automatically, not assembled manually. Every change detected. Every policy page scored. Every alert fired and documented. The auditor sees a system.
The first kind is preparing for the audit.
The second kind is the benchmark the auditor uses to evaluate everyone else.
The Master Direction does not specify which kind you must be. The operational requirements it sets — ongoing monitoring, continuous background checks, comprehensive onboarding assessment, annual audit documentation — describe the second kind precisely.
The Obligations at a Glance
| Clause | Requirement | Operational Implication |
|---|---|---|
| 13(c) | Background and antecedent check | Ongoing, not one-time |
| 13(h) | Monitor merchant business profile | Continuous web presence monitoring |
| 13(j) | Full due diligence from Jan 2026 | Every new merchant, no exceptions |
| 9(d) | Annual CERT-In audit | Documented compliance record required |
| Annexure 1.4 | Security assessment at onboarding | Website compliance check is baseline |
| Annexure 1.18 | PCI-DSS review at onboarding | Structured website assessment required |
What Beetle Does
Beetle is merchant website compliance infrastructure built from inside payment operations.
It monitors merchant websites in real-time, detects policy compliance signals across refund, terms, privacy, and grievance pages, and returns structured audit-ready results via API in under 5 seconds. It runs continuously — not just at onboarding. Every result is timestamped and exportable for regulatory submissions. Change detection fires in under 5 minutes.
It was built to solve the exact operational problem the Master Direction describes — before this document was issued, inside a production payment gateway, at a scale of 800,000+ merchants.
If you are running compliance or merchant ops at a payment aggregator and the requirements described in this post are on your radar — we would rather show you than tell you.
15 minutes. We will run Beetle live on three of your actual merchants.
Beetle monitors merchant websites in real-time for payment gateways and aggregators. Built from inside payment infrastructure. getbeetle.in