Payments Training Hub
SWIFTNet: private PAYMENT OPERATIONS STARTED LIVE 01 SWIFTNet - closed network that connects member ACTIVE 02 Main connection components - Alliance Access QUEUED 03 Security on SWIFTNet rests on public - infrastructure, message QUEUED 04 Control failure disconnection - bank that fails those controls can be QUEUED 05 Store and forward - design is essential for a global network QUEUED 06 Banks appear on SWIFTNet as distinct - Both banks appear on SWIFTNet as QUEUED SWIFTNet is a private, closed network that connects member institutions to SWIFT services. Step 1 of 6 SWIFTNet: private STARTED SWIFTNet closed network that connects member ACTIVE Main connection components Alliance Access QUEUED Security on SWIFTNet rests on public infrastructure, message authentication, QUEUED Control failure disconnection bank that fails those controls can be QUEUED Store and forward design is essential for a global network QUEUED Banks appear on SWIFTNet as distinct Both banks appear on SWIFTNet as distinct QUEUED SWIFTNet is a private, closed network that connects member institutions to SWIFT services.
Main connection components PAYMENT OPERATIONS IN PROGRESS LIVE 01 SWIFTNet - closed network that connects member DONE 02 Main connection components - Alliance Access ACTIVE 03 Security on SWIFTNet rests on public - infrastructure, message QUEUED 04 Control failure disconnection - bank that fails those controls can be QUEUED 05 Store and forward - design is essential for a global network QUEUED 06 Banks appear on SWIFTNet as distinct - Both banks appear on SWIFTNet as QUEUED The main connection components are Alliance Access, Alliance Gateway, and the SWIFTNet Link. Step 2 of 6 Main connection components IN PROGRESS SWIFTNet closed network that connects member DONE Main connection components Alliance Access ACTIVE Security on SWIFTNet rests on public infrastructure, message authentication, QUEUED Control failure disconnection bank that fails those controls can be QUEUED Store and forward design is essential for a global network QUEUED Banks appear on SWIFTNet as distinct Both banks appear on SWIFTNet as distinct QUEUED The main connection components are Alliance Access, Alliance Gateway, and the SWIFTNet Link.
Security on SWIFTNet rests on public key PAYMENT OPERATIONS IN PROGRESS LIVE 01 SWIFTNet - closed network that connects member DONE 02 Main connection components - Alliance Access DONE 03 Security on SWIFTNet rests on public - infrastructure, message ACTIVE 04 Control failure disconnection - bank that fails those controls can be QUEUED 05 Store and forward - design is essential for a global network QUEUED 06 Banks appear on SWIFTNet as distinct - Both banks appear on SWIFTNet as QUEUED Security on SWIFTNet rests on public key infrastructure, message authentication, and strict access control. Step 3 of 6 Security on SWIFTNet rests on public key IN PROGRESS SWIFTNet closed network that connects member DONE Main connection components Alliance Access DONE Security on SWIFTNet rests on public infrastructure, message authentication, ACTIVE Control failure disconnection bank that fails those controls can be QUEUED Store and forward design is essential for a global network QUEUED Banks appear on SWIFTNet as distinct Both banks appear on SWIFTNet as distinct QUEUED Security on SWIFTNet rests on public key infrastructure, message authentication, and strict access control.
Control failure disconnection PAYMENT OPERATIONS IN PROGRESS LIVE 01 SWIFTNet - closed network that connects member DONE 02 Main connection components - Alliance Access DONE 03 Security on SWIFTNet rests on public - infrastructure, message DONE 04 Control failure disconnection - bank that fails those controls can be ACTIVE 05 Store and forward - design is essential for a global network QUEUED 06 Banks appear on SWIFTNet as distinct - Both banks appear on SWIFTNet as QUEUED A bank that fails those controls can be disconnected from the network. Step 4 of 6 Control failure disconnection IN PROGRESS SWIFTNet closed network that connects member DONE Main connection components Alliance Access DONE Security on SWIFTNet rests on public infrastructure, message authentication, DONE Control failure disconnection bank that fails those controls can be ACTIVE Store and forward design is essential for a global network QUEUED Banks appear on SWIFTNet as distinct Both banks appear on SWIFTNet as distinct QUEUED A bank that fails those controls can be disconnected from the network.
Store and forward PAYMENT OPERATIONS IN PROGRESS LIVE 01 SWIFTNet - closed network that connects member DONE 02 Main connection components - Alliance Access DONE 03 Security on SWIFTNet rests on public - infrastructure, message DONE 04 Control failure disconnection - bank that fails those controls can be DONE 05 Store and forward - design is essential for a global network ACTIVE 06 Banks appear on SWIFTNet as distinct - Both banks appear on SWIFTNet as QUEUED That store and forward design is essential for a global network that spans time zones. Step 5 of 6 Store and forward IN PROGRESS SWIFTNet closed network that connects member DONE Main connection components Alliance Access DONE Security on SWIFTNet rests on public infrastructure, message authentication, DONE Control failure disconnection bank that fails those controls can be DONE Store and forward design is essential for a global network ACTIVE Banks appear on SWIFTNet as distinct Both banks appear on SWIFTNet as distinct QUEUED That store and forward design is essential for a global network that spans time zones.
Banks appear on SWIFTNet as distinct BICs PAYMENT OPERATIONS COMPLETE LIVE 01 SWIFTNet - closed network that connects member DONE 02 Main connection components - Alliance Access DONE 03 Security on SWIFTNet rests on public - infrastructure, message DONE 04 Control failure disconnection - bank that fails those controls can be DONE 05 Store and forward - design is essential for a global network DONE 06 Banks appear on SWIFTNet as distinct - Both banks appear on SWIFTNet as ACTIVE Both banks appear on SWIFTNet as distinct BICs, and both are subject to the same security rules. Step 6 of 6 Banks appear on SWIFTNet as distinct BICs COMPLETE SWIFTNet closed network that connects member DONE Main connection components Alliance Access DONE Security on SWIFTNet rests on public infrastructure, message authentication, DONE Control failure disconnection bank that fails those controls can be DONE Store and forward design is essential for a global network DONE Banks appear on SWIFTNet as distinct Both banks appear on SWIFTNet as distinct ACTIVE Both banks appear on SWIFTNet as distinct BICs, and both are subject to the same security rules.

