Deutsche BankGlobal Transaction Banking

The Ultimate Guide to SEPA MigrationUpdate: Finalise your preparations now!

September 2013

2

3

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.

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

Introduction

Michael SpiegelGlobal Head of Trade Finance and Cash Management Corporates

Table of Contents

1 Background 7

1.1 What is SEPA? 7

1.2 Benefits 8

1.3 SEPA and Centralisation 9

1.3.1 Background 9

1.3.2 Bank Connectivity 9

1.4 Deutsche Bank and SEPA 10

1.5 Regulation 12

1.5.1 EPC Rulebooks 13

1.5.2 Payment Services Directive (Dir. 2007 / 64 / EC) 13

1.5.3 Regulation on cross-border payments (Reg. 924 / 2009) 16

1.5.4 SEPA-Migration End-Date Regulation (Reg. 260 / 2012) 16

1.6 The SEPA Credit Transfer 19

1.6.1 Characteristics 19

1.7 The SEPA Direct Debit 22

1.7.1 Introduction 22

1.7.2 Core vs. B2B SDD 22

1.7.3 Submission Deadlines and Processing Flow 24

1.7.4 D–1 Core SDD 25

2 Implementation 27

2.1 Project Team 27

2.2 General Requirements 30

2.2.1 Strategic Aspects 30

2.2.2 Tactical Aspects SCT and SDD 31

2.2.3 Tactical Aspects SCT only 33

2.2.4 Tactical Aspects SDD only 33

2.2.5 Tactical Aspects of the MT940 Account Statement 41

2.2.6 Tactical Aspects XML Account Statements 46

2.3 Country-Specific Requirements 47

2.3.1 Austria 47

2.3.2 Belgium 48

2.3.3 Czech Republic 49

4

5

2.3.4 Estonia 50

2.3.5 Finland 51

2.3.6 France 52

2.3.7 Germany 54

2.3.8 Hungary 56

2.3.9 Ireland 57

2.3.10 Italy 58

2.3.11 Luxembourg 61

2.3.12 Netherlands 62

2.3.13 Poland 64

2.3.14 Portugal 65

2.3.15 Slovakia 66

2.3.16 Spain 67

2.3.17 Switzerland 68

2.3.18 United Kingdom 69

3 Annex 71

3.1 Abbreviations 71

3.2 Useful Links 72

3.3 List of Hyperlinks 72

3.4 Payment Factory Brochure 74

3.5 Availability of local IBAN Conversion Services in Europe 83

3.6 Overview of IBAN-Conversion Offering by Accuity 86

3.7 Overview of Member State Options 88

3.8 Overview of XML-Conversion Offering by Simplex 92

3.9 Overview of XML-Conversion Offering by Sentenial 94

3.10 XML checker 96

3.11 Country-by-country overview of how to obtain the Creditor ID 98

3.12 Overview of XML Reference Fields 100

3.13 Additional details about the Pre-notification 101

3.14 End Date for European Payment Instruments 102

3.15 Index 103

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.

Paris

Lyon

Frankfurt

Munich

Paris Frankfurt

Lyon Munich

EU Cross-Border Payment

– X-Border Direct Debits

not possible

German CreditTransfer and Direct Debit

French CreditTransfer and Direct Debit

SEPACredit Transfer and Direct Debits

Paris

Lyon

Frankfurt

Munich

Paris Frankfurt

Lyon Munich

EU Cross-Border Payment

– X-Border Direct Debits

not possible

German CreditTransfer and Direct Debit

French CreditTransfer and Direct Debit

SEPACredit Transfer and Direct Debits

Payments Environment pre-SEPA

Payments Environment with SEPA

Map of Europe – Countries encompassed in the SEPA Initiative

Canary Islands

EEA: EU Euro countries

EEA: EU Non-Euro countries

EEA: Non-EU countries

Non-EEA countries

8

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 2014. 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 (local-currency schemes in non-Euro countries will continue to exist, however). Therefore, companies are advised to prepare for their SEPA migration right away.

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

Croatia Poland

Czech Republic Romania

Denmark Sweden

Hungary United Kingdom

Latvia

EEA: Non-EU countries (3 countries)

Iceland Norway

Liechtenstein

Non-EEA countries (2 countries)

Monaco Switzerland

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.

1 As reflected by the low migration rates, which are tracked by the European Central Bank (see Annex page 72, section 3.2 / 1)

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.

1.3.1 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-on-behalf-of (POBO) or collections-on-behalf-of (COBO) are beyond the scope of this SEPA-migration document.

1.3.2 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)

ERP System Treasury System

Integration solutions

Global Formats

Feedback Messages

Account Statements

SWIFT

Plug and Play

SAP BELLIN

HANSE ORGA

ecofinance REVAL

cogon

SAP

OpusCapita

omikron

others

others

10

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.

The Flow of Payments / Collections in a Payment- / Collection-Factory Structure

SLAs

File Transfer

Authorisation

Feedback-File Transfer

Account- Statement Transfer

Sub 1

Sub 2

Sub 3

Sub 4

DeutscheBank

SystemsClearing

ACH

HVP

Cheque

Manual or automated

Deutsche Banks’s Global Centralisation SolutionBusiness Units

MT 940 MT 942

BAI

ERP / TWS / SAP

Local Format, XML,

EDIFACT, CSV, IDOC,

MT 101

Payment / CollectionFactory

IT & Ops Services Vendor Mgmt

EBICS

db direct internet HTTPS

direct connect e.g. HTTPS / AS2

SWIFT FileActMA-CUG and

SCORE

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 1.6.1.

Deutsche Bank also offers a variety of other value-addedservices. 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

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.

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 slow2, 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

100

80

60

40

20

0

%

1999 20082000 20092002 20102004 20112006 2012 2013 2014 2015 2016 2017

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

SEPA Direct Debits Review of PSD

Review of Reg. EC 260 / 2012

PSD in effect

Reg. EC 260 / 2012 on technical and business requirements for CTs and DDs in Euro in effect

% 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)

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.

1.5.2 Payment Services Directive (Dir. 2007 / 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 theEuropean Parliament and of the Council of 13 November 2007on 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 ScopeThe PSD applies to all “payment services” (e.g. credit transfers,direct debits, card payments, cash deposits to and withdrawalsfrom a payment account, issuing and acquiring of paymentinstruments, 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 beneficiarybank must be located in the EU / EEA (Two-leg-in principle).An exception are the value-dating provisions of the PSD – theyapply even if only the payer’s or the payee’s bank is located inthe EU / EEA (One-leg-in principle). In those cases, therespective bank located in the EU / EEA will have to comply withthe value-dating provisions.

14

Out of ScopeExamples of where the PSD does not apply include paymenttransactions based on paper cheques; payment transactionscarried 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 ChargesThe 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.

15

Value DatingThe 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 ClaimsThe 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 cross-border 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 2009.

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 / 2001”. The text is available in 23 EU languages via this hyperlink: Reg. 924 (see Annex page 72, section 3.3 / 4).

1.5.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 2014. This end date has been set as part of the new Regulation (EU) No. 260 / 2012. 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 2012. 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 / 2009”. 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 ScopeIn 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 ScopeOut of scope are all other transactions, including e.g. payments via high-value payment systems or card transactions.

17

End DateA 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.

ReachabilityEurozone 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.

XMLThe 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 2016. 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 1.6.1.

BICAfter 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.

MandatesDirect 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.

18

Account LocationPayers 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,000Regulation 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 ReportingRegulation 924 / 2009 is amended in such a way that settlement-based central-bank-reporting obligations by banks shall be abandoned from 1 February 2016. 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.

MIFMultilateral 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 2012.

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.

Niche ProductsAs 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 2016. 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).

19

1.6 The SEPA Credit Transfer

1.6.1 Characteristics

SEPA XML FormatAs mentioned before, per Regulation 260 / 2012, the XML format will be binding for the exchange of bulk transactions betweencorporates 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/2012Article 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 20022 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 member-state 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

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 3.10.

– Formats that can be checked are DK XML v. 2.4-2.7 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 BICThe only permissible account identifiers for SEPA transactionsare the International Bank Account Number (IBAN) and BusinessIdentifier Code (BIC). Until now, most countries have used theseidentifiers for cross-border payments only but, under SEPAregulations, these identifiers also apply domestic payments.

New / Changed Data Elements– 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.

– 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

Execution TimeThe 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 DeductionSEPA Credit Transfers are credited in full without deduction of fees from the principal amount.

Central-Bank-Reporting Duties for Cross-Border PaymentsEfforts to abolish central-bank-reporting duties for cross-border 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

For very small companies (so-called microenterprises), some EU Member States have excluded the use of the business- to-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.

1.7 The SEPA Direct Debit

1.7.1 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 2.

1.7.2 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 whencollecting payments from consumers.

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.

23

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:

B2B SDD

3.2 Captures mandate data in processing system

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

Debtor Bank

Creditor

Creditor Bank

Core SDD

2. Sends signed mandate back to Creditor

1. Sends mandate to Debtor

3. Captures mandate data

4. Stores mandate

Debtor

Debtor Bank

Creditor

Creditor Bank

Core SDD B2B SDD

Usage With consumers and companies With companies only

Refund RightRefund right 8 weeks after debit; 13 months after debit (in case of missing mandate)

No refund right after debit

Mandate Check by Debtor Bank Optional Mandatory

Mandatory Participation of BanksEUR countries: since November 2010 Non-EUR countries: from 31st October 2016

Optional

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 2.2.4 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 non-compliance 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

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

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

Comparison Core SDD with B2B SDD

CD = Calendar Days, BD = Business Days, W = Weeks, M = Months, * D+2 in Germany CD = Calendar Days, BD = Business Days, W = Weeks, M = Months

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

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 2013.

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 TeamLead by SEPA Project Manager

Finance Areas Other Divisions

Accounting(SEPA payments, booking, collection and maintenance of IBAN / BIC)

Treasury (banking relationships / liquidity management)

Invoicing(provision of IBAN, BIC and terms of payment)

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)

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.

Phases Examples of some key steps

Phase 1Analysis and Planning

– 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

Phase 2Adjustment and Upgrade of IT Infrastructure

– Upgrade of infrastructure– Adjustment of databases (new and enhanced fields)– Upload/Input of IBAN and BIC

Phase 3Account Information and Reconciliation

– Adjustment of reconciliation process to new SEPA reference logic– Matching of SEPA return reasons to existing logic

Phase 4SCT Migration

– Adjustment of payment processes ( e.g. cut off times, booking options)– Creation and test of SEPA XML SCT (e.g. pain.001.001.03) and test of third-party conversion services (if applicable)

Phase 5Mandate Management

– Definition of a pre-notification process– Development and integration of mandate-management solution– Addition of SEPA-relevant information (e.g. mandate reference, Creditor ID)

Phase 6SDD Migration

– Adjustment of payment processes (e.g. COT, submission deadlines)– Creation and test of SEPA XML SDD (e.g. pain.008.001.02) and test of third-party conversion services (if applicable)

SEPA Migration – Key Steps

29

30

2.2 General Requirements

2.2.1 Strategic Aspects

Centralisation and Consolidation StrategySEPA 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 Strategy1 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.

Format StrategyPlease refer to section 1.6.1 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. ( ) + , - . / :

