You are here: Home / Internet Governance / Blog / Event Report: Consultation on Draft Information Technology (Fintech Security Standards) Rules

Event Report: Consultation on Draft Information Technology (Fintech Security Standards) Rules

Posted by Anindya Kanan at Nov 12, 2019 06:40 AM |
The Centre for Internet and Society is in the process of drafting certain data security standards for Fintech entities. As part of the process of drafting, a consultation roundtable was organized to get inputs from industry executives, lawyers and policy experts working in this field.


By: Anindya Kanan

Reviewed and Edited by: Vipul Kharbanda and Elonnai Hickok

Edited by: Arindrajit Basu


The Centre for Internet and Society is in the process of drafting certain data security standards for Fintech entities. As part of the process of drafting, a  consultation roundtable was organized to get inputs from industry executives, lawyers and policy experts working in this field. Their industry knowledge and experience of dealing with these regulatory issues. The regulatory framework for data protection by Fintech entities is currently governed by the generic data protection laws of India enumerated in section 43A of the Information Technology Act, 2000, as well as the Information Technology (Reasonable security practices and procedures and sensitive personal data or information) Rules, 2011 (SPDI Rules) issued under it. The problem is that the SPDI Rules lack any specific protocols to be followed by Fintech entities, whereby they can satisfy their obligations under section 43A of the IT Act. 

Thus there is a need for a concrete framework for information security which can be used by entities working in this space. The SPDI rules refer ISO 27001 as one possible standard but certification under it isn't economically feasible for most small businesses to implement. The Draft Information Technology (Fintech Security Standards) Rules (“Fintech Rules”) being proposed by CIS is meant specifically to provide a mechanism for compliance to the smaller businesses in the fintech space. The schedule to the Draft fintech rules provides clear guidelines to be followed by a fintech entity to deem it to be in compliance with section 43A of the IT Act. As mentioned, the roundtable consultation was an effort to get inputs from independent sources including legal experts, academics and those working in the industry.

Session 1

This session dealt with the need for these fin-tech rules and how they address the shortcomings in the law as mentioned above.  The session started with the drafter giving a brief introduction on the scope and objective of these rules as well as their importance.  Then they went ahead with the reading of the rules with discussion on every section. The drafter then explained the objective behind that section and the participants gave their inputs on it. The various concerns raised by the participants during the session are given below.

Scope of Data protected by the draft fintech rules

The participants raised concerns that the draft Fintech Rules proposed by CIS only safeguard the confidentiality of sensitive personal data and information as defined in section 3(1) of the SPDI rules and not other data that may be in possession of a fintech entity. Thus they expressed a need to bring not just sensitive personal data within the ambit of these security standards but to expand the definition in the interest of data privacy of the users.  It was clarified that though the review of the definition of sensitive personal data and information is outside the scope of the draft fintech rules ,the drafters have tried to include a wider ambit of data under it as Section 3(2) puts an obligation to also protect vital data and information. The drafters agreed to take this under review for future drafts.

Updation of the security standards

The schedule to the fintech rules drafted by CIS provides Information security practices which would provide reasonable levels of security from the currently known threats. But the threat environment is ever-changing as thousands of new malware are created each day and malicious actors are looking for vulnerabilities in every security infrastructure. Thus, even though the information security practices are adequate in the present day there is a real risk of them getting obsolete very fast. To counter this risk section Section 3(2)[1] provides for updation of these security standards from time to time. A concern was thus raised at this juncture about there not being a fixed timeline for upgradation to a new standard by the fin-tech entities. Further it was pointed out that there was no provision for a periodic audit and certification of the security practices unlike the SPDI rules{Section 8(4)} which are meant to ensure government oversight on the fin-tech firms.

The drafters then explained that these rules are meant as a positive obligation for the fin-tech entities to adopt on their own free will so as to show compliance with “reasonable security practices and procedures” and thus limit their liability in case of an action under 43A of the IT act. Thus oversight by the government through audits are excluded by design, further the individual companies have to decide on the time-frame for upgradation of their security practices based on the latest standards when they think is reasonable or expedient for them to do based on their individual case.

Example - Say there were two security standards one enacted in 2011 and the other in 2016 now a fin-tech entity in 2019 has to decide which one of the two would be reasonable to comply with to ensure effective data security. The reasonableness would also depend upon the specific technologies used or the type of information the firm handles or the type of users they have to name a few factors. Finally it would be up to the court to decide whether a firm’s practice was reasonable or not based on the individual case of that fintech entity. This was opposed by the industry executives as they wanted to have a fixed standard for compliance as later the interpretation of the court could go either way when deciding the case. Further the legal experts also favoured having fixed standards rather than one based on reasonableness. They felt that the courts would need an authoritative source and these rules could be that authoritative source for the courts to base their decisions on. This point was then taken under review for later drafts.


