The BC model is an RBI framework, in place in some form since 2006, that lets a bank appoint agents — individuals, kirana store owners, retired government or bank employees, cooperative societies, NGOs, and corporate BC network operators — to deliver basic banking services at locations where the bank itself doesn't have a branch. It's the regulatory answer to a simple problem: banks can't put a branch in every village and every urban side street, but people still need to withdraw cash, check a balance, or send money.

A BC agent operates under a formal agreement with a bank (or with a corporate BC that has that agreement with the bank). The agent is not a bank employee, but they're acting on the bank's behalf, using the bank's core banking connection, and following the bank's KYC and transaction rules. This is the legal and commercial scaffolding — the contract, the code of conduct, the compliance obligations, the commission structure.

What the BC model does not specify is a single piece of hardware or a single transaction rail. A BC agent might process an AEPS cash withdrawal, swipe a debit card on a Micro-ATM, initiate an IMPS transfer through a mobile app, or open a small savings account — all under the same BC agreement, often through the same counter. The BC relationship is the umbrella; AEPS and Micro-ATM sit underneath it as tools.

This is also why the compliance obligations for running a BC point — KYC checks, transaction limits, grievance handling, RBI/NPCI/UIDAI reporting — don't change depending on whether a given transaction happened via AEPS or a card swipe. The obligations attach to the BC relationship, not to the specific rail. We go deeper into that regulatory layer in our dedicated guide on RBI, NPCI, and UIDAI compliance for AEPS service providers, so we won't repeat it all here.

AEPS stands for Aadhaar Enabled Payment System. It's a payment rail built and switched by NPCI that lets a bank customer whose Aadhaar number is linked to their bank account complete a transaction using just their Aadhaar number, the name of their bank (or its IIN), and a fingerprint or iris scan for authentication.

No card. No PIN. No signature. The customer's finger, on a biometric scanner, is the authentication factor — matched against UIDAI's database in real time.

AEPS supports a defined, fairly narrow set of transactions:

• Cash withdrawal: the most common use case at retail BC points — customers pulling out cash from their linked bank account.

• Cash deposit: depositing into a linked account through the agent.

• Balance enquiry: checking the account balance without a passbook or net banking.

• Mini statement: last few transactions, pulled instantly.

• Aadhaar-to-Aadhaar fund transfer / BHIM Aadhaar Pay: moving money or accepting merchant payments using biometric authentication instead of a card or UPI PIN.

What makes AEPS genuinely useful in rural and semi-urban India is interoperability: a customer of any bank can walk up to any BC agent's AEPS point and transact, because NPCI's switch routes the request to the customer's actual bank in the background. The agent doesn't need to be affiliated with the customer's specific bank — that's the whole point of the design.

On the hardware side, AEPS technically only requires a certified biometric scanner (fingerprint or iris) connected to a phone or a small device running the AEPS application, plus internet connectivity. That's a meaningfully lighter setup than what people assume is needed.

A Micro-ATM is a physical device — think of it as a smaller, portable cousin of a POS/EDC machine — that a BC agent uses to perform banking transactions using a customer's debit card (with a PIN) or, on many modern models, an added biometric authentication mode. It was originally proposed as a low-cost alternative to a full ATM machine, meant to be carried by an agent, run on a small battery, and connect over GPRS or mobile data.

The important distinction: a Micro-ATM is a device category, not a payment rail. It can be used to process a card-based transaction (swipe + PIN, exactly like a POS machine, routed through the card network and the bank), and depending on the model and integration, the same device can also carry a biometric module and be used to run AEPS transactions. This is precisely where people get confused — a Micro-ATM is often the physical box that an AEPS transaction actually happens on, which makes them think Micro-ATM and AEPS are the same thing.

