Naavi.org

DGPSI is the Digital Governance and Protection Standard of India (DGPSI) which is meant to be a guidance for compliance of DPDPA 2023 along with ITA 2000 and BIS draft standard on Data Governance. It is therefore natural to reflect how does DGPSI address the use of an AI algorithm by a Data Fiduciary during the process of compliance.

Let me place some thoughts here for elaboration later.

DGPSI addresses compliance in a “Process Centric” manner. In other words, the compliance is looked at at each process and the entity is looked at as an aggregation of processes. Hence each process including each of the AI algorithms used becomes a compliance subject and has to be evaluated for

• a) What Personal Data enters the system
• b) What processed data exits the system
• c) Is there an access to the data in process within the system by any human including the “Admin”.

If the algorithm is configured for a black box processing with no access to data during processing, we can say that personal data enters in a particular status and leaves it in another status. If the entry status of personal data is “Identifiable to an individual” it is personal data. If the exit status is also identifiable to an individual, then the modification from entry status to the exit status and the end use of the exit status data should be based on the consent.

If the output data is not identifiable to an individual, then it is out of scope of DPDPA. The blackbox is therefore both a data processor and a data anonymiser. Since ITA 2000 does not consider the “Software”a s a juridical entity and it’s activity is accountable to the owner of the software, and the owner of the software in this case had an access to identity at the input level and lost it at the output level, the process is similar to an “Anonymization” process. In other words the AI algorithm would have functioned as a sequence of two processes one involving the personal data modification and another as an anonymization. The anonymization can be before the personal data processing or after the personal data processing.

Under this principle, the owner of the AI is considered as a “Data Processor” and accordingly the data processing contract should include the indemnity clause. In view of the AI code being invisible to the data fiduciary, it is preferable to treat the AI processor as a “Joint Data Fiduciary”.

There is one school of thought that “Anonymization” of a “Personal Data” also requires consent. While I do not strictly subscribe to this view, if the consent includes use of “Data Processors” including “AI algorithms”, this risk is covered. In our view, just as “Encryption” may not need a special consent and can be considered as a “Legitimate Use” for enhancing the security of the data, “Anonymization” also does not require a special consent.

Hence an AI process which includes “Anonymization” with an assurance that the data under process cannot be captured and taken away by a human being, is considered as not requiring consent.

This is the current DGPSI view of AI algorithm used for personal data processing.

Open for debate.

Naavi

Today’s Economic Times carries an article “Banking Access at Risk if you seek to delete Credit Data” is an argument for exempting Credit Information Companies from the rigours of the Data Protection Act.

Naavi.org has been in the forefront of raising a complaint about CIBIL which collected enormous amount of data under its special status and transferred its share holding to a foreign company placing personal information worth lakhs of crores of rupees in the hands of a foreign company without any consent from the data principals.

Naavi.org has detailed its concerns in the following articles

1: Is TransUnion-CIBIL guilty of Accessing Critical Personal Data through surreptitious means?

2.CBI Enquiry is required for finding the truth behind TransUnion taking over CIBIL

The essence of these articles is that the value of data assets owned by CIBIL was transferred to a different company and outside India in a form which can be called “Data Laundering”.

Today’s article in ET threatens that if any Indian data principal has the vision of using the DPDPA and asking for deletion of personal data with CIBIL, then they may be denied further loan facilities by the Banks.

The threat is attributed to an IT Ministry official but has a serious flaw in the argument.

At present the CIC (Credit Information Company) comes into a picture as an agent of the lending Bank and not through any direct relationship with the data principal. The Banks may obtain a consent to share the credit information with the CIC. However, if the Bank deny the loan solely because the data principal refuses to permit sharing of his data with the CIC it could come in conflict with the “Right to withdraw Consent” and “Obligation to erase on completion of the consented process”.

The data principal has no direct relationship with the CIC and hence it is the responsibility of the credit giving Bank to get the data with the CIC removed after the closure of the loan when the purpose of the consent is over.

A Bank which has given a loan cannot indefinitely keep the previous loan data that too with a third party processor on the speculation that the person may apply for another loan in future and the information would be useful at that time. This would be a speculative retention of the data.