System StrategySEPA’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 StrategyThe 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

31

2.2.2 Tactical Aspects SCT and SDD

Booking Options: Bulk vs. Item-by-ItemSEPA 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 item- by-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 2.2.6.

Upfront ValidationBy 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 avalue-added service that supports validation immediately uponreceipt 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 remainingtransactions 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 BICOne 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 time-consuming 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 DeutscheBankCustomer@AccuitySolutions.com 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.

32

Payment DetailThe 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 ReferenceThe “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 ReferenceA 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 CodesThe “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 CodesThe 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 FieldThis 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.

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.

2.2.4 Tactical Aspects SDD only

ReachabilityAs 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.

34

Mandate ManagementThe 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 stand-alone 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

Deutsche BankGlobal Transaction Banking

Your Name Name of Debtor

Your Address Street and Number

ZIP and City

Country

Your Account Number IBAN

Bank (Name)

and (SWIFT BIC)

Name of Creditor Name of Creditor

Creditor ID

Street and Number

ZIP and City

Country

Creditor ID *

Contract Data

Type of Payment Recurrent payment or One-off payment

City, Date

Signature

SEPA Core Direct Debit Mandate

Mandate Reference *

Please return to: Name of Creditor

Street and Number

ZIP and City

* Mandate References may not exceed 35 characters and must consist of the following characters only: A-Z, a-z, 0-9 / - ?: ( ) . , ’+

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.

Creditor’s use only

Formular SEPA Core Direct Debit Mandate

C O M P A N Y

G B 9 3 Z Z Z S D D C X X X 0 0 0 0 0 0 1

C O M P A N Y S T R E E T

1 2 3 4 5 C O M P A N Y C I T Y

C O M P A N Y C O U N T R Y

1 2 3 4 5 8 A B C / 3 6 5 - 6 9 8

X

C O M P A N Y

C O M P A N Y S T R E E T

1 2 3 4 5 C O M P A N Y C I T Y

1 2 3 4 5

Deutsche BankGlobal Transaction Banking

Your Name Name of Debtor

Your Address Street and Number

ZIP and City

Country

Your Account Number IBAN

Bank (Name)

and (SWIFT BIC)

Name of Creditor Name of Creditor

Creditor ID

Street and Number

ZIP and City

Country

Creditor ID *

Contract Data

Type of Payment Recurrent payment or One-off payment

City, Date

Signature

SEPA Business-to-Business Direct Debit Mandate

Mandate Reference *

Please return to: Name of Creditor

Street and Number

ZIP and City

* Mandate References may not exceed 35 characters and must consist of the following characters only: A-Z, a-z, 0-9 / - ?: ( ) . , ’+

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.

Creditor’s use only

Formular SEPA Business-to-Business Direct Debit Mandate

1 2 3 4 5

C O M P A N Y

G B 9 3 Z Z Z S D D C X X X 0 0 0 0 0 0 1

C O M P A N Y S T R E E T

1 2 3 4 5 C O M P A N Y C I T Y

C O M P A N Y C O U N T R Y

1 2 3 4 5 8 A B C / 3 6 5 - 6 9 8

X

C O M P A N Y

C O M P A N Y S T R E E T

1 2 3 4 5 C O M P A N Y C I T Y

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-MandateAccording 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 bank3. 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 2015.

Mandate MigrationUnder 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.

38

Mandate ReferenceEach 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 DateThe 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-by-country overview of how to obtain the Creditor ID. In addition, the EPC also provides an overview (see Annex page 73, section 3.3/14).

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-notificationThe 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 DeadlinesCore 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 cut-off time is very early (please see section immediately below) we recommend to submit them no later than D–6 for first and one-off 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.

COTsThe 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 DatesPer 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

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.

SequenceAccording 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.

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

Value 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

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

Value 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

D–1 * D–1 D–1 D+1 D+1

D * D D D+2 D+2

* if receivedand processed prior to COT of 08:30 CET

B2B SDD

File Submission Date

Deutsche Bank Processing Date

Booking Date

Due Date

Value 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

NoteSubmission dates and COTs have been adjusted by Deutsche Bank to meet scheme rules and clearing cut-offs.

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)

Process Process

Next FRST after the first FRST has been rejected (as recommended by Rulebook and M-PEDD Business Practices)

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)

Process Process

Next OOFF transaction after a OOFF that has been settled for same mandate(less than 36 month ago)

Reject Reject

Next OOFF transaction after a FRST, a RCUR or a FNAL for same mandate has been settled (less than 36 month since settlement)

Reject Reject

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)

Reject Reject

FRST, RCUR or FNAL transaction after having received a OOFF (that has been settled less than 36 months ago)

Reject Reject

FRST, OOFF, RCUR transaction within 36 month after a FNAL transaction Reject Reject

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 ReturnsAny 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 2.2.6.

Multilateral Interchange FeeIn 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.

2.2.5 Tactical Aspects of the MT940 Account Statement

Transaction-Type CodesFor 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.

42

GVO Code

61 / 686 / ?00 Buchungstext (Deutsch)

86 / ?00 Posting Text (English)

Lange Beschreibung Deutsch Long Description English

104 NDDTSEPA-LASTSCHRIFT B2B

SEPA-DIRECT DEBIT B2B

SEPA-Lastschrift B2B (Belastung)

SEPA-Direct Debit B2B (Debit)

105 NDDT SEPA-LASTSCHRIFT SEPA-DIRECT DEBITSEPA-Lastschrift Core (Belastung)

SEPA-Direct Debit Core (Debit)

108 NRTISEPA LASTSCHR. RETOURE B2B

SEPA-DIRECT DBT. RETURN B2B

SEPA-Lastschriftsretoure B2B (Passiv / Belastung)

SEPA-Direct Debit Return B2B (Passive / Debit)

109 NRTISEPA LASTSCHR. RETOURE CORE

SEPA-DIRECT DBT. RETURN CORE

SEPA-Lastschriftsretoure Core (Passiv / Belastung)

SEPA-Direct Debit Return Core (Passive / Debit)

116 NTRF SEPA-AUFTRAGSEPA-CREDIT TRANSFER

SEPA-Überweisung (Belastung)

SEPA-Credit Transfer (Debit)

116 NTRFSEPA-AUFTR. MAN. EINGABE

SEPA-T / N MANUALLY INPUT

SEPA-Überweisung (Belastung) – paper / scanner

SEPA-Credit Transfer (Debit) – paper / scanner

116 NTRFSEPA-GUTSCHR.-DAUERAUFTR.

SEPA-CREDIT-ORDER

SEPA-Überweisung (Belastung) – Dauerauftrag

SEPA-Credit Transfer (Debit) – standing order

116 NTRFSEPA-EILIGER GUTSCHR.AUFTR.

SEPA-EXPRESS-CRED.-TRANSF.

SEPA-Beschleunigte Überweisung (Belastung)

SEPA-Accelerated Credit Transfer (Debit)

153 NTRFSEPA-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 NTRFDerzeit 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 NTRFSEPA-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 NRTISEPA-PASSIV-GUTSCHRIFTSRET.

SEPA-CREDIT TRANSF. RETURN

SEPA-Gutschriftsretoure (Passiv / Gutschrift)

SEPA-Credit Transfer Return (Passive / Credit)

159 NRTISEPA-GUTSCHRIFTS- RETOURE

SEPA-CRED.TRANSF.RET

SEPA-Gutschriftsretoure (Aktiv / Belastung)

SEPA-Credit Transfer Return (Active / Debit)

166 NTRF SEPA-GUTSCHRIFTSEPA-CREDIT TRANSFER

SEPA-Überweisung (Gutschrift)

SEPA-Credit Transfer (Credit)

171 NDDTSEPA-LASTSCHRIFT EINREICHER

SEPA-DIRECT DEBIT COLLECT.

SEPA-Lastschrift Core (Einreichung / Gutschrift)

SEPA-Direct Debit Core (Submission / Credit)

SEPA GVO and SWIFT Transaction Type Codes

43

SEPA ReferencesDeutsche 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 PartiesDeutsche 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 / .

GVO Code

61 / 686 / ?00 Buchungstext (Deutsch)

86 / ?00 Posting Text (English)

Lange Beschreibung Deutsch Long Description English

174 NDDTSEPA-LASTSCHRIFT B2B EINR.

SEPA-DIRECT DEBIT B2B COLL.

SEPA-Lastschrift B2B (Einreichung / Gutschrift)

SEPA-Direct Debit B2B (Submission / Credit)

181 NRTISEPA-LASTSCHRIFT RETOURE

SEPA-DIRECT DEBIT RETURN

SEPA-Lastschriftsretoure (Aktiv / Gutschrift) CORE

SEPA-Direct Debit Return (Active / Credit) CORE

184 NRTISEPA-LASTSCHR. RETOURE B2B

SEPA-DD RETURN B2B

SEPA-Lastschriftsretoure (Aktiv / Gutschrift) B2B

SEPA-Direct Debit Return (Active / Credit) B2B

191 NTRFSEPA-AUFTRAG SAMMLER

SEPA-CREDIT TRANSFER BULK

SEPA-Überweisung (Belastung) – Sammler

SEPA-Credit Transfer (Debit) – Bulk

192 NDDTSEPA-LS.EINR. CORE SAMMLER

SEPA-DD COLLECT.CORE BULK

SEPA-Lastschrift Core (Einreichung) – Sammler

SEPA-Direct Debit Core (Submission) – Bulk

193 NRTISEPA-LASTSCHRIFT REVERSAL

SEPA-DIRECT DEBIT REVERSAL

SEPA-Lastschrift Reversal SEPA-Direct Debit Reversal

194 NTRFSEPA-GUTSCHRIFT SAMMLER

SEPA-CREDIT TRANSFER BULK

SEPA-Überweisung (Gutschrift) – Sammler

SEPA-Credit Transfer (Credit) – Bulk

195 NDDTSEPA-LASTSCHR.CORE SAMMLER

SEPA-DIRECT DEBIT CORE BULK

SEPA-Lastschrift Core (Belastung) – Sammler

SEPA-Direct Debit Core (Debit) – Bulk

196 NDDTSEPA-LS.EINR. B2B SAMMLER

SEPA-DD COLLECT.B2B BULK

SEPA-Lastschrift B2B (Einreichung) – Sammler

SEPA-Direct Debit B2B (Submission) – Bulk

197 NDDTSEPA-LASTSCHR. B2B SAMMLER

SEPA-DIRECT DEBIT B2B BULK

SEPA-Lastschrift B2B (Belastung) – Sammler

SEPA-Direct Debit B2B (Debit) – Bulk

Note: GVO Codes 153-156 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

44

SEPA Code

Add’t Text Key

Reason

AC01 901 Incorrect Account Number

AC04 902 Closed Account Number

AC06 903 Blocked Account

AG01 904 Payment Type not allowed

AG02 905 Invalid Bank Operation Code

AM04 906 Insufficient Funds

AM05 907 Duplicate Collection / Entry

BE04 908 Missing Creditor Address

MD01 909 No Valid Mandate

MD02 910 Missing Mandatory Information

FF01 911 Invalid File Format

MD06 912 Refund Request By End Customer

MD07 913 End Customer Deceased

MS02 914 Not Specified Reason by Customer

MS03 914 Not Specified Reason by Agent

NARR 914 Narrative

