Your bank statement is password protected and the converter cannot open it

You forwarded a month of statements to a converter and got an error back on every one of them. Or you opened the file yourself and were asked for a password before a single page appeared. The statement is encrypted. If it prompts before it will display, the content itself is encrypted and nothing can read a transaction out of it until the password is supplied. If it displays perfectly well and simply refuses to give up its text, you are looking at a different lock, and separating the two is the first job on this page.

This is normal and extremely common. Many banks, across a number of countries, encrypt the statements they send out as email attachments, because email is not a secure channel and an attachment sitting in a mailbox is an attachment sitting in a mailbox. Encrypting it is the sensible thing for a bank to do. Whether yours does depends on the bank, on the product, and on how you asked to receive the document. It says nothing about your account, and it is not a flag on your file.

Two different locks that produce two different symptoms

The word "password" covers two mechanisms in a PDF, and knowing which one you are facing tells you what to do next. They are independent, and a document can carry either, both, or one presented as the other.

• A user password, sometimes called an open password. Without it the document cannot be displayed at all. The content is encrypted, so there is nothing for any tool to read until the correct password is supplied. The symptom is a prompt before the first page renders.
• An owner password, sometimes called a permissions or master password. The document opens and displays normally, but it carries flags restricting copying, text extraction, printing or editing. The symptom is stranger: the statement is right there on your screen, and selecting an amount and copying it produces nothing.

That second case is the one people misdiagnose, because the file does not behave like a locked file. If your statement opens without a prompt and yet nothing can pull data out of it, permissions flags are the explanation people forget, and they are worth checking early. They are not the only explanation: a scanned page has no text to copy in the first place, an unusual or damaged font encoding can hand back characters that are not the ones on screen, and a converter can be failing for reasons of its own. Settle it by opening the document's properties, where most PDF applications display the security settings and list which actions are permitted. One look tells you whether restrictions are present.

Worth knowing too: those flags are a request rather than a barrier. Plenty of software honours them by design, and plenty of ordinary tooling ignores them entirely, so a file one program refuses to read another will open without comment. That is why a permissions-locked statement produces such inconsistent results across tools, and why the flag being present does not by itself explain a particular failure.

There is a third symptom worth separating from both. If the document opens, text selects and copies fine, and the output is still unusable, the lock is not your problem and you should read up on telling a scanned statement from a text one instead.

Where your bank's password comes from

Most banks do not invent a random password and hope you keep it. They derive it from details you already hold, using a formula stated in the covering email, so that a statement is openable by its recipient without any secret being transmitted. Some issue a one-time password through a separate channel instead, and a few skip attachments and put the document behind a portal login; where that is the case none of the formulas below apply and the bank is the only source. Where a derived password is used, the formulas vary by bank but the ingredients rarely do.

• Date of birth, in a fixed format, most often DDMMYYYY or DDMMYY.
• Customer identification number or account number, sometimes the full number, more often the last four, six or eight digits.
• Name fragments, typically the first four or five letters of your surname or first name, in upper or lower case.
• PAN, national identity number or registered mobile number, in whole or in part, depending on the country.
• A combination of two of the above, which is the most common pattern of all, such as the first four letters of the name followed by the date of birth.

The covering email normally states the exact rule, usually in small type below the attachment. That email is the first place to look, and it is worth searching your mailbox for it before doing anything else. If it is not stated there, or you no longer have the email, the bank will restate the formula: it is commonly published in the internet banking help pages of banks that use this practice, and support will confirm it after their usual identity checks. Case sensitivity is real, so try both cases before concluding the formula is wrong.

Getting the statement converted

Once you hold the password you have two routes, and they are not equally good.

The better one is to supply the password to the converter alongside the file, so the document is decrypted for the duration of the conversion and no unlocked copy is ever written to disk. The unlocked copy is the part worth avoiding. An encrypted statement in your downloads folder is protected; a decrypted one is a full financial record with the protection deliberately removed, sitting in the same folder, on a laptop that travels.

1. 1

   Find the password formula

   Search your mailbox for the covering email that carried the statement. The rule is normally stated there, usually directly beneath the attachment, and where it is not, the bank's online help or its support line will restate it.
2. 2

   Confirm which lock you have

   If the document prompts before displaying, it is a user password. If it displays but will not allow copying, it is an owner password and the open step is already done.
3. 3

   Supply the password with the file

   Give the password to the converter rather than stripping it first, so no unprotected copy of the statement is created.
4. 4

   Check the statement downloaded from online banking

   If you are locked out of the emailed copy, sign in and download the same period directly. The online banking copy is frequently not encrypted, and it takes less time to try than to chase a formula.
5. 5

   Reconcile the converted output

   Compare the closing balance and the transaction count in the converted file against the figures printed on the statement before you use it.

If you do need an unencrypted copy, and there are legitimate reasons to want one, opening the document with the password and writing a new file with Print to PDF, or with an export or Save As option, usually produces one without the encryption. Usually, not always: printing may itself be restricted by the document, and some Save As paths carry the encryption into the new file rather than dropping it, so open the copy fresh and confirm it does not prompt before you rely on it. Note what the route requires either way: you must already be able to open the original. Every legitimate method of removing a password starts from possession of it, which is exactly as it should be.

Handle the whole batch the same way while you are there. A bank that encrypts one statement usually encrypts the rest, and the derivation tends to hold from month to month, so a whole year of statements will often open under a single password rather than needing to be worked through one file at a time. Do not treat that as guaranteed. A bank can revise its policy, migrate you onto a different product or merge with another institution, any of which can move the formula partway through a run of files, so if one statement in a batch refuses a password the others accepted, treat that file as its own case rather than concluding the password was wrong all along.

What the password does not tell you about the data

Here is the part that gets lost once the file finally opens, and it is the part that matters. Decryption is an access problem. It has no bearing whatsoever on whether the figures come out of the document correctly.

An encrypted statement can hold clean text, and it can just as easily hold scanned page images that happen to be encrypted. Removing the password reveals which, and it changes nothing about the difficulty of what follows. People routinely relax at this point because the obstacle they were fighting has gone, and a converted statement that opened after a struggle gets less scrutiny than one that opened immediately. That is precisely backwards.

The first two rows of that check are about access. The last three are about accuracy, and they are the ones that decide whether the file is usable. A statement can pass every access check and still arrive with a debit read as a credit or a thousands separator dropped from a four-figure amount, and neither of those will look wrong on the page. Opening balance plus movements against the printed closing balance is the check that catches them, because a dropped separator or a flipped sign breaks the arithmetic and cannot stay hidden. It is the strongest automatic check available on a converted file, and it is not everything: it will not tell you that a date landed in the wrong month or a description came out garbled, and a pair of errors that cancel each other exactly can slip past it. Pair it with the row count and a glance at the dates against the statement period.

Before you send a locked statement anywhere

A password protected statement deserves the same handling as any other: the encryption on the file is not a substitute for care about where the file goes. Check the retention policy and the deletion behaviour of anything you hand it to, and check it once rather than per statement, since the answer does not change between months. The questions worth asking are set out in the guide to whether it is safe to convert bank statements online.

One point specific to encrypted documents is worth stating plainly. Supplying a password to a tool means the tool can read the document, so the password is not adding protection at that stage; it is protecting the file at rest, in your mailbox and on your disk. That is a good reason to prefer supplying the password over stripping it, and a good reason to keep the encrypted original rather than replacing it with an unlocked one once the conversion is finished.