Compliance · Indian Regulatory
PA-PG audit evidence, mapped to how aggregators actually get breached.
Payment aggregators sit directly in the money-movement path, and RBI's Master Direction treats them that way — data localization, nodal-account controls, and annual system audits with VAPT of the payment stack. TriNetra scopes that testing around the authorization-boundary flaws that actually show up in aggregator stacks, not a generic checklist.
Subdomain Inventory
24 targets+ Scan ad-hocThe regulation
What RBI PA-PG expects of you.
RBI's Payment Aggregator and Payment Gateway Master Direction — updated in 2025 — governs any entity that facilitates online payment acceptance on behalf of merchants. The direction sets minimum net-worth thresholds, mandates a nodal account structure for merchant settlement, and requires that payment data reside exclusively within India — not replicated to a foreign region "for backup," not processed by an offshore vendor without an explicit carve-out. Annual system audits, including VAPT of the payment stack, are a standing requirement, not a one-time onboarding gate. A payment aggregator found short risks having its authorization suspended, which for a fintech means the product itself stops working — not a fine to absorb and move on from. Payment aggregator stacks are API-first almost by definition, and the vulnerability classes that actually show up are specific: BOLA (broken object-level authorization — one merchant pulling another merchant's transaction records by changing an ID), BFLA (broken function-level authorization — a merchant-role token reaching an admin-only settlement endpoint), and mass assignment (a client-supplied field silently overwriting a server-controlled one, like a settlement account number). Generic web-app testing checklists routinely miss all three because they're logic flaws, not scanner-detectable patterns.
How TriNetra maps to it
API-first testing, mapped to a payment stack.
| TriNetra module | Evidence produced |
|---|---|
| PTaaS | API-focused PTaaS engagements — testing approach, tools used, and the Coverage tab's methodology checklist set up around authorization-boundary testing (BOLA, BFLA, mass assignment) rather than generic OWASP Top 10 coverage alone, matched to how aggregator stacks actually get exploited. |
| Attack Surface Management | Continuous inventory of the aggregator's exposed subdomains and API surface between engagements, flagging newly exposed endpoints before they become the next engagement's biggest finding. |
| Continuous Controls Validation | Data-localization posture — which cloud regions, which vendors, which disaster-recovery paths touch payment data — verified as part of scoping, not assumed from a vendor's marketing page, with control evidence kept current between audits. |
| Continuous Controls Validation | Findings feed the same Compliance Reports pipeline used for the base RBI Cybersecurity Framework, so a PA-PG entity that's also subject to the general RBI framework doesn't have to run two disconnected audit tracks. |
Keep evidence current between audits with Continuous Controls Validation.
Why SecurityBoat
Empanelled for exactly this audit.
SecurityBoat's CERT-In empanelment qualifies our team for PA-PG system audits directly, backed by CREST membership, ISO 27001, ISO 9001, and SOC 2 Type 2 — credentials a payment aggregator's own banking partners check before accepting a report.
Ready when you are
Scope your PA-PG audit around how aggregators actually get breached.
Bring your merchant-onboarding and settlement APIs. We'll scope authorization-boundary testing around them before your next annual system audit is due.