Bank account management

Bank account management (BAM) is the operating discipline that keeps every legal bank account in the group known, owned, mandated, and justified. It covers inventory and KYC/mandate control, signatory hygiene, opening and closing, bank-fee and relationship mapping, and structured rationalization — not a one-off spreadsheet cleanup.

Without BAM, liquidity management cannot see cash, cash pooling and payment factory designs stall on unknown accounts, and virtual accounts never retire the redundant collection accounts they were meant to replace. See how many bank accounts does a multinational need? for the sizing question.

What BAM covers

Domain	What “good” looks like
Inventory & ownership	Every account has an entity owner, purpose, currency, bank, and status (live / freeze / close)
KYC / mandate control	Opening packs, beneficial-owner data, and bank forms are current and versioned
Signatory / mandate hygiene	Dual-control matrices match policy; leavers and role changes are removed on a known SLA
Opening / closing	Standard request → approve → bank → TMS/ERP update path; no shadow accounts
Fee & relationship map	Which bank holds which corridor, with fee schedules and RFP cadence
Rationalization	Target account count by purpose; retire collection-only and idle accounts deliberately

BAM is governance plus data. A TMS account master without mandate discipline still fails an audit; a mandate binder without a live inventory still hides trapped cash.

Why it matters

• Liquidity — you cannot concentrate, forecast, or invest what you cannot list. Opening balances for cash forecasting start from a complete account book.
• Risk — stale signatories, orphan accounts, and unknown foreign-currency wallets are fraud and compliance exposure.
• Cost — account maintenance, statement fees, and idle balances compound across hundreds of entities.
• Structure readiness — POBO, ROBO, in-house bank, and pooling programmes assume a clean account map; BAM is the prerequisite, not a side project.

Inventory and ownership

Start with a single account register (TMS, BAM module, or controlled spreadsheet that feeds the TMS):

1. Legal entity, country, bank, branch, IBAN/account number, currency
2. Purpose tag (operating, collection, payroll, tax, escrow, pool header/participant, dormant)
3. Product flags (ZBA, notional, VA master, host-to-host, cards)
4. Owner (treasury vs local finance) and backup
5. Mandate / dual-control profile and last review date
6. Statement channel (MT940, camt.053, API, portal-only)
7. Status and next action (keep / migrate / close)

Reconcile the register to bank confirmations and to ERP vendor/customer bank fields at least annually — more often after M&A or a bank RFP. Portal-only accounts that never hit multi-bank reporting are the usual blind spots.

Design choices: central vs local

Central BAM — group treasury owns the register, opening/closing approval, and bank relationship map. Best when payment factory or regional pooling already concentrates flows.

Local-led with central standards — entities open within a policy envelope; treasury audits and can veto. Common where regulators or tax authorities expect local account control (see country notes such as China).

Hybrid by purpose — payroll/tax stay local; collection and concentration accounts follow central design. Pair with virtual accounts so inbound keys can shrink physical collection accounts without fighting every local licence rule.

Pick one model per region and write it down. Ambiguous ownership produces duplicate accounts and “temporary” wallets that never close.

Rationalization playbook

1. Classify — must-keep (regulatory, payroll, tax, escrow), structure-critical (pool header, factory funding), collection-only, idle/dormant, duplicate.
2. Prove substitutes — before closing a collection account, confirm VA / ROBO coverage and payer acceptance; before closing an operating account, confirm POBO or factory release works in that corridor.
3. Sequence — freeze mandates → redirect flows → zero balance → formal close → remove from TMS/ERP. Never delete the register row; mark closed with evidence.
4. Bank negotiation — rationalization often coincides with a relationship RFP; fewer accounts should show up as fee and service outcomes, not only as an internal KPI.
5. Steady state — quarterly dormancy review; new-account gate that requires a purpose tag and an exit condition.

Target counts are directional (see the FAQ). The win is fewer unjustified accounts, not a magic global number.

How BAM sits in the liquidity stack

• Visibility — complete balances under liquidity management
• Forecasting — reliable opening positions and bank actuals for cash forecasting
• Concentration — clean participant lists for cash pooling and cross-border designs
• VA / ROBO — account reduction path once allocation quality is proven (virtual accounts, ROBO)
• Factory / POBO — known funding and release accounts for payment factory and POBO
• IHB — external account map that matches internal current accounts without double-counting (in-house bank)

Minimum design package

1. Account register fields and ownership model (central / local / hybrid)
2. Opening and closing SOP with dual control and bank checklist
3. Signatory / mandate review calendar and leaver SLA
4. Purpose taxonomy and must-keep rules by jurisdiction
5. Rationalization backlog with substitute proof (VA, POBO, pool) before each close
6. Fee and relationship map tied to the same register
7. Link to liquidity management, virtual accounts, and factory/pooling decisions so BAM is not a parallel spreadsheet

BAM earns its keep when treasury can answer “how many accounts, where, and why” in one pass — and when closing an account is a routine control, not a project.