NL/EN

Terms and conditions for provision of the eMandates Creditor Integration Guide:Terms and conditions

1. Currence Services BV (also referred to as 'Currence') provides these eMandates Creditor Implementation Guidelines to Creditor Banks that distribute it to (potential) Creditors and Payment Service Providers to enable them to implement eMandates.

2. Currence reserves the right to deny access to the eMandates Creditor Implementation Guidelines to (potential) Creditors and Service Providers on reasonable grounds, in consultation with the Creditor Bank with which the Creditor/Service Provider has a contract.

3. These Implementation Guidelines are explicitly and exclusively provided for the purpose mentioned above, and no other use is permitted. No rights can be derived from the information provided in this document or the accompanying notes. Currence is in no way liable for the consequences of later changes to the eMandates Standards or the eMandates Creditor Implementation Guidelines. If banks or other interested parties take decisions and/or make investments on the basis of the information that they obtain via the eMandates Creditor Implementation Guidelines, Currence accepts no liability for this in any way.

4. These implementation Guidelines are based on the information in the eMandates Standards documents. In the event of any discrepancy between the eMandates Creditor Implementation Guidelines and the eMandates Standards documents, the text in the eMandates Standards documents prevails.

For any questions concerning this document or requests for further information, please contact your Bank or Payment Service Provider.

Contents

1. General Introduction

2. eMandates Overview

2.1 What is eMandates?

eMandates was developed by the Dutch banking community in order to facilitate online processes for mandates. eMandates enables direct and secure real-time Real-time signing and issuing does not always apply when multiple signing is required for the specific Debtor. online issuing and amendment of eMandates by Debtors to Creditors.
The main characteristics of eMandates are:

• Real-time eMandates through accepted and trusted online banking that is already familiar to Debtors;

• Real-time eMandate approval by the Debtor and real-time confirmation to the Creditor by the Creditor Bank. The Creditor receives the eMandate that has been signed by the Debtor Bank on behalf of the Debtor;

• Officially recognised as valid mandates by the participating Debtor Banks. The refundrisk period for Creditor's SEPA Direct Debit collections is thereby reduced from 13 months to 56 days;

• For B2B Direct Debit collections, the Debtor Bank only processes the collection when it matches a pre-registered mandate. eMandate registrations are automatically created, amended or cancelled by the Debtor Bank as part of the eMandate process, which means the Creditor can almost immediately proceed with the direct debit This can vastly reduce the mandate-to-collection lead-times compared to the current mandate-registration processes as well as the number of failed direct debits due to mandate registration entry-errors.   

• Offers the flexibility to receive mandates for many different purposes (e.g. charitable donations, magazine subscriptions, telephone/e-mail orders);

• Supports multiple signing in the Debtor Bank domain in case this is required for specific Debtors.

In practice, nearly every Debtor that uses online banking with one of the Debtor Banks that support eMandates can use the eMandates service.

2.2 Design principles

2.2.1 Technical principles

eMandates is based on the following principles:

• Use of existing online banking and mobile banking products.

• Communication over the Internet.

• Use of open-market standards, where possible.

• Merchant implementation involving the least possible complexity.

• Taking measures to improve reliability, where possible.

• Use of the Multilingual European Subset 2 (MES-2) standard character set.

• Debtor's selection of Debtor Bank (Issuer) based on Debtor Bank name. - Safety and reliability (stability).

2.2.2 Functional principles

• The eMandates Implementation Guidelines described in this document are intended for the Core/B2B SEPA Direct Debit.

• The eMandates solution facilitates the issuing of new eMandates and amendment and cancellation of existing eMandates. Creditors must offer both functionalities to their Debtors (issuing new eMandates, amending existing eMandates and cancelling existing eMandates).

  • The only reason for amending an eMandate is when the Debtor wishes to change his bank account number for Direct Debits, within the same bank or to a different bank, or to change the Maximum Amount of the direct debit. The amendment process is initiated on the Creditor’s website. After the redirect to the Debtor Bank internet banking website, the Debtor can choose his preferred account number and/or adjust the value of the maximum amount.

  • Cancellation of eMandates is not supported by the Core eMandates solution. The reason for this is that cancellations usually focus on ending of the subscription or contract, instead of ending of the eMandate. Cancellation of eMandates is therefore something that must be facilitated electronically by the Creditor, without a role for the Debtor Bank.

• The eMandates solution uses the ISO XML 20022 standard eMandates messages to convey eMandate- specific data. The following messages are used: pain.009.01.04 (new, also referred to as 'issuing'), pain.010.01.04 (amendment), pain.011.01.04 (cancellation) and pain.012.01.04 (acceptance report). The information inside the ISO XML 20022 acceptance report (pain.012) constitutes the actual eMandate. The ISO messages are placed inside the container element in the messages. The XSD's for these ISO messages can be found at http://www.iso20022.org/full_catalogue.page, see pain – Payments initiation.

• The eMandates solution is intended for both recurring and one-off mandates.

• In the eMandates process, the eMandate information is shown to the Debtor for approval in the Debtor Bank domain.

• Each eMandate has an eMandateID that uniquely identifies it within a given CreditorID. Each Creditor is responsible for issuing his own unique eMandateID's. Creditors must beware that eMandateID's must be restricted to the SEPA Direct Debit character set.

• The Creditor is responsible for archiving It is expected that in the future more strict requirements will appear for electronic archiving, especially related to protecting document integrity for a longer period of time. In the short future the regulation on electronic identification will address the topic of e-Archiving and will create a legal framework underlying time-stamping services. These guidelines will then be evaluated and used in these implementation guidelines. the original eMandate (the ISO pain.012 message which includes the electronic signature and certificate information), together with any following amendment or cancellation information received from the Debtor (at a later stage). The ISO pain.012 message can be archived after extracting it from the XML envelope, using exclusive canonicalization. Alternatively, Creditors may choose to simply archive the entire StatusResponse message. Archiving the message needs to be done without making any changes to the message, as this will invalidate the electronic signature. Even minor changes such as adjusting the message-formatting will render the signature invalid.

• The elements eMandate.Frequency and eMandate.MaxAmount have been included in the eMandate solution to facilitate the Debtor Bank's Debtor Protection measures for Direct Debit collections. However, these elements have been included for future use and will not be used in this version of eMandates. The Creditor MAY NOT INCLUDE these fields in any of the eMandate messages.

• An approved eMandate is used for Core by the Debtor Bank to update the Debtor's whitelist A whitelist is a list of MandateID's belonging to an account number. For this account number, direct debit collections are allowed for these Mandate ID's only. , but this is done only when the whitelist has already been activated by the Debtor. An inactive whitelist will not be activated by an eMandate.

• If the Creditor or MandateID is on the Debtor's blacklist A blacklist blocks an account number for Direct Debit collections. This can be a complete blockage, a blockage for a specific CreditorID or for a specific MandateID. , there are several options:

  • The blacklist is adjusted real-time by the Debtor and the eMandate is approved

  • The blacklist must first be adjusted in a separate process, so the eMandate process will be cancelled and must be restarted at a later time

• For B2B, if the Creditor or MandateID is on the Debtor’s blacklist. A blacklist blocks an account number for Direct Debit collections. This can be a complete blockage, a blockage for a specific CreditorID or for a specific MandateID, there are several options:

  • The blacklist is adjusted real-time by the Debtor and the eMandate is approved

  • The blacklist must first be adjusted in a separate process, so the eMandate process will be cancelled and must be restarted at a later time

2.3 The four-corner model

The eMandates system is based on the 'four-corner' model. Figure 1 shows the roles in this model, along with their mutual primary relationships in the context of eMandates. The roles are those of Debtor, Creditor, Creditor Bank, Debtor Bank, Routing Service and Validation Service:

• The Creditor is the company collecting Direct Debits. This can be the actual Creditor, or a Collecting Payment Service Provider collecting Direct Debits acting on behalf of another Creditor.

• The Debtor is a consumer or company holding a bank account at the Debtor Bank, from which Direct Debits can be collected.

• The Creditor Bank is the bank where the Creditor has his contract for eMandate services.

• The Debtor Bank is the Bank where the Debtor hold's the bank account that he wishes to use for eMandates. This bank account MUST be used by the Creditor for the collection of direct debits.

• Routing Service: a technical role (routing of messages) that is fulfilled by a Creditor Bank or a third party endorsed by the Creditor Bank. Wherever the term 'Routing Service' is mentioned in this document, please read 'Routing Service of the Creditor Bank'.

• Validation Service: a technical role that is fulfilled by the Debtor Bank or by a third party endorsed by the Debtor bank. Wherever the term 'Validation Service' is mentioned, please read 'Validation Service of the Debtor Bank'.

2.3.1 The relations between these roles

Both contractual and technical relations exist between the roles. These are described below.

2.4 Terminology

eMandates has been based partly on existing XML messages (of the so-called iDx standards) that are based on the iDEAL messages. To convey specific eMandates information, pain ISO messages are placed inside a container element in these existing iDx XML messages. Because the existing XML messages have some different terminology/element names, a mapping applies between the XML element names and the functional element names that are used in eMandates. The table below shows the mapping of functional eMandates element names to the terms used in the XML messages.

^{Mapping of eMandates elements to XML elements}

As stated in the introduction, this document will only cover the messages that are exchanged between the Creditor and the Routing Service. However, the messages that are exchanged between the Routing Service (of the Creditor Bank) and the Validation Service (of the Debtor Bank) will be briefly explained if necessary to provide a good understanding of the entire transaction. Besides the four parties mentioned that are always involved in a transaction, additional parties can be involved. The Creditor can, for example, use a Service Provider to establish the technical connection with his Routing Service. When a Service Provider collects funds and then distributes these funds to the ultimate Creditor, this is called a "Collecting PSP" (CPSP).

3. eMandates protocol

A specific name (letter) has been assigned to identify each message. The following table applies:

^{Message names and descriptions}

By using the Directory protocol, the Creditor sends a DirectoryRequest to the Routing Service. This is a request in XML format to obtain the list of participating Debtor Banks from the Routing Service. The Routing Service will provide this list to the Creditor by sending back the DirectoryResponse. The Creditor will show the list of banks, which were sent in the DirectoryResponse to the Debtor. The Debtor will choose his bank from this list at the beginning of the eMandate process. The Directory protocol is explained in more detail in chapter 7.

By using the Transaction protocol the Creditor sends a TransactionRequest to the Routing Service, containing the ID of the Debtor Bank chosen by the Debtor, mandate information and other transaction details. This message also contains the MerchantReturnURL. This URL is used by the Validation Service to redirect the Debtor back to the Creditor's website when he has completed the eMandate transaction in his Debtor Bank domain. After the Routing Service has received the message from the Creditor, he adds some pre-registered Creditor details to the message and sends a message to the Validation Service of the Debtor Bank that was selected by the Debtor. In return, the Validation Service responds with a message that contains the issuerAuthenticationURL (and other data). The Routing Service passes this  issuerAuthenticationURL together with a unique TransactionID back to the Creditor via the TransactionResponse message, which is the response to the TransactionRequest. The Creditor now redirects the Debtor to the issuerAuthenticationURL, which refers to the page of the online banking portal. This takes the Debtor to his internet-banking environment where he can continue the eMandate transaction. The Debtor Bank adds Debtor information (such as IBAN and Debtor Name) to the eMandate proposal. The Debtor approves the eMandate and receives a confirmation from the Issuer. The Debtor is then redirected back to the website of the Creditor via the merchantReturnURL. The entire Transaction protocol and the 2 redirects are further described in chapter 8. 

Finally the Creditor initiates the Status protocol by sending a StatusRequest message to the Routing Service. The Routing Service will request the transaction status, if necessary, from the appropriate Issuer and returns the status to the Creditor. If all steps in the transaction were successful this status message contains the eMandate and the signature for the Creditor. Chapter 9 contains more detailed information on the Status protocol. 

Instead of a regular response to the messages mentioned above, it is also possible that an ErrorResponse is returned. This can be the case if the request contains an error, or if an error occurs during the processing of the request. The ErrorResponse messages are discussed in chapter 10.

Chapter 5 describes the general format of eMandates messages. The three protocols are discussed in more detail in chapters 7, 8 and 9.

4. Functions of the solution

This part describes several specific functionalities of the eMandates-solution. All eMandate processes are initiated on the Creditor website by the Debtor. eMandate processes are never initiated from the Debtor Bank domain. The eMandate (issuing, amendment or cancellation) proposal is created by the Creditor. This eMandate proposal is not yet complete: it is completed by the Routing Service (with Creditor information) and Validation Service (Debtor information) respectively.

4.1 Issuing a new eMandate

Issuing a new eMandate is supported through the use of the ISO pain.009 message type. The Creditor enters the mandate information in the message and this information set is then completed with Creditor information by the Routing Service, and with Debtor information by the Validation Service until the complete eMandate proposal is approved by the Debtor. Upon approval, the Debtor Bank adds an electronic signature to the eMandate on behalf of the Debtor. The signed eMandate is then retrieved by the Creditor and must be archived.

4.2 Amending an existing eMandate

Just like with new eMandates, the process is initiated by the Debtor on the Creditor website. The only relevant change for an eMandate is when the Debtor wishes to change his account number (within the same bank or to a different bank) or to change the maximum amount per Direct Debit. The process is almost identical to the process of issuing a new eMandate, but for amendments of existing eMandates, the ISO pain.010 message is used.

The ISO pain.010 message contains the same information as a pain.009 message, but it also included three referrals to the original (existing) eMandate: the original eMandateID, the Debtor IBAN and the Debtor Bank ID.

Amendments to eMandates may also be communicated by the Debtor to the Creditor through use of other channels than eMandates, but this is not recommended.

The Creditor is free to accept amendments to existing (paper) mandates through the use of the eMandates solution.

4.3 Cancelling an existing eMandate

Cancellation of eMandates is not supported by the Core eMandates solution (only for B2B); a cancellation of an eMandate does not have to be (and can not be) done via the Debtor Bank domain, but must be cancelled directly at the Creditor. The Creditor must facilitate this through electronic (website, mail) and regular channels.

Just like with new eMandates and amendments, cancellations are initiated by the Debtor on the Creditor website. For B2B the cancellation process includes validation at the Debtor Bank (whereas for Core, it is a matter between Creditor and Debtor). For cancellation of existing eMandates, the ISO pain.011 message is used. 

The cancellation message contains referrals to the original eMandate: eMandateID, Debtor IBAN and Debtor Bank ID. Cancellations, however, can only be done at the same bank where the eMandate has previously been issued/approved (that is, the bank where direct debits are being collected). The Creditor must make clear to the Debtor he must choose the same bank where the eMandate has been issued. If the Debtor chooses a different bank, the transaction will be rejected by that bank. 

The Creditor is free to accept cancellations to existing (paper) mandates through the use of the eMandates solution. 

4.4 Debtor protection information

Frequency and Maximum amount have been included in this document for future use to facilitate future Debtor protection measures by the Debtor Banks. Therefore, in any current implementation of eMandates, these elements will not be processed by the Routing Service nor by the Validation Service. Creditors may not include these fields in current eMandates messages, as this will lead to rejection of the entire message.