RC01 915 Invalid BIC

TM01 916 Cut-off Time

RR01 917 Regulatory Reason

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 20–29 and 60–63.

SEPA Code

Add’t Text Key

Reason

RR02 917 Regulatory Reason

RR03 917 Regulatory Reason

RR04 917 Regulatory Reason

SL01 918 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

BE05 928 Unrecognised Initiating Party

AC13 930 Invalid Debtor Account Type

FF05 931 Invalid Local Instrument Code

DNOR 932Debtor Bank is not Registered(Aviable Nov 13)

CNOR 933Creditor Bank is not Registered(Aviable Nov 13)

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

45

DTI Bulk Detail FileWhat 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.

R-TransactionsAccording 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:0906160616D727,60NTRF0600144429 / / AC12790392-

00001 :86:116?00SEPA CR TRANSFER?107E00?20EREF+0600144

429?21SVWZ+INVCD97001 1257INVCD970?22011266?30BARCGB22XXX?31GB08BAR

C20212345610288?32BA RONIDAR LTD. – Bulk Booking :61:090615D1410277,69NTRF000013350214 / / 10550334 :86:116?00SEPA-AUFTRAG?109075 / 611?20KREF+0000133

50214?21ANZAHL UMSATZ E: 43?22IHRE REFERENZ: 000013350214

Credit– Single Booking :61:0906160615C3655,12NTRFNONREF / / AC12766106-

00041 :86:166?00SEPA CR TRANSFER?107E50?20EREF+NOTPRO

VIDED?21SVWZ+INV(20126 2147,20126214?226,201262148)?30DABAFIHH?31FI23800

01800123482?32CR UDE OPTIONAL LTD OY – Bulk Booking :61:090520C348,17NTRFNONREF / / 9647595 :86:116?00SEPA-CREDIT TRANSFER?109075 / 611?20SEPA-

UBERWEISUNGSEINGANGE ?21ANZAHL UMSATZE: 7

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 tags1: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 FileWhat is it? – Multi-purpose XML format for transaction reporting – Similar structure as camt.052 and 053How 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 formatCorporates 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 camtIf 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>DTAZV0110914121817873< / Msgld> <AcctSvcrRef>121817622< / AcctSvcrRef> <EndToEndld>ZAS000225899051< / EndToEndld> <Txld>ICFSCT110914133114TDE1

AT00121817622< / 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>

47

2.3 Country-Specific Requirements

2.3.1 Austria

Products in Scope / out of ScopeBulk domestic Euro credit transfers (e.g. V3 Domestic) will haveto be migrated to the SCT. Domestic direct debits (“Einzugs- ermächtigungslastschrift” and “Abbuchungsauftrag”) will have to be migrated to SDD.

Niche ProductsAs 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 2016. 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 ConversionCompanies can use a file-based solution. Deutsche Bank willforward your file (e.g. CSV / txt / xls containing local accountnumbers and sort codes) to STUZZA (Society for PaymentSystem Research and Cooperation). STUZZA will send theaccount numbers to the respective banks. These banks complete the request by adding the IBAN and BIC and return thefile to STUZZA. Once all response files have been received fromthe various banks, STUZZA consolidates the information intoone response file and forwards this to Deutsche Bank. We thensend an xls file back to you. The end-to-end process generally does not take longer than two weeks.

Creditor IDAn 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 email. A copy of this email 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 MigrationExisting domestic direct debit mandates (“Einzugs ermäch ti-gungen” 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

MicroenterprisesMicroenterprises are treated as businesses, meaning that the B2B SDD can be used to collect from these small businesses.

Interchange Fee for Direct DebitsPlease refer to the end of section 2.2.4.

COR1 SDD (D-1)This alternative to the Core SDD is offered to debtor accounts in Austria since April 2013. 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 1.7.4 for additional information.

48

2.3.2 Belgium

Products in Scope / out of ScopeBulk domestic Euro credit transfers (ABB/BVB Layout 128) will have to be migrated to SCT by 1 February 2014. Domestic direct debits (DOM80) will have to be migrated to SDD Core or SDD B2B by 1 February 2014. Out of scope are LCR and Layout 128 for non-SEPA payments (e.g. foreign payments).

Niche ProductsAs mentioned above in the section on “Regulation”, memberstates could allow a waiver for so-called niche products (less than 10 % market share per ECB statistics) until 1 February 2016. 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 ConversionA service is offered by “Isabel” and is described on the followingwebsite (see Annex page 73, section 3.3 / 15). There, a detailed user manual and the conversion tool can be downloaded.

Creditor IDA 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 MigrationNew 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

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. DOM80825000000038)

– The Original Creditor Scheme ID (tag 2.53) has to report the legacy Creditor ID in the following format: “DOM80” + Creditor ID (e.g. DOM8000400000001)

– 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.

MicroenterprisesMicroenterprises are treated as businesses, which means that the B2B SDD can be used to collect from these small businesses.

Interchange Fee for Direct DebitsPlease refer to the end of section 2.2.4.

49

2.3.3 Czech Republic

Products in Scope / out of ScopeAs the Czech Republic is a non-Euro country, there are no localproducts that need to migrate to SEPA.

Niche ProductsAs the Czech Republic is a non-Euro country, there are no localproducts that need to migrate to SEPA.

IBAN ConversionNo 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).

Creditor IDThe 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 10000 to 99999; it is a

creditor-specific identifier

Mandate MigrationSDD 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.

MicroenterprisesMicroenterprises are treated as consumers, which means the B2B SDD cannot be used to collect from these small businesses.

Interchange Fee for Direct DebitsThere is no Multilateral Interchange Fee (MIF) per-item in Czech Republic.

50

2.3.4 Estonia

Products in Scope / out of ScopeBulk domestic Euro credit transfers will have to be migrated to the SCT. Domestic direct debits will migrate to an e-invoicepayment service.

Niche ProductsThere are no niche products in Estonia to migrate to SEPA.

IBAN ConversionA centralised IBAN converter is planned to be made available by the Estonian Bank Association soon.

SDDIn 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 SEPA-ready Deutsche Bank account, because Estonian banks are SDD-reachable.

Creditor IDThe 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 97-10– 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

Mandate MigrationExisting direct debit mandates cannot be used for SDD collections. Thus, for SDDs, new mandates need to beobtained.

MicroenterprisesMicroenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses.

Interchange Fee for Direct DebitsThere is no such fee in Estonia.

51

2.3.5 Finland

Products in Scope / out of ScopeBanks 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 2013. SDDs will exist next to e-invoicing, but it is expected that the usage will be low.

Niche ProductsThere are no niche products in Finland.

IBAN ConversionIBANs became mandatory in Finland in 2011, so conversion is no longer necessary. SDDIn 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 IDA 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)

Mandate MigrationExisting direct debit mandates cannot be used for SDD collections. Thus, for SDDs, new mandates need to beobtained.

MicroenterprisesMicroenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses.

52

2.3.6 France

Products in Scope / out of ScopeCFONB160 (Bulk domestic Euro credit transfers and direct debits) will have to be migrated to SCT, Core SDD or B2B SDD by 1 February 2014. 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 territory2. If collecting in XPF, they must use the CFONB format3. If collecting in EUR, they must use the XML format

Niche ProductsAs 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 2016. 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 ConversionCustomers may email 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 email. The turnaround time for the conversion service is approximately two business days upon receipt of the file(s).

Creditor IDA 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)

53

Mandate MigrationExisting 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

MicroenterprisesMicroenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses.

Interchange Fee for Direct DebitsPlease refer to the end of section 2.2.4.

CAI MessageSince 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.

54

2.3.7 Germany

Products in Scope / out of ScopeBulk domestic Euro credit transfers (e.g. DTAUS) will have to be migrated to the SCT. Domestic direct debits (“Einzugs- ermäch tigungslastschrift” and “Abbuchungsauftrag”) will have to be migrated to SDD.

Niche ProductsAs 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 2016. 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 ConversionTo facilitate the automated migration from legacy accountnumbers and bank routing codes to IBAN and BIC, the Germanbanking community has developed a web-based applicationcalled “IBAN-Service-Portal” (see Annex page 73, section 3.3 / 18).

During the registration process, please use the following initialpassword: kzx1u23z

Creditor IDA 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 e-mail.

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 MigrationSince 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).

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:

MicroenterprisesMicroenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses.

Interchange Fee for Direct DebitsPlease refer to the end of section 2.2.4.

COR1 SDD (D-1)This alternative to the Core SDD is planned to be offered for domestic German SDDs from November 2013. 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 1.7.4 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.

DOLOREM AG98765 IRWO

Gläubiger-Identifikationsnummer: DE99 0010 6712 3489 05Mandatsreferenz 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-Zahlungs- verkehrsraums (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: DE45 0123 4567 8901 2345 67BIC: 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üßenDolorem AG, Irwo

Sample letter

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.

56

2.3.8 Hungary

Products in Scope / out of ScopeAs Hungary is a non-Euro country, there are no local products that need to migrate to SEPA.

Niche ProductsAs Hungary is a non-Euro country, there are no local products that need to migrate to SEPA.

IBAN ConversionNo file-based service is available, only an individual solution via this German-language website (see Annex page 73, section 3.3 / 20).

Due to legal reasons, the SDD is not yet available in Hungary.

Creditor IDThis is not applicable, as the SDD is not currently used in Hungary.

Mandate MigrationThis is not applicable, as the SDD is not currently used in Hungary.

MicroenterprisesMicroenterprises 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 DebitsThere is no Multilateral Interchange Fee (MIF) per-item in Hungary.

57

2.3.9 Ireland

Products in Scope / out of ScopeThe 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 ProductsThere are no niche products in Ireland.

IBAN ConversionIf corporates have an account in Ireland, they can use a file-based 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-by-one 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 IDThe 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 MigrationThe 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.

MicroenterprisesMicroenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses.

Interchange Fee for Direct DebitsThere is no interchange fee in Ireland.

Other InformationIt 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.

58

2.3.10 Italy

Products in Scope / out of ScopeIn 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 2016. 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.

Please also refer to section 3.14 for a country-by-country overview of which instruments are in scope, niche and out of scope.

Niche ProductsAs 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 2016. 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 (Fixed-amount RID) fall into this category.

IBAN ConversionThe 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.

59

Creditor IDThe 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 97-10 (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 97-10 algorithm):– The number without the check digit is IT ?? ZZZ

0123456789012345– Take the country-specific part (positions 8 to 23):

0123456789012345– Move the ISO country code and “00” to the right-hand end:

0123456789012345IT00 – 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 = 33

0123456789012345182900 (I = 18, T = 29)– Divide by 97: 0123456789012345182900 / 97 =

1272750402189125596– From this number, determine the full-number difference to

the next smaller multiplier of 97 – 1272750402189125596 * 97 = 123456789012345182812 – 0123456789012345182900 - 123456789012345182812 = 88 – Remainder = 88– Subtract the remainder from 98 to get the check digit:

98 - 88 = 10 In this case the check digit is 10, the full Creditor ID is IT 10 ZZZ 0123456789012345.

The control code is 10, the Creditor ID is IT 10 ZZZ 0123456789012345.

Mandate MigrationExisting 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 2013.

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).

60

MicroenterprisesWhile 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 DebitsPlease refer to the end of section 2.2.4.

