SEPA: impatti sulle aziende, benefici e rischi dell area unica dei pagamenti in euro.

Transcript

1 SEPA: impatti sulle aziende, benefici e rischi dell area unica dei pagamenti in euro. Milano 6 febbraio 2009 Servizi di Amministrazione Telecom Italia SpA Membro del Consiglio Direttivo AITI

2 SEDA E SSDD AOS DI COMMUNITY PER INCREMENTARE LE PRESTAZIONI DEL SEPA DIRECT DEBIT 1

3 SEDA e SSDD Premesse logiche Le Imprese ritengono che l applicazione degli schemi SEPA Direct Debit determinerebbe: un impoverimento dei contenuti ed un deterioramento della gestione dei rapporti commerciali e delle funzionalità di tesoreria; difficoltà di riscossione dei crediti; un incidenza sul valore degli asset per le aziende caratterizzate da ammontari rilevanti di crediti verso la clientela normalmente incassati con strumenti di addebito diretto in conto. 2

4 SEDA e SSDD Premesse logiche Le Imprese italiane hanno manifestato formalmente le loro posizioni critiche rispetto al SEPA Direct Debit. Dette posizioni sono coerenti con quanto espresso a livello europeo dall EACT e supportato da Business Europe, UEAPME e CAST Projects. Il 5th Progress Report sulla SEPA pubblicato dalla BCE a luglio 2007 ha riconosciuto l'esigenza che i nuovi strumenti SEPA non determinino un peggioramento dei livelli di servizio attualmente offerti a livello nazionale. 3

5 SEDA e SSDD Premesse logiche Lo stesso Piano di Migrazione Nazionale approvato nel maggio 2007 riporta testualmente quanto segue: "I partecipanti al Comitato Nazionale assumono l impegno di collaborare in modo proattivo affinché la realizzazione della SEPA non comporti regressioni quanto alle funzionalità che caratterizzano gli attuali servizi di incasso e pagamento. In particolare, qualora non si riuscissero a soddisfare i fabbisogni degli utilizzatori finali italiani mediante gli strumenti previsti dai Rulebook, sarà compiuto ogni possibile sforzo per colmare con tempestività attraverso adeguati AOS i divari tra strumenti basic e quanto oggi offerto dal sistema bancario italiano al mercato." 4

6 SEDA e SSDD Premesse logiche La Task Force del Forum di Consultazione Imprese del Comitato Nazionale di Migrazione alla SEPA, sulla base dell analisi delle esigenze delle Imprese, ha elaborato una proposta di servizi integrativi addizionali rispetto a quelli base del SEPA Direct Debit (di fatto, un c.d. Community AOS ). La disponibilità di detti servizi condiziona l effettiva migrazione delle Imprese italiane alla SEPA (cfr. Piano Nazionale di Migrazione alla SEPA). 5

7 SEDA e SSDD Premesse logiche In particolare sono stati valutati e sono stati oggetto di consultazione tra banche e imprese i seguenti AOS di sistema: il Servizio SEDA SEPA-compliant Electronic Database Alignment gestione del mandato ad iniziativa del Creditore e, scegliendo la specifica opzione, anche ad iniziativa della Banca del Debitore; il Servizio SSDD Smart SEPA Direct Debit Cross reference tra SEDA e processo di incasso SDD. 6

8 SEDA e SSDD Perché sono necessari Il Servizio SEDA è un AOS avente lo scopo di allineare, in termini di sicurezza e funzionalità, lo schema previsto dagli attuali Rulebooks Core e B2B, ai livelli garantiti dall operante schema nazionale (RID raccolta mandato presso il Creditore + AEA). La stessa procedura gestirebbe altresì, in via facoltativa, le funzionalità dell attuale schema nazionale (RID raccolta mandato presso Banca Debitore + AEA) per la raccolta del mandato SEPA DD presso la banca del debitore; Il Servizio SSDD è un AOS atto a consentire la gestione, secondo gli standard del SEPA DD, delle collections relative ai mandati oggetto dell AOS precedente. 7

9 SEDA e SSDD Perché sono necessari Si tratta di servizi che garantiscono la sincronizzazione tra cicli di fatturazione, procedure di incasso e assetti contrattuali tra creditore, debitore e banche coinvolte e che assicurano elevate performances sia per le imprese sia per le banche sia per i consumatori, in termini di: sicurezza nei rapporti tra il debitore e la propria banca; sicurezza nei rapporti tra il creditore e il debitore; elevati livelli di STP E2E; rapidità nello scambio delle informazioni; chiara definizione delle responsabilità e dei profili di rischio; elevata consistenza delle risultanze gestionali espresse nel bilancio del creditore (certezza dell incasso); flessibilità rispetto ai variegati schemi di business delle imprese. 8

