Payment File Formats and ISO 20022

Why This Topic Matters for the CTP Exam

Payment file formats sit at the intersection of two major CTP domains: Technology in the Treasury Function and Payment Systems. Every disbursement a company makes, every collection it receives, and every balance report it pulls from a bank travels in a structured electronic format. Treasury professionals who understand these formats can achieve straight-through processing (STP), reduce payment repairs and rejections, reconcile faster, and migrate smoothly as the global financial system moves to ISO 20022.

The AFP tests this topic because the industry is in the middle of a historic transition. SWIFT, the Federal Reserve (Fedwire), The Clearing House (CHIPS, RTP), the Eurosystem (T2), and dozens of other market infrastructures have adopted or are adopting ISO 20022. A treasury professional who cannot explain the difference between a pain.001 and a camt.053, or who does not understand why structured remittance data matters, is behind the curve. Expect roughly two to four exam questions that touch directly on formats, standards bodies, or ISO 20022 message types, plus several more that assume you understand the concepts.

What Payment File Formats Are

A payment file format is a standardized layout that tells a bank or clearing system exactly where to find each piece of information in an electronic instruction: who is paying, who is being paid, how much, in what currency, through which accounts, on what date, and for what purpose. Formats also govern the reverse flow of information from banks to companies, such as balance reports, transaction detail, acknowledgments, and rejections.

Formats fall into a few broad families you should recognize:

1. Proprietary bank formats. Historically each bank designed its own file layouts. These work well with a single bank but force a corporate with ten banks to maintain ten different file specifications. This fragmentation is the core problem that open standards try to solve.

2. Fixed-width or flat-file formats. Data is placed in predetermined character positions. The classic example is the Nacha ACH file format, built on 94-character records (File Header, Batch Header, Entry Detail, Addenda, Batch Control, File Control). Addenda records carry limited remittance data, often using a subset of EDI syntax. Another example is BAI2 (now owned and maintained by the Accredited Standards Committee X9 as the BTRS, Balance and Transaction Reporting Standard), used in the United States for prior-day and intraday bank balance and transaction reporting.

3. Electronic Data Interchange (EDI) standards. ANSI ASC X12 dominates in North America. Key transaction sets you should know: 820 (Payment Order/Remittance Advice), 822 (Account Analysis), 823 (Lockbox), 835 (Health Care Claim Payment), and 997 (Functional Acknowledgment). UN/EDIFACT is the international equivalent used widely outside North America, with messages such as PAYMUL (multiple payment order), REMADV (remittance advice), and FINSTA (financial statement). EDI uses delimited segments and data elements rather than fixed positions, which makes it more compact but harder to read by eye.

4. SWIFT MT (Message Type) formats. The legacy SWIFT FIN messages use a numbered convention. Category 1 covers customer payments: MT101 (Request for Transfer, sent by a corporate to its bank), MT103 (Single Customer Credit Transfer, bank to bank). Category 2 covers financial institution transfers: MT202 and MT202 COV. Category 9 covers cash management and reporting: MT940 (end-of-day statement), MT942 (intraday statement), MT900/MT910 (debit/credit confirmations). MT messages are field-based with tight character limits (for example, four lines of 35 characters for remittance information), which is their chief weakness.

5. ISO 20022 XML. The modern, globally harmonized standard described in detail below.

What ISO 20022 Is

ISO 20022 is an international standard for financial messaging published by the International Organization for Standardization. It is best understood not as a single message format but as a methodology with three layers:

Business process and concepts layer. A common vocabulary describing payments, securities, trade, cards, and foreign exchange activities independent of technology.

Logical message layer (the data dictionary). A repository of reusable business components such as Party, Account, Amount, and Remittance Information. Because every message draws from the same dictionary, a debtor name means the same thing in a payment initiation as it does in a bank statement.

Syntax layer. How the message is physically expressed. Today this is almost always XML (Extensible Markup Language), which uses human-readable tags such as InstdAmt for Instructed Amount or Cdtr for Creditor. The standard also permits other syntaxes such as JSON and ASN.1, but XML is what the exam expects.

Messages are identified by a business area code, a three-digit message number, and a version number. The naming pattern is area.number.version, for example pain.001.001.09. You must know the main business areas:

pain (Payment Initiation): corporate-to-bank messages.
- pain.001 Customer Credit Transfer Initiation (the ISO equivalent of MT101, Nacha credit files, or an X12 820 for outbound payments). Used for ACH, wires, and instant payments.
- pain.002 Customer Payment Status Report (acknowledgment, acceptance, or rejection of the pain.001 or pain.008).
- pain.008 Customer Direct Debit Initiation (collections such as SEPA Direct Debit or ACH debits).

