Presentation is loading. Please wait.

Presentation is loading. Please wait.

HOW TO MAKE SEPA A SUCCESS GIANFRANCO TABASSO Chairman EACT PAYMENT COMMISSION Vice President.

Similar presentations


Presentation on theme: "HOW TO MAKE SEPA A SUCCESS GIANFRANCO TABASSO Chairman EACT PAYMENT COMMISSION Vice President."— Presentation transcript:

1 HOW TO MAKE SEPA A SUCCESS GIANFRANCO TABASSO Chairman EACT PAYMENT COMMISSION Vice President

2 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

3 Where we are with SEPA a corporate view… To date, SEPA is not a success story - after 2 and ½ years, SCT is % 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 30 th Nov 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

4 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

5 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

6 SEPA : what remains to be done General -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 1A similar commitment would be taken by corporates 2Unique Entity Identifier : a standard national code to identify non-banks 6/48

7 SEPA : what remains to be done SCT - Check identity of beneficiary ( UEI ) in addition to IBAN - Extend 140 chrs. “structured” for remittance information or use full ISO 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 and 7/48

8 SEPA : what remains to be done SDD 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

9 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 that go 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 mandate standard messages so that banks adopting the more limited AMI option could scale up to SEDA without 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 10/48 SEPA DD: ways for improving performances RULEBOOKS AMENDMENT PARTIES IDENTIFIERS - UEI SPECIAL CLAUSES DMF ADDITIONAL OPTIONAL SERVICES SEPA COMPLIANT ELECTRONIC DATABASE ALIGNEMENT SMART SEPA DD PSD TRANSPOSITION EXISTING MANDATE VALIDITY ART FEATURES MAINTAIN BUSINESS MODELS INCREASE SECURITY INCREASE CERTAINTY INCREASE SECURITY INCREASE AUTOMATION MAINTAIN BUSINESS MODELS REDUCE COSTS INCREASE CERTAINTY

11 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 MANDATE DATA SPECIAL CONDITIONS SPECIAL INSTRUCTIONS

12 12/48 SEDA: basics Debtor Bank Database Creditor Database 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 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

14 SEDA: modularity Basic MRI transmission and management Debtor bank receives MRI Debtor 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

15 SEDA: modularity MRI database management Debtor bank stores MRI Debtor bank stores enhanced MRI 15/48

16 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 collections Debtor bank checks ► Correlation between account holder and mandate subscriber based on Debtor Identification Code ► Service parameters 16/48

17 SEDA: modularity Mandate checking with debtors Debtor bank checks with debtor ► MRI ► Mandate validity ► Service parameters 17/48

18 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

19 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

20 SEDA: possibile future enhancements SDD portability Legacy system mandate migration to SDD General IBAN & BIC updating and verification Current account portabilty 20/48

21 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 Creditor Database

22 22/48 SEDA: mandate data check (CMF) DebtorCreditor 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 Transmission channel Request of confirmation: Mandatory for B2B Optional for B2C (as agreed with debtor) (SDD AOS) Checking mandates before collection (CMF)

23 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 24/48 Rulebook AT27 SDD Implementation guidelines SEDA: debtor identifier (e.g. Italy, Spain) Debtor / subscriber Creditor SDD Creditor Database Mandate ID document Fiscal Code Debtor ID ChrContent 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 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 PSD??

26 26/48 SEDA: mandate amendment (1) DebtorCreditor Debtor Bank Creditor Bank 1.mandate amendment (SDD basic) 2.Amendment 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 Transmission channel Request of confirmation: Mandatory for B2B Optional for B2C (as agreed with debtor) (SDD AOS) Amending mandates (released to Creditor)

27 27/48 SEDA: mandate amendment (2) Debtor Creditor Debtor Bank Creditor Bank 1.mandate amendment (SDD basic) 6.Check result transmission (SDD AOS) 7.Check result transmission (SDD AOS) 2.Mandate amendment check or origination & archiving (SDD AOS) 3.Mandate related data transmission (SDD AOS) 4.Mandate related data transmission (SDD AOS) 5.Check data and mandate amendments archiving SDD (basic) Transmission channel Mandate amendment originated by Debtor or Debtor Bank

28 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 29/48 SEDA: mandate cancellation (1) DebtorCreditor 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 Transmission channel Cancelling mandates (released to Creditor) 2.Information mandate cancellation (SDD basic)

30 30/48 SEDA: mandate cancellation (2) Debtor Creditor Debtor Bank Creditor Bank 1.Request mandate cancellation close account (SDD basic) 6.Check result transmission (SDD AOS) 7.Check result transmission (SDD AOS) 3.Cancellation confirm (SDD AOS) 4.Cancellation confirm (SDD AOS) 5.Check cancellation & archiving SDD (basic) Transmission channel Cancelling mandates (released or originated by Debtor Bank) 2.Manage cancellation request or cancellation origination. Dematerialisation and archiving (SDD AOS)

31 31/48 SEDA: open points Business model Messages and technical infrastructures Governance Debtor bank remuneration ISO CSMs?? Rules Transparency

