"CMS" shows up on fintech landing pages, bank websites and outsourcing contracts, and it rarely means the same thing twice. A retailer sees "CMS agency" ads and pictures a loan EMI counter. A corporate treasury team means bulk cheque and cash logistics. And a listed company literally trades under the name CMS Info Systems Ltd. Before you build or buy anything with "CMS" in the name, work out which one you actually need, because the compliance obligations attached to each are completely different.
Three things "CMS" can mean
| Term | What it means | Example |
|---|---|---|
| Agent cash collection (retail CMS) | A shop or Business Correspondent collects cash from a walk-in customer, usually against a loan EMI, and the lender's account is credited | A counter accepting an EMI payment on behalf of an NBFC |
| Corporate cash management services | A bank service for businesses: bulk collections, payouts, cheque and cash logistics, liquidity management | A company's treasury desk reconciling collections from hundreds of dealers |
| CMS Info Systems Ltd | A listed cash logistics and ATM-services company, unrelated to either meaning above | ATM cash replenishment, cash-in-transit |
This guide is about the first meaning: agent cash collection, mostly for loan EMIs, sometimes sold as a "cash collection API" or "EMI collection service". If your search led you here from a corporate treasury need, or from a stock ticker, the rest of this page is not for you.
What a Business Correspondent may actually do with cash
RBI introduced the business correspondent model in its January 2006 circular RBI/2005-06/288. Among the activities it lists, a BC may carry out "recovery of principal / collection of interest" on behalf of the bank. That one line is the legal root of almost every "EMI collection at a shop" product on the market: the shop acts as the bank's or lender's BC for that specific function, not as an independent collection business.
Two things follow from this:
- The bank stays responsible to the customer for what its BC does, so collection activity sits inside the lender's own outsourcing and grievance framework, not outside it.
- A collection setup is only ever collecting for a specific, named lender relationship. There is no general-purpose licence that lets a platform collect EMIs for any lender it likes.
Why pooling EMI cash got harder in 2025
RBI's Digital Lending Directions, 2025 (RBI/2025-26/36, 8 May 2025) tightened how digital loan repayments must flow. Paragraph 9.ii (rbi.org.in) requires repayments on digital loans to be made directly into the regulated entity's (RE's) bank account, without any pass-through or pool account of a third party, including a lending service provider.
For digital loans, a platform wallet that collects EMI cash from many shops and pays the lender in a batch looks like the pool-account structure paragraph 9.ii rules out. Do not design a collection product around a shared wallet without checking it against this rule first.
There is one narrow exception: cash recovered in person on a delinquent loan can be collected, and must be credited to the RE's account the same day. That covers physical, in-person recovery on an account already in default, not routine EMI collection at a counter.
Recovery agents have their own rulebook
If the activity looks like recovery rather than routine bill payment, RBI's Recovery Agent directions apply. RBI/2022-23/108 (12 August 2022) sets conduct rules for a lender's recovery agents: no calls before 8 am or after 7 pm, no intimidation or harassment, and the lender carries ultimate responsibility for the agent's conduct. A cash-collection network that also chases overdue borrowers is a recovery-agent network under this circular, whatever the app calls it.
Three routes an EMI can travel today
| Route | How it works | Who is accountable | Fits |
|---|---|---|---|
| Bharat Connect (Bharat Bill Payment System) | The lender is live as a biller in a Bharat Connect category such as Loan Repayment. The EMI is paid as a Bharat Connect bill payment and settled through Bharat Connect's settlement chain, not into a platform's pooled collection account | The lender's Biller Operating Unit and the agent's Customer Operating Unit or agent institution | Routine EMI payment where the lender already has a Bharat Connect biller relationship |
| NACH / e-mandate | The lender's own bank debits the borrower's account on the due date through the National Automated Clearing House, with no cash and no shop involved | The lender and its sponsor bank, through NPCI's NACH system | Borrowers who pay from a bank account, not in cash |
| Lender-appointed cash collection | A BC or agent accepts cash under a specific lender's agreement, and the lender's account is credited on the timeline that agreement and RBI's rules require | The lender, through its BC or agency agreement | Walk-in cash EMI payments where the lender has appointed the agent directly |
NACH is the lender's own rail, run through NPCI. Keep this description general: confirm mandate mechanics and timelines with the lender's own bank rather than treating NACH as a feature you can build independently.
Structures that can work (read this as analysis, not legal advice)
None of the three routes above is "download an SDK and go live." Each needs a real relationship with the lender. In practice, businesses building a collection product tend to land on one of these:
Become a Bharat Connect biller-side integration
Help the lender or its billing partner onboard as a Bharat Connect biller, so every shop-counter EMI payment is a standard bill payment with no pooling.
Sign on as the lender's named collection agent
Work directly under the lender's BC or recovery-agent agreement, with cash credited to the lender the same day, as the Digital Lending Directions require for in-person recovery.
Route through the lender's own NACH mandate
For customers who can pay from a bank account, point them to the lender's e-mandate instead of building a cash flow at all.
This is a general reading of the rules above, not legal advice. Ask the lender's own compliance or legal team to confirm which structure your integration fits, especially the treatment of any wallet or holding account.
What a collection platform needs, regardless of the route
A workable EMI-collection integration has to solve the same five problems, whichever legal structure it uses:
Lender mapping
Every collection must resolve to one specific lender and one specific loan account. There is no generic "pay any EMI" flow.
Receipts
The borrower needs a receipt that names the lender, the loan reference and the amount, immediately, whether the payment moves through Bharat Connect or a direct BC flow.
Timely credit
Collected cash must reach the lender on the timeline the lender and RBI's rules require. For in-person recovery on delinquent digital loans, that is the same day.
Reconciliation
Every collected rupee has to tie back to a loan account and a lender statement line. A collection product with no daily reconciliation job is a dispute waiting to happen.
Agent KYC
The person taking cash on the lender's behalf needs to be identifiable and traceable, in line with the BC and recovery-agent frameworks above.
Where Payonclick fits today
Bharat Connect's Loan Repayment category is live inside the Payonclick BBPS API today, alongside 29 other bill categories. A lender that is already a Bharat Connect biller can be paid through the same bill-fetch-and-pay flow used for electricity or credit card bills: your integration fetches the amount due where the lender supports bill fetch, shows it, and pays it with the same idempotent client_reference and status-check pattern used across the API. Bharat Connect also lists an Agent Collection category.
What Payonclick does not offer today is a ready-made agent cash-collection integration: the direct-BC-recovery route in the table above, with its own wallet, agent network and same-day settlement logic. That is not a live product. If your business needs it, it is scoped as custom development, built against your specific lender's or its collection partner's requirements, not as a standing API.