pain.001

pain.001 is the ISO 20022 message called the Customer Credit Transfer Initiation. A customer, usually a business, government body or payment service provider, sends it to its bank to instruct the bank to make one or more credit transfers from the customer's accounts. A single pain.001 file can contain anything from one urgent supplier payment to many thousands of salary payments. It is the standard format for corporate bulk payment files in Europe and is widely used by multinational companies and banks around the world.

The message belongs to the "pain" business area of ISO 20022, which covers payments initiation between customers and banks. After receiving it, the bank validates the file and reports back with a pain.002 status report, then executes the payments, typically by sending a pacs.008 into the relevant clearing system or correspondent chain. pain.001 thus sits at the very start of the payment chain.

A pain.001 is organised in three levels:

• Group header. One per file, with a unique message identifier, creation date and time, the total number of transactions, an optional control sum of all amounts, and the initiating party.
• Payment information. One or more blocks, each grouping payments that share the same debtor account, requested execution date and payment method. It includes the debtor, the debtor's account and bank, and optionally a charge bearer and a service level, such as SEPA or urgent.
• Credit transfer transaction information. One block per payment, with an end-to-end identification, the amount and currency, the creditor, the creditor's account and bank, and optional purpose codes, regulatory reporting data and remittance information.

This layout lets a company send one file with several batches, for example euro salaries from one account and dollar supplier payments from another, each with its own execution date. The end-to-end identification set by the company is carried through to later messages, which helps the company and the beneficiary match the payment, as described under payment reference.

Companies usually generate pain.001 files from their enterprise resource planning or accounts payable system, or from a treasury management system. Files are sent to banks through several channels:

• Bank portals. Uploading files to the bank's online banking platform.
• Host-to-host links. Secure file transfer connections between the company's systems and the bank's.
• Bank communication protocols. Standards such as EBICS, used widely in Germany, France and neighbouring countries.
• SWIFT. Large corporates can join SWIFT and send files to many banks through one connection.
• APIs. Some banks accept individual pain.001-style payloads through application programming interfaces.

ISO 20022 messages are updated over time, and pain.001 exists in several versions. Version 3 was used for many years, notably for SEPA Credit Transfers, and newer versions add elements such as structured addresses, legal entity identifiers and the unique end-to-end transaction reference. Because the standard allows many optional elements, banks publish implementation guides explaining exactly how they expect files to be filled in. Industry groups such as the Common Global Implementation initiative publish shared guidelines so that a company can use largely the same format with many banks, reducing the work of multi-bank connections.

Large groups sometimes use pain.001 for payments on behalf of subsidiaries, sending instructions from a central treasury entity while naming the subsidiary as the ultimate debtor. The standard has dedicated elements for such parties, so the beneficiary can still see which company in the group is paying.

Before ISO 20022, companies often had to produce a different file format for each bank and each country. A single, widely recognised XML format makes it easier to change banks, connect to several banks and automate the payment process end to end. Rich remittance fields allow invoice details to reach the supplier, while structured party information supports sanctions screening. When combined with pain.002 status reports and camt.053 statements, pain.001 enables straight-through processing from the creation of a payment to its reconciliation in the company's books.

Common problems include files rejected for schema or bank-specific validation errors, duplicate submissions, and missing or inconsistent data such as invalid account formats. Companies reduce these by validating files before sending, using unique message and payment identifiers, and monitoring pain.002 reports. Strong controls are also needed because a pain.001 is an instruction to move money: files should be generated from approved payment runs, protected against alteration in transit and authorised under maker-checker rules, as fraudsters target payment files through payment diversion fraud and compromised accounts.