Key points of this lesson, in order.

0:00 / 4:14 Step 1 of 6

SWIFTNet: How Banks Connect

SWIFT Fundamentals, Lesson 2 of 7, Narration 4:14, D04 Messaging and standards

GatewaySWIFTBIC

What you will learn

Your objective. By the end of this lesson, you will be able to explain swiftnet: how banks connect. SWIFTNet is a private, closed network that connects member institutions to SWIFT services.

Why it matters. This matters because the message is the payment instruction. A wrong field, a missing element or a misunderstood format is a failed payment, a return, or a compliance breach.

Chapter objective: Learner explains SWIFT fundamentals, SWIFTNet, message categories and types, BIC structure under ISO 9362, and the mandatory fields of an MT103. Learner uses real examples with amounts, banks and message names to show how the topic works in practice.

Key learning points

  • SWIFTNet: private
  • Main connection components
  • Security on SWIFTNet rests on public key
  • Control failure disconnection
  • Store and forward
  • Banks appear on SWIFTNet as distinct BICs

Key terms

Gateway: A service that connects a merchant website or app to payment networks and acquirers. It encrypts card data, routes authorisation requests, and returns the result to the merchant.

SWIFT: The Society for Worldwide Interbank Financial Telecommunication, a member owned cooperative that provides secure messaging services for financial institutions.

BIC: A business identifier code that uniquely identifies a bank or financial institution in international payments.

Payment flow diagram showing SWIFTNet: How Banks Connect.

Practise this lesson

Exercise

Apply the concept in this lesson to a real banking scenario.

Use the definition, the example and the key points in this lesson.

  1. What to do. Explain the concept in your own words, give a banking example with an amount, and state what goes wrong if it is misunderstood.

Correct result. A correct answer names the concept accurately, uses a realistic banking example with a concrete amount, and identifies the consequence of getting it wrong.

Why. Understanding is not memorising a definition. It is being able to explain it, apply it, and spot the failure it prevents.

Check your understanding

Practice question

Which of the following best describes swiftnet: how banks connect?

Takeaway and next step

What to remember

Both banks appear on SWIFTNet as distinct BICs, and both are subject to the same security rules.

Open the message type from this lesson and inspect its fields, then find the field that carries the amount.

Open the ISO 20022 Message Explorer →

Builds on "What SWIFT Is and What It Is Not".

Transcript and full text

Show transcript

SWIFTNet is a private, closed network that connects member institutions to SWIFT services. It runs over Internet Protocol, but it is not the public internet. Access is restricted to members, traffic is encrypted, and every connection is authenticated with certificates and hardware security modules. A bank cannot simply plug a laptop into SWIFTNet. It must install approved software, register its BIC, obtain security credentials, and pass SWIFT security reviews before it can send its first live message. That closed design is why banks trust SWIFTNet with payment instructions worth trillions of dollars each day. The main connection components are Alliance Access, Alliance Gateway, and the SWIFTNet Link. Alliance Access is the messaging software that a bank runs on its own premises to create, validate, store and route SWIFT messages. Alliance Gateway connects that software to SWIFTNet and manages the secure session. The SWIFTNet Link is the physical connection, usually two leased lines to two different SWIFT operating centres, so that a failure of one line does not cut the bank off. A large bank may run multiple gateways across two data centres to survive a site failure. Security on SWIFTNet rests on public key infrastructure, message authentication, and strict access control. Each message is signed, encrypted in transit, and checked for integrity on arrival, so a tampered message is detected and rejected. Only authorised operators can create or release a message, and every action is logged with a user identifier and a timestamp. Banks must also follow the Customer Security Programme, which requires controls such as multi factor authentication, segregation of duties, and regular penetration testing. A bank that fails those controls can be disconnected from the network. SWIFTNet is built for resilience as well as security. SWIFT operates data centres in Europe and the United States, with traffic distributed between them, and it can reroute messages if one centre fails. Messages are stored and forwarded, so if the receiving bank is temporarily offline, SWIFT holds the message and delivers it when the bank reconnects. A bank in Tokyo that loses its primary link at 9 in the morning can still receive its queued messages through its backup link at a quarter past 9 in the morning, and no message is lost in the process. That store and forward design is essential for a global network that spans time zones. A small bank connects to SWIFTNet in the same way as a large bank, but it may use a service bureau or a shared connection instead of running its own gateway. A service bureau is a third party that operates Alliance Access on behalf of several small banks, each with its own BIC and its own security credentials. For example, a small bank in Kenya with 200 SWIFT messages a day may use a service bureau in Nairobi, while a large bank in London with 200,000 messages a day runs its own gateways in two data centres. Both banks appear on SWIFTNet as distinct BICs, and both are subject to the same security rules. Worked example with real numbers: a banking group has 12 banks in 8 countries, and each bank needs a SWIFT connection, but 12 separate connections would cost 12 times the fee, need 12 security reviews, and need 12 teams to operate them. The hub processes 40,000 messages a day for the group, at a cost of EUR 0.08 per message, while 12 separate connections would have cost EUR 0.25 per message, so the group saves about EUR 2.5 million a year, and the security review is done once, not 12 times. Centralised connectivity is therefore a commercial decision, not just a technical one, and the BA must document the saving. Failure and recovery: the centralised hub fails when it goes down, because all 12 banks lose their SWIFT connection at once, and no bank can send or receive a payment, so the hub must have a disaster recovery site, tested twice a year, that can take over in under an hour, and each bank must have a fallback, usually a service bureau, that can send urgent payments while the hub is down. A hub without a tested disaster recovery is a single point of failure for 12 banks, and the BA must require the recovery test, the recovery time, and the fallback, because a hub that cannot recover is a hub that should not have been built. For a business analyst, product owner or subject matter expert, the SWIFTNet requirement must name the centralised connectivity model, the hub, the service bureau alternative, the RMA authorisation per BIC, and the disaster recovery. Each bank in the group keeps its own BIC, and the hub must route by BIC, so that a message for the Paris bank goes to Paris and a message for the Madrid bank goes to Madrid, and the RMA, the relationship management application authorisation, must be held per BIC, because a hub that holds one RMA for the group cannot send on behalf of a bank that has not authorised it. A hub that routes by BIC but holds RMA for only one bank is a hub that will fail for the other 11.

SWIFTNet is a private, closed network that connects member institutions to SWIFT services. It runs over Internet Protocol, but it is not the public internet. Access is restricted to members, traffic is encrypted, and every connection is authenticated with certificates and hardware security modules. A bank cannot simply plug a laptop into SWIFTNet. It must install approved software, register its BIC, obtain security credentials, and pass SWIFT security reviews before it can send its first live message. That closed design is why banks trust SWIFTNet with payment instructions worth trillions of dollars each day.

The main connection components are Alliance Access, Alliance Gateway, and the SWIFTNet Link. Alliance Access is the messaging software that a bank runs on its own premises to create, validate, store and route SWIFT messages. Alliance Gateway connects that software to SWIFTNet and manages the secure session. The SWIFTNet Link is the physical connection, usually two leased lines to two different SWIFT operating centres, so that a failure of one line does not cut the bank off. A large bank may run multiple gateways across two data centres to survive a site failure.

Security on SWIFTNet rests on public key infrastructure, message authentication, and strict access control. Each message is signed, encrypted in transit, and checked for integrity on arrival, so a tampered message is detected and rejected. Only authorised operators can create or release a message, and every action is logged with a user identifier and a timestamp. Banks must also follow the Customer Security Programme, which requires controls such as multi factor authentication, segregation of duties, and regular penetration testing. A bank that fails those controls can be disconnected from the network.

SWIFTNet is built for resilience as well as security. SWIFT operates data centres in Europe and the United States, with traffic distributed between them, and it can reroute messages if one centre fails. Messages are stored and forwarded, so if the receiving bank is temporarily offline, SWIFT holds the message and delivers it when the bank reconnects. A bank in Tokyo that loses its primary link at 9 in the morning can still receive its queued messages through its backup link at a quarter past 9 in the morning, and no message is lost in the process. That store and forward design is essential for a global network that spans time zones.

A small bank connects to SWIFTNet in the same way as a large bank, but it may use a service bureau or a shared connection instead of running its own gateway. A service bureau is a third party that operates Alliance Access on behalf of several small banks, each with its own BIC and its own security credentials. For example, a small bank in Kenya with 200 SWIFT messages a day may use a service bureau in Nairobi, while a large bank in London with 200,000 messages a day runs its own gateways in two data centres. Both banks appear on SWIFTNet as distinct BICs, and both are subject to the same security rules.

Worked example with real numbers: a banking group has 12 banks in 8 countries, and each bank needs a SWIFT connection, but 12 separate connections would cost 12 times the fee, need 12 security reviews, and need 12 teams to operate them. The hub processes 40,000 messages a day for the group, at a cost of EUR 0.08 per message, while 12 separate connections would have cost EUR 0.25 per message, so the group saves about EUR 2.5 million a year, and the security review is done once, not 12 times. Centralised connectivity is therefore a commercial decision, not just a technical one, and the BA must document the saving.

Failure and recovery: the centralised hub fails when it goes down, because all 12 banks lose their SWIFT connection at once, and no bank can send or receive a payment, so the hub must have a disaster recovery site, tested twice a year, that can take over in under an hour, and each bank must have a fallback, usually a service bureau, that can send urgent payments while the hub is down. A hub without a tested disaster recovery is a single point of failure for 12 banks, and the BA must require the recovery test, the recovery time, and the fallback, because a hub that cannot recover is a hub that should not have been built.

For a business analyst, product owner or subject matter expert, the SWIFTNet requirement must name the centralised connectivity model, the hub, the service bureau alternative, the RMA authorisation per BIC, and the disaster recovery. Each bank in the group keeps its own BIC, and the hub must route by BIC, so that a message for the Paris bank goes to Paris and a message for the Madrid bank goes to Madrid, and the RMA, the relationship management application authorisation, must be held per BIC, because a hub that holds one RMA for the group cannot send on behalf of a bank that has not authorised it. A hub that routes by BIC but holds RMA for only one bank is a hub that will fail for the other 11.

Full lesson text (all scenes)

Completing a lesson updates your progress dashboard on the homepage.

Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.