Finance and advisory firms: PDFs with bank data, kept private

A finance office runs on documents that read like a map of someone’s whole life. Bank statements showing every coffee and every salary deposit. Tax returns. Account ownership certificates. Loan agreements with IBANs printed across the top. Investment summaries with balances down to the cent. If you work in advisory, wealth, or financial planning, this is your raw material, and almost all of it arrives as a PDF.

Then comes the boring part. The statement needs the last three months merged into one file. The signed mandate has to be compressed to fit a portal upload limit. The engagement letter needs a signature before the bank will move. None of this is hard. The question is where it happens.

What’s actually printed on these pages

It helps to be specific about what’s on the page when a financial PDF leaves your hands.

A single bank statement usually carries the full account number or IBAN, the account holder’s name and address, and a transaction-by-transaction record of how that person lives. A tax return adds the national ID, declared income, deductions, and often a partner’s details too. An account certificate ties a real human to a real balance. Put a few of these together and you have enough to impersonate someone at their own bank, or to build a frighteningly complete profile of their finances.

That’s the data you’re moving around every time you tidy up a PDF before sending it on.

The upload nobody thinks of as an upload

Most online PDF tools work the same way under the hood. Your file goes up to their server, the merge or compress runs there, and the result comes back down. The page that promises “files deleted after one hour” might mean it. You still can’t verify it, and a regulator won’t accept “the website said so” as your due diligence.

Once a client’s bank statement sits on a third party’s server, even for a minute, the control is gone. Logs and backups can hold copies past the promised window. The server can be breached. The tool may run on infrastructure it doesn’t own, passing the file through storage and processing queues nobody told you about. A statement that never leaves your machine can’t surface in a breach somewhere else.

For financial firms this isn’t an abstract worry. You’re a regulated business handling exactly the data that fraud rings want most. An account number and a name pulled from a leaked statement is a starting point for social engineering against the client’s bank. The breach doesn’t have to be yours for the fallout to land on you.

What the rules expect from you

When a finance or advisory firm handles a client’s documents, GDPR treats that data as something you hold in trust, not something you can route through any free website that’s quick. You’re processing personal data on behalf of others, and that comes with duties.

You’re expected to apply appropriate technical measures to keep it secure (Article 32). Financial data carries extra weight, because the harm from exposure is direct and immediate. You’re meant to know every party in the chain, and a random PDF site that receives an uploaded file is a third party in that chain, usually with no contract and no idea who you are. If that site is breached, the client whose statement was exposed is the one who pays, and your firm is the one that has to explain why the file was there.

Uploading a client’s tax return to an unknown tool to save thirty seconds is hard to defend in front of anyone who later asks. Most people doing it just never pictured the file leaving the building. The tool felt like a calculator.

Keep the file on the device

There’s a different kind of PDF tool. Instead of sending your file to a server, it runs the whole operation inside the browser. The code downloads to your device once, the PDF opens and changes in the browser’s own memory, and the finished file saves straight back to the same machine. The document never travels.

That’s how reader.me works, and it’s why it fits financial documents. When you compress a PDF to get a signed mandate under a portal’s size limit, the file is processed on your computer, in your browser. Nothing is uploaded to us, because there’s no server step to upload to. Close the tab and the working memory is gone.

You don’t have to take that on trust. Open the browser’s DevTools, go to the Network tab, run a compression, and watch. No request carries your file out. If the bank statement isn’t in any request body, it wasn’t sent anywhere. That’s a check you can run once and show your compliance lead.

Protecting and signing, still on your machine

Two jobs come up constantly in finance work, and both can stay local.

The first is locking a file down. Before you email a client their statement or send a tax summary to a third party, you can add a password to the PDF so only the intended person opens it. The encryption is applied in your browser, on your device. The unprotected original never leaves your machine, and neither does the password.

The second is signing. Engagement letters, mandates, and authorisations all need a signature, and the usual reflex is to print, sign, scan, and upload to some signing site. You can sign the PDF in the browser instead, drop your signature onto the page, and save the signed file locally. No printer, no upload, no third party holding a document that authorises money to move.

Make it a habit, not a one-off

The shift is small. Before any client’s financial PDF goes into a web tool, ask whether it processes in the browser or on a server. If you can’t tell, run the DevTools test once and settle it. Pick a client-side tool and make it the firm’s default, then write it into your procedures so it survives the next new hire.

It’s faster anyway. No upload-and-download round trip, and it keeps working when the office connection drops. For a document that lists a client’s IBAN and three months of their spending, getting this right isn’t extra work. It’s the job.

For the wider picture on why uploading sensitive files is a problem in the first place, read our piece on GDPR and uploading PDFs.