Businesses rarely choose to bank in several places. It accumulates: one account from incorporation, another because a lender required it, a third because a vendor or a state operation made it convenient. The result is real money spread across portals that do not talk to each other.
The real cost of fragmentation
The visible cost is time — logging into several portals to answer what should be a one-line question about available cash. The expensive cost is slower decisions. If assembling a position takes half a day, nobody does it daily, and the business runs on a picture that is always slightly out of date.
- Cash position is a reconstruction rather than a number, so it is produced weekly at best.
- Statements arrive in different formats on different schedules, and somebody normalises them by hand.
- Payments are initiated in whichever portal holds the funds, so approval practice differs per bank.
- Nobody can answer 'what did we pay this vendor across all accounts' without a manual search.
- Idle balances sit undetected in one account while another is overdrawn.
How fragmentation actually happens
No finance team sets out to run six current accounts. Each one arrived for a defensible reason, and none of them is worth the disruption of closing on its own.
- The incorporation account, opened wherever the founders already banked.
- A lender's account, required as a condition of a facility.
- A collections account at a bank whose virtual account product suited the receivables problem.
- A state or regional account opened because a counterparty or a registration demanded a local presence.
- A legacy account from an acquisition, kept because unwinding it is somebody's low-priority project.
The useful observation is that none of these is a mistake. The mistake is treating the resulting fragmentation as something to fix by consolidating banks, rather than as something to manage by consolidating the view.
What connected banking actually does
It links existing accounts to a single interface, so balances and transactions across all of them can be read in one place and payments initiated without visiting each bank's portal.
The three capabilities, which are not the same thing
| Capability | What it gives you | Risk it carries |
|---|---|---|
| Balance visibility | A current position across all accounts | Read-only — minimal |
| Transaction feed | One normalised history for reconciliation | Read-only, but data leaves the bank's portal |
| Payment initiation | Sending from any account in one place | Material — this moves money |
Many adoptions take all three because they come bundled. It is worth deciding deliberately: an account you only need visibility on can be connected read-only, which removes it from the blast radius entirely.
What to ask before adopting one
Platforms differ most in the areas that are hardest to evaluate from a demo. These are the questions worth pressing on.
How current is the balance?
Live, or a periodic snapshot? For reporting a snapshot is fine. For deciding whether a payment run can go out this afternoon, the difference between live and four hours old is the whole value.
Press on what happens when the refresh fails. A stale balance displayed as current is worse than no balance, because somebody will make a decision on it. The answer you want is that the interface says when it last synced and flags anything beyond a threshold.
What can it do, versus what can it see?
Read-only aggregation and payment initiation are very different propositions with very different risk. Be clear which accounts are which, and confirm that an account can be connected in read-only mode where you want visibility without exposure.
How does data get out?
An export or an API that feeds your accounting system is what converts visibility into less month-end work. Without it you have replaced several portals with one portal, which is an improvement but a small one.
- Is the transaction feed normalised across banks, or does each bank's quirks come through?
- Can it be pulled on a schedule, or only exported by hand?
- Does it carry a stable identifier per transaction, so repeated pulls do not create duplicates?
- How far back does history go when an account is first connected?
What happens when a connection breaks?
Connections do break — credentials rotate, banks change interfaces, consents expire. The question is whether you find out immediately or discover it when a balance looks wrong.
Ask how reconnection works and who can do it. If it requires a specific person's credentials and that person is on leave, the answer to 'what is our cash position' becomes 'we are not sure' for a week.
Access control is the part to get right first
Consolidating accounts consolidates risk. One interface that can initiate payments from every account is valuable precisely because it is powerful, which makes roles and approvals the first thing to configure rather than the last.
- Separate initiation from approvalThe person who creates a payment should not be the person who releases it. This is the single most effective control available and costs nothing.
- Set thresholds that escalateAbove a defined amount, require a second approver. Pick the threshold from what a mistake would cost, not from what is convenient.
- Scope access per accountNot everyone who needs to see the operating account needs access to the one holding reserves.
- Treat beneficiary changes as privilegedEditing a payout destination should need the same approval as sending money to it, because functionally it is the same act delayed.
- Make the log immutable and reviewedAn audit trail nobody reads is a record for after the incident. Review it on a schedule so it also works as a detection control.
A workable role split for a small finance team
Teams of three or four often conclude that separation of duties is impractical at their size. It is not — it just needs the roles drawn around the work rather than around headcount.
| Role | Can | Cannot |
|---|---|---|
| Preparer | Create payments, upload batches, add beneficiaries | Approve anything they created |
| Approver | Release payments within a limit | Create payments or edit beneficiaries |
| Senior approver | Release above the limit, as second approver | Act as sole approver on their own items |
| Viewer | See balances and history, export data | Initiate or approve anything |
The viewer role is the one most often omitted and the most useful. Auditors, founders and advisors usually need to see rather than to act, and giving them a full login because no read-only option exists is how access quietly spreads.
What changes at month end
The strongest argument for connected banking is rarely the dashboard. It is that one normalised transaction feed removes the step where somebody reformats five bank statements before any reconciliation can begin.
- Pull one feed instead of downloading five statements in four formats.
- Match against your ledger using a stable per-transaction identifier rather than a date-and-amount heuristic.
- Investigate the exceptions, which are now a short list rather than a spreadsheet.
- Close, with the knowledge that anything unmatched is genuinely unexplained rather than a formatting artefact.
If collections are the harder half of your reconciliation, virtual accounts solve the identity problem at source by making the destination identify the payer.
Security questions worth asking the provider
A platform that can read every account and initiate payments from several of them concentrates a lot of capability in one place. That is the point, and it is also why the security questions deserve more than a glance at a certification badge.
- How is the connection to each bank authenticated, and what is stored on the platform's side? There is a meaningful difference between a token scoped to specific operations and stored banking credentials.
- Can an account be connected read-only, enforced by the bank rather than by the interface?
- What happens to the connection when the authorising person leaves your company?
- Is there an audit log you can export, or only one you can view inside their product?
- How are payment approvals enforced — in the platform, or at the bank? The second survives a compromise of the first.
- What is the incident notification commitment, in writing?
Rolling it out
The temptation is to connect every account on day one and switch off the old portals. The better sequence treats it as a migration, because the failure mode — a payment run that cannot go out because a connection broke — is expensive and avoidable.
- Connect read-only firstVisibility across every account, with no initiation anywhere. This alone delivers most of the reporting benefit and carries almost no risk.
- Run a month of parallel reconciliationReconcile from the platform's feed and from the bank statements, and compare. Discrepancies here are a data-quality problem you want to find now rather than at a year end.
- Enable initiation on one accountPreferably the operating account with the most routine, lowest-value payments. Prove the approval workflow with real traffic.
- Extend account by accountEach one with its own approval configuration rather than a copied default, because the reserve account should not inherit the operating account's limits.
- Keep one bank portal path openNot as a habit but as a documented fallback, with someone who knows how to use it. Connections break, and a payment run should not be blocked by one.
Frequently asked questions
Do I have to move my accounts to use connected banking?
No. The accounts stay with their existing banks on existing terms. Connected banking links them to one interface for visibility and, where enabled, payment initiation.
Is it read-only, or can it move money?
That depends on the platform and how you configure each account. Many setups allow read-only connection for some accounts and initiation for others — which is often the sensible arrangement.
What is the most important thing to configure at setup?
Separation between who creates a payment and who approves it, with escalation above a threshold. It is the highest-value control and much easier to establish at onboarding than to introduce later.
Can separation of duties work in a three-person finance team?
Yes, if the roles are drawn around the work rather than headcount: a preparer who creates but cannot approve, an approver who releases but cannot create, and a read-only viewer for anyone who needs sight without action.
What happens if a bank connection breaks?
Connections do break when credentials rotate or consents expire. Ask how you are notified and who can reconnect — if it needs one specific person, their leave becomes a gap in your cash visibility.
How does this help at month end?
Mainly through data export. One normalised transaction feed across all accounts removes the manual step of reformatting each bank's statement before anything can be reconciled.
Should changing a beneficiary's bank details require approval?
Yes. Editing a payout destination is functionally the same act as sending money there, just delayed, so it deserves the same control.
