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 - UEI
SPECIAL CLAUSES
DMF
ADDITIONALOPTIONAL SERVICES
SEPA COMPLIANT ELECTRONIC DATABASE
ALIGNEMENT
SMART SEPA DD
PSD TRANSPOSITION
EXISTING MANDATE VALIDITY
ART. 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
CreditorDebtor
Bank
► Mandate life cycle► Mandate risk profile► Collections risk profile
MANDATE
DATA
SPECIAL
CONDITIONS
SPECIAL
INSTRUCTIONS
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 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
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
Transmission
channel
Request of confirmation:
Mandatory for B2B
Optional 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
CreditorSDD
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)
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/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/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
Transmission
channel
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 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/48
SEDA: open points
Business model
Messages and technical infrastructures
Governance
Debtor bank remuneration
ISO 20022
CSMs??
Rules
Transparency
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
SEDA and SDD B2C 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 B2C comparison
CHECKS UPON COLLECTION SDD SEDA
Valid IBAN Yes Yes
Valid BIC Yes Yes
No prohibition to accept SDD Yes Yes
No SDD forbidden regulatory Yes Yes
Correlation 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
SEDA and SDD B2C comparison
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 Yes
Mandate cancellation originated through or by debtor bank No Yes
Mandate cancellation originated through or by creditor Yes Yes
SDD Mandate portability to other bank No Possible
Current account portability with existing SDD Mandates No Possible
Creditor bank mandate database AOS Yes
Creditor 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 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 B2B comparison
CHECKS UPON COLLECTION SDD SEDA
Valid IBAN Yes Yes
Valid BIC Yes Yes
No prohibition to accept SDD Yes Yes
No SDD forbidden regulatory Yes Yes
Correlation 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 Yes
37/48
SEDA and SDD B2B comparison
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 Yes
Mandate cancellation originated through or by debtor bank No Yes
Mandate cancellation originated through or by creditor Yes Yes
SDD Mandate portability to other bank No Possible
Current account portability with existing SDD Mandates No Possible
Creditor bank mandate database AOS Yes
Creditor 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
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
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
New SEPA Governance and End Date
SEPA is the rails, switches , lights , etc. one system /one managementPayment 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 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
New SEPA Governance and End Date
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¹
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