Master Directions on Cyber Resilience and Digital Payment Security Controls for non-bank Payment System Operators

1. Escrow if you cannot

Where the source code cannot be had, it must be placed in escrow.

2. Test backups half yearly

Backed up data must be tested at least once every six months.

3. Six hours to report

An unusual incident must be reported to RBI within 6 hours of detection.

4. Score below the mark

A staff member scoring below the mark may be barred from the information assets.

5. Keep tenants apart

A shared cloud must be guarded so the data of different users never mixes.

6. Keep logs five years

Audit logs must be kept for at least five years.

7. Twelve hour cooling period

After a change of mobile number or email, no online payment is allowed for at least 12 hours.

BankPulse example. A customer changes the mobile number on her wallet at nine in the morning. RBI sets a cooling period of minimum 12 hours. So no online payment from that wallet can go through until nine at night. A payment she tries at six in the evening is refused.

1. Partners must comply too

The operator must make its unregulated partners follow these rules by agreement.

2. Board policy for partners

A Board approved policy must set out how those partners are held to the rules.

3. Board owns cyber risk

The Board must oversee information security risk, cyber risk and cyber resilience.

4. Who chairs it

That sub-committee must be headed by a member who knows information and cyber security.

5. Board approved security policy

The operator must have a Board approved information security policy.

6. Review the policy yearly

That policy must be reviewed once a year.

7. What the policy covers

The policy must set out roles and how cyber risk is found, judged and managed.

8. Write a crisis plan

The operator must have a separate Board approved cyber crisis management plan.

9. Set risk and performance measures

The operator must set risk indicators and performance measures for its controls.

10. Reports go to the committee

Audit and test reports must go to the oversight sub-committee at its next meeting.

11. Assess before a launch

The operator must assess cyber risk before a new product or a major change.

12. Keep an asset record

The operator must record every key role, asset, process and outside provider.

13. Draw the data flow

A full diagram of the network, its links and its data flows must be kept current.

14. What the record holds

Each asset record must show its address, its place, its owner and its support end date.

15. Check kit nearing end

Any asset nearing the end of support must be assessed for the risk of running on.

16. One identity per person

Everyone with access must be given a digital identity, watched until they leave.

17. Kill default settings

Default sign in settings must be switched off and changed before a system goes live.

18. Least privilege access

Access must follow need to have, need to know and least privilege.

19. Privileged accounts need two factors

A privileged account needs more than one sign in factor and must be watched closely.

20. Control removable media

Removable media and portable devices must be controlled from one central list.

21. Close idle sessions

Sessions must be limited, locked and closed after a set time with no activity.

22. Guard the physical site

Physical safeguards, tested from time to time, must protect assets from disaster.

23. Check network devices

Network devices must be set up correctly and checked from time to time.

24. Run a security centre

A security operations centre must watch network and system logs from one place.

25. Tie the alerts together

An automatic system must tie alerts together across the business to spot an attack.

26. Layer the boundary defence

Boundary defences must be layered to watch traffic in and out of the business.

27. Split the network

The network must be split by role, place and environment to separate critical systems.

28. Whitelist the applications

Only permitted applications and services may run, and ports should be whitelisted.

29. Devices must qualify first

A device may join the network only after it meets the security rules set for it.

30. Secure by design

The operator must design and build its products securely from the start.

31. Separate the database layer

The database layer must sit apart from the other layers of the application.

32. Get the source code

The operator must obtain the source code of every critical application it buys.

33. Test at least yearly

Every application must be tested by qualified people at least once a year.

34. Certificate from the developer

Where the code is not owned, the developer must certify it carries no known flaw.

35. Fix what testing finds

A weakness found in testing must be closed in a time bound way.

36. Report repeat findings

A finding that comes back must go to the Board sub-committee with an analysis.

37. Guard the vendor door

Controls must stop anyone getting into the network through a vendor system.

38. Where the data may sit

The operator must follow the law on where systems sit and where data is held.

39. Independent vendor assurance

For a vendor in a critical process, an independent auditor must certify its strength.

40. Stop data leaks

The operator must have a full policy to stop the leak of business and customer data.

