SEPA DIRECT DEBIT CORE RULEBOOK CHANGE REQUEST - PUBLIC CONSULTATION DOCUMENT COVER PAGE

Transcription

1 EPC Version April 2016 SEPA DIRECT DEBIT CORE RULEBOOK CHANGE REQUEST - PUBLIC CONSULTATION DOCUMENT COVER PAGE The Single Euro Payments Area (SEPA) payment schemes, as set out in the SEPA Credit Transfer (SCT), the SEPA Direct Debit Core (SDD Core) and the SEPA Direct Debit Business to Business (SDD B2B) Scheme Rulebooks, evolve based on a transparent change management process adhered to by the European Payments Council (EPC). For details on the principles governing the EPC scheme change management process, we refer to sections 5, 6 and 7 in this document and the sources listed at the end of this page. This SDD Core 2016 Change Request consultation document (document EPC012-16) details change requests for possible modifications to be introduced into the next version of the SDD Core Scheme Rulebook. This consultation document builds on change requests submitted by stakeholder representatives, banking communities and by EPC Working and Support Groups. The SDD Core 2016 Change Request consultation document offers the analyses and recommendations of the EPC Scheme Evolution and Maintenance Working Group (SEMWG) on the way forward with regard to individual change requests. A summary overview of the change requests and related recommendations by the SEMWG is provided in section 1 of this Change Request consultation document. The EPC submits the SDD Core 2016 Change Request consultation document for public consultation. The public consultation takes place between 5 April and 4 July All Scheme participants and stakeholders are encouraged to provide feedback on the possible changes to be introduced into the next version of the SDD Core Scheme Rulebook by completing the response template EPC and send it to change-request.epc-scheme@epc-cep.eu by 4 July 2016 at the latest. Proposed changes detailed in this SDD Core 2016 Change Request consultation document, which are broadly accepted by all Scheme participants and stakeholders, and that are technically and legally feasible, will be taken forward, after approval by the Scheme Management Board (the EPC decision-making body in charge of the schemes administration and evolution). Others will not be retained. The updated version of the SDD Core Scheme Rulebook will be published in November 2016 for implementation in November In accordance with industry best practice, payment service providers and their suppliers have a one-year lead time to address rulebook updates prior to such updates taking effect. More information about the maintenance and the evolution of the SDD Core Scheme is available in Chapter 4 of the Scheme Management Internal Rules (the Internal Rules) being a binding Annex to the current applicable SDD Core Scheme Rulebook. It should be noted that the EPC is under the legal obligation to ensure compliance of the Rulebook with existing EU legislations or to any new EU legislation impacting this Rulebook. Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

2 Therefore, the EPC reserves the right to make necessary changes to the Rulebook at all times in order to ensure that the Rulebook does comply with changes to existing EU legislation or with the entry into force of any new EU legislation. Please refer to Annex 1 for the original detailed change requests. This document contains only a summary of each individual change request. EPC SDD Core Rulebook Change Request Consultation Document 2

3 TABLE OF CONTENTS 1. Executive Summary: Change requests for Major Changes to the SEPA Direct Debit Core Rulebook Detailed Analysis of Change requests for Major Changes to the SDD Core Rulebook # 2: Reference to separate EPC guide on SDD r-transaction reason codes # 3: Additional r-transaction reasons under 'Return' for AT-R # 4: Inclusion of SDD r-transaction type Reversal and r-transaction reasons # 6: Removal of Annex IX Advance Mandate Information (AMI) # 7: Review of SDD Annex VII 'e-mandates' linked to BIC debtor bank # 8: Mandatory Customer-to-Bank (C2B) Implementation Guidelines (IGs) # 9: Mandate amendment for change of creditor identifier # 10: Usage rules for the exchange rate for SDD Core Refunds # 12: Implementation of the purpose code 'IBAN Check Failed' for all SEPA payments # 13: Extension of the use of existing technical r-transaction reason codes and the introduction of new technical r-transaction reason codes for specific pain and pacs messages # 14: Assign clear responsibilities to scheme participants and CSMs for executing those SEPA Usage Rules defined in the interbank Implementation Guidelines # 15: Additional SDD r-tx reason codes for debtor driven reasonswhitelisting # 17: The introduction of LEI in the EPC SEPA schemes # 18: Request for clarification on the version of the ISO pain messages in the Rulebooks # 25: Clarification in business requirements for AT-22 for structured remittance info # 26: Allow contemporaneous presence of Unstructured and Structured remittance info in payment messages # 27: Additional clarification on the content (with examples) to be inserted in AT-27, AT-37 and AT # 28: Amendment of attributes present in DS-06 "Bank to Customer Direct Debit Information" and business rules for debtor PSPs # 30: Extension of the reversal period for the creditor from 5 days to 10 inter-bank business days # 32: Amendment to Chapter '1.4 Character Set' of the Customer-to-Bank and Inter-Bank IGs # 34: Make AT-59 'category purpose of the collection' mandatory instead of optional # 36: Amendment to section 2.1 of the Scheme Management Internal Rules (SMIRs) # 37: Making storage location for additional customer-to-customer information available outside the payment transaction # 38: Amendments to section of the Scheme Management Internal Rules (SMIRs) and Rulebook section Changes pertaining to the impact of the SEPA Regulation or of any other EU Legislation Detailed Analysis of Minor Changes to the SDD Core Rulebook EPC SDD Core Rulebook Change Request Consultation Document 3

4 4.1. Proposed change Principles governing the Change Request Process Change Request Structure of the Change Request Change management process in respect of Major Changes Consideration of Change requests Change Request SEMWG recommendation Consultation on the Change Request Next steps Further information Change management process in respect of Minor Changes Publication of list of minor changes Comments on the minor changes Submission of the list of minor changes to the SMB Annex 1 - Original Change Requests EPC SDD Core Rulebook Change Request Consultation Document 4

5 1. EXECUTIVE SUMMARY: CHANGE REQUESTS FOR MAJOR CHANGES TO THE SEPA DIRECT DEBIT CORE RULEBOOK The principles governing the evolution of the Single Euro Payments Area (SEPA) payment schemes as set out in the SEPA Credit Transfer (SCT) and SEPA Direct Debit (SDD) Scheme Rulebooks are detailed in the SEPA Scheme Management Internal Rules (the Internal Rules). These Internal Rules are available for download on the European Payments Council (EPC) Website. Sections 5, 6 and 7 in this SDD Core 2016 Change Request consultation document detail the application of the Internal Rules in the EPC scheme change management process. The Internal Rules make a difference between so called major and minor changes to the scheme rulebooks. A major change is a change that affects or proposes to alter the substance of the rulebooks and the schemes. Any change to chapters 5 and 6 of the rulebooks are always considered a major change. A minor change is a change of an uncontroversial and usually technical nature that facilitates the comprehension and use of the rulebooks. This executive summary of the SDD Core 2016 Change Request consultation document highlights change requests for major changes to the SDD Core Rulebook received in this scheme change management cycle. Change requests for minor changes to the SDD Core Rulebook are set out in section 4 of this Change Request consultation document. All change requests to the SDD Core Rulebook are submitted for public consultation between 5 April and 4 July Information on how to share feedback with the EPC is included on the cover page of this Change Request consultation document. The EPC received 24 change requests for major changes to be introduced into the SDD Core Scheme Rulebook. The change requests submitted to the EPC are included in Annex 1 to this document. Various contributors suggest making changes to existing SDD r-transaction reasons. One change request describes the creation of new SDD r-transaction reason codes. Another change request proposes to include in the SDD Rulebook an explicit reference to the separate EPC guide on SDD r-transaction reason codes. A number of change requests is related to structured and unstructured remittance information proposing the combination of different types of such information but also clarification requests in the concerned business requirements when structured remittance information is used. Another change request deals with making additional customer-to-customer information available outside of the SDD collection message. A further contribution proposes to turn the current recommended-only Customer-to- Bank Implementation Guidelines (C2B IGs) into mandatory IGs. This change request stems from a recommendation made by the Euro Retail Payments Board (ERPB) at the end of Amendments to the character set in the C2B and inter-bank IGs are proposed to increase the use of national characters in SDD collections. The idea is to extend the current limited SEPA character set in the interbank pacs messages to the UTF-8 character set. Change requests have also been submitted to improve the counterparty identification of the SDD collection by transmitting more data attributes in the SDD collection message and by clarifying the purpose of certain SDD data attributes. EPC SDD Core Rulebook Change Request Consultation Document 5

6 Another change request covers changes to the Internal Rules to make the scheme participant s obligations in the context of changes to the scheme participant s operational, contacting or invoicing details more explicit. A specific change request deals with the extension of the permitted timespan for SDD collection reversals. Another request is to remove the Annex IX on Advance Mandate Information from the SDD Rulebook. All change requests to the SDD Core Rulebook received were reviewed by the EPC Scheme Evolution and Maintenance Working Group (SEMWG). These Change Requests include the recommendations of the SEMWG with regard to each of these change requests. Each recommendation reflects one of the options detailed in items a) through f) below: a) The change request is already provided for in the scheme. No action is necessary for the EPC. b) The change request should be incorporated into the scheme. The change request becomes part of the scheme and the rulebook is amended accordingly. c) The change request should be included in the scheme as an optional feature. The new feature is optional and the rulebook will be amended accordingly. Each scheme participant 1 may decide to offer the feature to its customers, or not. d) The change request is not considered fit for SEPA wide use and could be handled as an additional optional service (AOS) by interested communities. The proposed new feature is not included in the rulebook or in the implementation guidelines released by the EPC with regard to the rulebooks. The development of AOS is out of scope of the EPC. The EPC does however publish declared AOS arrangements on its website for information. The EPC may consider the inclusion of AOS arrangements, if supported by a sufficient number of communities, in a future version of the rulebook. e) The change request cannot be part of the existing scheme. It is technically impossible. It is not feasible (explained on a case by case basis). It is out of scope of the EPC. It does not comply with the SEPA Regulation 2 or any other relevant EU legislation. f) The change request may be considered for the development of a new scheme. The change request reflects major changes which cannot be integrated into an existing scheme 1 A scheme participant is a payment service provider which has formally adhered to a SEPA Scheme. 2 Regulation (EU) No 260/2012 establishing technical and business requirements for credit transfers and direct debits in euro and amending Regulation (EC) No 924/2009 EPC SDD Core Rulebook Change Request Consultation Document 6

7 To develop the change request further, i.e. to develop a new scheme, the following requirements should be met: The benefits of the new scheme for bank customers are demonstrated prior to the launch of the development phase. It is demonstrated that a sufficient number of stakeholders will make use of the new scheme. A cost-benefit analysis is provided. It complies with the SEPA Regulation or any other relevant Regulation. Summary of change requests and proposed way forward for consideration by respondents to this public consultation The below table lists all the received change requests which are submitted for public consultation. The SEMWG has issued a recommendation on the way forward with regard to each change request; the reasons underlying each recommendation are detailed in section 2. The final decision whether a change request will be incorporated into the rulebook is however subject to the outcome of the public consultation. The contributors to this public consultation are requested to indicate whether they agree with the recommendation of the SEMWG on the way forward. In case the contributors do not agree with the SEMWG recommendation, they are requested to indicate in the comments section of the response template EPC their preferred way forward (e.g., support of the original change request, selecting another option). Furthermore any additional comments are welcome in the comments section. Change Request item Topic Contributor Recommendation of the SEMWG on the proposed way forward. The final decision is subject to the outcome of the public consultation. 2 Reference to separate EPC guide on SDD r- transaction reason codes 3 Additional r-transaction reasons under 'Return' for AT-R3 4 This suggestion has been withdrawn by the contributor 6 Removal of Annex IX Advance Mandate Information (AMI) 7 Review of SDD Annex VII 'e-mandates' linked to BIC debtor bank SEMWG SEMWG SEMWG SEMWG Should be incorporated into the scheme - option b Should be incorporated into the scheme - option b WITHDRAWN Should be incorporated into the scheme - option b Should be incorporated into the scheme - option b EPC SDD Core Rulebook Change Request Consultation Document 7

8 Change Request item Topic Contributor Recommendation of the SEMWG on the proposed way forward. The final decision is subject to the outcome of the public consultation. 8 Mandatory Customerto-Bank (C2B) Implementation Guidelines (IGs) 9 Mandate amendment for change of creditor identifier 10 Usage rules for the exchange rate for SDD Core Refunds 12 Implementation of the purpose code 'IBAN Check Failed' for all SEPA payments 13 Extension of the use of existing technical r- transaction reason codes and the introduction of new technical r-transaction reason codes for specific pain and pacs messages 14 Assign clear responsibilities to scheme participants and CSMs for executing those SEPA Usage Rules defined in the interbank Implementation Guidelines 15 Additional SDD r-tx reason codes for debtor driven reasonswhitelisting 17 The introduction of LEI in the EPC SEPA schemes 18 Request for clarification on the version of the ISO pain messages in the Rulebooks SEMWG SEMWG Shahid Ali Equens Equens Equens Dutch Payments Association Club SEPA France Club SEPA France Should be incorporated into the scheme - option b Should be incorporated into the scheme - option b Cannot be part of the existing scheme option e Cannot be part of the existing scheme option e No SEMWG recommendation defined Cannot be part of the existing scheme option e Should be incorporated into the scheme - option b Cannot be part of the existing scheme option e Cannot be part of the existing scheme option e EPC SDD Core Rulebook Change Request Consultation Document 8

9 Change Request item Topic Contributor Recommendation of the SEMWG on the proposed way forward. The final decision is subject to the outcome of the public consultation. 25 Clarification in business requirements for AT-22 for structured remittance info 26 Allow contemporaneous presence of Unstructured and Structured remittance info in payment messages 27 Additional clarification on the content (with examples) to be inserted in AT-27, AT- 37 and AT Amendment of attributes present in DS-06 "Bank to Customer Direct Debit Information" and business rules for debtor PSPs 30 Extension of the reversal period for the creditor from 5 days to 10 inter-bank business days 32 Amendment to Chapter '1.4 Character Set' of the Customer-to-Bank and Inter-Bank IGs 34 The category purpose of the collection (AT- 59) to become mandatory 36 Amendment to section 2.1 of the Scheme Management Internal Rules (SMIRs) EACT EACT EACT EACT Spanish banking community German Banking Industry Committee Portuguese banking community Starkeviciute Margarita No SEMWG recommendation defined Cannot be part of the existing scheme option e Cannot be part of the existing scheme option e Should be incorporated into the scheme (option b) with both fields as optional attributes. Cannot be part of the existing scheme option e Cannot be part of the existing scheme option e Cannot be part of the existing scheme option e Should be incorporated into the scheme - option b EPC SDD Core Rulebook Change Request Consultation Document 9

10 Change Request item Topic Contributor Recommendation of the SEMWG on the proposed way forward. The final decision is subject to the outcome of the public consultation. 37 Making storage location for additional customer-to-customer information available outside the payment transaction 38 Amendments to section of the Scheme Management Internal Rules (SMIRs) and Rulebook section 5.6 SEMWG EPC secretariat Should be incorporated into the scheme - option b Should be incorporated into the scheme - option b Summary of changes which will be included in the next version of the SDD Core Rulebook to align the rulebook with the SEPA Regulation or with any other relevant EU legislation (e.g., PSD) The contributors to this public consultation are welcome to comment on these changes. Ref. Topic Contributor Way forward At this point in time, no items have been identified that require a change to the rulebook due to any particular EU legislation EPC SDD Core Rulebook Change Request Consultation Document 10

11 2. DETAILED ANALYSIS OF CHANGE REQUESTS FOR MAJOR CHANGES TO THE SDD CORE RULEBOOK 2.1. # 2: Reference to separate EPC guide on SDD r-transaction reason codes Description This change request was made by the SEMWG. The EPC has published the document Guidance on Reason Codes for SDD R- transactions (EPC v2.1) on the EPC website. It eases the correct use of the various SDD r-transaction reason codes. The change request is that the SDD Core and the SDD B2B Rulebooks should formally refer to the document EPC The SDD Core and SDD B2B scheme participants can better monitor the correct use of the various SDD r-transaction reason codes as described in the document EPC and adjust, where necessary, their internal processes. The correct application of these reason codes by a debtor bank, informing a creditor bank, about a failed SDD collection is crucial for the creditor bank and the creditor to understand the cause of an unsuccessful SDD Core or SDD B2B collection and to undertake actions on how to solve the reported issue. The objective is that scheme participants are enabled using without doubt the correct SDD Core and SDD B2B r-transaction codes to maximise the straight-through processing rate of these exceptional transactions and to provide meaningful information up to the creditor and the creditor bank. The EPC considers that keeping the contents of EPC v2.1 outside the SDD Core and the SDD B2B Rulebooks allows more flexibility for the EPC to provide updated instructions with respect to SDD Core and SDD B2B r-transaction reasons and reason codes on a short notice SEMWG analysis and recommendation The SEMWG suggests incorporating the change request into the Scheme (option b) Rulebook impact If this change request is supported, this will impact only the Rulebook. EPC SDD Core Rulebook Change Request Consultation Document 11

