GDPR and Client Bank Statements: What Accountants Need to Know
A bank statement is about as personal as personal data gets: names, account numbers, salaries, medical payments, memberships, locations. When a client hands you their statements, you become a processor (or controller) of that data under UK and EU GDPR, and how you handle the file matters as much as what you do with the numbers.
This article covers the obligations that actually bite in practice, and the specific risk that statement-conversion tools introduce.
Your obligations in practice
GDPR does not prescribe tools, it prescribes outcomes. For client statements the relevant duties come down to a short list:
- Lawful basis and purpose limitation: use the statements for the engagement, nothing else
- Data minimisation: do not collect or retain more of the statement data than the work requires
- Security of processing (Article 32): protect the files in transit and at rest
- Processor accountability: know which third parties touch the data, and have agreements in place
- Breach notification: if a service you used leaks the file, that is your breach to report
Where statement converters create risk
The typical online PDF to Excel converter works by uploading the file to a server, parsing it there, and returning the result. The moment that upload happens, you have engaged a processor: you now need to know where that server is, how long the file is retained, who can access it, whether it is used for model training, and whether the provider will sign a data processing agreement. Most free converters answer none of those questions, and a statement sitting in an unknown server's temp directory is exactly the kind of exposure Article 32 is about. Side by side with an upload-based converter, that is the whole difference.
Emailing statements around has the same problem in a different shape: unencrypted copies proliferate in sent folders, inboxes and backups, and none of them have a retention policy.
Client-side processing changes the analysis
PivotBank takes a different architecture: the PDF is opened inside your browser using WebAssembly, and the file is never uploaded, so there is no server-side copy of the document and no retention question about it. Reading the transactions out of it does mean the transaction lines are sent, with the account holder's name, address, account number, IBAN and sort code stripped out first, and nothing sent is retained. You can verify the shape of that yourself: open your browser's network tab during a conversion and read the one request that goes out.
From a GDPR standpoint that narrows the assessment considerably. The document itself never leaves hardware you already control, so there is no copy of the client's statement on anyone's server to account for. What does leave is the transaction lines, with the account holder's name, address, account number, IBAN and sort code stripped out first, and it is not retained. Our privacy policy names every processor involved, which is what a due-diligence questionnaire will ask you for. The only data PivotBank stores is the extracted transactions of statements you explicitly save to an account, and those can be deleted at any time.
A sensible workflow for firms
A defensible client-statement workflow looks like this:
- Receive statements through a portal or encrypted channel rather than plain email where possible
- Convert locally (client-side) rather than uploading to third-party servers
- Import the converted CSV into your accounting platform, which is already covered by your DPA with that vendor
- Delete working copies of the PDFs per your retention schedule
- Document the flow once in your processing records, so the answer to "where does client statement data go?" is written down