The two names get used as if they were fast and slow versions of the same service. They are not the same kind of thing at all, and the difference explains most of what businesses find surprising about cross-border payments.
SEPA is a clearing scheme. It moves euro between accounts in participating countries under a common rulebook, with harmonised timing and a defined charge model.
SWIFT is a messaging network. It does not move money. It carries payment instructions between institutions that already hold accounts with one another. The money moves through those relationships — the correspondent chain — and the chain is where the cost and the delay live.
Once that distinction is clear, most of the practical guidance follows from it.
What each one is good at
| SEPA / SEPA Instant | SWIFT | |
|---|---|---|
| Currency | EUR only | Effectively any |
| Geography | SEPA participating countries | Global |
| Settlement | Same day; instant scheme in seconds | Typically 1–5 business days |
| Intermediaries | None — direct clearing | Commonly 1–3 |
| Charge model | Shared, defined by the scheme | Negotiated per leg; deductions possible |
| Cost predictability | High | Low without an agreed charge option |
Settlement speed is not the main difference
Speed is the headline, but predictability is what actually affects operations.
A SEPA credit transfer settles on a known schedule. SEPA Instant settles in seconds, around the clock, subject to per-transaction limits set by the scheme and by the institutions involved. Either way, you can tell a supplier when the money will arrive and be right.
A SWIFT payment settles when the correspondent chain has finished with it. With SWIFT gpi the payment is at least trackable end to end, which is a genuine improvement over the era of phoning a bank to ask where the money went. But tracking tells you where a payment is; it does not make the chain shorter.
For treasury purposes, "arrives in seconds" and "arrives in one to five days, observable" are not two points on one scale. They are different planning problems.
The cost question, honestly
SEPA's cost structure is set by the scheme: charges are shared between payer and payee, and the transferred amount is not reduced in transit.
SWIFT's is negotiated per leg, and this is where the well-known complaint originates — a supplier is invoiced 10,000 and receives 9,962. Nothing has gone wrong; intermediary institutions in the chain deducted their charges from the principal.
The charge option is what governs this, and it is a field on the instruction:
- SHA (shared) — the default. Sender pays their own institution's charge, deductions may still occur down the chain.
- OUR — sender pays all charges. The payee receives the full invoiced amount.
- BEN — payee bears all charges, deducted from the principal.
If your contracts specify an amount to be received rather than an amount to be sent, the charge option is not a technicality. Agree it in the contract, not at the point of payment.
ISO 20022 and why the data matters now
Both worlds have converged on the ISO 20022 message standard. The practical effect is that payment messages now carry structured, richer data — properly delimited party details, purpose codes, remittance information — rather than the free-text fields of the older formats.
Two consequences for a finance team:
Reconciliation gets better, if you use it. Structured remittance data can be matched automatically. It only helps if payers actually populate it, which means telling them what to populate.
Compliance screening gets stricter. Truncated or ambiguous party data used to pass. Increasingly it is what causes a payment to be held for review. Complete, correctly-formatted party details are now an operational requirement, not a nicety.
Choosing, in practice
Use SEPA when the payment is in euro and both ends are in the SEPA area. It is faster, cheaper, and the amount that arrives is the amount you sent. Use SEPA Instant where the counterparty supports it and the amount is within scheme limits — particularly for anything time-critical.
Use SWIFT when currency or geography leaves you no alternative: USD, CAD, most of Asia and MENA. Agree the charge option in advance, state complete party details, and build the settlement window into your terms rather than discovering it.
The common mistake is choosing by habit — routing a euro payment to a German supplier over SWIFT because that is what the finance system defaults to, and paying several days and a deduction for the privilege.
How this works with 2PayApp
A 2PayApp business payment account can support EUR, GBP and USD, with access to payment rails including SEPA, SEPA Instant, Faster Payments, SWIFT and ACH, so the rail can be chosen per payment rather than per provider.
2PAYAPP LIMITED is registered with FINTRAC as a Canadian Money Services Business. FINTRAC registration is a legal registration requirement; it is not a banking licence and does not constitute an endorsement by FINTRAC. 2PayApp is not a bank. Available currencies, payment rails and transaction limits are subject to onboarding, compliance approval, provider availability and the customer's approved account configuration.
FAQ
Can I send euro over SWIFT? Yes, and sometimes you must — if the beneficiary is outside the SEPA area. Inside it, SEPA is almost always the better route.
Why did my payment arrive short? Intermediary charges deducted in transit on a SHA or BEN instruction. Use OUR if the beneficiary must receive the full amount.
Is SEPA Instant available for any amount? No. The scheme sets a per-transaction ceiling, and individual institutions may apply lower limits.
Does ISO 20022 make SWIFT as fast as SEPA? No. It improves the data carried in the message. The correspondent chain, which is what determines the timing, is unchanged.