pain.001ISO 20022

pain.001 — Customer Credit Transfer Initiation

Carries a customer's instruction to its payment service provider (PSP) to make one or more credit transfers. It is the customer-to-bank message that starts the payment: nothing has moved between banks yet, and no interbank settlement happens until the debtor agent turns the instruction into an interbank message such as pacs.008.

DIRECTION: Sent by the initiating party — the account owner or a party instructing on its behalf, such as a shared service centre — to the debtor agent (the PSP holding the account to be debited), sometimes via a forwarding agent.

Contributor Shubham Mathure16 July 2026

WHO IS INVOLVED

Initiating partyCreates the instruction and is accountable for its content. May be the debtor itself or a party authorised to instruct on the debtor's behalf.
DebtorThe account owner whose account will be debited. Often the same party as the initiating party, but not always.
Debtor agentReceives and validates the instruction, debits the debtor's account, and originates the interbank leg (for example a pacs.008).
Forwarding agentOptionally relays the instruction to the debtor agent without executing it — common in multi-bank corporate setups.

KEY FIELDS

This is a curated teaching subset — the full pain.001 message definition contains many more elements, rules, and code lists. Requirement flags summarise the single context named on each field; always check the official ISO 20022 message definition and the implementation guideline your bank or scheme actually applies.

Key fields of pain.001
FIELD	NAME	PRESENCE	WHAT IT MEANS
`GrpHdr/MsgId`	Message identification	MANDATORYBase ISO 20022 message definition	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	MANDATORYBase ISO 20022 message definition	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	MANDATORYBase ISO 20022 message definition	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	MANDATORYBase ISO 20022 message definition	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	MANDATORYBase ISO 20022 message definition	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	MANDATORYBase ISO 20022 message definition	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	OPTIONALBase ISO 20022 message definition	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	OPTIONALBase ISO 20022 message definition	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	MANDATORYBase ISO 20022 message definition	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	MANDATORYBase ISO 20022 message definition	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	MANDATORYBase ISO 20022 message definition	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	MANDATORYBase ISO 20022 message definition	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	MANDATORYBase ISO 20022 message definition	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	CONDITIONALBase ISO 20022 message definition — Amt is a choice between InstdAmt and EqvtAmt	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	MANDATORYEPC SEPA credit transfer customer-to-PSP implementation guidelines	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	MANDATORYEPC SEPA credit transfer customer-to-PSP implementation guidelines	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	OPTIONALBase ISO 20022 message definition	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	OPTIONALBase ISO 20022 message definition	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	OPTIONALBase ISO 20022 message definition	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.

FIELD BY FIELD — FULL STRUCTURE

The whole pain.001 laid out as a parent-child tree: every field in its nesting, with a sample value and what it means. Expand a branch to drill in. Values are fictional (SYNTHETIC / TRAINING ONLY); this is a curated practitioner view, not the full schema.

