pain.010.001.08 MandateAmendmentRequestV08

ISO 20022 pain Messages

Change specified information in an existing mandate while identifying the mandate being changed.

Fictional alternative later action: on 20 January Cedar Books asks to replace its collection account with DEMO-CEDAR-NEW-ACCOUNT under DEMO-MANDATE-001. The message has its own identifier DEMO-M010-001 and refers to initiation DEMO-M009-001 from 2 January. The illustrated January collection predates this request. The request contains a proprietary demonstration reason, not a verified external reason code. No accepting response to this amendment is supplied. In a possible bank implementation, operations would retain the earlier terms while the proposed change is pending and investigate any missing response before deciding whether a retry is appropriate. That recovery story illustrates decisions to design; it adds no unshown successful outcome to the XML.

The request proposes change; it does not by itself establish acceptance, transfer money or reverse a prior collection. Preserve historical mandate terms and references for reconciliation.

The retained scope distinguishes specific amendments from replacing all mandate elements or changing the underlying contract. Do not silently implement a new mandate as an amendment simply to reuse its identifier.

ISO base syntax and a service's usage rules are separate. The EPC 2025 SDD Core e-Mandate implementation guide uses pain.010.001.06; this lesson's pain.010.001.08 example is not a SEPA conformance sample. Use the actual contracted scheme/profile and version rather than assuming CBPR+ or SEPA applies.

Original-message references, proposed mandate data and original-mandate identification serve different purposes. Do not infer a field's requiredness from this complete example; check its exact XSD path, enclosing choice and any applicable profile.

Explore the complete Payment Life Cycle