What Is SWIFT? How the Swift Network Works, How to Connect and What Financial Institutions Need to Know

If you have ever sent an international bank transfer, there is a good chance Swift was involved somewhere along the way.

But one of the most common misconceptions about Swift is also the most fundamental one:

Swift does not move money.

Swift is a secure financial messaging network. It allows banks, financial institutions and other participants to exchange standardised instructions about financial transactions. The actual movement of funds happens through banks, accounts, correspondent relationships and payment or settlement infrastructure.

That distinction matters, because connecting to Swift is not simply a matter of sending an API request. Behind every successful payment sits a much larger infrastructure of messaging standards, security, routing, tracking, exceptions and operational processes.

This guide explains what Swift actually is, how Swift payments work, what a BIC is, how ISO 20022 has changed the network, how financial institutions can connect to Swift, and what they need to operate that connection in practice.

What is Swift?

Swift is a global cooperative that provides secure financial messaging infrastructure to banks, financial institutions, corporates and other organisations.

Its network connects more than 11,500 institutions across more than 200 countries and territories, making it one of the core pieces of infrastructure behind international finance.

At a practical level, Swift provides three things.

1. A secure network

Financial institutions need a reliable way to communicate with each other across countries, currencies and banking systems.

Swift provides the network through which those messages can be exchanged securely and in a standardised way.

If Bank A in Germany needs to instruct Bank B in the United States about a payment, Swift can provide the messaging infrastructure used to send that instruction.

2. Common financial messaging standards

A secure pipe is not enough.

Both institutions also need to understand exactly what a message means.

Who is paying? Who is receiving? Which institutions are involved? What is the amount? What currency is being used? What is the purpose of the payment? What should happen if something goes wrong?

Swift provides common standards and market practices that allow institutions around the world to exchange this information consistently.

3. Services around the payment

Modern Swift connectivity goes beyond simply sending financial messages.

The ecosystem also includes services for payment tracking, reference data, payment pre-validation and other areas around the transaction lifecycle.

That becomes important once payments move from a simple demo into real production.

Because sending a payment instruction is usually the easy part.

Handling everything that can happen afterwards is where things get more complicated.

Is Swift a payment system?

No.

This distinction is important.

Swift is a financial messaging network, not a payment or settlement system.

It communicates the instructions that allow financial institutions to execute transactions. Swift itself does not hold customer accounts or transfer the underlying money. Swift describes its role as providing secure messaging that helps financial institutions send payment instructions; the actual transfer of funds takes place through financial institutions and other financial infrastructure.

A simple analogy is email.

Email carries information from one organisation to another, but it does not perform the action described in the email.

Swift does something similar for financial institutions, except the messages are highly structured, authenticated and governed by financial-industry standards.

In international payments, those instructions may ultimately result in money moving through correspondent bank accounts or other settlement arrangements.

How does a Swift payment work?

There is no single path that every Swift payment follows, but a simplified cross-border payment can look like this.

Step 1: The customer initiates the payment

A customer asks their bank or payment provider to send money to a beneficiary in another country.

The payment provider collects the necessary information, such as:

• payer details;
• beneficiary details;
• beneficiary bank;
• amount;
• currency;
• payment reference;
• routing information.

Step 2: The sending institution creates the financial message

The sending institution converts that payment instruction into the appropriate Swift message.

Today, ISO 20022 is the required standard for cross-border payment instructions on Swift, providing richer and more structured data than the legacy MT payment formats.

The message has to follow not only the technical format but also the relevant market-practice rules.

A message can be technically well formed and still fail because the information inside it is incomplete or unsuitable for the route being used.

Step 3: The message travels through Swift

Swift securely delivers the instruction to the relevant financial institution.

Sometimes the sending bank has a direct correspondent relationship with the beneficiary bank.

Sometimes one or more intermediary banks are involved.

Swift reports that 86% of payments on its network are either direct or involve only one intermediary.

