Corporate bank treasury API integration testing

Corporate bank treasury API integration testing checks that a corporate treasury system and a bank's application programming interface (API) exchange data and complete agreed workflows correctly. It verifies request and response contracts, authentication, payment processing, account information and error handling across the connected systems, including how each system behaves when a request is delayed, rejected or repeated.

What to test in a corporate bank treasury API integration

Start with the specific services and workflows in scope. A corporate treasury system may use bank APIs to retrieve balances and transactions, submit payments, obtain payment statuses or download statements. Each bank can expose different endpoints, fields, status models and security requirements, so derive tests from the applicable interface specification and business rules rather than assuming a common implementation.

Check the API contract: required and optional fields, data types, formats, enumerated values, identifier handling and validation errors. For financial data, verify currency codes, decimal precision, sign conventions, dates and time zones. Confirm that the treasury system maps bank responses to the correct legal entity, account and transaction. Where a workflow spans multiple systems, reconcile the result across the treasury system, bank response and any relevant payment or accounting record.

Test authentication and authorisation using the mechanisms required by the bank, which may include mutual Transport Layer Security (mTLS), OAuth 2.0 or another scheme. Verify token expiry and renewal, access to permitted accounts, and rejection of unauthorised operations. Use approved non-production credentials and synthetic or masked data. Do not place live credentials or unmasked customer information in test logs.

Prepare reliable integration tests

Agree the environment, API version, test accounts, permissions, test data and expected outcomes with the bank and internal service owners. Confirm which services the bank's test environment supports and how it represents processing delays, rejections and settlement. A sandbox may return simplified responses or omit downstream processing, so record its limits and arrange controlled validation in an authorised environment where required.

Keep test data repeatable. Give each payment a unique business reference, and define how the test will identify it in both systems. Capture correlation identifiers and timestamps so a failure can be traced through requests, responses and asynchronous status updates. Check environment configuration, certificates, endpoint URLs and API versions before execution; drift between test and production settings can cause failures that functional assertions will not reveal.

Build tests around both successful and unsuccessful paths. Include malformed requests, missing permissions, expired credentials, rejected payments, rate limiting and service unavailability where the environment permits. For timeouts, establish whether the bank received the request before retrying. Verify that retry behaviour cannot create an unintended duplicate payment, using the bank's documented idempotency or duplicate-detection rules.

Practical example: payment submission

Suppose a treasury system submits a payment and later receives a status update. A useful test case is:

1. Submit a valid payment for a test account with a unique client reference.
2. Assert that the response matches the bank's documented schema and contains the expected reference and initial status.
3. Retrieve or receive the subsequent status, then confirm the treasury system associates it with the original payment and displays the documented outcome.
4. Compare amount, currency, beneficiary and reference across the submitted request, bank status and treasury record.
5. Submit the same business instruction again under the documented retry conditions. Verify that the outcome follows the bank's duplicate-handling rules and does not create an unintended second payment.

An initial acceptance response does not necessarily mean that a payment has settled. Test the status transitions specified for that bank and workflow, and assert the correct final state only when the relevant evidence is available. For asynchronous updates, verify correlation, ordering and handling of repeated or late notifications.

How to verify results and diagnose failures

Use assertions at the API boundary and at the treasury system's business outcome. A successful HTTP response alone does not prove that the correct account was updated or that a payment reached the expected state. Check the stored transaction, displayed status and any required reconciliation record against the source request and bank response.

When a test fails, distinguish a contract mismatch from an environment or dependency problem. Preserve a redacted request and response, correlation ID, timestamp, API version and relevant configuration details. Classify timeouts carefully: the outcome may be unknown until a status query or reconciliation confirms whether the bank processed the instruction. This prevents a test rerun from creating a second financial instruction.