GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX
PAYMENTSSIGNAL

The interactive academy for the standards, messages, and rails that move money.

PROGRESS
ANNOTATED SAMPLE

pain.002 customer payment status

A fictional transaction-level rejection linked back to a pain.001 instruction.

Contributor Shubham Mathure

Illustrative, non-production example. Values are fictional and the message is not validated for any specific network, scheme, or implementation guide.

EVIDENCE AT ARM'S REACH

DOWNLOAD AND GOVERNING SOURCES

Download the canonical fictional sample, then open the exact official definition and profile needed for implementation testing.

An XSD checks XML structure. A usage guideline adds profile rules, conditional fields, code restrictions, and business controls. XSD-valid does not mean scheme-compliant.

XSD + definitionBase ISO 20022current

ISO 20022 message definitions and XSDs

Choose the exact message definition in the official catalogue. The base XSD checks XML structure; it does not prove compliance with a scheme profile.

Owner
ISO 20022 Registration Authority
Checked
2026-07-12
Access
Official page · Public official catalogue; select the required message version before downloading.
OPEN OFFICIAL SOURCE
Usage guidelineCBPR+current

CBPR+ usage guidelines

The network profile that restricts how ISO 20022 payment and reporting messages are used for cross-border traffic.

Owner
Swift (CBPR+ working group)
Version
Standards Release 2025
Checked
2026-07-19
Access
Login required · Full message-level guidelines require the relevant Swift MyStandards access.
VERSION TRACK
  • upcomingStandards Release 2026
    Published
    2026-03-20
    Effective
    2026-11-14
    Supersedes
    Standards Release 2025
    Access
    Login required
    Checked
    2026-07-19

    Adds the November 2026 validation and structured-address changes; implement against the final SR2026 usage guidelines.

    Final usage guidelines are published through MyStandards; the public release page gives the implementation timeline.

    Open version source
OPEN OFFICIAL SOURCE
RulebookSEPA SCTcurrent

SEPA Credit Transfer rulebook

The current scheme obligations, datasets, time cycles, and exception rules for a SEPA Credit Transfer.

Owner
European Payments Council
Version
2025 version 1.1 (EPC125-05)
Checked
2026-07-12
Access
Official page · Public EPC document page; confirm the effective version for the planned go-live date.
OPEN OFFICIAL SOURCE
Usage guidelineSEPA SCTcurrent

SEPA Credit Transfer implementation guidelines

The EPC profile describing how the ISO 20022 messages implement the SCT rulebook between payment service providers.

Owner
European Payments Council
Version
2025 version 1.0 (EPC115-06)
Checked
2026-07-12
Access
Official page · Public EPC document page; customer-to-PSP and inter-PSP guidance are separate documents.
OPEN OFFICIAL SOURCE
Usage guidelineSEPA SCT Instcurrent

SEPA Instant Credit Transfer implementation guidelines and XSDs

Customer-to-PSP and Inter-PSP profiles for SCT Inst. EPC XSDs are technical validation subsets, not production artefacts or proof of full scheme compliance.

Owner
European Payments Council
Version
2025 version 1.0
Checked
2026-07-19
Access
Official page · Public EPC scheme page with owner-hosted guideline and XSD downloads.
OPEN OFFICIAL SOURCE
Teaching sampleScheme-neutral teachingcurrent

pain.002 customer payment status — raw XML

A fictional transaction-level rejection linked back to a pain.001 instruction. SYNTHETIC / TRAINING ONLY; illustrative unvalidated.

Owner
Payments Signal
Version
pain.002.001.10
Checked
2026-07-19
Integrity
crc32:5dfa592a
Access
Payments Signal download · Original fictional teaching sample; no login required.
DOWNLOAD
Lifecycle packScheme-neutral teachingcurrent

Corporate MX positive lifecycle — ZIP pack

Initiation, customer and interbank status, payment, notification, intraday report, and statement.

Owner
Payments Signal
Checked
2026-07-19
Integrity
crc32:705aa0af
Access
Payments Signal download · Original fictional teaching pack; no login required.
DOWNLOAD
Field matrixBase ISO 20022current

pain.002 field matrix

Curated field requirements, contexts, operational meaning, and implementation cautions.

Owner
Payments Signal
Checked
2026-07-19
Integrity
crc32:5c054063
Access
Payments Signal download · Original, source-backed teaching asset; no login required.
DOWNLOAD
Profile packCBPR+current

CBPR+ implementation pack

Generated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.

Owner
Payments Signal
Checked
2026-07-19
Integrity
crc32:9d2559ed
Access
Payments Signal download · Original generated teaching pack; no login required.
DOWNLOAD
Profile packSEPA SCTcurrent

SEPA credit-transfer implementation pack

Generated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.

Owner
Payments Signal
Checked
2026-07-19
Integrity
crc32:39e4ef6d
Access
Payments Signal download · Original generated teaching pack; no login required.
DOWNLOAD
Profile packSEPA SDD Corecurrent