Step 4: The money is settled

This happens outside Swift itself.

For many international payments, settlement relies on correspondent banking relationships.

Banks hold accounts with one another – commonly described as nostro and vostro accounts – and use those relationships to settle payments across currencies and jurisdictions.

The route of the payment instruction and the route of the actual funding do not always have to be identical.

That is one reason cross-border payment operations can become substantially more complex than the original payment message suggests.

Step 5: The payment is tracked and confirmed

Payments carried over Swift use a Unique End-to-end Transaction Reference (UETR).

Think of the UETR as a tracking number for the payment. It follows the transaction through the chain and allows institutions to identify and track the same payment consistently.

Swift's tracking capabilities allow institutions to see status changes and receive confirmation when a payment has been credited or rejected.

Swift currently reports that 90% of cross-border payments reach the beneficiary bank in under an hour. That does not necessarily mean the beneficiary has received the funds within an hour: compliance checks, local regulation and processing at the final bank can still delay the final credit.

Why is Swift connectivity more complicated than sending a payment message?

A basic credit transfer is only one part of the payment lifecycle.

Real production systems also need to understand what happens when the payment does not follow the happy path.

For example:

• What if a payment is rejected?
• What if funds need to be returned?
• What if the sender asks for a cancellation?
• What if an intermediary bank puts the payment on hold?
• What if the funding arrives separately from the payment instruction?
• What if beneficiary information is incorrect?
• What if a correspondent uses different routing information?
• What if a payment has arrived but remains under compliance review?

A cancellation is a good example.

Sending a cancellation request does not simply reverse a payment. The receiving institution may already have processed or credited the payment. It needs to determine whether the cancellation can be honoured, respond correctly and, where appropriate, return funds using the correct references and reason codes.

That is why operating Swift is not just a connectivity problem.

It is also a payments-domain and operations problem.

Correspondent banking and RMA: being connected does not mean you can reach everyone

Another common misunderstanding is that joining Swift automatically gives an institution the ability to transact with every other Swift participant.

It does not.

Cross-border banking still depends heavily on commercial relationships between financial institutions.

One important part of that model is RMA – Relationship Management Application.

RMA allows institutions to control which counterparties are authorised to send them certain Swift messages. Swift describes it as a mandated authorisation mechanism for relevant financial messaging that helps institutions prevent unwanted traffic.

So there are two different questions:

Can we technically reach the Swift network?

and:

Do we have the relationships and authorisations required to exchange the messages we need?

Those are not the same thing.

A financial institution may also need correspondent banking relationships, clearing identifiers or national routing codes depending on where and how the payment is being sent.

Connectivity gives you the infrastructure.

It does not create the underlying banking relationships.

What is a SWIFT code or BIC?

People often search for a SWIFT code, but the formal identifier used in this context is the BIC – Business Identifier Code.

A BIC is an international ISO 9362 identifier used for routing business transactions and identifying financial and non-financial institutions. Swift acts as the registration authority for BICs.

A standard BIC contains eight characters, with an optional three-character branch identifier.

One important detail is often overlooked:

Having a BIC does not automatically mean an institution is connected to Swift.

Swift distinguishes between connected and non-connected BICs. A BIC can exist purely for identification and reference purposes without giving the organisation access to the Swift network.

What is Swift gpi?

Swift gpi – global payments innovation – introduced much greater visibility into the cross-border payment journey.

A central part of this is the UETR attached to payment instructions.

Instead of each institution relying on separate internal references, participants can use the same identifier to follow the payment through its lifecycle.

That can help institutions answer one of the most frustrating questions in cross-border payments:

Where is the payment right now?

Tracking also matters operationally.

It can help teams distinguish between a payment that:

• has reached an intermediary;
• is still being processed;
• has been rejected;
• is on hold;
• has reached the beneficiary bank;
• has been credited.

Universal confirmations also require institutions to report payment outcomes back into the tracking process.