4.5 Multiple signing

For eMandates, multiple signing may be required in the Debtor Bank domain when the Debtor is using a business account to approve the eMandate. This can't always be done in a single session, which means the Debtor Bank has to store the eMandate proposal and make it accessible for further approval. Furthermore, multiple signing implies the following:

• Only the Debtor Bank can determine when multiple signing is required.

• Only the initiator is allowed to be redirected to the Creditor website. This prevents other signers from taking over the initiator's session at the Creditor website.

• The initiator might not return to the Creditor website and hence wouldn't receive online confirmation of the eMandate. The Creditors are therefore recommended to use other means of (offline) communication to inform the initiator the eMandate has (not) successfully been received.

When multiple signing is required, the transaction may need more time to enable other signers to approve the eMandate. However, it is not known beforehand (by the Creditor) whether multiple or single signing is required. Both situations need to be catered for. Therefore, the following principles apply to the use of expiration period Expiration period is the amount of time the Debtor has to approve the eMandate in his Debtor Bank domain before it expires. :

• By default, the Creditor should not set the expiration period to the transaction. In that case, the standard expiration period is 30 minutes.

• When the first Debtor logs into the Debtor Bank domain within 30 minutes, the Debtor Bank is able to determine whether multiple signing is required. When multiple signing is indeed required, the Debtor Bank automatically sets the expiration period to 7 days. In all other cases, the expiration period remains 30 minutes.

• The Creditor may always assume the expiration time to be 30 minutes and can perform a status request after 30 minutes (assuming the redirect to the Creditor has not occurred so there has not been a trigger to request the status yet)

• When multiple signing is required, the transaction gets the status 'Pending'. The Creditor may then request the status of the transaction once every day. After 7 days, the status of the transaction becomes final (Expired) if not all required signers have approved the eMandate transaction.

• If a Creditor has an urgent need to ensure a stricter expiration period, he may choose to set the expiration period to his preferred time-frame, with a maximum of 7 days and a minimum of 1 minute. The Debtor Bank then always adheres to this expiration period (even when multiple signing is required). A possible consequence of setting the expiration period is that Debtors for which multiple signing is required may not have enough time for all signers to complete the transaction. We therefore strongly recommend Creditors to not set a specific expiration time.

4.6 Creditor Registration for eMandates

4.6.1 Creditor preconditions

Each Creditor that wants to use the eMandates solution must have an eMandates-contract. As a pre-condition for getting this contract, a Creditor must be in possession of a Direct Debit contract at a (same or different) Creditor Bank. Only after establishing that a Creditor has a Direct Debit contract will the Creditor Bank enter into an eMandates-contract with this Creditor.

A Creditor that acts as a Collecting Payment Service Provider can collect Direct Debits for other companies. In this case, the eMandates must also be in the name and CreditorID of this CPSP (because the eMandate must be issued to the company that is collecting the Direct Debits). To make sure the Debtor recognises the eMandate, the name of the company being serviced (the ultimate Creditor) must also be mentioned on the eMandate. This is done using the element Creditor.TradeName. In the Debtor Bank domain, for approval by the Debtor this would be phrased as the eMandate being issued to 'Creditor.Name regarding Creditor.TradeName'.

Likewise, a Creditor may have a company structure using different company labels (names) and addresses. As with the example of the Collecting Payment Service Provider, the labels can be shown on the eMandate as a tradename. In case of more than one company address, the correct address is also selected by the Routing Service for approval of the eMandate.

The Creditor registration process at the Creditor Bank facilitates selecting the right Creditor information for the eMandate by the Routing Service.

4.6.2 Creditor registration

When registering for eMandates, the Creditor Bank issues an eMandate.ContractID to the Creditor. The Creditor also gets an eMandate.ContractSubID if this is required to distinguish between Creditor tradenames and/or addresses. The Creditor must register his address using two address-lines, generally using the first line for information on street, number, postbus, addons and using the second line for postcode and city. The exact details of the registration (process) are determined by your Creditor Bank and/or the Routing Service acting on its behalf.

In the eMandate process, the eMandate.ContractID and eMandate.ContractSubID are sent to the Routing Service by the Creditor in the eMandates request message. The Routing Service then adds specific Creditor information to this proposal based on the contractID (and when relevant also on the SubID). The Routing Service selects the right Creditor.Name,
Creditor.CreditorID, Creditor.TradeName, Creditor.AddressLine1 and
Creditor.AddressLine2 to add to the eMandates proposal. The Creditor is not allowed to fill out any of these elements.

4.7 ValidationReference

When the eMandate is approved by the Debtor in his Debtor Bank domain, the Validation Service generates a reference number (the ValidationService.ValidationReference). This reference is sent to the Creditor as part of the eMandate. This reference must be added to the Direct Debit collection information from the Creditor to his Creditor Bank. This reference is used by the Debtor Bank to retrieve eMandates validation information in case of a Debtor dispute.

4.8 Dispute management

In case of a dispute, the Debtor Bank has the role to check the integrity and authenticity of the eMandate. Therefore, in case of a dispute (MOI):

