The Ultimate Guide to SEPA Migration

Transcription

1 Deutsche Bank Global Transaction Banking September 2013 The Ultimate Guide to SEPA Migration Update: Finalise your preparations now!

2 2

3 Introduction SEPA, the Single Euro Payments Area, has been a reality since January 2008, when the SEPA Credit Transfer came into effect. This has now been implemented in 33 European countries. A second milestone was achieved in November 2009, with the launch of the SEPA Direct Debit scheme. Michael Spiegel Global Head of Trade Finance and Cash Management Corporates 31 March 2012 saw the passing of the SEPA-Migration End-Date Regulation (Regulation (EU) No. 260/2012 of the European Parliament and of the Council of 14 March 2012 establishing technical and business requirements for credit transfers and direct debits in Euro and amending Regulation (EC) No 924/2009), which established 1 February 2014 as the end-date for SEPA migration. As a result, SEPA is no longer a voluntary initiative, but a regulatory requirement. Corporate migration to the new instruments is therefore necessary, and with the end-date fast approaching, we recommend that you focus on finalizing your migration preparations immediately. In this version of the Ultimate Guide to SEPA Migration you will find some updates that incorporate additional topics and country information (e.g. Estonia, Finland, Ireland, Luxembourg, The Netherlands and Slovakia). As well as the country essentials you will find detailed information about the usage of Member State Options of Regulation (EU) No. 260/2012, D-1 Core SEPA Direct Debit and guidance on handling of Multilateral Interchange Fee (MIF). Deutsche Bank is pleased to assist you in migrating to the new payment schemes. As part of our commitment to help you achieve a seamless transition, we have developed this guide, which covers the main issues for your consideration. We wish you every success and a smooth transition! Michael Spiegel 3

4 Table of Contents 1 Background What is SEPA? Benefits SEPA and Centralisation Background Bank Connectivity Deutsche Bank and SEPA Regulation EPC Rulebooks Payment Services Directive (Dir / 64 / EC) Regulation on cross-border payments (Reg. 924 / 2009) SEPA-Migration End-Date Regulation (Reg. 260 / 2012) The SEPA Credit Transfer Characteristics The SEPA Direct Debit Introduction Core vs. B2B SDD Submission Deadlines and Processing Flow D 1 Core SDD 25 2 Implementation Project Team General Requirements Strategic Aspects Tactical Aspects SCT and SDD Tactical Aspects SCT only Tactical Aspects SDD only Tactical Aspects of the MT940 Account Statement Tactical Aspects XML Account Statements Country-Specific Requirements Austria Belgium Czech Republic 49 4

5 2.3.4 Estonia Finland France Germany Hungary Ireland Italy Luxembourg Netherlands Poland Portugal Slovakia Spain Switzerland United Kingdom 69 3 Annex Abbreviations Useful Links List of Hyperlinks Payment Factory Brochure Availability of local IBAN Conversion Services in Europe Overview of IBAN-Conversion Offering by Accuity Overview of Member State Options Overview of XML-Conversion Offering by Simplex Overview of XML-Conversion Offering by Sentenial XML checker Country-by-country overview of how to obtain the Creditor ID Overview of XML Reference Fields Additional details about the Pre-notification End Date for European Payment Instruments Index 103 5

6 6

7 1 Background 1.1 What is SEPA? SEPA stands for Single Euro Payments Area and is an initiative by the European Banking sector (via the European Payments Council (EPC), which administers the SEPA schemes) to harmonise Euro payments in Europe. The objective is to transform the Euro payments landscape into a borderless area. Cashless Euro payments, such as credit transfers and direct debits, made between and among European countries should become as simple, quick and cost-effective as domestic payments. For credit transfers, SEPA was first implemented in January 2008, signalling an end to varying national payment schemes and allowing companies and consumers to make Euro credit transfers across Europe under the same terms and conditions. A similar simplification process was implemented for direct debit payments in November 2009, but in this case the initiative the SEPA Direct Debit was entirely new, as a cross-border direct debit instrument had previously not existed. Payments Environment pre-sepa Paris Paris French Credit Transfer and Direct Debit French Credit Transfer and Direct Debit Lyon Lyon Paris Paris Lyon Lyon EU Cross-Border Payment X-Border Direct Debits EU not Cross-Border possible Payment X-Border Direct Debits not possible Payments Environment with SEPA SEPA Credit Transfer and Direct Debits SEPA Credit Transfer and Direct Debits Frankfurt Frankfurt German Credit Transfer and Direct Debit German Credit Transfer and Direct Debit Munich Munich Frankfurt Frankfurt Munich Munich Map of Europe Countries encompassed in the SEPA Initiative EEA: EU Euro countries EEA: EU Non-Euro countries EEA: Non-EU countries Non-EEA countries Canary Islands 7

8 The 33 SEPA countries EEA: EU Euro countries (17 countries) Austria Italy Belgium Luxembourg Cyprus Malta Estonia Netherlands Finland Portugal France Slovakia Germany Slovenia Greece Spain Ireland EEA: EU Non-Euro countries (11 countries) Bulgaria Lithuania 1.2 Benefits While the benefits from SEPA were not sufficiently compelling to warrant migration for the majority of corporates, particularly in the absence of a regulatory requirement 1, there are significant benefits that can be realised. Of course, these will vary between companies and also depend on a number of other factors, such as the company structure. However, general benefits can include: Stronger incentive for (regional) payment / collection factories Better control and risk management resulting from: The standardisation of payment formats and bank interfaces The optimisation and standardisation of internal processes Improved visibility over and access to cash (in case of a reduction / centralisation of bank accounts) Reduced float Easier access and growth into new markets Reduced differences in bank fees across Europe and reduced fees in higher-priced markets. Croatia Czech Republic Denmark Hungary Poland Romania Sweden United Kingdom Latvia EEA: Non-EU countries (3 countries) Iceland Norway Liechtenstein Non-EEA countries (2 countries) Monaco Switzerland Over the next few months, legacy national Euro payment instruments and SEPA schemes will co-exist. The end date for this dual phase, after which existing legacy national Euro schemes will be discontinued, has been set via regulation for 1 February This means that existing ACH (Automated Clearing House) schemes for credit transfers and direct debits in the Euro countries will cease to exist as of that date (localcurrency schemes in non-euro countries will continue to exist, however). Therefore, companies are advised to prepare for their SEPA migration right away. 1 As reflected by the low migration rates, which are tracked by the European Central Bank (see Annex page 72, section 3.2 / 1) 8

9 1.3 SEPA and Centralisation SEPA is one of the drivers behind a renewed corporate interest in the centralisation of payables and receivables processing. We should therefore like to provide a general overview of payment/ collection factories and bank-connectivity options. However, with SEPA now being a regulatory project, which requires completion by 1 February 2014, the question of whether to centralise may have to be made independently of all SEPA migration plans. It is therefore important to ensure that any centralisation project threatens no delay to SEPA migration timelines Background Please refer to the appendix for our payment factory brochure The Road to European Payment / Collection Factories (see Annex page 74, section 3.4). Please note that this is intended as a high-level introduction to the topic. The more complex questions around payments-onbehalf-of (POBO) or collections-on-behalf-of (COBO) are beyond the scope of this SEPA-migration document Bank Connectivity Global format and bank connectivity are both components of integration. The technical set-up of bank connectivity is a crucial factor to the success of any centralisation project. Deutsche Bank offers numerous connectivity options for the sending of SEPA files. These include: db direct internet Host-to-Host SWIFTNet for Corporates EBICS (for Germany and France) Integration solutions ERP System SAP Global Formats BELLIN Treasury System omikron SWIFT others Feedback Messages cogon OpusCapita ecofinance REVAL SAP Account Statements HANSE ORGA others Plug and Play 9

10 The Flow of Payments / Collections in a Payment- / Collection-Factory Structure IT & Ops Services Vendor Mgmt File Transfer ACH Sub 1 Sub 2 Sub 3 SLAs ERP / TWS / SAP Local Format, XML, EDIFACT, CSV, IDOC, MT 101 Authorisation Feedback-File Transfer EBICS db direct internet HTTPS direct connect e.g. HTTPS / AS2 Deutsche Bank Systems HVP Clearing Sub 4 MT 940 MT 942 BAI Account- Statement Transfer SWIFT FileAct MA-CUG and SCORE Cheque Business Units Payment / Collection Factory Manual or automated Deutsche Banks s Global Centralisation Solution The final decision on connectivity depends on the requirements of the customer: Which processing-automation level is desired? Is the customer looking for a multi-bank solution (e.g. EBICS in Germany) Does the customer use a third-party treasury system like BELLIN, Hanse Orga, etc.? Different criteria need to be considered and analyzed during the first phase of the integration project in order to determine the most appropriate connection. Deutsche Bank provides guidance on this, and supports the customer accordingly. Furthermore, Deutsche Bank has established different integration solutions with several treasury systems (e.g. BELLIN, Hanse Orga, Omikron, or Opus Capita). These solutions are designed to provide pre-tested blueprints for our customers to reach a high level of automation and to minimise risk, implementation cost and project timelines. 1.4 Deutsche Bank and SEPA Deutsche Bank has been processing SEPA Credit Transfers and SEPA Direct Debits since day one of each instrument s introduction. As such, we have extensive experience of processing both SCTs and SDDs. We have invested heavily in a brand-new, state-of-the-art SEPA processing engine that is connected to our eurozone, UK, Switzerland, Poland, Czech-Republic and Hungary branches, thereby allowing customers to initiate and receive SEPA transactions from all existing accounts. We were also the first bank to announce domestic pricing for all bulk cross-border transactions within the SEPA area even for amounts exceeding EUR 50,000 and/or not executed as SCTs. This also means that we have treated all SEPA-compliant transactions as domestic transactions from the very start. As such, we have shaped the market for the benefit of our clients. 10

11 We have been offering format-conversion services since 2008 and have facilitated our clients SEPA migration for a number of years. However, as per Regulation 260 / 2012 (for more information on this regulation, please refer to section 1.5.4), the XML format will be binding for the exchange of bulk transactions between corporates and banks in eurozone countries from 1 February 2014 (unless the member state uses the option to postpone this until 1 February 2016). Thus, corporates are advised to migrate to the XML format. For more details on this topic, please refer to section To summarise, SEPA migration is no longer optional; it is mandatory. As such, corporates should ensure their migration is complete by late 2013 to be sure of meeting the 1 February 2014 deadline. While certain migration measures must be undertaken by corporates themselves, Deutsche Bank can help its clients keep these to a minimum by offering value-added services and providing detailed information. Deutsche Bank also offers a variety of other value-added services. Among them are: Local IBAN Conversion Services in Europe (see Annex page 83, section 3.5) and in addition a referral agreement with the vendor Accuity (see Annex page 86, section 3.6) Population of missing receiving bank s Business Identifier Code (BIC). To ensure that the correct BICs are used, we also recommend use of the SWIFT BIC Directory (see Annex page 72, section 3.3 / 1) or SWIFT BICPlusIBAN (see Annex page 72, section 3.3 / 2). Support of processing priorities and various booking preferences As debtor bank: optional mandate check 11

12 1.5 Regulation As mentioned above, the end date for SEPA migration has been set via regulation. The SEPA-Migration - End-Date Regulation (Regulation (EU) No 260/2012) became necessary, because corporate and public sector migration from legacy instruments to SEPA was deemed too slow 2, which would indicate that the financial incentives for migration were not adequately substantial. Although this regulation is the first legislation at European level to impose the use of specific standards for the processing of Euro payments on both payment service providers and their customers, it is not the first to be aimed at harmonizing payment processing in Europe. What follows on the next page is an overview of the most relevant harmonisation rules and laws. Overview of the major regulatory and self-regulatory milestones in the European payment-harmonisation process % SEPA Migration End-date EUR as cashless currency EUR as cash EC 2560 / 2001 Reg. on x-border payments in effect EC 924 / 2009 Reg. on x-border payments in effect SEPA Credit Transfers PSD in effect SEPA Direct Debits Review of PSD Reg. EC 260 / 2012 on technical and business requirements for CTs and DDs in Euro in effect Review of Reg. EC 260 / 2012 % share of SCTs in number of total transactions processed via CSMs % share of SDDs in number of total transactions processed via CSMs % Phase-out of legacy payments Regulation / Directive EPC SEPA Schemes Introduction of the Euro Source: Euro Banking Association guide Banks preparing for SEPA Migration 2 The current migration rates are available from the European Central Bank (see Annex page 72, section 3.2 / 1) 12

13 1.5.1 EPC Rulebooks The rules of the game, which all SEPA banks must observe, are documented in the EPC s rulebooks for SEPA Credit Transfers (SCT), Core SEPA Direct Debits (Core SDD) and B2B SEPA Direct Debits (B2B SDD), respectively. According to the EPC, these rulebooks provide a set of inter-bank rules, practices and standards that allow the banking industry to offer SEPA credit transfer and direct debit products to customers. As a result, all SEPA instruments will be provided on the same essential conditions and modalities throughout the SEPA zone. While the rulebooks are binding only for banks, their requirements are also reflected in the credit transfer and direct debit agreements or the general terms and conditions agreed on between banks and clients. One example of a rulebook requirement that is also reflected in the client agreement is the need to have mandates in place when submitting direct debits for collection Payment Services Directive (Dir / 64 / EC) The Payment Services Directive (PSD) provides the legal foundation for the creation of an EU-wide single market for payments. The PSD aims at establishing a modern and comprehensive set of rules applicable to all payment services in the European Union. The target is to make cross-border payments as easy, efficient and secure as national payments within a member state. The PSD also seeks to improve competition by opening up payment markets to new entrants, thus fostering greater efficiency and cost-effectiveness. At the same time, the Directive provides the necessary legal platform for SEPA. The full name of this law is Directive 2007 / 64 / EC of the European Parliament and of the Council of 13 November 2007 on payment services in the internal market amending Directives 97 / 7 / EC, 2002 / 65 / EC, 2005 / 60 / EC and 2006 / 48 / EC and repealing Directive 97 / 5 / EC. The text is available in 23 EU languages via this hyperlink: PSD (see Annex page 72, section 3.3 / 3). As opposed to a regulation which comes into effect the day after its publication in the Official Journal of the European Union the EU member states have had to adopt national rules implementing the Payment Services Directive into domestic law. Aside from the EU member states, Iceland, Liechtenstein and Norway have also implemented the directive. Thus, the PSD applies not just to the 28 EU member states, but to all 31 EEA (European Economic Area) member states. However, of the 33 SEPA countries, the PSD does not apply to Monaco and Switzerland. What follows is an overview of the PSD s key provisions. In Scope The PSD applies to all payment services (e.g. credit transfers, direct debits, card payments, cash deposits to and withdrawals from a payment account, issuing and acquiring of payment instruments, money remittance) provided within the EEA. However, as opposed to the SEPA-Migration End-Date Regulation (see section 1.5.4) which only applies to Euro transactions the PSD applies to all EEA currencies. For the PSD to apply, both the sender bank and the beneficiary bank must be located in the EU / EEA (Two-leg-in principle). An exception are the value-dating provisions of the PSD they apply even if only the payer s or the payee s bank is located in the EU / EEA (One-leg-in principle). In those cases, the respective bank located in the EU / EEA will have to comply with the value-dating provisions. 13

14 Out of Scope Examples of where the PSD does not apply include payment transactions based on paper cheques; payment transactions carried out between payment-service providers, their agents or branches for their own account; or payment transactions carried out within a payment / securities-settlement system between settlement agents, central counterparties, clearing houses and / or central banks and other participants of the system, or payment-service providers. Payment Order Upon receipt of a payment order, the execution time of the PSD (see below) starts to run. If the sender bank refuses to execute a payment order, it has to inform the sender hereof within these execution times. The time of receipt of a payment order is determined as the time when the payment order has been transmitted directly by the payer to the sender bank, or indirectly by or through the payee to the sender bank. If the time of receipt is not on a business day, the payment order is deemed to have been received on the following business day. The sender bank may establish cut-off times near the end of a business day. A payment order is received even if the order itself does not contain all information necessary to execute the payment transaction (non-straight-through-processing items). A payment user and his bank may agree that the execution of a payment order shall start on a specific day, or on the day on which the payer has set funds at his bank s disposal. If there is no such agreement, then the execution time starts to run even if there are insufficient funds in the payer s account. Due to the short execution times, a payment order (once it has been received by the sender bank) can only be revoked in exceptional cases. Execution Times The sender bank is liable for complying with the execution times set by the PSD. Therefore, the sender bank is also liable for acts or omissions of an intermediary bank. The sender bank is obliged to credit the amount of a payment transaction to the account of the beneficiary s bank within the execution times. The execution times of the PSD are defined as maximum execution times. Accordingly, the sender bank has to transfer any funds as soon as possible. Payment transactions in Euro, and most payment transactions in an EU- / EEA-currency have to be credited to the payee s payment service provider s account at the latest by the end of the next business day (D+1), i.e. the day after the payment order was received by the sender bank. For paper-initiated orders, the execution can take one extra day. In a few cases up to four business days may be agreed on (D+4). The beneficiary bank must credit the amount to the account of the beneficiary on the same day it has received the funds. Deduction of Charges The sender bank and any intermediary are obliged to transfer the full amount of the payment transaction and may not deduct any charges (full-amount-principle). The payee and the beneficiary bank may agree that it deducts its charges from the amount before crediting it to the payee. This full-amount-principle applies irrespective of the charge code of the payment transaction. 14

15 Value Dating The value-dating provisions apply to payment transactions in an EU / EEA currency even if only either the payer s or the payee s bank is located in the EU / EEA. Incoming payment transactions (beneficiary bank located in the EU / EEA): The value date for incoming payment transactions has to be the business day on which the amount of the payment transaction has been credited to the account of the beneficiary bank (as long as no FX-conversion is involved). Outgoing payment transactions (sender bank located in the EU / EEA): The debit value date for the payer s payment account may be no earlier than the point in time at which the amount of the payment transaction is debited to that account. Refund Claims The customer may request a refund for unauthorised or incorrectly executed payment transactions and, to a certain extent, for authorised payment transactions initiated by or through a payee (i.e. direct debits). Unauthorised direct debits (i.e. no mandate was obtained by the creditor) To be entitled to a refund the customer has to inform the bank without undue delay but no later than 13 months after the debit date. Authorised direct debits (a mandate was obtained): The debtor can request a refund within a period of 8 weeks if the authorisation did not specify the exact amount when the authorisation was made and if the amount of the payment transaction exceeded the amount the payer could reasonably have expected. Please note that in the interest of consumer protection, by allowing for a no-questions-asked refund policy, the Core SDD actually exceeds the legal refund requirements. 15

16 1.5.3 Regulation on cross-border payments (Reg. 924 / 2009) Regulation (EC) No 924 / 2009 on cross-border payments in the Community eliminates the differences in charges for crossborder and national payments in Euro. It applies to payments in Euro in all European Economic Area (EEA) Member States. The basic principle is that the charges for corresponding payment transactions offered by a payment-service provider have to be the same whether the payment is national or cross-border. The regulation applies to all electronically processed payments, including credit transfers and direct debits. Some conditions may apply depending on the type of payment transaction. For example, for credit transfers and direct debits, the use of IBAN and BIC is obligatory. Regulation (EC) No 924 / 2009 has replaced the previous Regulation (EC) No 2560 / 2001 as of 1 November The full name of this law is Regulation (EC) No 924 / 2009 of the European Parliament and of the Council of 16 September 2009 on cross-border payments in the Community and repealing Regulation (EC) No 2560 / The text is available in 23 EU languages via this hyperlink: Reg. 924 (see Annex page 72, section 3.3 / 4) SEPA-Migration End-Date Regulation (Reg. 260 / 2012) SEPA has become a regulatory project. European law makers agreed on a mandatory SEPA migration end date of 1 February This end date has been set as part of the new Regulation (EU) No. 260 / The regulation will also be implemented in Iceland, Liechtenstein and Norway, and as such be applicable in all 31 member states of the EEA. It has already been in effect in all EU countries since 31 March Therefore, preparations for migration should commence immediately. 1 February 2014 is the final date by which corporates must use the SEPA Credit Transfer (SCT) and the SEPA Direct Debit (SDD) instead of existing non-urgent mass credit transfers and direct debits in Euro. The full name of the law is Regulation (EU) No 260 / 2012 of the European Parliament and of the Council of 14 March 2012 establishing technical and business requirements for credit transfers and direct debits in Euro and amending Regulation (EC) No 924 / The text is available in 23 EU languages via this hyperlink: Reg. 260 (see Annex page 72, section 3.3 / 5). Besides establishing an end date for SEPA migration, the regulation covers many other topics of importance for the European payments landscape. What follows is an overview of the regulation s requirements and their impact on corporates. In Scope In scope are credit transfers and direct debits in euro where both the payer s and the payee s Payment-Service Provider (PSP, e.g. banks) are located in the European Economic Area (EEA). Out of Scope Out of scope are all other transactions, including e.g. payments via high-value payment systems or card transactions. 16

17 End Date A mutual migration end date for both credit transfers and direct debits of 1 February 2014 has been set. This is the date by which corporates must send SEPA Credit Transfers (SCTs) and SEPA Direct Debits (SDDs) to their bank. Reachability Eurozone banks must be reachable for SCT and Core SDD. PSPs in non-euro EEA states must be reachable for SCT and Core SDD only by 31 October 2016, or within one year of joining the Euro (if the joining takes place prior to 31 October 2015). This implies that the B2B SDD remains a voluntary scheme. Corporates interested in using this instrument should therefore either ask their customers about the acceptance by their banks, or check the list of all reachable banks (EBA s Participants list for B2B SDD) and compare this against their customers bank information. For more on SDD and advice on whether the Core SDD or the B2B SDD may be more appropriate, please refer to section 1.7. XML The XML format is to be used between corporates and banks in eurozone countries from 1 February 2014 (according to article 16.5, member states had the option of extending this period until 1 February Please also refer to section 3.7 for a summary of the countries decisions regarding the use of the various member-state options). This means that corporates who want to continue using non-xml formats need to obtain conversion / enrichment solutions (for which corporates may be charged) from their ERP providers or third-party vendors. For more on this topic, please refer to section BIC After 1 February 2014 (or 1 February 2016 per member-state option determined by each country by 1 February 2013) for national payments and after 1 February 2016 for cross-border payments, it is sufficient for corporates to only supply the beneficiary s (in case of SCT) or debtor s (in case of SDD) IBAN, i.e. the BIC will not be required anymore from the orderers but will be added by their banks. Mandates Direct debit mandates in place for currently-used domestic legacy direct debits can also be used for the Core SDD. This means that corporates wishing to use the Core SDD do not have to obtain new mandates from their customers unless of course no mandates currently exist (e.g. for new customers), in which case they must be obtained. 17

