Key fields explained with examples

The Debtor field identifies the party who owes the money, and it contains the debtor name, postal address, and identification. For example, the debtor could be Acme Trading Ltd, with a structured address in London and a legal entity identifier. The Creditor field identifies the party who is owed the money, and it contains the same type of information for the supplier, for example Meridian Supplies Pte Ltd in Singapore. Both fields can also contain an Ultimate Debtor and an Ultimate Creditor, where the party on whose behalf the payment is made is different from the debtor or creditor. For example, a parent company may pay on behalf of a subsidiary, and the subsidiary is then the ultimate debtor. The Instructed Amount is the amount the debtor instructs to be transferred, with its currency, for example 10000 US dollars. The Interbank Settlement Amount is the amount that will actually be settled between banks, which may differ if charges are deducted or if a currency conversion occurs. The Charge Bearer, as already noted, determines who pays the charges. The Remittance Information can be unstructured, as free text such as Invoice 4567, or structured, as a set of elements that identify the invoice number, the invoice date, and the amount. Structured remittance information is preferred in ISO 20022 because it can be processed automatically by the creditor accounts payable system. Other key fields include the Payment Type Information, which contains the Service Level and the Category Purpose, the Purpose code, and the Regulatory Reporting details where required. The Service Level can indicate that the payment is urgent or that it should be processed under a specific scheme, such as SEPA. SWIFT gpi is a service and tracking initiative, not a scheme. The Category Purpose can indicate that the payment is for a salary, a pension, or a supplier payment. These codes help banks route the payment correctly and help regulators monitor payment flows. An analyst should know which codes are used in the relevant usage guideline, and should ensure that test data covers each code that the product supports. Take a worked example with real numbers. A pacs.008 for a SEPA supplier payment carries payment type information with service level SEPA, which means the payment follows the SEPA Credit Transfer scheme rulebook, and category purpose SUPP, which means it is a supplier payment. The purpose code is also SUPP, and the regulatory reporting field is empty, because no regulatory reporting is required for this payment. The remittance information is unstructured with the text Invoice INV-2026-1187, and the debtor has also provided a structured remittance with the invoice number, the invoice date and the amount, so the creditor can reconcile automatically. The service level, the category purpose and the purpose code together tell the clearing system, the creditor agent and the creditor exactly what kind of payment this is, and they drive the processing, the screening and the reconciliation. Failure and recovery: a service level code that the clearing system does not recognise is rejected with a pacs.002 and reason code AG01, and the sender must correct it and resend. A category purpose code that contradicts the purpose code, for example category purpose SALA for salary with purpose code SUPP for supplier payment, is flagged by the creditor agent and may be returned, because the inconsistency suggests the payment was built from the wrong template. A remittance information field longer than 140 characters is truncated or rejected, depending on the scheme, and the sender must shorten it. A regulatory reporting field that is mandatory for the corridor but left empty is rejected, and the sender must populate it. The recovery is to correct the field and resend with a new MsgId, because the payment has not yet been executed and no funds have moved. For a business analyst, product owner or subject matter expert, the test is to state, for every payment product, the service level, the category purpose, the purpose code and the remittance format, and to explain what each one drives. The service level selects the scheme and the processing rules. The category purpose selects the processing priority and the reporting category. The purpose code is used by the creditor for reconciliation and by the bank for screening and reporting. The remittance information must be in the format the creditor can reconcile, structured for automated matching and unstructured for human reading, and the requirement must state which one the product uses. Note that SWIFT gpi is a service and tracking initiative, not a scheme, so it is never named as a service level. Source: ISO 20022 pacs.008.001.08, Payment Type Information; EPC SCT Rulebook 2025. Last reviewed 7 November 2026.