Flow of the explanation in this lesson.
e-Mandate Service and Its ISO 20022 Messages
What you will learn
Your objective. By the end of this lesson, you will be able to explain e-mandate service and its ISO 20022 messages. An e-mandate is a mandate that the debtor signs electronically, usually on the creditor website, and it is validated by the debtor bank during the signing process.
Why it matters. This matters because the rail decides how fast the money moves, what it costs, when it settles and what can go wrong. Choosing the wrong rail is a product and an operations failure.
Chapter objective: Mandates, collections, returns and refunds
Key learning points
- E-mandate: mandate debtor signs electronically
- Mandate: then created with digital
- Pain.009 carries the mandate request
- It then returns
- Jonas Weber changes his bank
Key terms
Authorisation: Approval by the issuer for a card transaction to proceed, confirming the card is valid and funds or credit are available.
E-mandate: An electronic mandate for direct debit, created and signed online by the debtor through a secure channel, such as internet banking.
ISO 20022: An international standard for financial messaging that defines XML message formats for payments, securities and trade.
Payment flow diagram showing e-Mandate Service and Its ISO 20022 Messages.
Insights and practice scenarios
Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.
Practise this lesson
Exercise
Read the ISO 20022 messages message described in this lesson and identify its key parts.
Use the message structure, fields and example in this lesson.
- What to do. List the main blocks of the message, name the field that carries the amount, and name the field that identifies the payment.
Correct result. The message is made of blocks, each carrying a part of the payment instruction. The amount field and the identification field are the two a receiving bank checks first, because without them it cannot process or reconcile the payment.
Why. A message is only useful if you can read it. The blocks tell the receiving bank what to do, and the amount and identification fields are what it checks first.
Check your understanding
Practice question
Which of the following best describes e-mandate service and its ISO 20022 messages?
Takeaway and next step
What to remember
If Jonas Weber had named an account that did not belong to him, the bank would have refused the mandate, and the utility would never have received a valid authorisation to collect.
Open the message type from this lesson and inspect its fields, then find the field that carries the amount.
Open the ISO 20022 Message Explorer →
Builds on "The Four-Corner SDD Model and Mandate Flows".
Transcript and full text
Show transcript
An e-mandate is a mandate that the debtor signs electronically, usually on the creditor website, and it is validated by the debtor bank during the signing process. Jonas Weber goes to the Stadtwerke Linden website, enters his IBAN and his name, and is redirected to his own bank, Meridian Bank Munich, to authenticate himself. He logs in with his normal online banking credentials, confirms the mandate details on the bank screen, and is redirected back to the utility website. The mandate is then created with a digital record of the authentication, and the creditor stores it as a valid mandate under the SDD scheme rules. The e-mandate flow uses ISO 20022 messages to carry the mandate information between the creditor, the debtor bank, and the service providers involved. The mandate initiation and the mandate acceptance are exchanged as pain.009 and pain.010 messages, while the mandate amendment and cancellation use pain.011 and pain.012 messages. The pain.009 carries the mandate request, including the debtor, the creditor, the account, and the collection details. The pain.010 carries the acceptance, confirming that the debtor bank has validated the mandate and that the debtor has authenticated the instruction. The debtor bank plays an active role in the e-mandate flow, and that role is what makes the electronic signature trustworthy. Meridian Bank Munich authenticates Jonas Weber, checks that the account he named belongs to him, and confirms that the mandate details match the account. It then returns a confirmation that the mandate has been accepted, and it records the mandate reference SWL-JW-2026-0417 against the account. If Jonas Weber had named an account that did not belong to him, the bank would have refused the mandate, and the utility would never have received a valid authorisation to collect. The e-mandate service also handles amendments and cancellations through the same message family, so the mandate stays current without paper forms. If Jonas Weber changes his bank account, he can amend the mandate through an online flow, and the amendment travels as a pain.011 message to the creditor and to the debtor bank. If he cancels the mandate, the cancellation travels as a pain.012 message, and the creditor must stop collecting from the next due date. The creditor must check the mandate status before each collection, because a collection sent against a cancelled mandate will be rejected by the debtor bank and may generate a complaint. Worked example with numbers: Jonas Weber goes to the Stadtwerke Linden website, enters his IBAN and his name, and is redirected to Meridian Bank Munich, which authenticates him, checks that the account belongs to him, and confirms the mandate details. The mandate is then stored under reference SWL-JW-2026-0417, and the mandate initiation travels as a pain.009 message while the acceptance travels as a pain.010 message, so that every party in the flow has a record of what was agreed. The whole signing takes under two minutes, and the customer never signs a paper form, which is why the e-mandate has replaced paper mandates for most utilities. Failure and recovery: the e-mandate fails when authentication fails, when the account does not belong to the customer, or when the mandate details are wrong. If Jonas Weber enters an IBAN that belongs to someone else, Meridian Bank refuses the mandate, because the account holder must be the debtor, and the signing stops. If the customer closes the browser before confirming, the mandate is never created, and the utility must ask the customer to start again. The recovery is a new signing flow, but the utility must not store a half completed mandate, because a mandate that was never confirmed is not a mandate at all, and a collection based on it would be unauthorised. For a business analyst, product owner or subject matter expert, the e-mandate requirement must state the messages, pain.009 for the initiation and pain.010 for the acceptance, and must state that the debtor bank authenticates the customer and checks the account. The requirement must also state how amendments and cancellations travel through the same message family, so that a mandate stays current without paper forms. The test pack must include a successful e-mandate, a failed authentication, a mandate with a wrong IBAN, and an amendment that changes the bank account, because each case exercises a different part of the flow. Source: EPC SDD Core Rulebook 2025; ISO 20022 pain.009 and pain.010; last reviewed 7 November 2026.
An e-mandate is a mandate that the debtor signs electronically, usually on the creditor website, and it is validated by the debtor bank during the signing process. Jonas Weber goes to the Stadtwerke Linden website, enters his IBAN and his name, and is redirected to his own bank, Meridian Bank Munich, to authenticate himself. He logs in with his normal online banking credentials, confirms the mandate details on the bank screen, and is redirected back to the utility website. The mandate is then created with a digital record of the authentication, and the creditor stores it as a valid mandate under the SDD scheme rules.
The e-mandate flow uses ISO 20022 messages to carry the mandate information between the creditor, the debtor bank, and the service providers involved. The mandate initiation and the mandate acceptance are exchanged as pain.009 and pain.010 messages, while the mandate amendment and cancellation use pain.011 and pain.012 messages. The pain.009 carries the mandate request, including the debtor, the creditor, the account, and the collection details. The pain.010 carries the acceptance, confirming that the debtor bank has validated the mandate and that the debtor has authenticated the instruction.
The debtor bank plays an active role in the e-mandate flow, and that role is what makes the electronic signature trustworthy. Meridian Bank Munich authenticates Jonas Weber, checks that the account he named belongs to him, and confirms that the mandate details match the account. It then returns a confirmation that the mandate has been accepted, and it records the mandate reference SWL-JW-2026-0417 against the account. If Jonas Weber had named an account that did not belong to him, the bank would have refused the mandate, and the utility would never have received a valid authorisation to collect.
The e-mandate service also handles amendments and cancellations through the same message family, so the mandate stays current without paper forms. If Jonas Weber changes his bank account, he can amend the mandate through an online flow, and the amendment travels as a pain.011 message to the creditor and to the debtor bank. If he cancels the mandate, the cancellation travels as a pain.012 message, and the creditor must stop collecting from the next due date. The creditor must check the mandate status before each collection, because a collection sent against a cancelled mandate will be rejected by the debtor bank and may generate a complaint.
Worked example with numbers: Jonas Weber goes to the Stadtwerke Linden website, enters his IBAN and his name, and is redirected to Meridian Bank Munich, which authenticates him, checks that the account belongs to him, and confirms the mandate details. The mandate is then stored under reference SWL-JW-2026-0417, and the mandate initiation travels as a pain.009 message while the acceptance travels as a pain.010 message, so that every party in the flow has a record of what was agreed. The whole signing takes under two minutes, and the customer never signs a paper form, which is why the e-mandate has replaced paper mandates for most utilities.
Failure and recovery: the e-mandate fails when authentication fails, when the account does not belong to the customer, or when the mandate details are wrong. If Jonas Weber enters an IBAN that belongs to someone else, Meridian Bank refuses the mandate, because the account holder must be the debtor, and the signing stops. If the customer closes the browser before confirming, the mandate is never created, and the utility must ask the customer to start again. The recovery is a new signing flow, but the utility must not store a half completed mandate, because a mandate that was never confirmed is not a mandate at all, and a collection based on it would be unauthorised.
For a business analyst, product owner or subject matter expert, the e-mandate requirement must state the messages, pain.009 for the initiation and pain.010 for the acceptance, and must state that the debtor bank authenticates the customer and checks the account. The requirement must also state how amendments and cancellations travel through the same message family, so that a mandate stays current without paper forms. The test pack must include a successful e-mandate, a failed authentication, a mandate with a wrong IBAN, and an amendment that changes the bank account, because each case exercises a different part of the flow. Source: EPC SDD Core Rulebook 2025; ISO 20022 pain.009 and pain.010; last reviewed 7 November 2026.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.