How can I get more than 10 years of transaction history from my bank? I will shamefully admit that it was only in the year 2021 that I finally built my own bookkeeping system. Yes, I should have done it 10-20 years ago, but I didn't. So now I'm in this situation: First of all, I logged in to my bank (Nordea in Sweden) and discovered that it now only supported dumping data from not very long ago at all. I think it was just a couple of years, or even months. So I contacted them. They responded that they &quot;will not&quot; give me any data that is older than 10 years, but that I can exploit a secret bug (yes, they actually said this...) on their website to basically ignore multiple error messages and force their website to keep feeding me data, until it hit 10 years back. That's when it stopped feeding any data, so I dumped the CSV and exported it into my own local database. So now I have all my bank transactions between the first day of 2009 up until today. (Yes, that &quot;10 year&quot; limit was slightly off, so you clearly cannot trust a single word they or their website claims...) I also tried to analyze the JSON data blobs and modify the requests to fetch older data, but it just displayed error messages then. But obviously, the bank does have all my old transactions in their real database. I don't believe for a second that they have actually thrown it away, or that they ever will. So why won't they give it to me? They didn't state a reason, and I kept asking repeatedly in different ways, but they consistently just told me that data older than 10 years isn't available or some cryptic sentencing like that. They didn't explicitly mention it, but many other companies keep using this stupid &quot;GDPR&quot; nonsense as an excuse to not give me their data, and perhaps this is somehow related to this. But still. This is my own data. Not the data of somebody else. It's my personal bank account, and I'm logged in securely to prove my identity. I'm not asking for this via e-mail! Clearly, they are unwilling to hand it out, but is there some way for me to force them to do so against their will? That is, without &quot;going to court&quot;. It really annoys me that I don't have a full transaction history to analyze. Can they be forced/persuaded? PS: I've even offered to pay them money for it, but even if you pay them, the time limit is still &quot;10 years&quot;.
Businesses only keep transaction data for as long as they have to For a live loan account they will keep transactions while the account is live and then for as long as local law dictates (it varies but 7 years is typical). For transaction accounts it will generally be only for as long as required by law - typically what is required by tax law (again 7 years is typical) or as long as you can sue them under statues of limitations (2-5 years). Banks (and other businesses) do not keep records indefinitely. 10 years seems more than necessary.
An incomplete list: Getting the money. How did you plan to get paid? Credit card? Paypal? Integrating those into a website in compliance with their terms of service is not easy. (I wouldn't touch credit card numbers, in particular, even with a ten-foot pole. Too much liability risk for weak implementations. Too many highly skilled attackers to pounce on any mistake.) Distributing the App. Places like the Apple App Store have their own terms of service, especially regarding payment and in-app purchases. At a guess, Apple would reject your app, but if they allowed it, how does your withdrawal policy fit with the 30% cut they want from the initial transaction? Holding the money. So there are user accounts with a credit balance that can be withdrawn again. Would you be able to repay them if all users withdraw at the same time? Where do you keep the money? Currency risks. Say international customers pay in currency A, which the payment provider transforms into currency B. Then they want their money back, but exchange rates have changed. What do they get? Knowing your customer. There would be money laundering concerns. Do you have the infrastructure to identify your customers? Can customers change the (re)payment method from one account to another? Can you handle withdrawals if a user no longer has the same credit card, for instance? Scammers leaving you to hold the bag. Say a scammer tricks a victim into making a deposit, and then finds a way to redirect the withdrawal (see above). Would you be able to deal with the legal and administrative fallout?
Normally the statute of limitations is five or six years (I think it's different between Scotland and the rest of the UK). The reason for the limitation is that if your employer asks for money back, you obviously should be able to defend yourself, for example by proving that you never received that money. After five or six years it is assumed that you wouldn't be able to provide any such evidence, so nobody can ask for the money back anymore. That's not specific to overpaid wages but quite general. In addition there is the question whether the pilots should have known they were overpaid. For example, I'm quite happy with my salary, but if it was less, I would look for and find a different job that pays better. If the company claimed in five years time that I had been overpaid all the time, then I would say that if they had given me the "correct" lower payment, I would have found a better job elsewhere, so asking me to repay the money seems quite unfair. (Why do you need to defend yourself? Maybe your salary was £3,000 per month. Someone in the right position records that they are paying you £4,000 but puts £3,000 into your account and £1,000 into their own. Then that person has an accident and their replacement finds that you were overpaid according to their records.)
I think haveibeenpwned would be legal in the EU because it carries out a task in the public interest (Art. 6(1)(e)), and it shares no more data then necessary, for example you can search for a password, but it would not show you the emailaddress which belongs to that password. It would also be legal for you to hold a copy of a leaked database, but only if you have a legitimate interest (Art. 6(1)(f)) to have it. Being a security company does not change that, but finding a legitimate interest might be easier. If you have a legitimate interest to hold a copy of a leaked database, it does not mean you can use it in any way you like. For example testing if the password still works, is very likely illegal everywhere in the EU. But I'm not familiar with the UK laws.
This is less of a compliance question, and more of an infosec question. On one hand, you want to be able to restore access to an account to users who have lost their access. On the other hand, you must prevent unauthorized access e.g. from hackers. These factors must be balanced. Whether you'll fulfil a data subject access request will generally follow the same criteria as deciding whether you'll reset someone's access credentials, so I'll mostly discuss identity verification in general. Trying to validate names is generally pointless from a security perspective, since the name on the account might not be real, or because validation documents like scans from a passport can be easily forged. When a service has identity validation measures like requesting a copy of photo ID, or requesting a photo of you holding up a validation code written on paper, that doesn't actually help validating that the person requesting access is the account owner, but that the person requesting access appears to be a natural person, and now documents about their identity are on file. A lot of information like names, birthdates, or addresses is also not at all secret and could be easily guessed by a malicious actor. Most websites work by equating access with control over an email account. If you can receive a password reset code over email, you have access. In effect, this delegates the responsibility of account recovery to the email or OAuth provider. So the issue is what happens when someone loses their email account, which is not entirely uncommon for accounts that are multiple years old. One reasonable (and likely GDPR-compliant solution) is to deny access when someone loses their account. Quite a lot of services operate this way. A milder form of this is to email the old address that someone is trying to take over the account, and turn over the account only if you have other evidence of ownership and there has been no reply over multiple weeks. Since this is part of an identity verification measure, I don't think the GDPR's normal 1 month deadline would apply. However, this approach is very risky: an attack can succeed through the mere inaction of the true account holder, and it would arguably be a data breach if you give access to the wrong person – safer for erasure requests only. Also, emails like “click here or we'll delete your account” look a lot like spam (I get a lot of those about alleged problems with my Paypal account). A potentially more reasonable approach is to use questions about the account to verify ownership. When did they create the account? When did they last use it? Can they answer questions about non-public content of the account? (But don't let an attacker choose the questions!) You see some older sites that ask the user to select a “security question” for recovery purposes. But this isn't a best practice – they are frequently the weakest link in an authentication system. If the user answers truthfully, the answer may be easy to guess or discover for an attacker. E.g. the infamous “what is your mother's maiden name” question is horrendously insecure in the age of Facebook. If the user provides a more secure answer, that is essentially just another password that's even easier to lose than an email account. High-value accounts typically offer a secondary authentication method as a fallback. E.g. my bank can send me new access codes via physical mail. GitHub can optionally link a Facebook account for recovery purposes. But these measures would be overkill for most cases. Especially collecting a physical address for the sole purpose of offering account recovery would likely violate the GDPR's data minimization principle, though it may be fine when the user opts in with freely given consent. To summarize: what you're trying to do is extremely difficult, because you've need to balance different security aspects: keeping malicious actors out, and letting legitimate account owners in. Whereas I'd resolve that by denying any account recovery or subject access requests, other approaches exists with other risk profiles. The GDPR requires you to perform reasonable identity verification measures, but what is reasonable depends on the business context and is ultimately an infosec question.
The way you describe this UUID, it is pseudonymous data (see GDPR Art 4(5) and Recitals 28–29). That is, it is not directly identifying, but you have a mapping between pseudonyms and identifiers that can be used to re-identify this data. Effective pseudonymisation requires not only that the data is logically separate, but that there are effective organisational and technical measures preventing re-combination by unauthorized persons. Alongside with encryption, pseudonymisation is one of the safety measures that the GDPR explicitly requires whenever appropriate (see Art 25, Art 32). Pseudonymous data is still personal data, because you can easily re-identify the data. The PII concept is US-specific and is misleading in a GDPR context, where it is not the inherently identifying characteristics of the information that matters, but the realistic ability of the data controller to single out data subjects to whom this data relates (compare Art 4(1) and Recital 26). However, were you to irrevocably erase the UUID–email mapping, things are more tricky. There is no longer any connection with directly identifying data, so this data might be anonymous. On the other hand, such a persistent UUID still allows you to recognize/distinguish persons, so it might still be personal data. This might be the case especially when the UUID is used in long-lived cookies of website visitors, thus matching the GDPR's concept of an “online identifier”. This conclusion could be avoided by limiting reuse of UUIDs, e.g. creating a new UUID after some context-dependent appropriate duration. The GDPR does not require all data to be stored in the EU, but requires international transfers of personal data to have sufficient protections. If you're processing these data in countries without adequate legal protections (like the United States), additional safeguards have to be used. Pseudonymisation could be part of such safeguards, and has been suggested by some data protection authorities in the wake of the Schrems II ruling. However, pseudonymisation alone does not make the international transfer legal, it is more of a strategy to reduce remaining risks. I think that your systems has a good chance of being OK, but not neccessarily so. If in doubt, perform a DPIA and possibly consult your data protection authority under GDPR Art 36. If feasible, storing/processing data only in the EEA or in countries with an adequacy decision will simplify compliance. Safeguards such as pseudonymisation could be strengthened by rotating UUIDs, and by restricting access to the table with identifiers.
So I suppose we basically need to disclose the exact geolocation of the datacenters that store this kind of content. That is incorrect. You need to identify a place of business where federal investigators may inspect the records without first making an appointment for access. The location of cloud storage is not particularly relevant. is it possible in any way to achieve compliance with 18 USC 2257A while using Google Cloud Storage (Or perhaps any other cloud storage service)? Yes. You must store the records as required by the statute and by the regulations issued under the authority of that statute, 28 CFR Part 75. I only scanned the regulations, but it seems that the &quot;location&quot; of the records is the place where they are available for inspection, not necessarily the place where digital files are stored. (The regulations also provide that you may indeed keep the records in digital form.) But consider, for example, what would happen if the FBI came knocking for an inspection and a local utility company accidentally severed the fiber cable on the next block. Such a network outage happened at my company a few years ago, and the incident disabled all of our redundant networking, so we had no internet access whatsoever for several hours. The investigators would probably tolerate such a disruption, but it is probably better to have a copy on site in addition to any off-site copies you might have. Regardless, you should hire a lawyer with relevant experience, because you need advice from someone who can find out whether there has been any litigation that may have a bearing on your rights and obligations, and you should find out what state and local law have to say about this, if anything. This is a criminal statute, and trying to protect yourself from criminal liability without qualified legal advice is quite possibly going to leave you vulnerable.
It is legal for a company to ask for any information they want as a condition of doing business with you, so long as their request isn't proscribed by law. I don't know of any jurisdiction where a request for banking or credit information is illegal. (In this case, however, it does seem like you are being phished. You could report the matter to your country's consumer protection agency.)