pacs (Payments Clearing and Settlement): bank-to-bank and bank-to-market-infrastructure messages.
- pacs.008 FI to FI Customer Credit Transfer (replaces MT103).
- pacs.009 Financial Institution Credit Transfer (replaces MT202).
- pacs.002 FI to FI Payment Status Report.
- pacs.004 Payment Return.

camt (Cash Management): bank-to-corporate reporting and account messages.
- camt.052 Bank to Customer Account Report (intraday, replaces MT942).
- camt.053 Bank to Customer Statement (end-of-day, replaces MT940 and BAI2 prior-day).
- camt.054 Bank to Customer Debit/Credit Notification (replaces MT900/910 and provides detailed remittance for incoming items).
- camt.086 Bank Services Billing Statement (the ISO successor to the X12 822 and the TWIST BSB standard for account analysis).
- camt.029 and camt.056 used in payment investigations and cancellation requests.

Other areas you may see mentioned include acmt (account management, such as electronic bank account management or eBAM), remt (stand-alone remittance advice, remt.001), head (business application header), and securities areas such as sese and semt.

How ISO 20022 Works in Practice

Consider a corporate paying a supplier in another country:

1. The ERP or treasury management system (TMS) generates a pain.001 containing the debtor, debtor agent (the company bank, identified by BIC), creditor, creditor agent, amount, currency, requested execution date, purpose code, and structured remittance information (invoice numbers, amounts, discount taken).
2. The file is transmitted to the bank over a secure channel: host-to-host SFTP, a SWIFT connection (via SWIFT for Corporates / SCORE, a service bureau, or Alliance Lite2), an API, or a bank portal upload.
3. The bank validates the file and returns a pain.002 indicating acceptance or giving a reason code for rejection (for example, invalid IBAN).
4. The bank converts the instruction into a pacs.008 and sends it to the beneficiary bank, either directly over SWIFT or through a market infrastructure such as Fedwire, CHIPS, or T2.
5. The beneficiary bank credits its customer and sends a camt.054 notification with the full remittance data intact, allowing the supplier to auto-apply cash to open receivables.
6. At end of day both companies receive a camt.053 statement that their TMS ingests for automated reconciliation.

The critical point is that the same structured data survives end to end. In the legacy world, data was truncated or lost at each hop as it was converted among Nacha, MT, and proprietary formats.

Key Benefits of ISO 20022 You Should Be Able to Articulate

Richer, structured data. Dedicated fields for structured addresses, Legal Entity Identifiers (LEIs), purpose codes, and ultimate debtor/creditor replace free-text lines. This improves sanctions screening accuracy (fewer false positives), fraud detection, and regulatory reporting.

Enhanced remittance information. Far more remittance capacity than MT or Nacha, enabling automated cash application and shrinking days sales outstanding (DSO).

Interoperability and bank agnosticism. One format works across many banks and countries, reducing the cost of maintaining proprietary interfaces and making it easier to change banks.

Higher STP rates. Fewer repairs, fewer manual investigations, lower bank fees for exception handling.

Extended character set. Supports non-Latin characters needed in many markets.

Foundation for real-time payments. Instant payment systems worldwide, including FedNow, RTP in the US, SEPA Instant, and UK Faster Payments (New Payments Architecture), are built on ISO 20022 from the start.

Challenges and Implementation Considerations

Even with a global standard, variations exist. Each market infrastructure and bank publishes usage guidelines that restrict or require certain fields. To combat this fragmentation, the Common Global Implementation Market Practice (CGI-MP) group, composed of corporates, banks, and vendors, publishes harmonized corporate-to-bank templates for pain.001, pain.002, camt.052/053/054, and others. Treasurers should ask banks whether they support CGI-MP guidelines.

Other practical hurdles include larger file sizes (XML is verbose), the need to upgrade ERP and TMS systems, data cleansing to populate structured addresses, mapping legacy codes to ISO external code lists, testing across all banks, and training accounts payable and receivable staff. Many corporates use middleware, a TMS, or a bank or SWIFT translation service to convert legacy formats during the transition.

Migration Timeline Facts Worth Memorizing

- SEPA credit transfers and direct debits have required ISO 20022 (pain.001, pain.008) since the scheme launched in 2008, making Europe the earliest large-scale adopter.
- SWIFT cross-border payments (CBPR+): coexistence period for MT and ISO (MX) began March 2023 and ends in November 2025, after which MT category 1, 2, and 9 payment messages are retired for interbank traffic. Corporate-to-bank MT101 and MT940 continue to be supported by SWIFT beyond that date, though banks are encouraging migration.
- Eurosystem T2 (successor to TARGET2) went live on ISO 20022 in March 2023.
- CHIPS migrated in April 2024.
- Fedwire Funds Service migrated in a single-day cutover on July 14, 2025.
- RTP (2017) and FedNow (2023) were ISO 20022 native from launch.
- Fully structured or hybrid postal addresses become mandatory in cross-border payments by November 2026.

