Automate Open Banking for Accountants: Consent and Feed Checklist

Automate open banking in a practice by splitting it into four jobs: a written consent request the client approves in their own bank, a feed that lands in the ledger, a calendar that warns you before access lapses, and a reconciliation check that proves the feed is complete. AI drafts and monitors; the client alone gives consent.

Most practices only automate the middle of that list, the feed itself, and then find out months later that a connection lapsed and nobody noticed. Reconnecting does not always fill the hole: Xero's open banking FAQ says re-authenticating brings back only 90 days of history, so a feed that stopped four months ago leaves about a month of transactions to import by hand. Consent is a dated record you keep, not a green tick you trust.

Follow me on Instagram@sagnikteaches

Why a feed that "just works" still needs an owner

A bank feed is permission to read a client's transactions for a limited time. That permission has an owner (the client), a scope (which accounts, how much history, balances or not), and an expiry. Accounting software hides this behind a green tick, so staff treat the feed as permanent. It is not.

Connect on LinkedInSagnik Bhattacharya

The vendor documentation shows how concrete the limits are. GoCardless's Bank Account Data guide, for instance, says that where you do not create a custom agreement, default terms apply: 90 days of transaction history and 90 days of account access, with the full scope of information. Its institution records also carry fields for the longest access period a bank allows and for how many days of transactions it will return, and those values differ from bank to bank. So the questions to settle per client are not abstract: how long does this consent last, how much history did we ask for, and what happens on the day it ends?

Subscribe on YouTube@sagnikteaches

Who renews, and how often, depends on the rules the client's bank works under. Under the UK rules, the FCA's changes to the strong customer authentication standards, in force from March 2022, mean customers need not re-authenticate with their bank every 90 days when they reach their account through a third-party provider, provided the bank applies the exemption; instead the provider must obtain the customer's explicit consent at least every 90 days, according to the FCA's strong customer authentication page. For EU accounts, the EU banking regulator's (EBA's) amended standards, adopted as Delegated Regulation (EU) 2022/2360, made the exemption mandatory for banks and moved strong-authentication renewal for access through an account information provider from every 90 days to every 180 days.

Your software may still describe all this as a 90-day re-authentication with the bank. Xero's open banking FAQ, for instance, tells users to re-authenticate their bank connection every 90 days and says Xero will remind them when it is due. So the period on a given client's connection is whatever their bank, your provider and your software apply in practice. Do not rely on a tutorial, including this one, for that figure: read the terms of the provider you actually use, check what the renewal screen shows the first time it appears, and write the number into your register.

The consent record: what to capture for each connection

Keep one row per client per bank connection. A spreadsheet is enough for a practice of this size; a table in your practice management tool is better if you already have custom fields. Every row needs these columns.

Two columns people skip are the purpose and the fallback. The purpose line stops a connection set up for bookkeeping being quietly reused for something the client never discussed, such as a lending referral. The fallback line decides in advance what you do when the feed breaks, so nobody improvises at year-end.

Writing the consent request so clients actually approve it

Clients ignore requests that look like security phishing. The email should name the practice, say exactly what is being connected and for how long, and explain what the client will see when their bank asks them to confirm. You can have an AI assistant draft it from your register row, then edit it. Here is a prompt and the kind of output to expect.

You are drafting a client email for an accountancy practice.
Facts: client first name [first name]; bank connection for bookkeeping and year-end accounts;
scope: balances and transactions for the last 12 months; access lasts 90 days then we ask again;
the client approves inside their own bank app; we never see their login details;
they can withdraw access any time in their banking app.
Write 130 words, plain tone, no jargon, one clear button instruction, one line on what to do if the bank screen looks unfamiliar.
Do not mention any other service.

Illustrative output, lightly trimmed: "Hi [first name], to keep your books up to date without chasing statements, we'd like to connect your business bank account to your accounting software. You'll be taken to your own bank to approve it; we never see your login. We can see balances and transactions for the last 12 months, used only for your bookkeeping and year-end accounts. Access lasts 90 days and we'll ask before it ends. You can withdraw it any time in your banking app. If the screen asks for anything unexpected, stop and call us."

What you fix: the draft usually reaches for words like "securely" and sometimes promises "real-time" data. Remove adjectives you cannot back up, and check that the 90 days matches your register row rather than whatever the model assumed.

Setting up the feed: practice-held or client-held connection

There are two routes, and the checklist differs for each.

1. Feed inside the accounting software. The connection starts from the software's bank-feed screen, but the approval at the bank belongs to the client: Xero's FAQ says its feeds can only be authorised by the account holder or someone with authorised access to online banking, so a bookkeeper cannot authorise a client's feed. The software then handles renewal prompts, and you monitor status from the software's dashboard. The consent record is your register plus the confirmation.
2. Your own connection through a data provider. You create the agreement through the provider's API or portal, choose the history length and access period, and pull data into a sheet or tool you control. You are responsible for storing tokens, tracking expiry and deleting data when the engagement ends.

