Is read-only bank access safe?

Yes, within its scope. A read-only connection made through an aggregator like Plaid or Mastercard Open Banking can retrieve statements, balances, or transactions and cannot move money or change the account. Clients authenticate at their own bank and can revoke the token at any time. Vendor data handling still needs separate diligence.

Can read-only bank access be used to move money?

No. Data-access connections carry no payment or transfer capability. Money movement products exist at aggregators, but they are separate products with their own consent flows and contracts. A statement-retrieval integration never holds them, and the software cannot widen its own scope later without the client going back through consent at the bank.

How does a client revoke read-only bank access?

Three ways. Most major banks list connected apps under online banking security settings, where the client can remove the app and kill the token. Plaid runs a consumer portal at my.plaid.com that shows every Plaid connection and lets the person disconnect any of them. The firm or vendor can also disconnect from the software side.

Does read-only access give the software my bank password?

At most major US banks, no. The client signs in on the bank's own OAuth page, the same pattern as signing in with Google, and the software receives a scoped token instead of credentials. Where a bank still requires credential-based login, the aggregator handles it, and the retrieval software never stores the password.

Read-only bank access: what connected software can and can't do

The short answer: a read-only bank connection can retrieve data, and that is all it can do. No transfers, no payments, no changes to the account. At major banks the client signs in on the bank’s own page, so the software never touches credentials. The real diligence question is how the vendor handles the data it reads.

That answer deserves unpacking, because “safe” bundles two different risks. The first is money movement: could connected software drain an account? Read-only architecture closes that one by design. The second is data handling: what happens to the statements and balances after retrieval? Read-only says nothing about that, and it is where your vendor diligence should actually go. We compared connections against email and shared logins in a separate post; this one is about what the connection itself can and cannot do.

What does a read-only connection actually permit?

When a client connects an account through Plaid or Mastercard Open Banking, the bank issues an access token scoped to exactly what the client approved on the consent screen. For statement retrieval, that scope is documents plus account metadata. The token is a data key. It carries no payment instruction because payment capability lives in entirely separate aggregator products, with separate contracts, separate consent screens, and separate API endpoints that a data-only integration never receives.

Two properties of that token matter for anyone assessing risk:

The scope is fixed at consent. Software cannot quietly widen its own access later. Adding a data product means the client goes back through the bank’s consent flow and approves it again.
Credentials stay at the bank. Wells Fargo, Chase, Bank of America, Citi, and most other large US institutions use OAuth for aggregator connections, so the client types their password only on the bank’s own page. For the shrinking set of banks without OAuth, the aggregator handles the login inside its own flow; the retrieval software never sees or stores the password either way.

Here is the boundary in one view:

A read-only statement connection can	It cannot
Download official PDF statements the bank has published	Initiate a transfer, payment, or wire
Read account name, type, and mask (last four digits)	Change account settings, contact details, or owners
Detect when a new statement posts	Store or replay the client’s banking password
Be revoked by the client at any moment	Restore its own access after revocation

The data scopes a statement tool actually needs

Aggregators sell data access as separate products, each with its own line on the consent screen. In Plaid’s catalog, Statements returns the official PDFs the bank has already produced, plus enough metadata to file them correctly. Transactions is a different product: a continuously refreshed feed of cleared and pending activity, with up to 24 months of history. Bank-feed and bookkeeping tools need Transactions. A statement-retrieval tool needs Statements. Mastercard Open Banking structures consent the same way with its own product tiers.

This distinction is useful during vendor review because the client sees the requested scopes at connection time. If a tool marketed for statements also asks for a transaction feed, that will be visible, and the vendor should be able to say why. Sometimes there is a good reason, such as a product that also builds bank feeds. But the narrower the scope, the smaller the data footprint your firm is responsible for assessing. Least privilege applies to bank data the same as everything else.

Revoking access when a client leaves

Three switches exist, and any one of them ends retrieval:

At the bank. OAuth banks list connected apps in online-banking security settings. The client removes the app there and the token dies immediately.
At the aggregator. Plaid runs a consumer portal at my.plaid.com where a person can see every app connected through Plaid across their financial life and disconnect any of them.
At the firm. Disconnecting on the software side retires the token from that end.

After revocation the token simply stops working. The software has no way to reinstate itself; the only path back is the client sitting through the consent flow again. That property is worth explaining to a hesitant client, because it reverses the usual dynamic of handing over financial documents. An emailed PDF can never be recalled. A token dies in under a minute.

The risk read-only does not remove

Read-only bounds what a connection can do at the bank. It does nothing to bound what a vendor does with the data after retrieval. Where the files are stored, who at the vendor can open them, whether staff access is logged, how long copies are retained, and what happens when you cancel are all architecture and policy questions that sit entirely outside the token’s scope. Under the FTC Safeguards Rule, firms are expected to select service providers capable of maintaining appropriate safeguards and to hold them to it, so these questions are your obligation, not just your preference. We walk through how different vendors answer them in who can see your clients’ documents.

The same framing applies to the worst case. If a read-only token were somehow compromised, the exposure is unauthorized data access. Serious, and exactly why tokens should be encrypted at rest, but a bounded and categorically different event from money leaving an account.

Read-only limits what a connection can do at the bank. It does not limit what a vendor can do with the data it retrieves. Assess the two risks separately: consent and scopes for the first, storage architecture and access policy for the second.

How we run read-only access at Scale CPA

StatementFlow was built inside Scale CPA, and it fetched statements for our own client book before anyone else’s, so we had to get comfortable with both halves of this question ourselves. Fielding the “wait, can this move our money?” call from a client is a rite of passage; the answer is a flat no, for the reasons above.

On the connection half: each client connects once through a secure invite link and authenticates at their own bank via Plaid or Mastercard Open Banking. Nobody at the firm ever sees credentials, and the scope is statements. On the data-handling half: every downloaded PDF is verified against its SHA-256 hash and filed into the firm’s own Google Drive, organized by client, year, and month, so the archive belongs to the firm rather than to us. Connection tokens are encrypted at rest with AES-256-GCM, webhooks are signature-verified, access is role-based with a passkey step-up before anyone touches a client connection, and actions on client connections land in an activity log. The full write-up lives on our security page.

Honest boundaries, stated plainly: StatementFlow retrieves official statements, including settlement statements from processors like Stripe, PayPal, Square, and Shopify. It does no OCR or data extraction, it covers US banks only, and it is in early access. For the wider process those statements feed into, start with the complete guide to collecting client bank statements.

If you want a statement pipeline built on exactly this model, read-only scopes and files in your own Drive, join the early access list and bring your security questions with you.