SEPA direct-debit implementation pack

Generated mapping, field-matrix, test, checklist, acceptance-criteria, migration, manifest, checksum, and source-inventory bundle.

Owner
Payments Signal
Checked
2026-07-19
Integrity
crc32:458732a2
Access
Payments Signal download · Original generated teaching pack; no login required.
DOWNLOAD
pain.002
<?xml version="1.0" encoding="UTF-8"?>
<!-- SYNTHETIC / TRAINING ONLY — illustrative non-production data -->
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.10">
  <CstmrPmtStsRpt>
    <GrpHdr>


      <InitgPty><Nm>Demo Bank</Nm></InitgPty>
    </GrpHdr>
    <OrgnlGrpInfAndSts>


      <GrpSts>PART</GrpSts>
    </OrgnlGrpInfAndSts>
    <OrgnlPmtInfAndSts>
      <OrgnlPmtInfId>DEMO-PMT-001</OrgnlPmtInfId>
      <TxInfAndSts>
        <OrgnlEndToEndId>DEMO-E2E-001</OrgnlEndToEndId>
        <TxSts>RJCT</TxSts>
        <StsRsnInf>
          <Rsn><Cd>AC01</Cd></Rsn>
          <AddtlInf>Illustrative account-identifier rejection</AddtlInf>
        </StsRsnInf>
      </TxInfAndSts>
    </OrgnlPmtInfAndSts>
  </CstmrPmtStsRpt>
</Document>

EVERY ANNOTATED FIELD

GrpHdr/MsgId Message identification — mandatory

A unique reference for this status report itself, assigned by the bank sending it.

Distinct from the original message's identification — a single pain.001 can generate several pain.002 messages over its life as statuses evolve.

GrpHdr/CreDtTm Creation date and time — mandatory

When this status report was created. Ordering matters when several reports about the same file arrive.

⚠ Processing status reports out of order can overwrite a final status with an earlier interim one.

OrgnlGrpInfAndSts/OrgnlMsgId Original message identification — mandatory

The MsgId of the pain.001 this report is about — the pointer back to what is being answered.

⚠ If your systems do not store outbound MsgIds, incoming status reports cannot be matched automatically and end up in manual queues.

OrgnlGrpInfAndSts/OrgnlMsgNmId Original message name identification — mandatory

The message type being answered, for example pain.001, including its version — so the receiver knows exactly which definition the original followed.

OrgnlGrpInfAndSts/GrpSts Group status — optional

A status for the original message as a whole — for example accepted, rejected, or partially accepted — before drilling into individual transactions.

A partial status at group level means you must read the transaction level to know which payments survived.

⚠ Treating a group-level acceptance as final for every transaction. Individual payments can still fail later in processing.

OrgnlPmtInfAndSts/OrgnlPmtInfId Original payment information identification — conditional

Identifies which payment block (PmtInf) of the original pain.001 this part of the report refers to.

Rejections at this level typically mean a block-wide problem — a bad debtor account or an invalid requested execution date — rather than a single bad payment.

OrgnlPmtInfAndSts/TxInfAndSts/OrgnlEndToEndId Original end-to-end identification — conditional

The EndToEndId of the specific payment being reported on, so the initiating party knows exactly which payment a status belongs to.

⚠ If the original EndToEndIds were not unique within the file, a transaction-level status may be ambiguous.

OrgnlPmtInfAndSts/TxInfAndSts/TxSts Transaction status — conditional

The status code for one payment. Common values from the ISO external code set include ACCP (accepted after profile checks), ACSP (accepted, settlement in process), ACSC (accepted, settlement completed), PDNG (pending), and RJCT (rejected).

Which statuses a bank actually sends varies a lot: some report only rejections, others report the full positive lifecycle. Confirm the bank's reporting policy rather than inferring from silence.

⚠ Treating ACSP as 'done'. Settlement in process is not settlement completed.

OrgnlPmtInfAndSts/TxInfAndSts/StsRsnInf/Rsn/Cd Status reason code — conditional

A coded reason from the ISO external code sets explaining a rejection or pending status — for example an account problem or a regulatory hold.

Reason codes drive automated repair routing. A payment engine that reads only the status and ignores the reason forces every reject into one manual queue.

⚠ Some banks put the substance in a narrative element with a generic code. Capture both code and narrative in your workflow.

FULL pain.002 REFERENCE →

COMMUNITY SIGNAL

Discuss this learning page

Share an operational observation or ask a concrete payments question. Your name and message are public; your email remains private.

NEXT QUESTION REVIEWMonday, 27 Jul, 8:00 amMonday answer runs use source-supported educational material. Some questions may need owner review.
WHAT ARE YOU SHARING?

Publish only lawful, relevant content. Never include confidential payment or personal data.

Public discussion

LOADING

Loading the discussion…