Le sfide bancarie si sommano: PSD2 significa nuove regole di condivisione dei dati

Pubblicato: 2018-04-13

Molti di voi, senza dubbio, hanno sentito parlare della direttiva dell'Autorità bancaria europea (o EBA) dell'Unione Europea chiamata PSD2 (abbreviazione di Payment Services Directive). Queste linee guida sono state originariamente pubblicate alla fine del 2015. Entro gennaio 2018, tutti gli Stati membri erano tenuti ad attuare i regolamenti.

Il settore bancario sta affrontando molte sfide se non sta già pensando a un futuro molto digitale.

Comprensione dell'autenticazione forte del cliente per PSD2 dell'UE

Gli scopi principali della PSD2 includono:

  1. Aprendo nuove opportunità di mercato per una varietà di attori come i commercianti online, livellando le condizioni per tutte le principali parti interessate
  2. Fornire trasparenza e scelta del consumatore
  3. Introduzione di nuove e più solide pratiche di sicurezza per i pagamenti online

Ci sono una serie di linee guida in generale per PSD2; tuttavia, una delle migliori linee guida PSD2 può essere scaricata dal MEF (Mobile Ecosystem Forum).

Forte autenticazione del cliente

Uno degli elementi chiave delle normative PSD2 è il concetto di Strong Customer Authentication (o SCA). L'EBA osserva: “Grazie alla PSD2 i consumatori saranno meglio protetti quando effettuano pagamenti o transazioni elettroniche (come l'utilizzo del proprio banking online o l'acquisto online).

Il Regulatory Technical Standard (RTS) rende l'autenticazione forte del cliente (SCA) la base per accedere al proprio conto di pagamento, nonché per effettuare pagamenti online". In breve, SCA richiede, come minimo, l'autenticazione a due fattori (2FA).

L'autenticazione a due fattori significa che gli utenti dovranno "dimostrare" la propria identità mediante due elementi separati di tre:

  1. Qualcosa che conoscono (un codice PIN o una password)
  2. Qualcosa che possiedono (un dispositivo mobile, una carta)
  3. Qualcosa che sono (impronte digitali, scansione facciale: es. biometria)

L'ABE rileva che SCA è comunemente utilizzato in tutta l'UE; tuttavia, questo non è sempre il caso per le transazioni di pagamento online come il pagamento con carta di credito o il bonifico bancario diretto. SCA è applicato nei paesi dell'UE di Belgio, Paesi Bassi e Svezia); tuttavia, in altri paesi dell'UE, lo SCA viene applicato solo su base volontaria, secondo un eccellente comunicato stampa della Commissione europea.

Mentre gli stati membri dell'UE avrebbero dovuto implementare la PSD2 entro gennaio 2018, SCA diventerà obbligatorio 18 mesi dopo l'EBA Regulatory Technical Standard (RTS) dopo la data di entrata in vigore dell'RTS (che dovrebbe essere entro la fine dell'anno) . Quindi, in sostanza, stiamo guardando da metà a fine 2019 (settembre 2019 era una di queste date citate da alcuni documenti). Ciò consentirà a tutte le parti interessate di tempo sufficiente per incorporare SCA e altri requisiti di sicurezza nei propri sistemi e flussi di lavoro.

Servizi bancari al dettaglio: Lions, banchieri e fintech, oh mio!

retail_banking_fintech.jpg Le fintech minacciano lo status quo. A differenza delle banche, non sono gravate da eredità, regolamenti e, nella maggior parte dei casi, anche dalla necessità di fare soldi. I banchieri al dettaglio devono adattarsi e concentrarsi sulle relazioni con i clienti per competere.

2FA per SCA

Data la sequenza temporale della SCA, il 2018 è un momento perfetto per le aziende per iniziare a implementare soluzioni 2FA per tenere conto della maggiore sicurezza richiesta.

Lo studio legale internazionale Taylor Wessing, nel suo documento: Strong customerAuthentication under PSD2 , osserva che "l'EBA ha concordato con la maggior parte degli intervistati al Consultation Paper che, al fine di garantire la neutralità tecnologica e consentire lo sviluppo di servizi di facile utilizzo , mezzo di pagamento accessibile e innovativo, non dovrebbe definire ulteriormente gli elementi di autenticazione.” Ciò significa che l'ABE non specifica le modalità di attuazione delle 2FA. Esistono vari schemi, tra cui la consegna di token su canali mobili come SMS o notifiche push o canali e-mail più tradizionali, nonché soluzioni di token software TOTP e altri.

Tutto ciò premesso, dobbiamo sottolineare che, come ogni buon schema di implementazione 2FA, ci sono alcune limitazioni e regolamenti specifici che devono essere considerati attentamente.

Codici di autenticazione

L'RTS rileva che la generazione di un codice di autenticazione soddisfa le seguenti condizioni:

  1. Nessuna informazione riguardante la conoscenza, il possesso e l'eredità può essere derivata dalla divulgazione del codice di autenticazione
  2. Non è possibile generare un nuovo codice di autenticazione in base alla conoscenza di qualsiasi altro codice di autenticazione precedentemente generato
  3. Il codice di autenticazione non può essere falsificato

Inoltre, l'RTS afferma che non devono essere tentati più di 5 tentativi di autenticazione falliti entro il tempo di vita del codice e che il tempo massimo senza attività da parte del pagatore o dell'utente dopo essere stato autenticato per l'accesso al proprio conto di pagamento online non deve superare i 5 minuti .

