RBI master directions for engineers

Most engineers working on Indian FinTech products hear about RBI master directions second-hand. Someone from the compliance team forwards a PDF. The engineering lead skims the summary, asks “does this affect our roadmap?”, and the answer is usually “we will get back to you.” Six weeks later the change is in production because the compliance team has signed off the proposal that the engineering team did not have time to read.

This pattern produces correct outcomes occasionally and expensive surprises often. The expensive surprises are the ones where an engineering decision (a data-retention default, a consent flow, an audit log shape, a tokenisation choice) implies a regulatory posture nobody on the engineering team is tracking. Six months later the regulator notices, and the team learns that the choice they made on a Tuesday afternoon now requires a quarter of remediation work.

The fix is not to make engineers into compliance officers. The fix is for engineers to know which RBI master directions sit closest to their work, what the directions actually say in plain language, and where the seam is between an engineering decision and a compliance decision. The rest of this post is that translation.

(For wider FinTech regulatory context and how we integrate it into engagement work, see the focus area.)

1. The PA-PG framework

Full name: Master Direction on Payment Aggregators and Payment Gateways. Published 17 March 2020, updated repeatedly since.

Who it covers: Any entity that acts as a Payment Aggregator (PA) — a merchant-facing service that collects card or UPI payments and settles to the merchant’s bank account — or Payment Gateway (PG) infrastructure that supports such a service.

What changes in engineering work:

• PCI DSS scope. Card data tokenisation is mandatory at the network token (RBI tokenisation) layer, with the PA holding no plaintext card numbers. Engineering work: token vault integration, scoped data flows, audit logs proving the un-tokenised card never persisted in your stores.
• Settlement timelines. T+1 settlement is the default, with specific carve-outs. Engineering work: durable ledger entries with explicit settlement state machines, reconciliation jobs that flag any settlement that misses the window.
• Refund handling. Refunds must reach the customer’s account within prescribed windows. Engineering work: a refund state machine separate from the original transaction, alerts on stuck refunds, a customer-visible refund-status surface.
• Concurrent audit by the PA’s auditor. Engineering work: an immutable audit log of every settlement, refund, and customer dispute, queryable by external auditors with a documented schema.

The PA-PG framework is the single regulation most likely to surface in the engineering team’s roadmap if your product touches merchant settlement. Read the master direction. The plain-language version is shorter than the engineering work it implies.

2. The digital lending guidelines

Full name: Guidelines on Digital Lending. Published 2 September 2022.

Who it covers: Any entity offering loans through digital channels, whether as a regulated lender (banks, NBFCs) or as a Loan Service Provider (LSP) acting on behalf of one.

What changes in engineering work:

• Direct disbursement. Loan funds must flow directly from the regulated lender to the borrower’s bank account, with no pass-through accounts held by the LSP. Engineering work: payment-rail integration that bypasses intermediate accounts, with the audit trail proving the path.
• Key Fact Statement. A Key Fact Statement (KFS) must be presented to the borrower before disbursement, in a standardised format. Engineering work: a KFS surface that renders the prescribed fields in the prescribed order, with a recorded acknowledgement event.
• Cooling-off period. The borrower must have an explicit cooling-off window to cancel without prejudice. Engineering work: a cancellation flow that can unwind a disbursement during the window.
• App-based lending. Apps offering digital lending must be associated with a regulated lender, listed on the lender’s website, and use only that lender’s branding for the lending surfaces. Engineering work: surface ownership and branding controls that prevent cross-lender contamination in the UI.

The digital lending guidelines reach further into engineering than the PA-PG framework, because they constrain not just data flows but the surfaces themselves.

3. The KYC master direction

Full name: Master Direction on Know Your Customer. Published 25 February 2016, amended repeatedly.

Who it covers: Every regulated entity onboarding customers — banks, NBFCs, PAs, brokers, asset managers, insurance.

What changes in engineering work:

• CDD tiering. Customer Due Diligence (CDD) has explicit tiers (simplified, regular, enhanced) with different documentary requirements. Engineering work: a CDD state machine that drives the document-collection flow based on the customer’s risk profile, with the regulator-facing audit trail showing why each tier was assigned.
• Video KYC (V-CIP). The Video-based Customer Identification Process has specific requirements: live, official-time stamped, with the field officer’s face visible, recorded with metadata. Engineering work: a video-capture surface with timestamping, immutable storage, and a quality-control workflow that catches re-recordings.
• Periodic update. KYC has to be updated on a schedule based on customer risk. Engineering work: a recurring-update workflow that surfaces the right documents to the customer at the right time, with audit trails of the prompts sent.
• eKYC and Aadhaar paths. OTP-based eKYC and offline Aadhaar paths each have their own engineering shapes. Both have to coexist with the legacy in-person path.

KYC is the master direction most engineers underestimate, because the surface looks like a form. The form is the smallest part. The state machine, the document workflow, the recurring update, and the audit surfaces are where the engineering effort actually sits.

4. The account aggregator framework

Full name: Master Direction on Non-Banking Financial Company - Account Aggregator (NBFC-AA), 2 September 2016, plus the broader AA ecosystem (Sahamati, FIPs, FIUs).

Who it covers: Anyone consuming or producing financial information through the AA framework, whether as a Financial Information User (FIU) reading data or a Financial Information Provider (FIP) serving it.

What changes in engineering work:

• Consent management. Every AA call is consent-driven, with the consent artefact carrying the scope, frequency, and duration. Engineering work: a consent artefact handling module with explicit storage, revocation, and expiry handling — and the audit trail that proves no fetch happened outside a valid consent.
• Data flow shape. The AA framework introduces explicit FIP → AA → FIU mechanics, which means your data ingress is no longer the same as your data storage. Engineering work: an ingress layer that handles the AA-shaped payload, parses the standardised XML/JSON, and lands data in your own store with provenance metadata intact.
• FIU obligations. As a Financial Information User, you have obligations on minimum data retention, customer-facing dashboards showing what was pulled, and dispute handling. Engineering work: a customer-facing AA dashboard that lists every active and revoked consent.

The AA framework is the cleanest of the four directions in terms of API specification (there are formal schemas) and the messiest in terms of engineering integration, because it sits across multiple regulatory boundaries.

DPDP Act 2023 as the cross-cutting concern

The Digital Personal Data Protection Act 2023 sits across all four directions. Every consent flow described above has to comply with DPDP’s notice + consent requirements. Every data retention default has to comply with DPDP’s purpose limitation. Every cross-border transfer has to comply with DPDP’s notified-country list.

The DPDP Act does not replace any of the RBI directions. It adds a cross-cutting obligation that engineers have to thread through every flow that touches personal data. The right approach is to design consent ledgers and audit defaults once, at the platform level, rather than retrofitting them per surface.

The pattern: ask the right question early

The engineering decision that produces the most regulatory pain is rarely “we did something wrong.” It is “we did something that did not look like a regulatory decision but turned out to be one.” A retention default. A consent flow that does not record what it should. An audit log that captures the API call but not the user state.

The fix is procedural, not technical. Every engineering decision that touches a customer, a payment, a consent, or a data flow gets a one-line check at design time: “does this imply a regulatory posture I am not currently tracking?” If yes, go ask compliance before the code lands. If no, the question got asked, and you have a record of it.

That is the seam between the engineering team and the compliance team. Most teams have it informally. Building it explicitly — as a checkbox on the design doc template, or a section in the PR description — is the single highest-leverage process change a FinTech engineering team can make.