If you’re running global payouts, you’re probably not spending much time thinking about rails.
Your focus is on closing the books, managing payment runs, reconciling accounts, and ensuring suppliers and employees are paid on time. The infrastructure underneath those transfers feels like someone else's problem, until it isn't.
Here's the reality: every bank transfer you initiate moves through a clearing and settlement system that determines how quickly a payment arrives, what it costs, and what happens when something goes wrong.
Those outcomes land on your desk. Understanding what's driving them starts with knowing how the underlying system works.
The industry often frames rail decisions as a simple choice between SWIFT, the global bank-to-bank messaging network used for cross-border payments, and local clearing systems like Automated Clearing House (ACH) in the US, Faster Payments in the UK, or the Single Euro Payments Area (SEPA) in Europe. That framing misses the point.
The real question isn’t which rail is better. It's whether the rail being used matches the payment’s intent.
When that match is deliberate, you see fewer surprises. When it’s defaulted, the consequences surface later in unexpected fees, short settlements, delayed transfers, and additional reconciliation work. The problem is most finance teams don’t choose their routing setup. They inherit it from a banking setup, a provider default, or a decision made years ago that nobody revisited.
Over time, that default setup becomes strategy, whether it was designed that way or not.
The distinction that actually matters: settlement model
Every country runs its own payment system. Each works well within its own borders, but none of them naturally connect to each other. When you send money from a UK account to a US supplier, you're bridging two entirely separate systems. That's what SWIFT does: it's the global messaging layer that connects banks across countries, enabling them to route payments across their respective domestic networks.
Wherever a payment travels – domestic or cross-border – it will settle through one of two models:
- Real-Time Gross Settlement (RTGS) settles each payment individually, in real time. Every transfer moves on its own, in full, the moment it's sent. This is the model behind what most people call wire transfers. You pay more for that certainty, but you get traceability, formal confirmation, and a clear process if something goes wrong. For large, time-sensitive, or high-value payments, this is usually the right model.
- Deferred Net Settlement (DNS) works differently. Payments batch together and settle collectively at scheduled intervals. Multiple transfers share the route, which brings the cost down significantly. This is the model behind regular transfers such as payroll, pensions, regular supplier payments. It suits predictable, repeatable flows where urgency isn't the priority.
Think of it this way. Wire transfers are like a private car: more expensive, but door-to-door, immediate, and traceable. Regular transfers are a scheduled bus service: cheaper and efficient for predictable journeys, but not built for urgency.
With payments, the more meaningful distinction is not international versus domestic. It’s certainty versus efficiency. There is no universally better option, only a settlement model that fits the payment.
Why SWIFT still matters
SWIFT connects more than 11,500 members, with a presence in 92% of the world's countries and territories. It gets criticized for cost, but cost is only part of the picture.
What SWIFT provides beyond connectivity is structured servicing: payment tracking and tracing, formal investigations, confirmation messages, and established correspondent networks. For large or time-sensitive transfers, that visibility is critical. When a payment of material size goes wrong, the ability to trace it is worth more than the fee.
The question isn’t whether SWIFT is the right choice for every payment. The question is whether you’re using it deliberately, or just by default.
Where your team feels the impact
Rail strategy doesn’t come up in planning cycles. It appears when something goes wrong.
Consider principal protection. When international payments route through correspondent banks, intermediary deductions can reduce what arrives on the other end. A payment you sent for $1,000 lands as $950. The invoice then appears partially paid, your supplier raises a query, and your team spends time reconciling a discrepancy that was never fully visible from the start.
Failed and returned payments create a different kind of drag. Incorrect or outdated beneficiary details can trigger rejections. In many cases, returns are a manual process that can take weeks. Funds can return short after fees have been deducted in transit. The operational burden sits with your team, not with the infrastructure layer where the issue originated.
Delays, tracing requests, rejected transfers, and month-end variances create operational drag that reduces your bandwidth for higher-value work.
How routing becomes strategy by default
In theory, rail choice is deliberate. In practice, your routing is often inherited.
Enterprise finance teams typically run payments in structured batches, processed on fixed schedules. Once a process works, it rarely gets revisited, especially mid-cycle where changes introduce unnecessary risk. The original routing decision gets embedded in bank configurations, provider settings, and internal workflows. It becomes strategy by inertia.
In some cases, choice is also constrained. Not all providers expose multiple rail options. Some markets require specific systems. Local rails can be difficult to access from outside a jurisdiction without the right infrastructure in place.
Without visibility into what’s actually running, routing decisions remain buried in defaults, and your team inherits the consequences.
Making routing a deliberate choice
Rail strategy becomes strategic when routing is visible and tied to the intent of each payment.
For finance, that means understanding which payments require individual settlement and servicing, and which can move efficiently through net systems without introducing risk. Most teams don't have that picture. Not because the information doesn't exist, but because it's spread across bank portals, provider reports, and payment run logs that nobody consolidates.
By exposing available rails per market, capturing the correct information for each route upfront, and letting you configure payments by urgency and value, Primer turns routing from a static bank configuration into an operational lever you actually control.
The result: fewer exceptions, fewer reconciliation surprises, and clearer accountability for how money moves within your business.
In the next piece, we look at how foreign exchange decisions build on this same foundation, and where value leakage compounds further.
Talk to us about building a routing strategy that matches your payment intent.
