Reserve Bank of India (Payments Banks – Digital Payment Security Controls) Directions, 2026
UR
- Applies toPayments banks
- StatusIn force
- RBI text changedRBI updated this document on October 01, 2026. BankPulse is re-reading it. BankPulse checked 98 points against RBI's new text on 2 October 2026. 97 stand. 1 are marked below and are being re-read.
- IssuedJul 31, 2026
- Amendmentsnone tracked
- Length98 points in 5 sections · 9 min read
The four dates on this rule
- PublishedJul 31, 2026The day RBI put this document out. This is the same day as the Issued date on this rule.
- Starts to applyJul 31, 2026The day this rule starts to apply, as RBI's own text states it.
- Time to get readyNoneIt starts to apply on the day it was published.
- Last date to actNot statedNo date to act by was found in this document. Other dates may sit inside single paragraphs.
Kept in your browser only. Your desk
Show me the points for
Nothing is removed from the page.
Show me the points about
96 of the 98 points name no product and bind every product. All products.
What it says
How firm is each point
Stated by RBI — RBI’s own paragraph says this. We have only made it plainer.
Our reading — BankPulse read RBI’s paragraph and shortened it. The paragraph is the authority, not this line.
Needs judgement — RBI leaves this to the bank to settle, so nobody can give you a fixed number here.
Chapter I. Preliminary
1. Payment security, payments banks
This paper sets the digital payment security rules for payments banks.
2. Start date
These Directions took effect at once.
BankPulse example. There is no gap here between issue and effect. The Directions come into effect immediately upon issuance. A bank cannot wait for a separate start date, because there is none.
3. Who is covered
These Directions apply to every payments bank.
4. What counts as payment
These rules cover every digital payment product the bank offers a customer.
Chapter II. Role of the Board
1. Board approves the policy
The Board must approve the policy for digital payment products and services.
2. Board reviews it yearly
Those policies must go back to the Board at least once a year.
Chapter III. General Controls
Must know
1. Test backups half yearly
Backup data and applications must be tested at least once every six months.
2. Nothing sensitive in the page
A web application must not keep sensitive data in hidden fields or cookies.
3. Six months, then a year
A scan must be run at least every six months and an attack test at least once a year.
4. No hidden bundling
A digital channel may be given only on the customer's clear wish, never bundled.
Do it
5. Write the product policy
The bank must write a digital payment policy and get its Board to approve it.
6. Get an outside check
The bank must set out when an outside party must check the build and its security.
7. Set a limit per product
The bank must set a limit for each product on the security risk it will accept.
8. Trained staff for payments
The bank must have trained staff with the skill to run its payment systems.
9. Assess before you launch
The bank must assess the risk before a service starts and at set times after.
10. Cover the whole chain
The risk work must cover the wider chain and the safety of payment data.
11. List systems holding data
The bank must list every system that holds customer data in the payment chain.
12. Weigh the platform risk
The bank must weigh the risk in the platforms and design it picks, at both ends.
13. Build internal controls
The bank must build internal controls and weigh operational risk before a launch.
14. Design for the volume
The payment design must be strong and able to grow with volume and customers.
15. Use a secure protocol
The link used by a digital payment channel must follow a secure standard.
16. Firewall and DDoS cover
The bank must run a web application firewall and steps to blunt a flood attack.
17. Renew certificates in time
The bank must renew the digital certificates used in its payment systems in time.
18. Log what users do
The mobile and net banking applications must log user activity and odd behaviour.
19. Split the application layers
The application, the database and the screen must sit in separate layers.
20. Secure by design
The bank must build security into a payment product from the design stage.
21. Set security aims early
Security aims must be set at each stage, from gathering needs to shutting down.
22. Model the threats
The bank must use threat modelling through the whole life of an application.
23. Escrow the vendor code
For software licensed from a vendor, the bank must place the source code in escrow.
24. Test the code itself
The bank must review source code and run scans and attack tests on its applications.
25. Code review each year
A source code review or a certificate must be repeated each year if the code changed.
26. Penalty in the contract
The vendor contract must carry a penalty clause if the application provider fails.
27. Scan with full rights
A scan must be run with sign in rights, by a local agent or a scanner with admin rights.
28. Test before it goes live
The bank must test both the working and the security controls before a launch.
29. Hunt for fake apps
The bank must watch app stores for fake copies of its application and take them down.
30. Server blocks fake apps
The bank server must refuse a payment sent from an application that is not genuine.
31. Mask numbers in messages
Account and card numbers must be masked when sent by text message or by email.
32. One factor must change
At least one of those factors must change each time or be impossible to copy.
33. Design the sign in well
The sign in method must deter fraud, resist attack and guard payment data.
34. Match method to risk
The sign in method must match the risk of the customer, the payment and the amount.
35. Name the merchant
The alert and the one time code must name the merchant, not the payment agent.
36. Stop the middleman attack
The bank must take steps to blunt a man in the middle attack on a payment.
37. Keep the session whole
A signed in session must stay whole. If it breaks, the session must be closed and the payments hit put right or reversed.
38. Cap the failed tries
The bank must fix how many failed sign in tries will block the service.
39. Safe way to unblock
The bank must have a safe way to unblock a service and must tell the customer.
40. Rules to spot fraud
The bank must write down the rules that flag a suspect payment and act on them.
41. Watch the alert settings
The bank must set and watch alert settings such as speed, place and merchant type.
42. Study each fraud
The bank must study why a fraud happened and how to stop the next one.
43. Train the fraud team
Staff in the fraud control team must be trained in tools, inquiry and card rules.
44. Keep contacts current
The bank must keep current contact details for use during an incident.
45. Safe use guide inside
Safe use guidance must sit inside the application and the customer must read it.
46. Complaint page in the app
The application must carry a clear section on how to raise a complaint.
47. Online dispute resolution
The bank must run an online system to settle digital payment disputes.
48. Teach device safety
The bank must teach customers to keep their own devices updated and clean.
49. Tell the risk first
A customer must be told the risk, the gain and the liability before subscribing.
50. Explain new features
The bank must explain a new security feature clearly when it adds one.
51. Warn about phishing
The bank must warn customers about phishing, vishing and remote access tricks.
52. Mark a payment fraud
The application must let a customer mark a payment as fraud and tell the bank at once.
Background
53. Board owns the rollout
The Board and senior staff answer for putting this policy into practice.
54. Test again after a change
A scan and an attack test are also needed when new systems or big changes come in.
55. Two factors for payment
A digital payment or a cash withdrawal needs more than one factor to sign in.
56. Alert on every change
Alerts are needed for every payment, every new payee and every change in a limit.
57. Only on written request
A digital payment service may start only on the customer's own written request.
Chapter IV. Internet Banking Security Controls
1. Guard the name system
The bank must guard against DNS cache poisoning and handle cookies safely.
2. Give a virtual keyboard
A virtual keyboard must be offered on the net banking site.
3. Close idle sessions
An online session must close on its own after a fixed idle time.
4. Change the first password
A password sent by the bank must expire, and it must be changed at first sign in.
5. Extra check on the website
Net banking sites need extra checks such as adaptive sign in and a strong CAPTCHA.
Chapter V. Mobile Payments Application Security Controls
Must know
1. Six months for old versions
An older version of the application must be switched off within six months.
Do it
2. Reinstall on an error
If the application behaves oddly, the customer must be told to install a fresh copy.
3. Publish the checksum
The bank must publish a checksum so a customer can tell the real application from a fake.
4. Bind app to device
The application must be bound to the device by hardware, software and service data.
5. Tell on new device
The customer must be told on more than one channel when a new device is registered.
6. Sign in again
The application must ask for a fresh sign in after idle time and on each launch.
7. Spot the unsafe network
The application must spot an unsafe network such as open wireless and add checks.
8. Guard the temporary files
The application must limit what it writes to temporary files and must protect it.
9. No raw database queries
The application must avoid raw database queries and guard against injection attacks.
Background
10. Check the device first
The application may run only if the device meets the security checks the bank set.
11. Block a rooted phone
The bank may check whether a phone is rooted and refuse to install on it.
Chapter VI. Card Payment Security Controls
Must know
1. Never store cards plainly
Card details must never be kept as plain text at the bank or at a vendor.
2. No remote card scanning
Card data scanning must be done on the bank's own devices and never from outside.
Do it
3. Follow the card standards
The bank must follow the card industry standards for PINs, terminals and modules.
4. Report to the IT committee
A status report on these card standards must go to the IT Strategy Committee.
5. Approved terminals only
Merchant terminals must be validated under the card industry programmes.
6. Secure the acquiring side
As an acquirer, the bank must secure the card payment kit it puts in the field.
7. Tamper proof security logs
The hardware security module must log its work and those logs must resist tampering.
8. No single point of failure
The bank must cluster the hardware security module and keep safe backups.
9. PIN made at the module
A card PIN must be made and printed at a system joined to the security module.
10. Anti skimming on ATMs
The bank must fit anti skimming and whitelisting on its ATMs.
11. Watch card transactions
The bank must watch card use closely, above all cash taken out abroad.
12. Limits at the switch
Card transaction limits must be set at the card network switch itself.
13. Watch limits round the clock
A breach of those limits must be watched 24x7, on weekends and holidays too.
14. Test the scanning tool
A card data scanning tool must first be tried in a test setting.
Background
15. Issuer and acquirer both
These standards bind the bank both as the card issuer and as the acquirer.
16. Harden every ATM
Every ATM needs a BIOS password, dead USB ports and the latest patches.
Chapter VII. Repeal and Other Provisions
1. Old payment rules go
These Directions repeal the earlier digital payment security instructions.
2. Other laws still apply
These Directions add to other laws and rules and do not replace them.
BankPulse example. A bank follows these Directions and thinks the matter is closed. It is not. Any other laws, rules, regulations or directions in force still apply on top. Where another one asks for more, the bank does the more.
3. RBI has the last word
RBI may issue clarifications, and its reading of these Directions is final.
BankPulse example. Two banks read the same clause differently. Neither reading settles it. RBI may issue clarifications, and its interpretation of any provision is final and binding on all concerned entities.
The same subject for other kinds of institution
The same subject for other kinds of institution.
Other RBI rules for payments banks
RBI compliance officer and compliance function rules for payments banks 2026
RBI customer service and fair conduct rules for payments banks 2025
Every rule page on BankPulse · Questions bankers ask, answered