For customers, this means greater transparency.

For operations teams, it means fewer investigations based purely on emails, calls and disconnected reference numbers.

Swift and ISO 20022: what changed?

Swift's cross-border payments infrastructure has gone through one of its biggest messaging changes in decades.

On 22 November 2025, the coexistence period between legacy MT payment messages and ISO 20022 for cross-border payments and reporting ended.

ISO 20022 is now required for cross-border payment instructions on Swift.

Why does that matter?

ISO 20022 allows considerably richer and more structured payment data.

That can improve:

• automation;
• reconciliation;
• compliance screening;
• straight-through processing;
• payment transparency;
• interoperability between systems.

But richer data also means institutions need better underlying data.

That becomes especially important with the next major change.

November 2026: unstructured postal addresses are being removed

From 14 November 2026, fully unstructured postal addresses will no longer be supported for CBPR+ payment messages. Institutions will need to use structured or hybrid address formats, with town and country provided in dedicated fields at minimum.

This sounds like a messaging change.

For many financial institutions, it is actually a core data problem.

If customer addresses have historically been stored as one free-text field, changing the outgoing Swift message is not enough. The institution may need to change how customer data is captured, stored and maintained across its systems.

That is a useful example of why Swift connectivity cannot be treated as a one-time integration.

The network and its standards continue to evolve after go-live.

What do you need to connect to Swift?

There is no universal onboarding path for every organisation. Eligibility, products and responsibilities depend on the type of institution and the connectivity model.

But a practical Swift connectivity project usually involves several layers.

1. Eligibility and onboarding

First, the organisation needs to determine whether it is eligible for the Swift services it intends to use and complete the appropriate onboarding process.

A BIC may form part of the setup, but a BIC alone does not grant network access.

2. A connectivity model

The institution needs a technical route into Swift.

That can involve Swift-hosted infrastructure, infrastructure operated by the institution, a service provider or an embedded-connectivity model.

The right option depends on factors such as:

• message volumes;
• internal technical resources;
• security model;
• operational capacity;
• required Swift services;
• time to market;
• appetite for running infrastructure internally.

3. Security

Security is a fundamental part of Swift participation.

Swift's Customer Security Programme (CSP) establishes mandatory security controls for Swift users. Institutions need to understand which controls apply to their connectivity architecture, implement them and complete the required security attestation process.

The exact security footprint differs depending on how the organisation connects.

That is one reason the connectivity model matters.

4. Counterparty relationships

Technical access to the network does not replace the institution's correspondent relationships or required RMA authorisations.

Those commercial and operational relationships still need to exist.

5. Message implementation

Your systems need to produce and consume the relevant message types correctly.

That includes more than outgoing credit transfers.

Depending on the use case, the institution may need to handle:

• payment instructions;
• status messages;
• returns;
• cancellation requests;
• confirmations;
• statements;
• notifications;
• tracking information.

6. Exception handling and reconciliation

This is where production reality starts.

A serious Swift implementation needs clear processes for:

• rejected payments;
• missing information;
• returns;
• cancellations;
• reconciliation;
• payment investigations;
• pending payments;
• tracking;
• compliance review.

A successful test payment proves that the connection works.

It does not prove that the operating model is ready.

7. Ongoing standards and operations

Going live is not the end of the Swift project.

Standards releases continue. Security controls evolve. Message requirements change. Counterparties behave differently. Operational teams need monitoring, escalation and support processes.

Swift connectivity is therefore better understood as an ongoing operating capability, not a one-off integration.

What are the main ways to connect to Swift?

Broadly, financial institutions can take several approaches.

Build and operate your own Swift environment

Traditionally, larger institutions have operated significant parts of their own Swift infrastructure.

This provides control, but also means taking responsibility for the technology, security, maintenance, specialist expertise and operations around the connection.

For institutions with the scale and internal capabilities to support it, that can make sense.