Further if it is required to keep the information for a reasonable period for tax or other purposes, the consent may be used by the lending Bank to keep the data with itself. Since no processing is involved, there is no case for allowing the CIC to be a personal data storage company on its behalf.

The purpose for which the CICs were established was to prevent a borrower from borrowing from multiple Banks and end up being a defaulter. However it is presently being used as a Big Data Processor who will analyze every EMI and determine the repayment efficiency.

While we can accept the need for such an agency from the point of view of credit discipline, it cannot be allowed to function without a direct consent from the data principals.

Hence the system of Banks taking a consent in their loan applications to share the data with the CICs, it is better if CICs become the specialized Consent Managers under DPDPA for the exclusive purpose of providing consent in the loan application context.

For this purpose they need to be licensed by the DPB and follow the Data Protection discipline that the DPDPA 2023 imposes in the form of Consent and Legitimate use.

One of the requirements of accrediting such consent managers should be the “Fitness criteria” which should include that the CIC should be an Indian Company with Indian promoters and should not be used for data laundering.

Referring to the article, in case a Bank refuses to provide the loan for the sole reason that the consent to share the data with a CIC, then it may be disputed as an unfair condition attached to the service.

The reading of DPDPA 2023 is that personal data can be processed only under Consent or under Legitimate interest or under Exemption. The legitimate interest clause has “Legal obligation” as one excuse so that if the disclosure of personal data is a legal necessity for the Bank, the sharing may be acceptable. However, after the loan is repaid there is no contractual relationship persisting between the Bank and the Customer and hence the Bank cannot refuse to get the data with the CIC erased.

At the time of the new loan application, it may be in order to ask for information about previous loans. In between it may be acceptable as a legitimate interest to retain the data for a reasonable period by the Bank with itself and not with the CIC.

Some of these issues will perhaps go to a Court shortly after the Act becomes fully effective and will get the clarity.

In the meantime FDPPI’s DGPSI adopts a “Consent Management Framework” that ensures that the consent is obtained by the Bank from the data principal to share the data with the CIC at the time of granting of a loan and take it back after the loan is closed.

In the instance when a loan is closed and the Bank or CIC defaults in maintaining the accuracy of information resulting in the lowering of the credit rating of the data principal, the Bank has to be take on the liability under DPDPA. CIC will be liable to the Bank under the contract and also under ITA 2000.

Beyond this general implication of DPDPA, we have to wait and see of MeitY tries to bail out the CICs from their responsibilities in which case a challenge in the Supreme Court is inevitable.

Naavi

In the last one week, Naavi has been looking at the WebDTS prospects of some of the websites and it has revealed some challenges that throws light on the overall DPDPA 2023 compliance.

Many of the WebDTS Certification requests have failed because the way the website Privacy compliance is currently designed is generally faulty. There is a need for correction.

Yesterday, Naavi had an extensive discussion with some industry experts to understand why most of the Websites may not qualify for the FDPPI’s WebDTS tag. The reasons are many and there is a need for further education of the Website Owners to make them appreciate the compliance requirements drawn up by Naavi/FDPPI. A brief attempt is made here to explain the reasons for wide prevalence of non compliance and more information will be published from time to time as a part of DGPSI compliance framework.

For example, one of the basic principles of DGPSI is that “Purpose Oriented” collection and processing of personal data is the essence of Privacy Commitment. This requires that the personal data collected has to be minimized for the required purpose at the time of collection and retention.

A Company is a bundle of many personal data processing activities and the Website is one activity where the purpose of personal data processing is “Enabling a Visitor to receive the information published”. However, a Website can also be used for conducting E Commerce. It can also be used as an application interface. The “Information publication” itself may be at the primary level of “Read what is published” which can be extended to “Request for further information”.

In view of the different requirements of a website for different purposes, the collection, retention, disclosure, requirements for each purpose differs.

For example, if the purpose is “Enabling a visitor to receive information as published” (fundamental objective of a website), then there is no need to know the name or email address or the mobile number of the visitor. The technology may require knowing the IP address of the visiting device without which the basic IP handshake cannot occur. Then there is a requirement to know whether the device is a mobile or a computer so that the GUI can be dynamically modified based on the browser and device. For these purposes the name, email or mobile is not required. The information collected for such browsing can be through session cookies which some call as “Essential Cookies”. Such session cookies get automatically purged when the session ends.