SEDAThe 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 non-existing 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 2013 . 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 FacilityAmong 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 SDDAs 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 SDDSome 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 InformationXML mandatory for corporates: postponed until February 2016

61

2.3.11 Luxembourg

Products in Scope / out of ScopeDomestic 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 2008. Domestic direct debits (DOM2009) still have to be migrated to SDD (Core or B2B) by 1 February 2014.

Niche ProductsThere are no niche products in Luxembourg.

IBAN conversionAccounts 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.

Creditor IDIn 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 2010. A Luxembourg CID can therefore be obtained via any bank in Luxembourg:

Example: LU27ZZZ0000000000123456789

– 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.

Mandate MigrationExisting 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).

MicroenterprisesMicroenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses.

Interchange fee for SDDThere is no Multilateral Interchange Fee (MIF) in Luxembourg, neither for legacy direct debits, nor for SDD.

62

2.3.12 Netherlands

Products in Scope / out of ScopeCLIEOP03 (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 ProductsThere 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 ConversionThe 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 2014.

The service can be found on the following website (see Annex page 73, section 3.3 / 25).

Creditor IDIn the Netherlands the Creditor Identifier can be obtained from the creditor bank.

Example: NL97ZZZ123456780001The 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 97-10– 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 MigrationThe 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 BedrijvenIncasso)

Yes No

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.

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.

MicroenterprisesMicroenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses.

Dutch National SEPA Migration siteMore 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 PayrollA 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 DebitsThere is no Multilateral Interchange Fee (MIF) in the Netherlands.

64

2.3.13 Poland

Products in Scope / out of ScopeAs Poland is a non-Euro country, there are no local products that need to migrate to SEPA.

Niche ProductsAs Poland is a non-Euro country, there are no niche products that need to migrate to SEPA.

IBAN ConversionNot applicable: IBANs have already been used for corss-border and domestic transactions for many years.

SDDMost 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 IDNo solution has been developed yet.

Mandate MigrationExisting 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.

MicroenterprisesMicroenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses.

Interchange Fee for Direct DebitsThere is no Multilateral Interchange Fee (MIF) per-item in Poland.

65

2.3.14 Portugal

Products in Scope / out of ScopeDomestic credit transfers and domestic direct debits will have to be migrated to the SEPA Credit Transer and SEPA Direct Debit, respectively.

Niche ProductsAs 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 2016. 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 2013. 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 ConversionIn 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 50 0123 1234 12345678901 34

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.

MicroenterprisesMicroenterprises are treated as consumers, which means the B2B SDD cannot be used to collect from these small businesses.

Mandate MigrationExisting 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 DebitsPlease refer to the end of section 2.2.4.

Other relevant InformationPortugal 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 2013.

66

2.3.15 Slovakia

Products in Scope / out of ScopeLocal credit transfers and local direct debits must be migrated to the SCT and SDD.

Niche ProductsThere are no niche products in Slovakia.

IBAN ConversionInformation 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 UsageBefore 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 MigrationExisting direct debit authorisations will be automatically converted by banks into SDD mandates on 31 January 2014. 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 IDA 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

MicroenterprisesMicroenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses.

Interchange Fee for Direct DebitsThere is no MIF for domestic direct debits. There is also no MIF for SDDs.

67

2.3.16 Spain

Products in Scope / out of ScopeDomestic 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 ProductsAs 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 2016. 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 2013. 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 ConversionTwo 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 IDThe 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

MicroenterprisesMicroenterprises are treated as businesses, which means the B2B SDD can be used to collect from these small businesses.

Interchange Fee for Direct DebitsPlease refer to the end of section 2.2.4.

Mandate MigrationExisting 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 2009.

Central Bank ReportingCentral Bank Reporting will be no longer mandatory from 1 January 2014.

COR1 SDD (D-1)This alternative to the Core SDD is available for domestic Spanish SDDs since July 2013. 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 1.7.4 for additional information.

Other relevant InformationSpain decided on the following possible transitional measures:– XML mandatory for corporates: Postponed to February 2016– Mandatory IBAN: Postponed to February 2016

68

2.3.17 Switzerland

Products in Scope / out of ScopeAs Switzerland is a non-Euro country, there are no local products that need to migrate to SEPA.

Niche ProductsAs Switzerland is a non-Euro country, there are no niche products that need to migrate to SEPA.

IBAN ConversionA 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 self-explanatory, because the BIC can be found in a column next to the bank code (where available).

Creditor IDOn 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.

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).

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 MigrationSDD 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 DebitsThere is no Multilateral Interchange Fee (MIF) per-item in Switzerland.

69

2.3.18 United Kingdom

Products in Scope / out of ScopeAs the UK is a non-Euro country, there are no local legacy instruments that need to migrate to SEPA.

Niche ProductsAs the UK is a non-Euro country, there are no niche legacy instruments that need to migrate to SEPA.

IBAN ConversionIn the UK, the IBAN can be obtained from the counterparty only – it is published on bank statements.

Creditor IDThe 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)

MicroenterprisesMicroenterprises are treated as consumers, which means the B2B SDD cannot be used to collect from these small businesses.

Mandate MigrationThere 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 DebitsInterchange fees are not currently market practice in the UK. There is also no MIF for cross-border SDDs.

70

ABBLAssociation des Banques et Banquiers Luxembourg (Luxembourg Bankers’ Association)

ACH Automated Clearing HouseAP Accounts PayableAR Accounts ReceivableB2B Business to Business

BAIBank Administration Institute (a file format used by banks to transfer financial data)

BDDBusiness Direct Debit (a Swiss direct debit type)

BIC Business Identifier CodeBLZ Bankleitzahl (bank sorting code)BOE Bonifici Esteri (Cross-border credit transfers)CAI Change Account InformationCBR Central-Bank ReportingCET Central European Time

CGICommon Global Implementation (XML standardisation effort)

CID Creditor IDCOT Cut-Off Time

CSVComma-Separated Values (a global file format)

DMF Debtor Mandate Flow

DTIDatenTrägeraustausch Information (German reporting format)

DTAUSDatenTrägeraustausch-Verfahren (German file format)

DTE Datenträger Eilig (domestic urgent payment)EB Electronic BankingEBA European Banking Association

EBICSElectronic Banking Internet Communication Standard

ECB European Central Bank

EDIFACTElectronic Data Interchange For Administration, Commerce and Transport (a global file format)

EEA European Economic Area

ELVElektronisches Lastschriftverfahren (German electronic direct debiting scheme)

EPC European Payments CouncilERP Enterprise Resource PlanningEU European UnionFX Foreign Exchange

HR Human ResourcesHVP High Value PaymentsIBAN International Bank Account NumberIDOC Intermediate Document (a global file format)ISO International Organisation for Standardisation

LSVLastSchriftVerfahren (a Swiss direct debit type)

MIF Multilateral Interchange FeePSD Payment Services DirectivePSP Payment Service ProviderPSU Payment Service User

RIDRimessa Interbancaria Diretta (Italian direct debit)

SCT SEPA Credit TransferSDD SEPA Direct DebitSEDA SEPA Electronic Database AlignmentSEPA Single Euro Payments Area

SIBSSociedade InterBancária de Serviços (Portugese Clearing House)

SLA Service Level AgreementSTP Straight Through Processing

SWIFTSociety for Worldwide Interbank Financial Telecommunication

TARGET2

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)

TWS Treasury WorkstationUK United KingdomVAT Value Added Tax

XMLExtensible Markup Language (a global file format)

XPF Französischer Pazifischer Franc

71

3 Annex

3.1 Abbreviations

72

3.2 Useful Links

1. European Central Bank (ECB) SEPA Indicatorshttp://www.ecb.europa.eu/paym/sepa/about/indicators/html/index.en.html

2. European Payments Council (EPC)http://www.europeanpaymentscouncil.eu/

3. European Payments Council (EPC) - Newsletterhttp://www.europeanpaymentscouncil.eu/newsletter.cfm

4. Deutsche Bank SEPAhttp://www.sepa.gtb.db.com/content/en/841.html

3.3 List of Hyperlinks

1. SWIFT BIC Directoryhttp://www.swift.com/products/bic_directory

2. SWIFT BICPlusIBANhttp://www.swift.com/products/bicplusiban_directory

3. Payment Services Directive (PSD)http://eur-lex.europa.eu/Notice.do?checktexts=checkbox&val=460702:cs&pos=-1&page=1&lang=en&pgs=10&nbl=0&list=&hwords=null&action=GO&visu=

4. Regulation (EC) No 924/2009 http://eur-lex.europa.eu/Result.do?RechType=RECH_celex&code=32009R0924&checktexts=checkbox

5. Regulation (EU) No 260/2012http://eur-lex.europa.eu/Notice.do?checktexts=checkbox&val=672986%3Acs&pos=5&page=1&lang=en&pgs=10&nbl=7&list=673000%3Acs%2C672830%3Acs%2C673001%3Acs%2C672995%3Acs%2C672986%3Acs%2C673024%3Acs%2C672887%3Acs%2C&hwords=&action=GO&visu=%23texte

6. EBA Guidehttps://www.abe-eba.eu/Overview-Documents-N=SEPA_and_PSD_Overview_Documents-L=EN.aspx

7. Simplexhttp://www.simplexgtp.com

8. Sentenialhttp://www.sentenial.com

9. EBA SDD B2B Participants listhttps://www.ebaclearing.eu/SDD-Services-Participants-N=SDD_Core_SDD_B2B-L=EN.aspx

10. ISO 20022http://www.iso20022.org/external_code_list.page 11. EPC’s Guidelines for the Appearance of Mandateshttp://www.europeanpaymentscouncil.eu/knowledge_bank_detail.cfm?documents_id=175

73

12. EPC Core SDD mandate translationshttp://www.europeanpaymentscouncil.eu/content.cfm?page=core_sdd_mandate_transalations

13. EPC B2B SDD mandate translationshttp://www.europeanpaymentscouncil.eu/content.cfm?page=sepa_b2b_dd_mandate_translations

14. EPC Creditor ID Guidehttp://www.europeanpaymentscouncil.eu/knowledge_bank_detail.cfm?documents_id=161

15. Belgian Isabel IBAN and BIC converterhttp://www.sepabelgium.be/fr/bban-iban-bic-converter

16. Czech National Bank – IBAN calculatorhttp://www.cnb.cz/en/payment_systems/iban/ibanen.html

17. Czech National Bank – Creditor IDhttp://www.cnb.cz/en/payment_systems/accounts_bank_codes/rules_rip.html

18. German IBAN-Service-Portalhttps://www.iban-service-portal.de/ibanp/iban/Start

19. German Central Bank – Creditor IDhttp://www.bundesbank.de/Navigation/DE/Kerngeschaeftsfelder/ Unbarer_Zahlungsverkehr/SEPA/Glaeubiger_Identifikationsnummer/glaeubiger_identifikationsnummer.html

20. Hungary – IBAN conversion (German-language website)http://www.easy-web.de/iban/ibangenerator.htm

21. Irish Payment Services Organisation (IPSO)http://www.ipso.ie/section/IPSOSEPAServices

22. IPSO BIC and IBAN converterhttps://ipsosepaservice.sentenial.com/ipso/

23. Luxembourg Bankers’ Associationhttp://www.abbl.lu/dossiers/sepa