For others, the infrastructure may become a substantial project of its own.

Use Swift-hosted cloud connectivity

Swift also offers cloud-based connectivity such as Alliance Cloud.

Alliance Cloud is hosted and managed by Swift and is designed to reduce local infrastructure requirements while providing messaging and API connectivity to Swift services.

This can significantly reduce the technical footprint compared with traditional locally hosted infrastructure.

The financial institution still needs to integrate the service into its own payment systems and build the processes around the messages it sends and receives.

Use a Swift service bureau

A Swift service bureau provides shared or indirect connectivity to the network.

This can reduce the amount of Swift infrastructure an institution needs to operate internally.

However, connectivity and payment-domain logic are two different problems.

An institution still needs to understand how payment messages, returns, exceptions, reconciliation and ongoing standards changes fit into its own systems.

Use embedded Swift connectivity through Business Connect

A newer model is Swift Business Connect.

Business Connect allows technology providers to embed Swift connectivity into their applications or SaaS platforms and offer that connectivity as part of a broader product.

Swift describes the model as providing simpler onboarding and a lower maintenance footprint for end customers, including the ability to consume connectivity without managing elements such as Swift training, USB tokens or certificates themselves.

For a financial institution, this shifts the architecture.

Instead of treating Swift as a separate technology estate that needs to be integrated and operated independently, connectivity can become part of the payment platform the institution already uses.

There is, however, a trade-off.

You are putting more responsibility into the hands of the provider.

That means the right question is not simply:

“Does the provider connect to Swift?”

It is:

“What does the provider actually operate behind that connection?”

Does it handle only transport?

Or does it also understand message construction, inbound flows, tracking, standards changes, exceptions and reconciliation?

That difference matters in production.

Who actually needs Swift connectivity?

Not every financial company needs its own Swift setup.

It becomes particularly relevant where an organisation needs to communicate directly with financial institutions across multiple countries, currencies or correspondent networks.

Typical use cases include:

Banks

Banks are the most obvious Swift users, particularly where they operate cross-border payments, correspondent banking, treasury, securities or other international financial services.

EMIs and payment institutions

For licensed payment institutions and electronic money institutions, Swift may become relevant as the business expands beyond domestic or SEPA-only payment flows.

For example, an institution may need:

• international payments outside SEPA;
• additional currencies;
• correspondent banking connectivity;
• direct communication with partner banks;
• global payment tracking.

The right setup depends on the institution's licence, banking relationships and operating model.

Large corporates

Large multinational companies may also use Swift to standardise communication with multiple banking partners.

For a treasury team dealing with many banks across markets, a common global communication layer can reduce fragmentation.

Securities, treasury and trade-finance participants

Swift is not limited to customer payments.

Its network and standards are also used across securities, treasury, trade finance and other financial workflows.

What is the difference between Swift and SEPA?

Swift and SEPA are often mentioned together, but they solve different problems.

For a European PSP, the two can complement each other rather than compete.

SEPA may handle euro payments within Europe, while Swift becomes relevant for broader international and multi-currency connectivity.

If you are evaluating SEPA infrastructure specifically, see our guide to direct SEPA access for PSPs.

Where does Inventi fit into Swift connectivity?

Inventi has joined the Swift Business Connect programme and is the first Business Connect provider in the Baltics. Swift also lists Inventi in its Platform Partners Directory.

What matters practically is what sits around the connection.

Inventi's Payments Platform is designed to manage payment infrastructure across multiple systems, including direct SEPA connectivity, TARGET Services and Swift.

On the Swift side, that includes the infrastructure around connectivity as well as payment-message processing, incoming and outgoing flows, tracking, exceptions and ongoing standards changes.

The aim is not to turn Swift into “just another API”.

The API is only the interface.

The value is in handling the payment infrastructure behind it.

For a bank, EMI or payment institution, that can mean accessing Swift through a managed platform rather than building another standalone infrastructure stack alongside the rest of its payment setup.

