Business bank audit logs: preserve who created, changed and approved every material action

Business-bank portals can record who logged in, created a payment, changed a beneficiary, approved a batch or altered account settings. Those logs are valuable evidence during fraud investigations and internal audits, but they only help if the company knows what data exists and preserves it before portal history expires.

Know which actions the bank logs

Ask the bank which events are recorded and visible to administrators. Useful events include login, payment creation, approval, rejection, beneficiary changes, card management and user-permission changes.

Some portals show only recent history while deeper logs require a bank request. Document how to retrieve them before an incident.

Named users make logs meaningful

An audit trail showing "FinanceUser1" is weak if five employees share the credential. Each bank user should have an individual account so activity can be attributed accurately.

Shared security devices or approval tokens can also weaken evidence. Use named authentication wherever the provider supports it.

Review sensitive actions, not every click

Focus monitoring on new beneficiaries, high-value payments, permission changes, unusual login times and failed authentication.

A monthly or quarterly report of those actions can reveal dormant access or unusual behaviour without overwhelming finance with routine statement downloads.

Export logs immediately after suspected fraud

If a payment is disputed or an account takeover is suspected, preserve the portal activity and ask the bank for server-side records where available.

Do not delete the user account before capturing what it did. Disable access first if possible and preserve evidence for the bank, police or insurer.

Align retention with accounting and fraud needs

Bank portals can retain activity for a limited period. Export important payment approvals or administrative logs where the company needs longer evidence.

Keep them securely because audit logs themselves contain sensitive account and user information.

Reconcile portal logs with ERP and bank statements

For material payment runs, finance should be able to trace invoice approval in the ERP, payment creation in the bank, approver identity and final statement debit.

Differences identify broken controls. A bank payment with no ERP approval or a beneficiary change with no supplier-verification record deserves investigation.

Worked example: a £180,000 payment goes to an unexpected account. The bank portal shows User A changed the beneficiary at 21:14, User B approved the change at 21:18 and User A released the payment at 21:22. That timeline immediately focuses the investigation on credential compromise or process failure.

Keep audit-log access separate from payment authority where possible. A security or internal-audit employee can need evidence without needing the ability to create transactions.

Test retrieval annually. A company that discovers during fraud that only the bank can retrieve six-month-old admin logs should already know the request route and expected response time.

Worked example: internal audit samples a £75,000 supplier payment. The ERP shows the invoice approved by procurement, the bank log shows User A created the payment at 10:04, User B approved at 10:18 and the statement shows settlement that afternoon. That complete chain is far stronger evidence than a bank statement alone.

Preserve logs around system migrations. When a company changes bank portals or merges accounts after an acquisition, historic administrative data can disappear from easy online access. Export important user and approval history before closing the old service.

Use logs to review failed actions too. Repeated failed logins, rejected payment attempts or unsuccessful beneficiary changes can indicate user training problems or attempted abuse even when no money moved.

Restrict audit-log deletion where the platform allows administrative cleanup. Security evidence should not be erasable by the same user whose actions it records without another layer of control.

Set a retention policy for exported bank evidence. Payment approvals can be relevant to statutory accounts, fraud investigations, insurance claims and lender reviews years later. Store exports in a read-only or controlled archive rather than one employee's downloads folder.

Use audit logs in access recertification. If a user has approval rights but has not logged in for nine months, finance should ask whether that permission is still needed or should be removed before the account becomes a forgotten attack surface.

Use one incident-export format that records timestamp, user, action, account, beneficiary and amount. Standardisation makes it easier to compare events across different bank portals during a fraud investigation. Where a bank cannot export those fields directly, create a controlled incident worksheet rather than copying screenshots into email threads.

Periodically compare bank administrator lists with internal IT privileged-access lists. A user removed from Microsoft 365 or the ERP can still remain active in the bank portal if offboarding is not coordinated across systems.