24. Luxembourg Bankers’ Association – Mandate Migration http://www.abbl.lu/sites/abbl.lu/files/wysiwyg/Kurt%20Salmon%20-%20ABBL%20-%20Migration%20to%20SDD%20-%20Deliverable%202%20for%20PSUs%20v1%202-7.pdf

25. Netherlands – IBAN Conversion Servicehttps://www.ibanbicservice.nl

26. Netherlands – SEPA Migration websitehttp://www.overopiban.nl

27. Netherlands – Direct Debit Migration Guidehttp://www.betaalvereniging.nl/wp-uploads/2012/09/Stappenplan-Van-de-huidige-Nederlandse-incasso-naar-de-zakelijke-Europese-incasso.pdf

28. SEPA DD Creditor Identifier Validatorhttp://www.maric.info/fin/SEPA/ddchkden.htm

29. National Bank of Slovakia – IBAN-conversionhttp://www.nbs.sk/en/payment-systems/iban

30. Slovak Banking Association (SBA)http://www.sbaonline.sk

31. Spain – IBAN Conversionwww.sepaesp.es/herramienta/conversion.htm

32. Spain – Creditor IDwww.maric.info/fin/SEPA/ddchkden.htm

33. Switzerland SIX-Group online IBAN-Conversion toolhttp://www.six-interbank-clearing.com/en/home/standardization/iban/inquiry-iban.html

34. Switzerland SIX-Group IBAN softwarehttp://www.six-interbank-clearing.com/en/home/standardization/iban/iban-tool.html

35. Switzerland SIX-Group BIC toolhttp://www.six-interbank-clearing.com/en/home/bank-master-data/download-bc-bank-master.html

36. SIX Interbank Clearing Ltdhttp://www.sepa.ch/en/home/direct-debits/creditor-identifier.html

37. EBA Clearing – Guidance on the handling of SDD R-transactions and related charging principleshttp://www.abe-eba.eu/N=SMART.aspx

3.4 Payment Factory Brochure

Deutsche BankGlobal Transaction Banking

The Road to European Payment/ Collection Factories

2

Definitions and BenefitsShared-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.

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?

A Shared-Service Center is an accountable entity within a multi-unit 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 labour-intensive processes. Likewise, Collection Factories are centralised collections-processing centers that are focused on the accounts-receivable function.

Shared-Service Center

In-House Bank

Payment/ Collection Factory

Chart 1: Definitions of Shared-Service Center, In-House Bank and Payment/Collection Factory

3

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.

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.

DriversThis 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 ManagementThe 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 project-management 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)

Risk Control

Cos

t Red

uct

ion

Chart 2: The Evolution of Payment/Collection Factories

1 gtnews Payments Survey info from 2010

Collections “on behalf of”

Expansion of in-house banks toinclude Payment Factories

Expansion of Payment Factories to include Collection Factories

Payments “on behalf of”

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

SEPA

4

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?

Data Collection and AnalysisAs 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)

5

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?

6

Senior Management Buy-inHaving 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):

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?

SLAs

File Transfer

Authorisation

Feedback-File Transfer

Account- Statement Transfer

Sub 1

Sub 2

Sub 3

Sub 4

DB Systems Clearing

ACH

HVP

Cheque

Manual or automated

DB’s Global Centralisation SolutionBusiness Units

MT 940 MT 942

BAI

ERP/TWS/SAP

Local Format, XML,

EDIFACT, CSV, IDOC,

MT 101

Payment/CollectionFactory

IT & Ops Services Vendor Mgmt

EBICS

db direct internet HTTPS

direct connect e.g. HTTPS/AS2

SWIFT FileActMA-CUG and

SCORE

Chart 4: The Flow of Payments/Collections in a Payment-/Collection-Factory Structure

Chart 5: Strategic and Tactical Questions to ask when planning a Payment/Collection Factory (Part 2)

7

Creation of business case

Optimisation of Payment Authorisation

Format Standardisation

Bank connectivity supporting large file sizes

Bank and Account concentration

Cash Pooling (local and international)

Standardisation of ERP systems

= Part of Deutsche Bank services

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 helpThe 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

www.db.com/gtbgtb.marketing@db.com

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

83

3.5 Availability of local IBAN Conversion Services in Europe

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 (DeutscheBankCustomer@AccuitySolutions.com) offer conversion services for multiple countries.

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-to-end process generally does not take longer than two weeks.

The service is described on the following website: http://www.sepabelgium.be/fr/bban-iban-bic-converter

There, a detailed user manual and the conversion tool can be downloaded.

http://www.cnb.cz/en/payment_systems/iban/ibanen.html

Clients can e-mail 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 e-mail. 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.

84

IBAN Conversion Overview

Germany Hungary Italy Netherlands Poland

How to get the IBAN / BIC

Via BV Zahlungssysteme Only individually via calculation

Via your local Deutsche Bank Implementation & Service team

Via Stichting IBAN Service

Not applicable

Service description

Companies need to register on the website (German language only) of BV Zahlungssysteme: https://www.iban-service-portal.de /ibanp/iban/StartThe 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 email. 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 100.000 items, plus VAT.

Only an individual solution via this German-language website:http://www.easy-web.de/iban/ibangenerator.htm

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.

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.

IBAN has already been standard practice for cross-border 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 (DeutscheBankCustomer@AccuitySolutions.com) offer conversion services for multiple countries.

85

IBAN Conversion Overview

Portugal Spain Switzerland UK

How to get the IBAN / BIC

Via Calculation Via your local Deutsche Bank Implementation & Service team

Via SIX Interbank Clearing The IBAN can be obtained from the counterparty via their bank only – it is published on bank statements.

Service description

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).

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:http://www.sepaesp.es/herramienta/conversion.htmThe 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

A file-based solution does not exist in CH. SIX-Group offers an online tool: http://www.six-interbank-clearing.com/en/home/standardization/iban/inquiry-iban.htmlThey also offer to download a small software:http://www.six-interbank-clearing.com/en/home/standardization/iban/iban-tool.htmlThis 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):http://www.six-interbank-clearing.com/en/home/bank-master-data/download-bc-bank-master.html

Currently, no industry-wide IBAN-conversion 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 (DeutscheBankCustomer@AccuitySolutions.com) offer conversion services for multiple countries.

3.6 Overview of IBAN-Conversion Offering by Accuity

PAYMENTS

Improve payment effi ciencyWith the introduction of SEPA, corporates have an opportunity to benefi t from lower payment operations costs. However, this means payment instructions must contain a valid International Bank Account Number (IBAN) and Bank Identifi er Code (BIC).

The benefi tsBy 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 benefi ts:

Lower bank charges: • Decreased return fees.

Improved effi ciency:• Fewer manual repairs.

Better customer service:• Your vendors, partners and employees will get paid on time.

The challengeIn 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 solutionAccuity provides a range of payment solutions to help you effi ciently update all your vendor, client and payroll bank records and obtain valid IBAN and BIC information. You can choose which solution best fi ts 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.

PAYMENTS

Access Online Data CleanseAccess Online Data Cleanse

Payment Solutions

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.

IBAN Conversion IBAN Validation PLUS a Connected BIC

For All SEPA Countries.

IBAN BIC STP+IBAN +IBAN BIC STP=BIC STP

Payment Solutions for Corporate Treasury

To discuss your requirements, please contact: TBD by BNP Paribas

©2010 Accuity, Inc. All rights reserved. 04.14.10

Beijing · Chicago · Dubai · Hong Kong · London · New York · Rome · San Diego · Sydney

Payment Solutions for Corporate Treasury

Comprehensive reports keep you informed and focused

Maintenance

Validationand

Clean-Up

Look-Up

Conversion

Only Accuity has the following strategic partnerships:

Accuity is the official registrar of American Bankers Association routing numbers.

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 provider of the Irish Payments Services Organisation’s directory of National Sort Code database.

Comprehensive solutions to fit your business needsAccuity’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.

About Accuity

DeutscheBankCustomer@AccuitySolutions.com

88

3.7 Overview of Member State Options

Use of Member State Options of Regulation 260/2012

Source: http://www.ecb.europa.eu/paym/sepa/about/countries/html/index.en.html (tab “Fact Sheets on Regulation No 260/2012”), as of 27 February 2013 1 = Publication date of the national fact sheet

End dates Euro area Member States

Austria21 January 2013

Belgium22 February 2013

Cyprus21 January 2013

Estonia1 February 2013

Finland12 September 2012

Article 6.4End date for credit transfers in Euro area Member States earlier than 1 Feb. 2014?

No No No No YesOctober 2011 (for B2B), December 2011 (for C2B)

Article 6.4End date for direct debits in Euro area Member States earlier than 1 Feb. 2014?

No No No No No

Article 8.1Multilateral interchange fees for national direct debits until 1 Feb. 2017?

No Yes N.A. No No

Conversion services and waivers

Article 16.1Are PSPs allowed to offer consumers conversion services to IBAN for national transactions until 1 Feb. 2016?

No No Yes YesFirst conversion period of 12 months, if necessary further extension of up to 12 months

YesThe end date for this has not been specified, yet

Article 16.3Is there a waiver until 1 Feb. 2016 for niche products?

YesOne product (credit transfer) concretely planned: image of the customer ‘s paper instruction form is forwarded along with the payment order

No YesBusiness continuity national scenario for credit transfers – government credit transfers

N.A. No

Article 16.4Is there a waiver until 1 Feb. 2016 for card payments resulting in a direct debit?

YesFor the electronic direct debit scheme “Elektronisches Lastschriftverfahren”

No N.A. N.A. No

Article 16.5Is there a waiver until 1 Feb. 2016 for use of the ISO 20022 XML format for individual credit transfers or bundled direct debits in batches?

No No Yes YesFirst conversion period of 12 months, if necessary further extension of up to 12 months

No

Article 16.6Is there a waiver until 1 Feb. 2016 allowing continued use of the PSP’s BIC for national credit transfers?

No No Yes No No

Article 16.6Is there a waiver until 1 Feb. 2016 allowing continued use of the PSP’s BIC for national direct debits?

No No Yes No No

89

Source: http://www.ecb.europa.eu/paym/sepa/about/countries/html/index.en.html (tab “Fact Sheets on Regulation No 260/2012”), as of 27 February 2013 1 = Publication date of the national fact sheet

End dates Euro area Member States

France26 February 2013

Germany12 September 2012

Greece25 February 2013

Ireland21 February 2013

Italy25 February 2013

Article 6.4End date for credit transfers in Euro area Member States earlier than 1 Feb. 2014?

No No No No No

Article 6.4End date for direct debits in Euro area Member States earlier than 1 Feb. 2014?

No No No No No

Article 8.1Multilateral interchange fees for national direct debits until 1 Feb. 2017?

YesBut French banks have decided to abandon MIF already from September 2013

No N.A. N.A. NoOnly allowed until 1 February 2014

Conversion services and waivers

Article 16.1Are PSPs allowed to offer consumers conversion services to IBAN for national transactions until 1 Feb. 2016?

No Yes Yes No NoMigration to IBAN is complete

Article 16.3Is there a waiver until 1 Feb. 2016 for niche products?

YesInterbank payment orders (“TIP”) until 1 Feb. 2016; electronic payment orders (“Télé-règlement”) until 1 Feb. 2016