12 2.2. # 3: Additional r-transaction reasons under 'Return' for AT-R Description This change request was made by the SEMWG. The SDD Core and the SDD B2B rulebooks list under attributes AT-R3 (refer to section in SDD Core Rulebook and to section in SDD B2B Rulebook) a number of r-transaction reasons under the r-transactions types Rejects and Returns when a SDD Core or SDD B2B collection has not been successfully completed. Both SDD rulebooks specify that the r-transaction reason Bank identifier incorrect (i.e. invalid BIC) and Operation code/transaction code/sequence type incorrect, invalid File format can only be used to reject a SDD collection (i.e. the collection diverted from normal execution, prior to interbank settlement) but not to return a SDD collection (i.e. after interbank settlement). However, it may occur that the final SDD settlement files contain valid IBANs but the BIC related to these IBANs do not belong to the debtor bank, a collection indicates Recurrent even though the mandate indicated a One-off SDD collection or the identification code of the scheme specified in the message is incorrect. The SCT rulebook already allows the use of the r-transaction reason Bank identifier incorrect (i.e. invalid BIC) for both rejecting and returning a SCT transaction (see AT- R3 in section 4.6 of the SCT Rulebook). The EPC proposes to foresee the use of the r-transaction reason Bank identifier incorrect (i.e. invalid BIC) and Operation code/transaction code/sequence type incorrect, invalid File format also for returning a SDD collection. The ISO reason codes RC01 and AG02 can be used SEMWG analysis and recommendation The SEMWG suggests incorporating the change request into the Scheme (option b) Rulebook impact If this change request is supported, this will impact the Rulebook and the interbank Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 12

13 2.3. # 4: Inclusion of SDD r-transaction type Reversal and r-transaction reasons Description This change request has been withdrawn. EPC SDD Core Rulebook Change Request Consultation Document 13

14 2.4. # 6: Removal of Annex IX Advance Mandate Information (AMI) Description This change request was made by the SEMWG. The annex IX Advance Mandate Information (AMI) had been added as an option in the SDD Core rulebook version 5.0 and in the SDD B2B rulebook version 3.0. Both rulebook versions were published in November 2010 with an effectiveness date of 19 November More than five years after the publication of Annex IX as an option to the two SDD rulebooks, none of the SDD scheme participants have informed the EPC directly that they used this option at a given moment in the past years, or that they currently use it or that they intend to use it in the future. Feedback received from the members of the SEMWG in October 2015 highlighted that no SDD scheme participant currently uses this option. There is no market demand for this option. Based on this input, the EPC proposes to remove Annex IX completely from the two SDD rulebooks SEMWG analysis and recommendation The SEMWG suggests removing the annex IX from the Scheme (option b) Rulebook impact If this change request is supported, this will impact the Rulebook (removal of the Annex IX) and the removal of the AMI Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 14

15 2.5. # 7: Review of SDD Annex VII 'e-mandates' linked to BIC debtor bank Description This change request was made by the SEMWG. The delivery of the BIC of the Debtor Bank in SDD transactions is optional as of 1 February 2016 when the Creditor Bank and the Debtor Bank are based in different countries of the EEA. This means that as of the above-mentioned respective dates and cases, the debtor does not need to mention the BIC of the payment service provider (PSP) holding his/her payment account, on a SDD Core or SDD B2B mandate. The provision of the BIC of the Debtor Bank in SDD transactions remains mandatory when the Creditor Bank or the Debtor Bank is located in a non-eea SEPA country. In this case, the debtor will still have to provide the BIC of the PSP holding his/her payment account, on the SDD Core or SDD B2B mandate. With respect above-mentioned changes in the provision of the BIC of the debtor bank, the EPC has done a review of Annex VII describing the e-mandate option for the two SDD rulebooks and proposes a number of changes to the Annex VII SEMWG analysis and recommendation The SEMWG suggests incorporating the change request into the Scheme (option b) Rulebook impact If this change request is supported, this will impact the Annex VII of the Rulebook and the e-mandate Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 15

16 2.6. # 8: Mandatory Customer-to-Bank (C2B) Implementation Guidelines (IGs) Description This change request was made by the SEMWG. In 2014, the Euro Retail Payments Board (ERPB) noted that various SEPA countries and EPC scheme participants have created their own configurations ( subsets ) of the XMLbased SEPA payment messages in the Customer-to-Bank (C2B) space. Corporate customers which transact in various countries and/or with different Payment Service Provider (PSP) partners need to implement these customer-to-bank (C2B) interface subsets. The ERPB meeting on 1 December 2014 agreed to support the publication and the use of the EPC s current C2B Implementation Guidelines (IGs) by all market participants. The ERPB recommends making the EPC s C2B IGs mandatory in the next EPC SEPA rulebook change management cycle (reference is made to the recommendation ERPB/2014/rec1). The EPC proposes that a scheme participant is obliged to accept at least but not exclusively C2B SEPA payment message files based on the EPC s C2B SEPA scheme IGs defined for SCT, SDD Core and SDD B2B. Creditor banks would still be free to agree with their creditors to use any other ISO XML payment message standard format to submit their C2B SEPA payment message files to their PSPs. This means that customers will still have the choice either to continue using their accepted C2B file set-up or to opt for the C2B file based on EPC specifications. On the other hand, the scheme participants will have to be technically capable of supporting the EPC C2B file specifications SEMWG analysis and recommendation The SEMWG suggests incorporating the change request into the Scheme (option b) Rulebook impact If this change request is supported, this will impact both the Rulebook and the C2B Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 16

17 2.7. # 9: Mandate amendment for change of creditor identifier Description This change request was made by the SEMWG. Section of both SDD rulebooks describes the mandate amendment process (PR- 02). The attribute AT-24 in section 4.8 lists the reasons for such a mandate amendment. Comparing the process step PT under section with AT-24, a terminology inconsistency is noted. The use of the different terms identity and identifier may cause confusion. The change request is to change the wording in the process step PT under section SEMWG analysis and recommendation The SEMWG suggests incorporating the change request into the Scheme (option b) Rulebook impact If this change request is supported, this will impact only the Rulebook. EPC SDD Core Rulebook Change Request Consultation Document 17

18 2.8. # 10: Usage rules for the exchange rate for SDD Core Refunds Description This change request was made by Mr Ali Shahid. For a non-euro account, a currency exchange is applied when a SDD debit happens for the debtor. When the debtor claims a refund due to dispute or wrong collection, a currency exchange is again applied for this refund. A debtor bank has two options to handle a SDD refund on non-euro account - Refund using same exchange rate as used when the SDD collection was done - Take the on-going market rate at both the SDD collection and the refund The change request is to use the same exchange rate at for both the SDD collection and the SDD refund. For the loss the debtor bank may suffer due to exchange fluctuation, the debtor bank should have the option to take more return amount by either using interchange fees or the use of a new exchange margin attribute. A proper indicator must exist in the inter-bank refund message to give exchange fluctuation deduction information to make the solution transparent. The contributor suggests introducing a dedicated attribute to mention the exchange rate and as a minimum to add information in the rulebook for the usage of interchange fees to manage exchange fluctuation for refund SEMWG analysis and recommendation The SEMWG recommends not taking forward the change request (option e). The change request is out of the scope of the scheme. The SDD Core scheme is only a scheme for euro transactions and will not provide rules on any currency conversion. The rates applied for currency conversion from/to EUR are a commercial matter between the debtor bank and each of its debtors Rulebook impact If this change request is supported, this will impact both the Rulebook and the interbank Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 18

19 2.9. # 12: Implementation of the purpose code 'IBAN Check Failed' for all SEPA payments Description This change request was made by Equens. It shortly explains an option that was used in the legacy German domestic payment schemes. The option allowed that legacy payments whereby the check digits of the account number were not correct, could be still forwarded by the initiating bank by using some sort of text key extension (Textschlüsselergänzung 444). It is suggested to implement a purpose code for SEPA payments having a similar meaning to the German text key extension. This should be the code IBCF IBAN-check failed for all formats and can be filled by initiating bank. This may be defined to be a regional or national AOS SEMWG analysis and recommendation The SEMWG recommends not taking forward the change request (option e). The interbank arrangements for SCT and SDD transactions are now based on IBAN. The IBAN foresees already its own check feature, i.e. the IBAN account check-digit. This makes that the account identifiers in the national BANs are no longer used. The proposed sort of text key extension is not necessary Rulebook impact If this change request is supported, this will impact both the Rulebook and the interbank Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 19

20 2.10. # 13: Extension of the use of existing technical r-transaction reason codes and the introduction of new technical r-transaction reason codes for specific pain and pacs messages Description This change request was made by Equens. The contributor explains that every clearing mechanism defines its own error codes as the EPC rulebooks currently do not include many technical codes. These error codes are not included in the main interbank formats. This results into technical errors regularly being mapped to the reason code MS03 (= reason not specified) when forwarded to another participant. This leads to lack of clarity, misunderstandings, requests and repetition of the errors. The first change request is to implement the following reason codes: CNOR and DNOR for use in Pacs.004 to be used instead of MS03 DT01 Invalid Date for use in Pacs.002, Pacs.004 and Pain.002 instead of MS03 ED05 (= SettlementFailed) for use in the pacs.002 The second change request is to implement the ISO reason code NARR in combination with the XML field AdditionalInformation, currently a white field in the Implementation Guidelines, to be shaded yellow. If the reason code is NARR, then AddititionalInformation must be present. If the reason code is not NARR, then AddititionalInformation is optional in ISO. The code should be implemented for Pacs.002, Pacs.004 and Pain.002. This will make it easier for every participant to give detailed information about the reason for a r-transaction, especially for technical issues. The field AdditionalInformation should be allowed to be used in combination with the existing SEPA codes. An alternative to the second change request is to open up the Reason Proprietary field. Currently this is a white field, it should be shaded yellow. It can then be used for proprietary codes SEMWG analysis and recommendation The SEMWG does not propose a concrete recommendation for this change request for the public consultation. On the one hand, how the clearing mechanisms clear transactions and report clearing issues lies outside the scope of the EPC. On the other hand, the Rulebook does specify reason codes that can be used by clearing mechanisms. The SEMWG looks forward to the comments from the stakeholders taking part in the public consultation Rulebook impact If this change request is supported, this will impact both the Rulebook and the interbank Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 20

21 2.11. # 14: Assign clear responsibilities to scheme participants and CSMs for executing those SEPA Usage Rules defined in the interbank Implementation Guidelines Description This change request was made by Equens. The EPC Rulebooks currently define SEPA Usage Rules but not the responsibilities for executing these. All too often there is lack of clarity if a certain check/validation has to be done, can be done or must not be done by a participant that is not the Creditor Agent or Debtor Agent. The contributor provides a number of examples to highlight the current situation. The contributor states that it must be clear to all the parties involved in the processing chain who is responsible for which validation. EPC should define the responsibilities in general or for each SEPA Usage Rule in the Implementation Guidelines. The in-depth checks and validation should be performed exclusively by the bank of the end users. The other involved interbank players should only reject a payment if it is not possible to forward (e.g. format validations fail, BIC is not reachable) SEMWG analysis and recommendation The SEMWG recommends not taking forward the change request (option e). A discussion should first be held between the EPC and the SEPA scheme-compliant clearing and settlement mechanisms (CSMs) before further responsibilities can be assigned to CSMs through the Rulebook Rulebook impact If this change request is supported, this will impact both the Rulebook and the interbank Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 21

22 2.12. # 15: Additional SDD r-tx reason codes for debtor driven reasonswhitelisting Description This change request was made by the Dutch Payments Association. The SEPA regulation has made it obligatory to offer the debtor the option to be able to block his account for direct debit transactions if: Whitelist in use; creditor / mandate not (properly) listed Creditor blocked Maximum number of direct debit transactions within certain period is exceeded by the creditor Transaction exceeds maximum amount Creditors have requested their creditor banks to be informed in more detail when direct debit transactions are returned based on parameters set by the debtor. In case of a rejected direct debit collection, the creditor wants to be able to communicate this with the debtor based on the specific parameter set by the debtor. This requires more detailed information than presently via the reason code SL01. Debtor banks must be able to report more specific reason codes where today only SL01 is available. The contributor suggests introducing new reason codes in the Rulebook for each of the four (optional) consumer settings in order that all parties (in the 4-corner model) can be informed more appropriately to be able to act in line with the parameter used. These codes, to be used by debtor banks, will identify the following four reasons: Code Name Definition SL11 Creditor not on Whitelist of Debtor SL12 Creditor on Blacklist of Debtor SL13 Maximum number of Direct Debit Transactions exceeded SL14 Maximum Direct Debit Transaction Amount exceeded Whitelisting service offered by the Debtor Agent; Debtor has not included the Creditor on its Whitelist (yet). In the Whitelist the Debtor may list all allowed Creditors to debit Debtor bank account. Blacklisting service offered by the Debtor Agent; Debtor included the Creditor on his Blacklist. In the Blacklist the Debtor may list all Creditors not allowed to debit Debtor bank account Due to Maximum allowed Direct Debit Transactions per period service offered by the Debtor Agent Due to Maximum allowed Direct Debit Transaction amount service offered by the Debtor Agent EPC SDD Core Rulebook Change Request Consultation Document 22

23 SEMWG analysis and recommendation The SEMWG suggests incorporating the change request into the Scheme (option b) provided that Debtor Banks are allowed to mention such more specific reason codes under national data protection laws and/or that debtor banks are technically capable to transmit more detailed reason codes than just SL Rulebook impact If this change request is supported, this will impact both the Rulebook and the interbank Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 23

24 2.13. # 17: The introduction of LEI in the EPC SEPA schemes Description This change request was made by Club SEPA France. The contributor questions the functional and organizational impact of an introduction of the Legal Entity Identifier (LEI) in the SEPA schemes SEMWG analysis and recommendation The SEMWG does not consider this item as a formal change request. The SEMWG recommends not introducing the LEI in the next version of the SCT and the SDD Rulebooks (option e). The Euro Retail Payments Board (ERPB) meeting on 1 December 2014 agreed on the recommendation for the EPC (supported by the ECB and standardisation authorities) to look for more appropriate attributes in a long term perspective (e.g., LEI as a unique entity identifier) to identify especially a SDD creditor (reference is made to the recommendation ERPB/2014/rec13). The EPC has made a first internal analysis about the potential added value of the LEI in the SDD and the SCT schemes. The EPC currently considers that it is too soon to include an attribute for the LEI in the EPC rulebooks. The number of LEIs currently issued to SDD creditors is very low compared to the current number of SDD creditors. Once the LEI is broadly used by corporate legal entities, the EPC is of the opinion that the SDD rulebooks (and maybe even the SCT rulebook) could be adapted to foresee the use of the LEI. In the third quarter of 2015, the EPC Scheme End-User Forum (SEUF) and the EPC Scheme Technical Forum (ESTF) had been consulted for their positions on the LEI. The following main comments were made: - The LEI might not be the right code but a fiscal code or VAT code could be a reliable alternative. - The number of LEIs currently issued to creditors is very low compared to the current number of creditors. - The LEI cannot replace the SDD Creditor Identifier as the LEI cannot be assigned to private creditors. - The attribute of the LEI is not foreseen in the ISO XML message versions used for SCT and SDD transactions. An adaptation via a new version of these ISO XML message versions would be needed. The approved minutes of the two EPC Stakeholder Forum meetings are available on the SEUF and the ESTF webpages. The EPC will review the issue in 2017 on the basis of the latest LEI developments Rulebook impact If this change request is supported, this will impact the Rulebook, the C2B and interbank Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 24

25 2.14. # 18: Request for clarification on the version of the ISO pain messages in the Rulebooks Description This change request was made by Club SEPA France. The contributor questions whether the mentioning of the pain message version in the Customer-to-Bank (C2B) Implementation Guidelines means that this version is mandatory. The contributor suggests deleting any reference to the number of version attached to the pain message because it can cause confusion and sometimes there can also be a technical gap. It would prevent the PSP to offer formats based on the latest formats because some stakeholders assume that only the version listed in the C2B Implementation Guidelines is applicable. The change request illustrates with some examples the issue SEMWG analysis and recommendation The SEMWG does not consider this item as a formal change request. The SEMWG recommends not taking forward the change request (option e). The C2B IGs are based on the 2009 version of the ISO XML pain format as indicated on the first page of the IGs (see abstract ) and in the introduction section. This gives scheme participants and the originators a basis to adapt their processing systems and ERP systems to process payment files according to the rulebook. The scheme participants are however free to support more recent versions. It is proposed that as of 2017 (see the change request # 8 in section 2.6 of this document), each scheme participant has to accept at least the version of ISO20022 XML pain format mentioned of the C2B IGs. The scheme participants are free to support more recent versions. Furthermore, there is indeed a gap with the latest ISO version but this does not impact the current EPC IGs as these are based on the 2009 version of ISO Rulebook impact If this change request is supported, this will impact both the Rulebook and the C2B Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 25

