| Field | Meaning | Required |
|---|---|---|
GrpHdr | The header with message identification, creation date and time, number of transactions, control sum and initiating party. It identifies the file for the bank an | M |
PmtInf | A block grouping payments that share the same debtor, debtor account, execution date and charges bearer. One pain.001 file can hold many payment information blo | M |
PmtInfId | A unique identification for the payment information block, assigned by the customer. It lets the customer and the bank refer to the whole block in status report | M |
PmtMtd | The method used for the payment, normally TRF for a credit transfer, TRA for a transfer advice or CHK for a cheque. TRF is the standard value for a bank credit | M |
ReqdExctnDt | The date on which the customer asks the bank to execute the payment. The bank checks it against cut off times and business days and may move it to the next busi | M |
Dbtr | The customer ordering the payment, with name, postal address and identification. The bank matches the debtor to its customer records and checks signing authorit | M |
DbtrAcct | The account from which the payment is debited, identified by IBAN or other account identification. The bank checks that the account exists, has sufficient funds | M |
DbtrAgt | The bank holding the debtor account, identified by BIC. It is the bank receiving the pain.001 file. The debtor agent validates the file, screens the payments an | M |
CdtrAgt | The bank holding the creditor account, identified by BIC when known. The customer may leave it blank and let the debtor agent derive it from the creditor IBAN. | O |
Cdtr | The beneficiary of the payment, with name, postal address and identification. The bank screens the creditor against sanctions and fraud lists before execution. | M |
CdtrAcct | The account to be credited, identified by IBAN or other account identification. The bank validates the IBAN format and check digits before accepting the file. A | M |
Amt | The amount and currency of the individual credit transfer, for example EUR 10,000. It is the amount the creditor receives before any charges. The sum of the amo | M |
Northgate Trading sends a pain.001 file to Meridian Bank London with one payment information block for 48 supplier payments totalling EUR 120,000, requested execution date 6 November 2026, charge bearer SLEV. The bank validates the file, debits the Northgate account, and reports acceptance in a pain.002.
Valid example from the message catalogue. Scheme rules: pain.001 is a base ISO 20022 message: the structure and fields below are the base definition, and each scheme adds its own rules for its rail. Under SEPA SCT the IBAN is mandatory for debtor and credi
Worked Example: A Corporation Sends pain.001 Through a Relay to Pay EUR 750,000, with the pain.002 status reports at each step
What you will learn
Your objective. By the end of this lesson, you will be able to explain worked example: a corporation sends pain.001 through a relay to pay EUR 750,000, with the pain.002 status reports at each step. A corporation based in Rotterdam, with its EUR operating account held by a bank in Frankfurt, needs to pay EUR 750,000 to a supplier in Vienna for a delivery of industrial pumps.
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 pain.001 and pain.002 in depth, describes the relay scenario, authorised party initiation, and financial institution initiation, and traces a payment to pacs.008. Learner uses real amounts, banks and message names to show how customer initiation works in practice.
Key learning points
- Corporation based in Rotterdam
- Amsterdam bank
- Frankfurt bank
- Pacs.008 travels through SEPA clearing
- Payment had failed
- Worked example shows why pain.001
Key terms
Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.
Execution date: The date on which the bank executes a payment instruction, debiting the debtor account and sending the message onward.
Charge bearer: A code that states who pays the charges for a payment. In ISO 20022 the values are DEBT for debtor, CRED for creditor, SHAR for shared and SLEV for service level.
ISO 20022 XML explorer showing Worked Example: A Corporation Sends pain.001 Through a Relay to Pay EUR 750,000, with the pain.002 status reports at each step.
Practise this lesson
Exercise
Read the pain.001 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 worked example: a corporation sends pain.001 through a relay to pay EUR 750,000, with the pain.002 status reports at each step?
Takeaway and next step
What to remember
The worked example shows why pain.001 and pain.002 are a pair, because the instruction without the report leaves the customer blind, and the report without the instruction has nothing to report on.
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 "Authorised Party Initiation and Financial Institution Payment Initiation".
Transcript and full text
Show transcript
A corporation based in Rotterdam, with its EUR operating account held by a bank in Frankfurt, needs to pay EUR 750,000 to a supplier in Vienna for a delivery of industrial pumps. The corporation uses a bank in Amsterdam as its payment platform, so it creates a pain.001.001.09 file in Amsterdam and sends it to the Amsterdam bank on Monday morning. The file contains one payment instruction, with the debtor named as the Rotterdam corporation, the debtor account held in Frankfurt, the creditor named as the Vienna supplier, the creditor IBAN AT611904300234573201, the amount EUR 750,000, the requested execution date of Tuesday, the charge bearer SLEV, and remittance information naming invoice INV-2026-1147 for the pump delivery. The Amsterdam bank receives the pain.001 file and performs its first validation. It checks the group header, the control sum of EUR 750,000, the IBAN format, the execution date, and the sanction screening for the supplier name and country. All checks pass, so the Amsterdam bank sends a first pain.002.001.10 report to the corporation with status ACCP at transaction level, confirming that the instruction has been accepted for relay. The bank then forwards the instruction to the Frankfurt bank, which is the debtor agent, preserving the end to end identification so the payment can be traced. The corporation now knows its instruction is valid and is moving to the account holding bank. The Frankfurt bank receives the relayed instruction on Monday afternoon and checks the debtor account. The account holds EUR 1,150,000, so the EUR 750,000 payment is covered, and there is no hold or freeze on the account. The bank also checks the requested execution date of Tuesday and confirms that Tuesday is a business day in Germany and Austria. It debits EUR 750,000 from the Rotterdam corporation account on Tuesday morning, leaving a balance of EUR 400,000, and it creates a pacs.008.001.08 message for EUR 750,000 to the supplier bank in Vienna. The Frankfurt bank sends a status report back through Amsterdam, and the corporation receives a second pain.002 with status ACSP, meaning accepted settlement in process. The pacs.008 travels through SEPA clearing to the supplier bank in Vienna, which receives it on Tuesday and credits the supplier account with EUR 750,000. The Vienna bank sends a pacs.002 report back to the Frankfurt bank confirming acceptance, and the Frankfurt bank passes the confirmation through the Amsterdam bank to the corporation. The corporation receives a third pain.002 report, this time confirming that the payment has been settled and that the supplier has been credited. The treasurer in Rotterdam can now match the payment to invoice INV-2026-1147, close the payable in the accounting system, and tell the supplier that EUR 750,000 was paid on Tuesday as agreed in the contract. If the payment had failed at any stage, the pain.002 chain would have shown the failure clearly and the corporation could have acted quickly. If the Frankfurt account had held only EUR 600,000, the Frankfurt bank would have reported RJCT with reason AM09 or with an insufficient funds code, and the corporation would have known on Monday that it needed to move EUR 150,000 into the account before the Tuesday execution date. If the Vienna IBAN had been wrong, the Amsterdam bank would have reported RJCT with reason AC01 at the first validation, and the corporation could have corrected the IBAN and resent the file the same day. The worked example shows why pain.001 and pain.002 are a pair, because the instruction without the report leaves the customer blind, and the report without the instruction has nothing to report on.
A corporation based in Rotterdam, with its EUR operating account held by a bank in Frankfurt, needs to pay EUR 750,000 to a supplier in Vienna for a delivery of industrial pumps. The corporation uses a bank in Amsterdam as its payment platform, so it creates a pain.001.001.09 file in Amsterdam and sends it to the Amsterdam bank on Monday morning. The file contains one payment instruction, with the debtor named as the Rotterdam corporation, the debtor account held in Frankfurt, the creditor named as the Vienna supplier, the creditor IBAN AT611904300234573201, the amount EUR 750,000, the requested execution date of Tuesday, the charge bearer SLEV, and remittance information naming invoice INV-2026-1147 for the pump delivery.
The Amsterdam bank receives the pain.001 file and performs its first validation. It checks the group header, the control sum of EUR 750,000, the IBAN format, the execution date, and the sanction screening for the supplier name and country. All checks pass, so the Amsterdam bank sends a first pain.002.001.10 report to the corporation with status ACCP at transaction level, confirming that the instruction has been accepted for relay. The bank then forwards the instruction to the Frankfurt bank, which is the debtor agent, preserving the end to end identification so the payment can be traced. The corporation now knows its instruction is valid and is moving to the account holding bank.
The Frankfurt bank receives the relayed instruction on Monday afternoon and checks the debtor account. The account holds EUR 1,150,000, so the EUR 750,000 payment is covered, and there is no hold or freeze on the account. The bank also checks the requested execution date of Tuesday and confirms that Tuesday is a business day in Germany and Austria. It debits EUR 750,000 from the Rotterdam corporation account on Tuesday morning, leaving a balance of EUR 400,000, and it creates a pacs.008.001.08 message for EUR 750,000 to the supplier bank in Vienna. The Frankfurt bank sends a status report back through Amsterdam, and the corporation receives a second pain.002 with status ACSP, meaning accepted settlement in process.
The pacs.008 travels through SEPA clearing to the supplier bank in Vienna, which receives it on Tuesday and credits the supplier account with EUR 750,000. The Vienna bank sends a pacs.002 report back to the Frankfurt bank confirming acceptance, and the Frankfurt bank passes the confirmation through the Amsterdam bank to the corporation. The corporation receives a third pain.002 report, this time confirming that the payment has been settled and that the supplier has been credited. The treasurer in Rotterdam can now match the payment to invoice INV-2026-1147, close the payable in the accounting system, and tell the supplier that EUR 750,000 was paid on Tuesday as agreed in the contract.
If the payment had failed at any stage, the pain.002 chain would have shown the failure clearly and the corporation could have acted quickly. If the Frankfurt account had held only EUR 600,000, the Frankfurt bank would have reported RJCT with reason AM09 or with an insufficient funds code, and the corporation would have known on Monday that it needed to move EUR 150,000 into the account before the Tuesday execution date. If the Vienna IBAN had been wrong, the Amsterdam bank would have reported RJCT with reason AC01 at the first validation, and the corporation could have corrected the IBAN and resent the file the same day. The worked example shows why pain.001 and pain.002 are a pair, because the instruction without the report leaves the customer blind, and the report without the instruction has nothing to report on.
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.