18 Account Location Payers cannot demand payees to have an account in a certain country, as long as the account is located within the EEA. Likewise, payees cannot demand payers to have an account in a certain country as long as the account is located within the EEA. Payment >EUR 50,000 Regulation 924 / 2009 has been amended such that higher charges for intra-eea cross-border payments exceeding EUR 50,000 are no longer permitted. As a result, these payments must cost the same as corresponding domestic payments. However, an urgent cross-border payment can cost more than a non-urgent domestic payment, because they are not considered to be corresponding payment types. Central Bank Reporting Regulation 924 / 2009 is amended in such a way that settlementbased central-bank-reporting obligations by banks shall be abandoned from 1 February However, this does not impact central-bank-reporting requirements that are not settlement based, such as direct reporting requirements by corporates, for example in Germany, or survey-based processes, for example in the Netherlands. Niche Products As per article 16.3, member states can allow a waiver for so-called niche products (less than 10 % market share per ECB statistics) until 1 February Member states wanting to make use of such waiver had to inform the Commission by 1 February 2013 accordingly, and advise for which products it will apply to the waiver. As per article 16.4, the waiver option also applies to transactions that are initiated by a card at the point of sale, but where the underlying payment transaction results in a direct debit. The German legislator uses this option for the so-called Elektronisches Lastschriftverfahren (ELV). Please refer to section 3.7 for a summary of the countries decisions regarding the use of the various member-state options/waivers. For an in-depth analysis of this regulation, please refer to the EBA Guide Banks preparing for SEPA Migration, which can be found on the EBA website (see Annex page 72, section 3.3 / 6). MIF Multilateral Interchange Fees (MIFs) are currently paid in a few countries (for example Italy or France) for direct debits by the creditor bank (and thus the creditor) to the debtor bank. These fees are not allowed for domestic direct debits from 1 February 2017 and for cross-border direct debits since 1 November However, MIFs may be allowed for returned direct debits under certain conditions (e.g. strictly cost based). Details still need to be determined via a collective agreement. 18

19 1.6 The SEPA Credit Transfer Characteristics SEPA XML Format As mentioned before, per Regulation 260 / 2012, the XML format will be binding for the exchange of bulk transactions between corporates and banks in eurozone countries from 1 February 2014 (unless the member state uses the option to postpone this until 1 February 2016). Thus, corporates are advised to migrate to the XML format. Deutsche Bank s detailed recommendation on this topic is as follows: Deutsche Bank s recommendation to companies is to migrate to XML by 1 February 2014 as required by EU Regulation 260/2012 Article 5.1. (d) requires for EUR credit transfer and EUR direct debit transactions that PSPs (Payment Service Providers, e.g. banks) shall carry out credit transfer and direct debit transactions in accordance with the following requirements They must ensure that where a PSU (Payment Service User, e.g. corporates) that is not a consumer or a microenterprise, initiates or receives individual credit transfers or individual direct debits that are not transmitted individually, are bundled together for transmission and the message formats specified in point (1)(b) of the Annex are used. Annex (1) (b) requires for credit transfer and direct debit transactions: The standard for the message format referred to in Article 5(1) (b) and (d) must be the ISO XML standard. Please note that this requirement applies to EUR-transactions in non-eur EEA countries only from 31 October 2016 (Art. 16.8) A few countries (e.g. Italy and Spain) used the memberstate option per Article 16.5 to waive the XML requirement for corporates until 1 February 2016, meaning that, in those countries, banks can continue to accept SEPA-transactions in other formats until that date. The full text of the regulation can be found on the following website (see Annex page 72, section 3.3 / 5). It is available in all EU languages. 19

20 For companies, there are two ways to create XML files The enhancement of proprietary systems (e.g. ERP, Treasury system, or EB system) This could also include buying and operating a format converter in-house The employment of a 3rd-party vendor to create them These vendors generally offer corporates to send credit transfer and direct debit files in legacy domestic file format and with legacy domestic account number (instead of IBAN) to the vendor, who then converts the file to a SCT or SDD file in XML format. This conversion may make use of a database hosted by the vendor, where the company uploads all of their suppliers or clients IBANs. This enables the vendor to add this data to the XML file they create. Deutsche Bank has created a vendor guide in cooperation with the consulting firm PPI ( A Practical Guide to Successful SEPA Migration. Providing a list of software and service providers ). This guide makes suggestions regarding the vendor-selection process, and it summarises the offerings of the major vendors for SEPA services. Please reach out to your Deutsche Bank contact if you are interested in this guide. For hosted file-format conversion services, there are various vendors on the market. Simplex (see Annex page 72, section 3.3 / 7) and Sentenial (see Annex page 72, section 3.3 / 8) are two vendors who may be able to meet your requirements. Please contact them directly to find out more about them and their offering (please refer to section 3.8 and section 3.9 for their brochures). Please understand that this is not an endorsement of or recommendation to use these vendors by Deutsche Bank, and that you should make your own decision to use or not use the vendors services based on your own due diligence and assessment of the vendors and their capabilities. Deutsche Bank is not liable for any services offered by Simplex and Sentenial. Deutsche Bank also offers a format checker The format checker is provided by the company Business Logic via a click agreement. Business Logic has a web-site where companies can either conduct online format checks or download a java applet that can be used for format checks in customers own operating environment. The vendor s can be found in section Formats that can be checked are DK XML v to be supported soon and Global XML (2009 und 2006) in line with CGI. In case of interest, customers may contact their Deutsche Bank Implementation & Service representative. IBAN and BIC The only permissible account identifiers for SEPA transactions are the International Bank Account Number (IBAN) and Business Identifier Code (BIC). Until now, most countries have used these identifiers for cross-border payments only but, under SEPA regulations, these identifiers also apply domestic payments. New / Changed Data Elements A new mandatory field for SEPA transactions is the end-toend reference, which passes through the entire SEPA payment/direct debit cycle. It is provided in all rejected and returned transaction information (enabling automatic reconciliation), as well as in the account information for the originator and the counterparty. In addition, a list of Category Purpose Codes (e.g. SALA for salary payments) has been established, which means corporates (via their banks) can initiate special processing, such as individual rather than bulk booking. Such services are optional, and they must be agreed with each bank individually. A further field for Purpose Codes has been introduced, allowing the issuer to inform the recipient about the reason for the transaction (e.g. PHON for a telephone bill). The compulsory change to remittance information is also crucial. Under SEPA, the standard length of this information is 140 characters, and banks are obliged to provide the information in full on account statements. Should more detailed remittance data be required, there are two options available: either fewer invoices should be paid in a single transaction, or additional information should be included outside of the standardised payments message, e.g. in separate advices. 20

21 Execution Time The maximum execution time for SEPA Credit Transfers is one TARGET business day. This is in line with the PSD, which obliges originator banks to credit the account of a beneficiary bank within one TARGET business day (following the point in time of acceptance of the payment order). In turn, the beneficiary bank is obliged to credit the account of the beneficiary on the same day it was credited by the originator bank. Credit without Deduction SEPA Credit Transfers are credited in full without deduction of fees from the principal amount. Central-Bank-Reporting Duties for Cross-Border Payments Efforts to abolish central-bank-reporting duties for crossborder payments have yet to be successful in all SEPA countries. This means that the February 2016 abolition of settlement-based central bank reporting obligations (in accordance with Reg. 260 / 2012) does not apply to non-settlement based reporting. Non-settlement based reporting duties must, therefore, still be observed in accordance with the prevailing rules in each country. 21

22 1.7 The SEPA Direct Debit Introduction The SEPA Direct Debit is a collections process based on a mandate signed by the debtor and presented to the creditor. Mandate content is standardised and must be issued in the language of the debtor (generally the language of the underlying contract). As is the case with the SEPA Credit Transfer, national account identifiers will be replaced by IBAN and BIC codes. In addition, there is an end-to-end reference for SDDs, which is a significant advantage for creditors submitting large numbers of direct debits, as it greatly simplifies the automatic reconciliation of returns. In addition, there are new data elements, including: A unique mandate number to be assigned by the creditor A centrally-assigned Creditor Identifier (in most countries this will be done either the Central Bank or the creditor s bank) The sequence of the direct debit, e.g. One-off, First, Recurring Further details on these new data elements are outlined in Section Core vs. B2B SDD In a collection process between corporates, the creditor and debtor are free to agree to use either the core SDD scheme or the B2B SDD scheme. For consumer protection reasons, however, it is not possible to use the B2B scheme when collecting payments from consumers. For very small companies (so-called microenterprises), some EU Member States have excluded the use of the businessto-business scheme this differs across countries in Europe. A microenterprise is defined as an enterprise which has less than 10 employees and whose annual turnover or balance sheet is equal to or less than 2 million Euro (2003 / 361 / EC). Microenterprises are treated as companies Austria, Belgium, Bulgaria, Denmark, Estonia, Finland, France, Germany, Greece, Ireland, Italy, Latvia, Lithuania, Luxembourg, Netherlands, Poland, Romania, Slovenia, Spain and Sweden, i.e. B2B SDD can also be used with these small companies. Microenterprises are treated as consumers Cyprus, Czech Republic, Great Britain, Hungary, Malta, Portugal and Slovakia, i.e. B2B SDD cannot be used to collect from small companies in these countries. The fundamental difference between the two schemes lies in the finality of the payments. Core direct debits can be returned by the debtor for up to 8 weeks after the debit, while direct debits under the B2B scheme are non-refundable by the debtor. In order to protect corporates against unauthorised debits under the B2B scheme, the debtor bank is obliged to control the debit authorisation. This is not the case for the core direct debit, in which case a mandate check by the debtor bank is optional (as the debtor has the option of claiming a refund). A further key difference is that participation in the core scheme is compulsory for banks in the eurozone, while the B2B SDD scheme remains optional (in accordance with Regulation 260 / 2012 see section 1.5.4). That said, our experience shows that the majority of banks also participate in the B2B SDD scheme. 22

23 Core SDD B2B SDD Usage With consumers and companies With companies only Refund Right Refund right 8 weeks after debit; 13 months after debit (in case of missing No refund right after debit mandate) Mandate Check by Debtor Bank Optional Mandatory Mandatory Participation of Banks EUR countries: since November 2010 Non-EUR countries: from 31st October 2016 Optional Our expectation is that the vast majority of all collections between businesses will be done via the core SDD scheme. The B2B SDD will likely be used only in the case of higher-value direct debits, where the importance of finality of payment outweighs concerns over the complexity of set-up requirements. Such requirements are as follows: Ensure the debtor bank participates in this optional scheme (for example by using the EBA s SDD B2B Participants list, see Annex page 72, section 3.3 / 9). If not, the core scheme could be used with this debtor. Convince the debtor to revoke their refund right Obtain a new mandate from the debtor (this is not required for the core SDD, in which existing mandates can be used). Ensure the debtor informs its bank of the mandate so that it can be logged into the processing system of the debtor bank. This may be achieved by the creditor issuing the debtor with two copies of the mandate, one of which can be signed by the debtor and given to the debtor bank. The debtor bank will only accept the first collection once the mandate has been registered. Thus, the mandate flow can differ as follows: Core SDD B2B SDD 2. Sends signed mandate back to Creditor 1. Sends mandate to Debtor 3. Captures mandate data 4. Stores mandate 2.1 Sends signed mandate back to Creditor 2.2 Sends signed mandate to debtor bank 1. Sends 2 mandate copies to Debtor 3.1 Captures mandate data (e.g. in ERP system) 4. Stores mandate Debtor Creditor Debtor Creditor Debtor Bank Creditor Bank 3.2 Captures mandate data in processing system Debtor Bank Creditor Bank 23

24 1.7.3 Submission Deadlines and Processing Flow Changes in company process flows will arise from the change in submission deadlines for direct debits. Deadlines for the core scheme are outlined below: Direct debits have a due date (D) to be assigned by the creditor. This is the date on which funds leave the debtor s account The debtor is informed by the creditor of the debit date and amount due no less than14 calendar days prior to D (shorter notification deadlines can be agreed upon, e.g. in the General Terms and Conditions of the creditor) Initial direct debits under a mandate or one-off direct debits must be sent by the creditor bank to the clearing house (e.g. EBA Step2) five TARGET business days prior to the due date (D 5). Please also refer to the section for details on submission deadlines and cut-off times Subsequent direct debits under a mandate must be sent to clearing two TARGET business days prior to the due date (D 2) Cut-off time for file submission by the creditor to Deutsche Bank is 08:30 CET on D 5 or D 2, respectively. In the event the cut-off time is missed, Deutsche Bank will shift the due date accordingly (to D+1). We therefore recommend that files be submitted to Deutsche Bank on D 6 or D 3 to ensure due dates are met Any returns by the debtor bank (e.g. if the account has been closed) must be effected no later than five TARGET business days after the due date The debtor can request a refund of the direct debit for up to eight weeks after the due date in cases where they had authorised the creditor via a mandate Unauthorised direct debits (for which the creditor cannot produce a mandate) can be returned for up to 13 months after the due date The mandate expires 36 months after the last initiated direct debit. This needs to be checked by the creditor, as noncompliance with this requirement would lead to the submission of a non-authorised direct debit Different deadlines apply to the B2B scheme Direct debits are sent to clearing one TARGET business day prior to the due date Cut-off time for file submission by the creditor to Deutsche Bank is 09:30 CET on D 1. In the event the cut-off time is missed, Deutsche Bank will shift the due date accordingly (to D+1). We therefore recommend that files be submitted to Deutsche Bank on D 2 to ensure due dates are met Banks have two business days (after D) in which to return the direct debit Returns by the debtor are not permitted under the B2B scheme Comparison Core SDD with B2B SDD Core SDD D: Due date = debtor s debit date = inter-bank settlement date D 14 CD: Customer pre-notification of amount and due date (unless other timeframe is agreed) D 5 BD : Submission of first and one-off SDD D 2 BD: Submission of subsequent SDD D+5 BD *: Latest date for bank returns D+8 W: Maximum refund period for debtor for authorised transactions D+13 M: Maximum refund period for debtor for unauthorised transactions D+36 M: Mandate expires 36 months after last SDD submission CD = Calendar Days, BD = Business Days, W = Weeks, M = Months, * D+2 in Germany B2B SDD D: Due date = debtor s debit date = inter-bank settlement date D 14 CD: Customer pre-notification of amount and due date (unless other timeframe is agreed) D 1 BD: Submission of first, one-off and subsequent SDD D+2 BD: Latest date for bank returns No refund right for debtor D+36 M: Mandate expires 36 months after last SDD submission CD = Calendar Days, BD = Business Days, W = Weeks, M = Months 24

25 1.7.4 D 1 Core SDD Some existing domestic direct debit schemes (such as German and Austrian schemes, for example) have shorter submission deadlines than the core SDD. Various industry associations have, therefore, pointed out that these longer submission deadlines do not support their current business models because of the resulting negative impact on liquidity and risk management. As a result, in November 2012 there was a change to the core SDD rulebook. This change allows the option of a reduced submission deadline of just one TARGET business day (D 1), on the condition that a community (e.g. all banks in a country) agrees on this. In addition to the banking communities in these countries, a few individual banks support this option via EBA Clearing. This means that if the debtor s account is in one of these three countries, and the debtor s bank adhered to this transaction type at EBA, the creditor has the option to use COR1 and only needs to submit the collection file one business day prior to due date. This has sparked the debate in several countries as to whether or not to opt for the reduced submission deadline. If the answer is yes, this would allow a creditor to submit core SDDs drawn on a debtor in such a country on D 1 only, as long as the direct debit is marked COR1. As such, Austria (since April 2013), Spain (from October 2013) and Germany (from November 2013) are set to use this option. This means that a creditor may submit Core SDDs drawn on a debtor bank in Austria on D-1 only, as long as the direct debit is marked accordingly (COR1). Of course this is an optional service, so a creditor can choose between Core SDD and COR1 SDD. Please note customers may initiate COR1 SDD from any Deutsche Bank SEPA branch, but the debtor s account must be in one of the three countries mentioned above and the debtor s bank must adhere to the COR1 SDD at EBA (to be found at EBA participants list for Core SDD s). It is currently under discussion whether the COR1 SDD scheme can be applied to the above mentioned countries. 25

26 26

27 2 Implementation As stated in section 1.5 on Regulation, SEPA migration is no longer a voluntary project that requires a business case. Instead, it is now a regulatory requirement, and must therefore be taken into consideration during the budget allocation process. Given the short timeframe for migration (1 February 2014), it is vital that the migration budget be approved as soon as possible so that the process can be completed throughout the course of Accurately calculating the budget for the migration process depends on a sound understanding of the changes required. Section 2 is, therefore, designed to aid this analysis and assist the establishment of SEPA project teams, which are vital if the migration process is to be completed in time and with minimal disruption. 2.1 Project Team The SEPA project team may comprise different company divisions depending on the company structure and the scope of the SEPA project. It is important to include not only departments directly involved with payments or accounting, but also other and perhaps less obvious areas that may also be impacted, such as HR, Legal, IT and Customer Services. The following table shows company divisions that may be affected by the project. Cross-divisional SEPA Project Team Lead by SEPA Project Manager Finance Areas Accounting (SEPA payments, booking, collection and maintenance of IBAN / BIC) Treasury (banking relationships / liquidity management) Invoicing (provision of IBAN, BIC and terms of payment) Other Divisions Human Resources (migration of payroll processing) Sales / Purchasing (notification of business partners, if applicable use of new agreements or forms) Customer Service (SEPA-related customer inquiries) Legal (in particular for direct debits due to mandate changes) External Partners (e.g. ERP providers; Call Centers) IT (required changes to systems) 27

28 The first issue the SEPA project team needs to address is the size of the project s scope. This may be achieved with the following steps, which provide a general overview of how SEPA will affect company, and estimations for project scope and cost: Identify the group companies concerned and the accounting / ERP systems used Determine in which SEPA countries accounts are maintained Analyze and assess the payment methods used for the accounts concerned, as well as the payment volumes. Once a plan like this is in place, the next step is to assess the strategic and tactical requirements related to the migration to SCT and SDD in detail. For this, the next section provides some useful information. SEPA Migration Key Steps Phases Phase 1 Analysis and Planning Phase 2 Adjustment and Upgrade of IT Infrastructure Phase 3 Account Information and Reconciliation Phase 4 SCT Migration Phase 5 Mandate Management Phase 6 SDD Migration Examples of some key steps Account-number and sort-code conversion to IBAN/BIC Future format and changes to existing ones (XML pain, camt, MT940) Internal versus external mandate-management solution Upgrade of infrastructure Adjustment of databases (new and enhanced fields) Upload/Input of IBAN and BIC Adjustment of reconciliation process to new SEPA reference logic Matching of SEPA return reasons to existing logic Adjustment of payment processes ( e.g. cut off times, booking options) Creation and test of SEPA XML SCT (e.g. pain ) and test of third-party conversion services (if applicable) Definition of a pre-notification process Development and integration of mandate-management solution Addition of SEPA-relevant information (e.g. mandate reference, Creditor ID) Adjustment of payment processes (e.g. COT, submission deadlines) Creation and test of SEPA XML SDD (e.g. pain ) and test of third-party conversion services (if applicable) 28

29 29

30 2.2 General Requirements Strategic Aspects Centralisation and Consolidation Strategy SEPA facilitates centralisation and provides opportunities for account consolidation. It is, therefore, a further driver of the trend towards payment / collection factories. However, companies planning or executing a centralisation project must ensure that it does not delay the transition to SEPA. Given the compulsory nature of SEPA and the short time-frame for migration SEPA must be the top priority. For more on centralisation, please refer to section 1.3. Migration Strategy 1 February 2014 is the deadline for the implementation of the SCT and SDD. Earlier migration is possible, but depends on the status of companies individual migration projects which will vary in scope and complexity as well as the SEPA capabilities of counterparties and partner banks. System Strategy SEPA s effect is not limited to AP / AR systems, but can extend to all systems that carry or collect account information. Identifying these systems and ensuring their preparation for SEPA is vital. If adjustments are needed, such adjustments should ideally support both SEPA and legacy domestic instruments and account data, to enable uninterrupted use and a seamless transition to the new requirements. Bank Strategy The ability of SEPA to facilitate centralisation provides an opportunity to consolidate bank relationships. Alongside credit and relationship aspects, it is also vital to consolidate: The banks SEPA strategies The banks core offerings The value-added services available The banks levels of experience The advisory services available Format Strategy Please refer to section for our recommendation regarding format requirements. With the use of the XML format, dedicated Reference Fields are available to facilitate transaction identification and reconciliation. Please refer to section 3.12 for a brief overview of these fields. Allowed characters for XML messages are numbers, letters, and special signs, e.g. ( ) +, -. / : 30

31 2.2.2 Tactical Aspects SCT and SDD Booking Options: Bulk vs. Item-by-Item SEPA transactions are generally considered to be mass payment transactions. For this reason, files with SEPA transactions are (by default) booked in bulk and individual transactions are subject to single booking. However, we also support itemby-item booking for files containing numerous transactions. The type of booking used depends on the nature of the transaction(s). Bulk booking is more suitable for outgoing transactions (such as SCT debits and SDD credits) because the user knows the detail of the file sent to the bank. For incoming transactions (such as SCT credits and SDD-return debits and SDD payments), bulk booking is only used for transactions where the beneficiary or creditor is informed about the breakdown of the total bulk amount via other means. For example, for customers with accounts in Germany, we support the generation of the German DTI file format (based on the legacy file format DTAUS). For German remitter accounts we decompose the sender s IBAN and populate the sender account-number and sort-code fields accordingly. And for clients requiring other breakdown file formats, we also offer the CSV file format, the French CFONB240 file format (for French accounts only) and camt.053 and camt.054 formats. For more on camt statements, please refer to section Upfront Validation By default, SEPA transactions are booked as gross. This means a customer will always be debited (SCT) or credited (SDD) the full value of a batch of transactions. If there are any validation failures or rejects, these transactions will be processed as returns and booked individually. The validations are completed by us on the day of processing/execution, so the customer will only learn about them on that day even if the file was submitted prior to processing day. As an alternative, we offer an upfront validation, which is a value-added service that supports validation immediately upon receipt of the payment file. Any validation failures will be reported to the client via a corresponding message (which will also be sent in case there are no rejects) and only the remaining transactions will then be processed/booked by us on processing day. If an upfront validation is chosen, this type of booking will be applied. IBAN and BIC One of the migration project s biggest tasks will likely be the replacement of legacy payment data with IBAN (International Bank Account Number) and BIC (Business Identifier Code). This requires that the company s systems need to be able to support and process this new information (see also System Strategy in section 2.2.1). There are various ways to obtain IBAN and BIC: Ask customers to supply the information and ensure staff manually enter the information. This option is the most timeconsuming and comes with the risk of typing errors, so all information should be checked throughout the process, using the respective IBAN algorithm. Manual capture is not the most practical for larger volumes. Therefore, there are two electronic alternatives: Domestic solutions, which vary from country to country (for more information see also section 2.3, and the Annex section 3.5 for an overview of the Availability of local IBAN Conversion Services in Europe ) Vendor solutions such as those provided by the company Accuity IBAN Payment Resource (IPR Batch) This is an online tool that validates and converts IBANs to provide all of the required information for SEPA-compliant transactions, including correct routing BICs. Payscreen Prior to conversion, this service repairs payment records to eliminate incorrect instructions, and it highlights those records that require review. Contact [email protected] for more information and refer to section 3.6 for an overview of this offering. In addition, IBAN and BIC should also be provided on your own invoices to enable clients to pay you via SCT. 31

