how to make sepa a success

HOW TO MAKE SEPA A SUCCESS

GIANFRANCO TABASSO

Chairman EACT PAYMENT COMMISSION

Vice President

Summary

• Where we are with SEPA …a corporate view

• What remains to be done - Change Requests - AOS

• The SEDA project

• New SEPA Governance and End Date

2/48

Where we are with SEPA a corporate view…• To date , SEPA is not a success story

- after 2 and ½ years , SCT is 9 -10 % of CT¹ , instead of the critical mass that should have made migration irreversible by end of 2010,(SEPA Roadmap 2004)

- SDD at 0,05 % not really started yet ….waiting for banks’ reachability by 30th Nov. 2010

• Reasons for low voluntary adoption - industry, not market –driven project - low interest of corporates for SEPA as is…

( incomplete ..no end-to-end standardization) - delay in delivery of PSD - other priorities forced by the financial crisis - poor communication

¹ All of it interbank …3/48

Where we are with SEPA A corporate view…

• Despite the lack of enthusiasm …SEPA must go on- status quo ( dual systems) is “unsustainable”

- “going back” is not an option • The End Date , a new governance and AOS can still make

SEPA a success…

• But the European Commission must tread carefully- avoid unilateral top-down decision making - support the new governance and put stakeholders in the driver’s seat - distinguish between competitive and collaborative domain

4/48

SEPA : what remains to be done• EACT¹ and EUC² have made known to the EPC

the changes and implementations requested by European corporates

- June 2009 White Paper on SEPA - Customer Stakeholder Forum ( CSF ) - Workshops and technical papers - Press releases • Some requests have slowly found their way in

the Rulebooks …the majority is still outstanding¹ European Association of Corporate Treasurers ² End User Coordination ( EACT , Business Europe, Eurocommerce ,UEAPME, CEA

, FAEP , BEUC , EMOTA ) 5/48

SEPA : what remains to be doneGeneral

- A new Roadmap to “complete” SEPA before the end date- A commitment by banks¹ to adopt ISO 2022

end-to-end by an agreed future date - Adopt a UEI² to identity account holders - Do not request BIC from end-users - Give SEPA Council effective power to guide development of SEPA - Interoperability and rules in extra-EU payments - Differences in PSD implementation by countries - “Structure” of SEPA bank fees - Joint monitoring of SEPA compliance - EPC Directory of SEPA-ready banks ( basic schemes and AOS )

and cut-off times

1 A similar commitment would be taken by corporates 2 Unique Entity Identifier : a standard national code to identify non-banks

6/48

SEPA : what remains to be doneSCT- Check identity of beneficiary ( UEI ) in addition to IBAN

- Extend 140 chrs. “structured” for remittance information or use full ISO 20022. Until then , payers of many invoices can only use the 140 chrs. “unstructured” with EACT formatting rules² or use a separate remittance advice

- Report to beneficiary in a standard way all information provided by payment originator ,including date of order

- A new Rulebook for B2B¹ where a few more fields of DS 01 in SCT Rulebook would be “mandatory”

¹ EPC proposed a voluntary B2B SLA ² EPC Rulebook Nov. 2011 and http://www.corporatesepa.com/eact.html

7/48

SEPA : what remains to be doneSDD • Implement in SEPA all options allowed by the PSD - shorter or no refund for consumer if debtor bank validates mandate - DMF • Create a communication channel between banks for non-monetary & non-accounting information ¹ related to payments ( symmetry of information for all participants )

• Non-authorized B2B direct debit ( like Italian RIBA )¹ SEDA ( SEPA-compliant Data Base Alignment ) primarily for SDD mandates but not only

8/48

The SEDA Project The EACT and the EUC had repeatedly asked for the EPC for increased control of mandate and debtor coordinates in the SDD Rulebooks. Late 2009 , the Belgian Community proposed a Change Request to the SDD Rulebook to check existence and correct bank coordinates of debtor account as given in mandate before the start of collections ( later to be known as AMI¹ ) .

At the same time ABI presented a request for a more comprehensive set of changes thatgo under the name of SEDA and mirrors the new system that operates in Italy since 2007 and was designed in conjunction with AITI and the corporate community .

In February 2010 representatives of Italian ,French German and Belgian banking communities met to coordinate efforts and make sure that the two solutions would not be in conflict .The result of these talks was an agreement to use the ISO 20022 mandate standard messages so that banks adopting the more limited AMI option could scale up to SEDAwithout much effort ( AMI can be seen as a first step )

