| Field | Meaning | Required |
|---|---|---|
:20: | A unique reference assigned by the sending bank to identify this payment through its whole life. It must not repeat for the same sender within the same business | M |
:23B: | A four character code that tells the receiving bank how to handle the transfer. CRED means a normal credit transfer, SPAY means a SWIFT payment, SSTD means a st | M |
:32A: | The value date on which funds become available to the beneficiary, the three letter ISO currency code and the amount to be paid. For USD 25,000 on 5 November 20 | M |
:33B: | The currency and amount in which the ordering customer instructed the payment, when that differs from the settlement currency in field 32A. It preserves the ori | O |
:50a: | The customer who ordered the payment, identified by account number and name and address. Option K gives account, name and address in free text. Option F gives s | M |
:52a: | The financial institution that ordered the transfer when it is not the sender of the message. It is normally the bank holding the ordering customer account in a | O |
:53a: | The account held by the sender with the receiver, or the correspondent bank through which settlement will occur. It tells the receiving bank where to debit the | O |
:54a: | The account held by the receiver with another bank, used when the receiver does not hold the sender account directly. It identifies the next bank in the settlem | O |
:57a: | The bank where the beneficiary holds an account, when it is not the receiver of the MT103. It directs the receiving bank to forward the payment to the correct a | O |
:59a: | The final recipient of the funds, identified by account number and name and address. Option A gives the account and BIC, option F gives structured name and addr | M |
:70: | Free text information for the beneficiary explaining what the payment is for, such as an invoice number, contract reference or salary month. It is limited to fo | O |
:71A: | A three letter code stating who pays the transfer charges. OUR means the ordering customer pays all charges, BEN means the beneficiary pays all charges, and SHA | M |
Meridian Bank London sends an MT103, reference MER1035521, for USD 25,000 value 5 November 2024 to Harbour Bank Singapore to pay Bright Logistics for invoice INV-1187. This is a pre-migration example, from before coexistence ended on 22 November 2025. Field :71A: is SHA, the beneficiary account is given in :59a:, and the payment settles on the value date.
Valid example from the message catalogue. Scheme rules: MT103 is a SWIFT MT (FIN) message, not a base ISO 20022 message: there is no single global scheme rulebook, and each bank and market practice sets its own format limits and cut-off times on top of the
How a BIC Routes a Message Across SWIFTNet
What you will learn
Your objective. By the end of this lesson, you will be able to explain BIC routes a message across swiftnet. Routing begins when the sender enters the receiver BIC in the payment system.
Why it matters. That acknowledgement is the evidence operations teams use when a customer asks whether a payment was sent.
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
- Routing begins when the sender
- Early check
- SWIFTNet uses a store
- Acknowledgement: evidence operations teams use
- Routing also depends
Key terms
ISO 20022: An international standard for financial messaging that defines XML message formats for payments, securities and trade.
pacs.008: An ISO 20022 message for a financial institution to financial institution customer credit transfer. It replaces MT103 in cross border payments and carries structured debtor, creditor, charges and...
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 MT message viewer showing How a BIC Routes a Message Across SWIFTNet.
Practise this lesson
Exercise
Read the MT103 message described in this lesson and identify its key parts.
Use the message structure, fields and example in this lesson.
- What to do. List the main blocks of the message, name the field that carries the amount, and name the field that identifies the payment.
Correct result. The message is made of blocks, each carrying a part of the payment instruction. The amount field and the identification field are the two a receiving bank checks first, because without them it cannot process or reconcile the payment.
Why. A message is only useful if you can read it. The blocks tell the receiving bank what to do, and the amount and identification fields are what it checks first.
Check your understanding
Practice question
Which of the following best describes BIC routes a message across swiftnet?
Takeaway and next step
What to remember
A bank that sends a pacs.008 ISO 20022 message through InterAct to DBS Bank in Singapore uses the same BIC DBSSSGSG as it would for an MT103, but the service and the routing are different.
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 "The BIC Code: ISO 9362 and How a BIC Identifies an Entity".
Transcript and full text
Show transcript
Routing begins when the sender enters the receiver BIC in the payment system. The system first checks that the BIC is well formed, with four letters for the bank code, two letters for the country code, and two characters for the location code. It then checks the SWIFT BIC directory to confirm that the BIC exists, is live, and is connected to SWIFTNet. If the BIC is mistyped, for example BSCHESMN instead of BSCHESMM, the directory lookup will fail and the payment will be stopped before it leaves the bank. That early check prevents a message being sent to a bank that does not exist. Once the BIC is validated, the sending bank creates the MT message, signs it, and hands it to Alliance Gateway, which encrypts it and sends it to SWIFTNet. SWIFTNet reads the receiver BIC in the message header and looks up the destination in its routing tables. It then forwards the message to the SWIFT operating centre that serves that receiver, and from there to the receiver own gateway. The whole journey usually takes a few seconds, even for a message from Paris to Singapore, because SWIFTNet is a dedicated network with no public internet hops in the path. SWIFTNet uses a store and forward model for FIN messages. If the receiver is online, the message is delivered immediately and an acknowledgement is returned to the sender. If the receiver is offline, for example during a system upgrade at 2 in the morning in Singapore, SWIFTNet stores the message securely and delivers it when the receiver reconnects. The sender receives a delivery acknowledgement that proves the message was delivered, and the receiver receives a message that it can process and archive. That acknowledgement is the evidence operations teams use when a customer asks whether a payment was sent. If the receiver BIC is correct but the message cannot be delivered, SWIFTNet returns a negative acknowledgement, known as a NAK, with a reason code. A NAK might mean that the receiver gateway is rejecting messages, that the message format is invalid, or that the receiver has closed its session. The sender must then investigate, correct the problem, and resend the message. A payment of 150,000 euros from Milan to Toronto that received a NAK because the Toronto bank was running a weekend upgrade was resent on Monday morning and delivered in seconds, with no loss of the original instruction. Routing also depends on the category and the service. A FIN message, such as an MT103, is routed through the FIN service, which is designed for store and forward messaging. An InterAct message is routed through a different service that supports interactive request and response, while a FileAct message is routed through a file transfer service. The BIC is the same in each case, but SWIFTNet uses the service name in the header to choose the right path. A bank that sends a pacs.008 ISO 20022 message through InterAct to DBS Bank in Singapore uses the same BIC DBSSSGSG as it would for an MT103, but the service and the routing are different.
Routing begins when the sender enters the receiver BIC in the payment system. The system first checks that the BIC is well formed, with four letters for the bank code, two letters for the country code, and two characters for the location code. It then checks the SWIFT BIC directory to confirm that the BIC exists, is live, and is connected to SWIFTNet. If the BIC is mistyped, for example BSCHESMN instead of BSCHESMM, the directory lookup will fail and the payment will be stopped before it leaves the bank. That early check prevents a message being sent to a bank that does not exist.
Once the BIC is validated, the sending bank creates the MT message, signs it, and hands it to Alliance Gateway, which encrypts it and sends it to SWIFTNet. SWIFTNet reads the receiver BIC in the message header and looks up the destination in its routing tables. It then forwards the message to the SWIFT operating centre that serves that receiver, and from there to the receiver own gateway. The whole journey usually takes a few seconds, even for a message from Paris to Singapore, because SWIFTNet is a dedicated network with no public internet hops in the path.
SWIFTNet uses a store and forward model for FIN messages. If the receiver is online, the message is delivered immediately and an acknowledgement is returned to the sender. If the receiver is offline, for example during a system upgrade at 2 in the morning in Singapore, SWIFTNet stores the message securely and delivers it when the receiver reconnects. The sender receives a delivery acknowledgement that proves the message was delivered, and the receiver receives a message that it can process and archive. That acknowledgement is the evidence operations teams use when a customer asks whether a payment was sent.
If the receiver BIC is correct but the message cannot be delivered, SWIFTNet returns a negative acknowledgement, known as a NAK, with a reason code. A NAK might mean that the receiver gateway is rejecting messages, that the message format is invalid, or that the receiver has closed its session. The sender must then investigate, correct the problem, and resend the message. A payment of 150,000 euros from Milan to Toronto that received a NAK because the Toronto bank was running a weekend upgrade was resent on Monday morning and delivered in seconds, with no loss of the original instruction.
Routing also depends on the category and the service. A FIN message, such as an MT103, is routed through the FIN service, which is designed for store and forward messaging. An InterAct message is routed through a different service that supports interactive request and response, while a FileAct message is routed through a file transfer service. The BIC is the same in each case, but SWIFTNet uses the service name in the header to choose the right path. A bank that sends a pacs.008 ISO 20022 message through InterAct to DBS Bank in Singapore uses the same BIC DBSSSGSG as it would for an MT103, but the service and the routing are different.
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.