However if a website decides that We will retain information about the BIOS identity of the device, and that will help me use the same display configurations when the visitor visits next time, then they may use “Persistent Cookies” which need to be retained and stored. If this information is not capable of identifying the human visiting the website, it does not constitute collection of “Personally Identifiable Information”.

Hence the DPDPA compliance is restricted to ensure that there is no persistent cookie and even if present, the cookie is not collecting personally identifiable information.

The Level 1 of WebDTS needs to enable just this data minimization requirement. We can discuss the higher levels of WebDTS compliance in subsequent articles.

It is an observation that even this Level 1 compliance of a website is not available with most websites. We may share some of the following observations in this regard so that we all can strive towards a better compliance eco system.

Some Observations

1.The lack of compliance could be because the hosting of the website is outsourced and the owner of the website may not have complete knowledge of what cookies are working on the website and what are their purposes. As a result the personal information may be collected by the hosting company and used for its own marketing efforts without a proper consent.

2.In the event a website works only with a basic functionality of company information being displayed and no personal identifiable information of the visitor is collected, then the website is compliant with DPDPA by default. But most websites have a purpose beyond presentation of information.

3.Since the website owner is dependent on the hosting provider for cookies used during hosting, it may be preferable to declare the identity of the hosting company and declare him as responsible for any undisclosed cookies collected by him.

4.It is also possible that the website may host cookies other than what the hosting company may install. This could normally come from data analytics companies including Google Analytic tools or associated Advertisements which are part of the Content monetization objective.

Such cookies may also be collecting only information which is not personally identifiable information but the cookies may be “Persistent” and may be stored and accessed beyond the session.

Further some information like Bios information and IP information may be used along with other information available with the analytics company and could lead to eventual identification of the individual. This is a consequential risk and the website owner may have to have some disclaimers in this regard.

5.The Base level of WebDTS (Level1) may therefore include such disclosures as may be necessary to declare that the possibility of undisclosed persistent cookies (beacons) hosted on the website by others exists and such companies will be considered as “Joint Data Fiduciaries” and are notified to identify themselves to the owner.

6. At the base level of WebDTS, some requirements of ITA 2000 compliance such as updation of declared privacy policy, provision of grievance redressal information, identifying the name and address of the website owner are considered essential.

7. A website is free to take a stand “We donot collect any personally identifiable information and hence this website is outside the scope of DPDPA 2023”.

8. If the website declares that it still wants to present a more detailed “Privacy Policy”, it has to declare if it is in compliance with the “Privacy Notice” under Section 5 of DPDPA 2023 which may include the 22 language criteria.

9. In a process wise compliance, the “Website Visitor Personal Information Process” may not constitute an activity that may qualify as an activity of a Significant Data Fiduciary. However, in view of the way Section 10 of the DPDPA is worded, the company may otherwise be considered as a “Significant Data Fiduciary”. If so, one interpretation could be that the name of the DPO should be displayed on the website. If however, there is a proper disclosure of the process, the identity of an organization as a “Significant Data Fiduciary” is also “Process Dependent” and need to be disclosed only when a consent to the related process is sought.

10. If the website opts to collect personally identifiable information through a secondary process such as “Request for Service” placed through the website, a separate Privacy Notice may be displayed in conformity with the DPDPA Section 5 and 6.

The scope of WebDTS certification is limited to “Compliance of DPDPA 2023 for the processing of applicable personal information collected from the visitors of the website”.

The most important compliance requirement is to ensure that the Objective of the website is declared as “Publishing of information to the public” and a separate Privacy policy declaring that there is no collection of personal information in the process .

Where the website wants to use the website as a gateway to further services, it is advised that the Privacy policies/Notices for each of such subsidiary services are separately displayed before requesting for the service which shall be of the “Consent Grade”.

If a company opts to use the website for not only information dissemination but also for other purposes (even if it is not e-commerce) as is the prevalent practice, the Privacy Policy becomes a Consent request for multiple purposes and it has to be appropriately written to meet the requirements of “Clear” and “Precise” standard along with “Consent” as per “Verifiable standard”.

