Client consent and data handling for bank connections

Somewhere in your client book right now there is probably a bank connection nobody can fully explain. It works. Statements arrive. But if the client’s new controller asked who authorized it, what it can access, and where the files go, assembling the answer would take a week. That gap costs nothing until the day it costs a client.

This is the consent and data-handling playbook we use at Scale CPA on our own client book. It covers what the authorization should say, where to capture it, what records to keep, and how to unwind access when a client leaves. Standard caveat: we are accountants, and this is operational guidance rather than legal advice. Have your attorney bless the actual engagement letter wording. What follows is the brief you hand that attorney.

What the authorization should cover

Five items. Get all five into your consent language and it will answer nearly every question a client security review throws at you.

1. What is accessed. Be specific: official PDF statements and basic account metadata, read-only. No payment capability, no ability to move money, no credential storage. If you use software for this, the stated scope should match what the tool actually does. Plaid’s statements product, for example, is scoped to statement documents, and that scope belongs in your language. The difference between data access and money movement carries the whole reassurance, and read-only bank access unpacks it in client-friendly terms.

2. Through whom. Name the aggregator. “We use Plaid and Mastercard Open Banking to retrieve statements” is one sentence and answers the question clients actually ask, which is who sits between the firm and the bank. Vague wording like “third-party services” reads as evasive and invites a longer conversation later.

3. Where the files land. State the storage location and who controls it. In our case: the firm’s own Google Drive, organized by client, year, and month. If your vendor stores files in its own cloud instead, say that, and be ready to explain who at the vendor can see the documents.

4. How long you keep them. Statements are workpapers, and firms hold workpapers for years. Put a retention period in writing and tie it to your firm-wide policy so nobody invents a number per client. Statement retention requirements covers the reasoning.

5. How the client turns it off. Describe revocation before anyone wants it. The honest answer for aggregator connections: the client can remove access in their bank’s connected-apps settings, through the aggregator’s consumer portal, or by asking the firm to disconnect. Putting this in writing costs nothing and defuses the “so you have my bank access forever?” worry on the spot.

Where consent lives

Two places, and you want both.

The engagement letter. A short bank-access clause, signed once, covering the five items above. This is the durable record. It survives staff turnover on both sides, and it is the document a new controller or an acquirer’s diligence team will ask for.

The connection flow itself. Easy to overlook because it happens automatically. When a client connects through an aggregator, they authenticate at their own bank and approve the data sharing on a screen the bank or aggregator controls. In our flow, the client gets an invite link, picks their bank, and signs in there; the firm never sees credentials, and the consent happens at the source, in the client’s own hands. That bank-side approval is real consent with a real timestamp. What it cannot capture is anything about your storage, retention, or internal access rules, which is why the engagement letter clause still exists.

The two records cover different ground:

The clause, piece by piece

We are not going to print a template, because your attorney should write yours. But the brief for that attorney is short. The clause should:

• authorize the firm to retrieve official bank and payment-platform statements electronically;
• name the aggregators involved;
• state that access is read-only and credential-free;
• identify the storage location and the retention period;
• describe how the client revokes, and commit the firm to disconnecting promptly on request;
• survive amendment of the account list, so adding a new checking account next year does not require a new signature.

One paragraph does it. If your current letter says nothing about electronic access and your team is already connecting accounts, fix the letter at the next renewal and capture interim consent by email in the meantime. Awkward, but far better than nothing on file.

Records worth keeping

Consent that is not findable might as well not exist. The record set that has worked for us:

• The signed clause, with the letter version and date.
• Per-account connection events: which account, connected when, by whom, through which aggregator. Good software writes this audit trail for you; a spreadsheet works if you maintain it.
• Revocations and reconnects, with dates. Connections break and get re-authorized, and each re-authorization is a fresh consent event worth logging.
• The offboarding record, covered in the next section.

This is also where regulators have an opinion. The FTC Safeguards Rule expects firms handling customer financial data to maintain a written security program with access controls, and the IRS points tax professionals the same direction in Publication 4557. Neither says “keep a consent log” verbatim. Both become much easier conversations when you have one.

Offboarding without loose ends

When a client leaves, the connection has to leave too. The sequence:

1. Disconnect every account in your retrieval tool the day the engagement ends, banks and payment platforms both.
2. Confirm revocation rather than assuming it. Check that the connection status shows removed, and tell the client they can verify in their own bank settings.
3. Apply your retention policy to the archive. Departed does not mean deleted; you keep workpapers for your stated period, then dispose of them under the same policy.
4. Hand over the files if asked. When the archive sits in the firm’s own storage in a clean client, year, month structure, this is a folder share rather than a project.
5. Write down the date of all of the above in the client file.

Ten minutes of work. The firms that skip it are the ones that discover, two years later, a live connection to an ex-client’s operating account, which is a genuinely bad email to have to send.

Rolling it out

Month one is retrofitting. New clients get the clause at signing. The existing book is the real work: inventory which clients have active connections or shared access today, then check what consent is on file. Expect gaps. Clear them by adding the clause at renewal and capturing email consent in the interim.

Expect the questions to come from new people. In our experience the consent conversation almost never comes from the person who signed. It comes from whoever arrives later: a controller, an investor’s diligence list, a security questionnaire. Write every record for that reader.

Revisit annually. Re-confirm the account list, prune connections for closed accounts, and re-capture consent on any material change such as a new entity, new ownership, or a new signer. The complete guide to collecting client bank statements shows where this fits in the broader collection process, and is it safe to connect client bank accounts handles the security half of the client conversation.

If you would rather the connection flow, audit trail, and firm-controlled filing come as defaults instead of a checklist, that is what we are building with StatementFlow, and early access is open: request an invite.