AMI was accepted by the EPC Plenary of September 2010 as an optional feature of both SDD Rulebooks ( effective 19 November 2011) .ABI decided to implement the SEDA as a SEPA AOS which will available at the same time.

9/48¹ Advanced Mandate Information

10/48

SEPA DD: ways for improving performances

RULEBOOKS AMENDMENT

PARTIES IDENTIFIERS - UEISPECIAL CLAUSES

DMF

ADDITIONALOPTIONAL SERVICES

SEPA COMPLIANT ELECTRONIC DATABASE

ALIGNEMENT

SMART SEPA DD

PSD TRANSPOSITION

EXISTING MANDATE VALIDITYART. 62.3 FEATURES

MAINTAINBUSINESS MODELS

INCREASE SECURITYINCREASE CERTAINTY

INCREASE SECURITYINCREASE AUTOMATION

MAINTAIN BUSINESS MODELS

REDUCE COSTSINCREASE CERTAINTY

11/48

SEDA - SEPA compliant Electronic Database Alignment - is a community AOS that will operate in full compliance with SEPA Core and B2B Schemes allowing exchange of information among creditors and debtors banks.

SEDA: basics

Creditor Debtor Bank

► Mandate life cycle► Mandate risk profile► Collections risk profile

MANDATEDATA

SPECIALCONDITIONS

SPECIALINSTRUCTIONS

12/48

SEDA: basics

Debtor Bank

Database

CreditorDatabase

continuous alignment

of information

► exchange of mandate reference data immediately after issue of mandate and before first collection

► use of check returns codes to allow STP management of exceptions by creditors and debtor banks

► exchange of specific service parameters agreed with debtors (e.g. maximum amount of a single collection, first and last date for collections)

► exchange of mandate amendments originated both from creditor or debtor bank

13/48

SEDA: modularity

Enhanced MRI transmission and management

Basic MRI ¹ transmission and management

Mandate checking with debtors

MRI amendment management

MRI database management

Collections checks

Mandate collection (DMF)

¹ Mandate Related Information

SEDA: modularity

Basic MRI transmission and management

Debtor bank receives MRIDebtor bank checks:► Valid and corresponding IBAN► Valid and corresponding BIC► No prohibition from debtor to

accept SDD► No direct debit forbidden on

account for regulatory reasons

14/48

SEDA: modularity

MRI database management

Debtor bank stores MRI Debtor bank stores enhanced MRI

15/48

SEDA: modularity

Enhanced MRI transmission and management

Debtor bank receives enhanced MRI► Debtor and Subscriber Identification Code► Collection frequency and Mandate duration► First and last collection date► Max amount allowed► Number of collectionsDebtor bank checks► Correlation between account holder and

mandate subscriber based on Debtor Identification Code

► Service parameters16/48

SEDA: modularity

Mandate checking with debtors

Debtor bank checks with debtor

► MRI► Mandate validity ► Service parameters

17/48

SEDA: modularity

Mandate amendment management

Debtor bank receives amendments to ► MRI► Mandate validity

► Service parameters

Debtor bank sends amendments to ► MRI► Mandate validity

► Service parameters

18/48

SEDA: modularity

Collection checks

Debtor bank receives standard Collections

and checks correspondence with its own

database, bank checks► Corresponding creditor► Corresponding debtor► Corresponding IBAN► Corresponding service parameters 19/48

SEDA: possibile future enhancements

SDD portability

Legacy system mandate migration to SDD

General IBAN & BIC updating and verification

Current account portabilty

20/48

21/48

SEDA: benefits

Debtor Bank

► checks mandate validity before receiving collections using a simple data set based on mandate reference

► safeguards debtor before debiting its account

► manages specific service parameters agreed with debtors

► checks mandate validity before sending collections using a simple data set based on mandate reference

► learns of mandate cancellation or amendment before sending the collections

► manages specific service parameters agreed with debtors

Creditor

Debtor Bank

Database

CreditorDatabase

22/48

SEDA: mandate data check (CMF)

Debtor Creditor

Debtor Bank

Creditor Bank

1. mandate delivery (SDD basic)

2. Mandate dematerialization & archiving(SDD basic)

3. Mandate related data transmission

(SDD AOS)

4. Mandate related data transmission(SDD AOS)

5. Mandate related data check & archiving (SDD AOS)

6. Check result transmission

(SDD AOS)

7. Check result transmission (SDD AOS)

8. Management & archiving check results

Transmissionchannel

Request of confirmation:Mandatory for B2BOptional for B2C (as agreed with debtor) (SDD AOS)

Checking mandates before collection (CMF)

23/48

Debtor bank executes controls on mandates information received through SEDA, before collection process starts. Results are communicated to creditor.