10 SEDA Principali funzionalità Le principali funzionalità del SEDA includeranno: Verifica dei dati del mandato da parte della banca del debitore immediatamente dopo l emissione del mandato ed antecedentemente alla prima richiesta d incasso; Archiviazione dei dati del mandato nei database della banca del debitore; Uso di codifiche per consentire la gestione STP delle anomalie tra creditore e banca del debitore; Scambio delle modifiche al mandato originate sia presso il creditore che presso la banca del debitore; Identificazione e differente trattamento da parte della banca del debitore delle richieste di pagamento legate a mandati precedentemente controllati tramite SEDA. 9

11 SEDA VERIFICA MANDATO RACCOLTO PRESSO CREDITORE Invio richiesta di conferma: Obbligatoria per B2B Opzionale per B2C (in base ad accordi con il debitore) Debitore 6. Invio risultati verifica 1. emissione mandato (SDD basic) Canale di Trasmissione 8. Gestione ed archiviazione risultati verifica e riscontri effettuati con il debitore 7. Invio risultati verifica Creditore 2. Archiviazione dati mandato (SDD basic) 3. Invio dati mandato 5. Verifica ed archiviazione dati mandato Banca del Debitore 4. Invio dati mandato Banca del Creditore 10

12 SEDA VERIFICA MANDATO RACCOLTO PRESSO CREDITORE Esempi di verifiche da parte delle banca del debitore su dati contenuti nel mandato : Corrispondenza tra titolare del conto e sottoscrittore del mandato basata sul Codice Identificativo del debitore*; Validità e corrispondenza dell IBAN; Validità e corrispondenza del BIC; Esistenza di proibizione ad accettare SDD; Esistenza di proibizioni regolatorie all SDD; Parametri di servizio invalidi. * Tema connesso a UEI/poteri di firma. 11

13 SEDA GESTIONE MODIFICHE RACCOLTE PRESSO CREDITORE Invio richiesta di conferma: Obbligatoria per B2B Opzionale per B2C (in base ad accordi con il debitore) Debitore 6. Invio risultati verifica 1. Modifica mandato (SDD basic) Canale di Trasmissione 8. Gestione ed archiviazione risultati verifica e riscontri effettuati con il debitore 7. Invio risultati verifica Creditore 2. Archiviazione modifica dati mandato (SDD basic) 3. Invio dati mandato 5. Verifica ed archiviazione dati mandato Banca del Debitore 4. Invio dati mandato Banca del Creditore 12

14 SEDA CANCELLAZIONE MANDATO RICHIESTA AL CREDITORE Invio informazione richiseta cancellazione (SDD BASIC) Debitore 6. Invio risultati verifica 1. Richiesta cancellazione mandato (SDD basic) Canale di Trasmissione 8. Gestione risultati verifica e conferma cancellazione 7. Invio risultati verifica Creditore 2. Archiviazione cancellazione (SDD basic) 3. Invio informativa cancellazione 5. Verifica ed archiviazione cancellazione Banca del Debitore 4. Invio informativa cancellazione Banca del Creditore 13

15 SEDA RACCOLTA MANDATO PRESSO BANCA DEBITORE (Opzionale) Debitore Creditore 5. Verifica dati mandato ed archiviazione (SDD Basic) 1. Emissione mandato 2. Verifica mandato, estrazione ed archiviazione dei dati 8. Gestione ed archiviazione risultati verifica Banca del Debitore 9. Invio conferma o diniego 3. Trasmissione dati mandati Canale di trasmissione 4. Trasmissione dati mandato 7. Invio risultati verifica Banca del Creditore 6. Invio risultati verifica 14

16 SEDA GESTIONE MODIFICHE RACCOLTE O ORIGINATE DA BANCA DEBITORE (Opzionale) Debitore Creditore 5. Verifica dati mandato ed archiviazione (SDD Basic) 1. Modifica mandato 2. Verifica modifiche o emissione modifiche, estrazione ed archiviazioene dei dati 8. Gestione ed archiviazione risultati verifica Banca del Debitore 9. Invio conferma o diniego 3. Trasmissione dati mandati Canale di trasmissione 4. Trasmissione dati mandato 7. Invio risultati verifica Banca del Creditore 6. Invio risultati verifica 15

17 SEDA GESTIONE MODIFICHE RACCOLTE/ORIGINATE DA BANCA DEBITORE (Opzionale) Esempi di modifiche al mandato gestite od originate della banca del debitore: Richiesta del debitore di rifiutare future collections in relazione al mandato; Richiesta del debitore di trasferire il conto corrente presso altro istituto; Modifiche dell IBAN; Modifiche del BIC. 16

