[Co-authored with Prasanth Regy, Renuka Sane, Anjali Sharma, and Shivangi Tyagi]
The Insolvency and Bankruptcy Code, 2016 (IBC) provides for the speedy resolution of insolvency. The process described in IBC hinges on the assumption that information will be easily accessible to the parties involved. It is for this purpose that IBC provides for the establishment of Information Utilities (IUs). As envisaged in IBC, as well as the Bankruptcy Law Reform Committee Report, IUs are repositories of information regarding debt and default, and are required to be able to produce this information quickly. This information can then be used for many purposes. For instance, the Courts can use it to decide whether to send a debtor company into a resolution process. But for this information to be widely used, it is essential that Judges, Insolvency Professionals, and other parties must be able to trust this information implicitly.
The timelines specified by IBC are quite strict. They can be met only if IUs stand ready to provide all requisite information quickly. IBC provides little guidance on how IUs are to function, leaving the details to subordinate regulation. A Working Group on IUs was set up by the Ministry of Corporate Affairs to draft the regulations governing IUs. The Working Group's suggestions (Draft Regulations) were put up for public comments. Subsequently, an Advisory Committee discussed the public comments, and the final regulations (IU Regulations) were notified on 31st March, 2017.
However, the regulations have some fundamental problems which are likely to impede the efficient and transparent functioning of IUs. In this article, we highlight some of these problems.
Core Services
IBC defines "core services" to be a set of services every IU has to provide. This includes accepting information, authenticating and verifying it, storing it, and providing access to it. There are several issues with how the current regulations treat the provision of core services:
1. Authorising representatives:
Regulation 18(5) of the IU Regulations says: An information utility shall provide a registered user a functionality to enable its authorised representatives to carry on the activities in sub-regulation (1) on its behalf.
This can be very dangerous, because of the possibility of misuse. For instance, can a bank be a registered representative of its borrower? Imagine a situation where an individual takes a loan from a lender, and one of the signatures among the many he signs in the paperwork authorises the lender to be his representative for filing information with an IU. The lender can now declare, on behalf of the borrower, that the borrower has defaulted. This is a clear conflict of interest.
This provision lends itself to misuse by the borrower, too. A borrower may borrow money and confirm this debt in an IU, but he could later claim that some authorised representative committed fraud.
If the functionality of enabling authorised representatives is desired, appropriate safeguards need to be added to the IU Regulations.
2. Registering users: According to section 214(e) of IBC, IUs are supposed to get the financial information authenticated before storing. But 18(1) of the IU Regulations suggests registration only for submitting and accessing information. Does this mean that unregistered parties can authenticate information? If yes, it can lead to the danger that IU records will have little sanctity in court.
3. Accessing information from other IUs: Regulation 19(3) of the IU Regulations states that a user can access information stored with an IU through any IU.
There are several issues here:
- This is commercially sensitive information. We are asking IUs to share information they have with all other IUs. Can the destination IU store this information or use it in any way?
- If incomplete information is provided at the time of financial information retrieval, it will not be clear whose fault it is: the primary IU's or some more distant IU's.
- How is this to work? How are the other IUs to provide this info "directly" to the user? Presumably the intent is to avoid routing the financial information through the destination IU, but this is contradictory and unclear.
The Draft Regulations expect that the user (or software deployed by him) would be able to query multiple IUs inexpensively and in parallel, as happens every day in online air-ticket booking. This is a simple and straightforward architecture that avoids the problems above.
4. Acknowledgement: Regulation 20 of the IU Regulations mandates that the IU should provide an acknowledgement. The acknowledgement is important to ensure that the IU has not manipulated or lost information. For this reason, the acknowledgement must be irrepudiable. In the Draft Regulations, this is achieved by ensuring that:
- The acknowledgement should echo the information submitted, along with the identities of the persons submitting and authenticating the financial information;
- It should be digitally signed by the IU.
The IU Regulations do not contain these requirements. Without them, it is difficult to detect if the IU loses data or manipulates it in connivance with parties to the debt. The information in the IU loses its sanctity, so that judges can no longer trust it.
5. Accepting documents as part of information submission:
Regulation 20(1) of the IU Regulations says: An information utility shall accept information submitted by a user in Form C of the Schedule.
Items 37, 50 and 56 of Form C lay down the documents to be attached as proof. This suggests that an IU has to accept documentary proof of the financial information being submitted.
This is a clear problem. The design of IBC intended IUs to be an electronic repository of financial information, and not a document management system. That is why the requirement of authentication and verification of information submitted to an IU was envisaged. While it may be possible for IUs to accept documents in electronic form, even this process creates two challenges. First, storing documents will add to the cost of the IU infrastructure, which will then be passed on to users. This may make storing credit contracts in an IU expensive and may disincentivise users from doing so. This in turn will pose fundamental viability challenges for the IU business model. Second, if an IU stores financial information as well as documents, its not clear whether both will need to be matched, and if so on whom the responsibility of doing so will fall upon.
6. Information of default: Regulation 21(2)(a) of the IU Regulations places an obligation on the IU to communicate information of default to all creditors. The question arises, which creditors: the creditors on the same IU or the creditors of that debtor on other IUs as well? The IU that has learnt of default does not know of the creditors of that debtor on other IUs, but IBC clearly intends that all creditors of a debtor should learn of default, whichever IU they are on.
The Working Group Report thinks this through properly: an obligation is placed on each IU to inform all IUs about default, and also on each IU to inform all creditors of a defaulting debtor.
7. Marking records as erroneous: Regulation 25(2) suggests that a user can unilaterally mark any information as erroneous. This is very dangerous. A process needs to be specified for correcting errors, and it should involve confirmation by the counterparties, just like any other information that gets to the IU.
8. Outsourcing:
Regulation 30(2)(a) of the IU Regulations says: An information utility shall not outsource the provision of core services to a third part service provider.
This clause is problematic, as it can create operating inflexibility for IUs. It is unclear how broad this clause is. For example: does this mean that the IU platform cannot be outsourced, or does this outsourcing ban apply to data center and related services, technology maintenance contracts, technology support personnel, physical security including guards, etc?
Technically, it can be read as an IU having to create every component of its core services delivery entirely on its own. This will increase the time taken for an IU to be set up, as well as add to the costs of service delivery by an IU.
Due to this problem, the Working Group Report suggested that outsourcing of core services could be possible, subject to approval by the IBBI. Alternately, instead of a blanket ban on outsourcing, the IBBI may consider a two stage outsourcing structure. First, a narrow list of services, such as authentication and verification, may be classified as those that cannot be outsourced. For the remaining, an outsourcing model similar to the one that the RBI follows for its regulated entities may be followed. Under this model, two elements are taken into consideration by the regulator when allowing outsourcing: (1) that the standards of service for the user remain the same, whether the components of service delivery are in-house or outsourced; (2) the primary liability, even in case of outsourced services, lies with the regulated entity.
9. Portability of records from one IU to another: Since IUs have pricing freedom, if they charge for storage, there is a danger that they may increase the fees substantially if users whose data is with them cannot move their data to another IU. To prevent such price-gouging, the Draft Regulations provide that any user may migrate his information from one IU to another IU, and the source IU is prohibited from charging for this facility. The manner in which the IU Regulations seeks to avoid this problem is through its declaration that fees should be a reasonable reflection of the service provided. But this requires the Board to form a view as to what is a reasonable fee. The solution suggested by the Working Group uses the market to achieve the same outcome in a less intrusive manner.
IU Records as Evidence
1. IU records admissible as evidence: Regulation 30 mandates that an IU shall adopt "secure systems" (as defined in the Information and Technology Act, 2000) for information flows. However, this alone does not ensure that the information stored in IUs will be admissible as evidence.
The Draft Regulations provided the information stored in an IU should conform to requirements laid down in section 65B of the Indian Evidence Act, 1872 (Evidence Act). This section of the Evidence Act lays down the standards for storage and maintenance of electronic records so that they are admissible as evidence.
2. Authentication and Verification: The manner in which the terms "authentication" and "verification" have been used in the IU Regulations creates confusion. It is not clear when authentication and verification will take place, after or before the information is submitted.
As per Regulation 20(2)(ii), on receipt of information by an IU, the submitter of information will be provided with terms and conditions of authentication and verification of information. It is not clear why the terms and conditions should be provided once the information has been submitted. The user should be aware of these terms before the information is submitted to an IU.
Regulation 21(1) states that on receipt of information about a default the IU shall expeditiously start the process of authentication and verification. This raises following questions:
- Why is an IU is required to act expeditiously once information of default is received? The process of authentication and verification should be followed in case of any information received and not just for default.
- What is meant by 'expeditious'? IUs should act expeditiously whenever any information is submitted and not just in case of default.
Regulation 23(2)(b) and (c) states that an IU shall enable the user to view the status of authentication and verification. It is not clear why the status of authentication is required after information has been submitted. IBC mandates that information should be stored only after authentication, so an IU should never store any unauthenticated information in the first place.
The Draft Regulations addressed the above issues by obligating an IU to do the following:
- Once information is submitted, the IU should make the information available to concerned parties for authentication.
- An IU should verify the identity of the concerned party before allowing it to authenticate the information, so that there is no unauthorised access.
- Once information is authenticated, the IU should store the information in such a manner that it cannot be lost or tampered with.
Obligations on IBBI
1. Access to IU records by IBBI: Regulation 23(1)(e) provides that the IBBI will be allowed to access any information from any IU. It doesn't impose any restrictions or conditions for accessing this information.
Since the information submitted to an IU is highly confidential and commercially sensitive, it is essential that there should be some accountability for the access of information by the IBBI. The Draft Regulations provided that in order to access information stored in an IU, the IBBI must pass a written order.
2. Exit management plan: Regulation 39 mandates all IUs to have an exit management plan. Clause 1(a) of this regulation requires the IU to have mechanisms in place so the users can transfer information to other IUs, in case there is a shut down of one or more IUs. This regulation places the onus of transferring information on the users of IUs instead of the IBBI or the IUs themselves. This onus is inappropriately placed, since an IU will probably have a large number of users, many of whom may not have the ability to ensure the transfer of their information.
The Draft Regulations put the onus of making sure information is transferred from one IU to another on IBBI and the IU. This ensures smooth transfer of information since they will be better equipped with resources to perform this task.
Miscellaneous
1. Entry Barriers: Regulation 3 of the IU Regulations requires that IUs have a net worth of at least Rs 50 crores, and prevents foreign control of IUs. Regulation 8 prevents any single shareholder from holding more than 10 percent of the equity share capital of an IU. Together, these have a chilling effect on the entry of firms into this industry.
2. Annual fees: Regulation 6(2)(e) provides that an IU must pay a fee of fifty lakh rupees to the Board annually. This is a large sum of money, especially given that the business model is unproven. This will discourage entry, limit competition, and increase the fees charged to the users.
3. In-principle vs regular registration: Regulation 7 is unclear on the difference between a regular approval and an in-principle approval. It is also unclear as to why an applicant would choose one form of application over the other. In the Draft Regulations, the idea was that in-principle registrations would be granted faster than regular registration.
4. Non-discrimination:
Regulation 29 makes a broad provision: An IU shall provide services without discrimination in any manner.
An explanation follows that mentions specific kinds of discrimination. It is not clear whether the explanation is indicative or if it is exhaustive. If exhaustive, there is no need for the broad prohibition of all discrimination above. This creates confusion for potential IUs.
Fees: Regulation 32(1)(a) provides that IUs shall charge a uniform fee for providing the same service to different users. Does this mean that an IU has to charge the same to an individual lender who wants to submit information about one loan, and a large bank such as SBI, which might want to submit information about thousands of loans everyday, on the basis that the service is the same?
Regulation 32(2)(a) provides that the fee charged for providing services shall be a reasonable reflection of the service provided. This is a very broad statement in the absence of any test of what a "reasonable reflection" is.
Conclusion
Many of the issues mentioned above can create serious problems for the new (and as yet unborn) industry of IUs. High entry barriers will lead to a monopolistic industry with high prices and poor service. If courts are not convinced of the accuracy of the records stored in IUs, the parties will get stuck in lengthy litigation to establish even the basic facts about the debt. IUs established under these regulations might not serve their basic purpose — the creation of an information-rich environment which would bolster speedy resolution in the country.
References
Government of India, The Report of the Bankruptcy Law Reforms Committee, chaired by Dr T K Vishwanathan, 4 November, 2015.
Government of India, The Insolvency and Bankruptcy Code, 2016.
Ministry of Corporate Affairs, The Report Working Group on Information Utilities, chaired by K V R Murty, 11 January, 2017.
Insolvency and Bankruptcy Board of India, Insolvency and Bankruptcy Board of India (Information Utilities) Regulations, 2017.
Sumant Prashant, Prasanth Regy, Renuka Sane, and Shivangi Tyagi are researchers at the National Institute of Public Finance and Policy, New Delhi. Anjali Sharma is a researcher at Indira Gandhi Institute of Development Research, Mumbai.
The views expressed in the post are those of the author only. No responsibility for them should be attributed to NIPFP.