No Yes No Yes“RID finanziari” and “Rid a importo fisso”

Article 16.4Is there a waiver until 1 Feb. 2016 for card payments resulting in a direct debit?

No YesFor the electronic direct debit scheme “Elektron isches Lastschrift verfahren (ELV)”

No No No

Article 16.5Is there a waiver until 1 Feb. 2016 for use of the ISO 20022 XML format for individual credit transfers or bundled direct debits in batches?

No No Yes No Yes

Article 16.6Is there a waiver until 1 Feb. 2016 allowing continued use of the PSP’s BIC for national credit transfers?

No No Yes Yes No

Article 16.6Is there a waiver until 1 Feb. 2016 allowing continued use of the PSP’s BIC for national direct debits?

No No Yes Yes No

90

Source: http://www.ecb.europa.eu/paym/sepa/about/countries/html/index.en.html (tab “Fact Sheets on Regulation No 260/2012”), as of 27 February 2013 1 = Publication date of the national fact sheet

End dates Euro area Member States

Luxembourg12 September 2012

Malta7 February 2013

Netherlands25 February 2013

Portugal14 January 2013

Slovakia13 February 2013

Article 6.4End date for credit transfers in Euro area Member States earlier than 1 Feb. 2014?

No No No No No

Article 6.4End date for direct debits in Euro area Member States earlier than 1 Feb. 2014?

No No No No No

Article 8.1Multilateral interchange fees for national direct debits until 1 Feb. 2017?

N.A. N.A.There is no legacy direct debit scheme

No NoAligned with cross-border direct debits, i.e. abolished from 1 Nov. 2012

No

Conversion services and waivers

Article 16.1Are PSPs allowed to offer consumers conversion services to IBAN for national transactions until 1 Feb. 2016?

No official information has been published

No No Not yet decided YesUntil 1 February 2016

Article 16.3Is there a waiver until 1 Feb. 2016 for niche products?

No official information has been published

No No Not yet decided N.A.

Article 16.4Is there a waiver until 1 Feb. 2016 for card payments resulting in a direct debit?

No official information has been published

No No No N.A.

Article 16.5Is there a waiver until 1 Feb. 2016 for use of the ISO 20022 XML format for individual credit transfers or bundled direct debits in batches?

No official information has been published

No No No YesUntil 1 February 2016

Article 16.6Is there a waiver until 1 Feb. 2016 allowing continued use of the PSP’s BIC for national credit transfers?

No official information has been published

YesMalta intends to apply this derogation until 1 Feb. 2016

No Not yet decided No

Article 16.6Is there a waiver until 1 Feb. 2016 allowing continued use of the PSP’s BIC for national direct debits?

No official information has been published

YesMalta intends to apply this derogation until 1 Feb. 2016

No Not yet decided No

91

Source: http://www.ecb.europa.eu/paym/sepa/about/countries/html/index.en.html (tab “Fact Sheets on Regulation No 260/2012”), as of 27 February 2013 1 = Publication date of the national fact sheet

End dates Euro area Member States

Slovenia11 February 2013

Spain25 February 2013

Article 6.4End date for credit transfers in Euro area Member States earlier than 1 Feb. 2014?

Yes31 December 2011

No

Article 6.4End date for direct debits in Euro area Member States earlier than 1 Feb. 2014?

Yes31 December 2012

No

Article 8.1Multilateral interchange fees for national direct debits until 1 Feb. 2017?

No No

Conversion services and waivers

Article 16.1Are PSPs allowed to offer consumers conversion services to IBAN for national transactions until 1 Feb. 2016?

No Yes

Article 16.3Is there a waiver until 1 Feb. 2016 for niche products?

No Yes

Article 16.4Is there a waiver until 1 Feb. 2016 for card payments resulting in a direct debit?

No No

Article 16.5Is there a waiver until 1 Feb. 2016 for use of the ISO 20022 XML format for individual credit transfers or bundled direct debits in batches?

No Yes

Article 16.6Is there a waiver until 1 Feb. 2016 allowing continued use of the PSP’s BIC for national credit transfers?

No No

Article 16.6Is there a waiver until 1 Feb. 2016 allowing continued use of the PSP’s BIC for national direct debits?

No No

3.8 Overview of XML-Conversion Offering by Simplex

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 format-conversion 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.

BenefitsBy 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

Global Mandate Management. Total Control.Simplex Mandate Manager™ delivers powerful SEPA Direct Debit solutions for Corporate customers.

Mandate Management Solutions

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 EngineFully 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 format-conversion 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 TransfersThe 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 award-winning 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: deutschebankcustomer@simplexgtp.com

SIMPLEXGTP

© Simplex GTP Limited 2012. 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

simplexgtp.com

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)20 7776 6400 | info@simplexgtp.com

3.9 Overview of XML-Conversion Offering by Sentenial

Origix CorporateA complete corporate solution for both SEPA Direct Debits/ Credit Transfers

www.sentenial.com

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. Bene�ciary bank accounts can be speci�ed 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 reachableunder SEPA. This ensures that paymentscan 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 DEBITSentenial’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 bene�ts 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 followingfeatures:

• Support for transaction �les 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, �le 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 indepen-dent but interconnected modules whichcan be deployed as required, to minimisecost 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 noti�cation 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 demateriali-sation and digitizing newly signed mandates

MODULE 2- MANDATE MANAGEMENTWith Origix Corporate you can create and archive new mandates, including paper mandates and amend existing mandates.

Origix Corporate o�ers 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 2006.

We are the trusted choice of leading European banks and corporate customers.

Mandate Migration

Mandate Management

SDD Transaction Processing

SCT Transaction Processing

CORPORATE

LEGACY ORIGINATION

LEGACY FILES

LEGACY

R TRANSACTIONS

DAILY

RECONCILIATION REPORTING

ORIGINATING BANK

BANK

ISO XMLFORMAT

ISO XML FORMAT

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

• 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

Mandates can be created and sent toyour 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 PROCESSINGSEPA compliance is compulsory for all direct debits and credit transfers, but existing �nancial 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) �le 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 �at �le formats.

Origix Corporate provides the following services as part of the Transaction Processing Module:

• Support for transaction �les 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 '�re drill' by taking action NOW

Phone: +353 1629 2141 E: dbcustomer@sentenial.com W:www.sentenial.com © Sentenial 2012

Origix CorporateA complete corporate solution for SEPA Direct Debits/ Credit Tansfers

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

Table 1 shows the national legacy formats supported, with more regularly added.

• MIS Reporting on mandates

3.10 XML checker

98

3.11 Country-by-country overview of how to obtain the Creditor ID

Country Example Positions

1–2 3–4 5–7 Variables

Austria AT97ZZZ01234567890 AT ## ZZZ 8: Fixed value “0”9 –18: Counter with leading zeroes

Belgium BE68ZZZ0123456789 BE ## ZZZ 8 –17: Enterprise No. (VAT No.)

Czech Republic

CZ97ZZZnnnnn CZ ## ZZZ 8 –12: Number from 10000 to 99999

France FR12ZZZ123456 FR ## ZZZ 8 –13: Identifiant Créancier SEPA

Germany DE97ZZZ12345678901 DE ## ZZZ 8 –18: Consecutive number

Italy IT97ZZZA1B2C3D4E5F6G7H8 IT ## ZZZ 8 – 23: National fiscal code

IT97ZZZ00000D4E5F6G7H8 IT ## ZZZ 8 –13: Filled with “00000”14 – 23: VAT number / temporary fiscal

code

Netherlands NL97ZZZ123456780001 NL ## ZZZ 8 –15: Trade Register Number (KvK number)

16 –19: Numerical code

Poland PL97ZZZ0123456789 PL ## ZZZ 8 –17: Tax Number (called NIP)

PL97ZZZ0123456789 PL ## ZZZ 8 –17: NIW (artificial NIP)

Portugal PT97ZZZ123456 PT ## ZZZ 8 –13: Creditor specific identifier

Spain ES97ZZZM23456789 ES ## ZZZ 8 –16: NIF (Número de Identificación Fiscal) for legal entities

ES97ZZZM23456790 ES ## ZZZ 8 –16: DNI (Documento Nacional de Identidad) or NIF (Número de Identificación Fiscal) for individuals

ES97ZZZM23456791 ES ## ZZZ 8 –16: NIE (Número de Identidad de Extranjero) for foreign individuals

Switzerland CH0712300000012345 CH ## ZZZ 8 –18: Ascending number filled with leading zeroes

United Kingdom GB39ZZZDDDEUT0000000123456 GB ## ZZZ 8 –10: Scheme Code i.e. SDD11–14: First 4 characters of creditor

bank’s BIC15 – 20: Bacs’ Service User Number

(SUN) or 6 zeroes in the absence of a Bacs’ SUN

21 – 27: Determined by creditor bank

99

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.

Country Issuer How to obtain it

Austria Austrian National Bank Via local Deutsche Bank Implementation & Service

Belgium Federal Public Service (Ministry) Economy

Via local Deutsche Bank Implementation & Service

Czech Republic Czech National Bank Via local Deutsche Bank Implementation & Service

France French Central Bank (Banque de France)

Via local Deutsche Bank Implementation & Service

Germany Deutsche Bundesbank Via website of Deutsche Bundesbank:www.bundesbank.de/Navigation/DE/Kerngeschaeftsfelder/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 NIP)

Customers to compute based on their NIP (or NIW if no NIP exists)

Customers to compute (based on their NIW)

Portugal SIBS (Portuguese ACH) Creditor should contact SIBS via email: sac.suporte@sibs.pt

Spain Agencia Tributaria Creditor to compute themselves. The following website can be used:www.maric.info/fin/SEPA/ddchkden.htm

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

3.12 Overview of XML Reference Fields

Deutsche BankGlobal Transaction Banking

SEPA Reference Mapping

With the use of the XML, SEPA format-dedicated 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

Definition of XML References

PaymentInformationIdentificationUnique identification assigned by the sending Party, to identify the Payment Information Group (Batch) within the message.

InstructionIdentificationUnique 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.

EndToEndReferenceUnique 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 end-to-end identification can be used for reconciliation or to link tasks relating to the transaction.

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.

RemittanceInformationInformation 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 20022 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.

Think SEPA. Think Deutsche.

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:IT70X0626070080000123406C00BIC: CRFIIT3PXXX

XML Tag Code Ebene Remarks

PaymentInformationIdentification

KREF+ Batch Sender Reference (max. 35 characters) serves for identification on the account statement

InstructionIdentification

KREF+ Transaction Sender Reference (max. 35 characters) serves for identification on the account statement

EndtoEndIdentification

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

RemittanceInformation

SVWZ+ Transaction Max. 140 characters / one line (Harmonisation across all SEPA Countries)

3.13 Additional details about the Pre-notification

Deutsche BankGlobal 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 pre-notification, 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.

MortgagesInstallment plan for the life time of the multi-year contract, which contains – Due dates– Amount per due date

Monthly downpayment for utilities, taxAnnual overview of monthly / quarterly down payments specifying – Due dates– Amount per due date

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.

Mandatory Elements Explanations

Name and address of the debtor 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.

Mandate reference These details will allow the debtor to align the pre-notification with debit on his account.

The amount of the direct debit

The due date of the direct debit – 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).