A concern was raised about there being no timeline for reporting the breach to the user but only for reporting it to CERT. The drafter replied with the standard being ”without undue delay” which would though based on this input be reviewed for later drafts. Another reason for not providing a firm time limit is so that fintech entities have the time to investigate the causes for the breach and are able to give a more complete picture to their customers when they are notified, so as not to cause undue panic amongst them. However, the drafters said that they would review this provision so that it is not misused.

A clarification was asked about the stage at which the rules became applicable (does this include beta testing as well?). The rules are extremely clear with their application being to any fintech entity handling sensitive personal data and information and thus would apply at all stages when any user data is used (including beta testing). 

The participants also made suggestions with regards to introducing penalties and defining wrongful gain and wrongful loss in the specific context of data loss or misuse to bring more clarity on this issue.

The session came to a close with reiteration of the fact that these draft fintech rules are only an enabling provision to improve compliance rates by making it economically feasible for smaller fin-tech entities. This helps foster growth in a new and emerging field like fin-tech while also safeguarding user interests of privacy and data security.

Session 2

Session 2 dealt with the schedule of the Draft fintech rules which specified the actual technical requirements which the fin-tech entities would have to fulfil to comply with the rules. The session started with the drafters explaining how these rules would less onerous on the fin-tech entities as compared to ISO standards. The Draft security standards have simpler technical guidelines that place a lower and less granular threshold of technical compliance on the fintech entity, in addition to not requiring external ISO certification which comes with a prohibitively high financial cost. The session progressed with the drafter and the participants discussing each of the sections of the schedule. The concerns raised and the discussions following them are given below. 

Limitation of scope to Information Security

A clarification was asked for the reason for limiting the scope of the rules to only infosec and not the whole of cybersecurity. The drafters said that as the rules specifically deal with compliance under section 43A of the IT Act which penalises entities in case of negligence in handling of data. Thus security standards for information security were thought to be adequate to fulfil this requirement and cybersecurity was deemed to thus be out of the scope of these draft fintech rules. 

Physical security compliance in case of Cloud storage

A concern was raised with regards to the physical security requirement under the schedule. Increasingly fintech entities are using commercial cloud storage providers for their data storage needs and thus are not in control of the physical premises where their data is stored and thus firms would be unable to comply with these requirements. After some discussion the consensus that was reached was that the fintech entity would have to indirectly ensure compliance by only opting for reputed or properly certified cloud providers but even in the case of a data breach on their end the fintech entity will have to prove in the court that it wasn’t negligent in choosing the cloud provider. A recommendation was floated to include the phrase “where applicable” in the clause for physical safety that only when a fintech entity has control over the physical infrastructure of its data storage systems would it be required to fulfil this obligation. This recommendation was taken for review for later drafts. 

Based on the recommendations of the industry executives some parts of the schedule were omitted due to the requirements under them already being fulfilled through SPDI rules. For instance rules relating to Migration controls which deal with transfer of data from one system to another were omitted as they were thought to have been adequately dealt within SPDI rules.

Maintenance of standardised logs

Another concern was raised on the requirement of standardised Log entries by the industry executives. They pointed out that in general logging is a good practice to ensure that unauthorized access or malicious activity can be traced but the form of the logs would depend a lot on the system or the software one was using and thus having a standardised log for such different systems would not be possible. This suggestion was taken under review for later drafts. Further concerns were raised about the time period for log-retention and the drafters decided that they would address this issue in later drafts. It was recommended that access logs as well as end-user logs also be included under this requirements which was then flagged for review by the drafters.

Compliance with requirements for malware protection and wireless security 

With regards to the requirements for malware protection and wireless security, the industry experts felt that the rules were very specific and inapplicable to a lot of systems that people in different parts of the fintech industry use. They also were of the view that these practices would get outdated pretty soon. 

They further pointed out that the compliance standards in the draft were impractical especially for fintech entities working in co-working spaces or decentralised networks as the fintech entity would not be in control of the network hardware. The drafters explained that the draft fintech rules could be updated from time to time to tackle these issues. Alternatively, it was suggested that for niche areas like wireless security and malware protection, the rules can refer to a widely accepted standard or practices in the tech industry (FIPS and OWASP guidelines for secure coding practices were given as examples). 

A general consensus was reached that the guidelines should focus more on concepts/abstractions of security practices rather than the specific mechanisms. However,the specific security mechanisms were considered to have their own benefits in the form of crystallizing the steps required to be taken for compliance. 


The discussion was concluded with a note of thanks to all participants for their invaluable contribution to further the development of these security standards. The participants raised pertinent concerns about the structure as well as the framework of these rules and various parts of the draft which were welcomed by the drafters who flagged them for review for future versions. Furthermore participants gave crucial inputs on the changing nature of the industry and the need to have a more principle based approach to the technical framework. The discussion concluded on the consensus that there was a need for flexible guidelines which take into account the fast-changing nature the fintech industry as a whole and the unique nature of work that any entity does under it so as to not stifle growth but without compromising on the need for data security for the users of these services.

CIS will be circulating the draft guidelines publicly for wider stakeholder inputs.