8th SEACEN-CPSS Advanced Course on Payment and Settlement Systems For Emerging Economics The Importance of Modern and International Retail Payment Standards Harry Leinonen 23 March 2010 The views expressed are those of the author and do not necessarily reflect the views of the Bank of Finland. 23.3.2010 Harry Leinonen 1
Introduction 2
Global standards are common in most industries i and especially in networks/communications Container shipping Flight ticketing Telecommunications, Internet Data processing, office systems Photography, video, audio etc entertainment Etc etc Common standards have been the basis for international connections and scale benefits 3
The payment industry has been an exception, with few international standards Credit transfer and direct debit schemes and standards are domestic or even proprietary Card payments are often domestic variants based on international standards International card payment standards/services are linked to closed branded d networks E-banking connections usually based on proprietary standards Data content and key structures vary considerably Payments currently processed less efficiently than they would be with on open global standards 4
Development incentives and disincentives for standards Forces pushing for change Strive for higher productivity New dominant Sufficient competition payment Examples in other industries standard Customer demand Authority actions Old dominant payment standard Forces maintaining status quo Legacy investments Monopolistic structures Invisible cost benefits Coordination problems Regulatory requirements Banks and customers have different development priorities for payment services 5
Banks have an interest in Delaying investments (receive same income without new investments as all pay their bills anyway) Reducing competition via domestic proprietary customer standards, monopoly payment processors (ACHs) and hidden charging g conventions (float etc) Customers have an interest in Investments in standards which support e-integration Increased competition via open standards Authorities can promote customer interests by maintaining structures supporting open competition and open efficient standards Note! Regulation can also stifle development 23.3.2010 Harry Leinonen 6
Payment standardisation di ti dimensions i Data content presentation and message standards Network address space and interbank trunk network Database access keys and integration support Versatility of accompanying data content Identification and security (encryption) standards Maximum standardisation benefits require good solutions for all dimensions 7
1. Data content presentation and message standards 8
Sending customer Two levels of payment standards (bank-to-bank and customer-to-bank) Customerto- bank standards Sending bank Interbank standards and processing Area of pure bank cooperation Recieving bank Customerto- bank standards Area of customer, bank and authority cooperation Recieving customer For end-to-end STP (Straight-Through-Processing) common standards are needed, both interbank and vis-à-vis customers 9
Necessary customer-to-bank payment standards Payer Payee Sending Payer s Payee s Sending - credit transfers bank bank - e-invoices - sending direct - direct debits debit mandates - card payments - accepting e-invoices i Receiving Receiving - payment notifications - e-invoices - credit transfers - direct debits - direct debits - card payment info - card payments - statements of accounts - direct debit mandates - statements of accounts Common standards facilitate direct reuse of same data within payer s and payee s systems. Common e-standards are the basis for efficiency. 10
ISO 20022 XML will be the SEPA payment standard Same standard for interbank and customer-to-bank transfers as well as internal customer processing Same standard across payment instruments credit transfers and direct debits and possibly also for card payments Large data content possibility covering both banks and customers processing needs ISO 2022 developments are supported by SWIFT and is the basis for SEPA payments in Europe ISO 20022 could develop into a common Financial Transfer Message (FTM) for all kinds of payments and related processing 11
XML data description standard = tags + attributes in a common version-based library Data field naming using tags eg DueDate Attributes describing characteristics eg type= xs.date Schemes for defining data content eg <xs:element name DueDate>type= xs.date /> D t /> Files with tag and data eg <DueDate>2007-05-20</DueData> 05 Style sheets for presenting data using different media/languages eg paper, screen, etc XML scheme XML file XML style sheet Listing Prog- ram The same data can as such be used for several purposes and in several languages 12
Payments affected via a chain of servers using the same basic XML Financial Transfer Message (=FTM) Payer s processes Banks processes Payee s processes Od Ordering system FTM Payablesables FTM Customer payment system FTM C2B interface system/ network FTM FTM FTM FTM Bank Bank Inter- Bank Bank Account FTM payment FTM Bank payment Account system system system/ system system network C2B interface system/ network FTM FTM FTM Customer payment system Receivable Shipment Invoicing system FTM Same schemes and tags (=data descriptions in all processes 13
ISO MG stripe CARD ISO Contactless CARD JAVA Example: card/eftpos developments Standard PC with EFTPOS appl. or special EFTPOS terminal ISO CHIP CARD JAVA ISO Digital MobileC JAVA Point of sale appl. ISO card interface ISO XML e invoice info EFTPOS application JAVA Acquirer s system ISO 20022 XML Acquirer message ISO 20022 XML Authorisation message Payment network ISO 20022 XML Issuer message Even the partly globally standardised cards will require a new round of standardisation Issuer s system ISO 20022 XML Purchase details message Card holder 23.3.2010 Harry Leinonen 14
Will cards be digitalised and stored in mobile phone? Manual vs digital? A mobile phone could store details of all cards and select the correct card based on parameters and learning Easier to provide and update cards completely remotely over the air Back-ups safely in the network and down-loadable in case of hardware failures or loss of phone A stepwise move from manual to digital, with parallel l usage possibilities 15
Mobile Payments: Push & Go + eticket Select event via network or locally from info-tags (RFID) Pay for ticket t via mobile Receive ticket via mobile Enter event by showing mobile to automatic gate Check seat from mobile Ordering everywhere secure e-tickets, automated entrance control, black market barrier, etc electronic possibilities 16
2. Network address space and interbank trunk network 17
IBAN, International Bank Account number (ISO 13616) IBAN BE62 5100 0754 7061 Recognition tag Country code International check digits Domestic account number An international account address standard is the very basis for STP Compare with - international telephone numbers - international email-addressesaddresses IBAN will be the basic account number in SEPA-region. IBAN is becoming popular also in other countries. 18
Payment processing requires one or more networks and network addresses for accounts Bank 1 Payment TCP/IP- Internetnetwork Payment Payment Payment Bank 2 Bank 3 Bank n In a modern network infrastructure, payments are sent via automated routing directly to receiving banks (like emails to email boxes). Account numbers need to be standardised = IBAN (international bank account number) for efficient routing just as card numbers have been standardised 19
3. Database access keys and integration support 20
Standardised database keys = addresses and references - Inquir Functional level ies Initia- Debit- Credit- - Recon- tion ing ing ciling Identifiers Payer s reference Payer s IBAN Transacion Transact- ID Payee s IBAN Payee s reference Application level Payer s system Bank s system Bank s system Payee s system Database level Accounts Accounts Orders Transations Transactions Invoices Payables Receivables Standardised keys facilitate automatic reconciliation 21
Payment reference = key to receiver integration Payer s bank Beneficiary s bank Reference number e-statements cycle e-receipts Customer-to-customer Invoice 123 123 Reference number provided d by beneficiary follows payment back to beneficiary for automated update of receivables. Payer (E-)billing Beneficiary Receivables General ledger Reference numbers required by big invoicers. Just a number with a common control digit. 22
Structured creditor reference number ISO RF standard d proposal (SEPA rulebooks 2010) 0) RF cc 12345689012345678901 Data ID Payee provided number for automatic reconciling Common standardized check digit In spite of its simplicity, RF is the basis for payee STP benefits 23
Reciever reference basis for customer automation benefits ISO standardisation proposal for RF code standardisation Receiver s account numbers Receiver Reference/reconciling number Sum to be paid Payer 94,9090 24 Bar code containing payment data Due date
4. Versatility of accompanying data content 25
E-invoices = expanded payments Data processing limitations minimised the accompanying remittance data Today, these limitations have disappeared and payments can efficiently contain any amount of accompanying data Synergies and efficiency can be gained by combining payment and invoice data into e-invoices processed as payments Savings can be over 30 euro/invoice and therefore more than EUR 50 b per year in the euro area alone E-invoicing is the largest single cost saving opportunity available in daily business administration E-invoicing i i requires expanded dpayment standards d 23.3.2010 Harry Leinonen 26
Basic automation benefits of e-invoicing (corporates) Electronic sending - no printing i on paper - no envelopes - just a file to the bank Invoic- ing database Creditor/ Payee Creditor/ Payee Electronic reception of payment - no paper notifications - automated reconciling of receivables based on reference code -just a file from the bank - easy to archive Secure electronic Electronic reception transportation - no letters to open - no physical processes - no data to key in - no stamps - just direct e-input - verified sender by banks - easy to archive Debtor/ Invoice transportation Payer Pay- ables database Funds Debtor/ transportation Payer Electronic fund transportation - all relevant information included Electronic payment initiation - no paper instructions - no data key-in - direct use of e-invoice as e-credit transfer Cost savings in the range of at least EUR 10-30 per invoice 27
E-invoicing alternatives Direct customer-to-customer (like mail today) Payer s Payee s eg via emails, but connection, addressing bank bank and security problems works among large companies BizTalk network developments may Payer Payee change the situation in future e-invoice hotels plus roaming among them special operators connecting and converting formats how to build sufficiently wide roaming space? possible temporary solution until common international standards Payer s Payee s bank bank Payer e-invoice hotel Payee Bank provided service routed using IBANs over interbank Payer s Payee s payment networks bank bank works generally, available for all kinds of companies especially suitable for consumer billing Payer Payee 28
SEPA e-billing via bank system Customer ID and acceptance control 4) Interbank payment transfer Payer s bank Payee s bank 2) Interbank invoice 3) Explicit transfer Payment/invoice 1) Invoice 5) Payment acceptance transfer reception Payer Payee e-invoices transferred via banks from payee to payer for explicit acceptance as part of credit transfer or a direct debit service (with more info). Routing based on payer and payee IBANs. 29
e-account statements = e-invoice archives Credit transfers + e-invoice i e-statement 1 Direct payments + invoices debits + e-invoice i e-statement n Card payments + invoices payments ecustomers view + e-invoice i ebank accounts Electronic account like email accounts statement consists of individual payments incl. invoices plus totals Easy browsing of banks systems for invoicing information or customers copies of e-statements 30
5. Identification and security (encryption) standards 31
Physical customer & account idenfication device Security by physical items, passwords and recognisable features Remote access require a secure physical identification device Electronic secure password generator Chip card Mobile telephone security feature Mobile payment Common standards are needed for world-wide customer identification Common security standards would speed up developments and improve the security level 32
Network of identification service providers Customers need to identify themselves to several e-service providers in an open global e-world The open Internet Customer s Customer secure identification ID provider The network of connected identification providers Service providers identification ID provider Service providers identification ID provider Registration office Bank Taxation authority Insurance company Social security office A common secure eid service is needed to build thrust within an m-to-n communication setup, (e-)payments must be secure 33
Internet and standard PCs are too open Relative easy to distribute viruses and spyware Trojan horses ( Main in the middle ) can seize control of the PC and e-identity read and change keyboard input change screen output change file content change sent transactions and information Customers will need hardware-protected keyboards, screens, storage and security processors. Mobile phones can be the security solution. 34
Mobile phones could become general authentication devices Mobile phones can use the SIMs (Subscriber Identity Module) for general authentication (access control, e-signatures, e-identification etc) Which will be the preferred technical solution? TELCO-, bank- or handset provider-based development? Could it be based on joint cooperation among all stakeholders incl. authorities (as in the case of Turkey) 35
Concluding remarks 36
International payment standardisation bodies ISO, International Standardisation Organisation, official CEN, European Committee for standards, official SWIFT, bank driven, international payments EMV, Mastercard&Visa driven, chip card authorisation EPC, European Payment Council, euro-payment standards (includes former ECBS Eurpean Committee for Banking Standards), d bank driven TWIST, user-driven, e-invoicing etc Topical issues in these bodies - General payment standards (ISO 20022) - Mobile payment standards - e-invoicing standards How to ensure interoperability and cooperation? 23.3.2010 Harry Leinonen 37
Governance issues in standardisation How to ensure inclusion of customer views? How to further openness and competition? How to support rapid developments and avoid lock-ins in old standards? How to select the efficient routes among several alternatives? How to find the balance and good timing between legacy investments and renewal needs? How to move from domestic markets to international ti communications? Increased authority involvement (recommendations, regulations etc) seems to be the solution for improvement of payment processing governance 23.3.2010 Harry Leinonen 38
Thank you for your attention. Questions? 39
More information in BoF publication A:111 Harry Leinonen: Payment habits and trends in the changing e-landscape 2010+ 40