pain.001 customer initiation

EVERY ANNOTATED FIELD

GrpHdr/MsgId Message identification — mandatory

A unique reference for this message, assigned by the initiating party. It identifies the file or message itself, not the individual payments inside it.

Banks use MsgId as a first line of duplicate-file detection, so uniqueness matters across the sender's history, not just within a day.

⚠ Reusing a MsgId — for example after a resend of a corrected file — is a common cause of duplicate rejections or, worse, silently ignored files.

GrpHdr/CreDtTm Creation date and time — mandatory

When the message was created. This is a timestamp for the instruction, separate from when the customer wants the payment executed.

Useful in investigations to reconstruct the order of events when several versions of a file were exchanged.

GrpHdr/NbOfTxs Number of transactions — mandatory

A control count of how many individual payment transactions the message contains.

Together with the optional control sum (CtrlSum), this lets the receiving bank check the file arrived intact before processing anything.

⚠ A mismatch between NbOfTxs and the actual transaction count usually rejects the whole file, not just one payment.

GrpHdr/InitgPty Initiating party — mandatory

Who created and sent the instruction. This can differ from the debtor — for example, a corporate treasury centre instructing payments from a subsidiary's account.

The distinction between initiating party and debtor matters for entitlement checks: the bank must verify the initiating party is authorised over the debtor's account.

PmtInf/PmtInfId Payment information identification — mandatory

The sender's reference for this batch of payments (the PmtInf block). It identifies the group, not the individual payment; a pain.002 status report quotes it back so you can locate which batch a status refers to.

One pain.001 can carry several PmtInf blocks with different debit accounts or execution dates; each needs its own PmtInfId.

PmtInf/PmtMtd Payment method — mandatory

How the payment should be made. For credit transfers this is the code TRF; the base standard also defines other methods such as cheques.

Rails that only support credit transfers, such as the SEPA schemes, restrict this to TRF in their implementation guidelines.

PmtInf/PmtTpInf/SvcLvl/Cd Service level code — optional

The rulebook or agreed service the payment runs under, as a 4-letter code — e.g. SEPA for a SEPA scheme payment. It tells every bank which rulebook's obligations and timings apply.

Service level answers 'under which scheme'; local instrument narrows 'which variant'; category purpose says 'what kind of payment'. See the code reference for the full list.

⚠ Omitting or mis-stating the service level on a scheme rail can misroute the payment or fail scheme validation.

PmtInf/PmtTpInf/CtgyPurp/Cd Category purpose code — optional

The high-level kind of payment, as a 4-letter code (e.g. SUPP supplier, SALA salary), used by the banks to apply special handling or routing.

Category purpose is for the banks in the chain; the separate Purpose (Purp) code is for the creditor. Some scheme values (e.g. SALA) trigger specific processing.

⚠ Do not confuse category purpose (bank-facing) with purpose (customer-facing) — they are different elements with overlapping code lists.

PmtInf/ReqdExctnDt Requested execution date — mandatory

The date the debtor asks the bank to execute the payment — in practice, the day the debit should happen. Newer message versions allow either a date or a full date-time.

Banks typically warehouse instructions with a future execution date and validate the date against currency and scheme calendars.

⚠ A past date or a non-business day is handled differently by different banks — some roll forward, some reject. Do not assume one behaviour.

PmtInf/Dbtr Debtor — mandatory

The party whose account is debited — the payer.

Debtor name and address quality directly affects sanctions screening downstream, because this data is copied into the interbank pacs.008.

PmtInf/DbtrAcct Debtor account — mandatory

The account to debit. In SEPA this is an IBAN (International Bank Account Number); other markets may use domestic account formats.

⚠ An account the initiating party is not entitled to instruct on is a common rejection reason that looks like a data error but is really an authorisation problem.

PmtInf/DbtrAgt Debtor agent — mandatory

The debtor's PSP — the bank being instructed. Usually identified by a BIC (Business Identifier Code).

In multi-bank files routed through a forwarding agent, DbtrAgt tells the relay where each payment block must ultimately go.

CdtTrfTxInf/PmtId/EndToEndId End-to-end identification — mandatory

The reference the debtor assigns to this payment. It is meant to travel unchanged through every leg of the chain, all the way to the creditor.

This is the reference the beneficiary can use to reconcile the credit against an invoice, and the reference operations teams use to correlate status reports and returns.

⚠ Filling this with 'NOTPROVIDED' or an internal sequence number wastes the single best reconciliation field in the whole chain.

CdtTrfTxInf/Amt/InstdAmt Instructed amount — conditional

The amount and currency the customer instructs, before any charges or currency conversion. The alternative, equivalent amount (EqvtAmt), instructs 'whatever amount in the target currency equals this amount in my currency'.

In SEPA the instructed amount is in euro. In cross-border use, InstdAmt can differ from the interbank settlement amount that later appears in pacs.008.

CdtTrfTxInf/Cdtr Creditor — mandatory

The party being paid — the beneficiary.

The base standard leaves more of the creditor side optional than any real rail does; the implementation guideline in force decides what you must supply.

⚠ A creditor name that does not match the account holder can trigger verification-of-payee warnings or beneficiary-side rejections.

CdtTrfTxInf/CdtrAcct Creditor account — mandatory

The account to credit — in SEPA, the beneficiary's IBAN.

⚠ A syntactically valid IBAN can still belong to a closed or wrong account; syntax validation is not delivery assurance.

CdtTrfTxInf/Purp/Cd Purpose code — optional

The reason for the payment as stated by the debtor (e.g. SUPP for a supplier payment), carried unchanged to the creditor. It is informational — the creditor's ERP can auto-post on it — and is not used by the banks to route.

Purpose (customer-to-customer) is distinct from category purpose (customer/bank-to-bank), even though both draw on similar 4-letter code lists.

CdtTrfTxInf/RmtInf/Ustrd Unstructured remittance information — optional

Free-text detail about what the payment is for (e.g. an invoice note). Readable by a human but not reliably machine-parseable.

SEPA carries one unstructured occurrence of up to 140 characters.

⚠ Remittance text is screened. Careless free text ('payment for Iran project') creates sanctions alerts that stop otherwise clean payments.

CdtTrfTxInf/RmtInf/Strd Structured remittance information — optional

Machine-readable references — most commonly a structured creditor reference (e.g. an ISO 11649 RF reference) — that let the creditor's system auto-match the payment to an invoice.

Structured references survive automated reconciliation far better than free text; many corporates mandate them.

⚠ Mixing a structured reference into the unstructured field defeats auto-reconciliation — put it in Strd, not Ustrd.