26 2.15. # 25: Clarification in business requirements for AT-22 for structured remittance info Description This change request was made by the European Association of Corporate Treasurers (EACT). The contributor demands for clarification in the business requirements for the Attribute AT-22 - The Remittance Information sent by the Creditor to the Debtor in the Collection when structured remittance information is used. The first change request is that structured remittance information should be redefined in the rulebook as Structured Machine to Machine Remittance Information. The rulebook business requirements and implementation guidelines should have a specific mention to the automatic treatment of this information. They should also indicate that such information should be mandatorily transferred to the debtor only when electronic means in the debtor bank-to- customer space are used, such as in electronic statements of account or other electronic formats using the data set DS-06 - Bank to customer Direct Debit Information (optional in other cases). The presence of the Structured Machine to Machine Remittance Information remittance information in paper statement of account should be then optional for the debtor bank. The second change request is to evaluate the possibility to have a specific new attribute code for the Structured Machine to Machine Remittance Information. Considering the opportunity to use the available ISO standard for end to end straight-through- processing reconciliation, the contributor accepts that the debtor bank may drop the received Structured Machine to Machine Remittance Information and not make it available to a debtor who is connected with an interface which does not comply with the ISO XML standard SEMWG analysis and recommendation The SEMWG does not propose a concrete recommendation for this change request for the public consultation. The SEMWG looks forward to the comments from the stakeholders taking part in the public consultation Rulebook impact If this change request is supported, this will impact the Rulebook, the C2B and interbank Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 26

27 2.16. # 26: Allow contemporaneous presence of Unstructured and Structured remittance info in payment messages Description This change request was made by the European Association of Corporate Treasurers (EACT). It proposes to allow contemporaneous presence of unstructured and structured remittance information in payment messages from the creditor to the debtor. Currently, the business requirements in the Rulebook for Attribute AT-22 - The Remittance Information sent by the Creditor to the Debtor in the Collection - and Implementation Guidelines indicate that either Structured or Unstructured remittance information may be present. Creditors should be able to insert and banks to transfer to debtors human readable information in the unstructured remittance information and, when required or useful, structured remittance information using the ISO standard for automatic straight through processing reconciliation SEMWG analysis and recommendation The SEMWG recommends not taking forward the change request (option e). The vast majority of SEMWG members representing national banking communities reported that currently there is no market demand for a combination for both structured and unstructured remittance information. The implementation of the combination of structured and unstructured remittance information in the applications of all payment service users and scheme participants is expected to be high Rulebook impact If this change request is supported, this will impact the Rulebook, the C2B and interbank Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 27

28 2.17. # 27: Additional clarification on the content (with examples) to be inserted in AT-27, AT-37 and AT Description This change request was made by the European Association of Corporate Treasurers (EACT). It is suggested to add further clarification to the content and to insert information examples in the description of the attributes AT-27, AT-37 and AT-39. They are used to identify counterparties involved in the payment: AT-27 Debtor Identification Code AT-37 The identification code of the Debtor Reference Party AT-39 The identification code of the Creditor Reference Party These attributes refer to elements of the ISO standard designed to transfer information (codes) for the automatic and straight-through-processing identification of the counterparties involved in the payment. In order to be effective, the codes inserted by the creditor in the attributes should allow an unique and unambiguous way of identifying an organisation or an individual person. The concrete change request is to add in the Rulebook the description of the above attributes, their purpose and examples of codes that could be inserted by the creditor in the payment initiation message. For attributes AT-27 and AT-37: The codes inserted in the attribute should allow a unique and unambiguous way of identifying an organisation or an individual person. Examples of codes that, among others, could be inserted are Fiscal Code, VAT Code, Enterprise Registration Number, Business Identity Code, Organization Code, Trade Register Number, Business Register Number, National Tax ID, Customer Code. For attribute AT-39: The codes inserted in the attribute should allow a unique and unambiguous way of identifying an organisation or an individual person. Examples of codes that, among others, could be inserted are Fiscal Code, VAT Code, Enterprise Registration Number, Business Identity Code, Organization Code, Trade Register Number, Business Register Number, National Tax ID, Supplier Code. EPC SDD Core Rulebook Change Request Consultation Document 28

29 SEMWG analysis and recommendation The SEMWG recommends not taking forward the change request (option e). It considers that the EPC SCT-SDD Clarification Paper (EPC348-12) is more appropriate to include such information. Together with the publication of the 2017 version of the Rulebook in the course of November 2016, the EPC will publish a new version of the document EPC including the clarifications and examples proposed by this change request Rulebook impact If this change request is supported, this will impact the Rulebook, the C2B and interbank Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 29

30 2.18. # 28: Amendment of attributes present in DS-06 "Bank to Customer Direct Debit Information" and business rules for debtor PSPs Description This change request was made by the European Association of Corporate Treasurers (EACT). The contributor suggests amendments to the attributes present in Data Set DS-06 - Bank to Customer Direct Debit Information and business rules for debtor PSPs. Currently it is not mandatory to transmit from the debtor bank to the debtor the attributes below (if present in Data Sets DS-03 and DS-04). AT-05 The address of the Creditor AT-15 The name of the Debtor Reference Party AT-18 The identifier of the original Creditor who issued the Mandate AT-37 The identification code of the Debtor Reference Party AT-38 The name of the Creditor Reference Party AT-39 The identification code of the Creditor Reference Party AT-58 The purpose of the Collection These attributes are designed to transfer useful information for the automatic and straight-through-processing identification of the counterparties involved in the payment. To facilitate the collection reconciliation by the debtor if any of such information is inserted by the creditor in the collection (therefore present in DS-03), it must be transferred to the debtor in the messages used to transmit the DS-06. The concrete change request is to amend the Rulebook so that where any of the above attributes is present in an interbank payment message (DS-04), the contents must be made available in full by the debtor bank to the debtor, subject to any prior agreement to the contrary. A debtor bank may drop the received extended reference party information (attributes 15, 18, 37, 38, 39 and 58) and not make it available to a debtor in case the debtor uses an interface which does not comply with the ISO XML standard SEMWG analysis and recommendation The SEMWG suggests incorporating the change request into the Scheme (option b) with these fields as optional attributes. The EPC document Recommendation on Customer Reporting SCT and SDD (EPC v2.0) already mentions these attributes Rulebook impact If this change request is supported, this will impact the Rulebook. EPC SDD Core Rulebook Change Request Consultation Document 30

31 2.19. # 30: Extension of the reversal period for the creditor from 5 days to 10 inter-bank business days Description This change request was made by the Spanish banking community. The SDD Core Rulebook states that reversals may only be processed from settlement date and within the five Inter-Bank Business Days following the Due Date requested in the original collection. Later presentations must not be processed by the Creditor Bank or CSMs mandated to act as such and the Debtor Bank must be so informed. The contributor proposes to extend the reversal period for the creditor from the current five days to ten inter-bank business days SEMWG analysis and recommendation The SEMWG recommends not taking forward the change request (option e). The need to do a reversal is due to an error by the Creditor. Extending the timespan to 10 days in which a reversal can be done will cause conflicts with other r-transaction types. It is expected that the Creditor rectifies its error as soon as possible. The Debtor can rely on the refund r-transaction to claim back the funds or the Creditor may agree with the Debtor to recover the funds outside of the scheme (e.g., by credit transfer) Rulebook impact If this change request is supported, this will impact only the Rulebook. EPC SDD Core Rulebook Change Request Consultation Document 31

32 2.20. # 32: Amendment to Chapter '1.4 Character Set' of the Customer-to- Bank and Inter-Bank IGs Description This change request was made by the German Banking Industry Committee (GBIC). The contributor proposes to amend the chapter 1.4 Character Set of the Customerto-Bank and Inter-Bank Implementation Guidelines of all three SEPA Scheme Rulebooks to reflect the recommended best practice as outlined in Section 5 of the document EPC SEPA Requirements for an Extended Character Set (UNICODE Subset) Best Practices in general and the 4 principles mentioned in this section in particular. This would increase the acceptance of SEPA payments by supporting the use of national characters similar to national practices. This will extend the current limited SEPA character set in the pacs messages to the UTF-8 character set in order that special national characters can be transported from the instruction ordering party up to the Debtor Bank. The Debtor Bank should then decide if it passes further the UTF-8 character to its customers or it converts the contents of the pacs message to the limited SEPA character set SEMWG analysis and recommendation The SEMWG recommends not taking forward the change request (option e). A major concern is raised about the unknown development costs that all scheme participants need to make in their internal systems and applications to handle the UTF- 8 characters. Furthermore, the impact of the UTF-8 character set with respect to transaction screening (e.g., anti-money laundering and counter-terrorist financing) is unknown Rulebook impact If this change request is supported, this will impact the Rulebook, the C2B and interbank Implementation Guidelines. EPC SDD Core Rulebook Change Request Consultation Document 32

33 2.21. # 34: Make AT-59 'category purpose of the collection' mandatory instead of optional Description This change request was made by the Portuguese banking community. The contributor suggests turning the optional attribute category purpose of the collection (AT-59) into a mandatory field. It will help all participants (creditor banks and debtor banks) of the scheme to identify correctly the purpose of the transaction to improve market practices SEMWG analysis and recommendation The SEMWG recommends not taking forward the change request (option e). Depending on the agreement between the Creditor and the Creditor Bank, the category purpose can be forwarded to the Debtor Bank and the Debtor subject to any overriding legal/ regulatory requirements. The SEMWG refers to the rules applied in datasets DS- 03 and DS-04 and recommends that this attribute remains optional Rulebook impact If this change request is supported, this will impact both the Rulebook and the Implementation Guidelines (IGs). EPC SDD Core Rulebook Change Request Consultation Document 33

34 2.22. # 36: Amendment to section 2.1 of the Scheme Management Internal Rules (SMIRs) Description This change request was made by Mrs Margarita Starkeviciute. The contributor suggests changes to section 2.1 Role of the Scheme Management Board in the Scheme Management Internal Rules. For efficient management of the evolution the EPC schemes, the Scheme Management Board should be supported by all relevant EPC bodies set up by the EPC Board SEMWG analysis and recommendation The SEMWG suggests incorporating the change request into the Scheme (option b) Rulebook impact If this change request is supported, this will impact only the Rulebook. EPC SDD Core Rulebook Change Request Consultation Document 34

35 2.23. # 37: Making storage location for additional customer-to-customer information available outside the payment transaction Description This suggestion was made by the SEMWG. The current SDD scheme permits the end-to-end carrying of remittance data on a structured or unstructured basis. The scheme rules allow for one repetition of the remittance information field of up to 140 characters to be included with the remittance information. Earlier change requests from different stakeholder groups and banking communities asked for a possibility to use significantly larger remittance information. The present 140 characters of remittance information appear to be not enough for some users or communities in the SEPA area. It is proposed to make additional customer-to-customer information available outside of the SDD payment message. The payment message would only carry the information of the location where the additional customer-to-customer information is stored. The additional data separated from the 140 characters of the remittance information can then be sent separately from the SDD collection message. Additional data elements/ attributes that already exist in ISO can be taken up in the SDD Rulebook (e.g., data element 2.94 RemittanceLocationElectronicAddress). These new attributes will store details of the location from where the additional customer-tocustomer information can be retrieved. It is emphasized that the current limited character set to be used in the SDD Scheme would remain unchanged. Furthermore, the additional attributes storing the location of the additional customer-to-customer information would be optional fields. This means that only when the Creditor provides information about the storage location of the additional customer-to-customer information in these optional fields, it is mandatory for the Creditor Bank to transport this storage location information in these fields to the Debtor Bank. In case of an arrangement between the Debtor Bank and the Debtor, the information about the storage location could be made available. These storage location details are sent together with the SDD message but are not part of the SDD collection. Upon review by the EPC s Legal Support Group in 2015 no legal or regulatory concerns were identified in the context of this proposed solution SEMWG analysis and recommendation The SEMWG suggests incorporating the suggestion into the scheme the change request into the Scheme (option b). With the provision of these additional fields, the market can further develop cloudbased solutions meeting the needs from Creditors and Debtors to make underlying business information available outside the payment transaction. Apart of this, the remittance information can be further used in the payment transaction Rulebook impact If this suggestion for change is supported, this will impact both the Rulebook and the Implementation Guidelines (IGs). EPC SDD Core Rulebook Change Request Consultation Document 35

36 2.24. # 38: Amendments to section of the Scheme Management Internal Rules (SMIRs) and Rulebook section Description This change request was made by the EPC secretariat. It proposes to amend the text of section of the Scheme Management Internal Rules (SMIRs) and the Rulebook section 5.6 to make the Scheme Participant s obligations in the context of changes to the Scheme Participant s operational, contacting or invoicing details more explicit. When the EPC Register of Scheme Participants database does not contain up-to-date information, this risks to negatively affect the Secretariat s ability to communicate with the relevant Scheme Participants, and would hamper the invoicing and collection of scheme participation fees. Having up-to-date contact information is a prerequisite to ensure that the EPC can effectively communicate with all Scheme Participants (for example when clarification letters are being sent to Scheme Participants). Furthermore, it is expected that the proposed change will be an important enabler for the EPC Secretariat to reach and bill Scheme Participants at all times in an effective manner. As such, the cost of invoicing the more than Scheme Participants can be kept under control, to the benefit of all Scheme Participants, as this cost will ultimately be borne by them SEMWG analysis and recommendation The SEMWG suggests incorporating the change request into the Scheme (option b) Rulebook impact If this suggestion for change is supported, this will impact only the Rulebook and the SMIRs. EPC SDD Core Rulebook Change Request Consultation Document 36

37 3. CHANGES PERTAINING TO THE IMPACT OF THE SEPA REGULATION OR OF ANY OTHER EU LEGISLATION As the EPC is under the legal obligation to ensure compliance of the rulebooks with the SEPA Regulation or of any other EU legislation, proposed changes to the rulebooks under this section are not subject to public consultation. They are included in this document for information but the contributors to this public consultation are welcome to comment on these changes. For this release management cycle, no changes have been deemed required at this point in time. EPC SDD Core Rulebook Change Request Consultation Document 37

