Every AEPS transaction touches three regulators at once, and each one is answerable for a different slice of the transaction. Confusing them — assuming, say, that being NPCI-compliant also covers your Aadhaar obligations — is the single most common mistake we see agents and even smaller BC networks make.

RBI governs the banking relationship → NPCI governs the payment rail → UIDAI governs the Aadhaar authentication → DPDP Act governs the data itself, and all four apply simultaneously to the same five-second transaction.

The Business Correspondent model itself is an RBI creation. It started life as a way for banks to reach customers who couldn't be economically served by a branch — RBI first allowed BCs in 2006, and widened the model in 2010 to let for-profit companies (not just NGOs and cooperatives) act as BCs. Every AEPS agent operating today, whether through a national distributor or a small-town retailer, is legally functioning as a sub-agent of a bank's BC arrangement, even when the retailer never sets foot in that bank's branch.

The principal-agent liability rule

The single most important thing to understand about RBI's framework is this: the bank remains fully responsible for everything its BC network does. RBI's outsourcing and BC guidelines make the bank — not the BC company, and not the individual retailer — the party accountable to the customer and to the regulator. That's precisely why sponsor banks push so much verification, monitoring, and reporting down the chain: they're carrying the regulatory risk for every transaction an agent processes.

• Board-approved BC policy: banks must operate under a policy approved by their own board, defining permissible activities, fee structures, and agent conduct rules — a platform or distributor onboarding agents has to work within that policy, not around it.

• No unauthorized fees: an agent cannot charge a customer anything beyond the fee schedule the bank has approved and disclosed. Charging an extra "service charge" on top is a direct violation, not a grey area.

• KYC responsibility: BCs frequently perform KYC and e-KYC on the bank's behalf, but the bank carries ultimate responsibility for KYC compliance under RBI's KYC Master Directions — a poorly verified agent is the bank's problem to answer for.

The 2024–25 due-diligence tightening

This part is recent and matters a lot right now. Following a visible spike in AEPS-linked fraud — largely biometric spoofing using cloned or silicone fingerprints pulled from other public records — RBI put out draft due-diligence guidelines for AEPS touchpoint operators in August 2024 and finalized them in mid-2025. These directions push banks to run enhanced background verification on every touchpoint operator (the actual retailer running the device), register and geo-tag biometric devices, monitor transaction patterns for anomalies, and act faster on suspicious activity flags. If you're evaluating an AEPS platform today, this is the exact area to ask about: how does the platform's onboarding flow map to these RBI due-diligence expectations, not just to NPCI's technical certification.

Where RBI governs the banking relationship, NPCI (the National Payments Corporation of India) governs the actual payment rail AEPS runs on. NPCI operates AEPS as an interoperable switch — meaning a customer of any bank can walk up to any BC agent tagged to any acquiring bank and still transact, because NPCI routes the request to the customer's own (issuer) bank behind the scenes. This interoperability is what makes AEPS structurally different from a normal single-bank BC arrangement, and it's also why disputes get more complicated — two banks and NPCI's switch are involved in every transaction, not just one.

AEPS, as NPCI defines it, supports four core services: cash withdrawal, balance enquiry, mini statement, and Aadhaar-to-Aadhaar fund transfer. Anything beyond these four is a different product (BHIM Aadhaar Pay for merchant payments, for instance) with its own separate rules.

Transaction limits and settlement

NPCI doesn't publish one universal transaction ceiling that applies uniformly across every bank — per-transaction and cumulative daily limits are ultimately set by the customer's issuing bank within NPCI's overall framework, and they vary from bank to bank. What providers and agents need to internalize is the pattern, not a single number: limits commonly sit in a per-transaction band, plus a lower cumulative daily cap that many issuing banks have tightened further since the 2024-25 fraud-prevention push. A platform worth using tells its agents this plainly rather than promising a flat number that quietly differs by which bank the customer holds an account with.

Settlement between the acquiring and issuing bank happens on NPCI's standard cycle, and failed or disputed transactions are routed through NPCI's dispute-management process — the same category of turn-around-time (TAT) obligation RBI applies to failed ATM and card transactions generally, where a failed transaction that debits the customer must be auto-reversed within a defined window, with compensation payable to the customer for delays beyond it. For an agent, this means a "failed" transaction isn't the end of the story — it triggers a reconciliation and reversal timeline that the bank, and by extension the BC network, is accountable for servicing.

