How to handle account deletion of user with financial information and/or otherwise liability related information So, I read a post on reddit the other day about a user unhappy with Binance (crypto currency exchange company) for only being able to &quot;disable&quot; his account but not &quot;delete&quot; it. Binance is used in Europe which means they must abide by the GDPR. Which states that a user may request information deletion. However, this information is related to financials. Meaning if they delete it and some government comes after them they could be liable. So which takes precedence in this situation? If they(government entity) prefer you to hold the financial information, couldn't any company argue that they can't delete user information for fear of be liable for.something?
The GDPR will probably not allow a successful demand for erasure in these circumstances. The company does not need to argue &quot;that they can't delete user information for fear of be liable for.something&quot; because GDPR art 17 1(c), 3(b), and 3(e) already make that case for the company. Lets look at the relevant law. GDPR Article 17 reads in relevant part: (1) The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies: (1) (a) the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed; (1) (b) the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing; (1) (c) the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2); ... (3) Paragraphs 1 and 2 shall not apply to the extent that processing is necessary: (3) (a) for exercising the right of freedom of expression and information; (3) (b) for compliance with a legal obligation which requires processing by Union or Member State law to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; ... (3) (e) for the establishment, exercise or defence of legal claims. Art 17 Par 1 (a) only allows erasure when data are &quot;no longer necessary&quot;. But depending on how the purposes were worded by the Controller, they may well still be necessary Art 17 Par 1 (b) only allows erasure when consent is withdrawn and consent was the legal basis for processing. But a contract with the user is a much more likely basis for processing for a financial service. Art 17 Par 1 (c) requires erasure if the user objects and there is no &quot;overriding legitimate grounds for the processing&quot; but the needs to maintain financial records of a transaction is probably an &quot;overriding legitimate ground&quot;. In any case par 3 alloys erasure to be refused &quot;for compliance with a legal obligation&quot; or &quot;for the establishment, exercise or defence of legal claims&quot;. Financial records may well fall into one or both of these categories, at least as regards transaction data. In short it is far from clear that the GDPR will require erasure in these circumstances.
Are my assumptions correct? Yes, this is precisely the sort of thing that would fall under the purview of "the purposes of the legitimate interests pursued by the controller or by a third party", as it fundamentally enables you to deliver the service to the data subject, and its also difficult to argue that "such interests are overridden by the interests or fundamental rights and freedoms of the data subject" given its a fundamental part of delivering the service before any consent can be given. Its not the intention of the GDPR to solely require a direct relationship between the data controller and data subject, its intention is to allow the data subject to control more of the relationship than they did previously - in some cases, that control remains with the data controller, which is why not all of the lawful basis for processing rest on consent. So long as you ensure that the CDN provider has a relevant privacy policy and is identified as a data processor in your privacy and data policy then you are good to go. In my mind, this is similar to the issue of how the data subjects packets get to you from their computer - we aren't including all of the network providers who carry the packets between the data subject and the processor (despite the fact that those providers will have access to much of the same information as the CDN, such as IP address, source, destination etc), even though in many cases we don't know that information (for example which route it will take over the internet). The only difference here is that as the data controller, you know about the CDN and can include it in your policies, so you should.
I live in the EU and Facebook has blocked access to my account unless I accept their privacy rules, which means giving up GDPR protections. Facebook operates in the EU and has EU data subjects, therefore Facebook is subject to GDPR. You should be able to withdraw your consent. Article 7(3) says: The data subject shall have the right to withdraw his or her consent at any time. The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. Prior to giving consent, the data subject shall be informed thereof. It shall be as easy to withdraw as to give consent.
The GDPR's right to erasure is not absolute. Simplifying things a bit, you only have this right if the legal basis for processing was consent, because consent can be revoked freely; or the legal basis for processing was legitimate interest and the controller does not have an overwhelming legitimate interest in keeping the data. Legitimate interest always requires that the controller's legitimate interest and the data subject's rights and interests are balanced. A request for erasure shifts this balance but does not decide it. In practice, a request for erasure may be denied if the controller has legal obligations to keep this data, for example financial records; or the continued processing of this data is necessary for performance of a contract; or the controller has an overriding legitimate interest in continued process of the data. Note that contracts may have effects that survive termination of the contract. Note also that a contract might not involve the data subject as a party to the contract, the classic example being a postal delivery contract that necessarily requires processing of the recipient's personal data. In your specific example it seems that the legal basis was legitimate interest and that the data controller has an overwhelming legitimate interest to hold on to parts of your data for the purpose of fraud prevention. If you feel like the continued processing of the data is illegal, for example because the legitimate interest balancing was done incorrectly, or because the legal basis was consent, then you have the following remedies: You can lodge a complaint with the responsible supervisory authority. You can sue the controller before a responsible court for compliance, and for the (actual) damages that you suffered as a result from illegal processing. I'll point out that neither of these approaches is likely to work for you, because abuse/fraud prevention appears like a pretty standard case of overwhelming legitimate interest.
This would not be "legal jeopardy" per-se, really the only remedy that Stack Exchange would have in a case like this would be to ban both accounts. It would be different if you caused SE some kind of monetary/reputation damages to the site itself. From SE's Acceptable Use Policy: Identity Theft and Privacy. Users that misleadingly appropriate the identity of another person are not permitted. It seems your described scheme would violate that term. But this isn't a legal problem, just an operational one. You aren't violating any law (unless there are local laws against this) by paying somebody to "be you" on SE. The most that this would earn you and your cohort would be a ban and probably removal of the contributions.
You are right that a visitor of a website does not expect to be tracked upon opening the website. But when using Google Analytics configured in the way explained in my other post, the visitor is not tracked. At least not in a way which violates the GDPR. You worry about the cookies. I also found this article which also does and suggests to either: change the _ga cookie to a session cookie, so it will be removed when the browser is closed. To do this, set the Cookie Expiration variable in your Google Analytics Settings to 0. completely disable cookies. (GA does not require cookies). To do this, set the storage field to none: ga('create', 'UA-XXXXX-Y', { 'storage': 'none' }); If you do not disable cookies, cookies can be used for tracking, which is more general defined in the GDPR as profiling. Profiling is defined in Art. 4 GDPR as: ‘profiling’ means any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person’s performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements; Art. 22(1) GDPR disallows profiling. Therefore in the settings menu from Google Analytics you have to disable data sharing and data collection. So data will only be used for the analytics function. But because you have configured to Anonymize your visitors IP Address, the part of the IP address used for this, is no longer considered personal data. This is because approx. 250 other users share the same part of the ip address which is stored, so data is not distinguishable between those 250 users. The anonymisation used by google is currently considered good enough. At least by the Dutch DPA. This might change if someone proves it is not good enough anonymized. Note that I am not a lawyer either, but I have read from multiple experts that analytics can be a "legitimate interest", the same way marketing can be a legitimate interest. This way configured the privacy impact is considered very low. It is also very important to note that a DPA consideres GA Google Analytics compliant. Even if a court would not agree in the future, you are acting in good faith if you follow those instructions, so you will probably not be fined. The DPA does currently not suggest to change the _ga cookie to a session cookie, or disable cookies completely. Note that the GDPR does not require doing anything to make it technical impossible to track someone. If a website has access to the data to track someone, but "promises" not to do that, that is fine. And rules regarding the usage of cookies in general, is not part of the GDPR, but (currently) part of the ePrivacy Directive. Only the way to ask for consent for storing cookies is defined in the GDPR.
Yes, your transaction history is your personal data. Personal data is any information relating to an identifiable person. Your transaction history relates to you, and you're definitely identifiable for the bank. You have access to the transaction history to the app, which would probably satisfy Art 15 GDPR. You do also have a right to data portability under Art 20 GDPR which allows you to get your data in a machine-readable format – but strictly speaking this right only applies to data you provided yourself. You could try to explicitly invoke this right. Your GDPR rights must be satisfied without cost. Your bank almost certainly does provide machine-readable API access, in conformance with the open banking mandate from the Revised Payment Services Directive (PSD2, Directive (EU) 2015/2366). The Directive requires your EU member state to have passed a law that gives you “the right to make use of services enabling access to account information”, if you're already using online banking. However, the exact details of that right will depend on the laws in your EU member state. You might already be able to connect to your transaction history via Open Banking software such as GNU Cash.
Article 32 of the GDPR requires companies to adequately secure their data when handling data belonging to EU citizens. This also applies to cross border scenarios where data is transferred between countries. Technically speaking, the GDPR doesn't set a standard for security: you don't have to encrypt your data, use AES or RSA encryption, or hash and salt passwords. It is your choice on how to secure your data, though the GDPR does mandate specific ways to secure data. However, not doing so opens yourself up to two consequences: The European data protection supervisor is tasked with the enforcement of regulations. A company can be forced to increase their level security if a valid complaint alleging that inadequate security measures are in place is made There is a significant amount of security risk, and if a data breach occurs, the GDPR allows authorities to levy heavy fines. Especially heavy fines may occur if it is found that the data was not securely stored. So the answer is: A complaint to relevant authorities can force the company to take action, or they will lose access to the European market.