They're not, because a Micro-ATM can do things AEPS cannot — most notably, straightforward debit-card-based cash withdrawal and balance enquiry for customers who don't want to (or can't) use biometric authentication, plus in some deployments a broader range of card-network transactions. And AEPS can run without any Micro-ATM hardware at all, on nothing more than a certified biometric scanner and a phone.

Why banks pushed Micro-ATMs in the first place

Before Aadhaar-linked biometric authentication was widespread and reliable at scale, card-plus-PIN was the more dependable way to authenticate a rural customer at an agent point. Micro-ATMs gave banks a hardware-standardized way to extend basic ATM-like functionality — cash withdrawal, balance check, mini statement, sometimes cash deposit — to a BC counter using the card rails banks already trusted, without waiting for full-scale ATM infrastructure or 100% Aadhaar-seeding of every account.

Think of it in layers rather than a straight line: BC Model (the relationship) → Transaction Technology (AEPS or Micro-ATM or both) → Actual Customer Transaction.

A single retailer, operating as a BC agent under one agreement, can run both AEPS and Micro-ATM transactions from the same counter, often through the same software platform switching between the two depending on what the customer needs and what identity document they're carrying. Someone without their debit card but with their Aadhaar-linked mobile number can still withdraw cash via AEPS. Someone who prefers card-and-PIN, or whose biometric doesn't match well due to manual labor wear on their fingerprints (a genuinely common real-world problem), can use the Micro-ATM's card mode instead.

None of this changes who the agent is answerable to. The BC agreement with the bank (or corporate BC) is what determines the agent's transaction limits, commission structure, KYC responsibilities, and grievance-redressal obligations — regardless of whether a given transaction that day happened over AEPS or a card swipe on a Micro-ATM. Getting that BC relationship structured correctly — sponsoring and onboarding each agent as a properly registered Business Correspondent — is a separate, necessary first step that a lot of fast-scaling networks skip past, assuming a device rollout alone constitutes agent onboarding.

The practical takeaway: it's never "BC model or AEPS." A bank or NBFC establishes the BC relationship for its agent network first, and only then decides which transaction technologies — AEPS, Micro-ATM, or both — that network should be equipped to support.

Strip away the jargon and three things drive most real-world decisions: hardware cost, authentication reliability, and what the customer base your agent network serves actually needs.

Hardware and setup cost

A basic certified biometric scanner for AEPS-only operation is the cheaper entry point — commonly in the ₹1,500 to ₹3,000 range for the device alone. A proper Micro-ATM device, especially one bundling card-swipe, a printer, and biometric capability, typically runs from around ₹5,000 up to ₹15,000 or more depending on the brand and features. Ongoing costs also differ — Micro-ATMs generally carry higher maintenance and consumable (paper roll) costs than a bare biometric scanner. That gap compounds quickly once you're standardizing hardware across a network of hundreds or thousands of agents, which is exactly why it's worth modelling total cost of ownership before locking in one device standard, not just the per-unit price a distributor quotes.

Authentication reliability

Biometric authentication is not universally reliable. Manual laborers, elderly customers, and people with worn or damaged fingerprints can fail fingerprint matches repeatedly, which is frustrating for both the agent and the customer standing in front of them. Card-and-PIN on a Micro-ATM doesn't have that failure mode — but it requires the customer to actually be carrying their debit card, which a meaningful share of AEPS's target rural customer base still doesn't have, or doesn't like carrying.

Customer profile

If the customer base your agent network primarily serves is Jan Dhan / Aadhaar-linked account holders without debit cards — common in many rural and low-income urban deployments — AEPS-only hardware is often enough, and it's the cheaper way to get a rollout live. Where the network serves a more mixed customer base with debit cards, or needs to also support POS-style merchant payment acceptance through the same agents, a Micro-ATM (or combo device) standard earns its higher cost back faster.

A network doesn't have to pick one and abandon the other — most mature BC deployments end up running both within a year or two of launch. But for a bank or NBFC scoping a first rollout with a limited hardware budget, here's a straightforward way to decide what to standardize on.

Use Assess the customer base your agents will serve → check the hardware budget → match the technology → add the second rail once volume justifies it as the order of operations.

Start with AEPS if

• Hardware budget is the binding constraint: a certified biometric scanner is the lowest-cost way to get a functioning agent counter live.

• The target geography is rural or low-income urban: most customers are Aadhaar-linked account holders who may not carry a debit card at all.

• Cash withdrawal and balance enquiry are the dominant expected demand: AEPS covers this core need well without extra hardware.

Add or start with a Micro-ATM if

• Agents' customers routinely carry debit cards: common in more urbanized or semi-urban deployment zones.

• Field data shows repeated biometric authentication failures: a card-and-PIN fallback keeps transactions from stalling at the counter.

• The network also needs to accept merchant card payments: a Micro-ATM/POS-style device adds a revenue line a biometric-only scanner can't.

Either way, get the BC relationship right first

Whichever technology gets standardized on, none of it works without a properly structured BC agreement covering every agent in the network — directly with your bank, or through a corporate BC/aggregator arrangement. That agreement is what actually authorizes each agent's transactions, defines commission structures, and sets the compliance obligations RBI ultimately holds the bank accountable for. We cover that full RBI/NPCI/UIDAI compliance picture — agent due-diligence, consent, data handling — in our companion guide on regulatory compliance for AEPS providers, and it's worth reading before locking in a device standard for the whole network.

The confusion between these three terms comes from the fact that they show up together so often — an AEPS transaction happening on a Micro-ATM device, at a counter run under a BC agreement, makes them feel like one thing. They're not. The BC model is the legal relationship that authorizes an agent to operate; AEPS and Micro-ATM are the tools an agent uses once that's in place. Get the BC relationship structured correctly first, then choose which transaction technology (or both) to standardize on based on the actual customer base your agent network serves, not on whichever device a distributor is pushing that week. If you're evaluating a platform that can run AEPS and Micro-ATM transactions under one BC setup across an entire agent network, without juggling separate logins and reconciliation systems, take a look at BC Edge, or get in touch with our team to talk through what fits your specific rollout.