• The Creditor must supply either the ISO pain.012 message that represents the actual eMandate (in exclusively canonicalized form), or the entire XML file that was received in the StatusReponse (message F'). The Creditor must also supply any additional amendment information in case any changes were made outside the eMandates protocol. An example of such information is the message that you receive from your bank if one of your customers has transferred to a new bank using the Dutch Overstapservice.

• The Creditor sends this information to his Creditor bank by email. The Creditor Bank forwards this information to the Debtor Bank.

• The Debtor Bank uses the certificate information to verify the electronic signature. Thereby determining authenticity and integrity of the eMandate.

5. eMandates Message format

This chapter contains a description of the general message structure for the Directory protocol, the Transaction protocol and the Status protocol. The subsequent sections will describe the specific fields within the XML messages for each protocol in more detail. 
Each message described in this section is an XML message conforming to the XML Schema in APPENDIX D. 

5.1 General

The eMandate messages in the container element must be validated against the pain message's XML schema.

XML Namespace declaration

The namespace for all messages described in this document is as follows:

All message instances must declare this namespace. Namespace declaration can be done in any way allowed by the XML standards (default namespace declaration or namespace qualification/prefixes). All parties must be able to receive and process messages that use either of the two namespace declaration methods.

Message attributes

All XML messages must contain attributes in the root element, as shown in the table below.

Beware: These attributes are not specified in each message separately.

6. eMandates Data dictionary

This chapter describes the data-elements and ID's that are used in the eMandates solution.

6.1 eMandate IDs

The eMandates solution relies on the identifiers described in below table.

^{eMandate IDs}

6.2 General data elements

The table below contains all XML data elements that appear in messages relevant to the Creditor, together with information about the format and permitted values.

6.3 eMandates ISO pain message data elements

The table below describes the data elements that are used in the eMandates ISO pain messages (009, 010, 011 and 012), together with their formatting rules. Attention: several of these elements are added to the eMandate by the Routing Service and Validation Service. These elements are therefore not part of the Transaction Request the Creditor sends to the Routing Service. Please see chapter 8.2 for an overview of the information that is part of the Transaction Request.

7. eMandates Directory protocol

7.1 General

• The Directory protocol allows a Creditor to retrieve an up to date list of participating Debtor Banks from his Routing Service, which can be presented to the Debtor. In case of changes in the list of Debtor Banks, the Directory protocol will supply the Creditor with the update of this list.

• It is not allowed to perform the Directory protocol for each transaction. Since the list of Debtor Banks only changes occasionally, it is sufficient to execute the Directory protocol on a weekly basis and check if the list has changed based on the directoryDateTimestamp. If the Debtor Bank list has changed, the latest version has to be saved and used for any subsequent transaction. Routing Services will normally also inform all Creditors (e.g. by email) about changes in their Debtor Bank list. The Directory protocol should at least be executed once a week.

• The Directory protocol (like the Transaction protocol and the Status protocol) consists of a HTTP POST request from the Creditor to the Routing Service, followed by a HTTP response. The DirectoryRequest is sent to the URL that is provided to the Creditor by the Routing Service for this specific purpose. This URL can be different from the one that is used for the TransactionRequest and the StatusRequest, but it can also be the same URL.

• The Routing Service validates the authenticity of the message sent by the Creditor by verifying the signature in the message. To do this, the Routing Service needs the Creditor's Certificate, including the public key. The way in which the public part of the Creditor certificate is communicated with the Routing Service varies per bank. Please refer to Chapter 11 for more information on authentication and security.

7.2 DirectoryRequest

The DirectoryRequest consists of an XML message that is sent to the Routing Service with HTTP POST. Below table shows all fields and formatting of the DirectoryRequest:

7.3 DirectoryResponse

The Creditor will receive the DirectoryResponse as a reply to the DirectoryRequest. This XML message contains a list of Debtor Bank names with their corresponding Debtor BankID (BIC). Debtor Banks are grouped by country. The Debtor Banks in the Creditor's country of choice may be presented at the top in the Debtor Bank selection list, the rest are sorted alphabetically by country, then by name. Below table shows all fields that appear in the DirectoryResponse message.

An example of the DirectoryResponse is shown in APPENDIX C.

7.4 Presentation of the Debtor Bank selection list

Creditors are not permitted to remove Debtor Banks temporarily from the Debtor Bank selection list or to grey them out. If a Creditor learns via the eMandates Notification System (Central Reporting tool for eMandates Validation Services and Routing Services to state system non-availability) or via error messages received from the Acquiring bank that a particular Validation Service is currently not available, the Creditor may display a message on its website informing Debtors that the particular bank is not available. In other words, it is permissible to display a message conveying such information but it is not permissible to temporarily remove or grey out the Debtor Bank concerned from the Debtor Bank selection list.

8. eMandates Transaction protocol

8.1 General

The Transaction protocol initiates the exchange of messages of the actual eMandates process. After the Debtor has chosen eMandates as a transaction method and has selected his bank, the Creditor sends a TransactionRequest to the Routing Service. Within the eMandates standards this message is referred to as the AcquirerTransactionRequest. The Routing Service replies to the TransactionRequest with a TransactionResponse. This TransactionResponse will also (among other fields) contain the issuerAuthenticationURL. This URL will redirect the browser of the Debtor to the Debtor Bank in order to let him authorise the transaction.

8.2 TransactionRequest

The XML message sent by the Creditor to the Routing Service to initiate the transaction contains the fields shown in below first table. The eMandate information (ISO message) is put inside the container element in the Transaction Request. The definition of the ISO message for a new eMandate request (ISO pain.009.001.004), amendment request (ISO pain.010.001.004) and cancellation request (ISO pain.011.004) are shown in below tables:

8.2.1 Container content

As explained, the mandate ISO pain messages are put in the container element. The ISO message is a standardised message, so it contains elements that are not used in the eMandates solution. In the following tables, only mandatory and recommended optional elements for the eMandates solution are mentioned. The table's columns contain the following information:

• Column 1 is the index. This index is specific for this document.

• Column 2 gives the name of the message element as defined in the ISO 20022 XML standard. When an element contains sub-elements these are indented and noted with a minus ( - ) sign per level.

• Column 3 specifies whether the element is Mandatory or Optional

8.2.2 Content of container element for new eMandates

8.2.3 Content of container element for eMandate amendments

A Debtor can amend the Debtor account number or maximum amount of an existing eMandate through the eMandate solution. The website-process is the same as with new eMandates, but in this case the Debtor indicates which existing eMandate (eMandateID) he wishes to adjust. The original Debtor Bank ID and the original Debtor IBAN are also included in the amendment request.

8.2.4 Content of container element for eMandate cancellations

A Debtor can cancel an eMandate through the eMandate solution. The website-process is the same as with new eMandates, but in this case the Debtor indicates which existing eMandate (eMandateID) he wishes to cancel AND the Debtor can only cancel his eMandate at the bank where the eMandate is currently registered. The Creditor must make this clear to the Debtor (to prevent the Debtor from choosing the wrong bank).  

The following table describes which elements the Creditor sends to the Routing Service in the TransactionRequest, for an eMandate Cancellation.

8.3 TransactionResponse

If everything goes well the Routing Service will reply to the TransactionRequest with the
TransactionResponse. Table 15 shows all fields of the TransactionResponse message. The TransactionResponse has no container, so there is no ISO message in this response (this is different in case of an ErrorResponse, see Chapter 10 on error handling).

_{Fields of the TransactionResponse}

*SignedInfo, SignatureValue ^and KeyInfo ^{are XML Signature data elements that are defined in the XML-Signature Syntax and Processing (Second Edition) W3C Recommendation 10 June 2008. The signature is described in more detail in chapter 8. The XML Schema for XML Signatures is available from W3C at the following URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd.}

8.4 Errors when executing Transaction Protocol

A number of errors may occur when executing the eMandates Transaction Protocol. These may be related to unavailability or an error within your own web environment (Creditor), the Routing Service environment or the Validation Service environment.
The following situations may occur:

1. The eMandates transaction cannot successfully be initiated.

2. You receive an error response (message 'X') from your Routing Service within the set time-out period.

3. You do not receive any response within the set time-out period.

In all of the above cases, the transaction protocol cannot be successfully executed. This means it is not possible for the eMandates transaction to take place at that time. Error handling is explained in more detail in chapter 10.

8.5 Redirect to the online banking environment (issuerAuthenticationURL)

After receiving the TransactionResponse the Creditor has to redirect the Debtor to the issuerAuthenticationURL of the selected Debtor Bank, as stated in the TransactionResponse message. If the Creditor's page contains HTML frames, these will be removed by the Debtor Bank ('frame busting'). If and when the Debtor returns to the Creditor's website (with the merchantReturnURL), the Creditor will have to completely rebuild its own page to show confirmation of eMandate reception. 

8.6 Redirect to the Creditor environment (merchantReturnURL)

After the Debtor has performed the necessary steps at the Debtor Bank he will be presented with a 'Continue' button that must redirect him back to the website of the Creditor with the merchantReturnURL as supplied in the TransactionRequest.
Two GET parameters are appended to this URL: the entranceCode (see paragraph 8.2) with 'ec' as GET parameter name, and the transactionID (see paragraph 8.3) with 'trxid' as GET parameter name. It is also possible for a Creditor to add additional parameters. For example, if the Creditor defines the merchantReturnURL as follows:

http://www.webshop.nl/processtransaction?producttype=electronics

The final URL will look something like:

http://www.webshop.nl/processtransaction?producttype=electronics&trxid= 0010123456789012&ec=4hd7TD9wRn76w

The entranceCode field should contain a unique value, with the object of preventing message 'sniffing'. Use of the same entranceCode each time would allow malevolent individuals to intercept the data from the merchantReturnURL and make fraudulent use of this information. This is why using unique values for the entranceCode is extremely important.

8.6.1 Requirements for eMandates Mobile: redirect to the Creditor environment.

After the Debtor has been authenticated in either the mobile or regular channel and has approved the transaction, he is redirected back to the Creditor as normal (using the merchantReturnURL). The merchantReturnURL usually starts with 'https', redirecting the Debtor back to a page on the mobile device's browser. If the Debtor has initiated the transaction from the Creditor's mobile app, the merchantReturnURL can be an app handler, which will redirect the Debtor directly to the Creditor app. An app handler is a call that can be used to start an app and request it to initiate a specific action. For example a Creditor's app handler can start with 'nl.companyname.eMandates://' and this will open the Creditor's app.

8.7 Errors during execution of the redirect to the Debtor Bank, approving the eMandate and/or the redirect to the Creditor environment

The following errors may occur during execution of the redirect to the online banking environment (Debtor Bank), the execution of the eMandate transaction at the Debtor Bank and/or the redirect back to your (Creditor) environment:

• The bank page is unavailable as a result of which the Debtor cannot approve the eMandate, but the Debtor can't be properly redirected to your confirmation page either

• The bank page is available but the Debtor cannot (after approving the eMandate or otherwise) be properly redirected to your confirmation page.

In both situations the Debtor cannot (as the result of a disturbance) return to your confirmation page in the normal way. In that case the Debtor can return to your website by using the 'back' button or entering the URL, for example.

If the Debtor can be identified (for example because he or she has logged into the Creditor environment or via the browser session), the advice in these situations is to check the status of the eMandates transaction (via the Status protocol) and notify the Debtor.

If the Debtor can be identified and the status can be checked but is found to still be 'open', we recommend that the Debtor is shown the following message:
We haven't received the confirmation of your eMandate from your bank yet. We will inform you as soon as we have received the confirmation.

If the Debtor can't be identified upon return, your system should check the status of the eMandate transaction at the end of the expiration period.

In such situations, we also recommend that the status of the eMandate is reported to the Debtor – as soon as it has become final – in one of the ways indicated below:

• By e-mail.

• On your website, for example in the account of the Debtor or via the Debtor's browser session.

8.8 Four different scenario's for completion of eMandates Mobile transaction

To give an overview of all the possible process steps and important notes when dealing with eMandates Mobile transactions, we have specified four different scenarios. There are four different scenarios because either the Debtor Bank or the Creditor or both can use a (mobile) web page or a mobile app.Because these scenarios (could) differ from the regular (non-mobile) eMandates transactions they will be illustrated in the following scenarios.

^{Different scenario's for the completion of an eMandates mobile transaction}

8.9 Performance and time-out of transaction message

The performance of the Debtor Bank and Routing Service systems has a direct influence on the Debtor's user experience. Therefore eMandates sets a target time and time-out for the transaction response message. For a Creditor the relevant target time and time-out concerning the communication with its eMandates Routing Service:

^{Performance requirements (for the 95th percentile)*}

The target time is the time (in seconds) within which the Creditor should receive a TransactionResponse message after sending a TransactionRequest. The time-out is the length of time after which the Creditor should no longer expect a response (most likely an error has occurred) and should act accordingly (for example by displaying an appropriate error message to the Debtor).

*95^th percentile is a statistical term indicating that 95% of transactions in a tested sample should be within the set target time.

8.10 Specific requirement eMandates Mobile: Print or e-mail confirmation message

After a successful regular eMandates transaction the Debtor Bank will always give the Debtor the option to print the confirmation of the eMandate. However in a mobile transaction environment printing will often not be possible, so this requirement is expanded to include alternatives such as e-mailing or downloading the confirmation to/by the Debtor.

9. eMandates Status protocol

9.1 General

To verify whether an eMandate transaction was successful the Creditor will start the Status protocol by sending a StatusRequest to the Routing Service. Within the eMandates standards this message is referred to as the AcquirerStatusRequest.

To avoid unnecessary system load status requests should not be made unnecessarily, see 9.5 for more details on what is allowed. The StatusRequest message can be sent after the return of the Debtor to the Creditor's website (after the redirect from the Debtor Bank), or after a specified amount of time as soon as the expiration period has expired (for example 5 or 10 minutes after the default expirationPeriod of 30 minutes has expired). As explained in paragraph 4.2 on Multiple signing, if the status is 'pending', this means the eMandate still needs to be signed by other Debtors. The Creditor may then execute the Status protocol on a daily basis. If the eMandates isn't completed within 7 days, the status will be set to 'expired' by the Validation Service.

9.2 StatusRequest

Table 22 contains all fields that are part of the StatusRequest XML message. The Creditor sends this message to the Routing Service. Please refer to the clarification in paragraph 6.2 for the abbreviations in the Format column.

9.3 StatusResponse

The reply to the StatusRequest is the StatusResponse. This message is created by the Validation  Service and sent to the Creditor by the Routing Service. The StatusResponse contains the fields  listed in Table 23. This message communicates the status of the transaction (related to the transactionID which was sent in the StatusRequest) to the Creditor. If the status equals "Success", the container element is included in the response. Inside the container element are the approved eMandate (the ISO pain.012 message) and the signature on the eMandate.

9.3.1 Content of container element for new eMandates,  amendments or cancellations

The following table specifies the eMandate elements in the ISO pain.012 message that is placed inside the container. The Validation Service signature is also placed inside the container, in the supplementary data of the ISO message. Please see paragraph 11.2.1 for more information. It is essential that the Creditor stores both the ISO pain.012 message and the signature (including the certificate information), at least until 13 months after the last direct debit collection related to the eMandate. The pain.012 message is nearly identical for new eMandates and for eMandate, amendments and cancellations. The only difference is in the field 'Message Name Identification'; this element gets.

the value 'Issuing' when the original TransactionRequest had a pain.009 message. It gets the value 'Amendment' when the original TransactionRequest had a pain.010 message. It gets the value ‘Cancellation’ when the original TransactionRequest contained a pain.011 message.  

9.4 Errors during execution of Status Protocol

When using the Status Protocol to fetch the eMandate status, errors can occur as a result of which it is impossible for you to obtain the status of the transaction at that moment. It is therefore not possible to show the Debtor the final status of the transaction at that moment.
Recommended messages to show to Debtors are defined further on in this document.
In addition to this, we recommend informing your customer how he or she will be notified of the transaction status when it is known or where he or she can obtain that information (online).
You can then try to obtain the status through your Routing Service, in accordance with the guidelines. As soon as a definitive status has been received, you can notify the Debtor of the status of transaction in the following ways, for example:

• By e-mail.

• On your website, for example in the account of the Debtor or via the Debtor's browser session.

9.5 Collection duty

The Creditor has to initiate a StatusRequest when the Debtor returns to the page to which he was redirected by the Debtor Bank (the merchantReturnURL from the TransactionRequest). However, it is possible for the Debtor to close his browser before returning to this merchantReturnURL. It is mandatory for Creditors to perform a StatusRequest for every transaction, also in case the Debtor does not return to the Creditor's website. The eMandates protocol prescribes a so called "collection duty" for the result of every transaction. The Creditor can comply with this "collection duty" by performing a StatusRequest for every transaction when the expiration period has passed and no final status has been retrieved yet.

If the retrieved status of a transaction is "Open", the StatusRequest for this transaction has to be repeated after a short period of time. If the status of a transaction is "Pending", this means the transaction is awaiting multiple signing in the Debtor Bank domain. The status can then be requested once per day.

All other statuses (Cancelled, Expired, Success and Failure) are final statuses. Since these statuses cannot change anymore, it is not necessary (and not allowed) to perform another StatusRequest. To avoid unnecessary load on the eMandates systems, Creditors shall not perform unnecessary StatusRequests.

The following actions are never allowed:

• Request the status of a transaction more than 5 times before the expiration period has passed;

• Perform repeated StatusRequests with a time interval shorter than 60 seconds.

The following actions are not allowed after the expiration period has passed:

• Perform repeated StatusRequests with a time interval shorter than 60 minutes;

• Request the status of a transaction more than 5 times per day;

• Perform StatusRequests for transactions with a timestamp older than 14 days;

• Request the status of a transaction after the final status of the transaction has been received;

• Stop requesting the status of a transaction before the final status of the transaction has been received or before the timestamp is more than 14 days old.

Usually one of the final statuses or 'Pending' should be returned shortly after the expiration period. If the "Open" status is still returned after the expiration period, this can indicate a system failure. If this failure is not solved within 24 hours, please contact the Routing Service and stop sending StatusRequests.

Also when a Debtor does not return to your website because he does not appropriately complete or cancel the eMandates transaction, the Creditor must perform the Status Protocol after the expiration time has ended, to collect the final status at the eMandates Acquiring bank. As long as the returned status is "Open", the status request must be repeated at least once or several times during the day (see guidelines stated above). This will provide the Creditor the opportunity to update the order status.

When the returned status is "Success" the Creditor will be able to continue the transaction with the Debtor (e.g. deliver an ordered product or service). When the Debtor returns to your website inappropriately (e.g. using browser buttons to get back from the Debtor Bank's eMandate screens to the Creditor website) and decides to start a new eMandates transaction request, the Creditor must first try to collect the final status of the eMandates transaction that was initiated earlier, before sending a new TransactionRequest to the Routing Service.

9.6 Performance and time-out of status messages

The performance of the Debtor Bank/Validation Service and Routing Service systems has a direct influence on the Debtor's user experience. Therefore eMandates sets a target time and time-out for the status response message. For a Creditor the relevant target time and time-out concern the communication with its eMandates Routing Service:

_{Performance requirements (for the 95th percentile)*}

The target time is the time (in seconds) within which the Creditor should receive a StatusResponse message after sending a StatusRequest. The time-out is the length of time after which the Creditor should no longer expect a response (most likely an error has occurred) and should act accordingly (for example by displaying an appropriate error message to the Debtor).

*95^th percentile is a statistical term indicating that 95% of transactions in a tested sample should be within the set target time.

10. Error handling

10.1 General

If an error occurs while processing a DirectoryRequest, TransactionRequest or StatusRequest, for example because a request contains a invalid value, an ErrorResponse will be returned instead of the regular response. The ErrorResponse has the same structure for all three types of requests.

10.2 ErrorResponse

Instead of the regular response (DirectoryResponse, TransactionResponse of StatusResponse) the Routing Service will return an ErrorResponse if an error occurs during the reception or processing of the request, or if the request contains values that are not allowed or do not comply with the required format. Table 26 lists the fields that appear in the ErrorResponse. The error code list, errorDetail and consumerMessage can be found in APPENDIX B.

If the Routing Service detects an error inside the pain message (009, 010 or 011) in the container of the Transaction Request, the ErrorResponse will contain an ISO Pain.012 error response acceptance report. This message is shown in below table. In this case, the errorCode as specified in Appendix B will have the value AP3000. The pain.012 error acceptance report will have the status 'rejected' and it will also have a Reject Reason code. 

10.3 Non-availability

It might be possible that one of the Debtor Banks is temporarily unavailable. In this case transactions that have to be processed by this Debtor Bank will generate an ErrorResponse (see paragraph 10.2). When the Routing Service has determined unavailability at a Debtor Bank it will communicate this to the Debtor Bank immediately. This means that Creditor will never have to contact the Debtor Bank directly.
It might also be possible that the Routing Service itself is temporarily unavailable. In this case, unless the Creditor has more than one Routing Service, no eMandate transactions can be processed and the Routing Service will generate an ErrorResponse or time-out.
When the Creditor confirmation page is not working properly, we recommend displaying a clear error message to the Debtor.
Subsequently, we also recommend you to report the status of the eMandate transaction to the Debtor in one of the ways indicated below:

• By e-mail.

• On your website, in the Debtor's account

• On your website, as part of the session information of the order.

11. Security and certificates

11.1 General principles of certificates

For asymmetric encryption two keys are used: one public key and one private key. The public key is linked to the certificate and can be shared with anyone. The private key must be kept confidential by the owner of the certificate. The specific characteristics of the private and public part of the certificates will allow the encryption of a message with the public part while the result can be decrypted with the private part, and vice versa. It is not possible to decrypt a text with the same key that was used to encrypt it.

These specific characteristics enable two applications of certificate:

1. Encryption of a message. By encrypting a message with the public key of the receiving party the information can only be read by the recipient (who has sole knowledge of the private key).

2. Creating an electronic signature of a message. By encrypting the (hash of a) message with the private key, the recipient can determine the authenticity of the (sender of the) message by successfully decrypting the signature with the public part of the certificate. The recipient will also verify the integrity of the message to make sure the contents of the message was not changed by a third party.

The one-sided TLS connection that is used within eMandates between the Creditor and the Routing Service is based on the first application. The TLS connection uses at least 128-bit encryption based on a server side certificate of the Routing Service.

Since eMandates does not put any constraints on the communication between the Debtor and the Creditor, this can be either with or without a TLS connection. Creditors are advised, however, to always use TLS on the transaction pages of their website. The eMandates standard also uses electronic signatures to ensure the authenticity, integrity and non- repudiation of all messages with the exception of redirects. The electronic signature of the Routing Service in the StatusResponse message, for example, enables the Creditor to verify the authenticity of the transaction confirmation.

11.2 Signing eMandates messages

All messages that are sent by the Creditor to the Routing Service (DirectoryRequest, TransactionRequest and StatusRequest) have to be signed by the Creditor. Messages are signed in accordance with the "XML Signature Syntax and Processing (2^nd Edition) W3C Recommendation" of 10 June 2008 +http://www.w3.org/TR/xmldsig-core/+ , with the following settings and restrictions applied:

1. The entire XML message XML Signature reference to the signed info URI is left blank, see example messages in APPENDIX C must be signed.

2. For the purpose of generating the digest of the main message, the exclusive +http://www.w3.org/2001/10/xml-exc-c14n+ canonicalization algorithm must be used.

3. For the purpose of generating the signature value, the exclusive +http://www.w3.org/2001/10/xml-exc-c14n+ canonicalization algorithm must be used.

4. The syntax for an enveloped +http://www.w3.org/TR/xmldsig-core/#sec-EnvelopedSignature+ signature must be used. The signature itself must be removed from the XML message using the default transformation prescribed for this purpose.

5. For hashing purposes the SHA-256 +http://www.w3.org/2001/04/xmlenc#sha256+ algorithm must be used.

6. For signature purposes the RSAWithSHA256 +http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/#sec-SHA256+ algorithm must be used. RSA keys must be 2,048 bits long.

7. The public key must be referenced using a fingerprint of an X.509 certificate. The fingerprint must be calculated according to the following formula HEX(SHA-1(DER certificate)) See example messages in APPENDIX C .

In general Creditors don't need to have extensive knowledge of RSA since most programming languages have libraries available that implement XML Digital Signature processing. It is strongly recommended to use these standard libraries. Standard functionality for creation and verification of RSAWithSHA256 digital signatures is available in commonly used software platforms, from the following versions and higher: PHP version 5.3.0, Microsoft .NET version 3.5 sp1 and Java version 1.6 u18.

This functionality may also be available in earlier versions of these platforms and in other platforms (e.g. Python, Ruby).

For information about creating the public and private key pair please refer to paragraph 11.4.

11.2.1 Signing of the ISO pain.012 acceptance report

Next to the regular signing of the entire XML message, the ISO message (that is placed inside the container element) is separately signed by the Debtor Bank (only for the status 'Success'). This Debtor Bank signature remains in place during the lifespan of the eMandate, as it is the signature that can be checked to verify integrity and authenticity of the eMandate by the Debtor Bank at a later time in case of a dispute (MOI). It is essential that this remains the Debtor Bank's signature, as the Debtor Bank has signed the eMandate 'on behalf of the Debtor'.

• This signing follows the same requirements that apply to signing of the entire XML message, except for the following: Instead of referring to the certificate to be used for verifying the signature by fingerprint, the entire certificate is included in the Signature in the X509Certificate element that is contained in the X509Data element in the KeyInfo element. This is done to guarantee availability of the certificate to check the signature in case of a dispute after many years.

• The signature can only be validated when the ISO message is taken out of the XML container element, using exclusive canonicalization. Validation will fail when the ISO message is still embedded. Reason for this is the implicit reference from the signature to the <Document> element.

11.3 Authentication of eMandates messages

To ensure the status of a transaction, the Creditor has to verify the signature of the Routing Service in the Response messages. If the status is "success" the electronic signature in the pain.012 message should also be verified, to ensure the validity of the message.

To verify the signature in the SignatureValue field, it is recommended that Creditors use standard XML Digital Signature libraries, which are available in most (web) programming languages.

11.4 Creating a key pair

If you want to use a so-called "self signed certificate" this paragraph will explain how to do so. It is also possible to purchase a certificate at a company specialized in this field (Certificate Authority), see paragraph 11.4.1.
In order to create a public and a private key execute the following steps:

1. Download the "OpenSSL Library" from http://www.openssl.org. You can find more information on the "certificate generating utility" at: http://www.openssl.org/docs/apps/req.html. You may also generate the key pair using other software. If so please use the manual that comes with your software.

2. Generate an "RSA private key" using the following command (choose your own password for the field [privateKeyPass]):

   openssl genrsa –aes128 –out priv.pem –passout pass:[privateKeyPass] 2048
    

3. Create a certificate based on the "RSA private key" (use the same password as in the previous step for the field [privateKeyPass]): 
   
   openssl req –x509 –sha256 –new –key priv.pem –passin pass:[privateKeyPass] -days 1825 –out cert.cer
   
   
   

4. The previous OpenSSL command will generate a certificate in X.509 format, with a validity period of 5 years (1825 days), the maximum for eMandates signing certificates.

5. The file priv.pem contains the private key. The file cert.cer contains the certificate with the public key. The Creditor has to keep the priv.pem file private, which is used in the RSA encryption. The cert.cer file has to be communicated to the Routing Service. The method of communication will depend on the Routing Service.

11.4.1 Buying a certificate from a Certificate Authority

When buying a certificate from a Certificate Authority (CA), rather than generating the certificate yourself it is important to note the following: the CA signing certificate (and the rest of the certificate chain) must use hashing algorithms and key lengths that are at least as secure or better than those of the Creditor certificate.

Therefore CA-certificates used to sign certificates for electronic signatures must use at least SHA-256 for hashing and 2,048 bits for RSA keys.

Signing certificates should also have a maximum validity period of 5 years.

12. Presentation

12.1 General

There are some requirements regarding the presentation of eMandates on the Creditor's website. The main purpose of these requirements is to create a uniform user experience for Debtors whenever they use eMandates, regardless which Creditor's website they use. The requirements are further explained in the following paragraphs.

The front-end communication to the Debtor is based on the following primary relationships and responsibilities:

• A Debtor chooses to 'mandate' the Creditor for a one off or recurring SEPA Direct Debit by means of an eMandate.

• The Creditor offers the Debtor the possibility to choose eMandates as a method to 'mandate' the Creditor to execute a (one off or recurring) Direct Debit.

• The Validation Service of the Debtor Bank offers the Debtor the ability to authenticate himself and to approve the eMandate. The Debtor Bank bears primary responsibility for the eMandate approval process and for the related communication to the Debtor.

A Creditor that accepts eMandates has to place the eMandates payment method in its list of offered payment methods, in such a way that it is a logical step in the Creditor's online process.

The eMandates payment method must be presented in the list of payment methods in such a way that it receives at least the same amount of attention as other payment methods.

12.2 Incassomachtigen via uw bank-button

It must be clear for the Debtor how and when eMandates has been chosen by the Debtor. This is achieved by displaying an eMandates button, generally on that part of the page where one of the payment methods is normally selected. It must be clear for the Debtor that he is making use of eMandates B2B. The eMandates button must have the text:
'Incassomachtigen Zakelijk via uw bank'.

12.3 Transaction flow

When the 'Incassomachtigen via uw bank' button is clicked, the Debtor should immediately be presented with the Debtor Bank selection list without any intermediate screens being displayed by the Creditor (e.g. Debtor login and/or registration screens). And when the Debtor has selected the required Debtor bank, he should be immediately redirected to the online bank environment of the selected Debtor Bank (based on the issuerAuthenticationURL the Creditor has received in the TransactionResponse).

12.4 Redirect to Debtor Bank

The Creditor needs to perform the redirect to the Debtor Bank, from the browser window where the Debtor selected the Debtor Bank. The complete page of the Creditor shall be replaced by the complete page of the selected bank. Therefore it is not allowed to open the redirect to the Debtor Bank in a new browser window. It is however allowed to open a new window, with visible address bar, before the Debtor selects his bank from the Debtor Bank list.

12.5 Frames

Frames used on the Creditor's site are allowed. The page of the Debtor Bank will remove these frames using a frame busting technique. This will allow the Debtor to verify whether the transaction is really taking place at the bank chosen from the Debtor Bank list. After the redirect to the Creditor the Creditor shall completely rebuild the Creditor page to show the Creditor's confirmation of reception of the (amended) eMandate.

12.6 New Window

The eMandates transaction may take place in a new browser window, as long as the Creditor will have this window appear at (or before) the moment the Debtor chooses the transaction method. A new window is only allowed if initiated by the Debtor (no pop-ups are allowed). The complete transaction flow must take place in this window, including the Creditor's confirmation of receiving the eMandate. The new window must also contain an address bar that allows the Debtor to check the Internet address URL and SSL-certificate of the Debtor Bank. During the transaction flow it should not be possible for the Debtor to initiate another transaction through the Creditor's original browser window.

12.7 Debtor Bank list

The Debtor Bank list has to be presented as described in paragraph 7.4.

12.8 'Incassomachtigen via uw bank' banners and logo's

The eMandates logo can be found in the eMandates style guide, available at http://www.incassomachtigen.nl/wp-uploads/HandleidingHuisstijl_2_1.pdf.

12.9 Explaining eMandates to Debtors

Merchants that want to provide specific help and instructions to Debtors regarding eMandates are advised to use the following text:

How does 'Incassomachtigen via uw bank' work?

A few simple steps is all it takes to pay using 'Incassomachtigen via uw bank':

• Place your order

• Select 'Zakelijk Incassomachtigen via uw bank' as your payment method

• Select your bank

• This opens the familiar (mobile) banking environment or mobile app of your own bank

• The relevant details of your eMandate will already be shown

• You approve the eMandate in the way you are accustomed to at your bank

• Your bank confirms your eMandate and you can email it or download it

• You return to this website – eMandate accepted and you can continue shopping

Dutch version

Hoe werkt 'Zakelijk Incassomachtigen via uw bank?

U kunt in een paar eenvoudige stappen betalen met 'Incassomachtigen via uw bank'

• U bestelt een product of dienst

• Selecteer 'Zakelijk Incassomachtigen via uw bank' als uw betaalmethode

• Selecteer de bank waar u de rekening heeft waar u de machtiging op wilt afgeven

• U komt direct in de (mobiele) bankieromgeving of app van uw bank

• De relevante gegevens van uw machtiging zijn al ingevuld

• Op de voor u bekende manier keurt u de machtiging goed

• Uw bank bevestigt de Incassomachtiging en u kunt het emailen of downloaden

• U keert terug naar deze website. De machtiging is geaccepteerd en u kunt weer verder winkelen

12.10 Creditor front-end

The Creditor bears primary responsibility for initiating the Business to Business eMandate process and for the communication to the Debtor regarding the status of the eMandate.

• A Creditor must make sure in the design of his implementation that the eMandates solution and the start of an eMandate process are recognisable as such. The Creditor must also distinguish clearly between the process of issuing a new eMandate and the process, amending  or cancelling an existing eMandate.

• Creditors who accept eMandates must include the eMandates solution in their lists of payment methods (if any).

• The eMandates solution must be presented in the list of methods in such a way that it receives at least the same amount of attention as other payment methods.

• It must be clear for the Debtor that an eMandates transaction is going to start.

The Creditor must offer the Debtor three eMandate-functionalities:

1. Issuing a new eMandate
   A new eMandate can be issued for example when the Creditor gets a new customer (Debtor) or when an existing customer (Debtor) needs to issue a new mandate due to additional (new) products or services.

2. Amending an existing eMandate
   Amending an existing eMandate is done only when the Debtor wishes to change his account number (within the same Bank or to a different Bank). Other Debtor changes (such as address changes) and Creditor changes are not relevant to the eMandate.

3. Cancelling an existing eMandate
   The Debtor can choose to cancel an existing eMandate. The Creditor must notify the Debtor to choose the bank at which the eMandate is currently registered. The Debtor is redirected to the Debtor Bank to validate the cancellation.

The Creditor must clearly indicate to the Debtor whether he is issuing a new eMandate or amending/Cancelling an existing eMandate.
Cancelling an eMandate is done directly between Debtor and Creditor, without validation in the Debtor Bank domain.

12.11 Debtor Bank front-end

All eMandate related information (i.e. eMandate information, Debtor information, Creditor information and Signer information), with the exception of the Debtor Reference number (klantnummer), is presented to the Debtor for approval by the Validation Service.
In detail, the following information is shown to the Debtor for approval:

Creditor information

• Creditor.Name

• Creditor.TradeName (optional)

• Creditor.AddressLine1

• Creditor.AddressLine2

• Creditor.Country

• Creditor.CreditorID

Debtor information

• Debtor.IBAN

• Debtor.AccountName

eMandate information

• eMandate.eMandateID

• eMandate.Reason (optional)

• eMandate.SequenceType

• eMandate.MaxAmount (optional) 
  For new eMandates, If the Creditor hasn’t included a maximum amount in the eMandate TransactionRequest, the Debtor Bank allows the Debtor to fill out a maximum amount. This maximum amount is added to the ISO pain.012 message. For eMandate amendments, the Creditor is not allowed to include a maximum amount in the pain.010 message. The Debtor Bank shows the maximum amount value from it’s registration list and allows the Debtor to adjust this value..

• eMandate.PurchaseID (optional)

• The term 'SEPA' must be mentioned on the eMandate

Signer-information

• Debtor.SignerName

The following screenshots show examples of Validation Service eMandate approval website or mobile app screen for one-off eMandates, with Creditor.TradeName (Figure 5), and an example of the confirmation screen following approval of the eMandate proposal by the Debtor (figure 6). Please note that these are example screens and are for illustration purposes only.

 

After approval, the Validation Service shows the complete eMandate to the Debtor. The Debtor can print, email or save the eMandate to his computer (Figure 6). Upon the redirect from Debtor Bank to the Creditor's website, the Creditor shows a message to the Debtor indicating whether the eMandate process was successful (e.g. "We have successfully received the eMandate / We hebben uw machtiging succesvol ontvangen" or "We have not yet received confirmation of the eMandate / We hebben nog geen bevestiging van het eMandate ontvangen"). There is no obligation for the Creditor to show the eMandate contents to the Debtor at this point.
 

_{13. eMandates and direct debit}

In this chapter the relation between eMandates and the collection of direct debits is explained, as well as the relation with the Dutch Overstapservice (Debtors can use this service to change the account number for all of their mandates at once).

13.1 Initiating direct debits

It is important to note that eMandates is not a means of pre-notification; this still needs to take place.The document "XML message for SEPA Direct Debit Initiation Implementation Guidelines for The Netherlands" of the Dutch Payments Association describes the requirements to the pain.008 XML message that is used to initiate direct debits.When a direct debit collection is based on an eMandate, the direct debit contains several values from the pain.012 status response (the eMandate). The elements from the pain.012 status response that are used are:

• eMandate.eMandateID - The eMandateID that is determined by the Creditor

• Debtor.AccountName - The name of the account holder as it is known at his bank.

• Debtor.IBAN - The account number of the Debtor, which the Creditor is authorised to collect directs debits from.

• ValidationService.ValidationReference - Reference to the signing of the eMandate by the Debtor, generated by the Debtor Bank.

• eMandate.DateTimestamp - The timestamp of signing of the eMandate by the Debtor, generated by the Debtor Bank. Note: In the pain.008 direct debit collection message only the date of the eMandate.DateTimestamp must be included.

Chapter 9.3.1 shows where the relevant elements can be found in the pain.012 message. Table 28 shows where in the pain.008 direct debit initiation message these elements are placed.

_{Mapping of pain.012 elements to pain.008 direct debit initiation message}

In the event that an eMandate is amended via the eMandates amendment process, this is processed in the direct debit collection message in the same manner as when a paper mandate would be amended.

Business direct debits are checked against the Debtor Bank’s mandate registration. When the Debtor issues/amends/cancels an  Mandate, the Debtor Bank immediately uses this information to update the mandate registration. This way, Creditors can initiate the  direct debit collection process immediately upon reception of the pain.012 message.

13.2 Relation with the Overstapservice

When the Debtor uses the Overstapservice, the Creditor is informed of the change of the Debtor's account number. The Creditor saves the transfer data together with the original eMandate. The Debtor does not have to issue a new eMandate, nor amend the existing eMandate. The Debtor does have to re-register each mandate at his new Debtor Bank.

Alternatively, Instead of using the Overstapservice, a Debtor can also choose to use the amendment-functionality of eMandates. This allows the Debtor to change each eMandate individually. In this case, the eMandate is automatically added to the eMandate registration of the new Debtor Bank.

APPENDIX A: Container content overview

The eMandate information is in the ISO messages that are put inside the container element. The following tables give an overview of the ISO pain message content in the container of the messages for new eMandates and for eMandate amendments.

APPENDIX B: Error codes

Categories

The Error.errorCode is composed of:

• A category (two letters)

• A number (four digits)

The following categories are distinguished:

_{Error code categories}

Error codes

^{Error codes}

The following Reject reason codes are used in the ISO pain.012 error acceptance message.

^{Reject reason codes}

Source: ISO External Code Sets spreadsheet (subset of ISO reason codes)

ConsumerMessage

The consumerMessage can contain 1 of four different standardised texts that are sent to the Creditor by the Routing Service. The Creditor must show the consumerMessage to the Debtor on his website.

The value of consumerMessage is specified in AcquirerErrorRes (X') by the Acquirer based on the criteria described in the following table:

^{consumerMessage}

APPENDIX C: Message examples

Most of the example messages given here only use the default method of namespace declaration. At the end of the appendix one example is given of a message with namespace prefixes (this message does not contain an information container, it is merely meant to signify the use of namespace prefixes).

APPENDIX D: iDx XML Schema