18 SEDA CANCELL.NE MANDATO RACCOLTA/ORIGINATA DA BANCA DEBITORE (Opzionale) Debitore Creditore 5. Verifica cancellazione ed archiviazione (SDD Basic) 1. Richiesta cancellazione mandato/chiusura conto (SDD BASIC) 9. Invio conferma o richiesta informazioni in caso di diniego 3. Invio informativa cancellazione 4. Invio informativa cancellazione 6. Invio risultati verifica 2. Gestione o emissione richiesta cancellazione, archiviazioene dei dati 8. Gestione ed archiviazione risultati verifica Banca del Debitore Canale di trasmissione 7. Invio risultati verifica Banca del Creditore 17

19 SEDA CANCELL.NE MANDATO RACCOLTA/ORIGINATA DA BANCA DEBITORE (Opzionale) Esempi di cancellazioni gestite od originate dalla banca del debitore: Richiesta di cancellazione mandato da parte del debitore; Richiesta di chiusura conto da parte del debitore; Conto corrente chiuso d iniziativa banca; Conto corrente chiuso per motivi regolatori; Conto corrente bloccato dalla banca. 18

20 SSDD Principali funzionalità Le principali funzionalità del SSDD includeranno: l inserimento nella collection SDD di un ulteriore informazione (cross reference SEDA) definita a livello di AOS community ; l esecuzione da parte della banca del debitore di una verifica sulla presenza della cross reference SEDA al fine di identificare che il mandato è già stato processato attraverso la procedura SEDA; in presenza della cross reference SEDA, la disposizione è processata in conformità ai dati del mandato ricevuti tramite SEDA e archiviati presso la banca; in assenza della cross reference SEDA, la disposizione è processata come previsto dai Rulebooks SDD. 19

21 UEI UNIQUE ENTITY IDENTIFIER IDENTIFICATIVO UNIVOCO DEGLI UTILIZZATORI DEI SISTEMI DI PAGAMENTO 20

22 UEI Premesse logiche Le modifiche autonomamente previste dall industria bancaria per regolamentare i rapporti tra intermediari nell area unica dei servizi di pagamento (Single Euro Payments Area SEPA) hanno impatti di rilievo in termini di verifica dell identità delle controparti nel corso delle transazioni monetarie. Tali impatti diverranno ancor più critici nel più ampio sistema economico di riferimento che, tra l altro, comprenderà una pluralità di giurisdizioni, quantunque ne sia prevista una certa armonizzazione a seguito della trasposizione nelle legislazioni nazionali della Direttiva sui Servizi di Pagamento (Payment Services Directive -PSD). 21

23 UEI Premesse logiche Nel contesto del sistema dei pagamenti, il concetto di identificazione è strettamente connesso con quello di rischio. È infatti essenziale avere certezza: che la controparte della transazione sia quella effettivamente destinataria dei fondi; che i fornitori di servizi di pagamento (banche e altri intermediari, operatori professionalmente qualificati per la loro identificazione) siano in grado di garantire tale verifica. Le legislazioni nazionali della maggior parte degli Stati Membri - Italia inclusa - si basano attualmente su questi presupposti e su tali basi si sono finora sviluppati i processi di electronic banking. 22

24 UEI Premesse logiche Considerate le numerose varianti testuali cui è possibile associare uno stesso nominativo o denominazione di un ente, in molti casi lo sviluppo delle transazioni elettroniche ha dato origine a codifiche di logistica delle transazioni. I codici identificativi delle controparti attualmente utilizzati nell ambito dei sistemi di pagamento, ove esistenti, sono generalmente carenti in quanto: non universali - sono legati a specifici contesti operativi o comunità di utilizzatori; non sempre accurati - ad esempio, consentono di associare più di un identificativo alla stessa controparte (come nel caso del codice SIA utilizzato in Italia per codificare le imprese nell ambito del sistema interbancario). 23

25 UEI Premesse logiche I processi gestiti secondo i canoni dello Straight Through (STP o modalità passante ) cioè gestiti automaticamente dai sistemi informatici e di telecomunicazioni senza o con limitato intervento umano richiedono la disponibilità di identificativi univoci e certi affinché in tutti i sistemi e sottosistemi informativi interessati dal processo si possano automaticamente individuare in real time e in modo non ambiguo le entità coinvolte. 24

