SWIFT / Learning brief
SWIFTNet and connecting to Swift
Your notes
In simple terms / 01
What this means in plain language
SWIFTNet is the secure private network that carries every Swift service. This article explains how institutions connect to it and maps the four messaging services that ride on top.
Swift is a cooperative that runs a shared messaging network for banks. The network itself is SWIFTNet, a private and secure internet-protocol backbone that no one reaches over the public internet. To join, an institution needs a secure entry point: a small piece of software and hardware called the SWIFTNet Link handles authentication and encryption so each message is provably from the sender and unaltered. An institution can connect in three broad ways. It can run its own infrastructure on-site (direct connectivity), it can outsource the plumbing to a service bureau that hosts the connection for several members, or it can use a cloud arrangement where Swift or a partner runs the components. Four messaging services travel across SWIFTNet: FIN, InterAct, FileAct, and Browse. Understanding which service carries which traffic is the first step to understanding how Swift actually moves instructions between institutions.
Complete lesson / 02
Understand the full idea, step by step
Every network you use daily rides on some physical path — a fibre, a cell tower, a cable under the sea. Financial messaging is no different. Under the post office you met last lesson sits a private network with unusually strict security, called SWIFTNet. Understanding it answers a practical question a new bank always asks: "What do we actually have to install to send our first message?"
SWIFTNet — the secure private IP network beneath every SWIFT service
SWIFTNet is a private IP (Internet Protocol) network. Institutions do not reach it across the public internet; they connect through dedicated, managed links. Its design goal is trust: the receiver must know exactly which institution sent a message, and that no byte changed in transit. It carries every SWIFT messaging service on top — the services are the traffic; SWIFTNet is the road.
How the network earns trust
Two shared controls make SWIFTNet trustworthy for thousands of members at once. First, a component called the SWIFTNet Link (SNL) runs at each connected member; it applies the security services — authenticating the sender through a PKI (public-key infrastructure), signing messages, and encrypting the connection. Because every member uses the same controls, any two can exchange traffic without negotiating security bilaterally. Second, a common addressing scheme built on the BIC (Business Identifier Code) — the eight- or eleven-character code identifying each institution — so messages are routed to exactly the right member.
| What the bank runs | Suits | |
|---|---|---|
| Direct / on-premises | Its own connectivity components, interface, and SWIFTNet Link, under its own staff | High volumes; wanting maximum control, accepting the cost and 24/7 operations |
| Service bureau | Little — a SWIFT-accredited third party hosts connectivity for several members | Lower operational burden; a professionally run connection without building it in-house |
| Cloud | Little — SWIFT or a partner runs the components as a managed service reached over secure channels | Firms wanting a light on-site footprint with the provider maintaining the infrastructure |
What every model still needs
- Secure link
- A managed path into SWIFTNet — never the open internet
- Sender authentication
- PKI-based signing via the SWIFTNet Link
- Addressing
- A BIC to be reached and to route to others
- The choice driver
- Message volume, in-house skills, budget, and how much control the bank wants to keep
You may be wondering whether a bank has to pick exactly one of these three.
No — many blend them. A firm might keep a direct path for its core flows and a bureau-managed connection as a resilient backup, or use a hosted model for most traffic while retaining some in-house capability. The models are options along a spectrum of control-versus-burden, not a single forced choice. What stays constant is the security: whichever route, the SWIFTNet Link authenticates the sender and the traffic never crosses the public internet unprotected.
WHAT IF — The connectivity layer is degraded — a link is down or the SWIFTNet Link is unavailable
What happens: The bank cannot send or receive on that path; messages queue at the sending side rather than being lost. Because SWIFT is store-and-forward, a message already accepted by the network is still held for delivery once the receiver's connection returns.
How it is handled: Operations teams rely on the resilience they designed in — a backup link, a bureau path, or a secondary site — and monitor delivery status closely. This is precisely why connectivity is treated as operational security: an outage is a continuity event, not a wiring nuisance.
FOR NOW, REMEMBER
- SWIFTNet is the secure private IP network that carries every SWIFT service; it is reached over managed links, not the public internet.
- The SWIFTNet Link (SNL) at each member applies PKI authentication, signing, and encryption; BIC addressing routes the traffic.
- Banks connect in three broad ways: direct/on-premises, via a service bureau, or via cloud — chosen on volume, control, and cost.
- The models can be blended for resilience, and connectivity is treated as an operational-security concern.
TRY IT YOURSELF
A small bank with modest message volumes wants to be on SWIFT without hiring a 24/7 infrastructure team or buying and upgrading its own connectivity hardware. Which route fits best?
The network is the road. But something has to help a bank compose, validate, authorise, and store its messages before they hit that road — SWIFT's Alliance interfaces. That is next.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
SWIFTNet is a private, secure IP network, not the public internet, and every Swift service rides on it.
- 02
The SWIFTNet Link provides authentication and encryption so each message is verifiably from its sender and unchanged.
- 03
Institutions connect directly, through a service bureau, or via cloud, and four services (FIN, InterAct, FileAct, Browse) carry the traffic.
Practical use cases / 04
Where you would use this
A payments operations team decides whether to run connectivity on-site or outsource it to a service bureau.
A network engineer configures the SWIFTNet Link so that messages are authenticated and encrypted end to end.
A project manager maps which messaging service (FIN, InterAct, FileAct, or Browse) each business flow will use.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional mid-sized bank, Meridian Trust, sends 8,000 payment instructions per day and receives 2,500 large statement files per month. It compares running its own SWIFTNet Link on-site against a service bureau that charges a fixed EUR 4,500.00 monthly fee plus EUR 0.02 per message. At 8,000 messages per day across 22 business days that is 176,000 messages, or EUR 3,520.00 in usage, giving EUR 8,020.00 per month through the bureau. The bank weighs that predictable cost against the staff and hardware needed to keep an in-house connection running around the clock.
Evidence & review / 07
Evidence & review
SWIFTNet connectivity at a conceptual level; exact product names, tiers, and accreditation rules evolve and vary by jurisdiction.
What this brief simplifies: Groups real connectivity options into three broad models and omits bandwidth tiers, accreditation specifics, and detailed resilience design.
Sources for this brief3
- Market practice
Swift products and services ↗ — Swift · SWIFTNet, SWIFTNet Link, connectivity models (direct, service bureau, cloud)
Used for the public overview of product details documented behind swift.com.
- Official requirement
Customer Security Programme (CSP) and Customer Security Controls Framework ↗ — Swift · Secure connectivity and operational-security expectations
The full Customer Security Controls Framework and detailed control descriptions sit behind a swift.com login.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.