di Andrea VIVOLI
GLI OSTACOLI INDIVIDUATI DALL’ABE
Nell’opinion(1) del 4 giugno 2020 l’ABE risponde ad una serie di eccezioni sollevate dai TPP (Third Party Providers), formulate sulla base dell’esperienza maturata nel rapporto con le banche e nell’accesso ai conti di pagamento dei clienti.
In primo luogo, l’ABE chiarisce che il reindirizzamento obbligato sulla procedura di autenticazione della banca non costituisce di per sé un ostacolo, a meno che l’esperienza d’uso del cliente sia peggiore rispetto a quella che avrebbe il medesimo cliente qualora accedesse direttamente al proprio conto dall’interfaccia web della banca.
L’ABE aveva già chiarito nel dicembre 2018 che nel caso di protocolli che prevedano il reindirizzamento o il disaccoppiamento, l’interazione dovrebbe essere ridotta al minimo, ovvero a quanto necessario per l’autenticazione (EBA Guidelines on the exemption from the contingency mechanism under Article 33(6) RTS – EBA/GL/2018/07)(2). La procedura di autenticazione, come parte di un percorso che coinvolge AIS/PIS (Account Information Service / Payment Initiation Service), non deve pertanto includere passaggi non necessari o richiedere al cliente di fornire informazioni inutili o superflue rispetto al modo in cui il cliente può eseguire l’autenticazione quando accede direttamente ai propri conti di pagamento o avvia un pagamento con la banca.
Al di là di questa premessa di ordine generale, l’ABE raggruppa i potenziali ostacoli alla fruizione dei servizi offerti dai TPP nelle seguenti macroaree.
❖ Interfacce di autenticazione e reindirizzamenti obbligatori. Le banche devono garantire ai TPP la possibilità di utilizzare tutte le modalità consentite ai propri clienti per accedere ai conti (modalità reindirizzata, disaccoppiata, integrata o una combinazione delle stesse). Ne consegue che se la banca consente l’accesso mediante validazione biometrica altrettanto dovrà avvenire mediante una procedura di autenticazione disaccoppiata.
Se le interfacce fornite dalle banche non supportassero invece tutte le procedure di autenticazione messe a disposizione dalle banche ai propri clienti, ciò costituirebbe una violazione dell’articolo 30(2) RTS (Regulatory Technical Standards)(3) e un ostacolo ai sensi dell’articolo 32(3) RTS. Come già chiarito al paragrafo 29 del parere dell’ABE sull’attuazione del RTS (EBA-Op-2018-04)(4), un PISP (Payment Initiation Service Provider) ha il diritto di avviare le stesse disposizioni di pagamento che la banca offre ai propri clienti. Ciò significa che se una banca consentisse di effettuare pagamenti istantanei direttamente presso il punto vendita, altrettanto dovrebbe avvenire, entro gli stessi limiti di importo, presso il punto vendita utilizzando i servizi dei PISP.
❖ Molteplici richieste di autenticazione forte (SCA, Strong Customer Authentication). Nel caso di servizi forniti da un AISP (Account Information Service Provider), la procedura di autenticazione delle banche per consentire ai clienti di accedere ai propri conti di pagamento non deve richiedere più SCA o aggiungere indebiti rallentamenti o complicazioni non necessari, rispetto alla procedura di autenticazione offerta direttamente ai propri clienti.
Per ordini di pagamento avviati tramite PISP, le banche devono supportare un’unica SCA per singolo pagamento qualora la terza parte abbia trasmesso alla banca tutte le informazioni necessarie per avviare il pagamento, compreso il numero di conto/IBAN da addebitare. La richiesta di procedere a due SCA (una per l’accesso ai dati dell’account e una per l’avvio del pagamento) costituirebbe invece un ostacolo, a meno che la banca non abbia debitamente giustificato, per motivi di sicurezza, l’ulteriore autenticazione. Se, invece, il conto di pagamento da addebitare non viene trasmesso dal PISP alla banca nella richiesta di avvio del pagamento e deve essere selezionato successivamente dal cliente nel dominio dei conti accesi presso la banca medesima, la richiesta di due SCA è legittima e non costituisce ostacolo.
❖ Ri-autenticazione dopo 90 giorni. Alcuni AISP hanno sollevato la questione dell’obbligo di procedere con una nuova SCA ogni 90 giorni dall’ultimo accesso autenticato della terza parte, il che può compromettere l’esperienza d’uso nel caso in cui l’aggregazione dei dati riguardi molteplici conti di pagamento detenuti dal cliente presso diverse banche. Infatti, in tali casi, il cliente dovrebbe procedere a una autenticazione forte con ogni banca per consentire all’AISP di continuare ad accedere ai dati dell’account.
Sul punto l’ABE ha ribadito come l’articolo 10 del RTS preveda l’esenzione dall’obbligo di applicare la SCA per ogni accesso solo qualora il cliente o l’AISP acceda a un insieme limitato di dati (saldo e/o alle transazioni di pagamento eseguite negli ultimi 90 giorni). Tale periodo di tempo è ritenuto il giusto compromesso tra facilità d’uso dei servizi forniti dall’AISP e requisiti di sicurezza richiesti dalla direttiva e pertanto la ri-autenticazione ogni 90 giorni non costituisce un ostacolo all’operatività dei TPP.
Diversamente, qualora le banche richiedano autenticazioni più frequenti, ciò può danneggiare il business dei nuovi operatori, aspetto sul quale le Autorità di vigilanza sono chiamate a intervenire.
Per evitare impatti sui clienti, potrebbe essere previsto uno schema alternativo – rileva l’ABE – nel quale gli AISP sono autorizzati dalle banche a eseguire i successivi rinnovi SCA per loro conto. In tale evenienza, occorre peraltro valutare se e in quale misura la delega costituisce outsourcing ai sensi delle EBA Guidelines (EBA/GL/2019/02)(5).
❖ Selezione dei conti. L’ABE ha da tempo chiarito come le interfacce che richiedono al cliente di immettere manualmente il proprio IBAN nel dominio della banca per poter utilizzare i servizi di una terza parte (AISP/PISP) costituiscono un ostacolo.
Per evitare che i clienti debbano inserire manualmente i dettagli dell’account vi sono due opzioni:
1) la banca consente ai TPP che dispongono di una licenza AIS e che hanno ottenuto il consenso del cliente, come richiesto dall’articolo 67(2)(a) di PSD2(6), di recuperare l’elenco di tutti gli account di pagamento del cliente tramite l’interfaccia, in modo che il cliente possa selezionare l’account nel dominio del TPP. Il TPP potrebbe quindi inviare una richiesta separata alla banca per l’accesso all’account o, come può essere il caso, l’avvio del pagamento, con i relativi dettagli dell’account;
2) in alternativa, se la banca ha implementato un approccio di reindirizzamento o disaccoppiato e il TPP non trasmette alla banca i dettagli dell’account pertinente, quest’ultima può consentire al cliente di selezionare gli account durante la procedura di autenticazione, in modo che l’esperienza d’uso non sia più complicata di quella che avrebbe il cliente. Ad esempio, le banche possono offrire un elenco a discesa per il cliente da cui selezionare gli account oppure precompilare i dettagli dell’account se il cliente dispone di un solo account presso la banca. Quest’ultima opzione non è attualmente supportata nel caso di autenticazione integrata, ovvero in cui le credenziali di autenticazione del cliente vengono scambiate tra il TPP e la banca e in cui il cliente non interagisce con la banca. Ciò significa che, nel caso di un approccio integrato, un PISP che non ha anche una licenza AIS e/o il necessario consenso da parte del cliente per accedere all’elenco di tutti i conti di pagamento del cliente, potrebbe essere necessario ottenere in anticipo dal cliente i dettagli del conto da cui avviare il pagamento.
In argomento, l’ABE ha altresì confermato come la banca non sia tenuta a condividere con i PISP l’elenco di tutti i conti di pagamento del cliente. Infatti, nel caso di una disposizione di pagamento, il PISP non ha diritto ad accedere all’elenco di tutti i conti di pagamento del cliente in quanto queste informazioni esulano dall’ambito dei dati a cui i PISP necessari per dare corso all’operazione di pagamento ai sensi dell’articolo 66(4)(b) PSD2 e dell’articolo 36(1)(b) RTS.
❖ Controlli aggiuntivi sul consenso. L’articolo 32(3) del RTS già qualifica come potenziale ostacolo eventuali controlli supplementari da parte della banca circa il consenso dato dai clienti agli AISP/PISP. L’ABE nell’opinion del 2018 (EBA-Op-2018-04)(3)14 e nella relazione finale sugli orientamenti dell’ABE sull’esenzione dal “meccanismo di emergenza” ai sensi dell’articolo 33(6) RTS (EBA/GL/2018/07)(2) ha ribadito che è obbligatorio per il PISP/AISP garantire l’ottenimento del consenso esplicito del cliente in conformità con l’articolo 66(2) e 67(2) della PSD2 e che la banca non debba verificare il consenso dato dal cliente. Ciò è stato confermato anche dalla Commissione europea nell’ambito dell’EBA Rule Book Q&A (cfr. risposta n. 4309)(7).
Ciò non esclude, tuttavia, la possibilità per il cliente di richiedere alla banca di negare l’accesso ai propri conti di pagamento a uno o più TPP specifici. In tal caso, le banche sono tenute a garantire che qualsiasi restrizione dell’accesso dei TPP venga effettuata in conformità con la PSD2, compresi, ove applicabile, i requisiti di cui all’articolo 68(5) PSD2, che consente alle banche di negare a un AISP/PISP l’accesso a un account di pagamento qualora siano oggettivamente giustificati e debitamente evidenziati i motivi relativi all’accesso non autorizzato o fraudolento all’account di pagamento da parte della terza parte così individuata.
❖ Registrazioni aggiuntive. Alcuni partecipanti al mercato hanno segnalato casi in cui i TPP sono tenuti a passare attraverso processi di registrazione aggiuntivi per avere accesso all’interfaccia della banca. In proposito, l’ABE richiama come l’articolo 32(3) del RTS menziona tra i potenziali ostacoli anche eventuali “autorizzazioni e registrazioni supplementari oltre a quelle previste dagli articoli 11, 14 e 15 della PSD2“.
Non siamo invece in presenza di ostacoli, qualora alcuni processi di registrazione siano tecnicamente necessari per consentire una comunicazione sicura con la banca. Ad esempio, qualora sia necessaria una pre-registrazione dell’app del TPP per consentire una comunicazione sicura con l’app di autenticazione della banca e tale registrazione viene elaborata in modo tempestivo non creando rallentamenti inutili per il cliente finale.
CONCLUSIONI
L’analisi condotta dall’ABE sui potenziali ostacoli nella prestazione di servizi di disposizione di ordini di pagamento o informativi sui conti richiederà alle autorità di vigilanza nazionali di verificare la conformità delle interfacce di accesso ai conti predisposte dalle banche ai requisiti tecnici regolamentari, avendo presenti gli ulteriori chiarimenti forniti nella opinion.
Il documento dell’ABE ha ovviamente trovato un positivo riscontro da parte della European Third Party Providers Association – ETPPA(8), costituita da 23 fintech di derivazione non bancaria che offrono servizi AIS o PIS ai propri clienti.
Il dubbio è se la presunta minaccia per i ricavi bancari portata dalle Fintech sia reale, tenuto conto che solo per il mercato italiano si stimano ricavi potenziali derivanti dall’open banking tra i 2 e i 3 miliardi di euro, a fronte di un utilizzo dei pagamenti digitali è ancora basso (26% quelli effettuati con carta, rispetto al 70% del Regno Unito).
In altri termini, al di là dei vincoli regolamentari, la PSD2 sta veramente minando le fondamenta del business bancario?
L’evidenza sui TPP non bancari censiti nel registro tenuto dall’Autorità Bancaria Europea, dimostra che in Italia le banche stanno progressivamente adattandosi al nuovo scenario, “inglobando” le nuove funzionalità in modo da mantenere il presidio della relazione con il cliente. Ad oggi, solo 3 soggetti non bancari sono autorizzati ad operare come AISP dalla Banca d’Italia rispetto agli 89 del Regno Unito, gli 11 della Svezia e i 7 della Finlandia.
Rispetto all’approccio di compliance che ha connotato i primi mesi di testing delle interfacce API (Application Programme Interfaces) (a partire da marzo 2019), si è assistito ad una evoluzione – tuttora in corso – verso un approccio modulare nel quale le banche tendono a evolvere come piattaforma di servizi integrati (dai pagamenti alla gestione dei patrimoni, dall’assicurazione al credito), proponendosi esse stesse come TPP rispetto ai propri competitor su scala paneuropea.
Nel corso del 2020 sono numerose le banche che hanno annunciato soluzioni “open”, tipicamente sotto forma di aggregatori finanziari in grado di collegare conti e carte di altri istituti, con possibilità di effettuare anche bonifici da qualsiasi banca collegata e richiedere finanziamenti.
Ma il tema delle strategie bancarie per crescere e consolidarsi nell’era dell’open banking è troppo ampio per esaurirlo in poche righe, rinviando ad un ulteriore approfondimento.
Nel frattempo, auspichiamo che l’intervento delle Autorità consenta di superare gli ostacoli richiamati dall’ABE e, cacciato definitivamente il demone dell’inefficienza, potremo apprezzare tutti i benefici della PSD2, snodo fondamentale per la creazione di un sistema dei pagamenti europeo aperto nel quale il cliente possa liberamente utilizzare gli strumenti che ritiene più adatti, ritrovandosi al centro di un nuovo ecosistema digitale, sicuro e integrato.
3/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 precedente 2/3, PSD2 a che punto siamo? Capire dove si annida l’inefficienza
Per approfondimenti e normative, consultare i seguenti link e/o riferimenti:
(3) Regolamento Delegato UE 2018/389, Autenticazione e Standard di Comunicazione (RTS, )
(4) Opinion of the European Banking Authority on the implementation of the RTS on SCA and CSC – EBA
(5) Guidelines on outsourcing arrangements – EBA
(6) Direttiva UE 2015/2366, Servizi di Pagamento nel mercato interno (PSD2)
(7) Rule Book Q&A, Consent for the provision of PIS and AIS, Answer 2018_4309 – EBA
(8) European Third Party Providers Association – ETPPA – (www.etppa.org)