For most small practices the first route is enough. The second suits a practice that wants one dashboard across many clients, and it carries real obligations. Before choosing it, read your provider's terms on data use, check whether you become a processor of the client's data under your data-protection rules, and add the processing to your engagement letter. My earlier tutorial on AI engagement letters for accountants covers the wording.

Choosing the scope and history to request

Ask for the least that does the job. A new client needing a year of catch-up bookkeeping needs perhaps 12 months of history. An established client with monthly bookkeeping needs only forward data. Where the provider lets you set history and access length (GoCardless's end-user agreement, for example, takes maximum historical days, days of access validity and an access scope), write your chosen values into the register at the same moment you create the agreement. A common mistake is requesting the maximum because the form allows it, then having no reason to give if the client asks why.

A worked example: a forty-client practice in one quarter

Say a small practice has forty bookkeeping clients. Thirty-two have a feed inside the accounting software; eight send PDF statements. Nobody holds a list of when the feeds were approved, and two clients have complained that figures look out of date.

Week one: the practice builds the register above and fills it for the thirty-two feeds. Dates approved come from the confirmation emails or software history; where they are missing, the row is marked "unknown, re-approve". Eleven rows are unknown.

Week two: the eleven unknown clients get the consent email drafted from the prompt above, each edited by the client's bookkeeper. Seven approve within five working days. The other four get a second email and one phone call each, and all four approve during the following week.

Week three: the practice sorts the register by "access valid until". Nine connections expire within the next 30 days. Those get the renewal email now, before expiry, not after the gap appears.

Week four: the first weekly reconciliation check runs (set out below). It finds two feeds that look connected but stopped importing, one because of a bank-side change the client had to re-approve, one because the account number changed after a card reissue. Both are fixed the same day.

Result in numbers, all illustrative: 32 of 32 feeds now have a dated record; 9 renewals handled early; 2 silent gaps found; the 8 statement clients moved onto a monthly upload deadline. The time saved is mainly the chasing, which falls from an unplanned weekly scramble to a Monday list.

Let AI watch the calendar, not the consent

The renewal job is dull and perfect for automation. Export the register to a sheet and add a column: days until expiry. A simple formula does the work.

=IF(H2="","check",H2-TODAY())

Then filter for 30 days or fewer. If you want AI to write the reminders, paste the filtered rows with client first names only, no account numbers, and use a prompt like this.

Here are five rows: first name, bank name, expiry date, bookkeeper name.
Write one short renewal email for each. State the date access ends,
that approval happens in their bank app, and that I will call if I haven't heard in 5 days.
Keep each under 90 words. Do not invent figures.

Check each draft against the row before sending, then send from your own mail. A tool that sends automatically on the client's behalf is tempting, but a wrong date in a bulk send is the kind of error that damages trust. See the mistakes that put an accounting firm's client trust at risk for what that looks like.

Weekly feed health check: four tests that take ten minutes

Consent can be valid while the feed is quietly broken, so run these checks every week on a sample, and every client monthly.

1. Latest transaction date. For each client, find the date of the most recent imported transaction. If it is more than five working days old for an active account, investigate.
2. Balance tie. Compare the ledger bank balance against the balance in the bank's own online view or the latest statement. A difference means a missing or duplicate line.
3. Count tie. Compare the number of transactions imported in the month with the count on the statement. Our tutorial on automating bank reconciliation with AI and checking the matches covers the matching side.
4. Duplicate scan. Sort by date, amount and description and look for exact repeats on the same day. A feed re-connected after a gap can import the overlap twice.

An illustrative failure: a client switches to a new account at the same bank. The old feed shows connected, the new account has no feed, and the ledger shows the old account balance frozen for six weeks. Test one catches it; the green tick does not.

Sample exception log after the weekly check

Keep this log. It is the evidence that you monitor feeds, and it shows patterns: if most failures are expiries, fix your calendar; if most are bank changes, fix your client onboarding.

Payment requests: collecting fees and keeping the audit trail

Many providers now offer account-to-account payment requests, where the payer approves a payment in their own bank and the money moves directly, sometimes with a mandate for repeat payments. Some practices use this to collect fees. The consent point is different here: approving a one-off payment is not the same as agreeing to recurring ones, and the client should be able to tell which they approved.

Verify what your own provider offers on its current pages, since features, limits and fees change. Then settle these points before switching on any fee collection:

• Is the payment one-off or recurring, and does your engagement letter say so?
• Who can cancel, and how does the client do it?
• Which invoice does each payment reference, so reconciliation matches automatically?
• What happens on a failed payment: reminder, retry, or a human call?

AI helps with the reference and chasing text. Give it the invoice number and the amount and ask for a payment reference format your ledger can match on, such as the invoice number plus the client code. A failed-payment message should be drafted by AI but approved by the bookkeeper, because tone matters when someone may be in difficulty.

Before and after: one client's onboarding, rewritten

An illustrative contrast shows what the register changes in practice. A craft brewery supplier joins in September. Under the old habit, a bookkeeper sends a link on a call, the director clicks through, the feed appears, and nothing is written down. In January the director asks why the January statement figures look short and whether anyone can see their account. Nobody can say when the connection was approved, for how long, or what it covered. The bookkeeper spends a morning reconstructing it from email search results.

Under the register habit, the same onboarding leaves a row: director approved on 12 September, scope balances and transactions, twelve months of history, purpose bookkeeping and year-end accounts, access valid to 11 December, evidence saved. The 30-day alert fires on 11 November, the renewal email goes out the same day, and the director approves again before the date. In January the answer to the director's question is one screen long. The difference is not the software; it is that someone owns the record.

Onboarding time, illustrative

Writing the row and saving the evidence adds roughly five minutes to each connection. Across forty clients that is a little over three hours once, and a few minutes a month afterwards. Chasing a lapsed feed, by comparison, easily takes thirty minutes of staff time per incident once you include the call, the second email and the catch-up import. Those are rough planning figures, not measurements, so time your own first five clients and use that number.

Edge cases that break a tidy process

Joint accounts and two-signature accounts

If an account needs two signatories for payments, check whether data access needs the same. Ask the client rather than assuming, and record who approved.

A client leaves the practice

Withdraw access on your side, ask the client to confirm it is withdrawn in their banking app, delete stored data according to your retention policy, and mark the register row closed with the date. A forgotten live connection to a former client is a risk you do not want.

A staff member leaves

If connections were created under a personal login, they can be lost with the account. Create connections under a shared practice role, and keep tokens in your password manager rather than in someone's email.

The client says they never approved it

This is why the evidence link exists. Show the dated request, the approval confirmation and the stated purpose. If you cannot, treat the connection as unauthorised: withdraw it, tell the client plainly, and ask a qualified adviser about any notification duty.

What to keep AI away from

Do not paste account numbers, sort codes, tokens or full transaction exports into a consumer chatbot. The register examples above use first names, bank names and dates for that reason. If you want to analyse transaction content with AI, read whether it is safe for an accountant to use ChatGPT with client data first, and use a business-grade plan whose terms you have read.

Also keep AI away from the decision to connect or renew. A model cannot know the client agreed. It can only know what you tell it, and a confident wrong draft is worse than a blank page.

The one-page checklist to copy into your practice manual

1. Create the register with the ten fields above.
2. For every new connection, send a written request that names the purpose, scope and duration.
3. Save the approval evidence before marking the row live.
4. Record the expiry date and set an alert for 30 days before.
5. Run the four weekly tests and log failures.
6. Draft renewal emails with AI; review and send them yourself.
7. Decide the fallback (statement upload) and its deadline per client.
8. On leaving, withdraw access, delete data and close the row.
9. Review the log each quarter and change the process where failures cluster.

If you would rather map this with someone who has set it up before, my AI implementation consultation covers it. For the surrounding bookkeeping steps, AI receipt capture and bank categorisation is the natural next read, and the AI guide sets out where each tool fits.

Open banking questions practices ask before switching feeds on

Who gives consent, the practice or the client?

The account holder gives it, normally by approving the connection inside their own banking app or login. Xero's open banking FAQ, for example, says feeds can only be authorised by the account holder or someone with authorised access to online banking. The practice organises the request and keeps the record of who approved.

Can AI approve or renew a connection for me?

No. Consent is a decision by the account holder, so nothing should click it on their behalf. AI is useful around the edges: drafting the request email, spotting which connections are about to lapse, and writing the renewal reminder you then send.

What if a feed stops and the client ignores the reminder?

Set a fallback date in your onboarding terms. After that date the practice moves to statement uploads for that client, records the change, and notes the extra time in the engagement letter. A silent gap in the ledger is worse than a documented switch to manual.

Should the practice or the client hold the aggregator account?

Decide it per service and write it down. A practice-held connection is simpler to monitor, but it makes you a processor of the client's bank data. Check your provider's terms and your data-protection position before you choose, and ask a qualified adviser if unsure.

Further reads

• Is It Safe to Connect AI Tools to Your Business Bank Account? — The client's side: is connecting AI tools to a bank account safe?
• AI Readiness Checklist for Accountants, Solicitors, Consultants — Check the wider practice is ready for more automation.
• Bank Statement PDF to Excel With AI: Check Every Line Before Import — The manual fallback when a feed cannot be connected.
• How Accountants Use AI to Spot Errors in Client Books — Use AI to catch errors once the feed data is in.
• Can AI Do My Bookkeeping? What Still Needs an Accountant — What still needs an accountant even with clean feeds.
• Automate BACS Payments in an Accountancy Practice: Where AI Fits — A step-by-step BACS payment run for a practice: file build, AI checks on changed bank details, dual approval, submission and reconciliation.
• Does QuickBooks Have AI Agents? Plans, Prompt Limits and Add-Ons — Which QuickBooks Online plan gets which AI features, how the monthly chat prompt cap works, and whether the $10 add-on is worth buying.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: GoCardless Bank Account Data quick-start guide (default access and history terms, agreement and institution fields); the FCA's strong customer authentication page (90-day consent reconfirmation by third-party providers); the EBA's 5 April 2022 press release on the 180-day renewal; Xero's open banking FAQ (who can authorise feeds, reminders, 90-day history on re-authentication). All read November 2026.