Document—The root of an ISO 20022 message — the business payload, which a Business Application Header (head.001) accompanies as a separate document.
- CstmrCdtTrfInitn—Customer Credit Transfer Initiation — the body of a pain.001: what a customer instructs their bank to pay.
  - GrpHdr—Group header — data that applies to the whole message: its identity, when it was created, how many transactions it carries, and shared settlement data.
    MsgIdDEMO-PAIN001-001MandatoryA unique reference for this message, assigned by the initiating party. It identifies the file or message itself, not the individual payments inside it.
    Use case
    Banks use MsgId as a first line of duplicate-file detection, so uniqueness matters across the sender's history, not just within a day.
    Example
    DEMO-PACS008-001
    Watch out
    Reusing a MsgId — for example after a resend of a corrected file — is a common cause of duplicate rejections or, worse, silently ignored files.
    CreDtTm2026-07-12T09:00:00ZMandatoryWhen the message was created. This is a timestamp for the instruction, separate from when the customer wants the payment executed.
    Use case
    Useful in investigations to reconstruct the order of events when several versions of a file were exchanged.
    Example
    2026-07-12T09:01:00Z
    NbOfTxs1MandatoryA control count of how many individual payment transactions the message contains.
    Use case
    Together with the optional control sum (CtrlSum), this lets the receiving bank check the file arrived intact before processing anything.
    Example
    <NbOfTxs>2</NbOfTxs>
    Watch out
    A mismatch between NbOfTxs and the actual transaction count usually rejects the whole file, not just one payment.
    CtrlSum1250.00Control sum — the total of all instructed amounts, a second control the receiver reconciles.
    Use case
    A second integrity check alongside NbOfTxs — the summed amounts must equal this figure.
    Example
    <CtrlSum>2500.00</CtrlSum>
    InitgPty—MandatoryWho created and sent the instruction. This can differ from the debtor — for example, a corporate treasury centre instructing payments from a subsidiary's account.
    NmDemo Trading LtdName — the free-text name of a party.
    Use case
    The name screening and verification-of-payee compare against; quality here directly affects whether a payment clears.
    Example
    <Nm>Demo Trading Ltd</Nm>
    Watch out
    A creditor name that doesn't match the account holder can trigger a name-check warning or return.
  - PmtInf—Payment Information — a batch of one or more payments in a pain.001 that share a debtor, a debit account, and an execution date.
    PmtInfIdDEMO-PMT-001MandatoryThe 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.
    Use case
    One pain.001 can carry several PmtInf blocks with different debit accounts or execution dates; each needs its own PmtInfId.
    Example
    DEMO-BATCH-001
    PmtMtdTRFMandatoryHow the payment should be made. For credit transfers this is the code TRF; the base standard also defines other methods such as cheques.
    Use case
    Rails that only support credit transfers, such as the SEPA schemes, restrict this to TRF in their implementation guidelines.
    Example
    <PmtMtd>TRF</PmtMtd>
    PmtTpInf—Payment Type Information — how the payment should be handled: its service level, local instrument, category purpose, and priority.
    InstrPrtyNORMInstruction Priority — the urgency the instructing party requests.
    Use case
    HIGH nudges the sending bank to process ahead of NORM traffic (a coarser signal than service level).
    Example
    NORM
    Codes
    see codes →
    SvcLvlchoice—Service Level — the rulebook or agreed service under which the payment runs (e.g. a SEPA scheme).
    CdSEPAOptionalThe 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.
    Use case
    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.
    Example
    SEPA
    Watch out
    Omitting or mis-stating the service level on a scheme rail can misroute the payment or fail scheme validation.
    Codes
    see codes →
    CtgyPurpchoice—Category Purpose — the high-level reason for the payment, used by the banks to apply processing/routing (e.g. salary, supplier).
    CdSUPPOptionalThe 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.
    Use case
    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.
    Example
    SUPP
    Watch out
    Do not confuse category purpose (bank-facing) with purpose (customer-facing) — they are different elements with overlapping code lists.
    Codes
    see codes →
    ReqdExctnDt—MandatoryThe 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.
    Dt2026-07-13Date — a calendar date value.
    Dbtr—MandatoryThe party whose account is debited — the payer.
    NmDemo Trading LtdName — the free-text name of a party.
    Use case
    The name screening and verification-of-payee compare against; quality here directly affects whether a payment clears.
    Example
    <Nm>Demo Trading Ltd</Nm>
    Watch out
    A creditor name that doesn't match the account holder can trigger a name-check warning or return.
    PstlAdr—Postal Address — the party's address; a fully structured address (street/town/country in separate elements) is preferred and, cross-border, becoming mandatory over unstructured lines.
    StrtNmBeispielstrasseStreet Name — the street, as a structured address element.
    Example
    <StrtNm>Beispielstrasse</StrtNm>
    BldgNb12Building Number — the building/house number, structured.
    Example
    <BldgNb>12</BldgNb>
    PstCd60311Post Code — the postal/ZIP code, structured.
    Example
    <PstCd>60311</PstCd>
    TwnNmFrankfurt am MainTown Name — the town or city, structured.
    Example
    <TwnNm>Frankfurt am Main</TwnNm>
    CtryDECountry — the ISO 3166 two-letter country code.
    Use case
    Mandatory even on an otherwise-unstructured address; used for routing and screening.
    Example
    <Ctry>DE</Ctry>
    DbtrAcct—MandatoryThe account to debit. In SEPA this is an IBAN (International Bank Account Number); other markets may use domestic account formats.
    Idchoice—Identification — a party or account identifier; for a party this is a choice of organisation id or private id.
    IBANDE02120300000000202051International Bank Account Number — the standardised account identifier used across SEPA and beyond.
    Use case
    Encodes country, bank, and account with a checksum, so a typo usually fails validation before it leaves.
    Example
    DE02120300000000202051
    DbtrAgt—MandatoryThe debtor's PSP — the bank being instructed. Usually identified by a BIC (Business Identifier Code).
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMODEFFXXXBusiness Identifier Code (financial institution) — the 8- or 11-character BIC naming a bank.
    Use case
    The primary way a bank is identified across the chain; 8 characters for the institution, 11 to name a branch.
    Example
    DEMODEFFXXX
    CdtTrfTxInf—MandatoryCredit Transfer Transaction Information — one individual payment: its identifiers, amount, parties, and remittance data.
    PmtId—Payment Identification — the set of references that identify this payment along the chain.
    EndToEndIdDEMO-E2E-001MandatoryThe 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.
    Use case
    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.
    Example
    DEMO-E2E-001
    Watch out
    Filling this with 'NOTPROVIDED' or an internal sequence number wastes the single best reconciliation field in the whole chain.
    Amt—Amount — the money being moved, as either an instructed amount or an equivalent amount.
    InstdAmt1250.00Ccy=EURConditionalThe 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'.
    Use case
    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.
    Example
    <InstdAmt Ccy="EUR">1250.00</InstdAmt>
    CdtrAgt—Creditor Agent — the creditor's bank, which credits the beneficiary at the end of the chain.
    FinInstnId—Financial Institution Identification — how a bank is identified, usually by its BIC.
    BICFIDEMOGB2LXXXBusiness Identifier Code (financial institution) — the 8- or 11-character BIC naming a bank.
    Use case
    The primary way a bank is identified across the chain; 8 characters for the institution, 11 to name a branch.
    Example
    DEMODEFFXXX
    Cdtr—MandatoryThe party being paid — the beneficiary.
    NmExample Supplies LtdName — the free-text name of a party.
    Use case
    The name screening and verification-of-payee compare against; quality here directly affects whether a payment clears.
    Example
    <Nm>Demo Trading Ltd</Nm>
    Watch out
    A creditor name that doesn't match the account holder can trigger a name-check warning or return.
    PstlAdr—Postal Address — the party's address; a fully structured address (street/town/country in separate elements) is preferred and, cross-border, becoming mandatory over unstructured lines.
    StrtNmSample RowStreet Name — the street, as a structured address element.
    Example
    <StrtNm>Beispielstrasse</StrtNm>
    BldgNb2Building Number — the building/house number, structured.
    Example
    <BldgNb>12</BldgNb>
    PstCdEC1A 1BBPost Code — the postal/ZIP code, structured.
    Example
    <PstCd>60311</PstCd>
    TwnNmLondonTown Name — the town or city, structured.
    Example
    <TwnNm>Frankfurt am Main</TwnNm>
    CtryGBCountry — the ISO 3166 two-letter country code.
    Use case
    Mandatory even on an otherwise-unstructured address; used for routing and screening.
    Example
    <Ctry>DE</Ctry>
    CdtrAcct—MandatoryThe account to credit — in SEPA, the beneficiary's IBAN.
    Idchoice—Identification — a party or account identifier; for a party this is a choice of organisation id or private id.
    IBANGB33BUKB20201555555555International Bank Account Number — the standardised account identifier used across SEPA and beyond.
    Use case
    Encodes country, bank, and account with a checksum, so a typo usually fails validation before it leaves.
    Example
    DE02120300000000202051
    Purpchoice—Purpose — the reason for the payment as stated by the debtor, carried unchanged to the creditor; informational, not for bank routing.
    CdSUPPOptionalThe 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.
    Use case
    Purpose (customer-to-customer) is distinct from category purpose (customer/bank-to-bank), even though both draw on similar 4-letter code lists.
    Example
    SUPP
    Codes
    see codes →
    RmtInf—Remittance Information — what the payment is for, so the creditor can reconcile it; either unstructured free text or structured references.
    UstrdDEMO INVOICE 1001OptionalFree-text detail about what the payment is for (e.g. an invoice note). Readable by a human but not reliably machine-parseable.
    Use case
    SEPA carries one unstructured occurrence of up to 140 characters.
    Example
    <Ustrd>DEMO INVOICE 1001</Ustrd>
    Watch out
    Remittance text is screened. Careless free text ('payment for Iran project') creates sanctions alerts that stop otherwise clean payments.
    Strd—OptionalMachine-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.
    CdtrRefInf—Creditor Reference Information — a structured reference the creditor supplied (e.g. an ISO 11649 RF reference) for automatic matching.
    Tp—Type — qualifies what kind of reference or code this is.
    CdOrPrtrychoice—Code or Proprietary — a choice between a standard code and a proprietary value.
    CdSCORCode — a value taken from a defined code list.
    RefRF18000000000000001001Reference — the reference value itself.