SEDA: mandate data checks

Debtor Bank

► Correlation between account holder and mandate subscriber based on Debtor Identification Code

► Valid and corresponding IBAN► Valid and corresponding BIC► Prohibition from debtor to accept

SDD► Direct debit forbidden on account

for regulatory reasons► Invalid service parameters

Creditor

24/48

Rulebook AT27 SDD Implementation guidelines

SEDA: debtor identifier (e.g. Italy, Spain)

Debtor/

subscriber Creditor SDD

CreditorDatabase

Mandate

ID document

Fiscal Code

Debtor ID

Debtor ID

Chr Content 1-2 ISO Country Code

3-4 Check digits

5-7 Debtor Business Code (ZZZ when not used)

8-35 Country specific identifier (UEI)

25/48

SEDA: mandate special clauses

Collection Frequency

Mandate duration (length of time of validity)

First and final collection date

Number of collections

Max amount to be collected

Flexibility

SDD use in different business models

Reduced risks

Art. 62.3 PSD??

26/48

SEDA: mandate amendment (1)

Debtor Creditor

Debtor Bank

Creditor Bank

1. mandate amendment

(SDD basic)2. Amendment

dematerialization & archiving(SDD basic)


(SDD AOS)




(SDD AOS)


8. Management & archiving check results

Transmissionchannel

Request of confirmation:Mandatory for B2BOptional for B2C (as agreed with debtor) (SDD AOS)

Amending mandates (released to Creditor)

27/48

SEDA: mandate amendment (2)

Debtor Creditor

Debtor Bank

Creditor Bank

1. mandate amendment(SDD basic)


(SDD AOS)

7. Check result transmission(SDD AOS)

2. Mandate amendment check or origination & archiving (SDD AOS)


(SDD AOS)

4. Mandate related data transmission (SDD AOS)

5. Check data and mandate amendments archivingSDD (basic)

Transmissionchannel

Mandate amendment originated by Debtor or Debtor Bank

28/48

SEDA can manage amendments to mandates originated directly by debtor bank or consequent to debtor instructions that impact on existing mandates:

SEDA: amendments coming from debtor bank

Debtor Bank

► Request from debtor to refuse any future collection

► Request from debtor to transfer current account to another bank

► Variation of current account IBAN (e.g. in case of merger or acquisition of debtor bank)

► Variation of current account BIC

Creditor

29/48

SEDA: mandate cancellation (1)

Debtor Creditor

Debtor Bank

Creditor Bank

1. mandate cancellation request(SDD basic)

3. Mandate cancellation trasnsmission(SDD AOS)

4. Mandate cancellation trasnsmission(SDD AOS)

5. Mandate cancellation check & archiving (SDD AOS)

6. Cancellation confirm

(SDD AOS)

7. Cancellation confirm (SDD AOS)

8. Management & archiving confirm

Transmissionchannel

Cancelling mandates (released to Creditor)

2. Information mandate cancellation(SDD basic)

30/48

SEDA: mandate cancellation (2)

Debtor Creditor

Debtor Bank

Creditor Bank

1. Request mandate cancellationclose account(SDD basic)


(SDD AOS)

7. Check result transmission(SDD AOS)

3. Cancellation confirm

(SDD AOS)

4. Cancellation confirm (SDD AOS)

5. Check cancellation & archivingSDD (basic)

Transmissionchannel

Cancelling mandates (released or originated by Debtor Bank)

2. Manage cancellation request or cancellation origination. Dematerialisation and archiving

(SDD AOS)

31/48

SEDA: open points

Business model

Messages and technical infrastructures

Governance

Debtor bank remuneration

ISO 20022 CSMs??

RulesTransparency

32/48

Debtor Creditor

Debtor Bank

Creditor Bank

1. mandate delivery (SDD AOS) 3. Mandate

related data ransmission

(SDD AOS)




(SDD AOS)


8. Management & archiving check results(SDD AOS)

Transmissionchannel

Collection of mandates by Debtor Bank (optional)

2. Check, mandate dematerialisation & archiving(SDD AOS)

9. Confirmation or reject

(SDD AOS)

SEDA: DMF option

SEDA and SDD B2C comparison

CHECKS BEFORE COLLECTION SDD SEDAValid IBAN No Yes

Valid BIC No Yes

No prohibition to accept SDD No Yes

No SDD forbidden regulatory No YesCorrelation between account holder and mandate subscriber based on Debtor Identification Code No Yes

Verification of mandate validity with debtor No Optional

Mandate duration No Optional

Max amount to be collected No Optional

Number of collections No Optional

