Harry Leinonen, Bank of Finland

Transcription

1 The SEPA end game panel Harry Leinonen, Bank of Finland Helsinki, 26 June Harry Leinonen 1

2 SEPA end-game = end-day for legacy services What Why Where When How Who (The honest servants of Rudyard Kipling)

3 What is an end-day? Part of the implementation ti phase of SEPA Legacy service forms and legacy systems are closed down A given end-date is communicated to users/customers A measure to speed up and coordinate the migration process Creates concrete common milestones To what extent will customers oppose forced changes? How to minimise the negative reactions? How to speed up voluntary migration before an end-day? d

4 What is an end-day in concrete terms? Credit transfers SEPA credit transfer rule book implemented IBAN (and BIC) in use XML customer messages in use Card payments Card schemes in line with the SEPA card framework Standardised cards (EMV) and messages (XML?) Direct debits SEPA direct debit rule book implemented IBAN and messages Direct debit mandates according to rule book Are the customers sufficiently interested in the SEPA offer? How to recognise the end-day? day?

5 Why? Standardisation di ti and harmonisation bi bring scale benefits With rapid changes, the benefits are achieved sooner Parallel services/systems increase costs temporarily Common platform for future developments But Change implies costs, and these are higher in hasty projects Costs can be reduced be connecting SEPA changes with other changes Delaying SEPA investments may free funds for other investments Will the customers net benefits from current SEPA be sufficiently high to motivate rapid change? How to communicate customer benefits convincingly?

6 Where? Bank and interbank systems Infrastructures have an earlier end-day than customer services Conversion needs for customer services Automatic IBAN conversion support Customers own systems System updates or conversion modules Account number (IBAN) updates ERP (eg SAP), accounting, cash management etc systems System updates and conversion modules SEPA compatible version X.x assessments How to distribute information to all the parties? How to intensify changes by software providers?

7 When? Rapid change Efficient joint project with general comittment A strong common push towards the new future Gradual change Individual national, bank and customer desires are accommodated Moving in the same direction but without clear timetables Prolonged change SEPA services will just be parallel services with old ones Just nudging towards common standards d How to achieve more commitment to common plans? How to increase the momentum of change? How to avoid general wait&see approach? How to avoid one-sided non-neutral implementation?

8 How? SEPA will be a continuing process SEPA will develop in versions 1.x, 2.x etc AOS services must also be recognised Version management document/library Clear definitions for version content Testing support and assessment board Common testing site(s) would reduce testing work Common assement board would harmonise compatibility stamps How to streamline and standardise implmentation?

9 Voluntary customer drive Who? Big companies want to harmonise and standardise IT service providers can reach a bigger market with the same version SEPA benefits have to be tangible Self-regulation Service providers make joint decisions Should clearly benefit customers, otherwise abuse of market position Regulation Authorities would enforce implementation of new standards Requires clear positive consumer impact How to recognise end-users needs? Will we need authority regulations? How to establish well-balanced regulation interventions?

10 SEPA migration is a big undertaking Immediate need for progress from mini-sepa to e-sepa Banks need to update their C-to-B SEPA services Customers need to experience visible SEPA benefits An end-day will require Service provider commitment Customer interest Authority support A balanced and rapid end-day will be in the customers interest