Sources for the field structure4

Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain/pacs/camt message-definition elements
Defines the current versions of all ISO 20022 message definitions, including the pain, pacs, and camt messages taught on this site. · Checked 2026-07-12
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
Official requirement
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · cross-border agent chain and structured-data usage
Defines how ISO 20022 messages (including pacs.008, pacs.009, pacs.002, pacs.004, and camt investigation messages) are used and validated for cross-border payments on the Swift network. · Checked 2026-07-12
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · FIN block structure
Defines the MT message standards (including MT101, MT103, MT202/202 COV, and the MT9xx statement messages) exchanged over the Swift FIN network, maintained through annual standards releases. · Checked 2026-07-12
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.
Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
This site's own simplified teaching models. · Checked 2026-07-12
What this simplifies: One-line plain-language descriptions of the commonly-populated elements — a practitioner view, not the authoritative ISO 20022 / MT schema, which defines many more optional elements.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.

COMMON ERRORS

Reusing a message or payment identification after correcting and resending a file.Consequence: The bank's duplicate controls reject the resend, or — depending on the bank — treat it as already processed and ignore it, so the corrected payments never execute.Avoid it: Generate a fresh MsgId for every physical message, track acknowledgements (pain.002) per MsgId, and keep the EndToEndId stable for the underlying business payment.
Leaving EndToEndId as 'NOTPROVIDED' or an internal counter.Consequence: The beneficiary cannot reconcile the credit, and any later status report, return, or recall is much harder to correlate with the original instruction.Avoid it: Populate EndToEndId with a meaningful business reference (for example an invoice or payment-run reference) and store it in your own records.
Instructing an execution date the bank cannot honour — a past date, weekend, or currency holiday.Consequence: Behaviour varies by bank: some roll the date forward silently, others reject the payment block, which surprises treasury teams expecting same-day execution.Avoid it: Validate ReqdExctnDt against business-day calendars before sending, and read the bank's channel documentation for its rolling policy rather than assuming.
Sending creditor data that fails the receiving scheme's requirements — missing IBAN, name mismatch, or address fragments in the wrong elements.Consequence: Rejection at the debtor agent, or repair fees and delays downstream once the instruction becomes an interbank message.Avoid it: Maintain beneficiary master data in structured form (name, structured address, IBAN, BIC where needed) and validate it against the target scheme's rules at capture time, not at send time.

