1 / 48

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 .

dai
Download Presentation

HOW TO MAKE SEPA A SUCCESS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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

  3. 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 …

  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

  5. SEPA : what remains to be done • EACT¹ and EUC² have made known to the EPCthe 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 )

  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 • A similar commitment would be taken by corporates • Unique Entity Identifier : a standard national code to identify non-banks

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

  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

  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 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. ¹Advanced Mandate Information

  10. SEPA DD: ways for improving performances RULEBOOKS AMENDMENT ADDITIONAL OPTIONAL SERVICES PSD TRANSPOSITION PARTIES IDENTIFIERS - UEI SPECIAL CLAUSES DMF SEPA COMPLIANT ELECTRONIC DATABASE ALIGNEMENT SMART SEPA DD EXISTING MANDATE VALIDITY ART. 62.3 FEATURES MAINTAIN BUSINESS MODELS INCREASE SECURITY INCREASE CERTAINTY INCREASE SECURITY INCREASE AUTOMATION MAINTAIN BUSINESS MODELS REDUCE COSTS INCREASE CERTAINTY

  11. SEDA: basics 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. Creditor Debtor Bank MANDATE DATA SPECIAL CONDITIONS SPECIAL INSTRUCTIONS • Mandate life cycle • Mandate risk profile • Collections risk profile

  12. SEDA: basics • 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 Debtor Bank Database continuous alignment of information Creditor Database

  13. SEDA: modularity Basic MRI ¹ transmission and management MRI database management Enhanced MRI transmission and management Mandate checkingwithdebtors MRI amendment management Collectionschecks Mandate collection (DMF) 13/48 ¹ 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

  15. SEDA: modularity MRI database management Debtor bank stores MRI Debtor bank stores enhanced MRI

  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

  17. SEDA: modularity Mandate checkingwithdebtors Debtor bank checks with debtor • MRI • Mandate validity • Service parameters

  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

  19. SEDA: modularity Collectionchecks Debtor bank receives standard Collections and checks correspondence with its own database, bank checks • Corresponding creditor • Corresponding debtor • Corresponding IBAN • Corresponding service parameters

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

  21. SEDA: benefits • 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 Debtor Bank Debtor Bank Database • 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 Creditor Database

  22. SEDA: mandate data check (CMF) Checking mandates before collection (CMF) Debtor • mandate delivery (SDD basic) Creditor • Mandate dematerialization & archiving • (SDD basic) • Management & archiving check results Request of confirmation: Mandatory for B2B Optional for B2C (as agreed with debtor) (SDD AOS) • Check result transmission • (SDD AOS) • Mandate related data transmission • (SDD AOS) • Check result transmission • (SDD AOS) Transmission channel Debtor Bank Creditor Bank • Mandate related data check & archiving • (SDD AOS) • Mandate related data transmission • (SDD AOS)

  23. SEDA: mandate data checks Debtor bank executes controls on mandates information received through SEDA, before collection process starts. Results are communicated to creditor. • 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 Debtor Bank Creditor

  24. SEDA: debtoridentifier (e.g. Italy, Spain) Debtor / subscriber Creditor Mandate SDD Creditor Database Debtor ID ID document Fiscal Code Rulebook AT27 SDD Implementation guidelines Debtor ID

  25. SEDA: mandate specialclauses Flexibility SDD use in different business models Reduced risks Collection Frequency Mandate duration (length of time of validity) First and final collection date Number of collections Art. 62.3 PSD?? Max amount to be collected

  26. SEDA: mandate amendment (1) Amending mandates (released to Creditor) Debtor • mandate amendment • (SDD basic) Creditor • Amendment dematerialization & archiving • (SDD basic) • Management & archiving check results Request of confirmation: Mandatory for B2B Optional for B2C (as agreed with debtor) (SDD AOS) • Check result transmission • (SDD AOS) • Mandate related data transmission • (SDD AOS) • Check result transmission • (SDD AOS) Transmission channel Debtor Bank Creditor Bank • Mandate related data check & archiving • (SDD AOS) • Mandate related data transmission • (SDD AOS)

  27. SEDA: mandate amendment (2) Mandate amendment originated by Debtor or Debtor Bank Debtor Creditor • Check data and mandate amendments archiving • SDD (basic) • Mandate related data transmission • (SDD AOS) • mandate amendment • (SDD basic) • Mandate related data transmission • (SDD AOS) • Check result transmission • (SDD AOS) Transmission channel • Mandate amendment check or origination & archiving • (SDD AOS) Debtor Bank Creditor Bank • Check result transmission • (SDD AOS)

  28. SEDA: amendmentscomingfromdebtorbank SEDA can manage amendments to mandates originated directly by debtor bank or consequent to debtor instructions that impact on existing mandates: • 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 Debtor Bank Creditor

  29. SEDA: mandate cancellation (1) Cancelling mandates (released to Creditor) • mandate cancellation request • (SDD basic) Debtor Creditor • Management & archiving confirm • Information mandate cancellation • (SDD basic) • Mandate cancellation trasnsmission • (SDD AOS) • Cancellation confirm • (SDD AOS) • Cancellation confirm • (SDD AOS) Transmission channel Debtor Bank Creditor Bank • Mandate cancellation check & archiving • (SDD AOS) • Mandate cancellation trasnsmission • (SDD AOS)

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

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

  32. SEDA: DMF option Collection of mandates by Debtor Bank (optional) • Mandate related data check & archiving • (SDD AOS) Debtor Creditor • Confirmation or reject • (SDD AOS) • Mandate related data transmission • (SDD AOS) • mandate delivery (SDD AOS) • Check result transmission • (SDD AOS) • Mandate related data ransmission • (SDD AOS) Transmission channel • Check, mandate dematerialisation & archiving • (SDD AOS) Debtor Bank Creditor Bank • Management & archiving check results • (SDD AOS) • Check result transmission • (SDD AOS)

  33. SEDA and SDD B2C comparison

  34. SEDA and SDD B2C comparison

  35. SEDA and SDD B2C comparison

  36. SEDA and SDD B2B comparison

  37. SEDA and SDD B2B comparison

  38. SEDA and SDD B2B comparison

  39. SEDA and AMI : differences Unlike SEDA , in AMI initiativeofcommunicationisonlywith creditor bank .No messages are foreseen on initiativeofdebtorbanktocommunicatechangesinitiated bythatbank ( e.g. new IBAN BIC , revocationof DD service todebtor) or the debtor(e.g. changeofdebit account withinsamebank , prohibitiontodebit 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.

  40. AMI¹ : Advanced Mandate Information Three data sets/messages for six functions DS-14 Creditor to Creditor BankAdvance Mandate Information -Initial Mandate DS-15 Inter-BankAdvance Mandate Information – Initial Mandate Mandate Initiation Request (pain.009.001.01) DS-14 Creditor to Creditor Bank Advance Mandate Information – Amended Mandate DS-15 Inter-BankAdvance Mandate Information – Amended Mandate Mandate Amendment Request (pain.010.001.01) DS-16 Inter-BankMessage for the Response on the Advance Mandate Information Request – Initial or Amended Mandate DS-16 Customer to BankMessage for the Response on the Advance Mandate Information Request – Initial or Amended Mandate Mandate Acceptance Report (pain.012.001.01) ¹ AMI is an optional SEPA service

  41. AMI AND SEDA USE ISO 20022 MESSAGES • Common Messages ( AMI – SEDA ) • MandateInitiationRequest(pain.009.001.01 ) (DS-SEDA-01) • AlignmentRequestof mandate • MandateAcceptanceReport( pain.012.001.01 ) DS-SEDA-04)Answerbydebtorbanktorequestforalignment , amendement and cancellationof mandate • MandateAmendmentRequest ( pain.010.001.01) DS-SEDA-02) • Requestofamendmentsinitiatedby creditor • SEDA additionalMessages • MandateAmendmentRequest ( pain.010.001.01) (DS-SEDA-05); • Communicationofamendmentsinitiatedbydebtorbank ( debtor) • MandateCancellationRequest( pain.011.001.01 ) ( DS-SEDA-03)Requestofcancellationof mandate initiatedbyalignmentbank ( creditor)and (DS-SEDA-06) • Communicationofcancellationinitiatedby the debtor’s bank ( debtor)

  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 andother Fora .This includes Workshops and mixed Task Forces ¹ ¹ First case is Task Force to run and evaluate IBAN BIC Survey

  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 20022

  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

  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

  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 DESTROYING IS EASIER THAN BUILDING LET’S HOPE FOR THE BEST …….. THANK YOU

  48. Sources of information SEDA ABI = PierfrancescoGaggi p.gaggi@abi.it AITI = Massimo Battistella massimo.battistella@telecomitalia.it EACT FORMATTING RULES EACT= Gianfranco Tabasso gianfranco.tabasso@fmsgroup.it = Luc Migeot ( website SEPA) luc.migeot@ni-hao.fr = Robert Bol¹ robert.bol@onsmail.nl B2B SLA- Automatic Reconciliation of Payments IBAN BIC SURVEY EACT = Gianfranco Tabasso = Massimo Battistella ¹ See article in the October issue of TMI ( Treasury Management International)

More Related