When an enterprise client in Germany asks for your banking details to wire a payment, they will ask for your SWIFT code and IBAN. When you pay a contractor in the UAE, they will send you the same. These two identifiers are not interchangeable terms for the same thing — they solve different problems in the same payment chain.

This guide explains what each identifier does, how they work together, where the system breaks down, and how international bank transfers compare with the way most digital sellers actually collect revenue today.

For context on how a Merchant of Record simplifies cross-border collection, see What Is a Merchant of Record?

What is the SWIFT network?

SWIFT stands for the Society for Worldwide Interbank Financial Telecommunication. It is a messaging network, not a payment system. SWIFT does not move money. It sends standardized messages between financial institutions that instruct them to move money.

When a business in Singapore initiates a wire transfer to a supplier in France, the Singapore bank sends a SWIFT message to the French bank — or to an intermediary bank that has a relationship with both. That message contains the transfer instructions: amount, currency, sender details, and recipient account information. The French bank, after receiving and validating the message, credits the recipient's account.

For international wire transfers outside of regional payment systems, SWIFT is the primary infrastructure.

What is a SWIFT code?

A SWIFT code, also called a BIC (Bank Identifier Code), is the unique identifier for a specific financial institution on the SWIFT network. It tells the sending bank exactly which institution should receive the transfer instruction.

A SWIFT code is 8 or 11 characters:

• Characters 1–4: Bank code (letters only)
• Characters 5–6: Country code (ISO 3166-1 alpha-2)
• Characters 7–8: Location code (letters or digits)
• Characters 9–11 (optional): Branch code. When omitted or replaced with "XXX," the code refers to the bank's head office.

An 8-character code identifies the bank and country; an 11-character code identifies a specific branch. When sending an international wire, either format typically works, with the transfer routing to the head office if no branch code is provided.

For example, a SWIFT code structured as HSBCHKHH identifies HSBC as the bank, Hong Kong as the country, and HH as the location. This is the format a client, contractor, or processor will request when initiating a transfer to your account.

What is an IBAN?

An IBAN (International Bank Account Number) is a standardized format for identifying a specific bank account across borders. It does not replace your domestic account number. Instead, it wraps your existing account number with country and bank routing information that can be validated automatically.

An IBAN is up to 34 characters and follows a consistent structure:

• Characters 1–2: Country code (ISO 3166-1 alpha-2)
• Characters 3–4: Check digits, calculated to verify the IBAN is valid
• Characters 5 onward: BBAN (Basic Bank Account Number), which encodes the domestic bank and account identifiers in a country-specific format

The BBAN portion varies in length and structure by country. A UK IBAN is 22 characters; a German IBAN is 22 characters; a French IBAN is 27 characters. The check digits in positions 3 and 4 let any system verify the IBAN is correctly formed before attempting a transfer, reducing errors.

How SWIFT codes and IBANs work together

SWIFT codes and IBANs operate at different levels of the same transfer. The SWIFT code identifies the institution; the IBAN identifies the account within that institution. A transfer instruction needs both: which bank to route to, and which account to credit once the transfer arrives.

For a transfer from a US company to a supplier in Germany:

1. The sender provides the German supplier's IBAN and the bank's SWIFT code.
2. The US bank sends a SWIFT message to the German bank — directly, or via one or more correspondent banks.
3. The German bank validates the IBAN, identifies the correct account, and credits the funds.

Without the SWIFT code, the transfer cannot reach the correct bank. Without the IBAN, the bank cannot identify the correct account. In countries that do not use IBAN, the domestic account number and routing identifier replace the IBAN in this sequence.

The practical limitations of SWIFT

SWIFT works for most international wire transfers. It also has limitations that become operationally significant when you receive or send multiple international payments each month.

Transfer fees are layered and opaque. A SWIFT transfer does not always move directly from the sending bank to the receiving bank. When the two banks have no direct relationship, the transfer routes through one or more correspondent banks. Each correspondent charges a handling fee, deducted from the transfer amount in transit. By the time the funds arrive, they may be less than the amount sent, with no advance disclosure of how much was deducted. A transfer of USD 5,000 may arrive as USD 4,945 — and for recurring revenue collection, that unpredictability accumulates.

Transfers take one to five business days. SWIFT transfers are not instant. Depending on the currency corridor, the number of correspondent banks involved, and whether the transfer crosses a time-zone boundary, completion can take one to five business days. A transfer initiated on a Friday in one time zone may not process until the following week in another.

Currency conversion happens at the correspondent's rate. If a transfer involves a currency conversion, the rate is typically applied by the correspondent bank handling the conversion leg — not the mid-market rate. It includes a spread that varies by institution and is not disclosed in advance. This is the same FX opacity that appears in many payment settlements: the conversion happens, the spread is embedded without a visible line item, and the net amount received is lower than the mid-market equivalent.