Getting a WebDTS compliance tag (Level 1) is therefore possible with a proper revision of the Privacy Policy. However the expectation of FDPPI is that a website as a whole needs to be compliant with DPDPA 2023 and it appears that in India at present there are not many websites that will pass this test.

In the coming days, we shall discuss the different requirements to be met by a website if it has to get the WebDTS seal without the qualified seal of (Level 1). I suppose other experts in DPDPA 2023 may debate the compliance requirements that Naavi/FDPPI may consider as “Necessary”.

Naavi

Every organization handles Corporate E Mail process. Just as having a website is one of the Digitization steps taken by all companies, having a corporate e-mail system is another early step in the process of digitization of business.

I would like to raise some issues on the application of DPDPA compliance related to handling of the E Mail system by a company for the industry professionals to debate.

For handling the email requirements, an organization sets up an e-mail server often in the domain name which is also used for its corporate website. For example abc.in is the domain name of the company and @abc.in is the email IDs used by the company.

The @abc.in emails are allocated to the employees such as vijay@abc.in. It is also allocated to certain positions in the company such as dpo@abc.in.

Outward emails are sent by different designations such a hr@abc.in or purchase@abc.in or marketing@abc.in, service@abc.in or support@abc.in etc.

Outsiders send e-mails to these email addresses and also to employees such as vijay@abc.in. E Mails to vijay@abc.in may be personal or business related. It may also contain a CV requesting for job. This could result in accumulation of unstructured personal data in the company’s assets.

Many companies are using and will continue to use “E-Mail Marketing” as a part of its corporate strategy where they will send out e-mails to their prospective customers.

In such cases different compliance issues may arise.

If a Company has to be compliant with DPDPA 2023, it has to therefore develop a policy for handling the e-mail identity of the employees.

We may recall the case of Cavauto S.R.L where the regulator fined the company for accessing the email customercare@cavouto.com in the PC of the Company allocated to the employee under the premise that there was no proper notice to the employees that their personal emails could be accessed even in the company asset and business email.

Can such a situation arise in India under DPDPA 2023?

If so, what compliance measures could mitigate this risk?

Let’s debate. Send your views …to naavi ..or comment below..

Ujvala/FDPPI ‘s service “E Mail DTS” is designed to evaluate the risk mitigation efforts towards meeting the challenge of Personal Data Processing in the E Mail management process.

Naavi

As followers of Naavi are aware, Naavi had introduced a service lookalikes.in based on his patent application around 2002. The objective of the service was to provide a third party disclaimer on the presence of confusingly similar domain names.

For example the accompanying note on the website indicates that Naavi.org does not have relationship with the site navi.co and related websites.

It is advisable for the other sites also to display similar disclaimers so that mutual distrust and trademark related disputes can be avoided.

This service was introduced long time back but was not pursued. The patent application also had to be abandoned subsequently.

The reason why this service was contemplated was to prevent the potential misleading information that an alternate website could give to a visitor. As a part of the compliance of a website it is considered that a website owner needs to take some reasonable steps to warn the visitors that there could be alternate sites with similar names that the visitor should be wary of.

Hence this is made part of the WebDTS service in whatever form it can be made available at present. Some improvement of presentation may be expected.

PS: Requests for WebDTS can be booked through FDPPI website.

Naavi

PayTM is a well known brand when it comes to online payments. If India is proud to say that even vegetable vendors are using UPI, a large part of the credit should go to PayTM. It is sad to note that currently this reputation got a hit because their sister entity which had a Payment Banking license has run into problems with RBI in terms of compliance of regulations.

Using its brand value, PayTM had also obtained the license as a Payment Bank and called it PayTM Payment Bank. (PPB). However the regulations for Banking being much different from the operations of an intermediary service as a payment transfer mechanism, PPB encountered regulatory issues. Accordingly, on March 11, 2022, RBI had invoked Section 35A (RBI Act) powers and stopped acceptance of further onboarding of new customers.

