Routing logic

In the context of payments, routing refers to the process of determining which payment network or rail will be used to conduct the transfer from the sender's account to the recipient's account, ensuring optimal speed, cost, and reliability of the transaction.

To simplify operations and maximize payment success rates, our routing logic includes intelligent features such as automatic retries and automatic rerouting to alternative payment rails when the preferred rail is unavailable.

While our default routing logic handles most scenarios automatically, you can also specify in some cases your preferred payment rail when needed, giving you full control over how your payments are processed.

Understanding Routing Controls

There are multiple levels of control over how payments are routed, from fully automated processing to specific per-payment instructions. This allows you to balance the desire to process the payment on any rail, or to prioritize a specific rail, in accordance to your needs.

Default Routing Logic

Our default routing logic prioritises successful payment processing above all other considerations, including the use of specific payment rails. This behavior applies universally across all payment types and currencies, unless you explicitly specify a network override or other logic for individual payments.

In most cases, payments follow this processing hierarchy, where the system automatically falls back to the next available rail if the preferred option is unavailable:

1. Instant local clearing (when available)
2. Local batch clearing
3. Real-Time Gross Settlement (RTGS)
4. Correspondent bank routing

Per-Payment Network Override for EUR payments

For EUR payments, we offer the option to override the default routing logic, on a per-payment basis. We offer two options for this:

1. Preferred Clearing Network, with fallback

This option allows you to specify a preferred rail, but not at the expense of processing the payment if the selected rail is not available.

We will try to process the payment on the selected rail, but if it is not available, we will fall back to the next rail in the order. The following values are available:

• SEPAINST: Forces SEPA Instant Credit Transfer
• SEPA: Forces SEPA Credit Transfer
• T2: Forces T2 (Target2) - note that specifying T2 is not available if instructing via pacs.008

For example, if a EUR payment with a network override value set to SEPAINST and fails, it will fall back to SEPA (SEPA Credit Transfer), then T2 (Target2), then correspondent bank.

You can use this feature by setting the clearingNetwork property in the single and bulk API endpoints, as well as ISO 20022 pain.001 and pacs.008 messages. See the API Reference for more details.

2. Prioritized Clearing Network List, without fallback

Occasionally you may want to process payments only on some rails, and exclude other fallback options. You can do that by setting the PrioritizedClearingNetworks property, which accepts a list of clearing networks to try, in the order of priority. Our system will only attempt to process the payments using the rails specified, in the order of priority stated. If all networks in your list fail, the payment will be rejected rather than falling back to other available networks.

For example, you might specify ["SEPAINST", "T2"] for a payment with a EUR amount.

This means our system will:

• Try SEPA Instant first
• If that fails, try T2
• If T2 fails, reject the payment (the system will not try SEPA Credit Transfer or correspondent bank)

This property is available in the single and bulk API endpoints, as well as ISO 20022 pain.001 and pacs.008 messages.

Note: The availability of override options depends on your client ID configuration, the specific payment details and your contractual agreement.

See the API Reference for more details.

Disabling Payment Rails

You can also choose to completely disable specific payment rails. These rails will then never be used for your payments, even as fallback options.

Payment Processing Mechanisms

The routing logic includes automated mechanisms to handle various scenarios that may arise during payment processing, ensuring maximum payment success rates while respecting scheme rules and limits.

Scheme Rules and Limits

Different payment schemes have specific transaction limits and rules that affect routing decisions. When a payment cannot be processed through the preferred rail due to these limitations, the routing logic will automatically attempt to use alternative rails based on your configuration.

Current transaction limits across instant clearing schemes:

Automatic Retry Process

When using instant payment schemes, certain temporary issues may prevent immediate processing. In these cases, our routing logic will automatically retry the payment before considering alternative routes.

For example, with SEPA Instant payments:

• If a soft rejection is received (such as beneficiary bank timeout or temporary offline status), the payment will be retried on SEPA Instant once every 30min, up to 20 times (in other words, the retry period can last a maximum of 10h).
• During the retry period, the payment status remains "Pending Processing"
• If successful processing isn't achieved within the retry period, the payment will either be rerouted or rejected depending on the specific scenario