Not all corridors are equal. Transfers into or out of markets with currency controls or limited correspondent banking relationships face additional friction — longer processing times, higher fees, or settlement in a different currency than intended.

Regional systems that operate alongside SWIFT

For transfers within specific regions, dedicated payment rails often offer faster and cheaper alternatives to SWIFT.

These systems operate in parallel to SWIFT, not as replacements for it. SWIFT remains the primary infrastructure for transfers that cross into or out of a non-SEPA country. SEPA handles payments that both originate and terminate within the SEPA zone — such as a German company paying a French supplier — where SWIFT is not involved.

How developers actually get paid with Waffo Pancake

Here is the honest part, and it matters: Waffo Pancake does not process SWIFT, IBAN, or bank transfers from your buyers. It is not a wire rail. If you are selling software, an API, or an AI product to a global audience, the bank-transfer infrastructure above is mostly the wrong tool — it is slow, opaque on fees, and built for occasional high-value transactions rather than recurring digital revenue.

Pancake is a card-based Merchant of Record. The flow is deliberately simple:

1. A customer checks out and pays with Visa or Mastercard, Apple Pay, or Google Pay — the only methods Pancake accepts.
2. Pancake processes that card payment as the legal seller of record across 173 countries, calculating and collecting the correct local tax at checkout.
3. Pancake remits that tax to the authorities and absorbs chargeback and fraud liability.
4. Pancake settles your net revenue and pays you out on its own schedule.

So you never hand a buyer your SWIFT code or IBAN, and you never reconcile incoming wires. The only place a bank account enters the picture is on the payout side, when Pancake pays you.

This is the structural advantage of a card-based MoR over collecting by wire: a customer's card authorization is near-instant and Pancake handles the cross-border collection, currency, and tax, so you are not chasing correspondent-bank deductions across dozens of markets. For a fuller picture of how cards, wallets, and local methods compare for online businesses, see the Global Online Payments Guide.

What Pancake charges

Pancake publishes every fee — no monthly fees and no setup costs.

The payout fee is 1% of the amount, minimum $10.00, and refunds cost $1.00 each. Because Pancake is the Merchant of Record, you are not managing FX spreads on collection or registering for foreign tax in covered markets — that work sits with the platform.

Why trust Waffo Pancake to collect for you

Waffo Pancake is built on Waffo's payment platform. Waffo is PCI DSS v4.0 Level 1 certified, backed by HSBC, and built by a founding team from Alipay and Ant Group, with over $30M raised. For context, the industry first-attempt subscription renewal rate averages roughly 57% (Cashfree, 2024); across the Waffo platform, merchants have recorded up to a 45% improvement in payment success rate and recovered about 18% of previously failed orders (based on Waffo platform data). The brand promise is direct: "We're the seller. You focus on building."

When SWIFT and IBAN still matter to you

Even with a card-based MoR collecting your sales, bank-transfer identifiers can still appear in two situations:

• Receiving large enterprise B2B payments outside your storefront. Some enterprise buyers in Europe and the Middle East prefer to pay by wire on negotiated contracts. In those cases you provide your SWIFT code and IBAN directly, and the limitations above apply — correspondent fees and unpredictable timing.
• Paying contractors and vendors internationally. Distributed teams across multiple countries are paid via the same SWIFT/IBAN rails, so understanding the format and fee structure helps you set expectations on what lands versus what is sent.

For your core digital revenue, though, you do not need to operate this plumbing yourself. A Merchant of Record collects payment in the customer's currency and settles net revenue to you, so you are not reconciling individual wires across markets or managing correspondent relationships for collection.

The bottom line

SWIFT codes and IBANs are the plumbing behind most international bank transfers: the SWIFT code routes to the bank, the IBAN identifies the account, and regional rails like SEPA fill the gaps within their zones. Their limitations — opaque correspondent fees, variable timing, and embedded FX spreads — are structural, because the correspondent banking model was built for occasional high-value transfers, not recurring digital revenue.

That is why most software and AI businesses do not collect revenue by wire at all. They collect by card and let a Merchant of Record handle cross-border payment, tax, and settlement. Waffo Pancake is that card-based MoR — Visa/Mastercard, Apple Pay, and Google Pay in, a clean net payout to you out — not a SWIFT or IBAN rail.

This article is general information, not tax, legal, or financial advice. Tax rates and rules change; verify current requirements with the relevant authority or a qualified advisor before acting.

Related articles

Payments

Why Payments Fail: A Field Guide to Declines and Recovery (2026)

Payments

ACH Payments 101: Lower Fees for B2B Transactions

Payments

How Global Online Payments Work: A 2026 Guide for Software Businesses