32 32/48 Debtor Creditor Debtor Bank Creditor Bank 1. mandate delivery (SDD AOS) 3.Mandate related data ransmission (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 (SDD AOS) Transmission channel Collection of mandates by Debtor Bank (optional) 2.Check, mandate dematerialisation & archiving (SDD AOS) 9.Confirmation or reject (SDD AOS) SEDA: DMF option

33 SEDA and SDD B2C comparison CHECKS BEFORE COLLECTIONSDDSEDA Valid IBANNoYes Valid BICNoYes No prohibition to accept SDDNoYes No SDD forbidden regulatoryNoYes Correlation between account holder and mandate subscriber based on Debtor Identification Code NoYes Verification of mandate validity with debtorNoOptional Mandate durationNoOptional Max amount to be collectedNoOptional Number of collectionsNoOptional Creditor in black or white listNoOptional Collection frequencyNoOptional Communication to creditor of checks resultsNoYes 33/48

34 SEDA and SDD B2C comparison CHECKS UPON COLLECTIONSDDSEDA Valid IBANYes Valid BICYes No prohibition to accept SDDYes No SDD forbidden regulatoryYes Correlation between MIR stored and MIR in collection NoYes Management of creditor black or white listAOS Mandate durationAOSYes, if present Max amount to be collectedAOSYes, if present Number of collectionsAOSYes, if present Collection frequencyAOSYes, if present Communication to creditor of checks resultsYes 34/48

35 SEDA and SDD B2C comparison FUNCTIONALITIESSDDSEDA Communication of MIR amendments to debtor bank before collectionNoYes Communication of MIR amendments to debtor bank in collectionYes Communication of MIR amendments by debtor bank to creditorNoYes Verification of MIR amendments originated through or by creditorNoYes Verification of MIR originated through or by debtor bankNoYes Mandate cancellation originated through or by debtor bankNoYes Mandate cancellation originated through or by creditorYes SDD Mandate portability to other bankNoPossible Current account portability with existing SDD MandatesNoPossible Creditor bank mandate databaseAOSYes Creditor and debtor bank mandate database continuous alignmentNoYes Mandate collection by debtor bankNoPossible 35/48

36 SEDA and SDD B2B comparison CHECKS BEFORE COLLECTIONSDDSEDA Valid IBANNoYes Valid BICNoYes No prohibition to accept SDDNoYes No SDD forbidden regulatoryNoYes Correlation between account holder and mandate subscriber based on Debtor Identification Code NoYes Verification of mandate validity with debtorNoYes Mandate durationNoOptional Max amount to be collectedNoOptional Number of collectionsNoOptional Creditor in black or white listNoOptional Collection frequencyNoOptional Communication to creditor of checks resultsNoYes 36/4

37 SEDA and SDD B2B comparison CHECKS UPON COLLECTIONSDDSEDA Valid IBANYes Valid BICYes No prohibition to accept SDDYes No SDD forbidden regulatoryYes Correlation between MIR stored and MIR in collection NoYes Verification of mandate validity with debtorYes Management of creditor black or white listAOS Mandate durationAOSYes, if present Max amount to be collectedAOSYes, if present Number of collectionsAOSYes, if present Collection frequencyAOSYes, if present Communication to creditor of checks resultsYes 37/48

38 SEDA and SDD B2B comparison FUNCTIONALITIESSDDSEDA Communication of MIR amendments to debtor bank before collectionNoYes Communication of MIR amendments to debtor bank in collectionYes Communication of MIR amendments by debtor bank to creditorNoYes Verification of MIR amendments originated through or by creditorNoYes Verification of MIR originated through or by debtor bankNoYes Mandate cancellation originated through or by debtor bankNoYes Mandate cancellation originated through or by creditorYes SDD Mandate portability to other bankNoPossible Current account portability with existing SDD MandatesNoPossible Creditor bank mandate databaseAOSYes Creditor and debtor bank mandate database continuous alignmentNoYes Mandate collection by debtor bankNoPossible 38/48

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

40 AMI¹ : Advanced Mandate Information Mandate Initiation Request (pain ) Mandate Amendment Request (pain ) Mandate Acceptance Report (pain ) DS-14 Creditor to Creditor Bank Advance Mandate Information - Initial Mandate DS-15 Inter-Bank Advance Mandate Information – Initial Mandate DS-14 Creditor to Creditor Bank Advance Mandate Information – Amended Mandate DS-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 Mandate DS-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

41 AMI AND SEDA USE ISO MESSAGES Common Messages ( AMI – SEDA ) MandateInitiationRequest ( pain ) (DS-SEDA-01) Alignment Request of mandate MandateAcceptanceReport ( pain ) DS-SEDA-04) Answer by debtor bank to request for alignment, amendement and cancellation of mandate MandateAmendmentRequest ( pain ) DS-SEDA-02) Request of amendments initiated by creditor SEDA additional Messages MandateAmendmentRequest ( pain ) (DS-SEDA-05); Communication of amendments initiated by debtor bank ( debtor) MandateCancellationRequest ( pain ) ( 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

42 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

43 New SEPA Governance and End Date - 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 /48

44 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

45 New SEPA Governance and End Date SEPA is the rails, switches, lights, etc. one system /one management Payment products are the trains …can be run by different companies 45/48

46 New SEPA Governance and End Date 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 industries but 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 compliance In Europe, for payments we have the EPC and, hopefully, a new SEPA governance in line with the above philosophy 46/48

47 New SEPA Governance and End Date LET’S HOPE FOR THE BEST …….. DESTROYING IS EASIER THAN BUILDING THANK YOU 47/48

48 Sources of information SEDA ABI = Pierfrancesco Gaggi AITI = Massimo Battistella EACT FORMATTING RULES EACT = Gianfranco Tabasso = Luc Migeot ( website SEPA) = Robert Bol¹ 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


Download ppt "HOW TO MAKE SEPA A SUCCESS GIANFRANCO TABASSO Chairman EACT PAYMENT COMMISSION Vice President."

Similar presentations


Ads by Google