Common scenarios triggering retries:

• Agent timeout
• Offline creditor bank
• Temporary system unavailability

Automatic Rerouting Process

While retries handle temporary issues, rerouting occurs when a payment cannot be processed through the preferred rail due to more fundamental limitations or restrictions. The payment will automatically be rerouted to an alternative rail according to your configuration priorities.

A number of scenarios can trigger a rerouting event. Common examples include:

• Regulatory restrictions
• Forbidden transaction types
• Scheme-specific limitations

For example, with SEPA Instant payments, rerouting to SEPA Credit Transfer occurs when:

• The transaction amount exceeds the scheme limit (over 100,000 EUR)
• A hard rejection is received due to scheme-specific restrictions
• The beneficiary bank is not reachable via SEPA Instant

Error Codes Indicating Rerouting

The following error codes indicate that a payment will be automatically rerouted:

Checking Rerouting Status

Rerouting events are tracked via the routingStatus property, which show the requested routing, the rail the payment was processed on, and the reason why the rerouting occurred.

This is available in the following endpoints: GET Singles Payments, GET Payment status and GET Oayment by transaction reference

You can also subscribe to specific Payment Routing notification Payment Routing notification.

Error Handling

When processing payments, errors are categorized based on their nature and how they should be handled. Understanding these categories helps predict whether a payment will be retried, rerouted, or rejected.

Soft Rejections

These are temporary issues that may be resolved through retries:

• Agent timeout
• Offline creditor bank
• Temporary system unavailability

Payments receiving soft rejections will remain in "Pending Processing" status during the retry period.

Hard Rejections

These are divided into two categories:

1. Reroutable Rejections

• Trigger automatic rerouting to alternative rails
• Include regulatory restrictions, scheme limitations, and transaction type restrictions
• See error codes table in Rerouting section above

2. Terminal Rejections
   These result in the payment being rejected back to the client without rerouting attempts:

• Invalid or closed account number
• Blocked account
• Other fundamental beneficiary account issues

Note: For payments that cannot be processed through any available rail, you will receive a clear rejection reason to help you take appropriate action.

Tracking and Monitoring

Identifying the Payment Rail Used

You can find information about which rail was used for executing your payment through multiple channels:

• GET single payments API endpoint
• GET single payment by ID API endpoint
• Webhook notifications
• Reconciliation report

The paymentRail property in these responses will contain one of the following values:

Payment Status Tracking

When monitoring payments that may be subject to retries or rerouting, pay attention to the following statuses:

During Retry Process

• The payment remains in "Pending Processing" status throughout the retry period
• If retries are successful, the status will change to "Processed"
• If retries are unsuccessful after the maximum retry period (2.5 hours for SEPA Instant), the payment will either:
  • Move to "Processed" if successfully rerouted
  • Move to "Rejected" if rerouting is not possible

During Rerouting

• For automatic rerouting (e.g., when amount exceeds instant payment limits), the payment moves directly to "Processed" once completed through the alternative rail
• The final paymentRail value will indicate which rail was ultimately used

You can track these status changes through:

• API endpoints for payment status
• Webhook notifications for status changes
• The reconciliation report

Note: For the most up-to-date status information, we recommend implementing webhook notifications for real-time updates.

Limitations and Special Considerations

The network selection, automatic retry and rerouting features described in this document are not available for all payment types. The following scenarios fall outside the scope of these features:

Payment Channels

• Payments initiated via the Client Portal do not allow you to specify a payment rail
• Agency banking payments
• Payments handled in sanctions screening
• FX-related payments
• T2 network override for pacs messages

Payment Types

• Bulk files containing more than 300 payment instructions

Configuration Requirements

• Network override functionality requires specific setup in your client ID configuration
• Some payment rails may be unavailable based on your contractual agreement
• Rerouting between different currencies is not supported

Note: contact your Relationship Manager to discuss your specific requirements and available options for these scenarios.