Creditor in black or white list No Optional

Collection frequency No Optional

Communication to creditor of checks results No Yes

33/48


CHECKS UPON COLLECTION SDD SEDAValid IBAN Yes Yes

Valid BIC Yes Yes

No prohibition to accept SDD Yes Yes

No SDD forbidden regulatory Yes YesCorrelation between MIR stored and MIR in collection No Yes

Management of creditor black or white list AOS AOS

Mandate duration AOS Yes, if present

Max amount to be collected AOS Yes, if present

Number of collections AOS Yes, if present

Collection frequency AOS Yes, if present

Communication to creditor of checks results Yes Yes

34/48


FUNCTIONALITIES SDD SEDACommunication of MIR amendments to debtor bank before collection No Yes

Communication of MIR amendments to debtor bank in collection Yes Yes

Communication of MIR amendments by debtor bank to creditor No Yes

Verification of MIR amendments originated through or by creditor No Yes

Verification of MIR originated through or by debtor bank No YesMandate cancellation originated through or by debtor bank No YesMandate cancellation originated through or by creditor Yes YesSDD Mandate portability to other bank No PossibleCurrent account portability with existing SDD Mandates No PossibleCreditor bank mandate database AOS YesCreditor and debtor bank mandate database continuous alignment No Yes

Mandate collection by debtor bank No Possible

35/48

SEDA and SDD B2B comparison

CHECKS BEFORE COLLECTION SDD SEDAValid IBAN No Yes

Valid BIC No Yes

No prohibition to accept SDD No Yes

No SDD forbidden regulatory No YesCorrelation between account holder and mandate subscriber based on Debtor Identification Code No Yes

Verification of mandate validity with debtor No Yes

Mandate duration No Optional

Max amount to be collected No Optional

Number of collections No Optional

Creditor in black or white list No Optional

Collection frequency No Optional

Communication to creditor of checks results No Yes

36/4


CHECKS UPON COLLECTION SDD SEDAValid IBAN Yes YesValid BIC Yes Yes

No prohibition to accept SDD Yes Yes

No SDD forbidden regulatory Yes YesCorrelation between MIR stored and MIR in collection No Yes

Verification of mandate validity with debtor Yes Yes

Management of creditor black or white list AOS AOS

Mandate duration AOS Yes, if present

Max amount to be collected AOS Yes, if present

Number of collections AOS Yes, if present

Collection frequency AOS Yes, if present

Communication to creditor of checks results Yes Yes37/48


FUNCTIONALITIES SDD SEDACommunication of MIR amendments to debtor bank before collection No Yes

Communication of MIR amendments to debtor bank in collection Yes Yes

Communication of MIR amendments by debtor bank to creditor No Yes

Verification of MIR amendments originated through or by creditor No Yes

Verification of MIR originated through or by debtor bank No YesMandate cancellation originated through or by debtor bank No YesMandate cancellation originated through or by creditor Yes YesSDD Mandate portability to other bank No PossibleCurrent account portability with existing SDD Mandates No PossibleCreditor bank mandate database AOS YesCreditor and debtor bank mandate database continuous alignment No Yes

Mandate collection by debtor bank No Possible

38/48

SEDA and AMI : differences 1. Unlike SEDA , in AMI initiative of communication is only with creditor bank .

No messages are foreseen on initiative of debtor bank to communicate changes initiated by that bank ( e.g. new IBAN BIC , revocation of DD service to debtor) or the debtor

(e.g. change of debit account within same bank , prohibition to debit SDD to account )

2 . As a result of 1 ) AMI does not contemplate ,like SEDA, an Alignment Bank..i.e. one of creditor’s banks designated to receive messages from debtors banks …

3. In AMI, special mandate clauses limiting debits ( max amount , date of first and last collection, etc. ) are not the object of preliminary alignment between creditor and debtor bank but could be provided as a Value Added service

4. AMI uses three ISO 20022 messages SEDA requires additional information which is in ISO mandate but not in SEPA SDD messages i) BIC of Alignment bank ii) name of mandate subscriber ( if legal person, subscriber must be authorized to operate account) iii) subscriber ID iv) a field for limiting clauses v) “status” of debtor’s account ( consumer / business )

5. Standard features of SEDA are Value added services in AMI …e.g. coherence of each collection with mandate , action of debtor bank in case negative check , etc.

39/48

AMI¹ : Advanced Mandate Information

Mandate Initiation Request (pain.009.001.01)

Mandate Amendment Request (pain.010.001.01)

Mandate Acceptance Report (pain.012.001.01)

