Intermediary bank routing testing verifies that a payment is sent through the intended intermediary or correspondent bank on its way from the originating bank to the beneficiary bank. It checks routing decisions, payment instructions and resulting statuses across the systems involved, including whether exceptions are handled safely when a route is unavailable or its data is invalid.

What the test covers

An intermediary bank may be used when the sending and receiving banks do not hold a direct relationship or cannot settle in the payment currency directly. The payment route can depend on currency, destination, beneficiary bank, correspondent account arrangements and configured routing rules. The exact path and message fields depend on the payment scheme and the banks' implementation.

Testing checks that the originating system selects an eligible route and passes the correct intermediary details to the payment gateway or network. For example, a SWIFT MT message can carry intermediary institution details in field 56a. In an ISO 20022 credit transfer message, intermediary agents can be represented by elements such as IntrmyAgt1. The mapping between internal payment data and the outgoing format must preserve the intended bank and account information.

A useful test also follows the payment across system boundaries. It checks that the payment hub, network adapter and any downstream processing system agree on the route, amount, currency and transaction reference. Where the design supports multiple intermediaries, tests should confirm their sequence and the conditions that select each route.

How to verify the routing

Start with approved routing rules and a controlled test environment. Define the expected route for a payment using representative inputs, such as the currency, destination bank and beneficiary details. Use test data that reflects valid bank identifiers and account arrangements without exposing live customer information.

For each scenario, compare the expected route with the outbound payment instruction and the records produced by downstream systems. Check that:

  • the selected intermediary and any required correspondent account are correct;
  • identifiers, payment references, amount and currency remain consistent across message transformations;
  • the payment is accepted, rejected or held according to the defined response;
  • status updates and reconciliation records refer to the same transaction.

Evidence can include the original payment request, the generated network message, gateway logs, acknowledgements and ledger or reconciliation records. A successful test response alone does not prove that the payment followed the intended route. Confirm the route using the available message and processing evidence, while respecting access controls for sensitive payment data.

Practical example

Assume a bank sends a payment in a currency for which its beneficiary bank uses a correspondent. Configure a test payment with the relevant destination bank and currency, and define the expected intermediary in the routing rules. Submit it through the payment interface. Assert that the outbound instruction contains the configured intermediary, that the amount and currency are unchanged, and that the returned status and reconciliation entry carry the original transaction reference.

Then change the test configuration so the intermediary is unavailable or the route is ineligible. Verify the specified outcome, such as selecting an approved alternative route, placing the payment in a repair queue or rejecting it. Confirm that retries do not create a second payment and that a rejected or held payment is not reported as settled.

Failure modes and scope

Common defects include a route selected for the wrong currency, missing or stale intermediary data, incorrect message-field mapping, truncated identifiers and inconsistent routing rules between environments. Environment drift can make a test pass against one configuration while production uses another. Record the relevant configuration version with the test evidence and include route changes in regression testing.

Intermediary bank routing testing is a focused form of payment and integration testing. It examines the correctness of the route and the exchange of payment data across connected systems. Broader end-to-end testing can cover the full customer payment journey, settlement and reconciliation, while correspondent banking integration testing can include a wider range of services and operational processes.

Frequently asked questions

Does every international payment use an intermediary bank?

No. Whether a payment uses an intermediary depends on the banks' settlement arrangements, the currency, destination and available route. Test cases should reflect the routes configured for the payment service.

Can intermediary routing be tested without sending a live payment?

Yes. Teams commonly test in a controlled environment using a payment network simulator, a bank-provided test service or stubs for unavailable counterparties. The setup should still expose the message and status behaviour needed to verify the route.

Who usually owns intermediary routing rules?

Ownership varies by organisation. Payment operations, product teams and technology teams may share responsibility, so tests should identify the authoritative rule source and the approval process for changes.

When should routing tests be rerun?

Rerun affected tests after changes to route configuration, payment message mapping, network connectivity or relevant downstream processing. Include representative routing scenarios in regression testing when shared payment components change.