38 4. DETAILED ANALYSIS OF MINOR CHANGES TO THE SDD CORE RULEBOOK The SEMWG recommends supporting the following suggested minor changes: 4.1. Proposed change Section Description Reason for change Type of Change 2.1 The Scheme is applicable within the countries listed in the EPC List of SEPA CountriesSEPA 3 as defined by the EPC 4 Removal of the second paragraph: It is recognised that actors will also be required to establish complementary operational rules and data requirements in relation to the roles they perform and these will be defined separately by those actors. The EPC does not define SEPA This paragraph does not provide any business rules relevant to the scheme CLAR CHAN AT-12 - BIC Code of the Creditor Bank A remark is added: for DS-03 (customer-to-bank collection), this attribute is only mandatory when the Creditor Bank is located in a non-eea SEPA country. This attribute remains mandatory in DS-04 (interbank collection). Provide more clarity about IBAN-Only CLAR AT-13 - BIC Code of the Debtor Bank A remark is added: for DS-03 (customer-to-bank collection), this attribute is only mandatory when the Debtor Bank is located in a non-eea SEPA country. This attribute remains mandatory in DS-04 (interbank collection). Provide more clarity about IBAN-Only CLAR 5.7 effect exceptional processing (including all Rejects, Returns and Refunds in relation to its Creditors' accounts) in accordance with the Rulebook Remain neutral about exception processing in chapter 5. A section in Chapter 4 is dedicated to such processing. CHAN 3 With a footnote referring to the document EPC EPC SDD Core Rulebook Change Request Consultation Document 38

39 5. PRINCIPLES GOVERNING THE CHANGE REQUEST PROCESS 5.1. Change Request This Change Request Public Consultation Document is submitted by the SEMWG in accordance with the procedures set out in the Internal Rules in respect of changes to the rulebook Structure of the Change Request Sections 2, 3 and 4 describe the changes to the rulebook which are proposed in this Change Request Public Consultation Document. These change requests fall into three categories: Section 2 covers innovative change requests to technical operations in sections 3 and 4 of the rulebook and other significant non-technical changes which fall within the definition of major changes Section 3 covers change requests to align the scheme rulebook with the SEPA Regulation and any other EU legislation Section 4 proposes changes to correct typing errors and provide additional clarification to the rulebook. These changes consist of minor changes to the rulebook which are uncontroversial in nature and do not affect technical operations. Annex 1 contains the original change requests. EPC SDD Core Rulebook Change Request Consultation Document 39

40 6. CHANGE MANAGEMENT PROCESS IN RESPECT OF MAJOR CHANGES 6.1. Consideration of Change requests In accordance with chapter of the Internal Rules, a number of change requests in respect of changes to the rulebooks have been submitted for consideration to the SEMWG. 24 of these are applicable to the SDD Core Scheme. Following consideration of these change requests as required under chapter of the Internal Rules, the SEMWG has determined: (a) that the changes set out in section 2 and 3 meet the criteria for acceptance into the change management process; and (b) that the changes set out in section 4 constitute minor changes invoking the procedures set out in Chapter 4.3 of the Internal Rules Change Request The SEMWG is responsible for preparation and development of a Change Request Public Consultation Document in respect of the major changes referred to in section 2 above, and guiding the changes through the change management process. The SEMWG has therefore formulated this Change Request Public Consultation Document under chapter 4.2 of the Internal Rules. This Change Request Public Consultation Document analyses the major changes which have been proposed, and attaches at Annex 1 the original change requests SEMWG recommendation The SEMWG is required under chapter of the Internal Rules to issue a recommendation on the way forward with regard to each change request; the reasons underlying each recommendation are detailed in section 2. The final decision whether a change request will be incorporated into the rulebook is however subject to the outcome of the public consultation. The contributors to this public consultation are requested to indicate whether they agree with the recommendation of the SEMWG on the way forward. In case the contributors do not agree with the SEMWG recommendation, they are requested to indicate their preferred way forward Consultation on the Change Request The EPC encourages all SEPA stakeholders to provide feedback during the public consultation. Banking communities are asked to consult all of their members who are involved in the SDD Core Scheme to ensure that the views of the payment services constituency are considered in the consultation process. The SEMWG encourages the banking communities to consult as wide a range of stakeholders as possible, including participants, end users and service suppliers. All stakeholders should provide feedback to the EPC on the Change Request Public Consultation Document by 4 July Next steps Taking into account comments received during the consultation, the SEMWG will produce a Change Proposal Submission Document to the EPC Scheme Management Board (SMB) for decision-making purposes in accordance with section of the Internal Rules, and to the EPC Stakeholder Forums (see section 4.4 of the Internal Rules), i.e. the Scheme End-User Forum (SEUF) and the EPC Scheme Technical Forum (ESTF), for their respective positions on the SEMWG Change Proposals. Approved changes will be incorporated into version 10.0 of the rulebook and published in November 2016 with the intention that they become effective in November EPC SDD Core Rulebook Change Request Consultation Document 40

41 6.6. Further information The above is a summary of the change management process. If you would like further information please refer to the Internal Rules or contact the EPC Secretariat. EPC SDD Core Rulebook Change Request Consultation Document 41

42 7. CHANGE MANAGEMENT PROCESS IN RESPECT OF MINOR CHANGES 7.1. Publication of list of minor changes The SEMWG has identified certain minor changes which they consider necessary for the Rulebook. The SEMWG is required under the Internal Rules to publish a list of minor changes on the EPC website and to ensure that the list may be viewed by all stakeholders. This obligation shall be met by the publication of this Change Request Public Consultation Document, and in particular the provisions of section 4 noting certain changes as 'minor' Comments on the minor changes All stakeholders may submit comments on the list of minor changes with feedback to this Change Request Public Consultation Document Submission of the list of minor changes to the SMB The list of minor changes shall be submitted to the SMB via the Change Proposal Submission Document in accordance with section of the Internal Rules. EPC SDD Core Rulebook Change Request Consultation Document 42

43 ANNEX 1 - ORIGINAL CHANGE REQUESTS EPC SDD Core Rulebook Change Request Consultation Document 43

44 Doc: EPC September 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Scheme Evolution and Maintenance Working Group (SEMWG) EPC Address: Contact details: Your reference: Scheme and document and version number: #2 Reference to separate EPC guide on SDD r-transaction reason codes Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Credit Transfer Rulebook Version 8.1 EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version 7.1 Request Date: 22 September 2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

45 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): Suggested Effective date: November Description of the suggestion: The EPC has published the document Guidance on Reason Codes for SDD R-transactions (EPC v2.1) on the EPC website. Various SDD Core and SDD B2B scheme participants highlight the usefulness of the document EPC v2.1 and it eases the correct use of the various SDD r-transaction reason codes. Therefore the EPC suggests that The SDD Core and the SDD B2B Rulebooks should formally refer to the document EPC and The SDD Core and SDD B2B scheme participants can better monitor the correct use of the various SDD r-transaction reason codes as described in the document EPC and adjust, where necessary, their internal processes. The correct application of these reason codes by a debtor bank, informing a creditor bank, about a failed SDD collection is crucial for the creditor bank and the creditor to understand the cause of an unsuccessful SDD Core or SDD B2B collection and to undertake actions on how to solve the reported issue. The EPC proposes the following SDD Core and SDD B2B Rulebook changes under sections A. to D. below in order that All SDD Core and the SDD B2B scheme participants are aware about the contents of the document EPC v2.1 All SDD Core and the SDD B2B scheme participants are able to understand and correctly use the reason codes as described in the document EPC v2.1 The objective is that scheme participants are enabled using without doubt the correct SDD Core and SDD B2B r-transaction codes to maximise the straight-through processing rate of these exceptional transactions and to provide meaningful information up to the creditor and the creditor bank. The EPC considers that keeping the contents of EPC v2.1 outside the SDD Core and the SDD B2B Rulebooks allows more flexibility for the EPC to provide updated instructions with respect to SDD Core and SDD B2B r-transaction reasons and reason codes on a short notice. A. Proposed changes to Section in SDD Core Rulebook v9.1: Value range: The reasons for a Reject by the Creditor Bank are left to a bilateral agreement between the Creditor Bank and the Creditor. The reasons for a Reject by the CSM or the Debtor Bank are as follows: Operation code/transaction code/sequence type incorrect, invalid File format Bank identifier incorrect (i.e. invalid BIC) Debtor deceased Account identifier incorrect (i.e. invalid IBAN) Account closed Direct debit forbidden on this account for regulatory reasons Account blocked Reason not specified Insufficient Funds Mandate data missing or incorrect #2 SDD Core & B2B-EPC SEMWG-Reference to separate EPC guide on SDD r-trx reason codes 2 of 6

46 E No Mandate Regulatory reason Account blocked for Direct Debit by the Debtor Specific service offered by the Debtor Bank Duplicate collection Refusal by the Debtor Identifier of the Creditor incorrect Creditor Bank not registered under this BIC in the CSM Debtor Bank not registered under this BIC in the CSM The reasons for a Return by the Debtor Bank are as follows: Account identifier incorrect (i.e. invalid IBAN or account number does not exist) Account closed Debtor deceased Direct debit forbidden on this account for regulatory reasons Duplicate collection Account blocked Reason not specified Insufficient Funds No Mandate Account blocked for Direct Debit by the Debtor Refusal by the Debtor Regulatory reason Specific service offered by the Debtor Bank Identifier of the Creditor incorrect The reasons for a Refund are as follows: Unauthorised Transaction Disputed authorised transaction (can only be used within the eight-week no-questions-asked Refund period) The document EPC Guidance on Reason Codes for SEPA Direct Debit R-transactions (document reference [22]) prescribes which ISO code should be used for each of the above-mentioned reasons under a Reject, a Return and a Refund. B. Proposed changes to section 0.1 References of SDD Core Rulebook v9.1: Document Number Title Issued by: [3] ISO Financial services - International bank account number (IBAN) -- Part 1: Structure of the IBAN HUISOUH ( ) ( ) ( ) [21] EPC Guidelines for the Appearance of Mandates (Core SEPA Direct Debit Scheme) [22] EPC EPC Guidance on Reason Codes for SEPA Direct Debit R-transactions EPEPC EPC C. Proposed changes to Section in SDD B2B Rulebook v7.1: Value range: The reasons for a Reject by the Creditor Bank are left to a bilateral agreement between the Creditor Bank and the Creditor being a Business Customer. The reasons for a Reject by the CSM or the Debtor s bank are as follows: #2 SDD Core & B2B-EPC SEMWG-Reference to separate EPC guide on SDD r-trx reason codes 3 of 6

47 Operation code /transaction code/sequence type incorrect, invalid File format Bank identifier incorrect (i.e. invalid BIC) Account identifier incorrect (i.e. invalid IBAN) Account closed Direct debit forbidden on this account for regulatory reasons Account blocked Reason not specified Insufficient Funds Mandate data missing or incorrect No Mandate or unable to obtain mandate confirmation from the Debtor Regulatory reason Specific service offered by the Debtor Bank Duplicate collection Refusal by the Debtor Identifier of the Creditor incorrect. (i.e. invalid Creditor Identifier). Debtor account is a consumer account Creditor Bank not registered under this BIC in the CSM Debtor Bank not registered under this BIC in the CSM The reasons for a Return by the Debtor Bank are as follows: Account identifier incorrect (i.e. invalid IBAN or account number does not exist) Account closed Direct debit forbidden on this account for regulatory reasons Duplicate collection Account blocked Reason not specified Insufficient Funds No Mandate or unable to obtain mandate confirmation from the Debtor Refusal by the Debtor Regulatory reason Specific service offered by the Debtor Bank Identifier of the Creditor incorrect (i.e. invalid Creditor Identifier). Debtor account is a consumer account The document EPC Guidance on Reason Codes for SEPA Direct Debit R-transactions (document reference [22]) prescribes which ISO code should be used for each of the above-mentioned reasons under a Reject and a Return. D. Proposed changes to section 0.1 References of SDD B2B Rulebook v7.1: Document Number Title Issued by: [3] ISO Financial services - International bank account number (IBAN) -- Part 1: Structure of the IBAN ISO [21] EPC Guidelines for the Appearance of Mandates EPCEPCUH [22] EPC EPC Guidance on Reason Codes for SEPA Direct Debit R- transactions EPC #2 SDD Core & B2B-EPC SEMWG-Reference to separate EPC guide on SDD r-trx reason codes 4 of 6

48 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: No change to the existing business rules for the 2017 version of the SDD Core and the SDD B2B rulebooks. There is no change in the range of r-transaction reasons described under section of the SDD Core rulebook or under section of the SDD B2B rulebook. 2. Impact on the interbank space: The change suggestion for the SDD Core and SDD B2B rulebooks makes an explicit reference to another EPC document explaining to scheme participants about the ISO reason code to be used for each r-transaction reason specified in the SDD Core and the SDD B2B rulebooks. 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): None. 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: None. 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) No b. A variant (adding an alternative optional rule alongside an existing Rulebook element) No #2 SDD Core & B2B-EPC SEMWG-Reference to separate EPC guide on SDD r-trx reason codes 5 of 6

49 2 Elements for evaluation The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? YES It provides clear information to the scheme participants about the ISO reason code to be used for each r-transaction reason under SDD Core and SDD B2B NO YES It will lead to the consistent use of the ISO codes among all scheme participants. It will provide accurate information to the creditor about the real reason of an unsuccessful SDD collection YES The SDD scheme participants have already implemented the concerned ISO codes in their systems. They have to assess whether the assignment of the r- transaction reasons is in line with the document EPC This change will contribute to the provision of accurate information to the creditor about unsuccessful SDD collections YES YES The SDD Core and B2B rulebooks already define r-transaction reasons. #2 SDD Core & B2B-EPC SEMWG-Reference to separate EPC guide on SDD r-trx reason codes 6 of 6

50 Doc: EPC September 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Scheme Evolution and Maintenance Working Group (SEMWG) EPC Address: Contact details: Your reference: Scheme and document and version number: #3 Additional r-transaction reason under 'Return' for AT-R3 Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Credit Transfer Rulebook Version 8.1 EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version 7.1 Request Date: 22 September 2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

51 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): Suggested Effective date: November Description of the suggestion: The SDD Core and the SDD B2B rulebooks list under attributes AT-R3 (refer to section in SDD Core Rulebook v9.1 and to section in SDD B2B Rulebook v7.1) a number of r- transaction reasons under the r-transactions types Rejects and Returns when a SDD Core or SDD B2B collection has not been successfully completed. First suggestion: Both SDD rulebooks specify that the r-transaction reason Bank identifier incorrect (i.e. invalid BIC) can only be used to reject a SDD collection (i.e. the collection diverted from normal execution, prior to interbank settlement) but not to return a SDD collection (i.e. after interbank settlement). However, it may occur that the final SDD settlement files contain valid IBANs but the BIC related to these IBANs do not belong to the debtor bank. The SCT rulebook already allows the use of the r-transaction reason Bank identifier incorrect (i.e. invalid BIC) for both rejecting and returning a SCT transaction (see AT-R3 in section 4.6 of the SCT Rulebook v8.1). In order to achieve consistency between the three EPC SEPA rulebooks in the handling of invalid BICs, the EPC proposes to foresee the use of the r-transaction reason Bank identifier incorrect (i.e. invalid BIC) also for returning a SDD collection. The ISO reason code RC01 can be used. Second suggestion: Both SDD rulebooks specify that the r-transaction reason Operation code/transaction code/sequence type incorrect, invalid File format can only be used to reject a SDD collection but not to return a SDD collection. However, it may occur that the final SDD settlement files contain e.g., a collection indicating Recurrent even though the mandate indicated a One-off SDD collection or the identification code of the scheme specified in the message is incorrect. The EPC proposes to foresee the use of the r-transaction reason Operation code/transaction code/sequence type incorrect, invalid File format also for returning a SDD collection. The ISO reason code AG02 can be used. A. Proposed changes to Section in SDD Core Rulebook v9.1 : Value range: The reasons for a Reject by the Creditor Bank are left to a bilateral agreement between the Creditor Bank and the Creditor. The reasons for a Reject by the CSM or the Debtor Bank are as follows: (.) The reasons for a Return by the Debtor Bank are as follows: Operation code/transaction code/sequence type incorrect, invalid File format Account identifier incorrect (i.e. invalid IBAN or account number does not exist) Account closed Bank identifier incorrect (i.e. invalid BIC) Debtor deceased Direct debit forbidden on this account for regulatory reasons Duplicate collection Account blocked #3 SDD Core & B2B-EPC SEMWG-Additional r-transaction reason under 'Return' for AT-R3 2 of 5

52 Reason not specified Insufficient Funds No Mandate Account blocked for Direct Debit by the Debtor Refusal by the Debtor Regulatory reason Specific service offered by the Debtor Bank Identifier of the Creditor incorrect ( ) B. Proposed changes to Section in SDD B2B Rulebook v7.1: Value range: The reasons for a Reject by the Creditor Bank are left to a bilateral agreement between the Creditor Bank and the Creditor being a Business Customer. The reasons for a Reject by the CSM or the Debtor s bank are as follows: (...) The reasons for a Return by the Debtor Bank are as follows: Operation code/transaction code/sequence type incorrect, invalid File format Account identifier incorrect (i.e. invalid IBAN or account number does not exist) Account closed Bank identifier incorrect (i.e. invalid BIC) Direct debit forbidden on this account for regulatory reasons Duplicate collection Account blocked Reason not specified Insufficient Funds No Mandate or unable to obtain mandate confirmation from the Debtor Refusal by the Debtor Regulatory reason Specific service offered by the Debtor Bank Identifier of the Creditor incorrect (i.e. invalid Creditor Identifier). Debtor account is a consumer account ( ) 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: YES. The use of r-transaction reasons under Reject can also be used for a Return of a SDD collection. 2. Impact on the interbank space: YES. Scheme participants will have to take up additional r-transaction reasons and the related ISO reason code in the list of foreseen SDD Return reasons and related ISO reason codes. An existing ISO reason code used for SDD Rejects can be re-used. 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): YES. The list of possible Return ISO reason codes will be extended with the ISO code RC01 and AG Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: #3 SDD Core & B2B-EPC SEMWG-Additional r-transaction reason under 'Return' for AT-R3 3 of 5

53 None. 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) YES b. A variant (adding an alternative optional rule alongside an existing Rulebook element) No #3 SDD Core & B2B-EPC SEMWG-Additional r-transaction reason under 'Return' for AT-R3 4 of 5

54 2 Elements for evaluation The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? YES, the r-transaction reasons Bank identifier incorrect (i.e. invalid BIC) and Operation code/transaction code/sequence type incorrect, invalid File format are already made available for rejecting a SDD collection. NO YES. The r-transaction reasons Bank identifier incorrect (i.e. invalid BIC) and Operation code/transaction code/sequence type incorrect, invalid File format will be a possibility for the SDD rulebooks YES. The SDD Rulebooks already allow the r- transaction type Return. Additional ISO reason codes just have to be added to the current range of ISO reason codes for SDD return messages YES YES. It extends the use of the SDD Return message for additional r-transaction reasons #3 SDD Core & B2B-EPC SEMWG-Additional r-transaction reason under 'Return' for AT-R3 5 of 5

