In Indian banking, the registered mobile number is more than a contact detail. It receives OTPs, transaction alerts, and password resets. Whoever holds the number can often control the account.<\/p>\n\n\n\n
That creates a quiet risk. Mobile numbers are disconnected every day for failed re-verification, links to cybercrime or plain non-use, and many are later reassigned. If a bank still treats a revoked number as its customer’s, OTPs<\/a> can reach a stranger, and accounts linked to fraud-flagged numbers can keep operating.<\/p>\n\n\n\n The Mobile Number Revocation List (MNRL) exists to close that gap. This guide explains what MNRL is, what RBI expects, and how to implement it without disrupting genuine customers.<\/p>\n\n\n\n MNRL stands for Mobile Number Revocation List<\/strong>. It is a list of mobile numbers that have been permanently disconnected, compiled from telecom service providers and published by the Department of Telecommunications (DoT) through its Digital Intelligence Platform (DIP).<\/p>\n\n\n\n DIP is DoT’s secure platform for sharing telecom-related fraud intelligence with stakeholders such as banks, payment providers, and law enforcement. Regulated entities access MNRL data through DIP, either by periodic download or integration.<\/p>\n\n\n\n Numbers appear on the list for reasons that carry different risk levels:<\/p>\n\n\n\n The first two categories are strong fraud signals<\/a>. The last is mostly benign but still means the number no longer reliably reaches the customer.<\/p>\n\n\n\n In January 2025, RBI advised regulated entities to use MNRL, available on DoT’s Digital Intelligence Platform, to clean their customer databases and monitor accounts linked to revoked numbers, with action expected by 31 March 2025.<\/p>\n\n\n\n RBI asked entities to build standard operating procedures that include:<\/p>\n\n\n\n The same communication covered related steps, such as sharing verified customer-care numbers with DoT and using designated number series for transactional and promotional calls.<\/p>\n\n\n\n The value is highest when MNRL is used continuously, not as a one-time clean-up.<\/p>\n\n\n\n A complete implementation covers three moments.<\/p>\n\n\n\n Check the applicant’s mobile number against MNRL before the OTP step completes. A revoked number should stop the journey or route it to an alternative verification path.<\/p>\n\n\n\n Screen all registered mobile numbers against each MNRL update. Matches create a work queue by risk category.<\/p>\n\n\n\n Re-check before high-risk actions: change of registered mobile number, new device registration, high-value payee addition, loan disbursal, and large withdrawals.<\/p>\n\n\n\n Behind all three, keep an audit trail: when each number was checked, against which list version, and what action was taken.<\/p>\n\n\n\n An MNRL match is a trigger for action, not proof of fraud. A disciplined SOP separates cases:<\/p>\n\n\n\n Avoid blanket account freezes for routine revocations. They create complaints and can block legitimate customers from their own money.<\/p>\n\n\n\n MNRL tells you a number is gone. Other signals tell you a live number is risky:<\/p>\n\n\n\n Combining these signals produces a mobile risk view that is far more useful than a single list check.<\/p>\n\n\n\n Retail bank:<\/strong> Screens its full customer base against each MNRL update, freezes OTP delivery to matched numbers, and runs a contact-update campaign through branches and email. Fraud-linked matches go to the financial crime team.<\/p>\n\n\n\n Digital lender:<\/strong> Blocks applications with revoked numbers at onboarding and adds number age and SIM-swap checks for new numbers.<\/p>\n\n\n\n Payments app:<\/strong> Re-checks MNRL before registered mobile changes and new device bindings, cutting account takeover attempts that relied on reassigned numbers.<\/p>\n\n\n\n At onboarding, before sensitive account changes, and against the full customer base whenever the list is updated.<\/p>\n<\/div><\/div>\n<\/div>\n<\/div>\n\n\n\n No. Numbers are revoked for many reasons, including non-use. The match means the number should no longer be trusted, and the reason should be reviewed<\/p>\n<\/div><\/div>\n<\/div>\n<\/div>\n\n\n\n RBI has advised regulated entities to use MNRL and to set up SOPs for handling revoked numbers, with action expected from March 2025.<\/p>\n<\/div><\/div>\n<\/div>\n<\/div>\n\n\n\n The Department of Telecommunications, through its Digital Intelligence Platform, uses data from telecom service providers.<\/p>\n<\/div><\/div>\n<\/div>\n<\/div>\n\n\n\n Mobile Number Revocation List.<\/p>\n<\/div><\/div>\n<\/div>\n<\/div>\n\n\n\n MNRL addresses a simple but costly weakness in digital finance<\/a>: institutions trusting a mobile number long after it has stopped belonging to their customer. RBI’s requirement turns that weakness into a defined control with clear expectations.<\/p>\n\n\n\n The institutions that get the most from it use MNRL continuously, handle matches with a careful SOP, and combine it with live mobile risk signals.<\/p>\n\n\n\n BeFiSc’s mobile intelligence APIs help regulated entities check revocation status and related mobile risk signals at onboarding and at key account events. Talk to the BeFiSc <\/a>team to add mobile risk checks to your stack.<\/p>\n\n\nWhat MNRL Is<\/h2>\n\n\n\n
Why Mobile Numbers Get Revoked<\/h2>\n\n\n\n
\n
The RBI Requirement<\/h2>\n\n\n\n
\n
Risks MNRL Helps Control<\/h2>\n\n\n\n
Risk<\/th> How it happens<\/th> How MNRL helps<\/th><\/tr><\/thead> OTP interception after reassignment<\/td> A disconnected number is reissued to a new person who receives the old customer’s OTPs<\/td> Flags the number so it can be replaced before reuse<\/td><\/tr> Mule account operation<\/td> Accounts opened or controlled with SIMs later cut for fraud<\/td> Identifies accounts tied to fraud-linked numbers for review<\/td><\/tr> Loan and onboarding fraud<\/td> Applications using numbers already revoked<\/td> Blocks or escalates at onboarding<\/td><\/tr> Failed customer communication<\/td> Alerts sent to numbers the customer no longer holds<\/td> Prompts contact-detail updates<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n How to Implement MNRL Checks<\/h2>\n\n\n\n
At onboarding<\/h3>\n\n\n\n
Portfolio screening<\/h3>\n\n\n\n
At sensitive events<\/h3>\n\n\n\n
Handling a Match Without Harming Customers<\/h2>\n\n\n\n
\n
MNRL Alongside Other Telecom Risk Signals<\/h2>\n\n\n\n
\n
Use Cases<\/h2>\n\n\n\n
Key Takeaways<\/h2>\n\n\n\n
\n
F<\/strong>requently Asked Questions<\/h2>\n\n\n\n
How often should MNRL checks run?<\/strong><\/h6>\n
Does an MNRL match mean the customer is a fraudster?<\/strong> <\/h6>\n
Is MNRL mandatory for banks?<\/strong> <\/h6>\n
Who publishes the MNRL?<\/strong><\/h6>\n
What is the full form of MNRL?<\/strong><\/h6>\n
Conclusion<\/h2>\n\n\n\n