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 30 th 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 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 1 2 A similar commitment would be taken by corporates Unique Entity Identifier : a standard national code to identify non-banks 6/48
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 B 2 B¹ where a few more fields of DS 01 in SCT Rulebook would be “mandatory” ¹ EPC proposed a voluntary B 2 B SLA ² EPC Rulebook Nov. 2011 and http: //www. corporatesepa. com/eact. html 7/48
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 B 2 B 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 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 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
SEPA DD: ways for improving performances RULEBOOKS AMENDMENT ADDITIONAL OPTIONAL SERVICES PSD TRANSPOSITION PARTIES IDENTIFIERS - UEI EXISTING MANDATE VALIDITY SPECIAL CLAUSES SEPA COMPLIANT ELECTRONIC DATABASE ALIGNEMENT DMF SMART SEPA DD MAINTAIN BUSINESS MODELS INCREASE SECURITY INCREASE AUTOMATION INCREASE SECURITY INCREASE CERTAINTY MAINTAIN BUSINESS MODELS ART. 62. 3 FEATURES REDUCE COSTS INCREASE CERTAINTY 48
SEDA: basics SEDA - SEPA compliant Electronic Database Alignment - is a community AOS that will operate in full compliance with SEPA Core and B 2 B Schemes allowing exchange of information among creditors and debtors banks. Creditor Debtor MANDATE SPECIAL DATA CONDITIONS INSTRUCTIONS ► ► ► Bank Mandate life cycle Mandate risk profile Collections risk profile 11/48
SEDA: basics ► Debtor Bank Database ► continuous alignment of information Creditor Database ► ► 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 8
SEDA: modularity Basic MRI ¹ transmission and management MRI database management Enhanced MRI transmission and management Mandate checking with debtors MRI amendment management Collections checks Mandate collection (DMF) ¹ Mandate Related Information 13/48
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
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 collections Debtor bank checks ► Correlation between account holder and mandate subscriber based on Debtor Identification Code ► Service parameters 16/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 Legacy system mandate migration to SDD Current account portabilty SDD portability General IBAN & BIC updating and verification 20/48
SEDA: benefits ► Debtor Bank Database Debtor Bank ► ► ► Creditor Database Creditor ► ► 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 21/48
SEDA: mandate data check (CMF) Checking mandates before collection (CMF) 1. mandate delivery (SDD basic) Debtor 8. Management & archiving check results Request of confirmation: Mandatory for B 2 B 7. Check result transmission 6. Check result transmission Optional for B 2 C (as agreed with debtor) (SDD AOS) 5. Mandate related data check & archiving Creditor Transmission 2. Mandate dematerialization & archiving (SDD basic) 3. Mandate related data transmission (SDD AOS) channel Debtor Bank 4. Mandate related data transmission (SDD AOS) Creditor Bank (SDD AOS) 22/48
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 ► Debtor Bank Valid and corresponding IBAN ► Valid and corresponding BIC ► Prohibition from debtor to accept SDD ► ► Creditor Direct debit forbidden on account for regulatory reasons Invalid service parameters 23/48
SEDA: debtor identifier (e. g. Italy, Spain) Mandate Debtor / subscriber ID document Creditor SDD Creditor Database Debtor ID Fiscal Code Chr Rulebook AT 27 Debtor ID SDD Implementation guidelines 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) 24/48
SEDA: mandate special clauses Collection Frequency Flexibility Mandate duration (length of time of validity) First and final collection date SDD use in different business models Reduced risks Number of collections Max amount to be collected Art. 62. 3 PSD? ? 25/48
SEDA: mandate amendment (1) Amending mandates (released to Creditor) 1. mandate amendment Debtor (SDD basic) Request of confirmation: Mandatory for B 2 B 8. Management & archiving check results 7. Check result transmission 6. Check result transmission Optional for B 2 C (as agreed with debtor) (SDD AOS) 5. Mandate related data check & archiving Creditor Transmission 2. Amendment dematerialization & archiving (SDD basic) 3. Mandate related data transmission (SDD AOS) channel Debtor Bank 4. Mandate related data transmission (SDD AOS) Creditor Bank (SDD AOS) 26/48
SEDA: mandate amendment (2) Mandate amendment originated by Debtor or Debtor Bank Creditor Debtor 5. Check data and mandate amendments archiving SDD (basic) 3. Mandate related data transmission 1. mandate amendment 4. Mandate related data transmission (SDD AOS) (SDD basic) 6. Check result transmission (SDD AOS) Transmission 2. Mandate amendment check or origination & archiving (SDD AOS) channel Debtor Bank 7. Check result transmission (SDD AOS) Creditor Bank 27/48
SEDA: amendments coming from debtor bank SEDA can manage amendments to mandates originated directly by debtor bank or consequent to debtor instructions that impact on existing mandates: ► ► 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) Creditor Variation of current account BIC 28/48
SEDA: mandate cancellation (1) Cancelling mandates (released to Creditor) 1. mandate cancellation request (SDD basic) Debtor Creditor 8. Management & archiving confirm 2. Information mandate cancellation 7. Cancellation confirm 6. Cancellation confirm (SDD basic) (SDD AOS) 3. Mandate cancellation trasnsmission Transmission (SDD AOS) channel 5. Mandate cancellation check & archiving (SDD AOS) Debtor Bank 4. Mandate cancellation trasnsmission Creditor Bank (SDD AOS) 29/48
SEDA: mandate cancellation (2) Cancelling mandates (released or originated by Debtor Bank) Creditor Debtor 5. Check cancellation & archiving SDD (basic) 1. Request mandate cancellation 3. Cancellation confirm close account (SDD AOS) (SDD basic) 2. Manage cancellation request or cancellation origination. Dematerialisation and archiving (SDD AOS) 4. Cancellation confirm 6. Check result transmission (SDD AOS) Transmission channel Debtor Bank 7. Check result transmission (SDD AOS) Creditor Bank 30/48
SEDA: open points Business model Messages and technical infrastructures Governance Debtor bank remuneration ISO 20022 CSMs? ? Rules Transparency 31/48
SEDA: DMF option Collection of mandates by Debtor Bank (optional) Creditor Debtor 5. Mandate related data check & archiving (SDD AOS) 9. Confirmation or reject (SDD AOS) 1. mandate delivery (SDD AOS) 4. Mandate related data transmission 3. Mandate related data ransmission (SDD AOS) 2. Check, mandate dematerialisation & archiving 6. Check result transmission (SDD AOS) Transmission channel (SDD AOS) 8. Management & archiving check results (SDD AOS) Debtor Bank 7. Check result transmission Creditor Bank (SDD AOS) 32/48
SEDA and SDD B 2 C comparison CHECKS BEFORE COLLECTION SDD SEDA Valid IBAN No Yes Valid BIC No Yes No prohibition to accept SDD No Yes No SDD forbidden regulatory No Yes Correlation 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
SEDA and SDD B 2 C comparison CHECKS UPON COLLECTION SDD SEDA Valid IBAN Yes Valid BIC Yes No prohibition to accept SDD Yes No SDD forbidden regulatory Yes Correlation between MIR stored and MIR in collection No Yes Management of creditor black or white list 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 34/48
SEDA and SDD B 2 C comparison FUNCTIONALITIES SDD SEDA Communication of MIR amendments to debtor bank before collection No Yes Communication of MIR amendments to debtor bank in collection 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 Yes Mandate cancellation originated through or by creditor Yes SDD Mandate portability to other bank No Possible Current account portability with existing SDD Mandates No Possible AOS Yes Creditor and debtor bank mandate database continuous alignment No Yes Mandate collection by debtor bank No Possible Creditor bank mandate database 35/48
SEDA and SDD B 2 B comparison CHECKS BEFORE COLLECTION SDD SEDA Valid IBAN No Yes Valid BIC No Yes No prohibition to accept SDD No Yes No SDD forbidden regulatory No Yes Correlation 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
SEDA and SDD B 2 B comparison CHECKS UPON COLLECTION SDD SEDA Valid IBAN Yes Valid BIC Yes No prohibition to accept SDD Yes No SDD forbidden regulatory Yes Correlation between MIR stored and MIR in collection No Yes Verification of mandate validity with debtor Yes Management of creditor black or white list 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 37/48
SEDA and SDD B 2 B comparison FUNCTIONALITIES SDD SEDA Communication of MIR amendments to debtor bank before collection No Yes Communication of MIR amendments to debtor bank in collection 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 Yes Mandate cancellation originated through or by creditor Yes SDD Mandate portability to other bank No Possible Current account portability with existing SDD Mandates No Possible AOS Yes Creditor and debtor bank mandate database continuous alignment No Yes Mandate collection by debtor bank No Possible Creditor bank mandate database 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 Three data sets/messages for six functions DS-14 Creditor to Creditor Bank Advance Mandate Information - Initial Mandate DS-15 Inter-Bank Advance Mandate Information – Initial Mandate Initiation Request (pain. 009. 001. 01) DS-14 Creditor to Creditor Bank Advance Mandate Information – Amended Mandate DS-15 Inter-Bank Advance Mandate Information – Amended Mandate Amendment Request (pain. 010. 001. 01) 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 Acceptance Report (pain. 012. 001. 01) ¹ AMI is an optional SEPA service 40/48
AMI AND SEDA USE ISO 20022 MESSAGES Common Messages ( AMI – SEDA ) Mandate. Initiation. Request ( pain. 009. 001. 01 ) (DS-SEDA-01) Alignment Request of mandate Mandate. Acceptance. Report ( pain. 012. 001. 01 ) DS-SEDA-04) Answer by debtor bank to request for alignment , amendement and cancellation of mandate Mandate. Amendment. Request ( pain. 010. 001. 01) DS-SEDA-02) Request of amendments initiated by creditor SEDA additional Messages Mandate. Amendment. Request ( pain. 010. 001. 01) (DS-SEDA-05); Communication of amendments initiated by debtor bank ( debtor) Mandate. Cancellation. Request ( 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
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 43/48 ISO 20022
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 44/48 collaborative and competitive domain
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
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
New SEPA Governance and End Date DESTROYING IS EASIER THAN BUILDING LET’S HOPE FOR THE BEST ……. . THANK YOU 47/48
Sources of information SEDA ABI = Pierfrancesco Gaggi AITI = Massimo Battistella p. gaggi@abi. it 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 B 2 B SLA- Automatic Reconciliation of Payments IBAN BIC SURVEY EACT = Gianfranco Tabasso = Massimo Battistella 48/48 ¹ See article in the October issue of TMI ( Treasury Management International)
Скачать презентацию HOW TO MAKE SEPA A SUCCESS GIANFRANCO TABASSO
2ee648faafceddbea8c48c51970e2f5d.ppt