Naavi.org

Personal Data is a key corporate asset in this time  of Data Driven Business. Organizations collect specific identifiable personal data some times in a structured manner  through a form associated with a service request. This is an ideal situation when the entire set of data elements  are collected in one shot along with a proper notice, purpose linkage, data minimisation etc.

But in actual practice an organization accumulates individual data elements often not specifically identifiable with a data principal. The “Personal Data identifiers”  therefore become available but cannot be associated with any identifiable individual. Even when a “Name is available”, if it is concluded as belonging to a  specific person which the Data Fiduciary knows, there  could be a risk of mismatch. Hence an organization has to wait for accumulation of at least 2  parameters which together create an identity.

To be on the safer side  it is better to have 3 parameters to identify a person unless one of the two parameters happens to  be a “Biometric” information.

Under “Biometric” one can take the  finger print, the facial photograph, the voice sample, DNA etc.

A Unique Government ID such as an aadhaar number or PAN number could perhaps have been considered equivalent to  the biometric for  identification but for the current state in India where these are not reliable.

In the absence of  such “biometric ” data, there should be atleast 3 parameters such as the name, email and the phone to reasonably identify an individual.

Once the identity of an individual can be fixed with a reasonable certainty, information such as a “Behaviour Profile” or a “Health report”, “Credit Report” can be added to the personal information and will also form the data that needs to be protected under the Data Protection Law.

To capture this nature of Personal Data as a “Set of Data Parameters”, Naavi adopts the following layered approach to recognition of Personal data.

Level 1: Operational Identifier: Name (Assigned by the Data Principal)

Level 2: Organizational Identity: Employee ID, Customer ID (Assigned by the Data Fiduciary).

Level 1+Level 2 will have confirmation from the data principal and the data fiduciary provided the two are linked with acceptance from both. If the two identifiers are present independently they donot form an identity till they are associated with a bond of conformation. This could be through a request for confirmation sent from one of the two to the other and its acceptance by the other.

Level 3: Contact Layer: E Mail address, Mobile number

Level 4: Biometric layer: Finger Print, Facial Photograph, Voice Sample, Dental X ray, DNA etc.

Level 5: KYC layer: A KYC report generated by a trusted third party “Joint Data Fiduciary”

Level 6:  Report level: Behaviour Profile, Health Report, Credit Report etc

We can organize these levels into a hierarchical system to move raw data as it flows into an organization into a “Provisional Personal Data Store”, process it periodically and move  it to the next level

Naavi

An Audio Summary is here:

Listen here

When ITA 2000 became a law in 2000, it  prescribed a method of authentication in the form of Digital Signatures (Now expanded as Electronic signatures) as the only means of authentication of an electronic document. This provision meant that an un-digitally signed electronic document could not be considered as “Signed” document for contractual purposes.  Hence there was a need for alternative methods of recording an online “Click Wrap Consent”.

The introduction of Aadhar based e-sign has made it simpler to obtain legally acceptable e-signed consent online but it still has a cost and the issue of use/disclosure of Aadhaar as for signing.

Naavi has suggested use of CEAC Drop Box as a kind of alternative to obtaining third party confirmation.

This problem has now got into prominence since “Consent” under DPDPA needs to be properly authenticated.

In the meantime there is the issue of “Stamp Duty” for digital contracts.  During 1999-2000 when ITA 2000 was enacted, India was one of the early countries to adopt the mandatory digital signature system. At that time many countries including India did not specify that stamp duty was payable on electronic documents and some countries specifically mentioned that since there was no viable system for payment of stamp duty for electronic documents, it was exempted. India did not specify the reason but the Indian stamp act at that time could be interpreted as excluding electronic documents from the list of documents requiring payment of stamp duty.

The keeping  of immovable property transfer documents from Schedule I of ITA 2000 was also linked to this problem.

During that time Naavi had introduced the “Digital Value Imprinted Instrument System” (DVIIS) as a system which combined the “Adhesive Stamp System” then prevailing with the “Digital Value Creation” in the back end server to enable a “Hybrid DVIIS coupon” that could be affixed on an instrument of contract along with payment  of stamp duty online. This was in an era where there was no UPI system. It was an innovative system was even presented to the Stock holding Corporation before they came up with the e-stamping of non judicial stamp papers but was rejected in favour of an alternative foreign system.

Over the years, E Governance has moved forward and many State Governments passed laws to mandate payment of stamp duty even on electronic documents.

in September 2022, even the ITA 2000 was amended to remove the immovable property documents from the list of excluded documents for recognition under ITA 2000.

Many options are now available for online payment of stamp duty to the treasury and obtaining an  acknowledgement such as a QR Code/Bar Code Receipt which can be affixed on an electronic document.

Hence currently the electronic documents are considered not excluded for stamp duty.

Kindly consider the previous views expressed in this website as suitably amended due to change of law.

We now however need to ensure that the nature of an instrument needs to be properly identified to distinguish “MOU” from an “Agreement”. We also need clarity on wehther MOUs also need minimal stamp duty or not.

MOU s are considered a documentation of intention and if organizations use MOUs to record their dealings with associates there may be a claim of stamp duty at some level.

While organizations may be fine with considering that the MOUs are not legally enforceable, the possibility of “Penalty” for not stamping the document even when not enforced in a Court could make it a “Compliance Issue”.

In a Privacy Contract where the notice asks for certain permissions which amount to monetization of personal data, there is an underlying financial value. Hence the “Consent” provided in the form of an “Acceptance” can be considered as an “Electronic Document that requires payment  of Stamp Duty”.

If the  data principal raises this issue with the Adjudicator and claims compensation, there could be a demand of the Stamp duty authorities that 10 times the  normal stamp duty on agreements need to be paid and also linked to the value of the underlying data on which a dispute has arisen. Otherwise the document  becomes infructuous both for lack of digital signature and lack of stamp duty payment.

It is necessary for MeitY to consider this ambiguity and  ensure that there  is a clarity on

a) Recognition of Click Wrap Contract which requires amendment of ITA 2000

b) Exemption of Stamp Duty which require amendment of several State Acts on Stamp Duty.

Since “Personal Data” can be “Nominated” DPDPA 2023 has already recognized the “Property Nature” of personal data and the established “Monetization” practices indicate a clear financial value for Personal data assets.

Hence if this ambiguity has to be removed, an amendment to ITA 2000  may be required.

Needs a debate..

Naavi