| Field | Meaning | Required |
|---|---|---|
GrpHdr | The header with message identification, creation date and time and instructing agent. It identifies the status report for tracking and duplicate detection. The | M |
OrgnlGrpInfAndSts | Reference to the original message group plus its status and reason. It tells the sender whether the whole group was accepted, rejected or partially accepted. Th | O |
TxInfAndSts | Status information for a single transaction, with its identification, status and reason. It is the core of the message for exception handling. The sender uses i | O |
OrgnlInstrId | The instruction identification from the original payment message, copied into the status report. It links the status to the sender instruction. The sender syste | M |
OrgnlEndToEndId | The end to end identification from the original payment, copied into the status report. It stays unchanged through the chain and lets all banks and the customer | O |
OrgnlTxId | The transaction identification from the original payment, assigned by the instructing agent. It provides a third matching key alongside instruction and end to e | O |
TxSts | The status of the transaction, using codes such as ACCP for accepted, RJCT for rejected, PDNG for pending, ACSC for accepted settlement completed and ACCC for a | M |
StsRsnInf | The reason for the status, with a coded reason and additional text. Codes include AC01 for wrong account number, AM05 for duplicate payment and NARR for a narra | O |
OrgnlIntrBkSttlmAmt | The interbank settlement amount from the original payment, copied into the status report. It confirms which payment the status refers to when several payments h | O |
OrgnlIntrBkSttlmDt | The interbank settlement date from the original payment, copied into the status report. It confirms the value date of the payment being reported on. The sender | O |
ChrgsInf | Charges applied by the reporting agent, with amount, currency and bearer. It lets the sender see any fee deducted by an intermediary or the creditor agent. Tran | O |
AccptncDtTm | The date and time when the reporting agent accepted the payment for processing. It is a key timestamp for gpi tracking and for measuring processing speed. The s | O |
Harbour Bank Singapore sends a pacs.002 to Meridian Bank London for the pacs.008 with end to end identification MER-20261105-1187: transaction status ACCP, accepted for processing. Meridian Bank updates its tracker and tells Bright Logistics the payment is on its way.
Valid example from the message catalogue. Scheme rules: pacs.002 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 CBPR+ a pacs.002 must be sent for a rejected paymen
Bank-to-Bank: pacs.002, pacs.003, pacs.004, pacs.008, pacs.009 in Depth
What you will learn
Your objective. By the end of this lesson, you will be able to explain bank-to-bank: pacs.002, pacs.003, pacs.004, pacs.008, pacs.009. The pacs.008 message, FI to FI Customer Credit Transfer, is the most widely used message in cross border payments, and it carries a customer payment from the debtor bank to the creditor bank.
Why it matters. Returns must be processed promptly, because a return that sits unmatched can look like a missing payment, and a customer who is not told about a return may believe the supplier has been paid when the money is on its way back.
Chapter objective: Learner navigates the complete ISO 20022 catalogue, selecting the right message for each business scenario across payments, cash management, securities, and reporting. Learner practises this skill on realistic banking cases, explaining the reasoning clearly and using correct terminology throughout the work.
Key learning points
- FI to FI Customer Credit Transfer
- FI to FI Financial Institution Credit Transfer
- FI to FI Payment Status Report
- FI to FI Customer Direct Debit
- Pacs.004 message
Key terms
Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.
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.
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 XML explorer showing Bank-to-Bank: pacs.002, pacs.003, pacs.004, pacs.008, pacs.009 in Depth.
Practise this lesson
Exercise
Read the pacs.008 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 three levels of the message and name the field that carries the amount and the field that carries the end-to-end reference.
Correct result. The amount is carried in the instructed amount element and the reference in the end-to-end identification. The three levels are the group header, the payment information, and the credit transfer transaction information.
Why. A message is only useful if you can read it. The group header identifies the message, the payment information identifies the batch, and the transaction information carries the single payment.
Check your understanding
Practice question
Which of the following best describes bank-to-bank: pacs.002, pacs.003, pacs.004, pacs.008, pacs.009?
Takeaway and next step
What to remember
Returns must be processed promptly, because a return that sits unmatched can look like a missing payment, and a customer who is not told about a return may believe the supplier has been paid when the money is on its way back.
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 "Customer-to-Bank: pain.001, pain.002, pain.008 in Depth".
Transcript and full text
Show transcript
pacs.008 is the FI to FI customer credit transfer. It is the message a bank sends to another bank to carry a customer payment, and it is the ISO 20022 equivalent of the MT103. It is the most important bank to bank message, because it carries the majority of cross border customer payments. The pacs.008 has a group header, GrpHdr, which carries the message identification, MsgId, the creation date and time, CreDtTm, the number of transactions, NbOfTxs, the control sum, CtrlSum, the settlement information, SttlmInf, which states the settlement method, SttlmMtd, such as INDA, INGA, COVE, or CLRG, and the clearing system, ClrSys, and the instructing agent, InstgAgt, and the instructed agent, InstdAgt. It has one or more credit transfer transaction information blocks, CdtTrfTxInf, each carrying the payment identification, PmtId, with the instruction identification, InstrId, the end to end identification, EndToEndId, and the unique end to end transaction reference, UETR, the amount, Amt, with the instructed amount, InstdAmt, and the equivalent amount, EqvtAmt, the charge bearer, ChrgBr, the debtor, Dbtr, the debtor account, DbtrAcct, the debtor agent, DbtrAgt, the creditor agent, CdtrAgt, the creditor, Cdtr, the creditor account, CdtrAcct, the purpose, Purp, the remittance information, RmtInf, and the instruction for the next agent, InstrForNxtAgt. pacs.009 is the FI to FI payment. It is the message a bank sends to another bank for its own payment, not for a customer payment, and it is the ISO 20022 equivalent of the MT202. It has a group header, GrpHdr, and a credit transfer transaction information block, CdtTrfTxInf, which carries the payment identification, the amount, the debtor agent, the creditor agent, and the settlement information. pacs.009 has a COV variant, the FI to FI payment with cover, which is the equivalent of the MT202 COV. In the COV variant, the pacs.009 carries the underlying customer credit transfer information, UndrlygCstmrCdtTrf, which states the originator, the beneficiary, the amount, and the remittance information of the customer payment that the cover payment is funding. The COV variant is used in the cover method, where the instruction travels directly to the beneficiary bank as a pacs.008, and the funds travel through the correspondent chain as a pacs.009 COV. pacs.002 is the FI to FI payment status report. It is the message a bank sends to another bank to report the status of a payment. It has a group header, GrpHdr, and an original group information and status block, OrgnlGrpInfAndSts, and one or more transaction information and status blocks, TxInfAndSts. The status codes are ACCP, accepted, RJCT, rejected, ACSP, accepted settlement in process, ACSC, accepted settlement complete, ACCC, accepted and credited, and PART, partially accepted. The status reason information, StsRsnInf, carries the reason code, such as AC01 for an incorrect account number, AM04 for insufficient funds, AG01 for a transaction forbidden, RC01 for a bank identifier incorrect, and FF01 for an invalid file format. A pacs.002 with a status of RJCT and a reason code of AC01 tells the sending bank exactly why the payment was rejected, and the sending bank can then advise its customer. pacs.004 is the payment return. It is the message a bank sends to return a payment that was previously credited, because the beneficiary account is closed, the beneficiary is deceased, the payment was sent in error, or the beneficiary bank cannot apply the funds. The pacs.004 has a group header, GrpHdr, and an original group information block, OrgnlGrpInf, and a transaction information block, TxInf, which carries the original instruction identification, the original end to end identification, the returned amount, RtrdAmt, and the return reason information, RtrRsnInf, with the reason code, such as AC04 for a closed account number, AC06 for a blocked account, MD07 for a deceased beneficiary, AG01 for a transaction forbidden, and AM05 for a duplicate payment. The return is a reversal of the original payment, and it must carry the original references so the sending bank can match it to the original instruction. pacs.003 is the FI to FI customer direct debit. It is the message a bank sends to another bank to collect a direct debit from a customer. It has a group header, GrpHdr, and a direct debit transaction information block, DrctDbtTxInf, which carries the payment identification, the amount, the mandate related information, the creditor, the debtor, and the debtor agent. The pacs.003 is used in the SEPA direct debit scheme, where the creditor bank sends the collection to the debtor bank, and the debtor bank debits the debtor account. The pacs.003 is the bank to bank leg of a direct debit, and the pain.008 is the customer to bank leg. An SME must know both, because a direct debit has two legs, and the mandate must be identified in both. The settlement information in a pacs.008 is the field that states how the payment will be settled, and it is the field that distinguishes the serial method from the cover method. SttlmInf carries the settlement method, SttlmMtd, which may be INDA, instructed agent, meaning the instructed agent is to settle the payment, INGA, instructed agent, meaning the instructed agent is to settle the payment on behalf of the instructing agent, COVE, cover payment, meaning the payment is covered by a separate pacs.009, or CLRG, clearing system, meaning the payment will be settled through a clearing system. The settlement method is the ISO 20022 equivalent of the MT103 field 53a and field 72 codes, and it determines whether the funds travel with the instruction or separately. An SME must know the four codes, because they determine the settlement, and a wrong code will cause the payment to be settled incorrectly. The charge bearer in a pacs.008 is carried in the ChrgBr element, and it may be DEBT, meaning the debtor bears all charges, which is the OUR instruction, CRED, meaning the creditor bears all charges, which is the BEN instruction, SHAR, meaning the charges are shared, which is the SHA instruction, or SLEV, meaning the charges follow the service level agreement. The charge bearer determines who pays the charges, and it must match the agreement between the debtor and the creditor. A pacs.008 with ChrgBr DEBT and a deducted charge is an error, because DEBT means the beneficiary must receive the full amount, and any deduction is a breach of the instruction. The charge bearer is one of the most commonly misunderstood fields, and it is a common source of disputes between banks. For a business analyst, the pacs messages are the bank to bank interface. The analyst must be able to specify a pacs.008 that carries a customer payment with the correct settlement method and charge bearer, a pacs.009 that carries a bank payment or a cover payment, a pacs.002 that reports the status with the correct reason code, and a pacs.004 that returns a payment with the correct return reason. The analyst must know the group header, the transaction information block, and the settlement information, and must know which fields are mandatory and which are conditional. The analyst must also know the status codes and the reason codes, because they are the language the banks use to communicate about a payment.
pacs.008 is the FI to FI customer credit transfer. It is the message a bank sends to another bank to carry a customer payment, and it is the ISO 20022 equivalent of the MT103. It is the most important bank to bank message, because it carries the majority of cross border customer payments. The pacs.008 has a group header, GrpHdr, which carries the message identification, MsgId, the creation date and time, CreDtTm, the number of transactions, NbOfTxs, the control sum, CtrlSum, the settlement information, SttlmInf, which states the settlement method, SttlmMtd, such as INDA, INGA, COVE, or CLRG, and the clearing system, ClrSys, and the instructing agent, InstgAgt, and the instructed agent, InstdAgt. It has one or more credit transfer transaction information blocks, CdtTrfTxInf, each carrying the payment identification, PmtId, with the instruction identification, InstrId, the end to end identification, EndToEndId, and the unique end to end transaction reference, UETR, the amount, Amt, with the instructed amount, InstdAmt, and the equivalent amount, EqvtAmt, the charge bearer, ChrgBr, the debtor, Dbtr, the debtor account, DbtrAcct, the debtor agent, DbtrAgt, the creditor agent, CdtrAgt, the creditor, Cdtr, the creditor account, CdtrAcct, the purpose, Purp, the remittance information, RmtInf, and the instruction for the next agent, InstrForNxtAgt.
pacs.009 is the FI to FI payment. It is the message a bank sends to another bank for its own payment, not for a customer payment, and it is the ISO 20022 equivalent of the MT202. It has a group header, GrpHdr, and a credit transfer transaction information block, CdtTrfTxInf, which carries the payment identification, the amount, the debtor agent, the creditor agent, and the settlement information. pacs.009 has a COV variant, the FI to FI payment with cover, which is the equivalent of the MT202 COV. In the COV variant, the pacs.009 carries the underlying customer credit transfer information, UndrlygCstmrCdtTrf, which states the originator, the beneficiary, the amount, and the remittance information of the customer payment that the cover payment is funding. The COV variant is used in the cover method, where the instruction travels directly to the beneficiary bank as a pacs.008, and the funds travel through the correspondent chain as a pacs.009 COV.
pacs.002 is the FI to FI payment status report. It is the message a bank sends to another bank to report the status of a payment. It has a group header, GrpHdr, and an original group information and status block, OrgnlGrpInfAndSts, and one or more transaction information and status blocks, TxInfAndSts. The status codes are ACCP, accepted, RJCT, rejected, ACSP, accepted settlement in process, ACSC, accepted settlement complete, ACCC, accepted and credited, and PART, partially accepted. The status reason information, StsRsnInf, carries the reason code, such as AC01 for an incorrect account number, AM04 for insufficient funds, AG01 for a transaction forbidden, RC01 for a bank identifier incorrect, and FF01 for an invalid file format. A pacs.002 with a status of RJCT and a reason code of AC01 tells the sending bank exactly why the payment was rejected, and the sending bank can then advise its customer.
pacs.004 is the payment return. It is the message a bank sends to return a payment that was previously credited, because the beneficiary account is closed, the beneficiary is deceased, the payment was sent in error, or the beneficiary bank cannot apply the funds. The pacs.004 has a group header, GrpHdr, and an original group information block, OrgnlGrpInf, and a transaction information block, TxInf, which carries the original instruction identification, the original end to end identification, the returned amount, RtrdAmt, and the return reason information, RtrRsnInf, with the reason code, such as AC04 for a closed account number, AC06 for a blocked account, MD07 for a deceased beneficiary, AG01 for a transaction forbidden, and AM05 for a duplicate payment. The return is a reversal of the original payment, and it must carry the original references so the sending bank can match it to the original instruction.
pacs.003 is the FI to FI customer direct debit. It is the message a bank sends to another bank to collect a direct debit from a customer. It has a group header, GrpHdr, and a direct debit transaction information block, DrctDbtTxInf, which carries the payment identification, the amount, the mandate related information, the creditor, the debtor, and the debtor agent. The pacs.003 is used in the SEPA direct debit scheme, where the creditor bank sends the collection to the debtor bank, and the debtor bank debits the debtor account. The pacs.003 is the bank to bank leg of a direct debit, and the pain.008 is the customer to bank leg. An SME must know both, because a direct debit has two legs, and the mandate must be identified in both.
The settlement information in a pacs.008 is the field that states how the payment will be settled, and it is the field that distinguishes the serial method from the cover method. SttlmInf carries the settlement method, SttlmMtd, which may be INDA, instructed agent, meaning the instructed agent is to settle the payment, INGA, instructed agent, meaning the instructed agent is to settle the payment on behalf of the instructing agent, COVE, cover payment, meaning the payment is covered by a separate pacs.009, or CLRG, clearing system, meaning the payment will be settled through a clearing system. The settlement method is the ISO 20022 equivalent of the MT103 field 53a and field 72 codes, and it determines whether the funds travel with the instruction or separately. An SME must know the four codes, because they determine the settlement, and a wrong code will cause the payment to be settled incorrectly.
The charge bearer in a pacs.008 is carried in the ChrgBr element, and it may be DEBT, meaning the debtor bears all charges, which is the OUR instruction, CRED, meaning the creditor bears all charges, which is the BEN instruction, SHAR, meaning the charges are shared, which is the SHA instruction, or SLEV, meaning the charges follow the service level agreement. The charge bearer determines who pays the charges, and it must match the agreement between the debtor and the creditor. A pacs.008 with ChrgBr DEBT and a deducted charge is an error, because DEBT means the beneficiary must receive the full amount, and any deduction is a breach of the instruction. The charge bearer is one of the most commonly misunderstood fields, and it is a common source of disputes between banks.
For a business analyst, the pacs messages are the bank to bank interface. The analyst must be able to specify a pacs.008 that carries a customer payment with the correct settlement method and charge bearer, a pacs.009 that carries a bank payment or a cover payment, a pacs.002 that reports the status with the correct reason code, and a pacs.004 that returns a payment with the correct return reason. The analyst must know the group header, the transaction information block, and the settlement information, and must know which fields are mandatory and which are conditional. The analyst must also know the status codes and the reason codes, because they are the language the banks use to communicate about a payment.
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.