| 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
The message catalogue, pacs, pain and camt
What you will learn
Your objective. By the end of this lesson, you will be able to explain message catalogue, PACS, PAIN and CAMT. The ISO 20022 message catalogue is organised by business area, and the three most important areas for payments are pacs, pain, and camt.
Why it matters. The catalogue is large, and it continues to grow, but an analyst does not need to memorise every message.
Chapter objective: Learner explains ISO 20022 structure, including business concepts, message definitions, XML syntax, and the roles of pacs, pain, camt, and admi messages, and navigates the message catalogue confidently. Learner practises this skill on realistic banking cases, explaining the reasoning clearly and using correct terminology throughout the work.
Key learning points
- ISO 20022 message catalogue
- Messages that replace
- Messages: used when corporate sends
- Replace MT940
- Statement once
Key terms
Settlement: The final movement of funds between banks to discharge obligations created by cleared payments. Settlement is usually made in central bank money or through correspondent accounts.
ISO 20022: An international standard for financial messaging that defines XML message formats for payments, securities and trade.
Clearing: The process of exchanging payment instructions between banks and calculating what each bank owes the others.
SWIFT MT message viewer showing The message catalogue, pacs, pain and camt.
Practise this lesson
Exercise
Read the ISO 20022 message 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 message catalogue, PACS, PAIN and CAMT?
Takeaway and next step
What to remember
That end to end chain, from initiation to clearing to reporting, is the real catalogue, and it is what you need to be able to trace.
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 business model behind the messages".
Transcript and full text
Show transcript
The ISO 20022 message catalogue is organised by business area, and the three most important areas for payments are pacs, pain, and camt. The pacs area, which stands for payments clearing and settlement, contains messages exchanged between financial institutions, such as pacs zero zero eight for a customer credit transfer, pacs zero zero nine for a financial institution credit transfer, pacs zero zero four for a payment return, and pacs zero zero two for a payment status report. These are the messages that replace MT103, MT202, MT900, and related MT messages in the interbank space. The pain area, which stands for payments initiation, contains messages exchanged between a customer and a bank, such as pain zero zero one for a customer credit transfer initiation, pain zero zero two for a payment status report to the customer, and pain zero zero eight for a customer direct debit initiation. These messages are used when a corporate sends a bulk file to its bank, or when a payment is initiated through an API. The camt area, which stands for cash management, contains messages for statements and reporting, such as camt zero five two for an intraday bank to customer account report, camt zero five three for an end of day statement, and camt zero five four for a debit credit notification. These replace MT940, MT942, and MT900 and MT910 in the reporting space. The catalogue is large, and it continues to grow, but an analyst does not need to memorise every message. Focus on the messages that are relevant to your product, learn their structure, and understand how they relate to each other. A payment that starts as a pain zero zero one becomes a pacs zero zero eight in the interbank space, and its status is reported back as a pacs zero zero two and then as a pain zero zero two. A statement that was once an MT940 becomes a camt zero five three. That end to end chain, from initiation to clearing to reporting, is the real catalogue, and it is what you need to be able to trace. Worked example with real numbers: a corporate customer initiates a EUR 20,000 supplier payment, and the message catalogue shows which message is used at each step. The customer sends a pain.001 payment initiation to Bank A. Bank A sends a pacs.008. Bank B sends a pacs.002. At the end of the day Bank B sends a camt.053 statement to the supplier, showing the EUR 20,000 credit with the end to end identifier. If the supplier account had been closed, Bank B would have sent a pacs.004 return with reason AC04, and Bank A would have sent a pain.002. Each message has a purpose, a sender, a receiver and a timing, and using the wrong message, for example a pacs.008 where a pain.001 is needed, will be rejected, because the receiver expects a different message type. Failure and recovery: a pain.001 sent to the clearing system, instead of to the bank, is rejected, because the clearing system expects a pacs.008, not a customer initiation, and the recovery is to send the pain.001 to the bank, which creates the pacs.008. A pacs.002 sent with the wrong status, for example ACCP when the payment was actually rejected, misleads the customer, and the recovery is to correct the status and to resend the pacs.002 with RJCT and the reason code. A camt. Each failure is a catalogue failure, using the wrong message or the wrong status, and the fix is to use the correct message for the step, as defined in the catalogue on iso20022.org. For a business analyst, product owner or subject matter expert, the test is to name, for any payment, the message used at each step, its sender, its receiver, its purpose and its timing, from the catalogue: pain for initiation, pacs for clearing and settlement, camt for cash management, admi for administration, and head for the header. The catalogue is the map, and a requirement that names a message without naming its step will be ambiguous, because the same message name can be used at different steps with different rules. The ISO 20022 catalogue on iso20022.org is the source, and the SWIFT CBPR+ usage guidelines are the source for which catalogue messages are used for cross-border payments, and both must be cited in the specification.
The ISO 20022 message catalogue is organised by business area, and the three most important areas for payments are pacs, pain, and camt. The pacs area, which stands for payments clearing and settlement, contains messages exchanged between financial institutions, such as pacs zero zero eight for a customer credit transfer, pacs zero zero nine for a financial institution credit transfer, pacs zero zero four for a payment return, and pacs zero zero two for a payment status report. These are the messages that replace MT103, MT202, MT900, and related MT messages in the interbank space.
The pain area, which stands for payments initiation, contains messages exchanged between a customer and a bank, such as pain zero zero one for a customer credit transfer initiation, pain zero zero two for a payment status report to the customer, and pain zero zero eight for a customer direct debit initiation. These messages are used when a corporate sends a bulk file to its bank, or when a payment is initiated through an API. The camt area, which stands for cash management, contains messages for statements and reporting, such as camt zero five two for an intraday bank to customer account report, camt zero five three for an end of day statement, and camt zero five four for a debit credit notification. These replace MT940, MT942, and MT900 and MT910 in the reporting space.
The catalogue is large, and it continues to grow, but an analyst does not need to memorise every message. Focus on the messages that are relevant to your product, learn their structure, and understand how they relate to each other. A payment that starts as a pain zero zero one becomes a pacs zero zero eight in the interbank space, and its status is reported back as a pacs zero zero two and then as a pain zero zero two. A statement that was once an MT940 becomes a camt zero five three. That end to end chain, from initiation to clearing to reporting, is the real catalogue, and it is what you need to be able to trace.
Worked example with real numbers: a corporate customer initiates a EUR 20,000 supplier payment, and the message catalogue shows which message is used at each step. The customer sends a pain.001 payment initiation to Bank A. Bank A sends a pacs.008. Bank B sends a pacs.002. At the end of the day Bank B sends a camt.053 statement to the supplier, showing the EUR 20,000 credit with the end to end identifier. If the supplier account had been closed, Bank B would have sent a pacs.004 return with reason AC04, and Bank A would have sent a pain.002. Each message has a purpose, a sender, a receiver and a timing, and using the wrong message, for example a pacs.008 where a pain.001 is needed, will be rejected, because the receiver expects a different message type.
Failure and recovery: a pain.001 sent to the clearing system, instead of to the bank, is rejected, because the clearing system expects a pacs.008, not a customer initiation, and the recovery is to send the pain.001 to the bank, which creates the pacs.008. A pacs.002 sent with the wrong status, for example ACCP when the payment was actually rejected, misleads the customer, and the recovery is to correct the status and to resend the pacs.002 with RJCT and the reason code. A camt. Each failure is a catalogue failure, using the wrong message or the wrong status, and the fix is to use the correct message for the step, as defined in the catalogue on iso20022.org.
For a business analyst, product owner or subject matter expert, the test is to name, for any payment, the message used at each step, its sender, its receiver, its purpose and its timing, from the catalogue: pain for initiation, pacs for clearing and settlement, camt for cash management, admi for administration, and head for the header. The catalogue is the map, and a requirement that names a message without naming its step will be ambiguous, because the same message name can be used at different steps with different rules. The ISO 20022 catalogue on iso20022.org is the source, and the SWIFT CBPR+ usage guidelines are the source for which catalogue messages are used for cross-border payments, and both must be cited in the specification.
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.