Straight-through processing: what puts a cross-border payment in the repair queue

A cross-border payment does not travel. It is re-created at every institution in the chain, and each one decides where to send it next from the data in the message. Straight-through processing means every hop resolved that automatically. When one hop cannot, a person opens the payment by hand — the difference between a two-day settlement and a five-day one.

Straight-through processing (STP) describes a payment that moves from initiation to settlement without manual intervention at any point in the chain. The definition is operational rather than aspirational. What STP removes is a specific cost: the work an institution does when it has to repair a payment, add missing data by hand, or apply a workaround to get it moving again.

The useful number is not your average settlement time. It is the share of payments that never reach a human.

That distinction matters because repair is not proportional. A payment that clears automatically takes minutes of machine time. A payment that drops into a repair queue takes an operator, a cut-off window it has now missed, and often an email round-trip to a counterparty in a different time zone. One failed hop costs a day, not an hour.

Treasury teams tend to track the average because that is what provider dashboards show. The tail is where the working-capital damage sits.

Cross-border payments move through the correspondent model. Your provider debits the account, a correspondent holds the currency, another institution has the relationship in the destination market, and the beneficiary’s provider credits the account. That is three or four institutions between you and the payee, depending on whether one of them covers two roles.

Each hop does three things independently. It re-derives the next destination from the message, it applies its own sanctions and screening rules, and it applies its own cut-off time.

None of these institutions can see the whole chain. Each sees one inbound message and decides what to do with it.

Consider a CAD payout from a Toronto client to a EUR account in Lisbon. In the accounting system it is one line. On the rails it is a currency conversion, a Canadian debit, a EUR correspondent leg, and a domestic credit in Portugal. Four separate resolution decisions, any of which can fail on data that looked complete at submission.

The sending institution does not phone anyone. It reads its own reference data and fills the routing fields from there.

Standing settlement instructions

Standing settlement instructions (SSI) are the published record of how an institution wants to be paid in a given currency: the account details, the clearing information, and the settlement preferences that apply. Swift distributes this as structured reference data through the SwiftRef Standing Settlement Instructions Directory, which sending institutions load directly into their payment systems.

When the receiving side’s SSI are published there, the sending bank’s system resolves the route from its own directory. No one asks anyone to confirm anything.

When they are not published, the routing has to come from somewhere else — usually the payment instruction itself, typed in by whoever set up the beneficiary. That is the moment the error enters. A stale intermediary institution, a correspondent that has since changed, a field left blank because the person filling it in did not know what belonged there.

The payment still leaves. It fails two hops later, where nobody involved knows the client or the context.

What that looks like from the client side

The visible symptom is rarely «routing data was missing.» It is a payment that shows as sent, does not arrive, and cannot be explained by either end for 48 hours.

Missing or stale intermediary routing. The message reaches an institution that has no direct relationship in the destination market and no instruction on where to pass the payment next. It stops there pending manual investigation.

Unstructured party data. ISO 20022 replaced free-text name and address blocks with structured fields for exactly this reason. A beneficiary address that arrives as one long text string cannot be validated automatically, so an operator validates it instead.

Truncated remittance information. Legacy message formats cap the reference field. When an invoice reference is cut off mid-string, the beneficiary’s provider can credit the account but cannot reconcile it, and the beneficiary’s finance team opens a query that lands back with you.

Name and screening mismatches. A beneficiary registered as one legal entity but paid under a trading name will hit a screening rule somewhere in the chain. The payment is not rejected; it is held for review, which is slower.

The second of those has a deadline attached. Under the 2025 SEPA Credit Transfer rulebook, the unstructured address format stops being permitted on 15 November 2026, aligned with the Swift standards release that month. Beneficiary records still holding an address as one string will fail outright rather than merely slow down.

Only the first of these is about the rail. The other three are about how disciplined the payment instruction was before it ever left. That is why beneficiary data quality is part of onboarding rather than an afterthought — the same logic that shapes our KYC requirements.

We operate on the Swift network under our own Business Identifier Code (BIC), and our settlement instructions are published in SwiftRef.

In practice a sending institution routes to us straight from its own reference data. There is no intermediary institution to fill in by hand and no request to confirm correspondent details before the first payment can be sent. Fewer fields typed by a person means fewer repairs downstream.

We are registered with the Bank of Canada as a payment service provider under the Retail Payment Activities Act (RPAA). The entry is public and dated: MONTOWIRE MSB LTD has appeared on the Bank’s registry of payment service providers since 17 October 2025. We are also registered with FINTRAC as a money services business, registration M23481791.

Neither registration is a license, and neither is an endorsement. Both carry reporting obligations, and those obligations shape how onboarding and monitoring work. We are not a bank in any jurisdiction. We are a non-bank payment service provider running international and local payments for business clients.

Reference data is unglamorous. It is also the reason payments arrive on the day you told your supplier they would.

The rails differ less in headline speed than in how the beneficiary is identified — which determines what can go wrong.

Two structural points follow. Under the SEPA Credit Transfer rulebook, funds reach the beneficiary’s provider by the next business day at the latest, so the variable there is not the rail but whether the IBAN passes verification.

Swift has no scheme-wide deadline at all, and timing is the sum of the hops. Where a payment lands inside the European Economic Area, PSD2 sets execution-time obligations on the leg inside the union, but nothing binds the chain end to end. That is why a single repair changes the outcome.

Domestic rails collapse the chain to a single hop. That is why a local rail beats a correspondent route on predictability, whichever provider you use. It is also why routing a corridor over the same rail every month is worth more than chasing the lowest headline fee — a trade-off that sits alongside how currency conversion is priced on the same flow.

Ask your provider for its straight-through processing rate on your payments last quarter. A provider that measures STP will have the number. A provider that answers with an average settlement time is telling you it does not track the tail.

Then look at your repeat beneficiaries. Payments to the same counterparty that settle in two days one month and five the next are almost never a rail problem — they are a data problem that resolves differently depending on which operator picks up the queue.

Finally, check where your beneficiary records live. If the routing details sit in a spreadsheet that someone copies into the payment screen, you are re-entering the failure point every time. Holding balances in the destination currency on a multi-currency business account removes a conversion hop and, with it, one of the places the chain can stall.

The question worth asking about a cross-border payment is not how fast it is sent, but how many institutions have to make a routing decision about it, and whether each of them can make that decision without a person. Published reference data, structured party data, and a shorter chain all reduce the same risk. Everything else is presentation.

Open a multi-currency business account with Montowire. We route through Swift under our own BIC, indirect SEPA, Interac through a Canadian payment provider, and ACH, across our payout network. Registration takes place in the Montowire app, and our payments team will walk your treasury through corridor-level routing before your first payment goes out.