32 Payment Detail The length of detail required in today s payment schemes varies from country to country. For SCT and SDD, it is standardised at 140 characters, and will be communicated in its entirety to the beneficiary or debtor bank bank. The remittance information may have to be adjusted depending on how much payment detail is required. Creditor Reference The Creditor Reference field found in the structured remittance detail in XML is an optional one and can assist with the reconciling of incoming SCTs, if a company requests that a client supply this reference. End-to-End Reference A new mandatory field for SEPA transactions is the end-to-end reference, which passes through the entire SEPA payment / direct debit cycle. It is provided in all rejected and returned transaction information (enabling automatic reconciliation), as well as in the account information for the originator and the counterparty. It is displayed in MT940 / 942 account statements (field 86, subfield 20-29, preceded by EREF+ ) and the maximum length is 35 characters. Purpose Codes The purpose code field, which is optional, provides information on the reason for the transaction. The originator bank (SCT) or creditor bank (SDD) must pass the information on to the beneficiary bank or debtor bank, who must then deliver the codes to their clients, for example in the account statement. A current list of purpose codes can be found on the External Code Lists spreadsheet under the tab Purpose, from the ISO20022 website (see Annex page 72, section 3.3 / 10). Category Purpose Codes The idea behind category purpose codes is to obtain special processing from the sender bank/bene bank (in the case of SCT) or the creditor bank/debtor bank (in the case of SDD). As this is an optional service, capabilities will vary between banks. Instead of using category purpose codes, Deutsche Bank recommends specifying the requested processing options by putting that information directly in the file. For example, clients can choose the clearing service rule NORM (for overnight clearing) or HIGH (for same-day clearing), or the booking rule TRUE (for bulk booking) or FALSE (for individual booking). A current list of category purpose codes can be found on the External Code Lists spreadsheet under the tab Category Purpose, from the ISO20022 website (see Annex page 72, section 3.3 / 10). On-behalf-of Field This optional field has a maximum of 70 characters, and caters to the centralisation trends of both originators and beneficiaries. The originator of a transaction can use the field originator reference party / ultimate debtor, in the case of SCT, or creditor reference party / ultimate creditor, in the case of SDD. The originator can also use the field beneficiary reference party / ultimate creditor, in the case of a SCT, or debtor reference party / ultimate debtor, in the case of a SDD. These fields are purely informational and were specifically developed for the needs of payment / collection factories, so that this information does not need to be presented in the payment detail, which already has limited space. Banks must report this information in account statements. However, as some banks only do so in XML account statements, we recommend that this information is still included in the payment detail. 32

33 2.2.3 Tactical Aspects SCT only Execution Time The maximum clearing cycle from payment initiation (D) to credit of the beneficiary s bank account is one TARGET business day (D+1). This is in line with the Payment Service Directive (PSD) (see section 1.5.2). The PSD also requires that the value date for incoming payment transactions must be the business day on which the payment transaction has been credited to the account of the beneficiary bank. Therefore, the beneficiary also receives the payment value within one business day. This is also true for local bank holidays that are not TARGET holidays. In case the beneficiary s bank was closed, they may credit the beneficiary only on D+2, but with the value from D+1. In such cases, whether the account credit occurs on D+2 or D+1 will likely vary from bank to bank, depending on whether they operate on local holidays or not. Our expectation is that most banks, likely Deutsche Bank, will operate on local holidays and thus also book on D+1. Cut-Off Times (COTs) The COT at Deutsche Bank for STP transactions is 15:30 CET (best effort until 17:00). Balance-of-Payment Reporting Obligations (Central Bank Reporting) Whether a payment is processed as SEPA or not has no impact on a company s Central Bank Reporting obligations, as these will still exist irrespective of the payment method used. However, the company s obligations will vary from country to country Tactical Aspects SDD only Reachability As mentioned before, per Regulations 260 / 2012 and 924 / 2009, banks in the eurozone must be reachable for the Core SDD. From 31 October 2016 this will include EU banks in non-euro countries, too. Meanwhile, the B2B SDD scheme remains optional, so it is up to the debtor bank to decide if they will participate and be reachable. Corporates can compare the list of debtors banks with that of banks participating in the B2B SDD scheme by looking at the SDD B2B Participants list (see Annex page 72, section 3.3 / 9), which can be downloaded from the EBA s website. 33

34 Mandate Management The creditor of an SDD is responsible for obtaining the debtor s authorisation to debit their account. This authorisation comes in the form of a mandate. The debtor signs it and sends it back to the creditor, who keeps it. The reason for storing the mandate is that in case of a debtor requesting a refund after the regular 8-week refund period, the creditor would have to accept the late refund if they cannot provide a mandate copy. Storing the mandate is a new process for creditors in countries who are familiar with a domestic direct debit scheme that follows the Debtor Mandate Flow (DMF) where the mandates are kept by the debtor bank rather than the creditor. The content of the mandate is standardised. It can be a standalone document or be part of a contract. The mandate reference (also known as mandate ID) must be assigned to each mandate by the creditor before the first direct debit is collected. This can happen either when the mandate is issued, or (especially in the case of existing legacy mandates that are also used for Core SDD) separately afterwards. Here is a checklist of the mandatory content of a SDD mandate, followed by an example of what standalone Core and B2B SDD mandates could look like: Title: SEPA Core Direct Debit Mandate or SEPA B2B Direct Debit Mandate Creditor ID Mandate Reference Recommended to be part of the mandate, but could also be communicated to the debtor separately prior to the first SDD Possible characters are a-z A-Z 0-9 / -? : ( )., + Space Frequency (one-off or recurrent) Name and address of the creditor Name and address of the debtor IBAN and BIC of the debtor Date and signature of the debtor 34

35 Formular SEPA Core Direct Debit Mandate Deutsche Bank Global Transaction Banking SEPA Core Direct Debit Mandate Mandate Reference * By signing this mandate form, you authorise (A) {NAME OF CREDITOR} to send instructions to your bank to debit your account and (B) your bank to debit your account in accordance with the instructions from {NAME OF CREDITOR}. As part of your rights, you are entitled to a refund from your bank under the terms and conditions of your agreement with your bank. A refund must be claimed within 8 weeks starting from the date on which your account was debited. Your Name Your Address Name of Debtor Street and Number ZIP and City Your Account Number Country IBAN Bank (Name) Name of Creditor Creditor ID * and (SWIFT BIC) C O M P A N Y Name of Creditor G B 9 3 Z Z Z S D D C X X X Creditor ID C O M P A N Y S T R E E T Street and Number C O M P A N Y C I T Y ZIP and City C O M P A N Y Country C O U N T R Y A B C / Contract Data Type of Payment X Recurrent payment or One-off payment City, Date Signature Creditor s use only Please return to: C O M P A N Y Name of Creditor C O M P A N Y Street and Number ZIP and City S T R E E T C O M P A N Y C I T Y * Mandate References may not exceed 35 characters and must consist of the following characters only: A-Z, a-z, 0-9 / -?: ( )., +

36 Formular SEPA Business-to-Business Direct Debit Mandate Deutsche Bank Global Transaction Banking SEPA Business-to-Business Direct Debit Mandate Mandate Reference * By signing this mandate form, you authorise (A) {NAME OF CREDITOR} to send instructions to your bank to debit your account and (B) your bank to debit your account in accordance with the instructions from {NAME OF CREDITOR}. This mandate is only intended for business-to-business transactions. You are not entitled to a refund from your bank after your account has been debited, but you are entitled to request your bank not to debit your account up until the day on which the payment is due. Your Name Your Address Name of Debtor Street and Number ZIP and City Your Account Number Country IBAN Bank (Name) Name of Creditor Creditor ID * and (SWIFT BIC) C O M P A N Y Name of Creditor G B 9 3 Z Z Z S D D C X X X Creditor ID C O M P A N Y S T R E E T Street and Number C O M P A N Y C I T Y ZIP and City C O M P A N Y Country C O U N T R Y A B C / Contract Data Type of Payment X Recurrent payment or One-off payment City, Date Signature Creditor s use only Please return to: C O M P A N Y Name of Creditor C O M P A N Y Street and Number ZIP and City S T R E E T C O M P A N Y C I T Y * Mandate References may not exceed 35 characters and must consist of the following characters only: A-Z, a-z, 0-9 / -?: ( )., +

37 Examples can be found in the EPC s Guidelines for the Appearance of Mandates (see Annex page 72, section 3.3 / 11). Translations for various languages are also available from the EPC for the Core SDD (see Annex page 73, section 3.3 / 12) and the B2B SDD (see Annex page 73, section 3.3 / 13). Certain mandate data that does not exist (such as mandate ID or creditor reference) or is not relevant (e.g. mandate date) in many national direct debit schemes must be stored electronically by the creditor, as the data is part of each SDD. In addition, prior to the submission of a direct debit, the system should check the mandate s status (first or recurring) and its validity. This is because of the different submission deadlines and the automatic mandate expiration if no collection is made for 36 months. In other words, a mandate remains valid so long as regular collections occur, or until cancelled by the debtor. Because of the different submission deadlines of Core versus B2B SDD and between one-off/first/recurring Core SDDs, a detailed mandate-management system is required. We recommend to check with the ERP vendor regarding their mandate-management capabilities, or alternatively to contact a non-erp, 3rd-party vendor. As mentioned in section 1.6.1, Deutsche Bank has created a vendor guide in cooperation with the consulting firm PPI. This guide makes suggestions regarding the vendor-selection process, and summarises the offerings of the major vendors for SEPA services. Please reach out to your Deutsche Bank contact if you are interested in this guide. e-mandate According to the European Payments Council (EPC), a mandate may exist as a paper document which is physically signed by the Debtor. Alternatively, it may be an electronic document which is created and signed in a secure electronic manner. The e-mandate solution is based on secure, widely-used online banking services currently offered by debtor banks. The debtor can re-use his online banking credentials. No additional means of identification are necessary. The e-mandate solution is an optional service offered by banks to their customers. Such a service would be of particular interest to online merchants, as the electronic mandate would make it easier to fulfil the requirements of the SDD Rulebooks as well as the requirements of the SDD agreement that a creditor signs with their bank 3. However, it remains to be seen if such a service will actually be developed by the market, and whether it would be a pan-european offering or merely regional. In either case, it is not a service that can be developed by any individual bank, and the success of such an offering would depend greatly on the number of debtor banks participating. This is currently under review by the European Payment Council. However, any changes to the rulebook will not became applicable before Mandate Migration Under the Core SDD scheme, most existing mandate types in all countries can be used for collections. However, prior to the first Core SDD collection, the creditor needs to inform the debtor about the switch to SDD and what the creditor reference and the mandate reference are. For collections under the B2B SDD scheme, new mandates are generally required (please refer to section 2.3 for country-by-country details). 3 Besides paper mandates and the e-mandate described above, other mandate forms such as verbal ones (via phone, for example) or checking a box on a website do not fulfil the requirements of the SDD agreement. 37

38 Mandate Reference Each SDD mandate must contain a unique mandate reference (also known as a mandate ID ) assigned by the creditor. At a maximum length of 35 characters, the number chosen will depend on the capabilities of the mandate database used, and whether the mandates are issued for each contract individually or are instead consolidated per customer. Often, companies use existing customer numbers or contract numbers. Possible characters are A-Z a-z 0-9 / -? : ( )., + and spaces. For new mandates, the mandate ID should be either included in the mandate or, if that is not possible, communicated to the debtor prior to the first SDD collection. Such communication is also needed for legacy mandates, for which mandate IDs need to be assigned if the company intends to use them for Core SDD collections. Mandate Date The mandate date is required in each SDD. While new mandates allow for the actual date of signing to be used, this is not practical for existing legacy mandates. Here, a dummy date can be used for example, the date of when to switch to SDD. This will suffice because banks do not check the actual mandate date, but merely check if the field has been populated. Creditor Reference (Creditor ID) Also known as a Unique Creditor Reference, or Creditor ID, the Creditor Reference is for clear identification of the creditor. In particular, the combination of Creditor ID and mandate ID enables a debtor bank to conduct a mandate check prior to debiting the debtor. This check is required only upon request by the debtor under the Core SDD scheme, but is mandatory under the B2B SDD scheme. Each legal entity wishing to submit SDDs should obtain a Creditor ID. The method of obtaining a Creditor ID varies between countries. The Creditor ID is generally obtained in the country hosting the company s headquarters, and it can then be used in any country. For example, a French Creditor ID can be used for making collections via the company s Spanish account. A Creditor ID remains valid even if the creditor switches banks or moves to another country. Please refer to section 3.11 for a country-bycountry overview of how to obtain the Creditor ID. In addition, the EPC also provides an overview (see Annex page 73, section 3.3/14). 38 We strongly recommend the Creditor ID is obtained right away if it has not already been done so as there might be capacity constraints by year end. Pre-notification The creditor must pre-notify the debtor of the date and amount of the direct debit. This should happen 14 days in advance, although a shorter timeframe can be used if agreed upon by the creditor and debtor. Often, the pre-notification occurs as part of the invoice. In the case of recurring direct debits of the same amount and frequency, a single pre-notification per year (e.g. we will debit your account on the first business day of every month for the amount of 100 Euros ) is sufficient. The purpose of the pre-notification is to minimise returns caused by non-sufficient funds. For this reason, it is in the creditor s best interest to notify the debtor. However, the creditor bank does not check if a pre-notification occurs, and a failure to pre-notify does not mean the direct debit becomes unauthorised. Please refer to section 3.13 for additional details about the pre-notification. Submission Deadlines Core SDDs (first and one-off) can be submitted by the creditor to Deutsche Bank between 5 (D 5) and 90 (D 90) business days prior to the due date or, in the case of recurring Core SDDs, between 2 and 90 business days prior to the due date. COR1 SDDs and B2B SDDs can be submitted between 1 and 90 business days prior to the due date. However, because the cutoff time is very early (please see section immediately below) we recommend to submit them no later than D 6 for first and oneoff Core SDDs, D 3 for recurring Core SDDs, and D 2 for COR1 SDDs and B2B SDDs. Due to differing submission deadlines and requirements for mandate checks, SDDs must be marked as either Core, COR1 or B2B. COTs The cut-off time (COT) at Deutsche Bank is 8:30 CET for Core SDDs and COR1 SDDs and 9:30 CET for B2B SDDs. If the cut-off time is missed, we will automatically adjust the due date to the next possible date. Booking Dates Per default, we book on processing day (generally D 6 / D 5, D 3 / D 2 and D 2 / D 1 respectively) with value on due date. If needed, booking on D is also available, (section 2.2.2).

39 Here is a summary of the standard submission deadlines, COTs and booking dates: Core SDD: First and One-off SDDs File Submission Date Deutsche Bank Processing Date Booking Date Due Date D 90 D 6 D 6 D D D 6 D 6 D D D 6 D 6 D 6 D D D 5 * D 5 D 5 D D Value Date D 4 * D 4 D 4 D+1 D+1 D * D D D+5 D+5 * if received and processed prior to COT of 08:30 CET Core SDD: Recurring SDDs File Submission Date Deutsche Bank Processing Date Booking Date Due Date D 90 D 3 D 3 D D D 3 D 3 D D D 3 D 3 D 3 D D D 2 * D 2 D 2 D D Value Date D 1 * D 1 D 1 D+1 D+1 D * D D D+2 D+2 Note Submission dates and COTs have been adjusted by Deutsche Bank to meet scheme rules and clearing cut-offs. If a due date falls on a local bank holiday that is not a TARGET holiday, the debtor may be debited one day after due day. This will depend on whether or not the debtor bank operates on the local holiday. Our expectation is that most banks, like Deutsche Bank, will operate and thus debit on the due date. Sequence According to the rulebook requirements and due to the differing submission deadlines between first / one-off and recurring Core SDDs, each must be marked accordingly. In some cases, how to mark certain transactions may not be clear. For example, a common question is as follows: after a first SDD was rejected, is the next a recurring SDD, or should it be marked as first again? The recommendation is: If it was rejected prior to clearing (i.e. it was never received by the debtor bank thus never booked on the debtor s account) then it needs to be submitted again as a first. If it was returned subsequent to clearing, then it should be submitted as recurring. However, not all debtor banks act in the same way. We expect this will change as SDD volumes grow and the behaviour of debtor banks becomes increasingly harmonised. * if receivedand processed prior to COT of 08:30 CET B2B SDD File Submission Deutsche Bank Processing Booking Date Due Date Value Date Date Date D 90 D 2 D 2 D D D 2 D 2 D D D 2 D 2 D 2 D D D 1 * D 1 D 1 D D D * D D D+1 D+1 * if received and processed prior to COT of 09:30 CET 39

40 Overview of recommendations by EBA Clearing on whether a debtor bank should process or reject the collection depending on how it is marked Sequence Type Core B2B Next FRST transaction for same mandate (so FRST after a FRST, or FIRST after a RCUR or FIRST after a FNAL: in all cases being settled less than 36 month ago and irrespective if that transaction has been returned / refunded) Next FRST after the first FRST has been rejected (as recommended by Rulebook and M-PEDD Business Practices) Process Process Process Process Next OOFF after the first OOFF has been rejected Process Process Next LAST transaction after a FNAL for the same mandate has been rejected Process Process FRST or OOFF more than 36 month after the latest transaction for the same mandate has been settled Process Process FRST transaction with mandate amendment Process Process OOFF transaction with mandate amendment Process Process RCUR or FNAL transaction with mandate amendment where original details as included in the transactions do not match with previously captured MRI (by default within 36 month the latest transactions have been settled) Next OOFF transaction after a OOFF that has been settled for same mandate (less than 36 month ago) Next OOFF transaction after a FRST, a RCUR or a FNAL for same mandate has been settled (less than 36 month since settlement) Next FNAL transaction after a FNAL for the same mandate has been settled (within 36 month and irrespective if that transaction has been returned / refunded) FRST, RCUR or FNAL transaction after having received a OOFF (that has been settled less than 36 months ago) Process Reject Reject Reject Reject Process Reject Reject Reject Reject FRST, OOFF, RCUR transaction within 36 month after a FNAL transaction Reject Reject 40

41 The lack of clarity in the rulebooks, and an absence of guidelines specifically focusing on such questions, has led to a situation where the treatment will inevitably differ from country to country, and even from bank to bank. For example, some countries require that the first debit collection that is to be processed in SEPA must be first, regardless of the actual sequence of the collection. In other countries, the first SEPA transaction will reflect the real sequence of the collection, i.e. it may be first or recurrent, as it could be an existing mandate migrating to SEPA. As greater clarity arises, we will make this information available. Rejects and Returns Any validations by Deutsche Bank will be conducted on execution / processing day only. Therefore, customers will only learn about any rejects on that day even if the file was submitted prior to the processing day. As an alternative, we also support validation immediately upon file receipt. This is known as upfront validation, and any validation failures (rejects) will be reported to the client via a corresponding XML message (pain.002). Following this, we will only process the remaining transactions. This is considered net booking. Returns will be shown in the account statement, and the reason displayed via additional text keys. SDD returns are, by default, booked individually. We also support bulk booking, although this should only be used if the creditor is informed of the breakdown of the total bulk amount via other means. For customers with an account in Germany, we support the generation of the German DTI file format (based on the legacy file format DTAUS), and for German debtor accounts we will decompose the debtor s IBAN and populate the (legacy) account-number and sort-code fields accordingly. And for clients requiring other breakdown file formats, we also offer the CSV file format, the French CFONB240 file format (for French accounts only) as well as camt.053 and camt.054 formats. For more on camt (XML) account statements, please refer to section Multilateral Interchange Fee In certain countries, a multilateral interchange fee (MIF) per direct debit is being paid by the creditor bank to the debtor bank. This therefore increases the fee that the creditor pays to their bank. In other countries, a per-item MIF does not exist, but instead a MIF per returned direct debit may be applied. Please refer to this EBA Clearing webpage (see Annex page 73, section 3.3 / 37) for a summary of the current situation Tactical Aspects of the MT940 Account Statement Transaction-Type Codes For the BCS-structured MT940, Deutsche Bank uses the bank transaction codes for SEPA payments issued by Deutsche Kreditwirtschaft (DK, former ZKA Zentraler Kreditausschuss). Other banks, particularly those outside Germany, will use different codes or no SEPA-specific codes at all. In basic SWIFT / unstructured MT940, Deutsche Bank does not use SEPA-specific codes. Only the generic SWIFT transaction type codes (TRF for any kind of credit transfer, DDT for any kind of direct debit, and RTI for any kind of return) are applied. 41

42 SEPA GVO and SWIFT Transaction Type Codes GVO Code 61 / 6 86 /?00 Buchungstext (Deutsch) 86 /?00 Posting Text (English) Lange Beschreibung Deutsch Long Description English 104 NDDT SEPA-LASTSCHRIFT B2B SEPA-DIRECT DEBIT B2B SEPA-Lastschrift B2B (Belastung) SEPA-Direct Debit B2B (Debit) 105 NDDT SEPA-LASTSCHRIFT SEPA-DIRECT DEBIT SEPA-Lastschrift Core (Belastung) SEPA-Direct Debit Core (Debit) 108 NRTI SEPA LASTSCHR. RETOURE B2B SEPA-DIRECT DBT. RETURN B2B SEPA-Lastschriftsretoure B2B (Passiv / Belastung) SEPA-Direct Debit Return B2B (Passive / Debit) 109 NRTI SEPA LASTSCHR. RETOURE CORE SEPA-DIRECT DBT. RETURN CORE SEPA-Lastschriftsretoure Core (Passiv / Belastung) SEPA-Direct Debit Return Core (Passive / Debit) 116 NTRF SEPA-AUFTRAG SEPA-CREDIT TRANSFER SEPA-Überweisung (Belastung) SEPA-Credit Transfer (Debit) 116 NTRF SEPA-AUFTR. MAN. EINGABE SEPA-T / N MANUALLY INPUT SEPA-Überweisung (Belastung) paper / scanner SEPA-Credit Transfer (Debit) paper / scanner 116 NTRF SEPA-GUTSCHR.- DAUERAUFTR. SEPA-CREDIT- ORDER SEPA-Überweisung (Belastung) Dauerauftrag SEPA-Credit Transfer (Debit) standing order 116 NTRF SEPA-EILIGER GUTSCHR.AUFTR. SEPA-EXPRESS- CRED.-TRANSF. SEPA-Beschleunigte Überweisung (Belastung) SEPA-Accelerated Credit Transfer (Debit) 153 NTRF SEPA-ZAHLUNG GEHALT / PENSION SEPA-PAYMENT SALARY / PENSION SEPA-Überweisung mit Purpose Codes BONU, SALA oder PENS SEPA-Credit Transfer with Purpose Codes BONU, SALA or PENS 154 NTRF Derzeit durch DeutscheBank nicht unterstützt. Currently not supported by DeutscheBank. SEPA-Überweisung Vermögenswirksame Leistungen (Purpose Code CBFF) SEPA-Credit Transfer (single entry-credit, capital building fringe fortune / Purp.Code CBFF) 156 NTRF SEPA-ZAHL.OEFF. KASSEN SEPA-PAYM.PUBLIC AUTH. SEPA-Überweisung mit Purpose Codes GOVT, SSBE oder BENE SEPA-Credit Transfer with Purpose Codes GOVT, SSBE or BENE 159 NRTI SEPA-PASSIV- GUTSCHRIFTSRET. SEPA-CREDIT TRANSF. RETURN SEPA-Gutschriftsretoure (Passiv / Gutschrift) SEPA-Credit Transfer Return (Passive / Credit) 159 NRTI SEPA- GUTSCHRIFTS- RETOURE SEPA-CRED. TRANSF.RET SEPA-Gutschriftsretoure (Aktiv / Belastung) SEPA-Credit Transfer Return (Active / Debit) 166 NTRF SEPA-GUTSCHRIFT SEPA-CREDIT TRANSFER SEPA-Überweisung (Gutschrift) SEPA-Credit Transfer (Credit) 171 NDDT SEPA-LASTSCHRIFT EINREICHER SEPA-DIRECT DEBIT COLLECT. SEPA-Lastschrift Core (Einreichung / Gutschrift) SEPA-Direct Debit Core (Submission / Credit) 42