Telephone billsMonthly 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.

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 pre-notification 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.

Think SEPA. Think Deutsche.

3.14 End Date for European Payment Instruments

Deu

tsch

e B

ank

Glo

bal

Tra

nsa

ctio

n B

anki

ng

End

Dat

e fo

r Eur

opea

n Pa

ymen

t Ins

trum

ents

Eu

rop

ean

Pa

ymen

t S

cop

e p

er C

ou

ntr

y

In S

cop

e (F

ebru

ary

2014

)N

ich

e P

rod

uct

s (F

ebru

ary

2016

)O

ut

of

Sco

pe

Paym

ents

Dir

ect

Deb

its

Au

stri

a–

Dom

estic

Paym

ents

(V3)

– Ein

zug

serm

äch

tig

un

g (V

3)–

Ab

bu

chu

ng

sau

ftra

g (V

3)–

ATI

B R

ecei

vab

les

– P

OS

/ ATM

Dir

ect

Deb

its

– U

rgen

t D

om

estic

Paym

ents

(V3)

– C

ross

-Bord

er P

aym

ents

(V3)

Bel

giu

m–

Dom

estic

AC

H P

aym

ents

(A

BB

/BV

B L

ayou

t 12

8)–

Cro

ss-B

ord

er P

aym

ents

(AB

B/B

VB

Lay

ou

t 12

8) in

Eu

ro w

ith

in S

EPA

– D

om

estic

Dir

ect

Deb

its

(A

BB

/BV

B L

ayou

t 12

8-D

OM

80)

Non

e–

Urg

ent

Dom

estic

Paym

ents

(AB

B/B

VB

Lay

ou

t 12

8)–

Urg

ent

Cro

ss-B

ord

er P

aym

ents

(AB

B/B

VB

Lay

ou

t 12

8)–

Bill

s of

Exc

han

ge

– C

ross

-Bord

er P

aym

ents

in N

on

-Eu

ro C

urr

ency

or

ou

tsid

e S

EPA

(AB

B/B

VB

Lay

ou

t 12

8)

Fran

ce–

Dom

estic

AC

H P

aym

ents

(CFO

NB

160

)–

Cro

ss-B

ord

er P

aym

ents

(CFO

NB

320

)in

Eu

ro w

ith

in S

EPA

– D

om

estic

AC

H D

irec

t D

ebit (C

FON

B 1

60)

– TI

P (n

on

-pre

-au

thori

sed

d

irec

t d

ebits)

– Té

lére

gle

men

t

– U

rgen

t D

om

estic

Paym

ents

(CFO

NB

160

) –

Urg

ent

Cro

ss-B

ord

er P

aym

ents

(CFO

NB

320

)–

LCR

– B

ills

of

Exc

han

ge

– C

ross

-Bord

er P

aym

ents

in N

on

-Eu

ro C

urr

ency

or

ou

tsid

e S

EPA

(CFO

NB

320

)–

Ele

ctro

nic

mon

ey (k

ind

of

pre

-pai

d c

ard

)

Ger

man

y–

Dom

estic

Paym

ents

(DTA

US

)–

Ein

zug

serm

äch

tig

un

g (D

TAU

S)

– A

bb

uch

un

gsa

uft

rag

(DTA

US

)–

PO

S D

irec

t D

ebits-

ELV

(D

TAU

S)

– U

rgen

t D

om

estic

Paym

ent

(DTA

US

/DTE

)–

Urg

ent

Cro

ss-B

ord

er (D

TAZV

/EU

E )

Ital

y–

Dom

estic

AC

H P

aym

ents

-BO

N (C

BI-

BO

N)

– C

ross

-Bord

er P

aym

ents

-BO

E (C

BI-

BO

NE)

in E

uro

with

in S

EPA

– S

tan

dar

d R

ID-R

ID O

rdin

ario

/Fas

t R

ID-R

ID

Vel

oce

(CB

I-R

ID)

– Fi

nan

cial

RID

-RID

Fi

nan

ziar

io/F

ixed

-am

ou

nt

RID

-RID

a Im

port

o F

isso

(C

BI-

RID

)

– R

IBA

(CB

I-R

IB)

– M

AV

/RA

V (C

BI-

MA

V)

– B

olle

ttin

o B

anca

rio (C

BI-

BO

B)

– B

ills

of

Exc

han

ge

– H

igh

Val

ue

Dom

estic

Paym

ents

-BIR

(CB

I-B

ON

)–

Cro

ss-B

ord

er P

aym

ents

-BO

E (C

BI-

BO

NE) i

n N

on

-Eu

ro C

urr

ency

or

ou

tsid

e S

EPA

– Ta

x Pa

ymen

ts-F

24 (C

BI-

F24)

Net

her

lan

ds

– D

om

estic

AC

H P

aym

ents

(CLI

OP

03)

– Eu

ro A

ccep

tgir

o (D

utc

h P

aper

Colle

ctio

n

Met

hod

usi

ng

an

OC

R F

orm

)–

iDEA

L (N

atio

nal

ePa

ymen

t S

chem

e)

– R

ecu

rren

t G

ener

al D

irec

t D

ebits

(CLI

OP

03)

– R

ecu

rren

t B

usi

nes

s D

irec

t D

ebit (C

LIO

P03

)–One-OffDirectDebit(CLIOP03)

– G

ames

of

Ch

ance

(CLI

OP

03)

– P

hon

e M

and

ate

Dir

ect

Deb

it (C

LIO

P03

)

Non

e–

Urg

ent

Dom

estic

(BTL

91)

– U

rgen

t C

ross

-Bord

er (B

TL91

)–

Norm

al C

ross

-Bord

er (B

TL91

)

Port

ug

al–

Dom

estic

pay

men

ts (P

S2)

– D

om

estic

Dir

ect

Deb

its

(ED

R)

Non

eN

on

e

Sp

ain

– D

om

estic

pay

men

ts (C

SB

34 a

nd

CS

B34

-1)

– D

om

estic

Dir

ect

Deb

its

(CS

B19

)–

Cre

dit A

dva

nce

s (C

SB

58)

– B

ill o

f Exc

han

ge

&

Pro

mis

sory

Note

s (C

SB

32)

–Confirming(FinancialSupplyChain)

Thes

e d

ocu

men

ts m

ay n

ot b

e re

pro

du

ced

, dis

trib

ute

d o

r oth

erw

ise

use

d w

ith

ou

t pre

viou

s au

thori

sation

. Th

is s

ervi

ce d

escr

iption

is fo

r in

form

atio

n p

urp

ose

s on

ly a

nd

pro

vid

es a

gen

eral

ove

rvie

w o

f th

e ra

ng

e of s

ervi

ces

off

ered

by

Glo

bal

Tra

nsa

ctio

n B

anki

ng

of D

euts

che

Ban

k A

G. T

he

gen

eral

info

rmat

ion

p

rovi

ded

in th

is s

ervi

ce d

escr

iption

is b

ased

on

Glo

bal

Tra

nsa

ctio

n B

anki

ng

Ser

vice

s as

they

may

be

off

ered

to c

lien

ts o

n th

e d

ate

this

ser

vice

des

crip

tion

was

pu

blis

hed

in S

epte

mb

er 2

013.

Th

is

info

rmat

ion

is s

ub

ject

to c

han

ge.

Th

is p

rese

nta

tion

an

d th

e g

ener

al in

form

atio

n o

n th

e se

rvic

es o

ffer

ed b

y G

lob

al T

ran

sact

ion

Ban

kin

g m

erel

y se

rve

as a

n il

lust

ration

; no c

on

trac

tual

or n

on

-con

trac

tual

ob

ligat

ion

s on

the

par

t of D

euts

che

Ban

k A

G o

r its

su

bsi

dia

ries

, or l

iab

ility

cla

ims

agai

nst

Deu

tsch

e B

ank

AG

or i

ts s

ub

sid

iari

es, c

an b

e d

eriv

ed fr

om

them

. C

op

yrig

ht ©

Sep

tem

ber

201

3 D

euts

che

Ban

k A

G. A

ll ri

gh

ts re

serv

ed.

RZ_

Bros

chue

re_E

nd D

ate

for E

urop

ean

Paym

ent I

nstru

men

ts_A

4_E_

1309

05.in

dd

105

.09.

13

10:0

3

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

103

3.15 Index

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.

www.db.com / gtbgtb.marketing@db.com

Deutsche BankGlobal Transaction Banking

End Date for European Payment Instruments

European Payment Scope per Country

In Scope (February 2014) Niche Products (February 2016)

Out of Scope

Payments Direct Debits

Austria – Domestic Payments (V3) – Einzugsermächtigung (V3)– Abbuchungsauftrag (V3)

– ATIB Receivables – POS/ ATM Direct Debits

– Urgent Domestic Payments (V3)– Cross-Border Payments (V3)

Belgium – Domestic ACH Payments (ABB/BVB Layout 128)

– Cross-Border Payments (ABB/BVB Layout 128) in Euro within SEPA

– Domestic Direct Debits (ABB/BVB Layout 128-DOM80)

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)

France – Domestic ACH Payments (CFONB 160)– Cross-Border Payments (CFONB 320)in

Euro within SEPA

– Domestic ACH Direct Debit (CFONB 160) – TIP (non-pre-authorised direct debits)

– Téléreglement

– 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)

Germany – Domestic Payments (DTAUS) – Einzugsermächtigung (DTAUS)– Abbuchungsauftrag (DTAUS)

– POS Direct Debits-ELV (DTAUS)

– Urgent Domestic Payment (DTAUS/DTE)– Urgent Cross-Border (DTAZV/EUE )

Italy – Domestic ACH Payments-BON (CBI-BON)– Cross-Border Payments-BOE (CBI-BONE)

in Euro within SEPA

– Standard RID-RID Ordinario/Fast RID-RID Veloce (CBI-RID)

– Financial RID-RID Finanziario/Fixed-amount RID-RID a Importo Fisso (CBI-RID)

– 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)

Netherlands – Domestic ACH Payments (CLIOP03)– Euro Acceptgiro (Dutch Paper Collection

Method using an OCR Form)– iDEAL (National ePayment Scheme)

– Recurrent General Direct Debits (CLIOP03)– Recurrent Business Direct Debit (CLIOP03)–One-OffDirectDebit(CLIOP03)– Games of Chance (CLIOP03)– Phone Mandate Direct Debit (CLIOP03)

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(FinancialSupplyChain)

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 2013. 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.

Deutsche BankGlobal Transaction Banking

Your Name Name of Debtor

Your Address Street and Number

ZIP and City

Country

Your Account Number IBAN

Bank (Name)

and (SWIFT BIC)

Name of Creditor Name of Creditor

Creditor ID

Street and Number

ZIP and City

Country

Creditor ID *

Contract Data

Type of Payment Recurrent payment or One-off payment

City, Date

Signature

SEPA Business-to-Business Direct Debit Mandate

Mandate Reference *

Please return to: Name of Creditor

Street and Number

ZIP and City

* Mandate References may not exceed 35 characters and must consist of the following characters only: A-Z, a-z, 0-9 / - ?: ( ) . , ’+

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.

Creditor’s use only

Deutsche BankGlobal 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 pre-notification, 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.

MortgagesInstallment plan for the life time of the multi-year contract, which contains – Due dates– Amount per due date