This is the layer most agents genuinely don't understand well enough, and it's the one with direct personal legal exposure attached. The Aadhaar Act, 2016, and specifically Section 8, governs how anyone — a bank, a BC network, an individual agent's device — is allowed to use a person's Aadhaar number and biometrics to authenticate them.

Consent comes first, every single time

Section 8(2) of the Act requires that before submitting someone's identity information for authentication, the requesting entity must obtain the individual's consent and inform them of the nature of information to be shared, the purpose of the authentication, and the alternatives available if they choose not to consent. This isn't a one-time onboarding formality — it applies to every authentication request, meaning every cash withdrawal, every balance enquiry. An agent who just grabs a customer's finger without that explicit, informed step is already non-compliant, regardless of whether the transaction itself succeeds.

What the authentication response does — and doesn't — return

Section 8(3) is what makes Aadhaar authentication privacy-conscious by design: UIDAI's Central Identities Data Repository does not send back the resident's Aadhaar number, their raw biometric data, or any other identity document to the requesting party. It returns either a simple positive/negative (yes/no) confirmation, or, in e-KYC mode and with the resident's specific consent, limited demographic details such as name, address and photograph. The requesting AEPS platform or bank never receives or is entitled to store the resident's actual fingerprint or iris template — that data lives and dies inside UIDAI's system.

• No biometric storage by agents or platforms: Section 29 of the Act separately prohibits anyone other than UIDAI from storing core biometric information, meaning the device, the app, or the platform processing an AEPS transaction cannot retain the raw fingerprint or iris scan once the authentication request is sent.

• Purpose limitation on logs: Authentication User Agencies and their sub-agents are permitted to maintain authentication transaction logs for record-keeping, but those logs cannot be used for any purpose beyond what consent was obtained for, and cannot be shared onward except as UIDAI's regulations permit.

• Restricted disclosure: Section 33 allows disclosure of identity information only under a court order or in the interest of national security, subject to further conditions — it is not something a bank, BC, or platform can hand over on its own initiative.

In practice, most AEPS agents and even most BC-network platforms are not the licensed Authentication User Agency (AUA) themselves — they operate as a sub-AUA under a bank or a licensed KYC User Agency (KUA), meaning the primary legal registration with UIDAI sits further up the chain. But that doesn't remove the agent's obligation at the point of capture: consent still has to be taken, the device still can't retain biometric data, and the same purpose-limitation rule still applies. This is also where identity verification tooling like Verify Edge earns its keep — building the consent-and-authentication flow correctly at the API layer, rather than leaving it to an agent's judgment at the counter.

The Digital Personal Data Protection Act, 2023 doesn't replace the Aadhaar Act or RBI's rules — it sits on top of them as a general data-protection layer, and it applies to every piece of digital personal data an AEPS transaction touches: the Aadhaar number, the phone number used for consent, the transaction history, the device and location metadata. An AEPS provider or BC network is, in DPDP terms, a Data Fiduciary for all of this — and can be classified a Significant Data Fiduciary if its scale or the sensitivity of data it processes crosses the thresholds the government notifies.

A separate consent trail, not a blanket one

Section 5 requires a clear, itemized notice at or before the point consent is sought — describing what data is collected and for what purpose, in plain language the customer can actually understand — and Section 6 requires that consent be specific, informed, and as easy to withdraw as it was to give. The practical catch for AEPS providers: this DPDP-level consent is separate from the Aadhaar Act consent under Section 8. A single vague "I agree" checkbox covering everything at once does not satisfy either law properly — the compliant approach logs the RBI/KYC purpose, the UIDAI authentication purpose, and the general DPDP data-processing purpose as distinct, traceable consent events.

• Reasonable security safeguards: Section 8 obliges fiduciaries to implement safeguards to prevent personal data breaches — vague internal policy documents don't count if the actual systems handling Aadhaar and transaction data aren't secured to match.

• Breach notification: a personal data breach has to be reported to the Data Protection Board and to affected individuals — this cannot be quietly absorbed and fixed internally once agent-level or platform-level systems are compromised.