USAGE CONTEXTS

SEPA credit transfer initiationThe European Payments Council (EPC) publishes customer-to-PSP implementation guidelines for pain.001 alongside the SEPA credit transfer rulebooks. The customer sends pain.001 to its PSP; the PSP converts accepted instructions into pacs.008 for the inter-PSP leg. Requirements in this context are stricter than the base standard — for example IBAN use.
Cross-border relay (CBPR+)CBPR+ — the usage guidelines for ISO 20022 payments exchanged over the Swift network — also defines usage of pain.001 between financial institutions, where one institution forwards a customer's instruction to another institution that will execute it. The interbank movement still happens in pacs messages.
Corporate-to-bank channels generallyMany banks accept pain.001 over host-to-host and API channels outside any scheme context. Field requirements, character set rules, and duplicate controls vary noticeably between banks, so a file accepted by one bank may be rejected by another.

SEE IT IN A PLAYABLE FLOW

Sources for this reference4

Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain.001 CustomerCreditTransferInitiation message definition
Defines the current versions of all ISO 20022 message definitions, including the pain, pacs, and camt messages taught on this site. · Checked 2026-07-12
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
Scheme-specific rule2025 version 1.0 (EPC115-06)
SEPA Credit Transfer Inter-PSP Implementation Guidelines ↗ — European Payments Council · Customer-to-PSP implementation guidelines for SEPA credit transfers
Specifies how the ISO 20022 inter-PSP messages (pacs and camt) are used to implement the 2025 SCT rulebook between scheme participants. · Effective 2025-10-05 · Checked 2026-07-12
Based on version 1.1 of the 2025 SCT rulebook. Companion Customer-to-PSP guidelines cover the pain.001 initiation leg.
Scheme-specific rule
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · pain.001 usage guideline
Defines how ISO 20022 messages (including pacs.008, pacs.009, pacs.002, pacs.004, and camt investigation messages) are used and validated for cross-border payments on the Swift network. · Checked 2026-07-12
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
This site's own simplified teaching models. · Checked 2026-07-12
What this simplifies: The key-field list is a curated subset chosen for teaching, not the full element catalogue. Requirement flags summarise one named context per field and compress differences between pain.001 versions and between bank-specific profiles. Actor descriptions omit less common constellations such as ultimate debtors and creditors.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.