You can read more about Inventi becoming the first Swift Business Connect provider in the Baltics.

What should a financial institution ask before choosing a Swift connectivity model?

The technology is only one part of the decision.

Before choosing how to connect, it is worth answering a broader set of questions.

What do we actually need Swift for?
Customer payments, correspondent banking, treasury, securities or something else?

Which counterparties do we need to reach?
Connectivity does not automatically create correspondent relationships.

Which currencies and markets are part of the roadmap?

What message types do we need to send and receive?

Who handles returns, cancellations and payment investigations?

Who owns payment tracking and reconciliation?

How much Swift-specific infrastructure do we want to operate ourselves?

What security responsibilities remain with us under the chosen connectivity model?

Are our systems ready for current ISO 20022 requirements?

Is our customer data ready for structured-address requirements in November 2026?

Who handles future Swift standards releases?

Does the same infrastructure need to support other payment systems as well?

The cheapest or fastest connection is not necessarily the best long-term option.

The better question is:

Which operating model fits where the institution is going?

FAQ: Swift payments and connectivity

What is Swift in banking?

Swift is a secure global financial messaging network used by banks, financial institutions and other organisations to exchange standardised information about financial transactions.

Swift does not itself hold or transfer customer funds.

Does Swift transfer money?

No.

Swift transmits financial messages and payment instructions. The actual movement and settlement of money takes place through banks, accounts and other payment or settlement infrastructure.

What is a SWIFT code?

The term “SWIFT code” commonly refers to a BIC – Business Identifier Code.

A BIC identifies an organisation for financial messaging and transaction-routing purposes.

However, not every BIC is connected to the Swift network.

Is a BIC the same as a SWIFT code?

In everyday banking usage, the terms are often used interchangeably.

Technically, BIC is the ISO-standard identifier. Swift is the registration authority for BICs.

How long does a Swift payment take?

Swift reports that around 90% of cross-border payments sent over its network reach the beneficiary bank within an hour.

The final credit to the beneficiary can take longer because of compliance checks, local regulation, processing at the receiving bank or other factors.

What is Swift gpi?

Swift gpi provides end-to-end payment tracking using a Unique End-to-end Transaction Reference, or UETR.

It allows participating institutions to follow a payment through the chain and receive status information and confirmation of the outcome.

What is ISO 20022 in Swift?

ISO 20022 is the global structured financial messaging standard now used for cross-border payment instructions on Swift.

The coexistence period with legacy MT payment messaging ended on 22 November 2025.

Can an EMI or payment institution connect to Swift?

Potentially, yes.

The appropriate route depends on the institution's eligibility, licence, banking relationships, use case and required Swift services.

Connectivity can be established using different models, including Swift-hosted infrastructure and embedded connectivity through providers.

Can you connect to Swift through an API?

Yes.

Modern Swift connectivity includes API-based options. Alliance Cloud provides API connectivity, while Business Connect allows providers to embed Swift connectivity into SaaS and application offerings.

But connecting the API is only part of the project. The institution still needs an operating model for messages, tracking, exceptions, security, reconciliation and counterparties.

Is Swift the same as SEPA?

No.

SEPA is focused on standardised euro payments across the Single Euro Payments Area.

Swift is a global financial messaging network used across currencies, markets and different types of financial transactions.

Financial institutions can use both as part of the same payment infrastructure.

The bottom line

The simplest description of Swift is also the most accurate:

Swift is the communication infrastructure behind a large part of global finance.

It does not move the money.

It makes it possible for financial institutions to exchange the trusted, structured instructions needed for that money to move.

And that is why connecting to Swift is about much more than getting onto a network.

There is connectivity, but there are also BICs, counterparties, RMA relationships, ISO 20022, tracking, security, message lifecycle management, exceptions, reconciliation and continuous standards changes.

The connection is only the visible part.

The real work is making everything behind it operate reliably in production.