In the previous article, we analyzed the messages for SDD schemes available in the SDD implementations guidelines except the ones used in the e-Mandate service. We will complete our analysis now by looking at the e-mandate service and the messages exchanges within. But before that, it is
What is the purpose of the e-mandate service?
The e-mandate service is ultimately about mandate management: mandate set-up and creation (initiation), mandate modification (amendment) and mandate termination (cancellation). Each party in the Four Corner Model plays a specific role in the processes related to the mandate management. And we get back again to the Four Corner Model, a essential concept in payments.
The processes related to the e-mandate management are described in details in the following documents (the latest versions available when this article is written): EPC109-08-e-Mandates-e-Operating-Model-High-level-Definition_v1-5.-approved.pdf and EPC208-08-e-Operating-Model-Detailed-Specification-v1.2-Approved.pdf. They can be downloaded from the EPC Website. Currently, the documents can be found from the homepage under the menu What we do / SEPA Direct Debit / SDD mandate (Paragraph EPC approval of e-mandate certification authorities).
The implementation guidelines (IGs) solely describe the messages that are exchanged between the players and not the processes. So the IGs are not enough to understand how the messages are used. Read the e-Mandates Operating-Models documents to see who initiates the message, how they flow and for what purpose.
One thing that strikes when we look at the above picture is that we have PAIN messages exchanged between the Debtor Bank and the Creditor bank, so in the interbank space. This is allowed by the standard ISO 20022 (So it is not a mistake :-)). So just be aware that in some cases, the standard allows PAIN messages to be sent in the interbank space.
A second thing to notice is the absence of the CSM. CSM is not needed since there is no clearing or settlement involved. But this service might be implemented by a CSM. For example EBA Clearing runs the service SEDA (SEPA compliant Electronic Database Alignment) for the Italian Banking community used for the exchange of mandate information. It is an additional optional service (AOS) of the SEPA Direct Debit Scheme. Otherwise the exchange of mandate information happens most of the time over the Internet through secured web API (application programming interfaces).
Messages for the e-Mandate Service
The figures below shows the pain messages related to the e-mandate services and how they are exchanged between the different players.
This is a good overview and it makes the things pretty straight forward and understandable. The pain.009-11 messages are all initiated by the Creditor, not the Debtor. The Creditor sends each message to his bank which forwards it to the debtor Bank. The Debtor bank makes the request available to the debtor (through the e-Banking portal for example), so that he can verify and accept or reject the request. Fraud can be better combatted since the debtor, who initiated the inquiry with his creditor, takes the final decision.
Note that all the messages sent by the Creditor result from an interaction with the debtor. If the Debtor does not provide the mandate information, the creditor cannot send a request for the mandate creation. Similarly the debtor must request a mandate modification or cancellation for the Creditor to forward the request through his bank to the debtor bank. That is why everything begins with the debtor.
Let’s look at each message now.
pain.009.001.01 (Mandate Initiation Request) : The message is used for the mandate creation. Since the mandate information comes from the debtor, the creditor must request it from him along with a signature or formal confirmation. In case the Creditor already has debtor information, he will just make sure that the information available is up-to-date and request a singature. The creditor then sends the request with all the information to the Debtor bank. The latter pushes the information to its customer and request him to confirm. Upon confirmation of the mandate creation by the debtor, the Debtor bank replies to the Creditor Bank with a positive acceptance report. Otherwise, the request is rejected and a negative acceptance report is issued.
pain.010.001.01 (Mandate Amendment Request): This message is used to request changes in the mandate. The debtor or the creditor may need to amend the mandate. So the request for change may come from either party. Few common reasons for mandate amendments are:
- The debtor changes his bank account or his address
- The creditor changes his name or his identifcation
- The Creditor changes the mandate reference
The creditor prepares and forwards the mandate amendment requests to the debtor bank through his own bank. Upon confirmation of the mandate amendment by the debtor, the Debtor bank replies to the Creditor Bank with a positive acceptance report. Otherwise, the request is rejected and a negative acceptance report is issued.
pain.011.001.01 (Mandate Cancellation Request): This message is used to cancel the mandate. As a result, the creditor will no longer be able to collect funds from debtor account. In general, the request comes from the debtor, but it may come from the creditor or the debtor bank in some cases. If the debtor bank wants to cancel the mandate, it will inform its customer, the debtor, and asks him to take the necessary steps with the creditor.
The cancellation request is forwarded by the creditor to the debtor bank like the previous messages. Upon confirmation of the mandate cancellation by the debtor, the Debtor bank replies to the Creditor Bank with a positive acceptance report. Otherwise, the request is rejected and a negative acceptance report is issued.
pain.012.001.01 (Mandate Acceptance Report): When the debtor reponds to his bank upon a request, the debtor bank issues a Mandate Acceptance Report. Since the response can be either positive or negative, the report can contain either a positive or a negative confirmation, respectively for success and failure.
This ends our analysis of the messages exchanged for the e-Mandate service. This overview is helpful to grasp e-mandate service faster. But if you want to understand the processes, then it is important to read the Operating Model High Level and detailled specifications documents. They contain a lot of useful information not mentionned in this article.