55 Doc: EPC September 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Scheme Evolution and Maintenance Working Group (SEMWG) EPC Address: Contact details: Your reference: Scheme and document and version number: #6 Removal of Annex IX Advance Mandate Information (AMI) Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Credit Transfer Rulebook Version 8.1 EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version 7.1 Request Date: 22 October 2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

56 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): Suggested Effective date: November Description of the suggestion: The annex IX Advance Mandate Information (AMI) had been added as an option in the SDD Core rulebook version 5.0 and in the SDD B2B rulebook version 3.0. Both rulebook versions were published in November 2010 with an effectiveness date of 19 November More than five years after the publication of Annex IX as an option to the two SDD rulebooks, none of the SDD scheme participants have informed the EPC directly that they used this option at a given moment in the past years, or that they currently use it or that they intend to use it in the future. Feedback received from the members of the Scheme Evolution and Maintenance Working Group (SEMWG) of the EPC in October 2015 highlighted that no SDD scheme participant currently uses this option. There is no market demand for this option. Based on this input, the EPC proposes to remove Annex IX completely from the two SDD rulebooks. 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: YES. Complete removal of an optional SDD feature from both SDD rulebooks. 2. Impact on the interbank space: YES. The Advance Mandate Information feature will no longer be available in the SDD schemes. 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): YES. Complete removal of the implementation guidelines related to the AMI option. 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: None. 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) YES b. A variant (adding an alternative optional rule alongside an existing Rulebook element) No #6 SDD Core & B2B-EPC SEMWG-Removal of Annex IX Advance Mandate Information (AMI) 2 of 3

57 2 Elements for evaluation The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? YES, the scheme participants have not used or have not shown interest in the AMI option. NO YES. YES. YES YES. #6 SDD Core & B2B-EPC SEMWG-Removal of Annex IX Advance Mandate Information (AMI) 3 of 3

58 Doc: EPC September 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Scheme Evolution and Maintenance Working Group (SEMWG) EPC Address: Contact details: Your reference: Scheme and document and version number: #7 Review of SDD Annex VII 'e-mandates' on stipulations with respect to BIC debtor bank Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Credit Transfer Rulebook Version 8.1 EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version 7.1 Request Date: 29 October 2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

59 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): Suggested Effective date: November Description of the suggestion: The delivery of the BIC of the Debtor Bank in SDD transactions is optional as of 1 February 2016 when the Creditor Bank and the Debtor Bank are based in different countries of the EEA. This means that as of the above-mentioned respective dates and cases, the debtor does not need to mention the BIC of the payment service provider (PSP) holding his/her payment account on a SDD Core or SDD B2B mandate. The provision of the BIC of the Debtor Bank in SDD transactions remains mandatory when the Creditor Bank or the Debtor Bank is located in a non-eea SEPA country. In this case, the debtor will still have to provide the BIC of the PSP holding his/her payment account on the SDD Core or SDD B2B mandate. With respect above-mentioned changes in the provision of the BIC of the debtor bank, the EPC has done a review of Annex VII describing the e-mandate option for the two SDD rulebooks. The following changes to the Annex VII are proposed: SDD Core and SDD B2B: PT The Debtor uses an electronic channel made available by of the Creditor for the completion of an e-mandate proposal. ( ) b. By the Debtor: 14 The name of the Debtor 09 The address of the Debtor 27 Debtor identification code (optional) 15 The name of the Debtor Reference party (optional) 37 The identification code of the Debtor Reference Party (optional) 13 The BIC code of the Debtor Bank (only mandatory when the Debtor Bank is located in a non-eea SEPA country) (see remark underneath) 24 The reason for Amendment/Replacement of the account in another Bank of the Mandate (in the case that the issuing of the e-mandate results from a Debtor moving the account to be debited for an existing Mandate to another Debtor Bank) ( ) PT The Debtor must identify and authenticate himself according to the instructions received from the Debtor Bank and agree on the e-mandate proposal. ( ) The Debtor Bank must check that the mandatory attributes are present in the e-mandate received and in line with the requirements of the attributes specific to the Debtor Bank and known by the Debtor Bank, such as the existence of the BIC code of the Debtor Bank when the Debtor Bank is located in a non-eea SEPA country. #7 SDD Core & B2B-EPC SEMWG-Review of SDD Annex VII 'e-mandates' linked to BIC debtor bank 2 of 6

60 PT The Debtor Bank executes the validation service, confirms the result of the validation service to the Debtor and to the Creditor and routes the Debtor back to the electronic channel of the Creditor. ( ) Description The Debtor Bank must execute the validation service as follows: decide on whether the authentication means have been correctly used conclude that the circumstances of the use of the authentication means appear to be correct on the basis of the information available to the Debtor Bank, i.e. they are not stolen, lost or subject to counterfeit risks When the Debtor Bank is located in a non-eea SEPA country, check the BIC code present in the e-mandate proposal message received is a valid BIC code applicable to the Debtor Bank PT The Debtor uses an electronic channel made available by of the Creditor for the completion of an e-mandate amendment request. ( ) b. By the Debtor: (the attributes subject of the amendment need to be introduced) 14 The name of the Debtor (optional) 09 The address of the Debtor (optional) 27 Debtor identification code (optional) 15 The name of the Debtor Reference party (optional) 37 The identification code of the Debtor Reference Party (optional) 13 The BIC code of the Debtor Bank (only mandatory when the Debtor Bank is located in a non-eea SEPA country) (see remark underneath l) PT The Debtor must identify and authenticate himself according to the instructions received from the Debtor Bank and agree on the e-mandate amendment request. ( ) The Debtor Bank must check that the mandatory attributes are present in the Mandate amendment received and in line with the requirements of the attributes specific to the Debtor Bank and known by the Debtor Bank, such as the existence of the BIC code of the Debtor Bank when the Debtor Bank is located in a non-eea SEPA country. PT The Debtor Bank executes the validation service, confirms the result of the validation service to the Debtor and to the Creditor and routes the mandate proposal of the Debtor back to the electronic channel of the Creditor. Description The Debtor Bank must execute the validation service as follows: decide on whether the authentication means have been correctly used conclude that the circumstances of the use of the authentication means appear to be correct on the basis of the information available to the Debtor Bank, i.e. they are not stolen, lost or subject to counterfeit risks When the Debtor Bank is located in a non-eea SEPA country, check the BIC code present in the e-mandate request message received is a valid BIC code applicable to the Debtor Bank #7 SDD Core & B2B-EPC SEMWG-Review of SDD Annex VII 'e-mandates' linked to BIC debtor bank 3 of 6

61 PT The Debtor uses an electronic channel made available by of the Creditor for the completion of an e-mandate cancellation request. ( ) b. By the Debtor: only the decision on the cancellation must be introduced 13 The BIC code of the Debtor Bank (only mandatory when the Debtor Bank is located in a non-eea SEPA country) (see remark underneath) The box at the bottom of the illustration in figure 12 in the same section for placing the signature(s), must be replaced by a box where the Debtor is invited to confirm that he agrees with the cancellation (in PT-09.03) PT The Debtor must identify and authenticate himself according to the instructions received from the Debtor Bank and agree on the e-mandate cancellation request. ( ) The Debtor Bank must check that the mandatory attributes are present in the e-mandate cancellation received and in line with the requirements of the attributes specific to the Debtor Bank and known by the Debtor Bank, such as the existence of the BIC code of the Debtor Bank when the Debtor Bank is located in a non-eea SEPA country. PT The Debtor Bank executes the validation service, confirms the result of the validation service to the Debtor and to the Creditor and routes the mandate proposal of the Debtor back to the electronic channel of the Creditor. ( ) Description The Debtor Bank must execute the validation service as follows: decide on whether the authentication means have been correctly used conclude that the circumstances of the use of the authentication means appear to be correct on the basis of the information available to the Debtor Bank, i.e. they are not stolen, lost or subject to counterfeit risks when the Debtor Bank is located in a non-eea SEPA country, check the BIC code present in the e-mandate request message received is a valid BIC code applicable to the Debtor Bank Dataset specific for use with e-mandates: DS-12 The e-mandate proposal /request message Attributes contained ( ) 39The identification code of the Creditor Reference party (optional) 13 The BIC code of the Debtor Bank (only mandatory when the Debtor Bank is located in a non-eea SEPA country) 08 The identifier of the underlying contract (optional) 21 The transaction type (recurrent, one-off) 17 The type of Mandate 24 The reason for amendment/replacement of the account in another Bank of the Mandate (only for amendments and for issuing moving the account to be debited to another Debtor Bank) Dataset specific for use with e-mandates: DS-13 The validation message ( ) #7 SDD Core & B2B-EPC SEMWG-Review of SDD Annex VII 'e-mandates' linked to BIC debtor bank 4 of 6

62 Attributes contained Data from the request step: ( ) 39The identification code of the Creditor Reference party (optional) 13 The BIC code of the Debtor Bank (only mandatory when the Debtor Bank is located in a non-eea SEPA country) 07 The account number (IBAN) of the account of the Debtor to be debited SDD Core specific: PT The Debtor Bank accepts or rejects the Request for Refund - requests e-mandate Copy from Creditor Bank. (.) Attribute of the Mandate The Identification Code of the Scheme The Unique Mandate Reference The Identifier of the Creditor The Name of the Creditor The Account Number of the Debtor (IBAN) The Name of the Debtor BIC Code of the Debtor Bank (only mandatory when the Debtor Bank is located in a non-eea SEPA country) The Transaction Type The Date of Signing of the Mandate 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: NO. The SDD scheme rulebooks themselves are in line with the SEPA Regulation. 2. Impact on the interbank space: No. The SEPA Regulation already set the end-date for IBAN+BIC in Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): YES. The phrase (only mandatory) when the Debtor Bank is located in a non-eea SEPA country may have to be included in certain fields or data elements in the e- Mandate Implementation Guidelines. 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: None. 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) No b. A variant (adding an alternative optional rule alongside an existing Rulebook element) No #7 SDD Core & B2B-EPC SEMWG-Review of SDD Annex VII 'e-mandates' linked to BIC debtor bank 5 of 6

63 2 Elements for evaluation The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? YES, in order to be full in line with in line with the SEPA Regulation NO. YES. YES. YES. YES. #7 SDD Core & B2B-EPC SEMWG-Review of SDD Annex VII 'e-mandates' linked to BIC debtor bank 6 of 6

64 Doc: EPC September 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Scheme Evolution and Maintenance Working Group (SEMWG) EPC Address: Contact details: Your reference: Scheme and document and version number: #8 Mandatory Customer-to-Bank (C2B) Implementation Guidelines (IGs) Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Credit Transfer Rulebook Version 8.1 EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version 7.1 Request Date: 29 October 2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

65 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): Suggested Effective date: November Description of the suggestion: In 2014, the Euro Retail Payments Board (ERPB 1 ) noted that various SEPA countries and EPC scheme participants have created their own configurations ( subsets ) of the XML-based SEPA payment messages in the Customer-to-Bank (C2B) space. Corporate customers which transact in various countries and/or with different Payment Service Provider (PSP) partners need to implement these customer-to-bank (C2B) interface subsets. The ERPB meeting on 1 December agreed to support the publication and the use of the EPC s current C2B Implementation Guidelines (IGs) by all market participants. The ERPB recommends making the EPC s C2B IGs mandatory in the next EPC SEPA rulebook change management cycle (reference is made to the recommendation ERPB/2014/rec1). The EPC interprets this ERPB recommendation as making the EPC s C2B SEPA scheme IGs for SCT, SDD Core and SDD B2B mandatory for the concerned scheme participants. The EPC proposes that a scheme participant is obliged to accept at least but not exclusively C2B SEPA payment message files based on the EPC s C2B SEPA scheme IGs defined for SCT, SDD Core and SDD B2B. SCT originators and SDD Core/ B2B creditors would still be free to agree with their originator banks/ creditor banks to use any other ISO XML payment message standard format to submit their C2B SEPA payment message files to their PSPs. This means that customers will still have the choice either to continue using their current C2B file set-up or to opt for the C2B file based on EPC specifications. On the other hand, the scheme participants will have to be technically capable of supporting the EPC C2B file specifications. At their first meetings in the 3rd quarter of 2015, the Scheme End-User Forum (SEUF) and the EPC Scheme Technical Forum (ESTF) supported the idea of having mandatory C2B IGs. (Minutes of these SEUF and ESTF meetings are available on the SEUF and ESTF webpages) The following concrete changes are proposed in the SCT, SDD Core and SDD B2B rulebooks: A. SCT Rulebook Version 8.1 Section SEPA Credit Transfer Scheme Implementation Guidelines (...) The SEPA Credit Transfer Scheme Implementation Guidelines are available as two complementary documents: the mandatory guidelines regarding the inter-bank messages (SEPA Credit Transfer Scheme Inter-bank Implementation Guidelines) and the recommended 1 On 19 December 2013 the ECB announced the launch of the Euro Retail Payments Board (ERPB). This new entity, which replaces the SEPA Council, will help foster the development of an integrated, innovative and competitive market for retail payments in euro in the European Union. More information is available on the ERPB webpage 2 Reference is made to the ERPB Statement #8 All Schemes-EPC SEMWG-Mandatory Customer-to-Bank (C2B) Implementation Guidelines (IGs) 2 of 7

66 the guidelines regarding the customer-to-bank messages (SEPA Credit Transfer Scheme Customer-to-Bank Implementation Guidelines) which each participant is obliged to support at the request of the Originator. The SEPA Credit Transfer Scheme Inter-Bank Implementation Guidelines (reference [1]) and the SEPA Credit Transfer Scheme Customer-to-Bank Implementation Guidelines (reference [12]) which set out the rules for implementing the credit transfer ISO XML standards, constitute a binding supplements to the Rulebook. Section DS-01 Customer to bank Credit Transfer Information ( ) Rules applied: Remarks The Originator Bank is obliged to accept customer-to-bank Credit Transfer Instructions which are based on the credit transfer ISO XML initiation message standards in the SEPA Credit Transfer Scheme Customer-to-Bank Implementation Guidelines as defined in Chapter 0.5. Where any of the above attributes (except for AT-45, see rules applied in DS-02) are provided by the Originator within a payment instruction, they must be transported by the Originator Bank to the Beneficiary Bank in accordance with DS-02 subject to any overriding legal/regulatory requirements Information relating to an Originator Reference Party and/or Beneficiary Reference Party is included only for the purpose of assisting the Originator and/or Beneficiary in managing their payments and is not required by the Originator Bank and/or Beneficiary Bank for the purpose of the execution of the payment to which the information relates These attributes reflect business requirements and do not prescribe fields in the SEPA Credit Transfer Scheme C2B Implementation Guidelines as defined in Chapter 0.5 Section 5.2 Compliance with the Rulebook A Participant shall comply with: the Rulebook, including amendments as and when they are made and properly communicated to Participants the SEPA Credit Transfer Scheme Inter-Bank Implementation Guidelines the SEPA Credit Transfer Scheme Customer-to-Bank Implementation Guidelines the Internal Rules, as set out in Annex II to this Rulebook Section 5.7 Obligations of an Originator Bank ( ) ensure the authenticity and validity of the Originator s instructions validate each Credit Transfer Instruction, accept (subject to account status and the terms of its agreement with the Originator) each valid Credit Transfer Instruction, and reject each invalid Credit Transfer Instruction. For these purposes, validation includes checking the plausibility of the IBAN of the Beneficiary and the validity of the Beneficiary Bank s BIC; accept Credit Transfer Instructions that comply with the standards set out in the SEPA Credit Transfer Scheme Customer-to-Bank Implementation Guidelines; provide an explanation to the Originator of the reason for rejecting any payment instruction in a manner and within a timeframe as may be agreed with the Originator; Chapter 7 DEFINED TERMS IN THE RULEBOOK ( ) #8 All Schemes-EPC SEMWG-Mandatory Customer-to-Bank (C2B) Implementation Guidelines (IGs) 3 of 7

