What is a pacs.008 message?

A pacs.008 is the ISO 20022 FI to FI Customer Credit Transfer message, used to move a customer payment between financial institutions. It carries the debtor and creditor details, their agents (banks), the amount and currency, the settlement information, and a unique end-to-end reference and transaction id. It is the interbank message that a customer-initiated pain.001 typically becomes once it moves between banks, and its status is reported back in a pacs.002.

How do you write pacs.008 test cases?

Write pacs.008 test cases field by field: test each mandatory field present and valid, each mandatory field missing, each field at its boundary and just beyond, structured fields such as postal address and remittance, and code values such as currency and charge bearer. For each case assert the expected outcome, acceptance or a pacs.002 rejection with a specific reason code, and verify the downstream state. Cover the happy path, validation failures, and structural edge cases.

How is a pacs.008 rejection reported?

A pacs.008 rejection is reported with a pacs.002, the FI to FI Payment Status Report, carrying a group or transaction status of RJCT and a reason code that explains why, such as AC04 for a closed account or AC01 for an incorrect account. Test cases must assert the correct status and the specific reason code for each rejection scenario, because the reason code drives downstream handling and any customer-facing message.

What is the difference between pacs.008 and pain.001?

A pain.001 is the customer-to-bank Customer Credit Transfer Initiation, how a customer instructs their bank to make a payment. A pacs.008 is the bank-to-bank FI to FI Customer Credit Transfer that carries that payment between financial institutions. The pain.001 initiates; the pacs.008 settles it interbank. Test cases differ because the messages have different mandatory fields, different actors, and different validation, even though they represent the same underlying payment.

How to Write pacs.008 Test Cases for an ISO 20022 Migration

Q: What fields are mandatory in a pacs.008?

Core mandatory elements in a pacs.008 include the message identification, creation date and time, number of transactions, settlement information, the instruction and end-to-end identifiers and the UETR, the interbank settlement amount and currency, the debtor and creditor names and accounts, and the debtor and creditor agents identified by BIC. Exact mandatory status depends on the scheme and usage guidelines, so test cases must be written against the specific market practice in scope.

Writing pacs.008 test cases is field-by-field work: every mandatory element present and missing, every boundary, every structured component, and every code value, each asserting the right outcome and the matching pacs.002 response. An ISO 20022 migration is won or lost in this detail.

To write pacs.008 test cases, you go through the message field by field and design tests for each element being present and valid, missing, at its boundary, structurally malformed, and carrying each allowed code value, then assert the exact outcome for each: acceptance, or a pacs.002 rejection with a specific reason code, plus the resulting downstream state. The pacs.008 is the ISO 20022 FI to FI Customer Credit Transfer, the interbank message that carries a customer payment between banks, and an ISO 20022 migration succeeds or fails on whether your tests cover its mandatory fields, its structured data, and its rejection paths with this level of precision. Vague test cases like “send a valid pacs.008 and check it works” miss exactly the field-level defects that break real payments.

I have written and run these test packs through ISO 20022 cutovers, and the lesson is consistent: the defects hide in the fields, the IBAN that fails mod-97 validation, the creditor name over the scheme length limit, the structured address that the downstream bank requires but your system sent unstructured. This is detailed QA analyst and functional analyst work, and the domain knowledge that makes it possible is the subject of Break Into Banking.

What is a pacs.008 and how does it relate to a pain.001?

A pacs.008 is the bank-to-bank message that carries a customer credit transfer between financial institutions, while a pain.001 is the customer-to-bank message that initiates it. The same underlying payment is a pain.001 when the customer instructs their bank, and becomes a pacs.008 when it moves interbank. They are different messages with different actors, different mandatory fields, and different validation, so they need different test cases.

The pacs.008 carries the debtor and creditor, their agents (the banks, identified by BIC), the interbank settlement amount and currency, the settlement method, and the identifiers that track the payment: the instruction id, the end-to-end id, the transaction id, and the UETR that uniquely identifies the payment end to end. Its outcome is reported back in a pacs.002, the FI to FI Payment Status Report, which carries acceptance or a rejection with a reason code.

Understanding this relationship matters for test design because a payment’s lifecycle crosses both messages, and a complete test follows it across the boundary: a pain.001 in, transformed to a pacs.008 interbank, with a pacs.002 status returning and ultimately a pain.002 reaching the customer. The transformation between them is itself a rich source of defects, fields that map incorrectly or get dropped at the boundary. The distinction between these message families is the subject of PAIN vs pacs in ISO 20022, and testing the full crossing is the payment testing discipline.

