Payments Initiation
CustomerPaymentStatusReportV10
Payments Initiation
The bank telling the initiator what happened to a pain.001. Group, payment-information and transaction level statuses are all optional, which is why parsers must handle three nesting levels.
Then the technical flows
Schema versions
SWIFT and ISO publish successive XSD revisions of the same business message (e.g. pacs.008.001.08 → .10 → .13; same pattern for camt and pain). Markets pin one via a usage guideline (EPC SEPA, CBPR+, Swiss SPS…) and may add a country suffix (pacs.008.001.08.ch.02) — the Document xmlns must match that XSD.
ISO catalogue (XSD) ↗SWIFT / CBPR+ ↗SWIFT & versioning glossary →
ISO / EPC customer status report paired with pain.001.001.09. OrgnlMsgNmId must quote the original initiation’s full versioned id.
Facts
- Root element
CstmrPmtStsRpt- Direction
- Bank → customer
- Namespace
urn:iso:std:iso:20022:tech:xsd:pain.002.001.10- Variant (flavour)
001- Version
10
Elements a validator will insist on
Not the full XSD — the paths whose absence causes the rejections you actually see in production.
- CstmrPmtStsRpt/GrpHdr/MsgId
- CstmrPmtStsRpt/GrpHdr/CreDtTm
- CstmrPmtStsRpt/OrgnlGrpInfAndSts/OrgnlMsgId
- CstmrPmtStsRpt/OrgnlGrpInfAndSts/OrgnlMsgNmId
Usage in flows
Bundled samples still use another xmlns; none match pain.002.001.10 yet. Inspect the payload carefully before sending to a bank on this revision.
ISO 20022 payload· XML
pain.002 SIC CHF accepted
Customer status report ACTC before the instruction hits SIC. Switch XML | JSON in the inspector without leaving this sample.
Edit in the XML / JSON tab, then run the check.