67 SEPA Credit Transfer Scheme C2B Implementation Guidelines The SEPA Credit Transfer Scheme C2B Implementation Guidelines set out the rules for implementing the credit transfer ISO XML standards in the Customer to Bank space, constitute a binding n optional supplement to the Rulebook, described with reference [124] in the Rulebook. B. SDD Core Rulebook Version 9.1 Section SEPA Direct Debit Scheme Implementation Guidelines ( ) The SEPA Core Direct Debit Scheme Implementation Guidelines are available as two complementary documents: the mandatory guidelines regarding the inter-bank messages (SEPA Core Direct Debit Scheme inter-bank Implementation Guidelines) and the recommended guidelines regarding the Customer-to-bank messages (SEPA Core Direct Debit Scheme Customer-to-Bank Implementation Guidelines) which each participant is obliged to support at the request of the Creditor. The SEPA Core Direct Debit Scheme Inter-bank Implementation Guidelines (reference [9]) and the SEPA Core Direct Debit Scheme Customer-to-Bank Implementation Guidelines (reference [12]) which set out the rules for implementing the direct debit ISO XML Standards; constitute a binding supplements to the Rulebook. Section DS-03 Customer to Bank Collection Description: The Creditor must supply the following attributes. Attributes known by the Creditor Bank may be filled in by the Creditor Bank. This is a matter between the Creditor and the Creditor Bank. Attributes are mandatory unless otherwise indicated. The Creditor Bank is obliged to accept Customer-to-Bank Collection Instructions which are based on the direct debit ISO XML initiation message standards in the SEPA Core Direct Debit Scheme Customer-to-Bank Implementation Guidelines as defined in Chapter 0.5. Section 5.2 Compliance with the Rulebook A Participant shall comply with: the Rulebook, including amendments as and when they are made and properly communicated to Participants the SEPA Core Direct Debit Scheme Inter-bank Implementation Guidelines for standards the SEPA Core Direct Debit Scheme Customer-to-Bank Implementation Guidelines the SEPA Scheme Management Internal Rules (the Internal Rules ), as set out in Annex IV to this Rulebook Section 5.7 Obligations of a Creditor Bank ( ) in the event that a prospective Creditor does not have a Creditor Identifier, provide or procure the provision of such a number perform all operational tasks allocated to Creditor Banks under the Rulebook and comply with the standards set out in the SEPA Core Direct Debit Scheme Inter-Bank Implementation Guidelines and in the SEPA Core Direct Debit Scheme Customer-to-Bank Implementation Guidelines effect exceptional processing (including all Rejects, Returns and Refunds in relation to its Creditors' accounts) in accordance with the Rulebook #8 All Schemes-EPC SEMWG-Mandatory Customer-to-Bank (C2B) Implementation Guidelines (IGs) 4 of 7

68 C. SDD B2B Rulebook Version 7.1 Section SEPA Business-to-Business Direct Debit Implementation Guidelines ( ) The SEPA Business-to-Business Direct Debit Scheme Implementation Guidelines are now available as two complementary documents: the mandatory guidelines regarding the inter-bank messages (SEPA Business-to-Business Direct Debit Scheme Inter-bank Implementation Guidelines) and the recommended guidelines regarding the customer-to-bank messages (SEPA Business-to- Business Direct Debit Scheme Customer-to-Bank Implementation Guidelines) which each participant is obliged to support at the request of the Creditor. The SEPA Business-to-Business Direct Debit Inter-bank Implementation Guidelines (reference [9]) and the SEPA Business-to-Business Direct Debit Scheme Customer-to-Bank Implementation Guidelines (reference [12]) which set out the rules for implementing the direct debit ISO XML standards, constitute a binding supplements to the Rulebook. Section DS-03 The Business Customer to Bank Collection ( -Mandates) e Description: The Creditor must supply the following attributes. Attributes known by the Creditor Bank may be filled in by the Creditor Bank. This is a matter between the Creditor and the Creditor Bank. Attributes are mandatory unless otherwise indicated. The Creditor Bank is obliged to accept Customer-to-Bank Collection Instructions which are based on the direct debit ISO XML initiation message standards in the SEPA Business-to-Business Direct Debit Scheme Customer-to-Bank Implementation Guidelines as defined in Chapter 0.5. Section 5.2 Compliance with the Rulebook A Participant shall comply with: the Rulebook, including amendments as and when they are made and properly communicated to Participants the SEPA Business-to-Business Direct Debit Inter-bank Implementation Guidelines for standards the SEPA Business-to-Business Direct Debit Scheme Customer-to-Bank Implementation Guidelines the SEPA Scheme Management Internal Rules (the Internal Rules ), as set out in Annex IV to this Rulebook Section 5.7 Obligations of a Creditor Bank ( ) in the event that a prospective Creditor does not have a Creditor Identifier, provide or procure the provision of such a number perform all operational tasks allocated to Creditor Banks under the Rulebook and comply with the standards set out in the SEPA Business-to-Business 2B Direct Debit Scheme Interbank Implementation Guidelines and in the SEPA Business-to-Business Direct Debit Scheme Customer-to-Bank Implementation Guidelines effect exceptional processing (including all Rejects and Returns in relation to its Creditors' accounts) in accordance with the Rulebook, and take care to avoid an excessive proportion of Rejects and Returns in respect of Collections in relation to any particular Creditor. #8 All Schemes-EPC SEMWG-Mandatory Customer-to-Bank (C2B) Implementation Guidelines (IGs) 5 of 7

69 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: Yes. The next version of the C2B IGs for each EPC SEPA scheme rulebook will become a binding supplement to the concerned rulebook and as a result each scheme participant will have to comply with the C2B IGs. 2. Impact on the interbank space: No. The only impact will be for SCT originator banks and SDD creditor banks which have to be technically able to accept and to process valid and complete SCT and SDD instructions based on the next version of the C2B IGs for each EPC SEPA scheme rulebook. 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): YES. Certain data elements in the C2B IGs will become mandatory and certain SEPA usage rules will be updated. 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: Yes. Extra obligations will be assigned to the SCT originator banks and SDD creditor banks. 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) Yes b. A variant (adding an alternative optional rule alongside an existing Rulebook element) No #8 All Schemes-EPC SEMWG-Mandatory Customer-to-Bank (C2B) Implementation Guidelines (IGs) 6 of 7

70 2 Elements for evaluation The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? YES, this suggestion responds to a request from the ERPB which is composed of representatives from the demand and the supply side in the European payments market. NO. YES. It is a further harmonization step whereby SDD creditors and SCT originators could submit their payment initiation files based on one set of specifications to all creditor banks and originator banks in SEPA YES. YES. YES. #8 All Schemes-EPC SEMWG-Mandatory Customer-to-Bank (C2B) Implementation Guidelines (IGs) 7 of 7

71 Doc: EPC September 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Scheme Evolution and Maintenance Working Group (SEMWG) EPC Address: Contact details: Your reference: Scheme and document and version number: #9 Mandate amendment for change of creditor identifier Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Credit Transfer Rulebook Version 8.1 EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version 7.1 Request Date: 21 December 2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

72 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): Suggested Effective date: November Description of the suggestion: Section of both SDD rulebooks describes the mandate amendment process (PR-02). The attribute AT-24 in section 4.8 lists the reasons for such a mandate amendment. Comparing the process step PT under section with AT-24, the following inconsistency is noted: PT-02.02: ( ) The amendments of the Mandate that are of concern for the Creditor Bank or for the Debtor Bank, are the following: The Creditor needs to change the unique Mandate reference of an existing Mandate because of internal organisational changes ( restructuring) The Creditor identity (italic underscore added) has changed due to the merger, acquisition, spinoff or organisational changes ( ) AT-24: Value range: Change of AT-01 (the Creditor defining a new unique Mandate reference) Change of AT-02 (new Creditor Identifier Information) (italic underscore added) Change of AT-03 (The Name of the Creditor) Change of AT-07 (the Debtor specifying another account to be debited in the same bank or in another bank) A combination of changes in the attributes AT-01, AT-02 and/or AT-03 The use of the different terms identity and identifier in the mandate amendment process may cause confusion. The suggestion is to change the wording in the process step PT under section as follows: ( ) The amendments of the Mandate that are of concern for the Creditor Bank or for the Debtor Bank, are the following: The Creditor needs to change the unique Mandate reference of an existing Mandate because of internal organisational changes ( restructuring) The Creditor identity Identifier has changed due to the merger, acquisition, spin-off or organisational changes ( ) #9 SDD Core & B2B-EPC SEMWG-Mandate amendment for change of creditor identifier 2 of 4

73 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: NO. The purpose of this suggestion is to have an unambiguous terminology in the mandate amendment process described in the SDD rulebooks. 2. Impact on the interbank space: No. It concerns only a terminology correction. 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): No. Attribute AT-24 remains unchanged. 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: None. 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) Yes. A terminology correction. b. A variant (adding an alternative optional rule alongside an existing Rulebook element) No #9 SDD Core & B2B-EPC SEMWG-Mandate amendment for change of creditor identifier 3 of 4

74 2 Elements for evaluation The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? YES, to further improve the clarity of the mandate amendment process description in the SDD rulebooks NO. YES. YES. YES. YES. #9 SDD Core & B2B-EPC SEMWG-Mandate amendment for change of creditor identifier 4 of 4

75 Doc:EPC August 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Contact details: Your reference: Scheme and document and version number: Request Date: For information: Shahid Ali Individual Bern 3013, Switzerland Delhi , India Business Analyst - Payments Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Direct Debit Core Rulebook Version Nov.2015 This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

76 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): Nov Description of the suggestion: Problem Statement Rule for usage of exchange rate for Refund of SEPA Direct Debit. For a non-euro account, currency exchange is applied when a debit happens for debtor. When debtor claims Refund due to dispute or wrong collection, Refund again use the exchange rate. Due to fluctuation of exchange rate between collection and refund, it ends up a new dispute between debtor and debtor bank for wrong usage of exchange. Solution Proposal Bank may opt either of below, to handle SDD refund on non-euro account - Refund using same exchange rate as used when collection done. - Take the on-going market rate at both collection and refund. For first option, debtor bank may suffer as it has taken risk and given same rate to debtor. While second has no risk for bank as it uses market rate, but debtor may suffer. As a customer(debtor) oriented solution, it demands rule/suggestion from EPC to avoid such bank specific opted solution. This problem demands attention as the Go Live End date for SEPA in non- Euro country is near (2016) and they are opting SEPA in full pace. As these country have account holder in non-euro currency such scenario arise. Suggestion is to use same exchange rate at both collection and refund stage. For the loss bank suffer due to exchange fluctuation, Bank should be given option to take more return amount by either using interchange fees or new exchange margin attribute to be introduced. Proper indicator must exist in inter-bank refund message to give exchange fluctuation deduction information to make solution transparent. Best approach will be to introduce a dedicated attribute to mention exchange rate and minimum is to add information in Rule book for usage of interchange fees as to manage exchange fluctuation for refund. 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: Yes 2. Impact on the interbank space: Yes 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): No 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: #10 SDD Core-Shahid Ali- Usage rules for the exchange rate for SDD Core Refunds 2 of 4

77 No 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) Yes b. A variant (adding an alternative optional rule alongside an existing Rulebook element) No #10 SDD Core-Shahid Ali- Usage rules for the exchange rate for SDD Core Refunds 3 of 4

78 2 ELEMENTS FOR EVALUATION The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? Yes Usage of exchage rate standard for non-euro counntry is obstacle to overcome complete acceptance of SEPA in such country. Not really, but the loss or profit due to exchange rate fluctuation can be explained. Yes, as one of the main objective of SEPA is transperancy. The suggested topic will give transperancy to parties for Exchange Rate oriented deduction. Yes Yes Yes #10 SDD Core-Shahid Ali- Usage rules for the exchange rate for SDD Core Refunds 4 of 4

79 Doc: EPC November 2014 (Version 1.0) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Beatrice Alberti Equens SE clm@equens.com Contact details: Your reference: Scheme and document and version number: IBAN check failed Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Credit Transfer Rulebook Version 8.0 EPC SEPA Direct Debit Core Rulebook Version 9.0 EPC SEPA Direct Debit Business to Business Rulebook Version 7.0 Request Date: For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

80 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): November Description of the suggestion: Background: German domestic payments could be designated by Textschlüsselergänzung 444 to show that the check digits of the account number were wrong but the initiating bank decided that the payment should be forwarded anyway. This option made it possible to forward payments e.g. in case of special account numbers (charity accounts are only one example) that don t fit to the normal check digits of the bank. Sometimes also for SEPA payments the calculation of the check digits is carried out wrong or the algorithm declared by the receivers bank is erroneous. In that case payments are rejected although they could be processed. Suggestion: Equens suggests to implement a purpose code for SEPA payments with similar meaning to 444 in German Domestic payments. This should be the code IBCF IBAN-check failed for all formats and can be filled by initiating bank. This may be defined to be a regional or national AOS. 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: Improvement of the scheme 2. Impact on the interbank space: New information has to be transferred. Validation checks have to be adjusted. 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): New Code has to be added to the Implementation Guidelines. 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: No impact. 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) b. A variant (adding an alternative optional rule alongside an existing Rulebook element) Equens Proposal - IBAN check failed.docx 2 of 3

81 2 Elements for evaluation The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? Yes No Yes Yes Yes Yes Equens Proposal - IBAN check failed.docx 3 of 3

82 Doc: EPC November 2014 (Version 1.0) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Beatrice Alberti Equens SE clm@equens.com Contact details: Your reference: Scheme and document and version number: New reason codes and updated usage rule for reason codes Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Credit Transfer Rulebook Version 8.0 EPC SEPA Direct Debit Core Rulebook Version 9.0 EPC SEPA Direct Debit Business to Business Rulebook Version 7.0 Request Date: For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

83 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): November Description of the suggestion: Background: As EPC Rulebooks for now don t include many technical codes, every Clearing institution defines own Error Codes. These error codes are not included in the main Interbank formats and therefore technical errors often can only be mapped to reason code MS03 (= reason not specified) when forwarded to another participant. This leads to lack of clarity, misunderstandings, requests and repetition of the errors. Suggestions: 1) Implement the following reason codes: - CNOR and DNOR for use in Pacs.004 (currently these are only allowed in Pacs.002 and Pain.002) to be used instead of MS DT01 Invalid Date as already used by (some) CSMs for use in Pacs.002, Pacs.004 and Pain.002 instead of MS03 - ED05 (= SettlementFailed) for use in the pacs.002, in both SCT and SDD. As already used by (some) CSMs for settlement rejects. 2) Implement ISO Reason Code NARR in combination with the XML field AdditionalInformation (Type Max105Text). currently white field, to be shaded yellow. If the reason code is NARR, then AddititionalInformation must be present. If the reason code is not NARR, then AddititionalInformation is optional in ISO. The code should be implemented for Pacs.002, Pacs.004 and Pain.002. This will make it easier for every participant to give detailed information about reason for R- Transaction especially for technical issues. In general, field AdditionalInformation should be allowed for use in combination with the existing SEPA codes. For example the code FF01 (= invalid file format) with in AdditionalInformation the element that causes the problem. 3) (Alternatively to 2) Open up the Reason Proprietary field. Currently this is a white field, it should be shaded yellow. It can then be used for proprietary codes. Then a SEPA code goes in the Reason Code field and a proprietary code goes in the Reason Proprietary field (the two fields are mutually exclusive). 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: Improvement of the scheme 2. Impact on the interbank space: Equens Proposal -add reason codes.docx 2 of 4

84 New information has to be transferred. Validation checks have to be adjusted. 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): New Reason Codes and new Message Element have to be added to the Implementation Guidelines. 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: No impact. 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) b. A variant (adding an alternative optional rule alongside an existing Rulebook element) Equens Proposal -add reason codes.docx 3 of 4

85 2 Elements for evaluation The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? Yes No Yes Yes Yes Yes Equens Proposal -add reason codes.docx 4 of 4

86 Doc: EPC November 2014 (Version 1.0) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Beatrice Alberti Equens SE clm@equens.com Contact details: Your reference: Scheme and document and version number: Validation responsibilities along the processing chain Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Credit Transfer Rulebook Version 8.0 EPC SEPA Direct Debit Core Rulebook Version 9.0 EPC SEPA Direct Debit Business to Business Rulebook Version 7.0 Request Date: For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

87 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): November Description of the suggestion: Background: The EPC Rulebooks for now defines SEPA Usage Rules but not the responsibilities for executing these. All too often there is lack of clarity if a certain check/validation has to be done, can be done or must not be done by a participant that is not the Creditor Agent or Debtor Agent. Example 1: The SEPA CORE DIRECT DEBIT SCHEME INTER-BANK IMPLEMENTATION GUIDELINES for the Use of the FI to FI Customer Direct Debit (pacs ) define a Usage Rule for 2.29 Amendment Information Details: Mandatory if Amendment Indicator is true. If a Clearing institution gets an Pacs.003 with Amendment Indicator true but no Amendment Details he has two options: 1) To reject this payment and get a claim from the Creditor Bank why he is doing too strict validations not essential or not in the scope of a clearing institution. 2) To forward the payment and get a claim from the receiving institution why forwarding a payment that doesn t meet the EPC rules. Example 2: According to the SEPA CREDIT TRANSFER SCHEME INTER-BANK IMPLEMENTATION GUIDELINES Use of FI-to-FI Payment Cancellation Request V01 (camt ) the codes TECH and FRAD have to be used in Proprietary while DUPL has to be filled into element Code. If the element Proprietary is filled with DUPL the Clearing institution again has the two options: 1) To reject the cancellation request and get a claim from the Creditor Bank why he is doing too strict validations not essential or not in the scope of a clearing institution. 2) To forward the payment and get a claim from the receiving institution why forwarding a payment that doesn t met the EPC rules. Suggestion: It must be clear to all the parties involved in the processing chain who is responsible for which validation. In depth checks and validation should be performed exclusively by the bank (of the end users) - meaning the Debtor Agent and the Creditor Agent. Others should only reject a payment if not possible to forward (e.g. format validations fail, BIC is not reachable). EPC should define the responsibilities in general or for each SEPA Usage Rule in the Implementation Guidelines. Equens Proposal- validationresp.docx 2 of 4

