| 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
How pain.001 Initiates pacs.008, Step by Step
What you will learn
Your objective. By the end of this lesson, you will be able to explain pain.001 initiates pacs.008,. The journey from pain.001 to pacs.008 begins when the customer system creates the pain.001 file and sends it to the debtor agent, which is the bank that holds the debtor account.
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
- Journey from pain.001 to pacs.008
- Debtor agent checks the account
- Debtor agent creates pacs.008
- Instruction identification
- EUR 2,400,000 payment
- Chain: lets corporate treasurer
Key terms
Execution date: The date on which the bank executes a payment instruction, debiting the debtor account and sending the message onward.
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.
pain.001: An ISO 20022 message a customer sends to its bank to instruct one or more credit transfers. It carries payment information, debtor and creditor details, amount, execution date and remittance data.
ISO 20022 XML explorer showing How pain.001 Initiates pacs.008, Step by 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 pain.001 initiates pacs.008,?
Takeaway and next step
What to remember
If an instruction fails, for example because the creditor IBAN is invalid or the amount exceeds a limit, the bank reports RJCT with a reason code such as AC01 or AM09, and that instruction never becomes a pacs.008 message.
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 "pain.002.001.10 Customer Payment Status Report: Statuses and Reason Codes".
Transcript and full text
Show transcript
The journey from pain.001 to pacs.008 begins when the customer system creates the pain.001 file and sends it to the debtor agent, which is the bank that holds the debtor account. The debtor agent first checks the file structure, the group header, the control sum, and the format of each instruction. If the file passes those checks, the bank sends a pain.002 report with status ACCP for the accepted instructions. If an instruction fails, for example because the creditor IBAN is invalid or the amount exceeds a limit, the bank reports RJCT with a reason code such as AC01 or AM09, and that instruction never becomes a pacs.008 message. Once an instruction is accepted, the debtor agent checks the debtor account for sufficient funds and for any hold, freeze, or sanction flag. A corporate account in Frankfurt holding EUR 900,000 can fund a EUR 750,000 payment, but the same payment would fail if EUR 600,000 of the balance were already reserved for a tax payment due that morning. The bank also checks the requested execution date, because a payment dated for a bank holiday cannot be executed on that day and must be moved to the next business day. Only when funds, date, and compliance checks all pass does the bank debit the debtor account and create the interbank instruction. The debtor agent then creates a pacs.008.001.08 Customer Credit Transfer message, which is the interbank version of the customer instruction. The pacs.008 carries the debtor and creditor details from the pain.001, but it adds interbank fields that the customer never sees, including the debtor agent, the creditor agent, the settlement method, the clearing system reference, and the interbank settlement amount and date. The end to end identification from the pain.001 is copied into the pacs.008 so the payment can be traced across both messages. The instruction identification may change, because the bank assigns its own transaction reference for its internal systems. The pacs.008 is sent through the clearing and settlement route that matches the payment, and the route depends on currency, geography, and urgency. A EUR 25,000 payment from a bank in Paris to a bank in Madrid under SEPA becomes a pacs.008 sent through the SEPA clearing system for same day or next day settlement. A USD 180,000 payment from a bank in London to a bank in New York becomes a pacs.008 sent through the cross border correspondent chain, with a UETR assigned for tracking. A EUR 2,400,000 payment that needs immediate final settlement becomes a pacs.008 sent to TARGET for real time gross settlement on central bank accounts. After the pacs.008 is sent, the debtor agent waits for a pacs.002 Payment Status Report from the next agent in the chain, and it uses that report to update the customer. A positive pacs.002 with status ACCP confirms the next agent accepted the payment, while a negative pacs.002 with status RJCT means the payment was rejected downstream and must be returned or corrected. The debtor agent then sends a further pain.002 to the customer, reporting the final outcome. This chain of reports is what lets a corporate treasurer in Munich know, within hours, that a EUR 96,000 payment to a supplier in Warsaw has settled, rather than learning about a failure days later from the supplier.
The journey from pain.001 to pacs.008 begins when the customer system creates the pain.001 file and sends it to the debtor agent, which is the bank that holds the debtor account. The debtor agent first checks the file structure, the group header, the control sum, and the format of each instruction. If the file passes those checks, the bank sends a pain.002 report with status ACCP for the accepted instructions. If an instruction fails, for example because the creditor IBAN is invalid or the amount exceeds a limit, the bank reports RJCT with a reason code such as AC01 or AM09, and that instruction never becomes a pacs.008 message.
Once an instruction is accepted, the debtor agent checks the debtor account for sufficient funds and for any hold, freeze, or sanction flag. A corporate account in Frankfurt holding EUR 900,000 can fund a EUR 750,000 payment, but the same payment would fail if EUR 600,000 of the balance were already reserved for a tax payment due that morning. The bank also checks the requested execution date, because a payment dated for a bank holiday cannot be executed on that day and must be moved to the next business day. Only when funds, date, and compliance checks all pass does the bank debit the debtor account and create the interbank instruction.
The debtor agent then creates a pacs.008.001.08 Customer Credit Transfer message, which is the interbank version of the customer instruction. The pacs.008 carries the debtor and creditor details from the pain.001, but it adds interbank fields that the customer never sees, including the debtor agent, the creditor agent, the settlement method, the clearing system reference, and the interbank settlement amount and date. The end to end identification from the pain.001 is copied into the pacs.008 so the payment can be traced across both messages. The instruction identification may change, because the bank assigns its own transaction reference for its internal systems.
The pacs.008 is sent through the clearing and settlement route that matches the payment, and the route depends on currency, geography, and urgency. A EUR 25,000 payment from a bank in Paris to a bank in Madrid under SEPA becomes a pacs.008 sent through the SEPA clearing system for same day or next day settlement. A USD 180,000 payment from a bank in London to a bank in New York becomes a pacs.008 sent through the cross border correspondent chain, with a UETR assigned for tracking. A EUR 2,400,000 payment that needs immediate final settlement becomes a pacs.008 sent to TARGET for real time gross settlement on central bank accounts.
After the pacs.008 is sent, the debtor agent waits for a pacs.002 Payment Status Report from the next agent in the chain, and it uses that report to update the customer. A positive pacs.002 with status ACCP confirms the next agent accepted the payment, while a negative pacs.002 with status RJCT means the payment was rejected downstream and must be returned or corrected. The debtor agent then sends a further pain.002 to the customer, reporting the final outcome. This chain of reports is what lets a corporate treasurer in Munich know, within hours, that a EUR 96,000 payment to a supplier in Warsaw has settled, rather than learning about a failure days later from the supplier.
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.