43 GVO Code 61 / 6 86 /?00 Buchungstext (Deutsch) 86 /?00 Posting Text (English) Lange Beschreibung Deutsch Long Description English 174 NDDT SEPA-LASTSCHRIFT B2B EINR. SEPA-DIRECT DEBIT B2B COLL. SEPA-Lastschrift B2B (Einreichung / Gutschrift) SEPA-Direct Debit B2B (Submission / Credit) 181 NRTI SEPA-LASTSCHRIFT RETOURE SEPA-DIRECT DEBIT RETURN SEPA-Lastschriftsretoure (Aktiv / Gutschrift) CORE SEPA-Direct Debit Return (Active / Credit) CORE 184 NRTI SEPA-LASTSCHR. RETOURE B2B SEPA-DD RETURN B2B SEPA-Lastschriftsretoure (Aktiv / Gutschrift) B2B SEPA-Direct Debit Return (Active / Credit) B2B 191 NTRF SEPA-AUFTRAG SAMMLER SEPA-CREDIT TRANSFER BULK SEPA-Überweisung (Belastung) Sammler SEPA-Credit Transfer (Debit) Bulk 192 NDDT SEPA-LS.EINR. CORE SAMMLER SEPA-DD COLLECT. CORE BULK SEPA-Lastschrift Core (Einreichung) Sammler SEPA-Direct Debit Core (Submission) Bulk 193 NRTI SEPA-LASTSCHRIFT REVERSAL SEPA-DIRECT DEBIT REVERSAL SEPA-Lastschrift Reversal SEPA-Direct Debit Reversal 194 NTRF SEPA-GUTSCHRIFT SAMMLER SEPA-CREDIT TRANSFER BULK SEPA-Überweisung (Gutschrift) Sammler SEPA-Credit Transfer (Credit) Bulk 195 NDDT SEPA-LASTSCHR. CORE SAMMLER SEPA-DIRECT DEBIT CORE BULK SEPA-Lastschrift Core (Belastung) Sammler SEPA-Direct Debit Core (Debit) Bulk 196 NDDT SEPA-LS.EINR. B2B SAMMLER SEPA-DD COLLECT. B2B BULK SEPA-Lastschrift B2B (Einreichung) Sammler SEPA-Direct Debit B2B (Submission) Bulk 197 NDDT SEPA-LASTSCHR. B2B SAMMLER SEPA-DIRECT DEBIT B2B BULK SEPA-Lastschrift B2B (Belastung) Sammler SEPA-Direct Debit B2B (Debit) Bulk Note: GVO Codes are / will currently only be supported in Germany, in all other countries the generic GVO codes for SEPA Credit Transfer (116 / 166) will be used SEPA References Deutsche Bank includes the major references in field 86 and identifies them with specific code words: EREF+ for the End-to-End reference MREF+ for Mandate ID (for SDD) CRED+ for Creditor ID (for SDD) IBAN and BIC In BCS-structured MT940, Deutsche Bank includes the BIC of the counterparty bank in sub-field?30 and the IBAN of the counterparty in sub-field?31. In basic SWIFT / unstructured MT940, Deutsche Bank uses the code words BIC+ and IBAN+ to identify these details. Counterparty Name In BCS-structured MT940, Deutsche Bank includes the counterparty name and address in sub-fields?32 and?33. In basic SWIFT / unstructured MT940, Deutsche Bank includes these details with the code word / ORDP /. Ultimate Parties Deutsche Bank includes this information in field 86 with the preceding code word ABWA+, ABWE+, BCS structured tag?35-36 or in special cases for unstructured remittance information with code word / ULTC / or / ULTD /. 43

44 Limitations If most of the optional fields are used, there may not be enough room for all information in fields 61 and 86 of the MT940. Deutsche Bank offers an extension for the transaction details across a second 61 / 86 field combination, known as a zero-amount transaction. This repeats all details of field 61 except for the amount being zero. Field 86 then continues the content that did not fit into field 86 of the main / original transaction. If a client has not opted for Deutsche Bank s zero-amount transaction, any information that exceeds the space provided will be cut (from the highest number down) from BCS fields and Purpose Codes In most SEPA countries, Deutsche Bank displays Purpose Codes as part of the remittance details with the preceding code word (PURP+). In Germany, special bank transaction codes are used for the most common purpose codes to identify the SEPA transactions. Purpose codes are comparable to the various Additional Text Key codes available for German legacy ACH payments: BONU, PENS, SALA: GVO code 153 (new) GOVT, SSBE, BENE: GVO code 156 (new) Rest: GVO codes 104 / 105 (SDD) or 116 (SCT) Additional text keys SEPA Code Add t Text Key Reason SEPA Code Add t Text Key Reason AC Incorrect Account Number AC Closed Account Number AC Blocked Account AG Payment Type not allowed AG Invalid Bank Operation Code AM Insufficient Funds AM Duplicate Collection / Entry BE Missing Creditor Address MD No Valid Mandate MD Missing Mandatory Information FF Invalid File Format MD Refund Request By End Customer MD End Customer Deceased MS Not Specified Reason by Customer MS Not Specified Reason by Agent NARR 914 Narrative RC Invalid BIC TM Cut-off Time RR Regulatory Reason RR Regulatory Reason RR Regulatory Reason RR Regulatory Reason SL Specific Service offered Debtor Bank FOCR 919 Return due to a Recall DUPL 920 Duplicate Payment TECH 921 Payment in Error (technical reasons) FRAD 922 Fraud AGNT 923 Incorrect Agent CURR 924 Incorrect Currency CUST 925 Recall by Customer CUTA 926 Recall due to Investigation Request UPAY 927 Undue Payment BE Unrecognised Initiating Party AC Invalid Debtor Account Type FF Invalid Local Instrument Code DNOR 932 CNOR 933 Debtor Bank is not Registered (Aviable Nov 13) Creditor Bank is not Registered (Aviable Nov 13) 44

45 R-Transactions According to the rules of Deutsche Kreditwirtschaft, return reasons will be displayed via additional text keys (in BCS subfield?34 of field 86). In addition, in most European countries Deutsche Bank displays the original ISO return reason code (SEPA code) as part of the remittance details (in?20ff) with the preceding code word RTNR+. Examples (BCS Structure) Debit Single Booking :61: D727,60NTRF / / AC :86:116?00SEPA CR TRANSFER?107E00?20EREF ?21SVWZ+INVCD INVCD970? ?30BARCGB22XXX?31GB08BAR C ?32BA RONIDAR LTD. Bulk Booking :61:090615D ,69NTRF / / :86:116?00SEPA-AUFTRAG? / 611?20KREF ?21ANZAHL UMSATZ E: 43?22IHRE REFERENZ: DTI Bulk Detail File What is it? The DTI Bulk Detail File is a legacy German domestic file format that provides details of all incoming (from clearing) transactions booked in a bulk posting, i.e. credit transfer credits, credit transfer returns and direct debit returns. Built for German domestic transactions, the DTI file is based on the German DTAUS format. How will it be used for SEPA transactions? Deutsche Bank will re-format incoming SCTs to fit into the DTI field structure. Truncation of details may be necessary. For German counterparties, the legacy bank code (BLZ) and account number will be displayed. BIC and IBAN will be shown in payment details with the preceding code words BIC+ and IBAN+, respectively. For counterparty accounts from the rest of Europe, sender-bank codes and account number fields will be filled with 9 s because they do not match the German bank code / account number structure. As an alternative, DTI files can be replaced by camt.054 files (XML-based), and individual transactions of the bulk bookings can also be directly reported in the camt.053 statement. Credit Single Booking :61: C3655,12NTRFNONREF / / AC :86:166?00SEPA CR TRANSFER?107E50?20EREF+NOTPRO VIDED?21SVWZ+INV( , ?226, )?30DABAFIHH?31FI ?32CR UDE OPTIONAL LTD OY Bulk Booking :61:090520C348,17NTRFNONREF / / :86:116?00SEPA-CREDIT TRANSFER? / 611?20SEPA- UBERWEISUNGSEINGANGE?21ANZAHL UMSATZE: 7 45

46 2.2.6 Tactical Aspects XML Account Statements XML Account Statements are part of the ISO20022 standard and successors of legacy MT formats camt.052 for MT942 (intraday transaction report) camt.053 for MT940 / 950 (end of day account statement) XML structure offers Far more granular information structure than the MT messages Significantly more space available for each transaction MT-Fields 61+86: Max. 490 characters camt: >2.000 characters across the various dedicated tags 1:1 presentation of SEPA transactions camt XML structure includes the same tags as the original messages All-purpose codes will be provided The account statement can directly include all the individual transaction details of a batch booking (no separate report in a different format needed like for legacy ACH payments) Example (due to the size of a full camt account statement, here is just a small fragment (from a SCT credit) to allow a first impression) Camt.054 Bulk Detail File What is it? Multi-purpose XML format for transaction reporting Similar structure as camt.052 and 053 How will it be used by Deutsche Bank? Reporting of all SEPA transactions booked in one bulk posting Reporting of (all) returned payments from one day (consolidated return report) This means camt.054 could also be used as a replacement for the German DTI format Corporates using camt.053 account statements will not need camt.054 unless they want or need a separate report outside the account statement As opposed to the legacy MT940, camt.053 can directly include all individual transactions of a batch booking MT versus camt If a corporate can manage the necessary developments as part of their SEPA project, then the recommendation is to migrate account reporting to camt messages. The details available are (at a minimum) the same as in MT940, but often they are better structured, and more details are available for SEPA. <NtryDtls> <TxDtls> <Refs> <Msgld>DTAZV < / Msgld> <AcctSvcrRef> < / AcctSvcrRef> <EndToEndld>ZAS < / EndToEndld> <Txld>ICFSCT TDE1 AT < / Txld> < / Refs> <AmtDtls> <InstdAmt> <Amt Ccy= EUR >429.35< / Amt> < / InstdAmt> <TxAmt> <Amt Ccy= EUR >429.35< / Amt> < / TxAmt> < / AmtDtls> <RltdPties> <Dbtr> <Nm>EXAMPLE LEBENSVERS. AG< / Nm> <PstlAdr> <AdrLine>GARTENSTRASSE 100< / AdrLine> <AdrLine>SOMETOWN< / AdrLine> 46

47 2.3 Country-Specific Requirements Austria Products in Scope / out of Scope Bulk domestic Euro credit transfers (e.g. V3 Domestic) will have to be migrated to the SCT. Domestic direct debits ( Einzugsermächtigungslastschrift and Abbuchungsauftrag ) will have to be migrated to SDD. Niche Products As mentioned above in the section on Regulation, member states had the option to allow a waiver for so-called niche products (less than 10 % market share per ECB statistics) until 1 February The Austrian legislator used this option for paper-based transactions (ATIB) and ATM / POS transactions via FINPAY. Please also refer to section 3.14 for a country-by-country overview of which instruments are in scope, niche and out of scope. IBAN Conversion Companies can use a file-based solution. Deutsche Bank will forward your file (e.g. CSV / txt / xls containing local account numbers and sort codes) to STUZZA (Society for Payment System Research and Cooperation). STUZZA will send the account numbers to the respective banks. These banks complete the request by adding the IBAN and BIC and return the file to STUZZA. Once all response files have been received from the various banks, STUZZA consolidates the information into one response file and forwards this to Deutsche Bank. We then send an xls file back to you. The end-to-end process generally does not take longer than two weeks. Creditor ID An Austrian Creditor ID (CID) can be obtained via your local Deutsche Bank Customer Service, i.e. the creditor bank starts the process, which occurs electronically via the website of the Austrian Central Bank (Oesterreichische Nationalbank OeNB). The issuance of the CID is fully automated for registered creditors (i.e. those who are registered in the Firmenbuch ) only. For all other applicants the CID will only be issued after OeNB has checked the application. OeNB will communicate the CID to the creditor bank via . A copy of this will be sent by the creditor bank to the creditor. The CID remains valid even if the creditor changes their bank. The Creditor ID for Austria is precisely 18 characters in length and is structured as follows: Positions 1 to 2: ISO country code (AT for Austria) Positions 3 to 4: check digit Positions 5 to 7: creditor business code (to be assigned by creditor, default are the letters ZZZ ) Characters 8 to 18 signify the national identifier for the creditor and are numbered in consecutive ascending order Mandate Migration Existing domestic direct debit mandates ( Einzugs ermäch tigungen and Abbuchungsaufträge ) can also be used for collections under the Core SDD scheme. They cannot be used, though, for collections under the B2B SDD scheme. The first SDD needs to be marked with the sequence type FRST and the mandate date for this SDD mandate should be the date of existing legacy mandates if known. Otherwise the date of the first submission should be used. The following table summarises which existing mandates can be used under SEPA. Direct Debit Type Core SDD B2B SDD Einzugsermächtigung Yes No Abbuchungsauftrag Yes No Microenterprises Microenterprises are treated as businesses, meaning that the B2B SDD can be used to collect from these small businesses. Interchange Fee for Direct Debits Please refer to the end of section COR1 SDD (D-1) This alternative to the Core SDD is offered to debtor accounts in Austria since April It follows the same rules as the normal Core SDD, but has a shorter submission deadline of just one business day (instead of five or two business days, respectively). Please refer to section for additional information. 47

48 2.3.2 Belgium Products in Scope / out of Scope Bulk domestic Euro credit transfers (ABB/BVB Layout 128) will have to be migrated to SCT by 1 February Domestic direct debits (DOM80) will have to be migrated to SDD Core or SDD B2B by 1 February Out of scope are LCR and Layout 128 for non-sepa payments (e.g. foreign payments). Niche Products As mentioned above in the section on Regulation, member states could allow a waiver for so-called niche products (less than 10 % market share per ECB statistics) until 1 February If a member state wanted to apply such a waiver, it had to inform the Commission accordingly (i.e. to which products it plans to apply the waiver). However, there are no niche products in Belgium. Please also refer to section 3.14 for a country-by-country overview of which instruments are in scope, niche and out of scope. IBAN Conversion A service is offered by Isabel and is described on the following website (see Annex page 73, section 3.3 / 15). There, a detailed user manual and the conversion tool can be downloaded. Creditor ID A Creditor ID (CID) for Belgium can be obtained from our local Deutsche Bank Customer Service. In Belgium, the CID can have up to 20 characters in length and has the following structure: Positions 1 to 2: ISO country code (BE for Belgium) Positions 3 to 4: Check digit Positions 5 to 7: Creditor business code (to be assigned by creditor, default are the letters ZZZ ) Positions 8 to 20: National identifier, comprising of a 10-digit enterprise VAT number (if existing). If no VAT number is available, the creditor bank will provide the national identifier as follows Positions 8 to 10: Bank code identifier Position 11: D Positions 12 to 20: increasing numbers provided by the creditor bank Mandate Migration New mandates are required when migrating to the B2B SDD scheme. The first SDD needs to be marked with the sequence type FRST and the mandate date for this SDD mandate should be the date of the first submission. Existing mandates are kept at the debtor s bank. Once the mandate has been migrated, there 48 is no possibility to return to a DOM80 direct debit. Until 1 February 2014, a creditor can use DOM80 and Core SDD in parallel, but not for the same mandate. Since existing mandates also reside with the Belgian Central Bank (Banque Nationale de Belgique BNB), it is acting as a concentrator. In this process, each bank communicates to the BNB a monthly list of all existing mandates, together with the respective IBAN / BIC and name / address of debtors. Whenever a creditor wants to migrate to SDD, they will contact their bank to obtain the IBANs of their DOM80 debtors. Based on the Creditor ID, the bank will then ask BNB for this information. A condition for the use of existing DOM80 mandates for Core SDD is that the first SDD XML message is flagged accordingly The first collection of a migrated mandate has to be flagged with the sequence type FRST In this transaction, the legacy DOM80 direct debit number has to be specified, along with the legacy Creditor ID The Amendment Indicator (tag 2.50) has to be set to True The Original Mandate ID (tag 2.52) has to report the legacy DOM80 direct debit number in the following format: DOM80 + direct debit number (e.g. DOM ) The Original Creditor Scheme ID (tag 2.53) has to report the legacy Creditor ID in the following format: DOM80 + Creditor ID (e.g. DOM ) The signature date of the mandate (tag 2.49) is the date of the migration/first SDD submission This procedure has to be strictly applied, as subsequent corrections are not possible. If this procedure is not followed, the consequence is that the debtor bank will be unable to reconcile the new SDD mandate and the legacy DOM80 mandate. As a result the creditor cannot prove that they have been authorised via a legacy mandate, as this link no longer exists. All following transactions have to be flagged as recurrent (RCUR) without any further reference to the legacy DOM80 direct debit number or legacy Creditor ID. For migrated mandates, it is recommended to use the date of the first SDD submission (if known in advance) as mandate date. Microenterprises Microenterprises are treated as businesses, which means that the B2B SDD can be used to collect from these small businesses. Interchange Fee for Direct Debits Please refer to the end of section

49 2.3.3 Czech Republic Products in Scope / out of Scope As the Czech Republic is a non-euro country, there are no local products that need to migrate to SEPA. Niche Products As the Czech Republic is a non-euro country, there are no local products that need to migrate to SEPA. IBAN Conversion No file-based service is available, only an individual solution via the website of the Czech National Bank (see Annex page 73, section 3.3 / 16). Mandate Migration SDD is a completely new and different payment type. Thus, a migration of legacy direct debit mandates to SEPA mandates is not possible, and new SEPA mandates are required. Microenterprises Microenterprises are treated as consumers, which means the B2B SDD cannot be used to collect from these small businesses. Interchange Fee for Direct Debits There is no Multilateral Interchange Fee (MIF) per-item in Czech Republic. Creditor ID The Creditor Identifier (CID) can be obtained via our local Deutsche Bank customer service, and the process is managed by the Czech National Bank. Each bank registers its clients for the Creditor Identifier. Upon client request, Deutsche Bank will ask the client to fill in a required form. Further details can be found at the website of the Czech National Bank (see Annex page 73, section 3.3 / 17). The structure of the CID is as follows: CZkkZZZnnnnn Positions 1 to 2: ISO country code (CZ for Czech Republic) Positions 3 to 4: check digit (Kk) according to ISO 7064 modulo 97 Positions 5 to 7: ZZZ: will be not used Positions 8 to 12: a number from to 99999; it is a creditor-specific identifier 49

50 2.3.4 Estonia Products in Scope / out of Scope Bulk domestic Euro credit transfers will have to be migrated to the SCT. Domestic direct debits will migrate to an e-invoice payment service. Niche Products There are no niche products in Estonia to migrate to SEPA. IBAN Conversion A centralised IBAN converter is planned to be made available by the Estonian Bank Association soon. Mandate Migration Existing direct debit mandates cannot be used for SDD collections. Thus, for SDDs, new mandates need to be obtained. Microenterprises Microenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses. Interchange Fee for Direct Debits There is no such fee in Estonia. SDD In Estonia, the SDD will not be widely used. Instead, e-invoicing services will be used. If a creditor nevertheless wants to collect from Estonian debtors via SDD, they can do so from any SEPAready Deutsche Bank account, because Estonian banks are SDD-reachable. Creditor ID The Creditor ID (CID) can be obtained via local banks. The Central Commercial Register s registry code is used as the national part of the Estonian Creditor ID. Since the registry code is only eight digits long, three leading zeros are used. Thus, the Estonian CID is structured as follows: Position 1 to 2: ISO country code (EE for Estonia) Position 3 to 4: check digit according to ISO 7064 Mod Position 5 to 7: creditor business code (to be assigned by creditor, default are the letters ZZZ ) Position 8 to 9: ISO country code of the registry or ID code s issuer Position 10 to 20: registry code including three leading zeros 50

51 2.3.5 Finland Products in Scope / out of Scope Banks will offer conversion services for creditors where domestic direct debits will be migrated to e-invoice or direct payment. The migration must be done before 20 November SDDs will exist next to e-invoicing, but it is expected that the usage will be low. Mandate Migration Existing direct debit mandates cannot be used for SDD collections. Thus, for SDDs, new mandates need to be obtained. Microenterprises Microenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses. Niche Products There are no niche products in Finland. IBAN Conversion IBANs became mandatory in Finland in 2011, so conversion is no longer necessary. SDD In Finland, the SDD will not be used widely. Only very few Finnish banks are expected to offer creditor services. Instead, e-invoicing services will be used. If a creditor nevertheless wants to collect from Finnish debtors via SDD, they can do so from any SEPA-ready Deutsche Bank account, because Finnish banks are SDD-reachable. Creditor ID A Finnish Creditor ID (CID) can be obtained via the local banks. In Finland, the CID has 15 characters and has the following structure: Positions 1 to 2: ISO country code (FI for Finland) Positions 3 to 4: check digit Positions 5 to 7: creditor business code (to be assigned by creditor, default letters are ZZZ ) Positions 8 to 15: national identifier, which in Finland is the Business-ID (8 digits) 51

52 2.3.6 France Products in Scope / out of Scope CFONB160 (Bulk domestic Euro credit transfers and direct debits) will have to be migrated to SCT, Core SDD or B2B SDD by 1 February Out of scope, for instance, are CFONB320, VCOM (deferred electronic payment order), BOR (promissory note), LCR (bill of exchange), or electronic money (like pre-paid cards). The following territories will migrate to SEPA by 1 February 2014: French Guiana, Guadeloupe, Martinique, Mayotte, Réunion, Saint-Barthélemy, Saint-Martin, Saint-Pierre and Miquelon. For Polynésie Française, Nouvelle Calédonie and Wallis-et-Futuna the situation is different. These territories are not part of the European Union and therefore do not fall under Regulation No. 260/2012. These territories have their own ISO country code, but their IBAN starts with FR. Today, these territories instruct payments (EUR and XPF) using the CFONB Minos Format. From February 2014 however, these territories must receive/ issue XML instructions for EUR transactions and R transactions between banks. However, they will not participate in the SEPA schemes - this is the so-called SEPA COM Pacifique. If a creditor is looking to collect from a debtor in one of the SEPA COM Pacifique countries, the following conditions apply: 1. They need a local account in the respective territory 2. If collecting in XPF, they must use the CFONB format 3. If collecting in EUR, they must use the XML format Niche Products As mentioned above in the section on Regulation, member states had the option to allow a waiver for so-called niche products (less than 10 % market share per ECB statistics) until 1 February If a member state wanted to apply such a waiver, it had to inform the Commission accordingly (i.e. to which products it plans to apply the waiver). The French legislator decided to use this option for the following payment types: TIP (non-pre-authorised direct debits) and Télérèglement. Please also refer to section 3.14 for a country-by-country overview of which instruments are in scope, niche and out of scope. IBAN Conversion Customers may their files in CSV or XLS format to their Deutsche Bank customer service representative. The file must contain the bank code (code banque: 5 digits), sort code (code guichet: 5 digits), basic account number (11 digits) and digit key (2 digits). Deutsche Bank will add the respective IBANs / BICs and provide a CSV file via . The turnaround time for the conversion service is approximately two business days upon receipt of the file(s). Creditor ID A French Creditor ID can be obtained from local Deutsche Bank implementation teams and the process is managed by Bank of France. The CID (Identifiant Créancier SEPA) is composed of 13 characters. It is structured as follows: Positions 1 to 2: ISO country code (FR for France) Positions 3 to 4: check digit Positions 5 to 7: creditor business code (to be assigned by creditor, default are the letters ZZZ ) Positions 8 to 13: national identifier for the creditor, which is the NNE (Numero National d Emetteur) 52

