Treasury bank APIs: connect ERP and treasury systems directly to banking data

Bank APIs can connect treasury or ERP systems directly to account balances, transactions and payment services. That reduces manual file downloads and re-keying, but an API connection becomes part of the company's payment infrastructure and needs permissions, technical monitoring and contingency controls.

APIs can pull balances and transactions into treasury systems

Open Banking account-information APIs allow authorised providers to retrieve account data with explicit customer consent. Corporate banking and Swift APIs can also provide structured balance and transaction reporting.

This supports automated cash dashboards and intraday reconciliation without employees signing into each bank portal manually.

Some APIs can initiate payments as well as read data

Lloyds Banking Group's developer catalogue includes domestic, international, bulk and batch payment APIs under Open Banking permissions. Other banks and corporate channels provide their own API services.

Reading a balance and moving money are very different risks. Separate credentials, roles and approvals so a reporting integration cannot automatically become a payment integration.

ISO 20022 can standardise richer payment and reporting data

Swift's corporate ISO 20022 guidance describes pain.001 payment initiation and camt reporting messages for corporate-to-bank use. Structured remittance can improve reconciliation and data quality.

Design internal master data around the structured fields rather than converting rich messages back into one free-text bank reference.

Treat API credentials as banking credentials

Use secure key management, certificate rotation, least privilege and monitored service accounts. Do not store production payment secrets inside ordinary scripts or shared developer repositories.

Require strong change control for payment rules and beneficiary data. Automation makes a valid instruction move faster, including a fraudulent or mistaken one.

Test failure states before relying on straight-through processing

Simulate duplicate requests, timeouts, bank rejections, partial batch failure and unavailable endpoints. Use unique transaction IDs so retries do not create duplicate payments.

Keep a manual or secondary channel for critical payments. An API outage should not leave payroll impossible when the bank portal remains available.

Keep business owners responsible for automated payment logic

Technology teams can maintain connectivity, but finance should own payment limits, beneficiary rules and reconciliation. Document who approves code changes that can alter money movement.

Review API users and connected applications periodically. Remove integrations that no longer serve a business purpose and keep logs long enough to investigate incidents.

Worked example: a treasury system sends a £2 million supplier batch through an API and receives a timeout before the bank's final response. The system must query payment status using a unique identifier rather than immediately resubmit. Without idempotency and status logic, automation can create a £2 million duplicate faster than a human operator could.

Use separate production and test environments. Developers should be able to validate file formats, beneficiary fields and error handling without touching real company cash. Changes to payment code should require peer review and finance approval where they alter limits, beneficiaries or routing rules.

Monitor API availability and response quality. A connection can be technically online while returning stale balances or partial transaction data. Treasury should set alerts for missing feeds and keep a documented fallback to the bank portal or another channel for critical payments.

Maintain version and change management for bank APIs. Banks can introduce new fields, authentication requirements or version deadlines. An integration that worked for years can fail after a mandatory migration if nobody owns the technical roadmap.

Log both business approval and machine execution. The audit trail should show who approved a payment batch in the ERP, which system sent it, which bank response was received and when settlement occurred. Automation should increase traceability rather than create a black box between invoice and bank.

Use transaction limits at several layers where possible: ERP approval threshold, API service-account limit and bank-side mandate. Multiple controls reduce the chance that one coding error or compromised credential can release an unusually large payment. Limits should align so staff understand where a payment can be stopped and who can raise each threshold.

Keep certificates and keys on a renewal calendar. A payment API that stops working because a production certificate expired can be as disruptive as a bank outage. Renewal should be tested before expiry, with responsibility split between technology staff managing credentials and treasury staff confirming business continuity.

Run periodic access recertification for machine identities as well as human users. An old integration can retain payment or data permissions after the underlying project ended. Treasury and technology should jointly confirm which APIs remain required, which accounts they can reach and whether the permissions still match the original approved purpose.