• Erasure once purpose is served: data must be erased once the purpose for collecting it is met or consent is withdrawn, unless another law (such as RBI's KYC record-retention rules) separately requires it to be kept — meaning retention timelines now have to be reconciled across both regimes, not decided by whichever is more convenient.

For a BC agent this mostly plays out as a platform-level responsibility — but any provider you work with should be able to explain, in plain terms, how consent is logged separately for each purpose and how long KYC data sits in their systems before it's purged.

Most compliance failures in the AEPS ecosystem aren't exotic — they're the same handful of shortcuts, repeated across thousands of outlets, that eventually get caught because a bank's monitoring flags an anomaly or a customer files a complaint.

• Storing or photographing Aadhaar details/biometric captures: writing down a customer's Aadhaar number in a register or saving a fingerprint scan locally violates both the Aadhaar Act's storage restrictions and DPDP's data-minimization principle — and is one of the fastest ways to get an outlet's device deactivated.

• Charging unauthorized fees: collecting an extra "service charge" beyond the bank-approved fee schedule is a direct RBI BC-policy violation; the standard consequence is suspension, and repeated instances lead to permanent deactivation from the network.

• Skipping device/agent registration: operating a biometric device that hasn't been registered and verified under the sponsor bank's due-diligence process (the same process RBI tightened in 2024–25) puts the agent's transactions at risk of being blocked retroactively, and puts the whole outlet under investigation.

• Sub-letting login credentials: letting an unverified third person operate under your registered AEPS login is one of the most common fraud vectors RBI has flagged — grounds for immediate termination, and potentially a criminal referral for identity-related fraud.

• Ignoring failed-transaction timelines: not following up on failed or disputed transactions within NPCI's reversal window shifts the compensation liability up to the bank, which typically recovers that cost from the BC's commission or terminates the relationship.

What the penalties actually look like

For an individual agent, the escalation is usually: warning → suspension → permanent deactivation and blacklisting across the sponsor bank's and NPCI's network, with a police referral where fraud or identity misuse is involved (unauthorized use of another person's identity information under the Aadhaar Act carries imprisonment of up to three years along with a fine). For the BC network or platform, RBI can direct the sponsor bank to suspend or terminate the outsourcing arrangement entirely, and under the DPDP Act, a data-fiduciary-level failure — not implementing reasonable security safeguards, or not reporting a breach — carries financial penalties that, per the Act's schedule, can run into the hundreds of crores for the most serious lapses. These consequences don't stay with the biggest player in the chain; they cascade down to whoever took the shortcut.

Compliance in this business isn't a document filed once — it's a handful of habits repeated correctly on every single transaction. This is the checklist worth pushing down to every agent in your network and auditing against periodically, since compliance drifts silently until an incident forces the issue. Verify consent → capture only what's needed → don't store what isn't allowed → follow up on failures covers most of it.

• Do: confirm the customer understands what's being authenticated and why, before every scan — not just at first sign-up.

• Do: keep your biometric device registered and updated with your sponsor bank/platform, and report any hardware change immediately.

• Do: follow up on any failed or pending transaction within the reversal window rather than letting the customer chase you.

• Do: charge only the fee schedule your bank/platform has explicitly approved and disclosed.

• Don't: write down, photograph, or store a customer's Aadhaar number or biometric capture anywhere outside the authorized transaction flow.

• Don't: let anyone else operate your login or your registered device, even briefly.

• Don't: assume a platform being "NPCI-certified" automatically means it's also handling Aadhaar Act consent and DPDP data-retention correctly — ask directly.

• Don't: treat a customer complaint about a failed transaction as something to informally resolve in cash — it needs to go through the proper reversal/dispute channel so the record stays clean.

None of this is meant to make AEPS sound harder than it is to run day-to-day — most agents who follow the consent, registration, and fee rules never run into trouble. The real risk is treating compliance as the platform's problem alone. It isn't: the liability, and often the immediate financial and legal consequence, lands on whoever was actually holding the device when something went wrong, and cascades up to the sponsor bank from there. Before you commit to a distributor or a platform for your agent network, ask specifically how they handle agent due-diligence, biometric device registration, consent logging, and dispute turnaround — not just what the commercial terms look like. If you want to see how a compliance-first AEPS setup actually looks in practice, take a look at BC Edge, or get in touch with SecureEdge to walk through the onboarding and compliance workflow directly.