Exam Tips: Answering Questions on Payment File Formats and ISO 20022

Tip 1: Master the message-family mapping. The single most testable fact set is pain = corporate initiates, pacs = banks clear and settle, camt = banks report. If a question describes a company sending instructions, the answer is in the pain family. If it describes a bank statement or notification, think camt. If it involves bank-to-bank or clearing house traffic, think pacs.

Tip 2: Know the legacy-to-ISO equivalents. MT101 to pain.001, MT103 to pacs.008, MT202 to pacs.009, MT940 to camt.053, MT942 to camt.052, MT900/910 to camt.054, X12 822 and BAI2 account analysis to camt.086, BAI2 balance reporting to camt.052/053. Questions often give you one and ask for the other.

Tip 3: Distinguish standards bodies. ANSI ASC X12 (North American EDI), UN/EDIFACT (international EDI), Nacha (US ACH operating rules and file format), ASC X9 (BTRS/BAI balance reporting), SWIFT (MT messages and the registration authority for ISO 20022), ISO (owner of the 20022 standard), CGI-MP (harmonized corporate-to-bank guidelines). If asked who maintains ISO 20022, the standard is owned by ISO; SWIFT serves as Registration Authority.

Tip 4: Remember the 820. When a question mentions a payment order combined with remittance advice in a US EDI context, the X12 820 is almost always the answer. The 835 is specific to health care. The 823 is lockbox. The 822 is account analysis. The 997 is an acknowledgment.

Tip 5: Focus on the business benefit, not just the technology. The CTP is a management exam. When a scenario asks why a treasurer would push for ISO 20022, the best answers emphasize STP, automated cash application, reduced exceptions and fees, better sanctions screening, bank independence, and support for real-time payments. Avoid answers that focus purely on XML syntax.

Tip 6: Watch for the word structured. Structured remittance, structured address, and structured party identification are hallmark ISO 20022 concepts. Legacy formats are characterized by free-text, truncation, and character limits.

Tip 7: Do not confuse format with channel. A format (pain.001, Nacha, MT101) is the content layout. A channel or connectivity method (SWIFT, host-to-host SFTP, API, bank portal) is how it is transported. Questions sometimes mix these as distractors. SWIFT is a network and messaging service; ISO 20022 is a standard that can travel over SWIFT or many other networks.

Tip 8: Use elimination on timeline questions. If a question asks which system is ISO 20022 native, instant payment systems (RTP, FedNow, SEPA Instant) are the safe choice. If asked which system completed migration most recently, think Fedwire in 2025. Europe (SEPA and T2) always precedes the United States.

Tip 9: Know what a pain.002 does. A frequent distractor is to describe a status report or rejection and offer pain.001 as the answer. The pain.001 initiates; the pain.002 reports status back. Likewise pacs.002 reports status for pacs messages, and pacs.004 is a return.

Tip 10: Connect to adjacent CTP topics. ISO 20022 appears in questions about bank connectivity (SWIFT for Corporates), TMS and ERP integration, electronic bank account management (acmt messages), real-time payments, cross-border payments and sanctions compliance, and receivables automation. If a question seems to be about cash application efficiency or lockbox versus electronic remittance, consider whether rich ISO 20022 remittance data is the underlying point.

Quick Review Checklist

- ISO 20022: global financial messaging standard, XML syntax, common data dictionary, owned by ISO, SWIFT as Registration Authority.
- Three business areas to know cold: pain (initiation), pacs (clearing and settlement), camt (cash management reporting).
- Core messages: pain.001, pain.002, pain.008, pacs.008, pacs.009, camt.052, camt.053, camt.054, camt.086.
- Legacy formats: Nacha (94-character records), BAI2/BTRS, ANSI X12 (820, 822, 823, 835, 997), UN/EDIFACT (PAYMUL, REMADV), SWIFT MT (101, 103, 202, 940, 942, 900/910).
- Benefits: rich structured data, better remittance, STP, interoperability, compliance, real-time readiness.
- Challenges: bank-specific variations (mitigated by CGI-MP), system upgrades, data quality, file size, testing.
- Milestones: SEPA 2008, T2 March 2023, SWIFT coexistence through November 2025, CHIPS April 2024, Fedwire July 2025, structured addresses November 2026.

Study this guide alongside your payment systems chapter, and you will be well prepared to handle any format or ISO 20022 question the CTP exam presents.