| 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
FIN, InterAct and FileAct
What you will learn
Your objective. By the end of this lesson, you will be able to explain fin, interact and fileact. FIN is the original SWIFT service, and it carries MT messages such as MT103, MT202 and MT950 in a store and forward model.
Why it matters. Operations teams must know which service carried each leg, because the investigation path is different for a FIN message, an InterAct exchange, and a FileAct transfer.
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
- FIN: original SWIFT service
- FIN remains the backbone
- Interactive model suits services
- FileAct supports large files
- Operations teams must know which service
- Bank that sends 10,000 MT103
Key terms
Sanctions screening: Checking payment parties, countries and references against sanctions lists published by governments and international bodies.
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...
SWIFT MT message viewer showing FIN, InterAct and FileAct.
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 fin, interact and fileact?
Takeaway and next step
What to remember
A bank that sends 10,000 MT103 messages a day through FIN will pay a different tariff from a bank that sends 100 FileAct files a day, and the operations team must understand both tariffs when it designs a new payment product.
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 "How a BIC Routes a Message Across SWIFTNet".
Transcript and full text
Show transcript
FIN is the original SWIFT service, and it carries MT messages such as MT103, MT202 and MT950 in a store and forward model. The sender creates an MT message, sends it through FIN, and SWIFT stores it until the receiver is ready to collect it. FIN guarantees delivery, provides acknowledgements, and supports the full range of message categories from 1 to 9. A payment of 367,574.90 dollars from BNP Paribas to Banco Santander travels as an MT103 through FIN, and the MT950 statement that Santander receives the next morning also travels through FIN. FIN remains the backbone of cross border payments. InterAct is an interactive service that supports real time request and response exchanges using XML messages, including ISO 20022 messages such as pacs.008 and pain.001. Unlike FIN, which stores a message and delivers it later, InterAct opens a session between the sender and the receiver and allows them to exchange messages and replies within that session. A bank that wants to query the status of a payment, or to send a single pacs.008 and receive an immediate acknowledgement, will use InterAct. The interactive model suits services where the sender needs an answer in seconds, not minutes. FileAct is a file transfer service that moves bulk files securely between institutions. It is used for large batches that would be inefficient to send as single messages, such as a file of 50,000 salary payments, a daily statement file, or a bulk sanctions screening file. A corporate client that submits a pain.001 file with 4,000 payments worth 18,000,000 pounds may send that file through FileAct to its bank, and the bank may return a pain.002 status report file through FileAct in return. FileAct supports large files, compression, and delivery confirmations, and it is designed for volume rather than for single transactions. The three services can work together on one payment. A corporate treasury system might send a pain.001 bulk file through FileAct to its bank, the bank might convert each item into a pacs.008 and send it through InterAct to a clearing system, and the clearing system might return an MT103 through FIN to a correspondent bank for the cross border leg. Each service does the job it is best at, and the BIC remains the routing address throughout. Operations teams must know which service carried each leg, because the investigation path is different for a FIN message, an InterAct exchange, and a FileAct transfer. The choice of service also affects security, timing and cost. FIN messages are validated against strict MT formats and are subject to SWIFT format checks, while InterAct and FileAct messages are validated against XML schemas and business rules agreed between the parties. FIN delivery is usually measured in seconds, InterAct responses in seconds as well, and FileAct transfers in minutes depending on file size. A bank that sends 10,000 MT103 messages a day through FIN will pay a different tariff from a bank that sends 100 FileAct files a day, and the operations team must understand both tariffs when it designs a new payment product.
FIN is the original SWIFT service, and it carries MT messages such as MT103, MT202 and MT950 in a store and forward model. The sender creates an MT message, sends it through FIN, and SWIFT stores it until the receiver is ready to collect it. FIN guarantees delivery, provides acknowledgements, and supports the full range of message categories from 1 to 9. A payment of 367,574.90 dollars from BNP Paribas to Banco Santander travels as an MT103 through FIN, and the MT950 statement that Santander receives the next morning also travels through FIN. FIN remains the backbone of cross border payments.
InterAct is an interactive service that supports real time request and response exchanges using XML messages, including ISO 20022 messages such as pacs.008 and pain.001. Unlike FIN, which stores a message and delivers it later, InterAct opens a session between the sender and the receiver and allows them to exchange messages and replies within that session. A bank that wants to query the status of a payment, or to send a single pacs.008 and receive an immediate acknowledgement, will use InterAct. The interactive model suits services where the sender needs an answer in seconds, not minutes.
FileAct is a file transfer service that moves bulk files securely between institutions. It is used for large batches that would be inefficient to send as single messages, such as a file of 50,000 salary payments, a daily statement file, or a bulk sanctions screening file. A corporate client that submits a pain.001 file with 4,000 payments worth 18,000,000 pounds may send that file through FileAct to its bank, and the bank may return a pain.002 status report file through FileAct in return. FileAct supports large files, compression, and delivery confirmations, and it is designed for volume rather than for single transactions.
The three services can work together on one payment. A corporate treasury system might send a pain.001 bulk file through FileAct to its bank, the bank might convert each item into a pacs.008 and send it through InterAct to a clearing system, and the clearing system might return an MT103 through FIN to a correspondent bank for the cross border leg. Each service does the job it is best at, and the BIC remains the routing address throughout. Operations teams must know which service carried each leg, because the investigation path is different for a FIN message, an InterAct exchange, and a FileAct transfer.
The choice of service also affects security, timing and cost. FIN messages are validated against strict MT formats and are subject to SWIFT format checks, while InterAct and FileAct messages are validated against XML schemas and business rules agreed between the parties. FIN delivery is usually measured in seconds, InterAct responses in seconds as well, and FileAct transfers in minutes depending on file size. A bank that sends 10,000 MT103 messages a day through FIN will pay a different tariff from a bank that sends 100 FileAct files a day, and the operations team must understand both tariffs when it designs a new payment product.
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.