41. Trace your data assets

The operator must be able to trace and see its data assets.

42. Build a security system

An information security management system must be built on a recognised standard.

43. Encrypt data both ways

Data must be encrypted while it moves and while it is stored.

44. Card data needs PCI-DSS

An operator that stores card data must hold PCI-DSS certification.

45. Have a patch policy

The operator must have a written policy for finding and applying patches.

46. Critical patches go at once

A patch for a well known attack must be applied at once.

47. Manage every change

Every change must go through a change process that keeps the whole set up sound.

48. Board approved response plan

The operator must have a Board approved plan for answering an incident.

49. Find the root cause

After an incident the operator must work out its impact and its root cause.

50. Tell CERT-In as well

A cyber security incident must also be reported to CERT-In.

51. Plan for the worst

A continuity plan must cover extreme but possible cyber events.

52. Review the plan yearly

The continuity plan must be reviewed at least once a year.

53. Aim for no data loss

The operator must aim for near zero data loss on recovery.

54. Recovery site, other zone

The recovery site must sit in a different earthquake zone from the main data centre.

55. Reconcile on switchover

A set method must reconcile data so nothing is lost when the recovery site takes over.

56. Follow API standards

The operator must follow recognised standards for interface security.

57. Train staff and vendors

The operator must train staff and vendors on information security again and again.

58. Train the Board too

Board members and senior staff must be trained on information security and cyber risk.

59. Audit the cloud provider

The cloud provider must be audited by an independent party at least once a year.

60. Watch fraud in real time

The operator must run a fraud monitoring system that works in near real time.

61. Manned desk all year

A manned desk must run 24x7x365 to settle fraudulent payments customers report.

62. What a log must show

A log must show who acted, what they did and with what settings.

63. Design for the volume

The payment design must be strong and able to grow with the volume it carries.

64. Secure the mail

Mail and messaging going in and out of the operator must be secure.

65. Buy anti phishing help

The operator must buy a service to take down fake sites and rogue apps.

66. Warn the public

The operator must build public awareness of fraud and cyber threats.

67. Mask numbers in alerts

Account and card numbers must be masked in an alert sent to a customer.

68. Name the merchant

An alert for an online payment must name the merchant, not the payment gateway.

69. Code at the end

Where a one time code is used, it must sit at the end of the message.

70. Mark a payment fraud

The customer must be able to mark a payment as fraud and tell the issuer at once.

71. No odd behaviour

The mobile application must be free of behaviour it was not built for.

72. 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.

73. Bind app to device

The mobile application must be bound to the device and its SIM.

74. Close idle mobile sessions

A mobile session must close on its own after a fixed idle time.

75. Cap failed sign ins

The operator must fix how many failed sign in tries will block the application.

76. Tell the customer at once

The customer must be told at once about a failed sign in try.

77. Block remote access apps

The application must be blocked while a remote access tool is running on the phone.

78. Approved card terminals

Merchant terminals must be validated under the card industry programmes.

79. Limits at the switch

Card transaction limits must be set at the card network switch itself.

80. Alert the issuer always

The card network must alert the card issuer about a suspicious event 24x7x365.

81. Encrypt stored card data

A card network must hold customer card details in encrypted form on every server.

82. Cooling period after loading

A prepaid issuer must set a cooling period after money is loaded on the instrument.

1. Cyber rules for operators

This paper sets the cyber and payment security rules for non-bank payment system operators.

2. Start date

These Directions took effect the day RBI placed them on its website.

3. Three phases by size

Large operators had to comply by 1 April 2025 and medium ones by 1 April 2026. Small operators have until 1 April 2028.

4. Who is covered

These Directions apply to every authorised non-bank payment system operator.

5. Sub-committee each quarter

Oversight may pass to a Board sub-committee that meets at least once a quarter.

6. New certificate on change

A fresh certificate is needed whenever the source code changes.

7. Audit before you deploy

A new or changed critical service goes live only after an audit and a test.

8. Test before going live

A patch or a change goes live only after it is tested somewhere else first.

9. Alerts in your language

Prepaid issuers are urged to send codes and alerts in the language a user picks.