Monthly downpayment for utilities, taxAnnual overview of monthly / quarterly down payments specifying – Due dates– Amount per due date

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.

Mandatory Elements Explanations

Name and address of the debtor 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.

Mandate reference These details will allow the debtor to align the pre-notification with debit on his account.

The amount of the direct debit

The due date of the direct debit – 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).

Telephone billsMonthly 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.

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 pre-notification 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.

Think SEPA. Think Deutsche.

PAYMENTS

Improve payment effi ciencyWith the introduction of SEPA, corporates have an opportunity to benefi t from lower payment operations costs. However, this means payment instructions must contain a valid International Bank Account Number (IBAN) and Bank Identifi er Code (BIC).

The benefi tsBy 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 benefi ts:

Lower bank charges: • Decreased return fees.

Improved effi ciency:• Fewer manual repairs.

Better customer service:• Your vendors, partners and employees will get paid on time.

The challengeIn 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 solutionAccuity provides a range of payment solutions to help you effi ciently update all your vendor, client and payroll bank records and obtain valid IBAN and BIC information. You can choose which solution best fi ts 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.

PAYMENTS

Access Online Data CleanseAccess Online Data Cleanse

Payment Solutions

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.

IBAN Conversion IBAN Validation PLUS a Connected BIC

For All SEPA Countries.

IBAN BIC STP+IBAN +IBAN BIC STP=BIC STP

Payment Solutions for Corporate Treasury

To discuss your requirements, please contact: TBD by BNP Paribas

©2010 Accuity, Inc. All rights reserved. 04.14.10

Beijing · Chicago · Dubai · Hong Kong · London · New York · Rome · San Diego · Sydney

Payment Solutions for Corporate Treasury

Comprehensive reports keep you informed and focused

Maintenance

Validationand

Clean-Up

Look-Up

Conversion

Only Accuity has the following strategic partnerships:

Accuity is the official registrar of American Bankers Association routing numbers.

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 provider of the Irish Payments Services Organisation’s directory of National Sort Code database.

Comprehensive solutions to fit your business needsAccuity’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.

About Accuity

DeutscheBankCustomer@AccuitySolutions.com

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 format-conversion 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.

BenefitsBy 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

Global Mandate Management. Total Control.Simplex Mandate Manager™ delivers powerful SEPA Direct Debit solutions for Corporate customers.

Mandate Management Solutions

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 EngineFully 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 format-conversion 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 TransfersThe 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 award-winning 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: deutschebankcustomer@simplexgtp.com

SIMPLEXGTP

© Simplex GTP Limited 2012. 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

simplexgtp.com

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)20 7776 6400 | info@simplexgtp.com

Deutsche BankGlobal Transaction Banking

The Road to European Payment/ Collection Factories

2

Definitions and BenefitsShared-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.

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?

A Shared-Service Center is an accountable entity within a multi-unit 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 labour-intensive processes. Likewise, Collection Factories are centralised collections-processing centers that are focused on the accounts-receivable function.

Shared-Service Center

In-House Bank

Payment/ Collection Factory

Chart 1: Definitions of Shared-Service Center, In-House Bank and Payment/Collection Factory

3

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.

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.

DriversThis 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 ManagementThe 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 project-management 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)

Risk Control

Cos

t Red

uct

ion

Chart 2: The Evolution of Payment/Collection Factories

1 gtnews Payments Survey info from 2010

Collections “on behalf of”

Expansion of in-house banks toinclude Payment Factories

Expansion of Payment Factories to include Collection Factories

Payments “on behalf of”

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

SEPA

4

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?

Data Collection and AnalysisAs 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)

5

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?

6

Senior Management Buy-inHaving 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):

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?

SLAs

File Transfer

Authorisation

Feedback-File Transfer

Account- Statement Transfer

Sub 1

Sub 2

Sub 3

Sub 4

DB Systems Clearing

ACH

HVP

Cheque

Manual or automated

DB’s Global Centralisation SolutionBusiness Units

MT 940 MT 942

BAI

ERP/TWS/SAP

Local Format, XML,

EDIFACT, CSV, IDOC,

MT 101

Payment/CollectionFactory

IT & Ops Services Vendor Mgmt

EBICS

db direct internet HTTPS

direct connect e.g. HTTPS/AS2

SWIFT FileActMA-CUG and

SCORE

Chart 4: The Flow of Payments/Collections in a Payment-/Collection-Factory Structure

Chart 5: Strategic and Tactical Questions to ask when planning a Payment/Collection Factory (Part 2)

7

Creation of business case

Optimisation of Payment Authorisation

Format Standardisation

Bank connectivity supporting large file sizes

Bank and Account concentration

Cash Pooling (local and international)

Standardisation of ERP systems

= Part of Deutsche Bank services

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 helpThe 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

www.db.com/gtbgtb.marketing@db.com

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.

Additionally, you can have the local version generatean error report as a text file, which you could, forexample, insert into an e-mail and forward it forfurther processing.

Another convenient feature is available in the localversion of BL Format Check: In a second window thepayment file is displayed in a clearly arranged format.Repeating information, such as multiple transactions,can be browsed by clicking a "next" button.

FormatsBL Format Check supports the following formats:

• SEPA for the data formats of the versions 2. 3through 2.6 specified by the DK

• DTAUS German domestic payments in disk format

• DTAUS German domestic payments in magnetic tapeformat

• DTAZV international payments in disk format

• SWIFT MT1 01 and MT1 03

Beyond this, BL Format Check can be extended withadditional formats.

Validation of payment files made easy with BL Format Check of Business-Logics

Additionally, errors are highlighted with colored marksin the file view. Upon hovering the marks with themouse, additional, detailed messages appear.

Furthermore you can re-check or delete uploadedfiles.

BL Format Check as local programFor using the online version of BL Format Check,payment files need to be sent over the Internet. Ifthis is not possible due to privacy concerns, BL FormatCheck as a local program comes into play.

The program is started simply by clicking the link atthe bottom of the page of the online version. With“Java Web Start” the latest version of the programwill then be started on your computer.

There is a standalone version available, too, whichcan be started without the online application.

You can easily drag and drop the file to check into theprogram window being sure that the file will not leaveyour computer.

As with the online version, a list of messages and thefile itself with colored marks will be displayed in caseof errors.

Payment files in companies usually originate fromdifferent systems and often do not conform withcurrent standards. The introduction of SEPA has evenincreased the emergence of non-conforming files.

BL Format Check is the system to test all commonpayment files before sending them to the bank forfurther processing.

BL Format Check is available in two versions — as anonline web application and as a local program.

BL Format Check onlineAfter applying for using BL Format Check at yourbank, you will receive an e-mail with your accessdata, which consists of a web address — individual andunique for you, hence you don't need to remember auser name and password to use BL Format Check.

Upon entering your personal web address into yourfavourite browser, an entry form appears allowing youto upload a file from your computer.

Once uploaded, BL Format Check automaticallyidentifies the file format. If the file does not have anyerrors, it will be confirmed and displayed. Otherwiseyou will see a list of messages including errordescriptions and information about the position ofeach error within the file.

Business-Logics

Business-Logics is an independent software producer,consulting company and service provider in the fieldof electronic banking, based in Hilden, Germany. Formore than ten years we develop solutions and provideconsulting services for banks, enterprises, softwaremakers and the public sector.

Our core business consists of developing products andcomponents as well as providing services forelectronic payment transactions between banks,companies and public authorities. Specializing incorporate banking with EBICS in Germany and Franceour experts possess in-depth knowledge in this field.

Business-LogicsFormat Check

Validation ofPayment Files

Business-Logics GmbHTellerringstr. 1 140721 HildenGermanyFon: +49 21 03 33993-0Fax: +49 21 03 33993-1 0www.business-logics. deinfo@business-logics. de

eBanking solutions

System Requirements

Java Runtime Environment version 5.0 or higher

Further information available athttp: //www.formatpruefer.de

Origix CorporateA complete corporate solution for both SEPA Direct Debits/ Credit Transfers

www.sentenial.com

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. Bene�ciary bank accounts can be speci�ed 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 reachableunder SEPA. This ensures that paymentscan 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 DEBITSentenial’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 bene�ts 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 followingfeatures:

• Support for transaction �les 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, �le 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 indepen-dent but interconnected modules whichcan be deployed as required, to minimisecost 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 noti�cation 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 demateriali-sation and digitizing newly signed mandates

MODULE 2- MANDATE MANAGEMENTWith Origix Corporate you can create and archive new mandates, including paper mandates and amend existing mandates.

Origix Corporate o�ers 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 2006.

We are the trusted choice of leading European banks and corporate customers.

Mandate Migration

Mandate Management

SDD Transaction Processing

SCT Transaction Processing

CORPORATE

LEGACY ORIGINATION

LEGACY FILES

LEGACY

R TRANSACTIONS

DAILY

RECONCILIATION REPORTING

ORIGINATING BANK

BANK

ISO XMLFORMAT

ISO XML FORMAT

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

• 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

Mandates can be created and sent toyour 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 PROCESSINGSEPA compliance is compulsory for all direct debits and credit transfers, but existing �nancial 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) �le 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 �at �le formats.

Origix Corporate provides the following services as part of the Transaction Processing Module:

• Support for transaction �les 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 '�re drill' by taking action NOW

Phone: +353 1629 2141 E: dbcustomer@sentenial.com W:www.sentenial.com © Sentenial 2012

Origix CorporateA complete corporate solution for SEPA Direct Debits/ Credit Tansfers

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

Table 1 shows the national legacy formats supported, with more regularly added.

• MIS Reporting on mandates

Deutsche BankGlobal Transaction Banking

Your Name Name of Debtor

Your Address Street and Number

ZIP and City

Country

Your Account Number IBAN

Bank (Name)

and (SWIFT BIC)

Name of Creditor Name of Creditor

Creditor ID

Street and Number

ZIP and City

Country

Creditor ID *

Contract Data

Type of Payment Recurrent payment or One-off payment

City, Date

Signature

SEPA Core Direct Debit Mandate

Mandate Reference *

Please return to: Name of Creditor

Street and Number

ZIP and City

* Mandate References may not exceed 35 characters and must consist of the following characters only: A-Z, a-z, 0-9 / - ?: ( ) . , ’+

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.

Creditor’s use only

Deutsche BankGlobal Transaction Banking

SEPA Reference Mapping

With the use of the XML, SEPA format-dedicated 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

Definition of XML References

PaymentInformationIdentificationUnique identification assigned by the sending Party, to identify the Payment Information Group (Batch) within the message.

InstructionIdentificationUnique 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.

EndToEndReferenceUnique 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 end-to-end identification can be used for reconciliation or to link tasks relating to the transaction.

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.

RemittanceInformationInformation 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 20022 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.

Think SEPA. Think Deutsche.

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:IT70X0626070080000123406C00BIC: CRFIIT3PXXX

XML Tag Code Ebene Remarks

PaymentInformationIdentification

KREF+ Batch Sender Reference (max. 35 characters) serves for identification on the account statement

InstructionIdentification

KREF+ Transaction Sender Reference (max. 35 characters) serves for identification on the account statement

EndtoEndIdentification

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

RemittanceInformation

SVWZ+ Transaction Max. 140 characters / one line (Harmonisation across all SEPA Countries)