di Andrea VIVOLI
GLI STANDARD TECNICI DI AUTENTICAZIONE E COMUNICAZIONE
Come abbiamo visto, nel nuovo contesto normativo è stabilito che l’accesso ai conti avvenga mediante interfacce dedicate, predisposte da ogni banca, per l’autenticazione in conformità a quanto stabilito dall’art. 97 della PSD2(1) e dal citato Regolamento Delegato n. 389/2018 (di seguito, RTS)(2).
In particolare, è richiesta l’autenticazione forte del cliente (Strong Customer Authentication – SCA) quando il pagatore:
a) accede al suo conto di pagamento on line;
b) dispone un’operazione di pagamento elettronico, comprendendo elementi che colleghino in maniera dinamica l’operazione a uno specifico importo e a un beneficiario specifico;
c) effettua qualsiasi azione, tramite un canale a distanza, che può comportare un rischio di frode nei pagamenti o altri abusi.
La SCA consente di verificare l’identità di un utente di servizi di pagamento o la validità dell’uso di uno specifico strumento di pagamento, utilizzando due o più elementi, classificati nelle categorie della conoscenza (qualcosa che solo l’utente conosce, come le credenziali di accesso), del possesso (qualcosa che solo l’utente possiede, come smartphone, app o token) e dell’inerenza (qualcosa che caratterizza l’utente, come i dati biometrici) che sono indipendenti, in quanto la violazione di uno non compromette l’affidabilità degli altri, assicurando la riservatezza dei dati di autenticazione (cfr. art. 4, par. 1, n. 30, PSD2). Nel caso di un pagamento effettuato tramite un PISP (Payment Initiation Service Provider), occorre che all’autenticazione sia “agganciato” anche un link dinamico all’importo della singola transazione e al beneficiario del pagamento (cfr. art. 5 del RTS, Regulatory Technical Standards).
Fonte: N. Bolton – SYSNET global solution 2019(3)
Le modalità di autenticazione sono quattro:
1. reindirizzata (redirect), nella quale le credenziali sono verificate dalla banca, a cui il TPP (Third Party Provider) effettua un reindirizzamento del browser dell’utente.
2. disaccopiata (decoupled), nella quale le credenziali sono verificate utilizzando una applicazione dedicata della banca (APP).
3. integrata (embedded), nella quale le credenziali del cliente sono gestite e verificate tramite API (Application Programme Interfaces) della banca.
4. oAuth 2 (Open Authorization 2.0), nella quale l’interfaccia funge da trasmettitore di informazioni tra diverse applicazioni, interfacce utente o pagine web accedendo a dati o servizi protetti.
Le modalità Reindirizzata, Disaccoppiata e oAuth 2 prevedono che l’autenticazione avvenga su un’interfaccia diretta fra utente e banca e l’esito venga successivamente comunicato al TPP per terminare la transazione. Qualora la banca supporti più modalità di SCA è possibile per il cliente effettuare una scelta differente rispetto a quella con cui è stata avviata la transazione.
Per cogliere il flusso di comunicazioni tra il cliente, la banca di radicamento del conto (ASPSP, Account Servicing Payment Service Provider), il PISP e il venditore online (merchant), possiamo suddividere in tre fasi l’operazione complessiva:
1) l’avvio del pagamento e il rilascio del consenso,
2) l’autenticazione e autorizzazione del pagamento e, infine,
3) l’esecuzione vera e propria del pagamento.
Ciò ci consente di apprezzare (e “prezzare”) la complessità tecnica delle comunicazioni che intercorrono tra i vari soggetti coinvolti.
Fonte: N. Bolton – SYSNET global solution 2019(3)
Il corretto ed efficiente funzionamento della filiera dei pagamenti, che coinvolge più soggetti autorizzati, richiede pertanto non solo la standardizzazione delle regole tecniche ma anche protocolli informatici che gestiscono le interfacce preposte al dialogo applicativo tra PISP (Payment Initiation Service Provider)/AISP (Account Information Service Provider), da un lato, e i diversi ASPSP di radicamento dei conti, dall’altro.
Sotto il primo aspetto l’ABE, in conformità al proprio mandato, ha richiamato i requisiti che devono essere rispettati nell’elaborazione delle interfacce grafiche e di API, come riepilogato nell’Opinion del 13 giugno 2018(4) che conferma l’ampiezza e complessità dei profili tecnici.
Sotto il profilo informatico, la scelta del regolatore europeo è improntata al principio della neutralità tecnologica, lasciando alle parti la definizione della soluzione tecnica ritenuta più efficiente, con il rischio tuttavia di innescare una indesiderata “frammentazione” dei protocolli di accesso.
Si tratta di un ostacolo non regolamentare, ma di mercato.
A tale riguardo, il rischio di gestire protocolli specifici di accesso per ogni banca è stato mitigato grazie alle iniziative di tipo cooperativo sviluppate a livello nazionale ovvero pan-europeo da parte di operatori di mercato (come nel caso di Berlin Group) che hanno permesso di definire standard condivisi tra banche e terze parti, consentendo di ottimizzare gli investimenti a livello di sistema. Ne sono esempio Open Banking UK (cui aderisce oltre il 90% delle banche UK), LuxHub (con oltre 36 gruppi bancari europei) e CBI Globe in Italia (con oltre 280 banche).
L’iniziativa NextGenPSD2 XS2A del Berlin Group costituisce un indubbio benchmark tecnico, le cui caratteristiche di base sono riepilogate nella tabella seguente, dove sono richiamati anche i servizi a valore aggiunto che, pur non essendo obbligatori ai sensi della PSD2, possono consentire alle TPP di arricchire l’offerta e l’attrattività per la gestione di molteplici tipologie di pagamenti.
Fonte: The Berlin Group – A European Standard for PSD2 NextGen(5)
Le richiamate iniziative hanno avuto il pregio di assicurare la massima interoperabilità (interoperability) e raggiungibilità (reachability) delle banche da parte dei TPP in Europa grazie a specifiche armonizzate per le API di accesso ai conti e agli altri servizi messi a disposizione. Eppure, manca ancora qualcosa.
2/3
Intervento del Dott. Andrea VIVOLI – Consulente Aziendale. Esperto in vigilanza bancaria e antiriciclaggio
Le considerazioni espresse nell’articolo sono riconducibili esclusivamente all’Autore e non impegnano in alcun modo le Istituzioni con le quali sussistono rapporti di collaborazione.
LEGGI QUI l’articolo successivo 3/3, PSD2 a che punto siamo? Come coglierne i benefici
Per approfondimenti e normative, consultare i seguenti link e/o riferimenti:
(1) Direttiva UE 2015/2366, Servizi di Pagamento nel mercato interno (PSD2)
(2) Regolamento Delegato UE 2018/389, Autenticazione e Standard di Comunicazione (RTS)
(3) N. Bolton, Payment Services Directive (EU) 2015/2366 (PSD2) & Strong Customer Authentication, sysnetgs.com
(5) 01. NextGenPSD2 XS2A Interoperability Framework – General Introduction Paper V2_20190325.pdf – The Berlin Group
