Roberto Garavaglia
Questa mattina, 23 febbraio 2017, come annunciato da PagamentiDigitali un paio di giorni fa, l’Autorità Bancaria Europea ha rilasciato la bozza finale del degli standard tecnici di regolamentazione in tema di autenticazione forte del cliente e comunicazione sicura ai sensi della PSD2.
A una primissima lettura (scrivo questo articolo dopo aver letto rapidamente le oltre 150 pagine di cui è costituito il documento), l’immagine che mi si palesa, difficilmente sfugge ad una libera associazione: elastoplasticità, ossia la proprietà dei corpi che, soggetti a particolari sollecitazioni, subiscono deformazioni di tipo plastico associate a deformazioni di tipo elastico.
Così è ciò che mi appare la bozza finale degli standard tecnici di EBA, testé diffusa. Un documento che, posto (ed esposto) a consultazione pubblica nell’estate dello scorso anno, ha ricevuto ben oltre 220 commenti, raggruppando un totale complessivo di circa 300 differenti perplessità e richieste di chiarimento, sollevate e postulate dai diversi rispondenti. Una siffatta mole di pareri, opinioni e riscontri, che aveva così indotto l’Authority a comunicare, il 29 novembre 2016, un ritardo, rispetto all’end-date indicata dal legislatore europeo per il 13 gennaio 2017, di almeno un mese, per il rilascio degli strandard tecnici in Final Draft[1].
Ma vengo subito al punto e, in questo primo breve commento, evidenzio ciò che, a mio avviso, meglio spiega l’analogia elastoplastica, ossia quali sono le modifiche che, rispetto alla precedente versione del testo regolativo, appaiono più rilevanti.
L’estensione d’esenzione dell’applicazione di autenticazione forte
Come sempre, è bene ricordare un ossimoro quanto mai attuale, ossia quello che lega usabilità e sicurezza, la cui (ri)soluzione è determinante per il successo di molti servizi di pagamento, in particolare quelli più innovativi. Ciò premesso, allargare le maglie del perimetro di dispensa, per quanto attiene l’obbligo di applicare meccanismi di autenticazione forte del cliente, quando il pagatore:
a) accede al proprio conto di pagamento on line;
b) dispone un’operazione di pagamento elettronico;
c) effettua qualsiasi azione, tramite un canale a distanza, che può comportare un rischio di frode nei pagamenti o altri abusi,
è qualcosa su cui è opportuno riflettere, laddove gli effettivi impatti sull’esperienza digitale del pagamento, possono produrre una maggiore semplificazione a discapito di una minore sicurezza.
La proposta di EBA diffusa in consultazione lo scorso anno, imponeva di applicare per tutte le operazioni di pagamento superiori a 10 Euro che si compiono in remoto (ossia tramite un canale a distanza come l’internet o la rete mobile cellulare), un sistema di autenticazione forte dinamica che leghi elementi quali l’importo ed il beneficiario, nel processo di riconoscimento già basato su più fattori tra loro indipendenti, nel dominio del possesso, della conoscenza e dell’inerenza.
Nelle specifiche finali rilasciate questa mattina, sono state introdotte due nuove deroghe all’applicabilità dell’autenticazione forte, ed una modifica alla dispensa prevista per i micropagamenti.
È stato infatti previsto che il prestatore dei servizi di pagamento (p.e. una banca) possa essere esentato dall’applicare l’autenticazione forte (e dinamica) del cliente, basandosi su una specifica analisi del rischio associato alla transazione stessa (la c.d. “TRA Transaction Risk Analysis”). I sistemi di monitoraggio della transazione che supportano la TRA, tengono conto, ad esempio, del comportamento dell’utente in situazioni normali. relativamente all’uso delle proprie credenziali di sicurezza. Oppure, si basano sulle valutazioni di alcuni fattori base di rischio, fra cui: il numero di elementi di sicurezza compromessi o rubati, i segni di evidente infezione da malware in qualsiasi sessione di autenticazione, l’importo di ogni transazione, la conoscenza aprioristica di frodi.
Distinguendo in due tipologie di pagamento remoto, ossia quello che si compie mediante una carta (p.e. via internet) e quello che si ottiene disponendo un bonifico (p.e. tramite un dispositivo mobile), EBA dispone che l’applicazione della TRA sia possibile nel rispetto di specifichi limiti d’importo, per i quali sono stati calcolati ed associati coefficienti – in percentuale – del tasso di frode, ossia osservando la conformità a una tabella di scoring prevista negli standard.
Al fine di poter esimere un prestatore di servizi di pagamento dall’applicazione dell’autenticazione forte, l’adesione in conformità a tale tabella deve avvenire in combinato disposto con la verifica delle seguenti condizioni, che, ove ricorressero, vanificherebbero la dispensa stessa: l’identificazione di un comportamento di spesa anomalo o l’uso di strumenti di pagamento “nuovi” per la transazione in fieri (ossia non precedentemente identificati), il luogo in cui si trova l’utilizzatore mentre compie il pagamento.
Un’ulteriore deroga alla Strong Authentication è stata inoltre prevista per quelle transazioni che si compiono su terminali non presidiati, finalizzate al pagamento di parcheggi (p.e. presso i parcometri) e titoli di trasporto (p.e. presso le “macchinette” che vendono i biglietti del tram).
Anche per quanto attiene i limiti d’importo relativi alle operazioni di micro-pagamento che si compiono remotamente, il tetto è stato triplicato, innalzandolo a 30 Euro.
Rimangono invece confermate le esenzioni per i pagamenti contactless su terminali POS inferiori a 50 Euro, a patto che dall’ultima volta in cui sia stata applicata l’autenticazione forte, l’importo complessivo delle transazioni non superi i 150 Euro o non siano stati superati 5 pagamenti consecutivi effettuati dal singolo individuo.
Permangono altresì le deroghe per in cc.dd. “Beneficiari trusted”, per le quali viene estesa la validità a qualsiasi pagamento remoto, ossia non solo il bonifico.
L’accesso ai conti e l’interfaccia che deve essere resa disponibile
Per quanto attiene l’annoso tema dell’accesso ai conti, EBA ha precisato che vi è l’obbligo per gli ASPSP (ossia per i prestatori di servizi di pagamento che forniscono e amministrano un conto di pagamento, quali ad esempio le banche o le Poste) di proporre almeno un’interfaccia per gli AISP (prestatori di servizi di pagamento che eserciscono servizi di informazione sui conti – o Account Information) i PISP (prestatori di servizi di pagamento che eserciscono servizi di disposizione di ordine di pagamento – o Payment Initiation) e per i PSP che emettono strumenti di pagamento basati su carte (le cc.dd. “Decoupled Debit Cards”), per la quale siano garantiti i medesimi livelli di servizio offerti ai propri clienti.
Nel merito dell’interfaccia che deve essere esposta dagli ASPSP, gli standard tecnici rilasciati questa mattina, riferiscono a due tipologie:
- Interfaccia consueta
- Interfaccia dedicata
La prima tipologia di interfaccia rappresenta quella mediante cui l’ASPSP rende comunemente accessibile – online – i conti ai propri clienti (p.e. l’interfaccia dell’Home Banking). Nel consentire l’uso in sicurezza di tale accesso, EBA tuttavia richiama ciò che la PSD2 ha ampiamente chiarito (già a suo tempo …) in merito all’obbligo che i TPP debbano potersi identificare presso gli ASPSP acceduti; in tal senso, l’Autorità dispone per i TPP che non si identificano ed usano le tecniche altrimenti note di “screen scraping”, il divieto di operare dal termine del periodo transitorio previsto dalla direttiva, ossia 18 mesi dopo l’entrata in vigore. Parimenti, a far data del medesimo termine, gli ASPSP potranno rifiutarne l’accesso.
L’interfaccia dedicata, può essere invece implementata ex novo dagli ASPSP, anche basandosi sull’impiego del protocollo ISO20022, ma deve comunque garantire gli stessi livelli di servizio offerti ai propri clienti tramite l’interfaccia consueta.
In merito a questa tipologia d’interfaccia, ricordo quanto in più occasioni ho avuto l’opportunità di spiegare: EBA non obbliga gli ASPSP allo sviluppo di API (Application Programming Interface), tuttavia ritiene apprezzabile un’intesa sulla idoneità dell’uso, da parte dell’industry coinvolta (banche, e, in generale, qualsiasi ASPSP).
In altri termini, gli ASPSP avranno la possibilità e il vantaggio di identificare nelle API l’interfaccia più congrua per farsi “accedere”. Pur non essendo imposte, esse rappresentano tuttavia una grande opportunità per tutti i prestatori di servizi che forniscono e amministrano un conto di pagamento, un mezzo mediante il quale è possibile conseguire un triplice obiettivo di compliance, strategia e riprogettazione degli asset tecnologici[2].
L’impiego dei certificati emessi da Identity Provider eIDAS
Anche in questo caso, EBA conferma che, ad entrata in vigore degli standard, le comunicazione “server-to-server” tra ASPSP e TPP autorizzati, così come quella tra ASPSP e i PSP che emettono strumenti di pagamento card-based, deve avvenire impiegando, per l’autenticazione delle parti, i certificati qualificati emessi da un provider conforme al regolamento (UE) 910/2014, altresì noto come regolamento eIDAS.
I prossimi passi
La bozza finale degli standard tecnici proposti da EBA, saranno presentati alla Commissione per l’adozione, dopo di che saranno oggetto di esame da parte del Parlamento europeo e del Consiglio, prima di essere pubblicati sull’Official Journal dell’Unione europea.
Ai sensi di quando disposto dalla PSD2, i regolamenti di EBA entreranno in vigore 18 mesi dopo la pubblicazione in Gazzetta ufficiale dell’Unione europea, pertanto, non si prevede che essi saranno cogenti prima di novembre 2018.
NOTE
[1] Introductory statement of Andrea Enria, chairperson of the EBA at the scrutinity hearing on SCA and CSC Committee on Economic and Monetary Affairs (ECON) of the European Parliament
[2] Si veda anche di Roberto Garavaglia “Il potenziale delle API: dall’obbligo all’opportunità, quali strategie di sviluppo indirizzate dalla PSD2” – gennaio 2017 – Report “Digital Rethinking nel Banking e Finance”, Osservatorio Digital Finance del Politecnico di Milano