88 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: Improvement of the scheme. 2. Impact on the interbank space: Reduction of disagreements and uncertainty because of more precise responsibilities. 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): Responsibilities for SEPA Usage Rules have to be added to the Implementation Guidelines. 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: No impact. 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) b. A variant (adding an alternative optional rule alongside an existing Rulebook element) Equens Proposal- validationresp.docx 3 of 4

89 2 Elements for evaluation The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? Yes No Yes Yes Yes Yes Equens Proposal- validationresp.docx 4 of 4

90 Doc: EPC August 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Contact details: Your reference: Scheme and document and version number: C. Bastian Betaalvereniging Nederland (Dutch Payments Association) P.O. Box 83073, 1080 AB Amsterdam, The Netherlands c.bastian@betaalvereniging.nl, +31(0) or info@betaalvereniging.nl Additional reasoncodes for debtor driven reasons/whitelisting Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version 7.1 Request Date: December 22nd 2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

91 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): November Description of the suggestion: The SEPA regulation has made it obligatory to offer the Debtor the option to be able to block his account for direct debit transactions if: Whitelist in use; creditor / mandate not (properly) listed Creditor blocked Maximum number of Direct Debit transactions within certain period is exceeded by Creditor Transaction exceeds maximum amount Creditors have requested their Creditor Banks to be informed in more detail when Direct Debit transactions are returned based on parameters set by the debtor. In case of a rejected direct debit collection Creditors wants to be able to communicate this with the Debtor based on the specific parameter set by the Debtor. This requires more detailed information than presently provided by the use of reason code SL01. Debtor Banks must be able to report more specific reason codes where today only SL01 is available. By introducing specific codes for each of the four (optional) consumer settings, all parties (in the 4-corner model) can be informed more appropriate to be able to act in line with de parameter used. Therefore the Dutch Payments Association, on behalf of the Dutch Banking community, requests four new reasoncodes to be added to the SDD Rulebooks. These codes, to be used by Debtor Banks, will identify the following four reasons: Code Name Definition SDD CORE SDD B2B SL11 Creditor not on Whitelist of Debtor Whitelisting service offered by the Debtor Agent; Debtor has not included the Creditor on its Whitelist (yet). In the Whitelist the Debtor may list all allowed Creditors to debit Debtor bank account. YES N.A. SL12 Creditor on Blacklist of Debtor Blacklisting service offered by the Debtor Agent; Debtor included the Creditor on his Blacklist. In the Blacklist the Debtor may list all Creditors not allowed to debit Debtor bank account YES N.A. SL13 Maximum number of Due to Maximum allowed Direct Debit Transactions per Direct Debit period service offered by the Debtor Agent Transactions exceeded YES N.A. SL14 Maximum Direct Debit Due to Maximum allowed Direct Debit Transaction amount Transaction Amount service offered by the Debtor Agent exceeded YES YES NOTE: The introduction of the requested four new reason codes also implies the extension of the ISO code set. The Dutch Payments Association did take care of the application process for above mentioned reasoncodes with ISO.org. The codes were approved during the ISO Payments SEG meeting of March SDD_Changes_proposedbyNL _v1.1.docx 2 of 4

92 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: Schemes will become more customer friendly for end-users (especially Creditor-side) 2. Impact on the interbank space: Number of (possible) reasoncodes to be used by Debtor Banks will be extended 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): Yes, list of reasoncodes will be extended with four new reasoncodes 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: NO 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) b. A variant (adding an alternative optional rule alongside an existing Rulebook element) Variant: By adding new reasoncodes Debtor Banks can supply Creditor Banks with more useful information in case whitelisting and/or specific debtor driven services provided by Debtor Banks (as described in the SEPA Regulation) are in use. Creditor Banks can pass this information towards their Creditors. SDD_Changes_proposedbyNL _v1.1.docx 3 of 4

93 2 ELEMENTS FOR EVALUATION The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPAwide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? YES NO YES YES YES YES SDD_Changes_proposedbyNL _v1.1.docx 4 of 4

94 Doc: EPC August 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Contact details: Your reference: Scheme and document and version number: Request Date: For information: CLUB SEPA CLUB SEPA France Hervé SITRUK [herve.siturk@orange.fr] LEI Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Credit Transfer Rulebook Version 8.1 EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version December-2015 This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

95 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): 1.2 Description of the suggestion: The introduction of LEI in SEPA scheme will have functional and organizational impacts. - Need for a special organisation to migrate from ICS architecture to LEI: because many amendments to do if such a choice of Big Bang is done - Impact on message structure: just one for one (ICS vs LEI) or new fields to add through a new pain version - Will the LEI be impacting IG Customer to bank and/or IG Bank to bank? - What kind of interaction with others topics such as protection of personal data? - What would be the objective? 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: 2. Impact on the interbank space: 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) b. A variant (adding an alternative optional rule alongside an existing Rulebook element) #17 All Schemes-Club SEPA France-the introduction of LEI in the EPC SEPA schemes 2 of 3

96 2 ELEMENTS FOR EVALUATION The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? YES YES To be analysed YES YES YES #17 All Schemes-Club SEPA France-the introduction of LEI in the EPC SEPA schemes 3 of 3

97 Doc: EPC August 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Contact details: Your reference: Scheme and document and version number: Request Date: For information: CLUB SEPA CLUB SEPA France Hervé SITRUK [herve.siturk@orange.fr] Multiplication of PAIN versions: need for a clarification concerning the versioning listing in the Rulebooks Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Credit Transfer Rulebook Version 8.1 EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version December-2015 This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

98 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): 1.2 Description of the suggestion: Question: does the mention of pain version mean that this version is mandatory? Indeed we would suggest to delete any reference to the number of version attached to the pain because it can cause confusion and sometimes also there can be a technical gap. Example: the current version of IG refers to 2012 version of ISO pain format (pain ). Whereas the latest version published by ISO Swift in May 2015 mentioned the version pain This difference does not allow the PSP to offer formats based on the latest formats because some stakeholders have in mind that only version listed in the rulebooks is compliant. Besides in IG C2B 2016 (go live Nov 2017): the pain format mentioned is pain in which BIC filed is mandatory. But in February 2016, BIC will be optional. In the latest format published by ISO Swift, pain the BIC field has been removed. So there is a gap. 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: 2. Impact on the interbank space: 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) b. A variant (adding an alternative optional rule alongside an existing Rulebook element) #18 All Schemes-Club SEPA France-Request for clarification on the version of the ISO pain messages in the Rulebooks 2 of 3

99 2 ELEMENTS FOR EVALUATION The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? Yes Yes Yes Yes Yes Yes #18 All Schemes-Club SEPA France-Request for clarification on the version of the ISO pain messages in the Rulebooks 3 of 3

100 Doc: EPC August 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Contact details: Your reference: Scheme and document and version number: Massimo Battistella European Association of Corporate Treasurers (EACT) 3 rue d Edimbourg CS F Paris France massimo.battistella@telecomitalia.it anni.mykkanen@eact.eu EACT CR SDD EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version 7.1 Request Date: 29/12/2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

101 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): November Description of the suggestion: Clarification in business requirements for Attribute AT-22 - The Remittance Information sent by the Creditor to the Debtor in the Collection when Structured remittance information are used. Structured remittance information based on the ISO standard are inserted in the payment message to enable the matching/reconciliation of an incoming payment with the items that such a payment is intended to settle, such as commercial invoices in an accounts receivable system and are supposed to be used in straight-through-processing machine to machine automatic reconciliation. Such information include creditor references or other information of the invoices and eventual credit notes that has been settled with the payment. They should be redefined in the Rulebooks as Structured Machine to Machine Remittance Information. We therefore suggest that business requirements and implementation guidelines have a specific mention to automatic treatment of those information and an indication that such information should be mandatorily transferred to beneficiary only when electronic means in the Beneficiary PSP to Customer space are used, such as in electronic statements of account or other electronic formats using Data Set DS-06 - Bank to customer Direct Debit Information (optional in other cases). The presence of the Structured Machine to Machine Remittance Information remittance information in paper statement of account should be then optional for the PSP of the beneficiary. We further suggest to evaluate the possibility to have a specific new attribute code for the Structured Machine to Machine Remittance Information. Considering the opportunity to use the available ISO standard for end to end straightthrough-processing reconciliation, we consider acceptable that the Beneficiary Bank may drop received Structured Machine to Machine Remittance Information and not make it available to a Beneficiary who is connected with an interface which does not comply with the ISO XML standard. This change request has to be valued in connection with other EACT change request no EACT CR SDD Wherever possible, please indicate: 1. Impact on the Scheme in general: Yes, revision of AT-22 definition and rules in the PSP to Beneficiary space. 2. Impact on the interbank space: None 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): None EACT CR SDD docx 2 of 4

102 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: None 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) Refining current Rulebook element definition and business rules b. A variant (adding an alternative optional rule alongside an existing Rulebook element) EACT CR SDD docx 3 of 4

103 2 ELEMENTS FOR EVALUATION The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? No, but could allow to reap the benefits in the reconciliation processes enabled by the SEPA xml SDD Schemes Yes. Cost of manual, human managed, reconciliation of incoming collections by payers are high for Corporates and the request, connected with other EACT Change request no EACT CR SDD , EACT CR SDD , EACT CR SDD , will enhance the possibility of straight-through-processing in SDD payments reconciliation by the payer. Yes. Straight-through-processing of payment flows has been considered one of most important benefit of SEPA (see ECB 7 th SEPA Progress Report), but it cannot be limited to the interbank space. As evidenced by ECB in the 6 th SEPA Progress Report The full benefits of SEPA will only be reached if SEPA responds to customer needs. End to-end straight-throughprocessing is a major requirement for professional users. Yes, it is feasible No, interoperability will not be impeded. Yes, it is in the scope EACT CR SDD docx 4 of 4

104 Doc: EPC August 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Contact details: Your reference: Scheme and document and version number: Massimo Battistella European Association of Corporate Treasurers (EACT) 3 rue d Edimbourg CS F Paris France massimo.battistella@telecomitalia.it anni.mykkanen@eact.eu EACT CR SDD EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version 7.1 Request Date: 29/12/2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

105 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): November Description of the suggestion: Allow contemporaneous presence of unstructured and structured remittance information in payment messages from creditor to debtor. Currently both business requirements in the Rulebook for Attribute AT-22 - The Remittance Information sent by the Creditor to the Debtor in the Collection - and Implementation Guidelines indicate that either Structured or Unstructured remittance information may be present. We suggest to allow contemporaneous presence of both Structured or Unstructured remittance information. Creditors should then be able to insert and PSPs to transfer to debtors human readable information in the Unstructured remittance information and, when required or useful, structured remittance information using the ISO standard for automatic straight through processing reconciliation in the Structured remittance information ( Structured Machine to Machine Remittance Information - reference to change request EACT CR SDD ). 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: Yes, revision of AT-22 definition and rules in the Creditor to PSP and PSP to Debtor space. 2. Impact on the interbank space: Yes, eventual checks operated by CSMs on the existence of a single occurrence of either Structured or Unstructured xml tags to be removed. Possible increase in message length. 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): Yes, changes in the IG and in PSP to Customer reporting recommendations. 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: None 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) Redefining current Rulebook element definition and business rules b. A variant (adding an alternative optional rule alongside an existing Rulebook element) EACT CR SDD docx 2 of 3

106 2 ELEMENTS FOR EVALUATION The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? No, but could allow to reap the benefits in the reconciliation processes enabled by the SEPA xml SDD Schemes Yes. Cost of manual, human managed, reconciliation of incoming collections by payers are high for Corporates and the request, connected with other EACT Change requests no EACT CR SDD , EACT CR SDD , EACT CR SDD will enhance the possibility of straight-through-processing in SDD payments reconciliation by the payer. Contemporaneous occurrence of both Unstructured and Structured remittance information could increase the use of the Structured remittance information making obsolete the complex and often far-fromautomated processes of remittance advices. Yes. Straight-through-processing of payment flows has been considered one of most important benefit of SEPA (see ECB 7 th SEPA Progress Report), but it cannot be limited to the interbank space. As evidenced by ECB in the 6 th SEPA Progress Report The full benefits of SEPA will only be reached if SEPA responds to customer needs. End to-end straight-through-processing is a major requirement for professional users. Yes, it is feasible No, interoperability will not be impeded. Yes, it is in the scope EACT CR SDD docx 3 of 3

107 Doc: EPC August 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Contact details: Your reference: Scheme and document and version number: Massimo Battistella European Association of Corporate Treasurers (EACT) 3 rue d Edimbourg CS F Paris France massimo.battistella@telecomitalia.it anni.mykkanen@eact.eu EACT CR SDD EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version 7.1 Request Date: 29/12/2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

108 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): November Description of the suggestion: Further clarification on the content and examples of information to be inserted in Attributes AT-27, AT-37 AT-39 used to identify counterparties involved in the payment. These attributes refer to elements of the ISO standard designed to transfer information (codes) useful for the automatic and straight-through-processing identification of the counterparties involved in the payment: AT-27 Debtor Identification Code AT-37 The identification code of the Debtor Reference Party AT-39 The identification code of the Creditor Reference Party In order to be effective, the codes inserted by the creditor in the attributes should allow a unique and unambiguous way of identifying an organisation or an individual person. We suggest to insert in the Rulebooks description of the above attributes their purpose and examples of codes that could be inserted by the creditor in the payment initiation message. For attributes AT-27 and AT-37: The codes inserted in the attribute should allow a unique and unambiguous way of identifying an organisation or an individual person. Examples of codes that, among others, could be inserted are Fiscal Code, VAT Code, Enterprise Registration Number, Business Identity Code, Organization Code, Trade Register Number, Business Register Number, National Tax ID, Customer Code. For attribute AT-39: The codes inserted in the attribute should allow a unique and unambiguous way of identifying an organisation or an individual person. Examples of codes that, among others, could be inserted are Fiscal Code, VAT Code, Enterprise Registration Number, Business Identity Code, Organization Code, Trade Register Number, Business Register Number, National Tax ID, Supplier Code. 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: Yes, refinement of AT-27, AT-37, AT-39 definitions. EACT CR SDD docx 2 of 4

109 2. Impact on the interbank space: None 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): None. 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: None. 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) Redefining current Rulebook element definition. b. A variant (adding an alternative optional rule alongside an existing Rulebook element) EACT CR SDD docx 3 of 4

110 2 ELEMENTS FOR EVALUATION The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? No, but could allow to reap the benefits in the reconciliation processes enabled by the SEPA xml SDD schemes. Yes. Efficiency and effectiveness in the reconciliation of collection by the payer are highly effected by the quality of information inserted by the creditor. Furthermore it is often difficult to identify the creditor and the ultimate creditor only on the mere basis of the name. Where available, additional and codified information transferred to the debtor will improve automatic identification of the payee, matching of open items on accounts payable and reducing the administrative effort for reconciliation. The request, connected with other EACT Change request no EACT CR SDD , EACT CR SDD , EACT CR SDD , will enhance the possibility of straight-through-processing in SDD payment reconciliation by the payer. Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? Yes. Straight-through-processing of payment flows has been considered one of most important benefit of SEPA (see ECB 7 th SEPA Progress Report), but it cannot be limited to the interbank space. As evidenced by ECB in the 6 th SEPA Progress Report The full benefits of SEPA will only be reached if SEPA responds to customer needs. End to-end straight-through-processing is a major requirement for professional users. Yes, it is feasible No, interoperability will not be impeded. Yes, it is in the scope EACT CR SDD docx 4 of 4

111 Doc: EPC August 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Contact details: Your reference: Scheme and document and version number: Massimo Battistella European Association of Corporate Treasurers (EACT) 3 rue d Edimbourg CS F Paris France massimo.battistella@telecomitalia.it anni.mykkanen@eact.eu EACT CR SDD EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version 7.1 Request Date: 29/12/2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

