# Unlock Password Protected Bank Statements in Bulk

- Author: AutoBankConvert (https://www.autobankconvert.com)
- Published: 2026-01-05
- Updated: 2026-01-05
- Category: Batch conversion
- Canonical: https://www.autobankconvert.com/blog/unlock-password-protected-bank-statements-in-bulk

> How to unlock password protected bank statements in bulk before a batch run: collect passwords safely, remove the lock and keep the originals secure.
To unlock password protected bank statements in bulk, collect each client's statement password through a secure channel, remove the lock from every PDF in one pass with a tool that writes an unlocked copy, and keep the locked originals in restricted storage. The unlocked copies then go into the batch while the originals stay as the record.

## Why do banks send password protected statement PDFs?

Banks lock statement PDFs so that an emailed attachment cannot be opened by whoever happens to see it. The password is usually something the account holder already knows, such as part of a date of birth, a customer number or the last digits of an account, and it is often the same for every statement that client receives.

That last point is what makes bulk unlocking practical. A client with twelve months of locked statements from one bank usually has one password for all twelve. A client with three banks may have three. You rarely face a different password per file, so the work is mostly collecting a short list once.

Locked files are a common reason a batch stalls. A converter cannot read the transactions inside a PDF it cannot open, so the file either fails or waits for a person. Removing the lock first keeps those statements in the same run as everything else, including any [scanned statements mixed in with digital ones](/blog/scanned-and-digital-statements-in-one-batch).

## Collecting statement passwords from clients safely

Collect statement passwords once, through a channel that does not leave them sitting in a mailbox next to the statements they open. A password-manager share, a secure client portal or a phone call written straight into your vault all work. A reply email containing both the password and the attachments defeats the lock completely.

Ask for the passwords during onboarding, when you are already asking for account lists. Phrase the request around the bank, not the file: "Which banks send you locked statements, and what does each one ask for?" Clients often know the rule ("my birthday, day and month") better than the exact string.

Record each password against the client and the bank, in the same place the practice keeps other client credentials. Note the date you received it. Banks sometimes change the rule, and a dated entry tells you whether a failure means a new rule or a typo.

Limit who can see the list. If a team member leaves, the passwords they could read are part of what needs closing off, alongside logins and shared folders, as set out in the checklist for [revoking staff access to client files](/blog/revoke-staff-access-to-client-files).

## How do you remove statement passwords from many PDFs at once?

Remove statement passwords in bulk with a tool that opens each PDF with its password and saves an unlocked copy under a new name. Desktop PDF editors offer this one file at a time, while command-line tools can loop through a whole folder, which is the faster route when one client has many files with one password.

Here is a step list for one client's folder:

1. Copy the client's locked statements into a working folder. Never run the tool on the only copy.
2. Look up that client's password for the bank that issued the files.
3. Run the unlock over every file, writing each result into an output folder with the same file name.
4. Open two or three of the unlocked copies to confirm they open without a prompt and show every page.
5. Compare the file count in the input and output folders. A file that did not come out usually has a different password.
6. Move the unlocked copies into the batch folder.

On a computer with the free qpdf tool installed, step 3 can be a short loop. The example below is illustrative; replace the password with the client's own:

```
mkdir -p unlocked
for f in locked/*.pdf; do
  qpdf --password='CLIENT-PASSWORD' --decrypt "$f" "unlocked/$(basename "$f")"
done
```

A password typed on the command line can end up in the shell's history file. Clear it afterwards, or read the password from a prompt instead of typing it inline.

Some bulk converters accept a password and unlock the file themselves. AutoBankConvert's homepage does not say it does this, so plan to unlock first, and ask before you count on it. The guide to [what a bulk bank statement converter does with a folder](/blog/bulk-bank-statement-converter) lists other limits worth asking any vendor about.

## Storing the locked originals after a password is removed

Keep the locked original as the record and treat the unlocked copy as a working file. The original is exactly what the bank sent and still protects itself if it leaks. The unlocked copy is easier to read, so it should live only where the batch needs it and be deleted or archived once the run is exported.

A simple pattern is two folders per client: one for originals, readable by fewer people, and one for working files that the batch reads. After the month is exported, the working copies have done their job. The converted transactions live in the export files, which you can deliver through a routine like [exporting converted statements per client after a batch](/blog/export-converted-statements-per-client).

Check the converter's retention too. If the tool keeps uploaded files, the unlocked copy now sits there without its password. [AutoBankConvert](/) encrypts files in transit and at rest and lets you choose how long originals are kept after export, so set that period to match your own policy.

## When a locked statement should stay locked

Leave a statement locked when nobody needs to read its transactions this month. That covers prior-year files kept only for the record, statements for accounts you do not keep books on, and files a client sent by mistake. Unlocking creates a readable copy, and every readable copy is one more thing to store and eventually delete.

Two other cases call for a pause rather than a bulk unlock:

- **A password that no longer works.** Do not guess repeatedly. Ask the client, since a changed rule usually applies to new statements only, and old files keep the old password.
- **A file locked against printing or copying but not opening.** Some PDFs open freely but restrict copying text. That is a different lock. Try the batch with the file as it is before changing anything.

The goal is a batch with no locked files in it, not a practice with no locked files anywhere. Unlock what the run needs and leave the rest alone.