26 UEI Premesse logiche Nell industria dei servizi di pagamento, è pertanto da tempo emersa la consapevolezza della necessità di sviluppare un identificativo universale - Unique Entity Identifier - che possa: conferire certezza real/near time nell identificazione delle controparti nel corso delle transazioni; semplificare i processi di riscontro e riconciliazione; abilitare l immediata attribuzione delle partite di pertinenza a ciascuno dei soggetti interessati dagli scambi e dai regolamenti, anche ai fini della gestione dei rischi e del reporting; facilitare le attività di due diligence verso le autorità e gli altri stakeholder richieste nella gestione delle transazioni monetarie e finanziarie. 25

27 UEI Evoluzioni in corso Iniziative in ordine alla definizione di standard per la codifica internazionale dei soggetti coinvolti nelle transazioni finanziarie e monetarie sono state avviate nel tempo, in particolare: dall ISO Technical Committee 68/SC4/WG8, che ha elaborato una proposta per definire un International Business Entity Identifier (IBEI) basato su una estensione alle imprese, in particolare a quelle operanti sui mercati finanziari, del Bank Identifier Code (BIC). da ISO e SWIFT per estendere l uso della codifica BIC alle istituzioni non finanziarie operanti sulle piattaforme SWIFT (p.e. MACUGs). 26

28 UEI Evoluzioni in corso Anche la PSD prevede un Identificativo Unico, in particolare l Art 4-21 lo definisce come: la combinazione di lettere, numeri o simboli che il prestatore dei servizi di pagamento indica all utente di servizi di pagamento e che quest ultimo deve fornire per identificare con chiarezza l altro utente del servizio di pagamento e/o il suo conto di pagamento per un operazione di pagamento 27

29 UEI Evoluzioni in corso Nell ambito degli sviluppi dei nuovi strumenti di pagamento della SEPA, sono state previste dall EPC alcune codifiche dei soggetti a diverso titolo coinvolti nelle transazioni: SEPA Credit Transfer: Originator identification code SEPA Credit Transfer: Identification code of Originator Reference Party SEPA Credit Transfer: Beneficiary identification code SEPA Direct Debit: SEPA Direct Debit: SEPA Direct Debit: SEPA Direct Debit: Creditor identifier Debtor identification code Identification code of Debtor Reference Party Identification code of Creditor Reference Party 28

30 UEI Evoluzioni in corso Per quanto concerne il Creditor Identifier da utilizzarsi nei SEPA DDs, l EPC, ha definito gli attributi di tale identificativo, stabilendo che sia composto da 35 caratteri e sia costruito secondo le seguenti regole: Posizioni N. Car. Descrizione Paese dove l identificativo viene emesso Check digits Business code del Creditore (ZZZ in caso non sia utilizzato) Identificativo nazionale del Paese ove il soggetto risiede 29

31 UEI La posizione delle Imprese La definizione di un UEI veicolabile tramite i fornitori di servizi di pagamento ed utilizzabile secondo i canoni dello STP, assume enorme importanza per le imprese in quanto consentirebbe: incrementi nei livelli di automazione della gestione amministrativa e contabile dei regolamenti monetari; semplificazioni nelle codifiche anagrafiche presenti nei sistemi aziendali di customer relationship management, di logistica, di contabilità, di tesoreria; riduzione nei rischi operativi derivanti dalla gestione delle citate anagrafiche e delle integrazioni tra i sistemi nei quali le stesse sono presenti; incremento nella sicurezza delle transazioni monetarie, per la possibilità di effettuare un controllo automatico tra intestatario del conto e beneficiario/esecutore del pagamento. 30

32 UEI La posizione delle Imprese La definizione di un identificativo del titolare del conto è poi necessaria per consentire le funzionalità di controllo: sui sottoscrittori dei mandati SEPA Direct Debit nell ambito della SEDA; sulla coerenza tra beneficiario del pagamento e titolare del conto, non previsto dal Rulebook SEPA Credit Transfer e per il mantenimento del quale gli utilizzatori finali dei sistemi di pagamento hanno richiesto l elaborazione di uno specifico AOS nazionale di comunità. 31

33 UEI La proposta delle Imprese In vista della migrazione alla SEPA, si propone: di utilizzare il codice univoco antiriciclaggio e antiterrorismo, basato sul Codice Fiscale, quale riferimento nazionale per la costruzione Creditor Identifier nel SEPA Direct Debit; di introdurre una codifica standardizzata delle controparti interessate dai servizi di pagamento; di estendere quindi a tutti gli identificativi di controparte previsti negli schemi SEPA le logiche di costruzione della codifica prevista per il Creditor Identifier nel SEPA DDs; di utilizzare il codice unico antiriciclaggio e antiterrorismo quale riferimento nazionale per la costruzione del Codice Identificativo Unico degli utilizzatori finali dei servizi di pagamento previsto dalla PSD. 32

34 Grazie per l attenzione Massimo Battistella Massimo.Battistella@Telecomitalia.it Mobile