53 Mandate Migration Existing mandates remain valid for the Core SDD scheme, but for B2B SDDs, new mandates are required. For migrated mandates, it is recommended for creditors to have the mandate reference called RUM, Reference Unique de Mandat in France start with two pluses + +, as these characters indicate is a mandate was migrated. The creditor must pre-notify the debtor about an upcoming SDD collection at least 14 days in advance of the due date (unless a different notification period was bilaterally agreed on) - this can be done e.g. through the usage of invoices or any other means. For the first SEPA Direct Debit the following conditions apply: It must be presented with the sequence type FRST, and initiated no later than five business days prior to the due date. The mandate date for this SDD mandate should be the date of existing legacy mandates if known, otherwise the date of the first submission should be used If the NNE is different from the NNE of the legacy direct debit, the following information must be submitted: AmendmentIndicator set to True The legacy NNE The SEPA Creditor ID If the NNE is identical to the original NNE AmendmentIndicator set to False The SEPA Creditor ID Interchange Fee for Direct Debits Please refer to the end of section CAI Message Since March 2013, Deutsche Bank supports the XML camt.022 message. This message is more commonly called CAI (Identification Modification Advice). For SDDs, this message will be sent by the debtor bank to the creditor bank to inform them in case of incorrect debtor-bank details in the original SDD. This message will then be provided to the creditor to allow them to update their client database. Microenterprises Microenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses. 53

54 2.3.7 Germany Products in Scope / out of Scope Bulk domestic Euro credit transfers (e.g. DTAUS) will have to be migrated to the SCT. Domestic direct debits ( Einzugsermäch tigungslastschrift and Abbuchungsauftrag ) will have to be migrated to SDD. Niche Products As mentioned above in the section on Regulation, member states can have the option to allow a waiver for so-called niche products (less than 10 % market share per ECB statistics) until 1 February If a member state wanted to apply such a waiver, then it had to inform the Commission accordingly (i. e. to which products it plans to apply the waiver, too). This option also appliesd to transactions that are initiated by a card at the point of sale (POS), but where the underlying payment transaction results in a direct debit. The German legislator will use this option for the German POS direct debit, the so-called Elektronisches Lastschriftverfahren (ELV) will be treated as a niche product. No other niche products exist currently. Please also refer to section 3.14 for a country-by-country overview of which instruments are in scope, niche and out of scope. IBAN Conversion To facilitate the automated migration from legacy account numbers and bank routing codes to IBAN and BIC, the German banking community has developed a web-based application called IBAN-Service-Portal (see Annex page 73, section 3.3 / 18). During the registration process, please use the following initial password: kzx1u23z Creditor ID A German Creditor ID (CID) can be obtained from the German Central Bank. Applications for the issuance of a Creditor ID can be made on business days between 0600 and 2000 in electronic form only via the Central Bank s website (see Annex page 73, section 3.3 / 19). Applications cannot be submitted in any other way. The prerequisite for the allocation of a Creditor ID by the German Central Bank is that the creditor has its principal residence or principal office in Germany. For creditors who may not be able to obtain a Creditor ID from their country (because they are based outside the SEPA-zone or do not maintain a bank-relationship in their country), Deutsche Bundesbank offers to create a CID upon request by a German bank. Creditor ID s are assigned via . The CID for Germany is exactly 18 characters in length and is structured as follows: Positions 1 to 2: ISO country code (DE for Germany) Positions 3 to 4: check digit Positions 5 to 7: creditor business code (to be assigned by creditor, default are the letters ZZZ ) Characters 8 to 18 signify the national identifier for the creditor and are numbered in consecutive ascending order Mandate Migration Since 9 July 2012, existing domestic direct debit mandates (Einzugsermächtigungen only) can also be used for collections under the Core SDD scheme. Existing Abbuchungsaufträge cannot be used for any SDD collections (neither for Core, nor for B2B SDD). 54

55 The following table summarises which existing mandates can be used under SEPA. Direct Debit Type Core SDD B2B SDD Einzugsermächtigung Yes No Abbuchungsauftrag No No It is important to note that prior to migrating to Core SDD, the creditor is obliged (per German SDD Agreement) to inform the debtor in writing about the switch from the German legacy direct debit (Einzugsermächtigung) to Core SDD, and include the Creditor ID and the mandate reference. See sample letter (in German language) on the right side of this page: Microenterprises Microenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses. Interchange Fee for Direct Debits Please refer to the end of section COR1 SDD (D-1) This alternative to the Core SDD is planned to be offered for domestic German SDDs from November It follows the same rules as the normal Core SDD, but has a shorter submission deadline of just one TARGET business day (instead of five or two business days, respectively). Please refer to section for additional information. Domestic Urgent Payment (DTE): As a result of the German DTA format migrating to XML and IBAN becoming the standard account number format German banks have decided to also offer the current urgent domestic credit transfer (DTE) in XML format (pain.001) from November 2013 (Deutsche Bank have already been offering this since April 2013). Thus, such payments can be instructed in XML and using an IBAN. All other characteristics (e.g. the cut-off time) will remain unchanged. Sample letter DOLOREM AG IRWO Gläubiger-Identifikationsnummer: DE Mandatsreferenz 567RDF346 Umstellung auf die SEPA-Basislastschrift ab (Datum) unter weiterer Nutzung Ihrer Einzugsermächtigung (Anrede) wir nutzen bei der mit Ihnen bestehenden Geschäftsbeziehung die Lastschrift im Einzugsermächtigungsverfahren. Als Beitrag zur Schaffung des einheitlichen Euro-Zahlungsverkehrsraums (Single Euro Payments Area, SEPA) stellen wir ab dem (Datum) auf das europaweit einheitliche SEPA- Basislastschriftenverfahren um. Die von Ihnen bereits erteilte Einzugsermächtigung wird durch die oben genannte Mandatsreferenz und unsere oben genannte Gläubiger- Identifikationsnummer gekennzeichnet. Diese Aufgaben sind zukünftig bei allen Lastschrifteinzügen enthalten. Da die Umstellung durch uns erfolgt, brauchen Sie nichts unternehmen. Lastschriften werden weiterhin von Ihrem folgenden Konto eingezogen: IBAN: DE BIC: CILLDEBW (Bankhaus Cillum, Bad Wiesenwald) Sollten diese Angaben nicht mehr aktuell sein, bitten wir Sie um Nachricht. Ihre IBAN und den BIC finden Sie auch auf Ihrem Kontoauszug. Sofern Sie Fragen zu diesem Schreiben haben, kontaktieren Sie uns gerne. Mit freundlichen Grüßen Dolorem AG, Irwo The first SDD needs to be marked with sequence type FRST and the mandate date for this SDD mandate should be the date of migration notification to the debtor. 55

56 2.3.8 Hungary Products in Scope / out of Scope As Hungary is a non-euro country, there are no local products that need to migrate to SEPA. Niche Products As Hungary is a non-euro country, there are no local products that need to migrate to SEPA. IBAN Conversion No file-based service is available, only an individual solution via this German-language website (see Annex page 73, section 3.3 / 20). Creditor ID This is not applicable, as the SDD is not currently used in Hungary. Mandate Migration This is not applicable, as the SDD is not currently used in Hungary. Microenterprises Microenterprises are treated as consumers, which means the B2B SDD cannot be used to collect from these small businesses, even after SDD s become available in Hungary. Interchange Fee for Direct Debits There is no Multilateral Interchange Fee (MIF) per-item in Hungary. Due to legal reasons, the SDD is not yet available in Hungary. 56

57 2.3.9 Ireland Products in Scope / out of Scope The Direct Debit Core scheme of the Irish Retail Electronic Clearing Company (IRECC) has to be migrated to SDD. Direct Debit Plus will be migrated to an Additional Optional Service (AOS) as follows: An AOS has been accepted for the Irish banking community that will allow the current Direct Debit Plus to continue under SEPA, provided that the creditors and debtors accounts are both held with banks in Ireland. Direct Debit Plus does not require a paper mandate and provides for a shorter advance notice to be given to the debtor before each collection. Bulk domestic Euro credit transfers (e.g. EFT/EMTS) are already migrating to SCT. Niche Products There are no niche products in Ireland. IBAN Conversion If corporates have an account in Ireland, they can use a filebased IBAN conversion tool offered by the Irish Payment Services Organisation (IPSO) (see Annex page 73, section 3.3 / 21). It is recommended to use this tool to update the partners data in their ERP/treasury systems. For a corporate without an account In Ireland, IPSO also offers an online tool (see Annex page 73, section 3.3 / 22) for one-byone IBAN conversion, as and when required. Alternatively, customers can submit SEPA transactions to their Irish bank with only the BBAN instead of the IBAN, and the bank generates the IBAN on the fly. Creditor ID The Creditor Identifier (CID) can be obtained from your bank in Ireland and will be maintained by IPSO. Applicants must be registered in or have their principle office in Ireland. The CID for Ireland is 13 characters in length and is structured as follows: Positions 1 to 2: ISO Country Code Positions 3 to 4: check digit Positions 5 to 7: creditor business code (to be assigned by the creditor, default are the letters ZZZ Positions 8 to 13: national identifier for the direct debit originator, based on the legacy national scheme. This number will be the same number that an existing originator in the national scheme uses at present (if applicable) Mandate Migration The physical mandates will remain with the debtor banks, and thus there is no need for the creditor to ever produce a copy (e.g. in case of a dispute). These existing mandates can be used by the creditor for Core SDD. Microenterprises Microenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses. Interchange Fee for Direct Debits There is no interchange fee in Ireland. Other Information It may not be feasible to close local accounts in Ireland. Often, local accounts may still be required, especially for salary payments or tax reasons. However, a creditor can also use an account outside of Ireland to do SDD collections from debtors in Ireland. 57

58 Italy Products in Scope / out of Scope In Scope Domestic ACH Payments (BON) Standard direct debit (RID Ordinario) Fast direct debit (RID Veloce) Cross-Border Payments (BOE) in Euro within SEPA (these transactions will be converted to SCT starting from 1 February 2014) Out of Scope Ricevuta Bancaria (RIBA) Pagamento Mediante Avviso / Rudi Mediante Avviso (MAV/RAV) Bollettino Bancario Bills of Exchange High Value Domestic Payments (BIR) Cross-Border Payments (BOE) in non-euro Currency or outside SEPA Tax Payments (F24): The F24 form used to instruct tax payments in Italy is designed to allow the payment of a number of different taxes. The form contains various pieces of information (e.g. tax codes, etc.) used by the Italian Tax Agency to reconcile the payments. Thus, a specific electronic format is in place in Italy Domestic pre-authorised direct debits (RID) will have to be migrated to SDD, except for certain specific subtypes Financial RID, Fixed-amount RID that are viewed as niche products and therefore will remain in place until 1 February RIBA (which is not based on a mandate and requires explicit acceptance of the account holder before any debit) is not considered a direct debit and therefore is out of SEPA scope. The same is true for MAV, RAV, and Bollettino Bancario, as these are specific instruments that do not have the necessary features to be considered a direct debit. Niche Products As mentioned above in the section on Regulation, member states had the option to allow a waiver for so-called niche products (less than 10 % market share per ECB statistics) until 1 February If a member state wanted to apply such a waiver, then it had to inform the Commission accordingly (i.e. to which products it plans to apply the waiver). In Italy, RID Finanziario (Financial RID) and RID a Importo Fisso (Fixedamount RID) fall into this category. IBAN Conversion The IBAN calculation rule is public. Depending on the account holding Bank, the account number part of the IBAN may contain additional information in comparison to the legacy account number. For this reason, it is not recommended to calculate Italian IBANs from the legacy account number. To cope with the need of the creditor to feed their own database with the IBANs corresponding to a certain legacy account number, as well as to ensure that the creditor has all the updated information necessary to issue SDDs (e.g. the correct status of the debtor account consumer or non-consumer necessary to issue the proper type of SDD), a file-based service was developed by Italian banking community. Such a file-based service is available using Deutsche Bank Italy s electronic banking tool (db Corporate Banking Windows, db Corporate Banking Web). Clients can upload files containing legacy account numbers and bank routing codes. Deutsche Bank will send the account numbers to the respective banks and receive back the corresponding IBANs (or the appropriate error code in case no IBAN can be retrieved) as well as other useful information (e.g. the account status). Deutsche Bank Italy will then forward the updated file to the client. db direct users could use this service by accessing db Corporate Banking Web, which is available in English. Please also refer to section 3.14 for a country-by-country overview of which instruments are in scope, niche and out of scope. 58

59 Creditor ID The Creditor Identifier (CID) for Italy is precisely 23 characters in length and is structured as follows: Positions 1 to 2: ISO country code (IT for Italy) Positions 3 to 4: check digits, which are calculated in compliance with the MOD (ISO 7064) algorithm Positions 5 to 7: creditor business code selected by the creditor for his own business needs; default are the letters ZZZ Positions 8 to 23: national identifier for the creditor which contains the tax number assigned to the creditor by the Italian Tax Agency; the value is right-aligned, with leading zeroes (the tax number for companies is 11-digits long) To facilitate the migration from legacy direct debits to SDD, the Italian banking system generated the Creditor IDs for all companies that in January 2013 were registered with SIA as submitters of direct debits. Based on that, there are two options for a company to obtain the Creditor ID for Italy: To use the Creditor ID generated by the Italian Banking System (contact your Deutsche Bank Customer Service to obtain it) To generate the Creditor ID as described below. In this case, the company will have to calculate the check digit using the appropriate algorithm To generate the Creditor Identifier as described below. In this case, the company will have to calculate the check digit using the appropriate algorithm. The following example shows the calculation of a check digit with a non-zero remainder (ISO 7064, MOD algorithm): The number without the check digit is IT?? ZZZ Take the country-specific part (positions 8 to 23): Move the ISO country code and 00 to the right-hand end: IT00 Convert letters to digits in accordance with the conversion table: A = 10 G = 16 M = 22 S = 28 Y = 34 B = 11 H = 17 N = 23 T = 29 Z = 35 C = 12 I = 18 O = 24 U = 30 D = 13 J = 19 P = 25 V = 31 E = 14 K = 20 Q = 26 W = 32 F = 15 L = 21 R = 27 X = (I = 18, T = 29) Divide by 97: / 97 = From this number, determine the full-number difference to the next smaller multiplier of * 97 = = 88 Remainder = 88 Subtract the remainder from 98 to get the check digit: = 10 In this case the check digit is 10, the full Creditor ID is IT 10 ZZZ The control code is 10, the Creditor ID is IT 10 ZZZ Mandate Migration Existing domestic direct debit mandates for RIDs are valid for collections under the SDD scheme (for both Core and B2B). Direct Debit Type Core SDD B2B SDD RID Yes Yes It is important to note that, prior to migrating to SDD, the creditor is obliged to inform the debtor about the switch from RID to any SDD, including the Creditor ID and the mandate reference. This needs to happen at least 30 days prior to the switch, but no later than 1 December Please note that the validity of the mandate is confirmed if the refund rights for the debtor do not change (i.e. if the creditor migrate from a Standard RID that have 8 weeks as right of recourse for the debtor to an SDD B2B that have no right of recourse for the debtor the RID mandate is not valid). 59

60 Microenterprises While in Italy, microenterprises are generally treated as consumers, but for direct debits microenterprises are usually considered as businesses. This means that the B2B SDDs can be used to collect from these small businesses. Interchange Fee for Direct Debits Please refer to the end of section SEDA The current process for RIDs is based on an upfront mandate validation service called AEA Allineamento Elettronico Archivi (Electronic Database Alignment). The AEA service can be initiated by either the creditor or the debtor (who can present the paper mandate to their bank). This process allows the electronic exchange of the mandate details with the debtor bank, which has the duty to perform mandate matching and verification against any collection instruction received. Through this service it is also possible to exchange data about mandates revoked or mandate changes (e.g. change of account number). The benefits include a reduction in returns arising from nonexisting mandate and/or technical rejects. In addition, the process ensures that debtors are protected against unauthorised debiting of their account. This overall verification effort is one of the main reasons for the multilateral interchange fee existing for RIDs, which compensates the debtor bank for its mandate-related services. To maintain the existing level of service also for SDD, the Italian banking community designed the so-called SEDA service (SEPA Electronic Database Alignment) to replicate the existing AEA service. According to the Italian Banking Association (ABI), the SEDA service is expected to become available from 14 October Differently from AEA, SEDA will be an optional service for the creditor. The creditors interested in making use of this service have to make a specific request to their Alignment Bank, who will take care of the necessary setup actions (among which there is the registration of the Creditor ID into a dedicated interbank registry of SEDA users). SEDA service will be charged to the creditor making use of it directly by the Debtor s Banks mantaining the debtor s account. RID Overdraft Facility Among the credit facilities in use in Italy, there are specific instruments related to the use of direct debits, such as: An advance against the direct debit portfolio, which allows for a fraction of the amount of outstanding collections (up to the total amount) to be credited prior to the maturity date. The creditor pays a periodical interest for the time of the financing. The so-called Credito Effetti, which is an overdraft backed by the outstanding collections and thus allows for an improved interest rate compared to the standard overdraft rate. These instruments are traditionally offered in connection with RIDs to enable clients to improve liquidity. Deutsche Bank plans to offer these instruments for SDD collections as well. IBAN for SDD As mentioned in the Implementation section of this guide, oneof the key aspects of the migration to the new instruments is the availability of IBANs of the counterparties. The RID scheme is based on the upfront exchange of several data elements that are not included in the subsequent collection instructions (see section on SEDA above). One of these elements is the debtor s account number, which until a few years ago was exchanged only in legacy format. As mentioned in the IBAN Conversion section a specific function of the AEA service was created that allows the creditor to retrieve from the debtor banks the list of debtors IBANs, debtor status (consumer or non-consumer) and other parameters corresponding to legacy direct debit mandates. This allows creditors to easily update their own databases with the necessary information. Default Blocking of accounts for Core SDD Some banks have blocked the accounts of their customers for SDDs and will allow SDDs only with permission from the account holder. We therefore recommend that, prior to the issuance of SDDs, debtors are instructed to inform their banks to accept SDDs submitted by creditors. Other relevant Information XML mandatory for corporates: postponed until February

61 Luxembourg Products in Scope / out of Scope Domestic credit transfers have already been migrated to SCT. The former Luxembourg clearing system Lips-Net was discontinued in October 2006 and, after a first migration to Step2 (XCT), the domestic payment traffic migrated to Step2 (SCT) in Domestic direct debits (DOM2009) still have to be migrated to SDD (Core or B2B) by 1 February Niche Products There are no niche products in Luxembourg. IBAN conversion Accounts in Luxembourg have already been switched to IBAN, which means the IBANs have had to be used for domestic and cross border payments for a number of years already. Mandate Migration Existing domestic direct debit mandates can be used for/ migrated to either Core or B2B SDD. For further migration details, please refer to the SEPA-website of the Luxembourg Bankers Association (see Annex page 73, section 3.3 / 23) and this presentation (see Annex page 73, section 3.3 / 24). Microenterprises Microenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses. Interchange fee for SDD There is no Multilateral Interchange Fee (MIF) in Luxembourg, neither for legacy direct debits, nor for SDD. Creditor ID In Luxembourg, the Luxembourg Bankers Association (ABBL) was mandated by banks to issue the SEPA Creditor Identifier (CID) in consultation with the creditor s bank. This service has been made available from 1 July A Luxembourg CID can therefore be obtained via any bank in Luxembourg: Example: LU27ZZZ Positions 1 to 2: ISO country code (LU for Luxembourg) Positions 3 to 4: Check digit Positions 5 to 7: Creditor business code (to be assigned by creditor, default are the letters ZZZ ) Position 8: Fixed Value: 0 Position 9 to 26: National Identifier of 18 characters, normally generated from national DOM identifier, VAT number, BEI or other The creditor does not have to be located in Luxembourg to obtain a Creditor ID. 61

62 Netherlands Products in Scope / out of Scope CLIEOP03 (domestic payments and collections), ideal (National epayment Scheme) and Euro Acceptgiro will have to migrate to SEPA by 1 February 2014 (Euro Acceptgiro is a Dutch Paper Collection Method using an OCR Form. This means on the Acceptgiro form there will be an IBAN field. This SEPA Acceptgiro, however, will be discontinued as of 31 December 2018). The existing Recurrent Games of Chance direct debits (e.g. for lottery) and The Phone Mandate direct debits will be discontinued as of 1 February 2014 Out of scope is BLT91 (Cross-Border Payments). Niche Products There are no niche products in the Netherlands. Please also refer to section 3.14 for a country by country overview of which instruments are in scope, niche and out of scope. IBAN Conversion The IBAN-BIC Service is a service set-up by the national banking community. It provides BBAN (Basic Bank Account Number) to IBAN (International Bank Account Number) conversion plus the corresponding BICs. This service will be in place until September The service can be found on the following website (see Annex page 73, section 3.3 / 25). Creditor ID In the Netherlands the Creditor Identifier can be obtained from the creditor bank. Example: NL97ZZZ The Trade Register Number of the Chamber of Commerce (KvK) will be used as the national part of the Creditor Identifier. This 8-digit Trade Register Number is mandatory for all legal entities in the Netherlands. The exact specification of the Creditor Identifier for the Netherlands is structured as follows: Position 1 to 2: ISO country code (NL for Netherlands) Position 3 to 4: Check digit according to ISO 7064 Mod Position 5 to 7: Creditor business code (to be assigned by creditor, default are the letters ZZZ ) Position 8 to 15: Mandatory Trade Register Number (KvK number) of the creditor Position 16 to 19: Numerical code to be issued by the creditor bank Mandate Migration The following table summarises which existing mandates can be used under SEPA: Direct Debit Type Core SDD B2B SDD Recurrent General Direct Debit (Doorlopend Algemeen Incasso) Yes No Recurrent Business Direct Debit (Doorlopend Algemeen Bedrijven Yes No Incasso) One-off Direct Debit (Eenmalige Machtiging Incasso) No No Games of Chance Direct Debit (Kansspel Incasso)* No No Phone Mandate Direct Debit (Telefonische Machtiging Incasso)* No No * Games of chance direct debit and Phone mandate direct debit schemes cease to exist after 1 February 2014 and need to migrate to a SEPA direct debit scheme. 62

63 The national direct debit schemes - Recurrent general direct debit (Doorlopend algemeen incasso) and Recurrent business direct debit (Doorlopend algemeen bedrijven incasso) can be migrated to the SEPA direct debit Core scheme while the existing mandates remain valid. Please note that, in the Netherlands, all existing legacy mandates need to be administrated in the company s SEPA mandate database with a mandate date of 1 November 2009 to indicate that these are mandates that were issued for existing legacy direct debit types (Recurrent General or Recurrent Business). The first SDD needs to be marked with sequence type FRST. The debtor must be notified about the migration from legacy direct debit to SEPA Direct Debit. Migrating from Recurrent general direct debit (Doorlopend algemeen incasso) or Recurrent business direct debit (Doorlopend algemeen bedrijven incasso) to SEPA direct debit B2B scheme requires a new contract and new set up of the mandates. New mandates are also required to migrate from One-off direct debit (Eenmalige machtiging incasso). Games of chance direct debit (Kansspel incasso) or Phone mandate direct debit (Telefonische machtiging incasso) need to migrate to a SEPA direct debit scheme. Dutch National SEPA Migration site More information about Dutch SEPAmigration topics can be found on the following website (see Annex page 73, section 3.3 / 26). In addition, a Dutch-language guide on how to migrate from the existing Dutch Direct Debit schemes to the SEPA Direct Debit scheme is available here (see Annex page 73, section 3.3 / 27). SEPA and Payroll A corporate that would like to use a payroll service provider generally needs to have a local account for using this service. In most instances, the payroll agency on behalf of the corporate will deliver the payment files directly to the local clearer (Equens) for further processing. This so-called direct delivery service will be discontinued by 1 February 2014, and replaced with a new SEPA-compliant service for direct delivery. This means corporates will need to contact their payroll agent to find out if and when they will be migrated to this new service. They also need to contact their bank requesting to be set-up for the new direct delivery service. Interchange Fee for Direct Debits There is no Multilateral Interchange Fee (MIF) in the Netherlands. Microenterprises Microenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses. 63

64 Poland Products in Scope / out of Scope As Poland is a non-euro country, there are no local products that need to migrate to SEPA. Niche Products As Poland is a non-euro country, there are no niche products that need to migrate to SEPA. IBAN Conversion Not applicable: IBANs have already been used for corss-border and domestic transactions for many years. SDD Most banks are not yet ready to support SDD ( except, for example, Deutsche Bank ). The focus is on the local direct debit in local currency PLN. Creditor ID No solution has been developed yet. Mandate Migration Existing domestic direct debit mandates (Zgoda na polecenie zaplaty) can also be used for collections under the Core SDD scheme. However, they cannot be used for collections under the B2B SDD scheme. Microenterprises Microenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses. Interchange Fee for Direct Debits There is no Multilateral Interchange Fee (MIF) per-item in Poland. 64

65 Portugal Products in Scope / out of Scope Domestic credit transfers and domestic direct debits will have to be migrated to the SEPA Credit Transer and SEPA Direct Debit, respectively. Niche Products As mentioned above in the section on Regulation, member states had the option to allow a waiver for so-called niche products (less than 10 % market share per ECB statistics) until 1 February If a member state wanted to apply such a waiver, then it had to inform the Commission accordingly (i.e. to which products it plans to apply the waiver) before 1 February However, there are no niche products to migrate to SEPA in Portugal. Please also refer to section 3.14 for a country by country overview of which instruments are in scope, niche and out of scope. IBAN Conversion In Portugal the construction of the IBAN is done without having to change the structure of the BBAN. There is only the need to insert, before the 21-digit BBAN, the prefix PT50. Therefore, the IBAN in Portugal has a length of 25 characters. Example: PT Creditor ID (CID) The calculation of the Creditor Identifier is under the responsibility of the Creditor. They can use this website (see Annex page 73, section 3.3 / 28). If you write 00 as the check digit, the system calculates the correct check digits. The CID for Portugal is exactly 13 characters in length and is structured as follows: Positions 1 to 2: ISO country code (PT for Portugal) Positions 3 to 4: Check digit Positions 5 to 7: Creditor business code (to be assigned by creditor, default are the letters ZZZ ) Positions 8 to 13: National identifier. As the national identifier, a 6-digit number provided by SIBS (local clearing house) is used. The National identifier required for the Creditor Identifier calculation may be obtained via the dedicated local Deutsche Bank Customer Service representative. Microenterprises Microenterprises are treated as consumers, which means the B2B SDD cannot be used to collect from these small businesses. Mandate Migration Existing legacy direct debit mandates (PS2) can also be used for collections under the Core SDD scheme. They cannot be used, however, for collections under the B2B SDD scheme. Interchange Fee for Direct Debits Please refer to the end of section Other relevant Information Portugal decided on the following possible transitional measures: XML mandatory for corporates: To be postponed until February 2016 End of BIC mandatory: To be postponed until February 2016 Mandatory IBAN: To be postponed until February 2016 In addition, Central Bank Reporting will no longer be mandatory from 1 September

66 Slovakia Products in Scope / out of Scope Local credit transfers and local direct debits must be migrated to the SCT and SDD. Niche Products There are no niche products in Slovakia. IBAN Conversion Information is available on the website of the National Bank of Slovakia (NBS) (see Annex page 73, section 3.3 / 29). The NBS refers to Slovak banks to provide clients with the IBAN. Slovak banks have their own converters to calculate IBAN from BBAN. SDD Usage Before 1 February 2014, Slovak banks will likely process legacy domestic collections as SK Inkaso type via local clearing (SEPA SIPS operated by National Bank of Slovakia), not as SDD via EBA STEP2. Local clearing will be prepared for processing of SDD at the end of 2013 (in production planned from 1 February 2014). Currently, debtors accounts in Slovakia are blocked by default for SDD. If a debtor wants to be reachable by SDD before 1 February 2014, it is necessary that debtors ask their bank to change the status of the account to conditionally protected for SDD. In case the debtor does not get the status changed, some Slovak banks automatically reject SDDs, while others may contact the debtor with a request to change the account status to conditionally protected prior to the due date. From 1 February 2014 accounts in all Slovak banks will have status conditionally protected for SDD by default. If no SDD mandate has been provided by the debtor to their bank, then the debtor bank will generally contact the debtor with information about a waiting SDD, and the debtor can reject or accept the SDD. If there is no response from the debtor, the SDD is automatically accepted. Mandate Migration Existing direct debit authorisations will be automatically converted by banks into SDD mandates on 31 January Debtor banks will add the Creditor ID (if available based on CID register in Slovakia) and the mandate reference (if available based on the existing UMR of the legacy SK Inkaso) to legacy mandates and change them to SDD mandates (with sequence type RCUR and signing date 31 January 2014). If legacy mandate reference and Creditor ID are not available, the banks will update the mandate based on the data in the first SDD received. Creditor ID A centralised national register of Creditor IDs will be available on the website of the Slovak Banking Association (SBA) (see Annex page 73, section 3.3 /30) for authorised users from local banks. Creditors can apply for a CID through their local bank. The bank will then be notified about the newly issued Creditor ID by SBA. In the near future (expected for the second half of 2013), the CID registry will be administered by the National Bank of Slovakia. The structure is as follows: SKxxZZZnnnnnnnnnnn (fixed length of 18 characters). Positions 1 to 2: ISO country code (SK for Slovakia) Positions 3 to 4: Check digit Positions 5 to 7: Creditor business code (to be assigned by creditor, default are the letters ZZZ ) Positions 8 to 18: A consecutive number assigned by SBA/ National Bank of Slovakia Microenterprises Microenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses. Interchange Fee for Direct Debits There is no MIF for domestic direct debits. There is also no MIF for SDDs. 66

67 Spain Products in Scope / out of Scope Domestic direct debits (CSB19) will have to be migrated to SDD (Core SDD). Domestic and cross-border credit transfers (CSB34 and CSB34-1) must be migrated to SCT. Confirming ( supply-chain financing ) is out of scope. Niche Products As mentioned above in the section on Regulation, memberstates had the option to allow a waiver for so-called niche products (less than 10 % market share per ECB statistics) until 1 February If a member state wanted to apply such a waiver, then it had to inform the Commission accordingly (i.e. to which products it plans to apply the waiver) before 1 February Niche products are financed credit facilities (CSB58) and bills of exchange (CSB32). Please also refer to section 3.14 for a country by country overview of which instruments are in scope, niche and out of scope. IBAN Conversion Two options are available to obtain IBANs from legacy account numbers / BBANs: Calculate IBANs one by one using a tool on the internet (see Annex page 73, section 3.3 / 31). The other is an Excel application that allows pasting the legacy account numbers and receiving the corresponding IBANs. The application is available via your Deutsche Bank Spain Service representative. Creditor ID The calculation of the Creditor Identifier (CID) is under the responsibility of the creditor. They can use this website (see Annex page 73, section 3.3 / 32). If an applicant writes 00 as the check digit, the system calculates the correct check digits. The CID for Spain is precisely 16 characters in length and is structured as follows: Positions 1 to 2: ISO country code (ES for Spain) Positions 3 to 4: Check digit Positions 5 to 7: Creditor business code (to be assigned by creditor, default are the letters ZZZ ) Positions 8 to 16: National identifier. As the national identifier, the first 9 digits of the NIF (fiscal identification number) is used as follows: The first position is a letter that identifies the type of legal entity Seven numbers follow (the first two numbers identify the province, the following five numbers identify the legal entity in the province s register) Finally, a check code that can be a letter or a number Microenterprises Microenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses. Interchange Fee for Direct Debits Please refer to the end of section Mandate Migration Existing domestic direct debit mandates (CSB19) can also be used for collections under the Core SDD scheme. However, they cannot be used for collections under the B2B SDD scheme. When migrating to the Core SDD based on existing legacy mandates, the first SDD collection needs to be marked with sequence type Recurrent, and the mandate date for this SDD mandate should be 31 October Central Bank Reporting Central Bank Reporting will be no longer mandatory from 1 January COR1 SDD (D-1) This alternative to the Core SDD is available for domestic Spanish SDDs since July It follows the same rules as the normal Core SDD, but has a shorter submission deadline of just one TARGET business day (instead of five or two business days, respectively). Please refer to section for additional information. Other relevant Information Spain decided on the following possible transitional measures: XML mandatory for corporates: Postponed to February 2016 Mandatory IBAN: Postponed to February

68 Switzerland Products in Scope / out of Scope As Switzerland is a non-euro country, there are no local products that need to migrate to SEPA. Niche Products As Switzerland is a non-euro country, there are no niche products that need to migrate to SEPA. IBAN Conversion A file-based solution does not exist in Switzerland. SIX-Group offers an online tool (see Annex page 73, section 3.3 / 33). They also offer to download a small software package (see Annex page 73, section 3.3 / 34). This can also be integrated into an ERP to retrieve the corresponding IBAN for an account number / bank code combination. However, this tool does not offer the possibility to get the BIC for a specific IBAN. To get the BIC, another file (BC-Bankenstamm) can be downloaded from the SIX-Group webpage (see Annex page 73, section 3.3 / 35) as Excel- or ASCII-File. The structure is selfexplanatory, because the BIC can be found in a column next to the bank code (where available). Creditor ID On behalf of Switzerland and Liechtenstein, SIX Interbank Clearing is in charge of the issuing and administration of Creditor Identifiers (CID). Applications for the issuing of a Creditor ID are to be made exclusively through financial institutions. To receive a Creditor ID, the primary domicile and business location must be in Switzerland or Liechtenstein. The CID is structured as follows: Positions 1 and 2: ISO countrycode (CH for Switzerland) Positions 3 to 4: Check digit Positions 5 to 7: Creditor business code (to be assigned by creditor, default are the letters ZZZ ) Positions 8 to 18: Eleven-digit numerical Swiss Creditor Identifier, which unambiguously identifies the creditor within Switzerland. It will be numbered progressively beginning with 1 and filled in with leading zeros Mandate Migration SDD is a completely new and different payment type. Thus, a migration of legacy direct debit mandates to SEPA mandates is not possible, and new SEPA mandates are required. The following table summarises which existing mandates can be used under SEPA. Direct Debit Type Core SDD B2B SDD LSV No No BDD No No Interchange Fee for Direct Debits There is no Multilateral Interchange Fee (MIF) per-item in Switzerland. Applications to financial institutions are to be submitted via an online form to the Creditor Identifier CH / LI Issuing Authority, c /o SIX Interbank Clearing Ltd (see Annex page 73, section 3.3 / 36). 68

69 United Kingdom Products in Scope / out of Scope As the UK is a non-euro country, there are no local legacy instruments that need to migrate to SEPA. Niche Products As the UK is a non-euro country, there are no niche legacy instruments that need to migrate to SEPA. IBAN Conversion In the UK, the IBAN can be obtained from the counterparty only it is published on bank statements. Microenterprises Microenterprises are treated as consumers, which means the B2B SDD cannot be used to collect from these small businesses. Mandate Migration There will be no SEPA Direct Debit mandate migration required for the UK, as there are no legacy Euro direct debit instruments in use today. Interchange Fee for Direct Debits Interchange fees are not currently market practice in the UK. There is also no MIF for cross-border SDDs. Creditor ID The Creditor Identifier (CID) can be obtained via our local Deutsche Bank customer service representative. The CID for the UK can contain from 21 up to 35 characters in length and is structured as follows: Positions 1 to 2: ISO country code (GB for UK) Positions 3 to 4: Check digit Positions 5 to 7: Creditor business code (to be assigned by creditor, default are the letters ZZZ ) Positions 8 to 10: Scheme code, i.e., SDD Positions 11 to 14: Participant code, i.e., the first four characters of the issuing creditor bank s BIC Positions 15 to 20: BACS Service User Number (SUN), or 6 zeros in case of no BACS SUN Positions 21 to 35: Determined by the issuing creditor bank (alphanumeric Latin characters only) 69

70 70

71 3 Annex 3.1 Abbreviations ABBL ACH AP AR B2B BAI BDD BIC BLZ BOE CAI CBR CET CGI CID COT CSV DMF DTI DTAUS Association des Banques et Banquiers Luxembourg (Luxembourg Bankers Association) Automated Clearing House Accounts Payable Accounts Receivable Business to Business Bank Administration Institute (a file format used by banks to transfer financial data) Business Direct Debit (a Swiss direct debit type) Business Identifier Code Bankleitzahl (bank sorting code) Bonifici Esteri (Cross-border credit transfers) Change Account Information Central-Bank Reporting Central European Time Common Global Implementation (XML standardisation effort) Creditor ID Cut-Off Time Comma-Separated Values (a global file format) Debtor Mandate Flow DatenTrägeraustausch Information (German reporting format) DatenTrägeraustausch-Verfahren (German file format) HR HVP IBAN IDOC ISO LSV MIF PSD PSP PSU RID SCT SDD SEDA SEPA SIBS SLA STP SWIFT TARGET2 Human Resources High Value Payments International Bank Account Number Intermediate Document (a global file format) International Organisation for Standardisation LastSchriftVerfahren (a Swiss direct debit type) Multilateral Interchange Fee Payment Services Directive Payment Service Provider Payment Service User Rimessa Interbancaria Diretta (Italian direct debit) SEPA Credit Transfer SEPA Direct Debit SEPA Electronic Database Alignment Single Euro Payments Area Sociedade InterBancária de Serviços (Portugese Clearing House) Service Level Agreement Straight Through Processing Society for Worldwide Interbank Financial Telecommunication Trans-European Automated Real-time Gross- Settlement Express Transfer-System 2 (an interbank payment system for the real-time processing of cross-border transfers throughout the European Union) DTE Datenträger Eilig (domestic urgent payment) TWS Treasury Workstation EB Electronic Banking UK United Kingdom EBA European Banking Association VAT Value Added Tax EBICS Electronic Banking Internet Communication Standard XML Extensible Markup Language (a global file format) ECB European Central Bank XPF Französischer Pazifischer Franc EDIFACT Electronic Data Interchange For Administration, Commerce and Transport (a global file format) EEA European Economic Area ELV Elektronisches Lastschriftverfahren (German electronic direct debiting scheme) EPC European Payments Council ERP Enterprise Resource Planning EU European Union FX Foreign Exchange 71

72 3.2 Useful Links 1. European Central Bank (ECB) SEPA Indicators index.en.html 2. European Payments Council (EPC) 3. European Payments Council (EPC) - Newsletter 4. Deutsche Bank SEPA List of Hyperlinks 1. SWIFT BIC Directory 2. SWIFT BICPlusIBAN 3. Payment Services Directive (PSD) :cs&pos=-1&page=1&lang=en&pgs=10&nbl=0&list=&h words=null&action=go&visu= 4. Regulation (EC) No 924/ e=32009r0924&checktexts=checkbox 5. Regulation (EU) No 260/ %3Acs&pos=5&page=1&lang=en&pgs=10&nbl=7&list= %3Acs%2C672830%3Acs%2C673001%3Acs%2C %3Acs%2C672986%3Acs%2C673024%3Acs%2C672887% 3Acs%2C&hwords=&action=GO&visu=%23texte 6. EBA Guide PSD_Overview_Documents-L=EN.aspx 7. Simplex 8. Sentenial 9. EBA SDD B2B Participants list N=SDD_Core_SDD_B2B-L=EN.aspx 10. ISO EPC s Guidelines for the Appearance of Mandates detail.cfm?documents_id=175 72

73 12. EPC Core SDD mandate translations cfm?page=core_sdd_mandate_transalations 13. EPC B2B SDD mandate translations cfm?page=sepa_b2b_dd_mandate_translations 14. EPC Creditor ID Guide detail.cfm?documents_id= Belgian Isabel IBAN and BIC converter Czech National Bank IBAN calculator Czech National Bank Creditor ID rules_rip.html 18. German IBAN-Service-Portal German Central Bank Creditor ID Unbarer_Zahlungsverkehr/SEPA/Glaeubiger_ Identifikationsnummer/glaeubiger_identifikationsnummer.html 20. Hungary IBAN conversion (German-language website) Irish Payment Services Organisation (IPSO) IPSO BIC and IBAN converter Luxembourg Bankers Association Luxembourg Bankers Association Mandate Migration Salmon%20-%20ABBL%20-%20Migration%20to%20SDD%20 -%20Deliverable%202%20for%20PSUs%20v1%202-7.pdf 25. Netherlands IBAN Conversion Service Netherlands SEPA Migration website Netherlands Direct Debit Migration Guide Stappenplan-Van-de-huidige-Nederlandse-incasso-naar-dezakelijke-Europese-incasso.pdf 28. SEPA DD Creditor Identifier Validator National Bank of Slovakia IBAN-conversion Slovak Banking Association (SBA) Spain IBAN Conversion Spain Creditor ID Switzerland SIX-Group online IBAN-Conversion tool standardization/iban/inquiry-iban.html 34. Switzerland SIX-Group IBAN software standardization/iban/iban-tool.html 35. Switzerland SIX-Group BIC tool SIX Interbank Clearing Ltd html 37. EBA Clearing Guidance on the handling of SDD R-transactions and related charging principles 73

74 3.4 Payment Factory Brochure Deutsche Bank Global Transaction Banking The Road to European Payment/ Collection Factories

75 Over the past few years, Deutsche Bank has implemented many integrated payment and collection solutions for corporate clients around the world. With this experience, Deutsche Bank has developed best practices that can assist corporates looking for integration efficiencies within their global cash management structures. So what are the steps to be taken when centralizing payments and collections? Definitions and Benefits Shared-Service Centers (SSCs), In-House Banks and Payment/Collection Factories are distinct organisational vehicles, but the borders between them can be blurred. Companies may have different definitions/ interpretations of what exactly they are. The reason is that all three are cost centers that focus on supplying standardised, recurring services to the business units more efficiently and more effectively. All three provide: Lower Costs External economies of scale leading to lower bank fees and fewer bank accounts Internal economies of scale leading to lower IT, headcount, or overhead costs Centralised Processes Better liquidity management and simpler, more visible cash positions Improved processing quality and speed Harmonised payment/collection processes and procedures Streamlined account reconciliation Fewer IT interfaces and file formats Reduced Risks Stronger internal controls Increased IT security The idea is to industrialise labour-intense, repetitive processes and replace them with more capital-intense, centralised ones. However, while the goals between all three are similar, an SSC has the broadest scope, while a Payment Factory has the narrowest. Chart 1: Definitions of Shared-Service Center, In-House Bank and Payment/Collection Factory Shared-Service Center In-House Bank Payment/ Collection Factory A Shared-Service Center is an accountable entity within a multiunit organisation tasked with supplying the business divisions with specialized services. The range of services can vary and include accounting, human resources, IT, security, liquidity management, or accounts payable and accounts receivables. The basis for the provision of services is a Service-Level Agreement (SLA) between the participating entities with cost allocation on the basis of transfer pricing agreed. An In-House Bank is often part of a broader SSC and has the purpose of supplying various financial services to the business units. These services can include the provision of FX, interest-rate, liquidity, intercompany-liability or funding management. For example, to facilitate the efficient processing of transactions between internal entities, an In-House Bank can provide the business units with internal virtual accounts. Combined with netting of these internal flows, this can substantially reduce external bank fees. Payment Factories are by nature SSCs that are focused on the accounts-payable function. Often, they are part of an In-House Bank. The goal is to simplify and automate accounts payable. Accounts payable is an ideal candidate for centralisation because invoice receipt and processing are often paper-based and labourintensive processes. Likewise, Collection Factories are centralised collections-processing centers that are focused on the accountsreceivable function. 2

76 As illustrated in chart 2, the normal starting point for most corporates is not a Payment/ Collection Factory, but the decentralised management of payables and collections as local interfaces to local banks are set up. Chart 2: The Evolution of Payment/Collection Factories Collections on behalf of SEPA Research by gtnews showed that two-thirds of companies payments are initiated by units outside central treasury, while 33% of central treasuries have sole control over payments initiation. Companies that allow other business units to initiate payments have on average 9.5 units outside central treasury initiating payments. In Europe, a greater number of business units (12) are able to initiate payments, perhaps reflecting the geographical diversity and the number of national payment systems in Europe. 1 On the road towards centralisation, a phased approach often works best, whereby more and more formerly decentralised tasks are migrated to an SSC in a step-by-step manner. Often, the first step is to sweep liquidity from local bank accounts into a central account per country or region to improve control, visibility and investment options for excess cash. This can be followed by establishing an In-House Bank, which can facilitate inter-company netting to reduce the number of external payments and thus complexity. After that, as a third step, payments and (potentially later) collections can be centralised by establishing a Payment/Collection Factory within the SSC. Cost Reduction Expansion of Payment Factories to include Collection Factories Payments on behalf of Risk Control Expansion of in-house banks to include Payment Factories Creation of in-house banks in shared-service centers (centralisation of liquidity regionally) Centralisation of liquidity by country Local cash management by subsidiaries SEPA SEPA Drivers This final step, the creation of Payment/ Collection Factories, is currently experiencing renewed momentum for many reasons: SEPA (through the creation of pan- European payment and collection instruments and the use of a harmonised format) Increased payments complexity (as a result of the growth in international trade): To various countries Through multiple banks With distinct connections Using different formats Regulatory changes (e.g. Payment Services Directive) New technologies (e.g. web-based platforms) Evolving standards (e.g. XML) Increase in convertible currencies Geographic expansion of corporates Project Management The idea of a payment/collection factory is to industrialise labour-intensive, repetitive processes and replace them with more capital-intensive, centralised ones. This means that centralising accounts-payable and accounts-receivable processing is a rather complex task requiring a substantial investment and a significant change in internal processes and organisational structure. As a result, senior management buy-in is essential. Also, strong projectmanagement discipline is required because of the inherent complexity. Such a project could have the following components: Data collection Current countries, legal entities, ERP systems, bank relationships, costs and cost components, processing steps, inventory of transaction types used today Data analysis Pros and cons of current set-up (quantitative and qualitative, e.g. is now a good time to stop using paper checks?) Definition of strategic goals and requirements for the new structure Definition and analysis of tactical steps/ considerations for the new structure Decision on exact structure, degree of centralisation, location, processes Pros and cons of new/proposed set-up (quantitative and qualitative) Senior management buy-in Implementation Setting and monitoring of key performance indicators (KPIs) 1 gtnews Payments Survey info from

77 Data Collection and Analysis As part of the project plan there are many aspects that will influence the exact structure, degree of centralisation, location and processes of the Payment/Collection Factory. Chart 3: Strategic and Tactical Questions to ask when planning a Payment/Collection Factory (Part 1) Scope Should only AP, only AR, or both be centralised? How strong is the balance sheet and how important is internal funding? Could a collection factory help reduce DSO? How much can working capital be improved by centralizing payments? Where are suppliers and where are the corporate s own production units located? What are the entities terms of payments? How fast are current payment processes are they sufficiently fast to take advantage of discounts? How much can working capital be improved by centralizing collections? Where are the customers located? What are customers terms of payments? How fast are current collection processes? Are the customers consumers or businesses? If they are consumers, direct debits could be centralised, but cross-border credit-transfer receipts may be more difficult Which entities/subsidiaries should be included? How can common goals between different parts of the organisation be ensured? Should any of the current tasks remain with the local entities? Which payments/collections should be included? How can the existing relevant bank relationships, accounts, payments/collections, bank interfaces, formats, and local regulations best be identified? What do the internal and external cash flows look like? Banks How many banks should be used? What are the pros and cons of fewer vs. more bank relationships? Account Structure What account option(s) makes the most sense? Options can include: Payment/Collection Factory (PF/CF) owns central accounts (including currency accounts) and makes payments/collections (incl. cross-border) on behalf of the legal entities PF/CF owns local in-country accounts and makes local payments/collections on behalf of the legal entities Legal Entity (LE) owns the account, PF/CF generates payments/collections, LE only authorises them LE owns the account, PF/CF generates payments/collections, PF/CF authorises them (power of attorney) Hybrid structure, e.g. payments on-behalf-of (but collections remaining with) local entity, which could later be migrated towards on-behalf-of collections Legal & Tax What is the legal structure of the entities in scope? What is the legal status of on-behalf-of payments in the relevant countries? What are the central-bank-reporting obligations (for the payment factory, the group entity, the beneficiary)? How would they change? What are the tax implications? 4

78 Location Where should the PF/CF be located? HR costs and quality, language, travel costs, real-estate costs, time zones, tax Do the existing AML requirements change (which could potentially lead to delayed payments/ receipts)? Should a regional or a global PF/CF be used? Commercial Model What should be covered by Service-Level Agreements (SLAs)? What are the agreements regarding: Internal compensation for repair items? Intercompany loans? Transfer pricing? How can the success of the PF/CF be measured (definition of KPIs)? What are the transactional costs? Operating Model What should the new processes for making/receiving payments/collections, account reconciliation, and liquidity management look like? What instruments should be used for payments/collections? SEPA vs. local ones? What is the level of inter-company trade? What are potential effects on cash forecasting? Will payment advices be available as timely as before? What should the back-up processes look like (continuity-of-business plans)? Which characteristics influence the choice of IT infrastructure? PF/CF must handle various sources of information from subsidiaries? What kind of file formats are received from subs? What file format is sent to bank(s)? What treasury/erp systems are in place? Is it a global system or a fragmented structure? Bank Connectivity Which connectivity option makes most sense? Electronic Banking, host-to-host, SWIFTNet or others? Phased approach: start with electronic banking and move to host-to-host later? 5

79 Chart 4: The Flow of Payments/Collections in a Payment-/Collection-Factory Structure IT & Ops Services Vendor Mgmt File Transfer ACH Sub 1 Sub 2 Sub 3 SLAs ERP/ TWS/ SAP Local Format, XML, EDIFACT, CSV, IDOC, MT 101 Authorisation Feedback-File Transfer EBICS db direct internet HTTPS direct connect e.g. HTTPS/AS2 DB Systems HVP Clearing Sub 4 MT 940 MT 942 BAI Account- Statement Transfer SWIFT FileAct MA-CUG and SCORE Cheque Business Units Payment/Collection Factory Manual or automated DB s Global Centralisation Solution Senior Management Buy-in Having senior management buy-in is crucial when starting a major centralisation initiative. Quantifying the value of centralising the corporates payments/collections is therefore very important. It is important to ask how the business case compares to other projects for which funding has been asked. To strengthen the value of the project, it is extremely important that qualitative factors such as risk-management, compliance benefits, or harmonised processes and procedures are also listed. These benefits will very often be more important than costs saved from reduced bank fees or IT expenses. Therefore, probably the most important questions to ask are about the business case (See chart 5): Chart 5: Strategic and Tactical Questions to ask when planning a Payment/Collection Factory (Part 2) Business Case What are the qualitative and quantitative benefits? By how much can bank fees be reduced? By how much can working capital performance be improved? How large are the processing-quality and processing efficiency improvements? By how much can IT-maintenance costs be reduced? By how much will the visibility of liquidity be improved? By how much can risks be reduced? What are the compliance benefits? 6

80 While there will be frequent surprises along the way, answering most or all of the questions listed will give a corporate a good starting point for quantifying and qualifying the required business case and creating a detailed project plan. How Deutsche Bank can help The creation of a Payment/Collection Factory requires strong senior management commitment. With this pre-condition in place, a detailed project plan needs to be developed, taking into consideration the analysis and complex decisions required. Deutsche Bank will share best practices, experience, and lessons learned and will guide corporates through its solutions that facilitate centralisation. Examples include access-channel, file-format-conversion, reporting, FX-conversion, cross-border-ach and multi-currency-account solutions that are geared to the specific needs of Payment/ Collection Factories and will have a significant impact on the corporate s business case. Chart 6: Deutsche Bank s Solutions for Payment/Collection Factories Bank and Account concentration Format Standardisation Optimisation of Payment Authorisation Cash Pooling (local and international) Bank connectivity supporting large file sizes Standardisation of ERP systems Creation of business case = Part of Deutsche Bank services 7

81 This brochure is for information purposes only and is designed to serve as a general overview regarding the services of Payment/Collection Factories solutions for corporate clients. The general description in this brochure relates to the Payment/Collection Factories solutions for corporate clients services offered to customers as of September 2013, which may be subject to change in the future. This brochure and the general description of the services of Payment/Collection Factories solutions for corporate clients are in their nature only illustrative and do not therefore contain or cannot result in any contractual or non-contractual obligation or liability of Deutsche Bank AG or any of its affiliates. Copyright September 2013 Deutsche Bank AG. All rights reserved.

82 82

83 3.5 Availability of local IBAN Conversion Services in Europe IBAN Conversion Overview Austria Belgium Czech Republic France How to get the IBAN / BIC Via your local Deutsche Bank Implementation & Service team Via Isabel online banking Only individually via Central Bank Via your local Deutsche Bank Implementation & Service team Service description Deutsche Bank will forward the client s file (e.g. csv / txt / xls containing local account numbers and sort codes) to STUZZA (Society for Payment System Research and Cooperation). STUZZA will send the account numbers to the respective banks. These banks complete the request by adding the IBAN and BIC and return the file to STUZZA. Once all response files are received from the various banks, STUZZA consolidates the information into one response file and forwards this to Deutsche Bank. DB then sends an xls file to the client. The end-toend process generally does not take longer than two weeks. The service is described on the following website: fr/bban-iban-bic-converter There, a detailed user manual and the conversion tool can be downloaded. payment_systems/iban/ ibanen.html Clients can their files in CSV or XLS format to their DB account manager. The DB account manager will organise the file conversion with the local DB-Paris team. The file must contain the bank code (5 digits), sort code (5 digits), basic account number (11 digits) and digit key (2 digits). DB Paris will add the respective IBANs / BICs and provide back a CSV file, through . The turnaround time for the conversion service is approximately two business days upon receipt of the file(s). A fee for the service will apply. Note: The service descriptions above are indicative summaries only. For details please contact your Deutsche Bank account manager. Alternatively, instead of using these individual solutions per country, vendors like Accuity ([email protected]) offer conversion services for multiple countries. 83

84 IBAN Conversion Overview Germany Hungary Italy Netherlands Poland How to get the IBAN / BIC Service description Via BV Zahlungssysteme Companies need to register on the website (German language only) of BV Zahlungssysteme: / ibanp/iban/start The initial password for registration is kzx1u23z. Through this website, companies can upload their files containing account numbers and bank routing codes. Available file formats are CSV and Text, and sample files (in German language only) and detailed instructions are available on the website. BVZ will add the respective IBANs / BICs to the file and make the file available for download on the same website. Companies will then be informed about this via . The turnaround time for the conversion service is approximately two business days. The service currently costs EUR 45,00 as a one-time registration fee, and EUR 27,50 per items, plus VAT. Only individually via calculation Only an individual solution via this German-language website: ibangenerator.htm Via your local Deutsche Bank Implementation & Service team Using Deutsche Bank Italy s electronic banking tool (dbcorporate Banking Windows, dbcorporate Banking Web, based on CBI standard) clients can upload files containing legacy acount numbers and bank routing codes. Deutsche Bank will send the account numbers to the respective banks and receive back the corresponding IBANs (or the appropriate error code in case no IBAN can be retrieved). Deutsche Bank will then forward the updated file to the client. Via Stichting IBAN Service http: / / www. ibanbicservice.nl / You can use this service to find out the IBAN and BIC codes of Dutch account numbers, either by entering a single account number or by sending a file. If you choose the latter option, you will need to register first. Pricing for this service is tiered and can be obtained from the website. Not applicable IBAN has already been standard practice for crossborder and domestic transactions for many years Note: The service descriptions above are indicative summaries only. For details please contact your Deutsche Bank account manager. Alternatively, instead of using these individual solutions per country, vendors like Accuity ([email protected]) offer conversion services for multiple countries. 84

85 IBAN Conversion Overview Portugal Spain Switzerland UK How to get the IBAN / BIC Service description Via Calculation In Portugal the construction of the IBAN is done without having to change the structure of the BBAN. There is only the need to insert before the BBAN the prefix PT50 (the BBAN already contains a check digit). Via your local Deutsche Bank Implementation & Service team There are two conversion options from legacy account numbers / BBANs to IBANs. One is to calculate IBANs one by one using a tool on the internet: es/herramienta/ conversion.htm The other is an Excel application that allows to paste the legacy account numbers and receive the corresponding IBANs. The application is available via your Sales Manager from Customer Service Spain Via SIX Interbank Clearing A file-based solution does not exist in CH. SIX-Group offers an online tool: com/en/home/standardization/iban/ inquiry-iban.html They also offer to download a small software: com/en/home/standardization/iban/ iban-tool.html This can also be integrated into an ERP to retrieve the corresponding IBAN for an account number / bankcode combination. However, this tool does not offer the possibility to get the BIC for a specific IBAN. To get the BIC, another file (BC-Bankenstamm) can be downloaded from the SIX-Group webpage as Excel- or ASCII-File. The structure is self-explanatory, because the BIC can be found in another column next to the bankcode (in case it is availbale): com/en/home/bank-master-data/ download-bc-bank-master.html The IBAN can be obtained from the counterparty via their bank only it is published on bank statements. Currently, no industry-wide IBANconversion solution exists. Note: The service descriptions above are indicative summaries only. For details please contact your Deutsche Bank account manager. Alternatively, instead of using these individual solutions per country, vendors like Accuity ([email protected]) offer conversion services for multiple countries. 85

86 3.6 Overview of IBAN-Conversion Offering by Accuity Payment Solutions for Corporate Treasury Improve payment efficiency With the introduction of SEPA, corporates have an opportunity to benefit from lower payment operations costs. However, this means payment instructions must contain a valid International Bank Account Number (IBAN) and Bank Identifier Code (BIC). The challenge In order to include IBANs and BICs for all euro payment instructions, corporates need to update all vendor, client and payroll bank records with valid IBAN and BIC information. This can be problematic and time consuming for already busy treasury operations. Plus, IBANs have a broader impact as Italy and Luxembourg, and even non-euro-zone countries such as Lebanon and Saudi Arabia have made IBAN compulsory for domestic payments. The solution Accuity provides a range of payment solutions to help you efficiently update all your vendor, client and payroll bank records and obtain valid IBAN and BIC information. You can choose which solution best fits your needs: Access Online: Gives you control over the process by providing you with access to our industry-leading SEPA payments solution, which allows you to convert legacy Basic Bank Account Numbers (BBANs) into valid IBANs, in batch or single query, including correct routing BICs. Data Cleanse: Engage with our subject-matter experts to outsource the cleansing of your bank records. The benefits By using Accuity s solutions, you can avoid deploying personnel to manually manage this time-consuming process. The return on investment in terms of updating vendor bank records is typically measured in weeks, providing the following immediate benefits: Lower bank charges: Decreased return fees. Improved efficiency: Fewer manual repairs. Better customer service: Your vendors, partners and employees will get paid on time. IBAN + BIC = STP IBAN Conversion IBAN Validation PLUS a Connected BIC For All SEPA Countries. Payment Solutions Access Online Data Cleanse IBAN Payment Resource An online single or batch look-up tool that validates and converts IBANs and provides all the information needed for SEPA-compliant payments, including correct routing BICs. PAYScreen Repairs your payments records prior to conversion and highlights those records that require review. PAYMENTS

87 About Accuity Comprehensive solutions to fit your business needs Accuity s global payment solutions for corporates provide the essential tools companies need to reduce costs and optimise payment efficiency. Our solutions provide the most accurate, highest-quality payment data and services available through a range of offerings that meet the needs of corporate treasury departments worldwide. With Accuity s comprehensive payment solutions, you can: Look-Up missing payment routing information with our online solutions. Clean-Up outdated or incorrect payment files. Convert and Validate BBANs into IBANs for SEPA payments. Maintain your corrected payment information files. Look-Up Maintenance Validation and Clean-Up Conversion Only Accuity has the following strategic partnerships: Accuity is the official provider of the Euro Banking Association Priority Payment Scheme central registry. Accuity is the official provider of the European Payments Council SEPA adherence database. Accuity is the official registrar of American Bankers Association routing numbers. Comprehensive reports keep you informed Accuity and focused is the official provider of the Irish Payments Services Organisation s directory of National Sort Code database. Payment Solutions for Corporate Treasury To discuss your requirements, please contact: [email protected] TBD by BNP Paribas 2010 Accuity, Inc. All rights reserved Beijing Chicago Dubai Hong Kong London New York Rome San Diego Sydney

88 3.7 Overview of Member State Options Use of Member State Options of Regulation 260/2012 End dates Euro area Member States Austria 21 January 2013 Belgium 22 February 2013 Cyprus 21 January 2013 Estonia 1 February 2013 Finland 12 September 2012 Article 6.4 End date for credit transfers in Euro area Member States earlier than 1 Feb. 2014? Article 6.4 End date for direct debits in Euro area Member States earlier than 1 Feb. 2014? Article 8.1 Multilateral interchange fees for national direct debits until 1 Feb. 2017? Conversion services and waivers No No No No Yes October 2011 (for B2B), December 2011 (for C2B) No No No No No No Yes N.A. No No Article 16.1 Are PSPs allowed to offer consumers conversion services to IBAN for national transactions until 1 Feb. 2016? Article 16.3 Is there a waiver until 1 Feb for niche products? Article 16.4 Is there a waiver until 1 Feb for card payments resulting in a direct debit? No No Yes Yes First conversion period of 12 months, if necessary further extension of up to 12 months Yes One product (credit transfer) concretely planned: image of the customer s paper instruction form is forwarded along with the payment order Yes For the electronic direct debit scheme Elektronisches Lastschriftverfahren No Yes Business continuity national scenario for credit transfers government credit transfers N.A. No N.A. N.A. No Yes The end date for this has not been specified, yet No Article 16.5 Is there a waiver until 1 Feb for use of the ISO XML format for individual credit transfers or bundled direct debits in batches? Article 16.6 Is there a waiver until 1 Feb allowing continued use of the PSP s BIC for national credit transfers? Article 16.6 Is there a waiver until 1 Feb allowing continued use of the PSP s BIC for national direct debits? No No Yes Yes First conversion period of 12 months, if necessary further extension of up to 12 months No No Yes No No No No Yes No No No Source: (tab Fact Sheets on Regulation No 260/2012 ), as of 27 February = Publication date of the national fact sheet 88

89 End dates Euro area Member States France 26 February 2013 Germany 12 September 2012 Greece 25 February 2013 Ireland 21 February 2013 Italy 25 February 2013 Article 6.4 End date for credit transfers in Euro area Member States earlier than 1 Feb. 2014? Article 6.4 End date for direct debits in Euro area Member States earlier than 1 Feb. 2014? Article 8.1 Multilateral interchange fees for national direct debits until 1 Feb. 2017? Conversion services and waivers No No No No No No No No No No Yes But French banks have decided to abandon MIF already from September 2013 No N.A. N.A. No Only allowed until 1 February 2014 Article 16.1 Are PSPs allowed to offer consumers conversion services to IBAN for national transactions until 1 Feb. 2016? Article 16.3 Is there a waiver until 1 Feb for niche products? No Yes Yes No No Migration to IBAN is complete Yes Interbank payment orders ( TIP ) until 1 Feb. 2016; electronic payment orders ( Télérèglement ) until 1 Feb No Yes No Yes RID finanziari and Rid a importo fisso Article 16.4 Is there a waiver until 1 Feb for card payments resulting in a direct debit? Article 16.5 Is there a waiver until 1 Feb for use of the ISO XML format for individual credit transfers or bundled direct debits in batches? Article 16.6 Is there a waiver until 1 Feb allowing continued use of the PSP s BIC for national credit transfers? Article 16.6 Is there a waiver until 1 Feb allowing continued use of the PSP s BIC for national direct debits? No Yes For the electronic direct debit scheme Elektron isches Lastschrift verfahren (ELV) No No No No No Yes No Yes No No Yes Yes No No No Yes Yes No Source: (tab Fact Sheets on Regulation No 260/2012 ), as of 27 February = Publication date of the national fact sheet 89

90 End dates Euro area Member States Luxembourg 12 September 2012 Malta 7 February 2013 Netherlands 25 February 2013 Portugal 14 January 2013 Slovakia 13 February 2013 Article 6.4 End date for credit transfers in Euro area Member States earlier than 1 Feb. 2014? Article 6.4 End date for direct debits in Euro area Member States earlier than 1 Feb. 2014? Article 8.1 N.A. Multilateral interchange fees for national direct debits until 1 Feb. 2017? Conversion services and waivers No No No No No No No No No No N.A. There is no legacy direct debit scheme No No Aligned with crossborder direct debits, i.e. abolished from 1 Nov No Article 16.1 Are PSPs allowed to offer consumers conversion services to IBAN for national transactions until 1 Feb. 2016? Article 16.3 Is there a waiver until 1 Feb for niche products? No official information has been published No official information has been published No No Not yet decided Yes Until 1 February 2016 No No Not yet decided N.A. Article 16.4 Is there a waiver until 1 Feb for card payments resulting in a direct debit? No official information has been published No No No N.A. Article 16.5 Is there a waiver until 1 Feb for use of the ISO XML format for individual credit transfers or bundled direct debits in batches? Article 16.6 Is there a waiver until 1 Feb allowing continued use of the PSP s BIC for national credit transfers? Article 16.6 Is there a waiver until 1 Feb allowing continued use of the PSP s BIC for national direct debits? No official information has been published No official information has been published No official information has been published No No No Yes Until 1 February 2016 Yes Malta intends to apply this derogation until 1 Feb Yes Malta intends to apply this derogation until 1 Feb No Not yet decided No No Not yet decided No Source: (tab Fact Sheets on Regulation No 260/2012 ), as of 27 February = Publication date of the national fact sheet 90

91 End dates Euro area Member States Slovenia 11 February 2013 Spain 25 February 2013 Article 6.4 End date for credit transfers in Euro area Member States earlier than 1 Feb. 2014? Article 6.4 End date for direct debits in Euro area Member States earlier than 1 Feb. 2014? Article 8.1 Multilateral interchange fees for national direct debits until 1 Feb. 2017? Yes 31 December 2011 Yes 31 December 2012 No Conversion services and waivers No No No Article 16.1 Are PSPs allowed to offer consumers conversion services to IBAN for national transactions until 1 Feb. 2016? Article 16.3 Is there a waiver until 1 Feb for niche products? No No Yes Yes Article 16.4 Is there a waiver until 1 Feb for card payments resulting in a direct debit? Article 16.5 Is there a waiver until 1 Feb for use of the ISO XML format for individual credit transfers or bundled direct debits in batches? Article 16.6 Is there a waiver until 1 Feb allowing continued use of the PSP s BIC for national credit transfers? Article 16.6 Is there a waiver until 1 Feb allowing continued use of the PSP s BIC for national direct debits? No No No No No Yes No No Source: (tab Fact Sheets on Regulation No 260/2012 ), as of 27 February = Publication date of the national fact sheet 91

92 3.8 Overview of XML-Conversion Offering by Simplex SIMPLEXGTP Mandate Management Solutions Global Mandate Management. Total Control. Simplex Mandate Manager delivers powerful SEPA Direct Debit solutions for Corporate customers. Corporate Treasurers face significant challenges in today s uncertain economic environment, with the requirement to comply with SEPA mandatory payment and direct debit schemes accompanied with a renewed focus on reducing costs. Multiple data formats and legacy treasury systems remain non-compliant with the new SEPA standard. Compliance can require Corporates to migrate to new payment and direct debit standards, overhaul current business processes and upgrade ERP and billing systems. In addition, large Corporates typically hold several banking relationships, adding further complexity to the collections process. Simplex Mandate Manager (SMM) is a comprehensive hosted solution, providing formatconversion and mandate-management services covering the full life cycle of SEPA Direct Debits. SMM has been designed specifically to address all the challenges a corporate will face, enabling you to unlock the full potential offered by SDD. The enhanced collection management service enables organisations to take full advantage of SEPA Direct Debits without requiring a change to existing Treasury or Enterprise systems. Benefits By reducing the complexity of global mandate management and XML creation, SMM delivers a wide range of benefits and efficiencies to customers. These include: Enhanced global SEPA solution for Corporates Fast and effective on-boarding Avoids costly and lengthy internal development; speed to market Massively scalable solution with a Pay-As-You- Grow model Integrates with current TMS/ERP systems Global message standards and format complexity removed with seamless transformation Provides browser-based deployment across desktop, tablet, mobile platforms

93 SIMPLEXGTP High volume scanning service to ease the bulk upload of paper mandates User friendly web access for customer services staff Secure physical and/or electronic archiving of mandates Tailored European language support. Integrated Logica Engine Fully integrated with the comprehensive financial messaging solutions provided on the Simplex Global Transaction Platform, the high performance SMM ensures global compliance and interoperability. Legacy domestic data formats for national direct debits are transformed into SDD message formats (XML), converting legacy direct debits into SDDs and managing the full life cycle of B2C and B2B SDDs. This helps Corporates benefit from lower transaction costs without the expense of changing existing Treasury or Enterprise systems. SMM on the Simplex GTP is a massively scalable solution based on award-winning technology, Logica All Payments Solution (LAPS), with proven success and strong customer references. In combining the market-leading Mandate Management engine of Logica, with best-in-class transformation and reconciliation functionality of our global cloud platform, Simplex Mandate Manager is designed from the ground-up to provide formatconversion and mandate-management services to Corporates quickly and cost effectively, regardless of their ERP. Simplex Mandate Manager is a truly future proofed banking solution: based on Oracle s Java Enterprise platform (JEE), it leverages leading application servers for the ultimate in data security and resilience. With virtually unlimited scalability and performance (benchmarked for processing 51 million SEPA business transactions per hour), SMM is the ultimate choice to power a robust and scalable service to the world s most demanding Corporates. SEPA Credit Transfers The mandate management tools provided by SMM work harmoniously with the market-leading transformation and business flows integration capabilities of the GTP, delivering significant benefits without upfront capital costs. Simplex GTP supports the translation of financial messages from one format to another and comes with built-in format libraries, including the SEPA XML rulebook libraries with all the needed messages for SEPA Credit Transfer processing. Why Simplex? As part of the comprehensive suite of hosted business services provided by the Simplex Global Transaction Platform, SMM helps address the Corporate need for increased global transparency and risk visibility, better liquidity management, intraday reconciliations and greater operational efficiencies. As a leading white-label managed payments service provider to some of the largest global transaction banks and their corporate customers, Simplex has proven expertise in providing awardwinning global transaction solutions. The cost and scalability benefits of outsourced and hosted cloud solutions are increasingly proven. The hosted services of the Simplex Global Transaction Platform provide cost-effective and scalable on-demand solutions. The reduced requirement for IT maintenance and manual mandate processing delivers measurable operational efficiencies, allowing Corporates to realign resources around core service proficiencies and revenue generation. For more information please contact: [email protected] Simplex was the first independent SWIFT Service Bureau in the UK and is the white-label managed payments service provider to some of the largest global transaction banks and their corporate customers. Founded upon the most sophisticated and robust value-added SWIFT service bureau in Europe, Simplex is a trusted global transaction platform provider, boasting a seamlessly integrated technology stack. Please contact Simplex if you would like to receive further information about our best-in-class global transaction services for Corporates, Banks and the Securities industry. Simplex Headquarters: Becket House, 36 Old Jewry, London EC2R 8DD Tel: +44 (0) [email protected] simplexgtp.com Simplex GTP Limited All rights reserved. GTP is a registered Trade Marks of Simplex GTP Ltd. The information contained in this document is provided for general information purposes only and does not constitute a service commitment. Ref: GTP_SMM_CORP_201208_E

94 3.9 Overview of XML-Conversion Offering by Sentenial Origix Corporate A complete corporate solution for both SEPA Direct Debits/ Credit Transfers LEGACY ORIGINATION ORIGINATING BANK Origix Corporate offers a complete corporate solution for both SEPA Direct Debits and Credit Transfers. Sentenial has been eveloping payments solutions since 2003 and SEPA-ready solutions since LEGACY R TRANSACTIONS LEGACY FILES Mandate Migration Mandate Management SDD Transaction Processing SCT Transaction Processing ISO XMLFORMAT ISO XML FORMAT We are the trusted choice of leading European banks and corporate customers. CORPORATE DAILY RECONCILIATION REPORTING BANK SEPA Credit Transfer For SCT, you can easily deliver payment instructions to Origix Corporate in a variety of formats, including existing domestic formats, Origix standard formats and other industry formats. Beneficiary bank accounts can be specified either in the current national format or in the BIC/IBAN format required by SEPA. Where national format is used, Origix will automatically enrich and convert the account information to BIC/IBAN and check that the bank is reachable under SEPA. This ensures that payments can continue seamlessly and successfully using the SEPA scheme. Origix Corporate automatically processes return information from other banks; original payment records are then matched and updated appropriately. This information can be viewed by the user in addition to receiving the information electronically to facilitate automatic update the of the user s accounting systems. SEPA DIRECT DEBIT Sentenial s SEPA Direct Debit (SDD) solution contains three distinct modules. These modules cover the entire process from the initial migration phase through to ongoing management and transaction processing. Origix Corporate takes a business-as-usual approach to SDD, leveraging the benefits while avoiding associated costs and risk. Implementing SEPA with Origix Corporate is fast projects have been known to be completed in a matter of days. Origix Corporate includes the following features: Support for transaction files in national / legacy formats (see Table 1) Custom-mappings for formats not included in Table 1 as well as for proprietary formats Conversion and enrichment of existing data to meet SEPA requirements File transfer connectivity to creditor banks using proven channels Conversion and return of failed direct debits Reporting and reconciliation at mandate level, file level and transaction level No need to change existing accounts & payments processing systems, minimising the costs and time needed to upgrade existing systems to SEPA BBAN/IBAN conversion Origix Corporate features three independent but interconnected modules which can be deployed as required, to minimise cost of implementation. MODULE 1 - MANDATE MIGRATION Switching to SEPA Direct Debit requires the conversion and extension of the data held in your existing legacy / domestic mandates. You can achieve this quickly and easily with Origix Corporate. The Mandate Migration module rovides a complete process to convert existing authorisations to SDD, providing: Automatic BIC/IBAN conversion Automatic generation of the required Unique Mandate Reference (UMR) Customer notification of conversion of their existing mandate to SDD Archival and retrieval of existing mandates: digital and / or physical Creation of SEPA mandates where mandates need to be re-signed Complete paper-based process (with print, post & return mail service) if required Automatic scanning, data dematerialisation and digitizing newly signed mandates MODULE 2- MANDATE MANAGEMENT With Origix Corporate you can create and archive new mandates, including paper mandates and amend existing mandates.

95 Origix Corporate A complete corporate solution for SEPA Direct Debits/ Credit Tansfers Mandates must contain information about the customer, including address and bank details. Electronically stored mandates can be migrated. Authorised (signed) paper mandates are scanned and then converted into an electronic format which is stored and uniquely linked to the scanned image. Mandate Management features: Mandate details generated from electronically provided data Manual input of customer data via a web-based GUI or web services Manual entry of debtor details onto a paper mandate 'New mandate pack' printed and posted to debtor with your branding and/or customisation Table 1 shows the national legacy formats supported, with more regularly added. MARKET FORMATS FOR COLLECTIONS R-MESSAGE CREDITOR AND TRANSFERS FILE BANK FORMAT All Sentenial CSV Sentenial CSV PAIN.008 All SAP I-doc SAP I-doc PAIN.008 BE DOM80 CODA2.3 PAIN.008 CH LSV+ LSV+ PAIN.008 DE DTAUS, DTA DTAUS, DTA PAIN.008 FR CFONB 160 CFONB 240 PAIN.008 IE STD18 STD18 PAIN.008 IT CBI RID-001 CBI PAIN.008 NL CLIEOP03 Verwinfo PAIN.008 PT SIBS EDR, PS2 SIBS EDR, PS2 PAIN.008 ES Cuaderno AEB- 19 & 58 Cuaderno AEB- 19 & 58 PAIN.008 Use default mandates or customised and branded mandates if required Signed mandates scanned; data dematerialised and then converted into an electronic format Scanning of signed mandates and storage of original mandate Amend existing mandates MIS Reporting on mandates Mandates can be created and sent to your customers in 4 ways: 1. Download, self-print and send the mandates to your customers 2. Allow customer to download / print mandates at the point-of-purchase 3. Sentenial print the mandates and send automatically to your customers 4. Sentenial print the mandates in bulk and deliver to you MODULE 3 - TRANSACTION PROCESSING SEPA compliance is compulsory for all direct debits and credit transfers, but existing financial IT systems are often unable to store or process all of the new information Legacy systems can therefore represent a serious challenge, particularly for companies that have many cross-border payments or that use legacy (non SEPA compliant) file formats. Origix Corporate accepts payments (SCT) and collections (SDD) in legacy formats, then converts and enhances the data to meet SEPA standards for immediate and automatic transaction processing. Origix Corporate also translates SEPA R-messages into a variety of legacy and flat file formats. Origix Corporate provides the following services as part of the Transaction Processing Module: Support for transaction files in any national / legacy format Conversion and enrichment of existing data from national / legacy format to XML Origix Corporate supports both B2B and Core schemes File transfer to creditor banks (connectivity) using existing or new connection(s) Automatic display of failed direct debits, linked to images of scanned physical mandates Conversion and return of failed direct debits in preferred domestic format Reporting and reconciliation Together with Sentenial, you can achieve your SEPA priorities: Ensure compliance with the SEPA regulation Avoid the risk of disrupting Direct Debit revenue streams Maintain 'business as usual', limiting cost and resource commitment Insulation from continuing market uncertainties and evolving SEPA rules Avoid a last minute 'fire drill' by taking action NOW Phone: E: [email protected] W: Sentenial 2012

96 3.10 XML checker

97

98 3.11 Country-by-country overview of how to obtain the Creditor ID Country Example Positions Variables Austria AT97ZZZ AT ## ZZZ 8: Fixed value : Counter with leading zeroes Belgium BE68ZZZ BE ## ZZZ 8 17: Enterprise No. (VAT No.) Czech CZ97ZZZnnnnn CZ ## ZZZ 8 12: Number from to Republic France FR12ZZZ FR ## ZZZ 8 13: Identifiant Créancier SEPA Germany DE97ZZZ DE ## ZZZ 8 18: Consecutive number Italy IT97ZZZA1B2C3D4E5F6G7H8 IT ## ZZZ 8 23: National fiscal code IT97ZZZ00000D4E5F6G7H8 IT ## ZZZ 8 13: Filled with : VAT number / temporary fiscal code Netherlands NL97ZZZ NL ## ZZZ 8 15: Trade Register Number (KvK number) 16 19: Numerical code Poland PL97ZZZ PL ## ZZZ 8 17: Tax Number (called NIP) PL97ZZZ PL ## ZZZ 8 17: NIW (artificial NIP) Portugal PT97ZZZ PT ## ZZZ 8 13: Creditor specific identifier Spain ES97ZZZM ES ## ZZZ 8 16: NIF (Número de Identificación Fiscal) for legal entities ES97ZZZM ES ## ZZZ 8 16: DNI (Documento Nacional de Identidad) or NIF (Número de Identificación Fiscal) for individuals ES97ZZZM ES ## ZZZ 8 16: NIE (Número de Identidad de Extranjero) for foreign individuals Switzerland CH CH ## ZZZ 8 18: Ascending number filled with leading zeroes United Kingdom GB39ZZZDDDEUT GB ## ZZZ 8 10: Scheme Code i.e. SDD 11 14: First 4 characters of creditor bank s BIC 15 20: Bacs Service User Number (SUN) or 6 zeroes in the absence of a Bacs SUN 21 27: Determined by creditor bank 98

99 Country Issuer How to obtain it Austria Austrian National Bank Via local Deutsche Bank Implementation & Service Belgium Federal Public Service (Ministry) Via local Deutsche Bank Implementation & Service Economy Czech Republic Czech National Bank Via local Deutsche Bank Implementation & Service France French Central Bank (Banque de Via local Deutsche Bank Implementation & Service France) Germany Deutsche Bundesbank Via website of Deutsche Bundesbank: Unbarer_Zahlungsverkehr/SEPA/Glaeubiger_ Identifikationsnummer/glaeubiger_identifikationsnummer.html Italy Agenzia delle Entrate Creditor to compute themselves. For a calculation example, local Deutsche Bank Implementation & Service may assist. Netherlands Creditor Bank Via local Deutsche Bank Implementation & Service Poland Customers to compute (based on their Customers to compute based on their NIP (or NIW if no NIP exists) NIP) Customers to compute (based on their NIW) Portugal SIBS (Portuguese ACH) Creditor should contact SIBS via [email protected] Spain Agencia Tributaria Creditor to compute themselves. The following website can be used: If 00 is used as the check digit, the tool calculates the correct actual check digit. Switzerland SIX Interbank Clearing Ltd. Via local Deutsche Bank Implementation & Service United Kingdom Creditor Bank Via local Deutsche Bank Implementation & Service Each legal entity needs a Creditor ID, which can be used in any country. For example, a Creditor ID obtained in France can be used to make SDD collections from an account in Belgium. Also, if the Creditor ID has been obtained e.g. via bank A in France, it remains valid even when the creditor switches banks and has no relationship with bank A in France anymore. It is generally obtained in the country where the legal entity has its headquarters, independent from where the creditor account is maintained. ## Check digit, modulo 97 ZZZ Business Area Code: Can be replaced by creditor to distinguish between e.g. departments, business lines, etc. 99

100 3.12 Overview of XML Reference Fields Deutsche Bank Global Transaction Banking SEPA Reference Mapping With the use of the XML, SEPA formatdedicated reference fields will be available as part of the SEPA Credit Transfer and SEPA Direct Debit. To show the available tags in XML and understand how they should be used, please read the information below. Available Reference Tags in XML On Batch Level: PaymentInformationIdentification On Transaction Level InstructionIdentification EndToEndIdentification RemittanceInformation RemittanceInformation Information supplied to enable the matching of an entry with the items that the transfer is intended to settle, such as commercial invoices in an accounts receivable system. (ISO Message Definition Report June 2012) EndToEnd Reference A new mandatory field for SEPA transactions is the end-to-end reference, which passes through the entire SEPA payment/direct debit cycle. It is provided in all rejected and returned transaction information (enabling automatic reconciliation), as well as in the account information for the originator and the counterparty. Reference Display in the MT940 In order to Display the References in the MT940 the information is preceded by code words, which allows for the translation into the actual MT940. Please note, for some countries the harmonisation of the Remittance Information field length to 140 Char is a limitation and has to be considered during the migration to SEPA. Definition of XML References PaymentInformationIdentification Unique identification assigned by the sending Party, to identify the Payment Information Group (Batch) within the message. InstructionIdentification Unique identification, as assigned by an instructing party, to enable an instructed party to identify the instruction. Usage: the instruction identification is a point to point reference that can be used between the instructing party and the instructed party to refer to the individual instruction. XML Tag Code Ebene Remarks PaymentInformation Identification Instruction Identification EndtoEnd Identification Remittance Information KREF+ Batch Sender Reference (max. 35 characters) serves for identification on the account statement KREF+ Transaction Sender Reference (max. 35 characters) serves for identification on the account statement EREF+ Transaction Unique Reference (max. 35 characters) that has to be part of all R-Transactions as well as the Sender and Receiver Account Statement SVWZ+ Transaction Max. 140 characters / one line (Harmonisation across all SEPA Countries) EndToEndReference Unique identification assigned by the initiating party to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. Usage: The endto-end identification can be used for reconciliation or to link tasks relating to the transaction. German Payment Detail Sample It is recommended to either move or copy the content of the first line of the Payment Details into the EndToEndIdenfication Tag, when migrating to SEPA. SEPA Ueberweisung an MONTECARLO RISTORA SRL Ihre Referenz: WALTER Mueller APPARTAMENTO IL CANARINO ARRI IBAN:IT70X C00BIC: CRFIIT3PXXX Think SEPA. Think Deutsche. This brochure is for information purposes only and is designed to serve as a general overview regarding the services of Global Transaction Banking. The general description in this brochure relates to the Global Transaction Banking services offered to customers as of September 2013, which may be subject to change in the future. This brochure and the general description of the services of Global Transaction Banking are in their nature only illustrative and do not therefore contain or cannot result in any contractual or non-contractual obligation or liability of Deutsche Bank AG or any of its affiliates. Copyright September 2013 Deutsche Bank AG. All rights reserved.

101 3.13 Additional details about the Pre-notification Deutsche Bank Global Transaction Banking SEPA Pre-Notifications SEPA Pre-Notification SEPA pre-notification fulfills various purposes: a) To inform a payer about a direct debit due to be made in order to ensure respective funds are in the account on the due date b) To protect the biller to the widest extent possible from rejected payments resulting from a lack of funds c) During migration, to inform the payer about the new SEPA data elements, e.g. creditor ID and mandate reference. The payer needs to be informed about upcoming direct debits The biller must send a so-called prenotification, for example an invoice, to the payer at least 14 calendar days before collecting the payment, unless a different time line has been agreed between the payer and the biller. The different time lines as well as the means of communication may be agreed, for example as part of the general terms & conditions or specified in the contract. With this in mind, the following examples were put together as valid options for pre-notifications. Mortgages Installment plan for the life time of the multi-year contract, which contains Due dates Amount per due date Monthly downpayment for utilities, tax Annual overview of monthly / quarterly down payments specifying Due dates Amount per due date Telephone bills Monthly distribution of invoices containing Due date of the SDD to come The amount of this SDD Increase in newspaper subscriptions Announcement in the magazine itself Pricing overview on website During migration When migrating from legacy direct debits to SEPA Direct Debits, the debtor has to be informed up-front about this migration. At the latest this could be done with a pre-notification. Mandatory Elements Name and address of the debtor Mandate reference The amount of the direct debit The due date of the direct debit The contents of the pre-notification The pre-notification includes the due date and the amount of the collection. The pre-notification may be sent only once, even for recurrent direct debit collections if the due dates and the amounts of future collections are stated. For example: a publisher (biller) may send a single prenotification annually to the newspaper subscriber (payer) if this pre-notification states that the amount of the monthly subscription fee will be collected on the first day of each month. The mandatory (i.e. minimum) elements of a pre-notification are explained in the table below. Explanations Where a direct debit is collected from a debtor s account on behalf of a debtor reference party, it is advisable to send the pre-notification to both parties. These details will allow the debtor to align the pre-notification with debit on his account. This is supposed to enable the debtor to ensure adequate funding on his account by due date at the latest The Due Date may be mentioned as exact dates (e.g. 01 Sep 2012, 01 Oct 2012, 01 Nov 2012), or a period (3 instalments, debited on the 1st day of a month, starting September 2012). Think SEPA. Think Deutsche. This brochure is for information purposes only and is designed to serve as a general overview regarding the services of Global Transaction Banking. The general description in this brochure relates to the Global Transaction Banking services offered to customers as of September 2013, which may be subject to change in the future. This brochure and the general description of the services of Global Transaction Banking are in their nature only illustrative and do not therefore contain or cannot result in any contractual or non-contractual obligation or liability of Deutsche Bank AG or any of its affiliates. Copyright September 2013 Deutsche Bank AG. All rights reserved.

102 3.14 End Date for European Payment Instruments Deutsche Bank Global Transaction Banking End Date for European Payment Instruments European Payment Scope per Country In Scope (February 2014) Niche Products (February 2016) Payments Direct Debits Austria Domestic Payments (V3) Einzugsermächtigung (V3) Abbuchungsauftrag (V3) Belgium Domestic ACH Payments (ABB/BVB Layout 128) Cross-Border Payments (ABB/BVB Layout 128) in Euro within SEPA France Domestic ACH Payments (CFONB 160) Cross-Border Payments (CFONB 320)in Euro within SEPA Domestic Direct Debits (ABB/BVB Layout 128-DOM80) Germany Domestic Payments (DTAUS) Einzugsermächtigung (DTAUS) Abbuchungsauftrag (DTAUS) Italy Domestic ACH Payments-BON (CBI-BON) Cross-Border Payments-BOE (CBI-BONE) in Euro within SEPA Netherlands Domestic ACH Payments (CLIOP03) Euro Acceptgiro (Dutch Paper Collection Method using an OCR Form) ideal (National epayment Scheme) ATIB Receivables POS/ ATM Direct Debits Domestic ACH Direct Debit (CFONB 160) TIP (non-pre-authorised direct debits) Téléreglement Standard RID-RID Ordinario/Fast RID-RID Veloce (CBI-RID) Recurrent General Direct Debits (CLIOP03) Recurrent Business Direct Debit (CLIOP03) One-Off Direct Debit (CLIOP03) Games of Chance (CLIOP03) Phone Mandate Direct Debit (CLIOP03) Out of Scope Urgent Domestic Payments (V3) Cross-Border Payments (V3) None Urgent Domestic Payments (ABB/BVB Layout 128) Urgent Cross-Border Payments (ABB/BVB Layout 128) Bills of Exchange Cross-Border Payments in Non-Euro Currency or outside SEPA (ABB/BVB Layout 128) POS Direct Debits-ELV (DTAUS) Financial RID-RID Finanziario/Fixed-amount RID-RID a Importo Fisso (CBI-RID) None Urgent Domestic (BTL91) Urgent Cross-Border (BTL91) Normal Cross-Border (BTL91) Portugal Domestic payments (PS2) Domestic Direct Debits (EDR) None None Spain Domestic payments (CSB34 and CSB34-1) Domestic Direct Debits (CSB19) Credit Advances (CSB58) Bill of Exchange & Promissory Notes (CSB32) Confirming (Financial Supply Chain) Urgent Domestic Payments (CFONB 160) Urgent Cross-Border Payments (CFONB 320) LCR Bills of Exchange Cross-Border Payments in Non-Euro Currency or outside SEPA (CFONB 320) Electronic money (kind of pre-paid card) Urgent Domestic Payment (DTAUS/DTE) Urgent Cross-Border (DTAZV/EUE ) RIBA (CBI-RIB) MAV/RAV (CBI-MAV) Bollettino Bancario (CBI-BOB) Bills of Exchange High Value Domestic Payments-BIR (CBI-BON) Cross-Border Payments-BOE (CBI-BONE) in Non-Euro Currency or outside SEPA Tax Payments-F24 (CBI-F24) These documents may not be reproduced, distributed or otherwise used without previous authorisation. This service description is for information purposes only and provides a general overview of the range of services offered by Global Transaction Banking of Deutsche Bank AG. The general information provided in this service description is based on Global Transaction Banking Services as they may be offered to clients on the date this service description was published in September This information is subject to change. This presentation and the general information on the services offered by Global Transaction Banking merely serve as an illustration; no contractual or non-contractual obligations on the part of Deutsche Bank AG or its subsidiaries, or liability claims against Deutsche Bank AG or its subsidiaries, can be derived from them. Copyright September 2013 Deutsche Bank AG. All rights reserved. RZ_Broschuere_End Date for European Payment Instruments_A4_E_ indd :03

