DMT API and RBI's Cash Remittance Rules

Domestic Money Transfer (DMT) lets a walk-in customer hand over cash at a shop counter and have it credited to a beneficiary's bank account. Because it moves cash into the formal banking system through a bank's own business correspondent network, RBI regulates it more tightly than most other retail payment flows. This piece sets out what RBI's current framework requires, what a DMT platform's software needs to capture to support it, and where Payonclick's own DMT API fits. None of this is legal advice: confirm your specific obligations with your bank partner and your own legal adviser.

RBI/2024-25/52: what changed on 1 November 2024

RBI's revised framework for domestic money transfer, RBI/2024-25/52, issued 24 July 2024 and effective 1 November 2024, tightened the rules banks must apply to cash-based money transfer done through their business correspondents. It sits alongside limits going back to a 5 October 2011 circular, which the 2024 framework did not replace.

Four requirements matter most for anyone building software on top of a bank's DMT rails:

1. Register every remitter against a verified mobile number and a self-certified Officially Valid Document (OVD).
2. Run an Additional Factor of Authentication (AFA) on every single transaction, not only at registration.
3. Carry the remitter's details and a cash-based remittance identifier in the IMPS or NEFT message the bank sends.
4. Record the beneficiary's name and address for every cash pay-out.

Card-to-card transfers sit outside this framework entirely.

Registering a remitter: a verified mobile number and an OVD

KYC for a DMT remitter is not a single OTP. RBI's framework asks for two things together: a mobile number the bank has verified belongs to the remitter, and a self-certified Officially Valid Document. Only once both are on file does a remitter exist in the bank's system as someone who can send money. A platform's onboarding screen should capture and store both, tied to that specific bank relationship, before the first transfer is attempted.

AFA on every transaction, and the cash-remittance identifier

AFA is required on every transaction, not only at onboarding. RBI does not mandate a specific mechanism; an OTP sent to the remitter's registered mobile is the common implementation, but the requirement is the additional factor itself, verified and logged, not the channel used to deliver it.

Separately, the bank must be able to tag the transaction as cash-based remittance and pass the remitter's details inside the IMPS or NEFT message it sends. This identifier is what lets the receiving bank, and RBI, tell a cash-funded transfer apart from an ordinary account-to-account one. A DMT platform's job is to hand the bank everything it needs to build that message correctly; the bank owns the rail and the message format.

Cash pay-out: beneficiary details and the 2011 limits

Where a transfer pays out in cash rather than crediting a bank account, the remitting bank records the beneficiary's name and address. Limits for cash-based DMT come from the 2011 circular and still apply:

Banks are expected to run velocity checks, and a bank sees transactions your platform can't. A limit check on your side improves the customer experience, but it doesn't replace the bank's own controls.

Velocity checks and audit logs

Beyond the monthly caps, a bank's own risk systems watch velocity: how often the same remitter sends, how many different beneficiaries one remitter pays in a short window, and whether a beneficiary receives from an unusual number of remitters. A platform sitting in front of a bank's DMT rail should keep an audit trail detailed enough to answer the bank's questions on any of these patterns: who registered the remitter, when, against which OVD, which AFA fired on which transaction, and the full beneficiary history tied to a given account. These logs are what your bank partner will ask for during its own periodic reviews.

The bank is the principal: three misconceptions to retire

KYC and anti-money-laundering responsibility for a business correspondent's transactions stays with the bank, as RBI's own compendium makes clear. Software supports that responsibility; it does not take it over. Three claims worth retiring:

• "₹25,000 is an NPCI or IMPS limit." It is not a rail limit at all. It is RBI's monthly cap specifically for cash-based DMT, and it applies regardless of whether the transfer travels by IMPS or NEFT.
• "An OTP is the KYC." An OTP is one common implementation of AFA, which authenticates a transaction. KYC is the earlier step of registering the remitter against a verified mobile number and an OVD. The two checks serve different purposes, and neither substitutes for the other.
• "A reference number means the money has moved." A reference number confirms the request reached the bank's system. The transfer itself still depends on the bank's own processing and the receiving side, which is why it can sit pending well after the screen shows a reference.

Where the Payonclick DMT API fits

Payonclick's DMT API supports the steps above; it does not claim to satisfy RBI's rules on your behalf, and that responsibility sits between you, your bank partner and your legal adviser. What the API offers:

• OTP-based sender registration against a mobile number
• Penny-drop verification of a beneficiary's bank account before a transfer is attempted
• Per-beneficiary daily limits, returned with your balance so your app can check an amount before sending it
• An idempotent client_reference, so retrying the same request never creates a second transfer

Transfers made through the DMT API are neither instant nor automated. Each transfer is queued and completed by a transfer operator on the Payonclick platform, only for supported banks and only inside those banks' service windows; the status stays pending until the transfer is completed. If your business needs to send its own funds rather than remit a walk-in customer's cash, that is a different, separately regulated flow. Our DMT API vs payout API comparison sets out the difference, and the payout API page covers the alternative.

Payonclick India Team · VVN MULTISERVICES INDIA Pvt. Ltd., Sirsa, Haryana.