A UK platform that pays suppliers in Frankfurt, collects from customers in Manchester and settles a marketplace payout in Dublin is touching at least three different payment mechanisms in a single working day. Domestic rails handle the local legs quickly and cheaply. Anything that crosses outside the UK's Faster Payments network or the EU's SEPA zone usually has to travel a different route: correspondent banking, carried over the SWIFT network. Understanding how that route works, and where it sits alongside domestic rails, matters for any product team building payment flows on Banking as a Service infrastructure.

Domestic rails and their limits

UK domestic payments move using a sort code and account number, routed through Faster Payments, BACS or CHAPS depending on value and urgency. SEPA does the equivalent job across the eurozone, using an IBAN rather than a sort code. Both systems are closed networks. A sort code only means something to a bank in the UK clearing system. A SEPA IBAN only routes within participating eurozone institutions. Neither identifier carries any instruction for a bank in, say, Singapore or the United States.

This is where most platforms first run into friction. A business collecting GBP through a UK collection account and paying out in euros through a SEPA-linked IBAN has covered two rails well. The moment a payment needs to leave that footprint, a different mechanism takes over.

How a SWIFT payment actually moves end to end

SWIFT is not itself a payment system. It is a secure messaging network that banks use to instruct one another. The money moves through a chain of correspondent banking relationships, and the message tells each link in that chain what to do.

  1. Origination. The sending bank formats a payment instruction, typically as an ISO 20022 message, specifying beneficiary details, currency and any charges arrangement.
  2. Correspondent routing. If the sending and receiving banks do not have a direct relationship, the message passes through one or more intermediary banks that do have accounts with each other. Each intermediary debits and credits its own ledgers and forwards the instruction.
  3. Compliance screening. At each hop, banks screen the payment against sanctions lists and anti-money laundering rules. This can introduce delay, particularly where beneficiary or purpose details are incomplete.
  4. Crediting the beneficiary. The final bank in the chain credits the receiving account and, where SWIFT gpi tracking is used, confirms completion back through the network.

Settlement times vary with the number of intermediaries, the currency pair, cut-off times and how much screening is required. A same-day credit is common for well-established corridors; a payment through three or four correspondent banks in a less common currency can typically take several business days. These are typical patterns, not guarantees, and any BaaS provider offering cross-border payments should be able to explain what affects timing in a given corridor rather than quoting a fixed number.

Where Banking as a Service infrastructure fits

An API banking platform sits above these mechanisms and gives a product team one interface instead of several. In practice this usually breaks down into a few distinct capabilities.

  • EUR IBAN issuance gives a platform a genuine SEPA-reachable account, so euro payments in and out of the eurozone move on the domestic rail rather than through SWIFT.
  • GBP collection accounts, identified by a standard sort code and account number, do the same job for UK-domestic collections, keeping fast, low-friction payments on Faster Payments rather than routing them unnecessarily through correspondent banks.
  • Cross-border payments over SWIFT cover everything outside those two networks: US dollars, other non-SEPA currencies, or beneficiaries in jurisdictions without a domestic equivalent.
  • Payment scheme membership determines how directly a BaaS provider sits in this chain. Direct membership of a scheme means fewer intermediary steps for domestic payments. For SWIFT payments, the provider's own correspondent banking relationships determine how many hops a cross-border payment takes before reaching its destination.

The practical effect for a platform is that a single fintech banking infrastructure layer can present one API for a payment, while behind it the system chooses the right rail: SEPA for a euro payment inside the eurozone, Faster Payments for a domestic GBP transfer, SWIFT for anything that falls outside both.

Common integration mistakes

A few recurring errors show up when platform teams design cross-border flows without mapping the underlying mechanism.

  • Treating an IBAN as universally reachable. An EUR IBAN reaches SEPA participants. It does not automatically mean every payment sent to it will route domestically; some corridors still fall back to correspondent banking depending on the counterparty bank's connectivity.
  • Assuming the sent amount equals the received amount. Correspondent banks in a SWIFT chain can deduct their own handling charges before forwarding funds, so a beneficiary may receive less than the amount instructed. Reconciliation logic needs to account for this, particularly for marketplace payouts where exact amounts matter to the recipient.
  • Ignoring compliance data requirements. Incomplete beneficiary details, missing purpose codes or vague reference fields are a common cause of screening delays. Capturing full beneficiary information upfront in the platform's payout flow reduces this risk.
  • Building on a single rail and bolting on cross-border later. Platforms that design purely for domestic Faster Payments or SEPA often find their data model, especially around currency, beneficiary format and settlement confirmation, does not extend cleanly to SWIFT payments. Planning for multiple rails from the outset avoids a rebuild.
  • Quoting fixed settlement windows to end users. Because SWIFT timing depends on the corridor and the number of correspondent hops, presenting a fixed delivery time to customers creates expectations the underlying network cannot always meet.

What to check in a BaaS provider's cross-border capability

For a product or treasury team evaluating infrastructure, the useful questions are mechanical ones: does the provider hold payment scheme membership directly or route through a sponsor bank; are EUR IBANs issued as genuinely SEPA-reachable accounts or as virtual references sitting over a pooled account; and what correspondent banking relationships sit behind their SWIFT capability. London Rails Ltd. is one example of a BaaS provider built around these questions, but the same checklist applies whichever provider a platform is assessing. The answers determine how predictable, and how transparent, cross-border payments will be once the platform is live.