PPB under its Payment Banking license was otherwise allowed to accept deposits of upto Rs 2 lakhs which could not be used for lending but could be used as a deposit for other services. (eg: remittance services, mobile payments/transfers/purchases and other banking services like ATM/debit cards, net banking and third party fund transfers.). After two years of observation and audits, RBI has now come to the conclusion that the PPB has failed to implement all the regulatory requirements and therefore issued a further notice on March 31, 2024 to stop further operations except allowing the customers to withdraw their current deposits in different services.

While PayTm and Paytm Payment bank are two different entities and 70% of revenue of PayTM group is said to come from its PayTM business and not PayTM Payment Bank business, the reputation loss and consequential damage to the stock market value cannot be avoided.

We have to wait and see how PayTM comes out of this problem. Currently the Company is yet to provide appropriate clarifications by way of disclaimers though the promoter has made some press statements. As of today, Paytmbank.com does not have any disclaimers about its “Arms Length Relationship” with PayTM.com which should have been one of the first things to do. (P.S: This sort of risk would be noted under the WebDTS compliance measure suggested by FDPPI)

In the meantime, we would like to highlight two aspects of policy failures which have led to this situation.

Firstly, RBI was not prudent in trying to convert FinTECH companies into Banks. Naavi.org had discussed some of these issues in the earlier articles. (https://www.naavi.org/wp/new-banking-licenses-in-india/)

Recently we have also pointed out how RBI’s over enthusiastic measures on Account Aggregators have created a set of licensees who may not be compliant with most of the regulatory requirements required for the conduct of Banking.

The “Reasonable Security Practices” required by these Banks and the Banking regulatory measures were un-natural to the “Innovation driven Fintech Industry” and it was wrong for RBI to assume that “Banking” and “E-Commerce” were two faces of the same coin.

This policy error by RBI can be considered as the main problem that has led to the current situation where the non-compliance has forced the RBI to take drastic steps.

The second policy failure is in the policies of the licensed entities who tried to raid on their current brands and started Banking activities under the same umbrella name. As a result today when the Banking business needs to be closed down for reasons of non compliance the damage to the parent brand is inevitable.

Clarification issued by the company is available here:

https://timesofindia.indiatimes.com/gadgets-news/will-your-paytm-work-after-february-29-this-is-what-ceo-vijay-shekhar-sharma-has-to-say/articleshow/107348660.cms

RBI should realize that when an existing IT Company gets into Banking, one of the strengths are their current operations and hence the extension of their IT infrastructure to the new business is a natural inclination of technology architects. It is perhaps the business strategy of aggregating their current IT infrastructure for better productivity.

However, from Compliance perspective this introduces certain risks which have come to hurt PayTM.

We may foresee similar issues when MeitY allows the RBI licensed Payment Aggregators as “Consent Managers” under DPDPA 2023. It is for this reason that Naavi has been advocating that the Consent Managers under DPDPA 2023 are different from Account Aggregators under RBI license.

We have advocated that “Licensed Consent Managers” under DPDPA 2023 are more like the “Licensed Certifying Authorities” under ITA 2000 and when Meity formulates the notifications, it has to avoid the mistakes committed by RBI in allowing brand sharing with an existing unrelated business with the licensed business.

Hence we debate that RBI was wrong to call E Commerce Companies as “Banks” in the first place and hence its licensing terms were faulty. Had PayTM Payment Bank been called as “PayTM E Commerce” or just “PP Bank” either disassociating the Bank from the name or disassociating the parent company name from the licensed entity, the damage would not have been as much as it is now.

(P.S: It is also time to point out this branding confusion in respect of Naavi.org and Navi group of companies promoted by the erstwhile Flipkart promoter. Authorities who have licensed navi.co.in as a business entity need to be aware that if they fail, they will be hurting the reputation of Naavi and if Naavi.org gets into bad reputation, it could hurt navi.co.in. It is for this reason that the existing brand of Naavi has issued a notice to navi.co.in that their “Lookalike-Imitation” is not a good strategy. So far their arrogance has made them ignore this mutual risk.

Naavi

PS: Views expressed here are the personal views of Naavi

Also refer:

The Watal Committee Report on Digital Payments..1

https://www.rbi.org.in/Scripts/BS_PressReleaseDisplay.aspx?prid=32615

https://cleartax.in/s/payment-bank-license