By: Money Navigator Research Team
Last Reviewed: 04/02/2026
FACT CHECKED
Quick Summary
SWIFT, SEPA and ACH are not “types of bank accounts” – they are payment networks/schemes that determine where a payment can go, what details are required, how it is processed, and why fees/timings vary.
In Tide, international sending is framed mainly as EUR via SEPA and USD to the US via ACH, while GBP can be received internationally via SWIFT; USD receiving is currently not supported.
This article is educational and not financial advice.
What these three terms actually describe
An “international transfer” can mean any combination of:
Cross-border messaging (how banks communicate payment instructions),
Clearing and settlement (how money moves between banks),
Currency and FX conversion (how amounts are converted and priced),
Intermediaries (how many institutions touch the payment on the way).
SWIFT, SEPA and ACH sit in different places in that stack. Understanding that helps explain why two “bank transfers” can behave very differently.
SWIFT: global messaging for cross-border payments
SWIFT (Society for Worldwide Interbank Financial Telecommunication) is best understood as a secure financial messaging network used by banks and other financial institutions to exchange standardised payment messages.
SWIFT itself is not “the bank that moves the money”; it supports the message layer that coordinates cross-border payments between participants (and, in many cases, between multiple correspondent banks). A useful starting point is SWIFT’s “Who we are” page.
What SWIFT usually implies in practice
When a payment is “sent by SWIFT”, the route often involves:
The sending bank,
One or more correspondent/intermediary banks,
The recipient bank.
That extra chain is one reason SWIFT transfers can be:
Harder to predict (timings can vary by route and intermediary checks),
Subject to multiple fees (not all fees are always charged by the sender’s bank).
How SWIFT shows up in Tide
Tide indicates that international payers can send GBP to a Tide account via SWIFT (using the SWIFT details shared in-app). See Tide’s international payments guidance.
For operational expectations on inbound SWIFT flows (including typical timeframes and what Tide currently supports), see Tide’s inbound and outbound SWIFT payments article.
SEPA: euro credit transfers across the SEPA area
SEPA (Single Euro Payments Area) is a European payments integration framework for cashless euro payments. The practical takeaway: SEPA is the structure that makes EUR bank transfers behave more like domestic transfers across participating countries, using harmonised rules.
For a scheme-level description, the European Payments Council’s overview of SEPA Credit Transfer (SCT) is a strong primary reference: SEPA Credit Transfer (EPC).
What SEPA usually implies in practice
SEPA credit transfers are:
EUR-denominated (the scheme is about euro payments),
Built around standardised identifiers (commonly IBAN, sometimes BIC depending on context),
Typically designed to reduce friction compared with ad-hoc cross-border routing.
How SEPA shows up in Tide
Tide states that it supports international payments in EUR via SEPA and provides EUR SEPA details in-app for receiving EUR from SEPA countries. See Tide’s international payments guidance.
ACH: US bank-to-bank transfers (USD) via the ACH Network
ACH (Automated Clearing House) is the main US network for electronic bank payments. It is commonly used for payroll, supplier payments, bill payments and other account-to-account transfers in the US, and it is typically processed as a clearing system rather than a single real-time “wire”.
A primary description is available from the network operator: Nacha’s overview of the ACH Network. For a complementary system-level view, see the Federal Reserve’s FedACH overview.
What ACH usually implies in practice
ACH transfers are often:
Batch processed (many payments are cleared together),
Built for high-volume account-to-account movements,
Operationally distinct from “wire transfers” (which are typically routed via different infrastructure).
How ACH shows up in Tide
Tide states it supports sending USD to the US via ACH. It also states there are no limits on the number of USD payments you can send, and that USD receiving is currently not supported. See Tide’s USD limits page.
On plan-level charging mechanics for USD ACH payments in Tide, see Tide’s ACH fee article.
How to interpret “SWIFT vs SEPA vs ACH” inside Tide
Tide describes its international payment options in a way that maps to “rail + currency + destination”:
EUR transfers: SEPA
USD transfers to the US: ACH
GBP receiving from overseas payers: SWIFT
That framing matters because these rails differ on:
Where they work (geography and participating institutions),
What details are mandatory (identifier formats and bank data),
How fees can appear (provider fees, FX markup, intermediary deductions),
What a “successful” payment looks like operationally (confirmation, tracing, returns).
Summary Table
| Scenario | Outcome | Practical impact |
|---|---|---|
| Supplier in the EU needs paying in EUR | Payment is routed as a SEPA credit transfer (EUR) | Typically clearer EUR-specific routing; reconciliation usually depends on the reference and recipient bank posting practices |
| Contractor in the US needs paying in USD | Payment is routed via ACH (USD to the US) | Processing pattern differs from SWIFT; confirmation and settlement behaviour can feel “non-instant” even after submission |
| Customer overseas pays you in GBP from their bank | Payment can be sent via SWIFT into GBP details | Time and deductions can vary by the sender’s route and intermediaries; statements may show net amounts |
| You initiate USD payments from Tide | Sending is permitted; receiving USD is not currently supported | Expect one-way operational design for USD (send only); inbound USD alternatives may be needed outside the Tide account |
| FX applies during EUR/USD international activity | Tide applies an FX markup (plan-dependent) | The amount debited/credited can differ from the mid-market rate; fee and FX treatment affect margin and reconciliation |
Where charges come from: provider fee, FX pricing, and third-party deductions
International payment “fees” often show up as a combination of:
1) Tide platform fees (plan/allowance-driven)
Tide explains that USD ACH charges depend on plan allowances, with a per-payment fee applied above included transactions, and shows where those fees appear during processing and in transaction details. See Tide’s ACH fee article.
For broader Tide fee mechanics across payment types (where fees can differ between inbound and outbound contexts), see Tide incoming vs outgoing transfer charges.
2) FX markup (currency conversion pricing)
Tide states it applies an FX markup to EUR and USD transactions, and that the markup is reduced on paid plans. This is described in Tide’s international payments guidance.
3) Intermediary and recipient-side deductions (route-driven)
This is most commonly associated with SWIFT-routed payments where correspondent banks may apply fees during processing or at receipt. Even when the sender sees “sent”, the recipient may receive a different net amount depending on the route and fee model used by banks in the chain.
Scenario Table
| Scenario-level | Process-level | Outcome-level |
|---|---|---|
| GBP received from abroad | SWIFT message routes payment through one or more banking relationships before posting | Funds may arrive after variable processing time; net amount can reflect third-party deductions and posting practices |
| EUR sent to a SEPA country | SEPA Credit Transfer scheme rules standardise euro credit transfer processing | Generally more predictable EUR routing compared with non-SEPA cross-border paths; reference quality still affects matching |
| USD sent to the US | ACH network clearing processes account-to-account USD payments | Settlement behaviour differs from “wire”; operational status can be “pending/processing” even after submission |
| Same currency, different rail | Rail determines message formats, bank identifiers, compliance checks and exception handling | “Bank transfer” is not one uniform product; the rail changes tracing, rejects/returns, and fee appearance |
| Missing/incorrect recipient identifiers | Network and receiving bank validations fail at different stages depending on rail | Rejection or return can occur; timing and visibility of failure differs between SEPA/ACH/SWIFT paths |
Compliance checks and payment holds: why international rails can be “slower” operationally
International transfers are more likely to involve:
Extra data validation (bank identifiers, beneficiary details),
Sanctions/AML screening across multiple parties,
Manual exception handling when something doesn’t match.
Even without wrongdoing, additional checks can slow processing or trigger requests for clarification. For Tide-specific operational impact where international activity is held for review, see Tide international payments held for review: triggers and operational impact.
For broader context on how to verify whether an app-based provider is operating as a bank or an e-money institution (which can influence how certain rails/features are delivered), see App business accounts: bank or e-money (check the FCA register).
Tide Business Bank Account
Tide positions international payments around EUR via SEPA, USD to the US via ACH, and GBP receiving via SWIFT, with fees and FX treatment depending on the product rules and plan structure described in Tide’s own support content.
A broader, neutral overview of Tide’s account structure and features is available in our guide to Tide business bank accounts.
Frequently Asked Questions
- SWIFT is best thought of as a global messaging network used to coordinate cross-border payments between participating institutions. It often sits “above” the money movement, which may still require correspondent banking relationships for settlement.
- SEPA and ACH are more like region-specific clearing frameworks: SEPA for euro transfers across the SEPA area, and ACH for USD account-to-account transfers within the US ACH Network. The consequence is that the same instruction (“send money to this account”) behaves differently depending on which framework is doing the work underneath.
Tide describes SWIFT primarily in the context of receiving international GBP payments using SWIFT details shared from the Tide app. That means overseas payers can route GBP to Tide using bank-to-bank rails that rely on SWIFT messaging.
Tide’s help content also sets expectations about what is and isn’t supported for SWIFT flows and how inbound SWIFT behaves operationally. In practice, SWIFT payments can involve multiple banks and checks, which affects timing and transparency compared with domestic transfers.
Tide states that EUR international payments can be made via SEPA, and that EUR SEPA details can be requested in-app to receive EUR from SEPA countries. That framing matters because SEPA is designed around harmonised rules for euro credit transfers, reducing country-by-country variation.
Even with harmonised rules, operational details still matter: beneficiary bank posting times, cut-offs, and reference formats can affect when a payment appears and how easily it can be matched to an invoice or customer record.
Tide states it supports sending USD to the US via ACH, which aligns with ACH being a US account-to-account payment network. ACH is widely used in the US and is operationally distinct from wire-style transfers, especially in how payments clear and settle.
Tide also states that USD receiving is currently not supported. That creates a practical asymmetry: USD functionality may be “send only” in the Tide account context, which affects how US customers or platforms can pay into the business’s banking stack.
SWIFT transfers can pass through correspondent and intermediary banks. Depending on how fees are applied in the chain, deductions may be taken before the payment lands at the recipient bank, meaning the credited amount can be lower than the amount the sender initiated.
This is not unique to Tide; it is a structural feature of many cross-border routes. Operationally, it can create reconciliation issues where invoices were issued for a round amount but the net receipt is different.
They can, but the typical pattern differs. SEPA credit transfers are built on harmonised rules for EUR transfers across SEPA participants, and ACH is a US network designed for bank-to-bank clearing within the ACH framework; both are generally less associated with multi-intermediary correspondent chains than SWIFT.
That said, deductions and additional fees can still appear depending on the banks involved, the service level used, and any currency conversion steps. The key point is that “deduction risk” is usually higher when the payment is routed through broader cross-border correspondent paths.
For SEPA EUR transfers, the core identifier is typically an IBAN, with beneficiary name and a payment reference. For ACH in the US, transfers are commonly built around US bank routing and account identifiers, which are formatted differently from IBAN-based systems.
For SWIFT-routed payments, details can include bank identifiers and account identifiers that enable the message to reach the correct institution and account. Missing or mismatched details don’t always fail instantly; they can create exceptions that surface later as returns, delays, or clarification requests.
Tide states it applies an FX markup to EUR and USD transactions and that this markup is reduced on paid plans. It also describes how ACH fees can depend on plan allowances and how those fees appear during processing and in transaction details.
Beyond Tide’s own fees, international payments can still involve third-party costs (including recipient bank fees or route-related deductions), especially on SWIFT paths. The operational result is that “fee” is often a bundle rather than a single line item.
International activity can increase screening and exception handling because cross-border payments carry higher complexity (additional counterparties, jurisdictions, identifiers, and compliance checks). A hold can affect timing even where the payment details are correct.
From an operations standpoint, the main impact is cashflow predictability: outgoing payments may not leave when expected, or inbound funds may be delayed in posting. Tide-specific triggers and operational impacts are covered in the linked Tide-focused guide.
With SEPA, a wrong IBAN or mismatched beneficiary details can result in rejection or a return, depending on where the validation fails. With ACH, incorrect routing/account identifiers can similarly fail validation or be returned after processing attempts.
With SWIFT, errors can create longer exception chains because multiple parties may need to resolve the mismatch. The practical effect is that the time between “initiated” and “final failure/return” can be longer, and the visibility into what happened may depend on how much information each bank in the chain provides.
“SWIFT vs SEPA vs ACH” is really a question about layers. SWIFT is primarily a messaging and identification layer that helps institutions communicate payment instructions securely; SEPA and ACH are scheme/network layers that define how clearing happens within a region and currency context.
Most confusion comes from user interfaces flattening these layers into one button called “bank transfer”. Operationally, the rail determines the fields that must be correct, the parties that can introduce fees or delays, and how exceptions are handled.
Treating “international transfer” as a single product hides the real driver of outcomes: how many institutions are involved, which scheme rules apply, and whether FX conversion is happening in-line.
Sources & References
Related Content