Collegamento dinamico della transazione

L'RTS indica che le transazioni elettroniche remote, essenzialmente pagamenti effettuati su Internet (sia su un dispositivo desktop come un laptop o un dispositivo mobile) devono includere elementi che "collegano dinamicamente la transazione a un importo specifico e a un beneficiario specifico". L'RTS considera questa una forma aggiuntiva di SCA.

Per questo requisito SCA, l'importo della transazione di pagamento e chi è il beneficiario (o il commerciante) devono essere forniti all'utente al momento di una transazione 2FA. In caso di variazione dell'importo o del beneficiario, deve essere generato un altro codice di autenticazione (ad es. “collegamento dinamico” di tale codice al nuovo beneficiario e/o importo del pagamento). Un messaggio SMS con tutte le informazioni richieste potrebbe essere simile all'immagine a destra: il codice di sicurezza di 10 minuti, il nome del commerciante (o del beneficiario) e l'importo della transazione.

È interessante notare che un codice di autenticazione generato da un'app conforme a TOTP di terze parti come Google Authenticator viene generato in modo completamente separato dalle informazioni sul pagamento / commerciante e quindi non può essere collegato dinamicamente.

Indipendenza dal canale

Questo requisito è un po' complicato. La RTS afferma che “i prestatori di servizi di pagamento devono adottare misure di sicurezza, laddove uno qualsiasi degli elementi di autenticazione forte del cliente o il codice di autenticazione stesso sia utilizzato attraverso un dispositivo multiuso, per mitigare il rischio che deriverebbe da tale dispositivo multiuso essere compromesso”. Un dispositivo multiuso potrebbe essere un dispositivo mobile, un tablet o anche un laptop.

Se un utente è su un laptop e gli viene richiesto di effettuare un pagamento, quel commerciante può inviare un SMS al dispositivo mobile dell'utente con il beneficiario (ad esempio il commerciante) nonché l'importo che pagherà, insieme all'autenticazione codice nel corpo dell'SMS.

In un altro esempio, se l'utente utilizza un dispositivo mobile per interagire con un commerciante e avvia un pagamento, questa indipendenza dal canale non vieta specificamente gli SMS o qualsiasi canale di consegna specifico per dispositivi mobili. Qui è una linea sottile. In molti casi, l'unico dispositivo di cui dispone un utente è un dispositivo multiuso come un telefono cellulare. Ma l'indipendenza dal canale è proprio questo - un canale indipendente sullo stesso dispositivo - un SMS con un codice di autenticazione è un canale diverso (infatti è un canale fuori banda , raggiungibile tramite il numero di cellulare) rispetto al cellulare app o browser web che l'utente sta interagendo con il commerciante. La stessa indipendenza dal canale si applicherebbe all'utilizzo dell'app mobile per generare un codice conforme a TOTP (come Google Authenticator), ma come notato in precedenza, il codice di reclamo TOTP non riesce a collegare dinamicamente la transazione.

Al contrario, se l'utente utilizzava un'app mobile per accedere al commerciante, non sarebbe possibile inviare una notifica push alla stessa app (con il codice di autenticazione), poiché sono lo stesso canale.

C'è chi direbbe che la 2FA tramite SMS non è molto sicura e, in alcuni casi, potrebbe essere vero. Sì, ci sono stati alcuni casi isolati in cui un utente malintenzionato è riuscito ad accedere ai messaggi SMS 2FA tramite SS7 su un operatore; tuttavia, molte di queste vulnerabilità sono state chiuse. Inoltre, è molto importante il modo in cui il codice di autenticazione viene generato e fornito all'utente e il modo in cui il provider di servizi di messaggistica fornisce tali codici.

Nelle situazioni in cui sono prevalenti i dispositivi multiuso (e oggi questi sono e continueranno ad essere i dispositivi più diffusi), un canale di messaggistica fornito da un operatore mobile dovrebbe continuare a essere un valido canale fuori banda per i token 2FA.

Per un'analisi più dettagliata, ho trovato un post sul blog informativo di Frederik Mennes che fornisce maggiori dettagli su quali tipi di scenari, in particolare per i dispositivi multiuso, dovrebbero essere conformi alla PSD2 SCA.

PSD2 SCA non dovrebbe essere preso alla leggera, ma molte soluzioni 2FA già implementate dovrebbero funzionare; tuttavia, sappiamo anche che molti commercianti online non stanno ancora fornendo soluzioni compatibili con PSD2 SCA. Al momento della stesura di questo documento, c'è ancora molto tempo per incorporare SCA nei flussi di lavoro di pagamento.

SAP Authentication 365 è una soluzione che fornisce una soluzione cloud basata su API per consentire alle aziende di implementare SCA conforme a PSD2. Il servizio mobile SAP Authentication 365 è un servizio end-to-end che ti consente di implementare un servizio di autenticazione a due fattori multicanale (2FA) in modo rapido e sicuro, con un'autenticazione su misura per il tuo business digitale.

Aiuta a proteggere l'identità e i dati dei tuoi clienti aziendali abilitando l'autenticazione tramite SMS, e-mail, notifiche push o soft-token TOTP. L'API REST di SAP semplifica la generazione e l'autenticazione dei codici di convalida o autenticazione e fornisce flessibilità e funzionalità per consentire l'implementazione di una strategia SCA conforme a PSD2.