DS-14 Creditor to Creditor Bank Advance Mandate Information - Initial MandateDS-15 Inter-Bank Advance Mandate Information – Initial Mandate

DS-14 Creditor to Creditor Bank Advance Mandate Information – Amended MandateDS-15 Inter-Bank Advance Mandate Information – Amended Mandate

DS-16 Inter-Bank Message for the Response on the Advance Mandate Information Request – Initial or Amended MandateDS-16 Customer to Bank Message for the Response on the Advance Mandate Information Request – Initial or Amended Mandate

Three data sets/messages for six functions

¹ AMI is an optional SEPA service 40/48

AMI AND SEDA USE ISO 20022 MESSAGES Common Messages ( AMI – SEDA ) MandateInitiationRequest ( pain.009.001.01 ) (DS-SEDA-01)Alignment Request of mandate

MandateAcceptanceReport ( pain.012.001.01 ) DS-SEDA-04)Answer by debtor bank to request for alignment , amendement and cancellation of mandate

MandateAmendmentRequest ( pain.010.001.01) DS-SEDA-02)Request of amendments initiated by creditor

SEDA additional Messages MandateAmendmentRequest ( pain.010.001.01) (DS-SEDA-05);Communication of amendments initiated by debtor bank ( debtor)

MandateCancellationRequest ( pain.011.001.01 ) ( DS-SEDA-03)Request of cancellation of mandate initiated by alignment bank ( creditor)and (DS-SEDA-06)Communication of cancellation initiated by the debtor’s bank ( debtor) 41/48

New SEPA Governance and End Date

EACT and EUC support the fixing of an end date (s) but believe that a “new governance” is key to the ultimate success of SEPA

The new SEPA Council must become the real “driver” of future developments ( new SEPA Roadmap) and control SEPA deployment

SEPA Council should receive “technical support” by the EPC and other stakeholders organizations in the Customer Stakeholder Forum and other Fora .This includes Workshops and mixed Task Forces ¹ ¹ First case is Task Force to run and evaluate IBAN BIC Survey

42/48


- A two year debate on end date (s) - A public consultation - A Proposal for a Regulation on SEPA which included end dates but also set ( generic) essential requirements for credit transfers and direct debits in euro ….

This document, which circulated in non-authorized draft, received strong criticism from the EPC and created a heated debate in Euroland - no mention of the EPC and its role in SEPA - sets specific information requirements not in line the Rulebooks - requires end-to-end standardization of payments with ISO 20022

43/48

New SEPA Governance and End Date EACT and EUC , while appreciating most recommendations which reflect long standing requests of corporates, have expressed reservations

- Method followed : no prior consultation with stakeholders on the content ( the matter is for the SEPA Council )

- Failure to state that there is only “one SEPA” and to recognize the role of the EPC and the new governance.

The text ,in its present form, may give “ammunition” to critics of SEPA and the EPC and inspire creation of alternative “SEPA “schemes ( e.g. revamped legacy systems )

In our view, what’s behind the Commission’s pronouncement is - an “outdated” vision of monopoly and competition applied to the management of essential facilities ( like payment systems) in a network society and regulated industries

- a failure to distinguish between payment “schemes” and “products” , between collaborative and competitive domain 44/48


SEPA is the rails, switches , lights , etc. one system /one managementPayment products are the trains …can be run by different companies

45/48


Is there a risk of “monopoly” when a “utility” is run by all stakeholders in a collaborative way under the supervision of regulators ?

Standards are recognized as essential in network industriesbut international standards like ISO 20022, in order to be implemented around the world, need “regional authorities” who, under mandate from stakeholders and subject to Regulators, gather consensus , implement and adapt the standard to real life, define operating rules , enforce complianceIn Europe, for payments we have the EPC and, hopefully,a new SEPA governance in line with the above philosophy

46/48


LET’S HOPE FOR THE BEST ……..

DESTROYING IS EASIER THAN BUILDING

THANK YOU

47/48

Sources of informationSEDA ABI = Pierfrancesco Gaggi [email protected]

AITI = Massimo Battistella [email protected]

EACT FORMATTING RULES EACT = Gianfranco Tabasso [email protected]

= Luc Migeot ( website SEPA) [email protected] = Robert Bol¹

[email protected]

IBAN BIC SURVEY B2B SLA- Automatic Reconciliation of Payments

EACT = Gianfranco Tabasso = Massimo Battistella

¹ See article in the October issue of TMI ( Treasury Management International) 48/48

how to make sepa a success

Documents

sepa roadmap

complete sepa

lack of enthusiasm sepa

sepa council effective

new governance

new rulebook

new roadmap

corporate viewto date