How do you test the mandatory fields?

Test each mandatory field twice at minimum: once present and valid to confirm acceptance, and once missing or empty to confirm the message is rejected with the correct reason. Mandatory means the message must fail without it, and your test proves the system actually enforces that.

Work through the core mandatory elements: message identification, creation date and time, number of transactions, settlement information, the instruction and end-to-end identifiers and the UETR, the interbank settlement amount and currency, the debtor and creditor names and accounts, and the debtor and creditor agents by BIC. For each, the missing-field case should produce a pacs.002 with RJCT and a reason code indicating the missing or invalid element. Do not assume the system enforces mandatory status just because the spec says the field is mandatory; the entire point of the test is to confirm enforcement, and I have seen plenty of fields that were mandatory on paper and quietly optional in the code.

A critical caveat: exact mandatory status depends on the scheme and the market practice guidelines in scope, because ISO 20022 is a toolkit that each scheme constrains differently. Your test cases must be written against the specific usage guidelines for the rail you are migrating to, not against the base standard. Getting that mapping right is systems analysis and functional analysis, and the structured way to capture it is in Real-World BA Deliverables.

How do you test validation, boundaries, and code values?

Test validation by attacking each field’s rules at its edges: the formats, the lengths, the allowed code sets, and the cross-field constraints. This is boundary value analysis applied to a payment message, and it is where most field-level defects surface.

For the account, test a valid IBAN, an IBAN that fails mod-97 check-digit validation, and an account in a format the scheme does not accept. For the creditor name, test the maximum allowed length, one character over, and characters the downstream scheme rejects, because a name that is one character too long or contains an unsupported character is a real and common rejection. For the amount, test the smallest valid value, zero, a negative, an amount with more fraction digits than the currency allows, and a value over any scheme limit. For currency, test a supported ISO 4217 code, an unsupported one, and a malformed code. For coded fields like charge bearer or settlement method, test each valid code and an invalid one.

Field            Test value            Expected outcome
creditorName     70 chars              Accepted
creditorName     71 chars              pacs.002 RJCT, reason (length)
creditorAccount  invalid IBAN          pacs.002 RJCT, reason AC01/AC04 per scheme
amount           0.00                  pacs.002 RJCT, reason (amount)
amount           2 dp on JPY (0 dp)    pacs.002 RJCT, reason (currency/amount)
currency         "XYZ"                 pacs.002 RJCT, reason (currency)

Each row asserts a specific outcome and a specific reason code, not just “it rejects.” The reason code is the heart of the assertion, because it drives downstream handling and the customer message, and a rejection with the wrong code is still a defect. This systematic edge-attack is the core of negative test design, applied to a message standard.

How do you test structured data and the pacs.002 response?

Test the structured components, address, remittance information, agents, both in their structured and any permitted unstructured forms, because the move to structured data is one of the biggest sources of ISO 20022 migration defects. And for every case, assert the pacs.002 that reports the outcome, because the status report is how the result actually travels.

ISO 20022 favors structured data: a postal address broken into building number, street, town, and country rather than free-text lines; structured remittance with reference and amount detail. Test that your system produces and accepts the structured form correctly, that it handles the case where a downstream bank requires structured and you sent unstructured, and that long remittance information is handled rather than silently truncated. These structural cases are invisible to a test that only checks the amount and the accounts, and they are exactly where a migration breaks when a counterparty bank rejects a message your system thought was fine.

Then close every test with the pacs.002 assertion. Whether the case is acceptance or rejection, the result comes back as a pacs.002 with a status, ACCP or RJCT, and on rejection a reason code such as AC04 for a closed account or AC01 for an incorrect account. Assert the status and the exact reason code, and verify the downstream state matches, the database status, the customer message. Following the message all the way to its status report is the end-to-end discipline from You Don’t Understand the System Until You Test It, and the technical skills to run these checks across the flow are mapped in The Technical Skills Guide for BAs.

The takeaway

Writing pacs.008 test cases is field-by-field work: every mandatory element present and missing, every field at its boundary, every structured component in structured and unstructured form, and every code value, each asserting a specific outcome and the matching pacs.002 status and reason code. Write against the specific scheme usage guidelines in scope, not the base standard, and follow each case downstream to confirm the state and the customer message. An ISO 20022 migration is won in exactly this detail.

This is high-value, domain-deep work that few analysts can do well, which is what makes it worth building. Start with Break Into Banking for the domain and Real-World BA Deliverables for the test artifacts, or browse everything at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Software Testing, ISO 20022, Payments, QA, Banking