103 3.15 Index Page BIC 17, 20, 28, 31, 43 Category Purpose Codes 20, 32 Central Bank Reporting 18, 21, 33, 65, 67 Conversion Services 11, 28, 31, 83ff, 92ff Creditor ID 22, 34, 38, 98ff Creditor Reference 32, 37f Cut-Off Times (COTs) 14, 24, 33, 38, 44 End Dates 88ff, 102 End-to-End Reference 20, 22, 32, 43 Execution Times 14, 21, 33 IBAN 20, 28, 31, 43 Mandate Management (22ff), 28, 34ff, 40, 41, 47ff Multilateral Interchange Fee (MIF) 18, 41 On-behalf-of-Field 32 Payment Order 14, 21 Pre-notification 24, 28, 38, 101 Purpose Codes 20, 32, 42, 44, 46 R-Transactions 45, 100 Reachability 17, 33 Refund Claims 15, 22ff, 34, 37, 40, 44, 59 SCT / SEPA Credit Transfer 19ff, 31ff SDD / SEPA Direct Debit 22ff, 31ff SEPA XML Format 11, 17, 19f, 28, 30, 46, 88ff, 92ff, 100 Submission Deadlines 24f, 28, 37f, 39 Value-Dating 13,

104 / gtb [email protected] The information contained in this brochure is designed to serve as a general overview of the services and does not purport to contain all the information you may require. Neither Deutsche Bank AG nor Accuity is acting or purports to act in any way as your advisor. It is recommended that you seek your own independent advice in relation to any issues (whether legal, tax, accounting, regulatory or otherwise) relating to the merits or otherwise of the services discussed. The information and the general description of the services contained herein are in their nature only illustrative and do therefore not contain or cannot result in any contractual or non-contractual obligation of Deutsche Bank AG or Accuity or any of their respective branches or affiliates. Deutsche Bank does not assume any liability or guarantee for other websites that may be accessed through hyperlinks. Deutsche Bank AG assumes no responsibility for the contents of websites that can be accessed through such links. Copyright September 2013 Deutsche Bank AG. All rights reserved.