pain.009.001.08 MandateInitiationRequestV08

ISO 20022 pain Messages

Set up a mandate that allows the debtor’s institution to accept collection instructions from the creditor through its institution.

Example Services Ltd proposes recurring monthly EUR 125.00 collections from Cedar Books Ltd. The pain.009 message DEMO-M009-001 was created on 2 January 2026, carrying request DEMO-MANDATE-REQ-001 and mandate reference DEMO-MANDATE-001. It identifies DEMO-SERVICES-ACCOUNT and DEMO-CEDAR-ACCOUNT with Fictional Services Bank and Fictional Cedar Bank, specifies RCUR and MNTH, and proposes 10 January 2026 as the first collection date. TrckgInd is present with value false. The XML contains no response or consent evidence. For the handover, suppose the service separately confirms the required mandate outcome before the collection team proceeds. The related pain.008 example, message DEMO-M008-001 created on 8 January, uses the same mandate ID and EUR 125.00 amount and requests collection on 10 January. That is a distinct collection instruction. The linked values illustrate continuity; neither fixture establishes that the assumed mandate acceptance or payment execution occurred.

Catalogue availability identifies pain.009.001.08 as MandateInitiationRequestV08; it does not make that version mandatory for a particular scheme or bank. Match the receiving service’s supported version and restrictions before sending it. Reference-mode cardinalities describe this exact supplied base XSD, not every implementation guideline.

The base V08 message allows Mndt 1..unbounded. In contrast, the EPC 2025 v1.0 optional SEPA Core e-Mandate service guidelines describe pain.009.001.06 and a single creditor-to-debtor-PSP request. That V06 service restriction must not be restated as V08 base cardinality or a universal initiation direction. This worked XML is not a SEPA e-Mandate certification fixture.

Local cardinality applies within its parent, in sequence and with any choice context. MndtId is 0..unbounded in this version; MndtReqId and TrckgInd are 1..1 within every Mndt. Bank requirements for identity, consent, response handling or additional fields belong in a named usage contract. Do not label them ISO-mandatory merely because this example includes them.

Submitting pain.009, receiving transport acknowledgement, recording a pain.012 result and collecting money are distinct events. Record what each piece of evidence establishes. Request acceptance is not a cash movement, and a missing response is not evidence of rejection. The mandate and collection processes require separate correlation and recovery decisions.

A mandate lifecycle change may affect which future collections are permitted, but its effect on a collection already prepared, submitted or executed depends on the service’s rules and actual timing. Do not assume cancellation or suspension of a mandate automatically recalls an existing payment. Retrieving a copy supplies information and is not a new consent or change instruction.

The supplied field reference describes TrckgInd as automatic resubmission of direct-debit instructions at agreed intervals under a bilateral arrangement. This retained definition is not permission to retry mandate requests after transport failure. Check the actual arrangement; the worked false value does not enable that resubmission.

Illustrative implementations may store a mandate record, deliver requests through APIs or queues and retain response and audit evidence. Keep sensitive account and consent data under applicable access, logging and retention policy. Correlate technical attempts separately from business requests and preserve enough evidence to resolve an uncertain outcome without duplicate submission.

Explore the complete Payment Life Cycle