112 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): November Description of the suggestion: Amendment of Attributes present in Data Set DS-06 - Bank to Customer Direct Debit Information and business rules for debtor PSPs. Currently it is not mandatory the communication from debtor PSP to the debtor of the following attributes (if present in Data Sets DS-03 and DS-04) designed to transfer information useful for the automatic and straight-through-processing identification of the counterparties involved in the payment: AT-05 The address of the Creditor AT-15 The name of the Debtor Reference Party AT-18 The identifier of the original Creditor who issued the Mandate AT-37 The identification code of the Debtor Reference Party AT-38 The name of the Creditor Reference Party AT-39 The identification code of the Creditor Reference Party AT-58 The purpose of the Collection To facilitate collection reconciliation by the payer if any of such information is inserted by the creditor in the collection (therefore present in DS-03) it must be transferred to the debtor in the messages used to convey Data Set DS-06. We suggest to amend the Rulebooks so that where any of the above attributes are present in an interbank payment message (DS-04) the contents must be made available in full by the debtor PSP to the debtor, subject to any prior agreement to the contrary. A debtor PSP may drop received extended reference party information (attributes 15, 18, 37, 38, 39 and 58) and not make it available to a debtor who uses an interface which does not comply with the ISO XML standard. 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: Yes, revision of DS-06 definition and business rules in the PSP to Beneficiary space. 2. Impact on the interbank space: None 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): Yes, changes in the PSP to Customer reporting recommendations. EACT CR SDD docx 2 of 4

113 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: None. 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) Redefining current Rulebook element definition and business rules. b. A variant (adding an alternative optional rule alongside an existing Rulebook element) EACT CR SDD docx 3 of 4

114 2 ELEMENTS FOR EVALUATION The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? No, but could allow to reap the benefits in the reconciliation processes enabled by the SEPA xml SDD schemes. Yes. Efficiency and effectiveness in the reconciliation of SDD collection by the payer are highly effected by the quality of information inserted by the creditor. Furthermore it is often difficult to identify the creditor and the ultimate creditor only on the basis of the name. Where available, additional and codified information must be transferred to the debtor to improve automatic identification of the payee, matching of open items on accounts payable and reducing the administrative effort for reconciliation. The request, connected with other EACT Change request no EACT CR SDD , EACT CR SDD , EACT CR SDD , will enhance the possibility of straight-through-processing in SDD collections reconciliation by the payer. Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? Yes. Straight-through-processing of payment flows has been considered one of most important benefit of SEPA (see ECB 7 th SEPA Progress Report), but it cannot be limited to the interbank space. As evidenced by ECB in the 6 th SEPA Progress Report The full benefits of SEPA will only be reached if SEPA responds to customer needs. End to-end straight-through-processing is a major requirement for professional users. Yes, it is feasible No, interoperability will not be impeded. Yes, it is in the scope EACT CR SDD docx 4 of 4

115 Doc: EPC August 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Contact details: Pilar Clavería Spanish banking Community Velázquez MADRID pclaveria@aebanca.es Your reference: Scheme and document and version number: EPC SEPA Direct Debit Core Rulebook Version 9.1 Request Date: 30 Dec For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

116 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): Next SDD Core Rulebook version. 1.2 Description of the suggestion: SDD Core Rulebook states that Reversals may only be processed from Settlement date and within the five Inter-Bank Business Days following the Due Date requested in the original Collection. Later presentations must not be processed by the Creditor Bank or CSMs mandated to act as such and the Debtor Bank must be so informed. We propose to extend reversal period for the creditor from the current five days to ten inter-bank business days. 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: Minimum 2. Impact on the interbank space: Reversals would need to be processed from Settlement date and within the ten Inter-Bank Business Days following the Due Date requested in the original Collection. 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): None. 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: None. 5. The nature of the suggestion: a a. A change (deleting or replacing an existing Rulebook element by a new one) b. A variant (adding an alternative optional rule alongside an existing Rulebook element) #30 SDD Core-ES banking community-extension of the reversal period for the creditor from 5 days to 10 inter-bank business days 2 of 3

117 2 ELEMENTS FOR EVALUATION The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? Yes No No Yes Yes, It does not impede SEPA-wide interoperability Yes #30 SDD Core-ES banking community-extension of the reversal period for the creditor from 5 days to 10 inter-bank business days 3 of 3

118 Doc: EPC August 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Contact details: Your reference: Scheme and document and version number: Roland Flommer German Banking Industry Committee on behalf of the German banking community c/o Deutscher Sparkassen- und Giroverband e.v. Charlottenstraße Berlin, Germany roland.flommer@dsgv.de DK-SEM Version 1.0 Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Credit Transfer Rulebook Version 8.1 EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version 7.1 Request Date: 30 December 2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

119 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): November Description of the suggestion: Amend Chapter 1.4 Character Set of the Customer-to-Bank and Inter-Bank Implementation Guidelines of all three SEPA Scheme Rulebooks to reflect the RECOMMENDED BEST PRACTICE as outlined in Section 5 of the document EPC SEPA Requirements for an Extended Character Set (UNICODE Subset) Best Practices in general and the 4 principles mentioned in this section in particular. 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: Increase acceptance of SEPA payments by supporting the use of national characters similar to national practices. 2. Impact on the interbank space: There is no need for a sending scheme participant to agree upfront with the receiving scheme participant the use of the full UTF-8 character set. 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): Chapter 1.4 Character Set of all Implementation Guidelines should adopt the RECOMMENDED BEST PRACTICE of Section 5 of document EPC Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: none 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) A change of Chapter 1.4 in the Customer-to-Bank and Inter-Bank Implementation Guidelines of all three SEPA Scheme Rulebooks b. A variant (adding an alternative optional rule alongside an existing Rulebook element) #32 All Schemes-GBIC-Amendment to Chapter '1.4 Character Set' of the Customer-to-Bank and Inter-Bank IGs 2 of 4

120 2 ELEMENTS FOR EVALUATION The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? YES NO However, today sending scheme participants need to develop functionality to support different character sets depending on which country/ language the counterparty bank is located in. YES It increases the acceptability of SEPA payments by national users of payment services YES However, there may be a need for change by receiving scheme participants YES In fact, it will increase the interoperability YES #32 All Schemes-GBIC-Amendment to Chapter '1.4 Character Set' of the Customer-to-Bank and Inter-Bank IGs 3 of 4

121 3 ELEMENTS FOR EVALUATION The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? YES NO However, today sender banks need to develop functionality to support different character sets depending on in which country/language the counterparty bank is located YES It increases the acceptability to national users of payment services YES However, there may be a need for change in the receiving banks YES In fact, it will increase the interoperability YES #32 All Schemes-GBIC-Amendment to Chapter '1.4 Character Set' of the Customer-to-Bank and Inter-Bank IGs 4 of 4

122 Doc: EPC August 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: José Vicente Portuguese Banking Community Address: Contact details: Your reference: Scheme and document and version number: Tel: / Mobile jvicente@millenniumbcp.pt PT_Rulebook_SCT 2017 PT_Rulebook_SDD Core 2017 PT_Rulebook_SDD B2B 2017 Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Credit Transfer Rulebook Version 8.1 EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version 7.1 Request Date: 04 December 2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

123 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): November Description of the suggestion: Our suggestion for the 2017 Rulebook release is related with the category purpose of the credit transfer (AT-45). This kind of information must be mandatory and not optional. It will help all participants (Originator banks and Beneficiary banks) of the scheme to identify correctly the purpose of the transaction to improve market practices and make this useful for the beneficiary bank as well the ordering bank. The same procedure for SEPA DD should be applied. 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: Low or null Impact 2. Impact on the interbank space: Low or null Impact 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): Low or null Impact 4. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: Low or null Impact 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) Change a rule from optional to mandatory b. A variant (adding an alternative optional rule alongside an existing Rulebook element) #34 All Schemes-PT banking community-the category purpose of the credit transfer (AT-45) - collection (AT-59) to be mandatory 2 of 3

124 2 ELEMENTS FOR EVALUATION The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? Yes, because the identification of payment reasons, thanks the availability of specific data fields, allows on a very positive way to indicate payment types such as salaries, pensions or taxes, for example, allowing the originator bank or the beneficiary bank to apply special processing rules. Furthermore, this will also help to achieve full migration among the Portuguese Banking Community as well as the Public Administration, as this is a very important feature of the current legacy scheme. Yes. Yes. Yes. Yes, this suggestion does not impede SEPA interoperability Yes. #34 All Schemes-PT banking community-the category purpose of the credit transfer (AT-45) - collection (AT-59) to be mandatory 3 of 3

125 Doc: EPC August 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Contact details: Your reference: Scheme and document and version number: Margarita Starkeviciute Independent member of the EPC Scheme Management Board N/A N/A N/A Scheme Management Internal Rules (SMIRs) which are included in the SCT, SDD Core and SDD B2B Rulebooks Request Date: 23 December 2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

126 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): First following Rulebook update. 1.2 Description of the suggestion: The proposal is to adapt section 2.1 of the Scheme Management Internal Rules as follows: 2 SCHEME MANAGEMENT ROLES AND RESPONSIBILITIES 2.1 Role of the Scheme Management Board The SMB shall be responsible for performing the following functions of SEPA Scheme Management: Management of the maintenance and the evolution of the EPC Schemes (supported by the SEMWG and other relevant EPC bodies) Interaction with the Scheme end-users and relevant stakeholders (Scheme End-User Forum) Interaction with Clearing and Settlement Mechanisms and other technical providers (Scheme Technical Forum) For efficient management of the evolution the EPC schemes, the Scheme Management Board shall be supported by all relevant EPC bodies set up by the EPC Board. 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: No operational impact 2. Impact on the interbank space: No impact Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): No impact 3. Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: No impact. The proposed suggestion has already been positively reviewed by the Scheme Management Board and the EPC Board. 4. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) Yes. b. A variant (adding an alternative optional rule alongside an existing Rulebook element) N/A #36 All Schemes-Starkeviciute-Amendment to section 2.1 of the Scheme Management Internal Rules (SMIRs) 2 of 3

127 2 ELEMENTS FOR EVALUATION The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? Yes N/A N/A Yes Yes Yes #36 All Schemes-Starkeviciute-Amendment to section 2.1 of the Scheme Management Internal Rules (SMIRs) 3 of 3

128 Doc: EPC September 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Scheme Evolution and Maintenance Working Group (SEMWG) EPC Address: -- Contact details: Your reference: Scheme and document and version number: -- #37 Additional customer-to-customer information Highlight which EPC SEPA Scheme Rulebook(s) this suggestion relates to: EPC SEPA Credit Transfer Rulebook Version 8.1 EPC SEPA Direct Debit Core Rulebook Version 9.1 EPC SEPA Direct Debit Business to Business Rulebook Version 7.1 Request Date: 30/12/2015 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: nts_id=535 Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu

129 1 GENERAL DESCRIPTION OF THE SUGGESTION 1.1 Suggested launch date (if any): Suggested Effective date: November Description of the suggestion: The current EPC SEPA schemes permit the end-to-end carrying of remittance data on a structured or unstructured basis (AT-05 remittance information, AT-22 the remittance information sent by the Creditor to the Debtor in the Collection). The scheme rules allow for one repetition of the remittance information field of up to 140 characters to be included with the remittance information. While this has generally been considered sufficient for most retail payment needs, during the last couple of years there have been several change requests by different stakeholder groups and banking communities asking for a possibility to use larger remittance information. It indicates that the present 140 characters of remittance information are not enough for certain users or communities in the SEPA area. The ISO enables unlimited number of repetitions of the unstructured 140 character remittance information field or an unlimited number of structured remittance information instances. The SEPA End-Date Regulation sets the similar 140 characters end-to-end requirement but does not prohibit the transmission of longer remittance information. To meet those previous change suggestions, it is proposed to make additional customer-to-customer information available outside of the payment transaction from the SCT or SDD message. The payment message would only carry the information of the location where the additional customerto-customer information is stored. The additional data exceeding 140 characters can then be sent separately from the SCT or SDD payment message. Additional data elements/ attributes that already exist in ISO can be taken up in the three EPC SEPA scheme rulebooks (e.g., data element 2.94 RemittanceLocationElectronicAddress having a maximum length of 2048 characters). These new attributes will store details of the location from where the additional customer-to-customer information can be retrieved. It is emphasized that the current limited character set to be used in the three EPC SEPA schemes would remain unchanged. Furthermore, the additional attributes storing the location of the additional customer-to-customer information would be optional fields. This means that only when the Originator or the Creditor provides information about the storage location of the additional customer-to-customer information in these optional fields, it is mandatory for the Originator Bank or Creditor Bank to transport this storage location information in these fields to the Beneficiary Bank or to the Debtor Bank. In case of an arrangement between Beneficiary Bank and the Beneficiary/ between the Debtor Bank and the Debtor, the information about the storage location could be made available. These storage location details are sent together with the SCT or SDD message but are not part of the SCT or SDD payment. Upon review by the EPC s Legal Support Group in 2015 no legal or regulatory concerns were identified in the context of this proposed solution. The diagram below provides an illustration about the concept of making additional customer-tocustomer information (AC2CI) available: #37 All Schemes-EPC SEMWG- additional customer-to-customer information 2 of 5

130 1.3 Wherever possible, please indicate: 1. Impact on the Scheme in general: SCT Rulebook: Section 2.7 remittance data: additional wording indicating the option to indicate the storage location of extended remittance information via a message other than the SCT payment message DS-01, DS-02 and DS-04: inclusion of new optional attributes to be used for the identification and the location of the extended remittance information Section 4.6: o Additional wording in AT-05 indicating the option to indicate the storage location of extended remittance information via a message other than the SCT payment message o Description of the new optional attributes to needed to facilitate the optional exchange of extended remittance information Section 7: definition of the term remittance information (extended) SDD Core Rulebook and SDD B2B Rulebook: DS-03, DS-04 and DS-06: inclusion of new optional attributes to be used for the identification and the location of the extended remittance information Section 4.8: Description of the new optional attributes to needed to facilitate the optional exchange of extended remittance information Section 7: definition of the term remittance information (extended) 2. Impact on the interbank space: It means that only when the Originator/ Creditor provides information about the storage location of the additional customer-to-customer information in these optional fields, it is mandatory for the Originator Bank/ Creditor Bank to transport this storage location information in these fields to the Beneficiary Bank/ Debtor Bank. In case of an arrangement between the Beneficiary Bank/ Debtor Bank and the Beneficiary/ Debtor, the information about the storage location could be made available. 3. Impact on the message standards (SEPA Scheme Implementation Guidelines and other standards): SCT Customer-to-Bank IGs: Customer Credit Transfer Initiation (pain ): 2.1.3, Index 2.91 #37 All Schemes-EPC SEMWG- additional customer-to-customer information 3 of 5

131 SCT Inter-Bank IGs: FI to FI Customer Credit Transfer (pacs ) , Index 2.68 SDD Core Inter-Bank IGs: FI to FI Customer Direct Debit (pacs ) , Index 2.74 SDD Core Customer-to-Bank IGs: Customer Direct Debit Initiation (pain ) , Index 2.81 SDD B2B Inter-Bank IGs: FI to FI Customer Direct Debit (pacs ) , Index 2.74 SDD B2B Customer-to-Bank IGs: Customer Direct Debit Initiation (pain ) , Index Impact on the legal rules as defined in chapter 5 of the EPC SEPA Scheme Rulebooks: No impact. 5. The nature of the suggestion: a. A change (deleting or replacing an existing Rulebook element by a new one) YES b. A variant (adding an alternative optional rule alongside an existing Rulebook element) YES #37 All Schemes-EPC SEMWG- additional customer-to-customer information 4 of 5

132 2 Elements for evaluation The submitting party is requested to give an appropriate answer to each of these questions with sufficient detail to allow the EPC to make an evaluation of the suggestion submitted. Is the suggestion a case for SEPA wide acceptance? Is the suggestion underpinned by a cost-benefit analysis? Does the change fit in the strategic objectives for SEPA? Do you consider that the implementation of the change resulting from the acceptance of the suggestion is feasible? Do you consider that the suggestion does not impede SEPA-wide interoperability? Do you consider that the suggestion is in the scope of the scheme involved? YES. In the last years, several change requests by different stakeholder groups and banking communities had been made asking for a possibility to use additional customer-to-customer information. NO YES YES YES YES #37 All Schemes-EPC SEMWG- additional customer-to-customer information 5 of 5

133 Doc: EPC August 2015 (Version 1.1) EPC Template for proposing a suggestion for a change in a SEPA Payment Scheme Responses by to: change-request.epc-scheme@epc-cep.eu by 31 December 2015 Name of contributor: Organisation: Address: Contact details: Your reference: Scheme and document and version number: EPC Director General EPC Secretariat N/A N/A 38 Each of the SCT, SDD Core and SDD B2B Rulebooks, as well as the Scheme Management Internal Rules (Annex II of the SCT, SDD Core and SDD B2B Rulebooks) Request Date: 25 January 2016 For information: This template is provided by EPC to allow any person or organisation to submit a suggestion for making a change to the SEPA Schemes in accordance with the rules set out in the document SEPA Scheme Management Internal Rules (SMIRs) available on the EPC Website: Conseil Européen des Paiements AISBL Cours Saint-Michel 30A, B-1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu