A bank reconciliation app can be safe for client statements if the vendor encrypts files in transit and at rest, limits who can open them, lets you set retention and delete on request, and answers a security questionnaire in writing. Safety is something you verify per vendor and per engagement, not something you assume.
What happens to statements uploaded to a bank reconciliation app?
When you upload a statement to a bank reconciliation app, the file travels to the vendor's servers, is stored, is read by software that extracts the lines, and is then available to you in a workspace. Each of those steps has a security question attached, and the vendor should be able to answer all of them plainly.
The path a file takes
A typical upload follows five steps:
- Your browser sends the PDF to the vendor over an encrypted connection.
- The vendor stores the original file, usually in cloud storage.
- An extraction process reads the file and produces lines, balances and confidence scores.
- The extracted data is saved in a database, linked to the original.
- You and anyone you invite view, correct and export the results.
At every step, ask who and what can touch the data. Steps 2 and 4 are where copies live, so retention and deletion apply to both the file and the extracted data.
Who can see the files
At minimum, the people in your own account can see them. The harder questions are about the vendor's staff, the vendor's subprocessors such as a cloud host, and whether your files are ever used to train a model or test a product. A vendor with a good answer states each of these in its terms or security document, not only in a sales call.
What the homepage of PreciseBankFlow says
PreciseBankFlow states that statements are encrypted in transit and at rest, kept in the engagement they belong to, and retained for as long as you choose. It is opening to firms in small groups, so ask for written answers to the questionnaire below when you request a spot.
Encryption in transit and at rest for online bank reconciliation
Encryption in transit protects a file while it moves between your browser and the vendor, and encryption at rest protects it while it sits in storage. An online bank reconciliation service should provide both, and it should be able to say which standard it uses for each. Either one alone leaves a gap.
In transit
Transit encryption means the connection uses TLS, the same protocol behind the padlock in a browser. You can check this yourself: the address begins with https, and the browser shows no warning. Ask the vendor whether older protocol versions are turned off and whether internal traffic between its own services is also encrypted.
At rest
Rest encryption means that stored files and databases are encrypted on disk, so a stolen disk or a misconfigured storage bucket does not expose readable statements. Ask who holds the keys and whether the vendor encrypts with a separate key per customer or a single shared one. A per-customer key narrows the damage of a single mistake.
What encryption does not cover
Encryption does not stop a person with a valid login from downloading a file. It does not stop a weak password or a shared account from being the way in. Encryption is the floor, and access control, logging and retention make up the rest of the walls. The vendor's answers on those matter as much as the cipher name.
Retention: how long a reconciliation app keeps original statements
Retention is how long the vendor keeps the original PDFs and the extracted data. A reconciliation app should let you set the period, let you delete on request, and confirm deletion in writing. The shorter the retention that still meets your engagement needs, the smaller the exposure.
Who controls deletion
Prefer a setup where you control the period for each engagement. A firm that must keep workpapers for years may want a long period for audit files and a short one for a one-off bookkeeping cleanup. PreciseBankFlow states that you choose how long originals are retained, which matches that need.
Deleted means all copies
Ask whether deletion covers the original file, the extracted rows, the exports kept on the server and the backups. Backups often expire on a delay, such as 30 or 90 days, and a vendor should be able to name the delay. A vendor that cannot say how long a deleted file lives in backup has not answered the question.
What your own rules require
Your firm's retention policy, your engagement letter and any client contract set the real minimum and maximum. If your policy says to keep source documents for a set number of years, keep your own copy of the statements and use the app for the working copy. If a client demands deletion at the end of the work, confirm the app can do it before you start.
Questions for an online reconciliation vendor's security review
A security review for an online reconciliation vendor is a written list of questions with answers you can file. Ten questions cover the ground for a small firm. The table gives each question and what an acceptable answer looks like. Treat the acceptable answers as examples; your own policy may be stricter.
| # | Question | Acceptable answer (example) |
|---|---|---|
| 1 | Are files encrypted in transit? | Yes, TLS on every connection, older versions disabled |
| 2 | Are files and extracted data encrypted at rest? | Yes, files and database, with key management described |
| 3 | Who at the vendor can open customer statements? | Named roles only, access logged, and only for support you request |
| 4 | Which subprocessors handle the data? | A written list, with their locations |
| 5 | Is customer data used to train models or test products? | No, stated in the terms |
| 6 | How long are originals kept, and who sets it? | The customer sets it per engagement |
| 7 | Can you delete on request, and how fast? | Yes, within a stated number of days, with written confirmation |
| 8 | How long do backups keep deleted data? | A stated delay, such as 30 days |
| 9 | How do users sign in, and can access be limited by role? | Individual accounts, roles, and a login record |
| 10 | What happens if there is a breach? | A stated notice period and a contact, in writing |
Working through the table
Send the ten questions as a short email or form and ask for written replies. Keep the replies in the engagement file or the vendor file. A vague answer is itself an answer: if a vendor says "we take security seriously" and offers nothing else, mark the question unanswered.
Reports you may be offered
Some vendors offer an independent security report. If one is offered, read what it covers, the period it covers and any exceptions it lists, instead of treating its existence as proof. If none is offered, that does not make a vendor unsafe, but it moves more weight to the written answers above. PreciseBankFlow is in early access, so ask for the answers directly and keep them on file.
Who should ask
The person who signs the engagement letter should own this list. If the answers are not good enough for a client's data, the decision to upload is yours, and the table gives you the record of why.
When not to upload statements to a bank reconciliation app
Do not upload statements when a contract, a regulator or an engagement letter bars sending them to a third party, when the vendor has not answered the security questions, or when the data is sensitive beyond what the work needs. In those cases reconcile offline.
Contract or policy bans
Some clients prohibit third-party processing of their financial records. Some firm policies require a data review before any new tool. If either applies, the answer is no until the review is done, however good the app.
Unanswered questions
If a vendor leaves any of the ten questions unanswered, especially questions 5, 7 and 10, hold the engagement back. You can run a test on a sample statement with no real names or numbers instead.
More data than the task needs
A reconciliation needs transaction lines and balances. It does not need a full set of unredacted statements for a person's personal accounts, or documents containing health, legal or other unrelated details. Upload only what the task requires. If you can redact the statement without breaking the footing, do so, but remember that redacting amounts defeats the purpose.
Engagements that should stay offline
Keep a regular, manual process for the engagements above. Manual bank reconciliation versus software sets out when a manual method is the better choice and how to keep the audit trail when you do.
Does an online bank reconciliation app need bank login access?
An online bank reconciliation app does not need your bank login if it works from uploaded statements. Some tools connect to bank accounts through a feed, which needs credentials or an authorization, while others read PDFs you upload yourself. Know which kind you are choosing, because the risks differ.
Uploads versus bank connections
With an upload, you choose each file and nothing else about the account is reachable. With a bank connection, the tool gets standing access to an account, often read-only but sometimes broader, and a breach at the vendor can mean exposure of live account data. For a firm handling many clients' accounts, the uploaded-statement model keeps the client's bank login out of the picture.
What PreciseBankFlow describes
The homepage describes a flow that reads statements from digital and scanned PDFs. It does not describe connecting to bank accounts, so ask the team to confirm in writing what access the product needs before you rely on that.
If a tool asks for credentials
If a vendor asks for a client's online banking username and password, treat it as a stop sign and ask what authorization method it uses instead. Banks and clients usually forbid sharing credentials, and a firm that takes them on has taken on the liability.
Where to go next
Once the security answers are in hand, the next step is a feature comparison. Check reconciliation software covers a special case for accounts that pay by check, the buying questions for account reconciliation software cover price and features, and forensic accounting software covers the heavier tools used when fraud is suspected.