The Hidden Danger in "Read-Only" Bank Access

Giving your staff read-only access to client bank accounts feels safe. It isn't. In most firms, "read-only" is a label on a practice that exposes the client, the firm, and the employee to fraud, liability, and regulatory risk.

Every month, bookkeepers and CPAs need bank statements and check images to close the books. The common shortcut is to ask the client for a login, or to have the client add staff as a viewer. It gets the statements. It also creates problems most firms never see until something goes wrong.

"Read-only" is often not read-only

Many small business and personal bank accounts have no true read-only user role. When a client says "I gave you read-only access," it often means one of three things:

• The client shared their own username and password. Your staff now hold the keys to move money, not just view it.
• The client added a sub-user with limited rights. Permissions vary by bank, are rarely reviewed, and can be widened later without anyone at the firm noticing.
• A staff member set up access once and saved it in a browser or spreadsheet. The login outlives the engagement, the employee, or both.

In each case, the firm cannot prove what the employee could or could not do. That gap is where the risk lives.

Pitfall 1: The operational mess

• Credentials spread. Logins end up in emails, sticky notes, shared password sheets, and saved browser profiles. Each copy is a new place to be breached.
• MFA breaks the workflow. Banks send one-time codes to the client's phone. Staff text the client for codes every month, which trains clients to hand codes to anyone who asks. That is exactly the habit phishers exploit.
• Turnover leaves doors open. When an employee leaves, few firms ask every client to change their bank password. The former employee may still be able to log in.
• No audit trail. If money moves, the bank's logs show the client's own login. Neither the client nor the firm can easily prove who did it.
• It doesn't scale. Logging into 200 client banks to download PDFs and check images is hours of manual work every month.

Pitfall 2: Fraud lands on your client, and blame lands on you

When a client hands over login credentials, the law can treat your employee as an authorized user. Under Regulation E's official interpretation, if a consumer gives someone an access device and that person exceeds their authority, the consumer is fully liable for the transfers until they tell the bank that person is no longer authorized (Shazam summary of Reg E §1005.2(m)).

It gets worse for business accounts. Regulation E protects consumer accounts. Most of your clients' operating accounts are business accounts, which generally fall outside it, so the protections are weaker still.

What this means in practice:

• A dishonest or compromised employee with a client's login is not "a hacker" in the bank's eyes. The client may have no claim to get the money back.
• Many bank account agreements prohibit sharing credentials. A client who shares them may be in breach of their own bank terms.
• The client will look to your firm to make them whole. Ask your E&O carrier, in writing, whether a loss caused by staff holding client bank credentials is covered.

Pitfall 3: It undercuts your own compliance program

If your firm prepares tax returns, the FTC Safeguards Rule (16 CFR Part 314) treats you as a financial institution. The IRS says so directly in its guidance to tax professionals (IRS, "Careful WISP(er)"). The amended rule's technical requirements, including MFA, encryption and a written program, took full effect on June 9, 2023.

Shared bank logins collide with that program in three places:

• Access controls. The rule expects you to limit who can reach customer information. A password sheet of client bank logins is the opposite.
• Multi-factor authentication. Texting clients for one-time codes, or asking them to turn MFA off, defeats the control the rule requires.
• Logging and incident response. You can't log or investigate activity that happens under the client's own identity on the bank's site.

If your Written Information Security Plan (WISP) is silent on client bank credentials, it has a gap. If it describes them honestly, it describes a risk you have chosen to keep.

The safer model: your staff never touch a bank login

The fix is to separate getting the data from holding the keys. Bank data aggregators such as Mastercard Open Finance (Finicity) and MX let the client connect their bank once, inside a secure flow, and authorize data sharing.

Compared with shared logins:

The client stays in control, your staff get only the statements and check images they need, and your WISP gets simpler, not harder.

A 30-day checklist for your firm

• List every client bank login your staff hold, and where each is stored.
• Delete credentials from spreadsheets, emails and shared browser profiles.
• Ask clients to change passwords for any account a former employee could reach.
• Move each client to an aggregator connection instead of a shared login.
• Update your WISP to state that staff do not hold client bank credentials.
• Ask your E&O carrier how it treats losses tied to staff bank access.

How LedgerSync helps

LedgerSync was built for exactly this problem. Your clients connect their banks once through Mastercard Open Finance or MX, and your staff never see a password. LedgerSync then fetches bank statements from 5,000+ banks and check images from hundreds of them, and syncs them to QuickBooks Online, QuickBooks Desktop, Accounting CS and Zoho Books.

You get the statements you need for month-end, without the keys you don't want.

See pricing Book a 30-minute demo

Maurice Berdugo is Founder and CEO of LedgerSync and has worked in open banking and data aggregation since 2009.

Sources

• IRS Office of Professional Responsibility, "Careful WISP(er)" (Oct 2023)
• Shazam, "Reg E and Unauthorized EFT Claims"
• CPA Practice Advisor, "What the FTC Safeguards Rule Actually Requires From Tax and Accounting Firms" (Oct 2, 2026)

This article is general information, not legal advice.