Consenso PSD2

Introduzione

La PSD2 consente a banche e clienti di beneficiare di API di terze parti per ottenere una migliore esperienza nelle proprie attività finanziarie, sia per le operazioni informative (AISP) che per quelle dispositive (PISP). Tuttavia, ciò implica che le banche dovranno condividere dati sensibili — come le informazioni finanziarie del cliente — con società terze, garantendo al contempo la sicurezza dei dati del cliente e delle altre informazioni. Lo stesso vale per l'inizializzazione dei pagamenti.

Nell'ambito dell'open banking, gli Account Servicing Payment Service Provider (ASPSP) e i Third-Party Provider (TPP) sono strettamente regolamentati da normative specifiche del settore, tra cui la SCA (Strong Customer Authentication) e il GDPR (General Data Protection Regulation).

Ad esempio, le informazioni finanziarie devono essere condivise solo con il consenso esplicito dell'utente; in caso contrario, il fornitore di servizi violerebbe il GDPR, entrato in vigore nel maggio 2018.

Gestione del Consenso

Nel contesto dell'open banking, la gestione del consenso si articola in tre fasi:

1. La fase del consenso.
2. La fase di autenticazione.
3. La fase di autorizzazione.

Nella fase del consenso, l'interfaccia mostra all'utente quali informazioni vengono richieste e per quali scopi. Nella fase di autenticazione, è responsabilità della banca coinvolgere l'utente nei meccanismi di autenticazione necessari a garantire la sicurezza dei suoi dati — la PSD2 impone a tal fine la SCA. Nella fase di autorizzazione, all'utente vengono presentati i dettagli del consenso richiesto nell'interfaccia banca-utente, e viene chiesto di accettare o rifiutare la richiesta del TPP di accedere ai dati mostrati.

Le tre fasi appena descritte possono essere riassunte nei 6 passaggi illustrati nel seguente diagramma:

L'utente deve essere consapevole del TPP a cui sta concedendo il consenso e del numero di giorni per cui il consenso sarà valido; al termine di questo intervallo di tempo sarà necessario un rinnovo (ovvero un nuovo consenso) da parte dell'utente. Il numero massimo di giorni consentito è 180 (in precedenza era 90, aumentato a partire dal 25/07/2023).

Ai sensi dell'articolo 7 del GDPR europeo, le banche non solo devono garantire la sicurezza dei dati raccolti dagli utenti, ma devono anche offrire agli utenti la possibilità di cambiare idea e revocare il consenso.

Un aspetto importante da tenere a mente è il seguente:

Per la tripletta TPP (certificato) – Banca – Utente (credenziali di accesso al banking interno), può essere valido uno e un solo consenso ricorrente alla volta.

Il termine "ricorrente" è utilizzato deliberatamente, poiché esiste anche il consenso non ricorrente, che consente una singola richiesta informativa (ad esempio la lista dei conti), dopodiché non è più valido. In generale, salvo diversa indicazione, il consenso si intende ricorrente.

Questo significa che la creazione di un nuovo consenso con gli stessi tre attori sovrascriverà il precedente. È un aspetto da tenere in considerazione sia in fase di test che in fase di progettazione. Ad esempio, se più tester stanno testando consensi e accedendo alle API, dovranno utilizzare due account diversi oppure coordinarsi per utilizzare lo stesso consenso — altrimenti, l'ultimo tester a creare un consenso invaliderà quello precedentemente creato dal collega.

Un altro esempio è quello di un TPP che desidera creare più applicazioni per i propri clienti: dovrà implementare un livello aggiuntivo per la corretta gestione dei consensi.

Per Fabrick Pass, il TPP è sempre Fabrick (che detiene la licenza AIS / PIS).

Stato del Consenso

I possibili valori che un consenso può assumere sono elencati di seguito:

• RECEIVED: prima fase — il consenso non è ancora stato autorizzato dal PSU. Ad esempio, il TPP (o Fabrick nel caso di un FPP) ha richiesto il consenso alla banca, ma l'utente non ha ancora completato la fase SCA.
• VALID: il consenso è attivo e valido.
• TERMINATED_BY_TPP: il TPP (o il PSU nel caso di un FPP tramite Fabrick) ha annullato il consenso tramite API (DEL DeleteConsent).
• REVOKED_BY_PSU: il PSU ha revocato il consenso tramite il proprio internet banking.
• EXPIRED: il consenso è scaduto.
• REPLACED: il consenso è stato rinnovato prima della scadenza. Se si incontra questo valore, esisterà certamente un secondo consenso con le stesse proprietà ma con uno stato diverso (ad esempio VALID).
• REJECTED: i dati del consenso sono stati rifiutati, ad esempio perché non è avvenuta alcuna autorizzazione con esito positivo.

Date le varie modalità con cui un consenso può essere invalidato, è possibile incontrare un consenso con uno stato diverso da VALID anche se la data di scadenza è nel futuro.

Strong Customer Authentication

La SCA si applica sia alle operazioni informative (AISP) che a quelle dispositive (PISP). Richiede un'autenticazione forte utilizzando almeno due dei seguenti tre elementi:

• Conoscenza: qualcosa che l'utente conosce, come una password, un PIN, una passphrase o una domanda di sicurezza.
• Possesso: qualcosa che l'utente possiede e può utilizzare, tipicamente un dispositivo come uno smartphone, un dispositivo portatile o un token bancario.
• Inerenza: qualcosa di fisico che identifica univocamente l'utente, come un'impronta digitale o caratteristiche biometriche del volto.

Per quanto riguarda i pagamenti, la PSD2 prevede che alcune tipologie di transazioni possano essere esentate dal processo SCA a due fattori. In particolare, le seguenti categorie possono essere esenti:

• Transazioni di importo ridotto: transazioni inferiori a €30 che, accumulate nell'arco di 24 ore, non superano €100, o che non superano una serie di cinque transazioni esenti.
• Transazioni a basso rischio: operazioni analizzate dai prestatori di servizi di pagamento in cui il tasso di frode rimane al di sotto delle soglie regolamentari per i pagamenti con carta, escludendo così la necessità della SCA.
• Pagamenti ricorrenti con importo fisso: ad esempio, abbonamenti. In questi casi, l'autenticazione forte è richiesta solo per la prima transazione; tutti i rinnovi successivi sono trattati come operazioni automatiche e non richiedono la SCA, salvo variazioni dell'importo o della modalità di erogazione del servizio.
• Pagamenti verso beneficiari attendibili: l'autenticazione forte è richiesta per il primo pagamento verso un beneficiario identificato come attendibile. I pagamenti successivi verso lo stesso beneficiario possono essere effettuati senza SCA.

Flussi di Strong Customer Authentication — UI

Introduzione

In questo documento vengono descritte le diverse tipologie di flussi SCA. Come previsto dallo standard PSD2, ogni banca può supportare uno o più dei seguenti metodi:

• redirect
• decoupled
• embedded

Il TPP deve adeguarsi di conseguenza e implementare il metodo definito dall'ASPSP.

Il TPP dovrà sviluppare i flussi indipendentemente dal fatto che scelga la soluzione base o quella semplificata tramite workflow. Per i dettagli si rimanda alla documentazione tecnica.

Per gli FPP non sarà necessario alcuno sviluppo, poiché l'utente verrà reindirizzato alle pagine Fabrick che gestiscono già tutti i casi possibili.

Flussi Standard

Redirect

Il redirect è uno degli approcci SCA più diffusi e più semplici da implementare. Quando il Payment Service User (PSU) avvia l'interazione con il TPP, viene reindirizzato a un'interfaccia web dell'ASPSP per l'autenticazione. Ciò significa che i PSU vengono reindirizzati al sito web della propria banca per autenticarsi inserendo le proprie credenziali. Un vantaggio fondamentale dell'approccio redirect è che nessun dato aggiuntivo dell'utente viene condiviso con il TPP.

Decoupled

L'approccio SCA decoupled è simile al redirect, ma l'autenticazione viene eseguita tramite un'applicazione o un dispositivo indipendente fornito dall'ASPSP (ad esempio un'app di mobile banking). Il PSU si autentica tramite un metodo separato dal flusso di interazione principale. Questo modello consente diverse soluzioni innovative e offre il vantaggio aggiuntivo di permettere al PSU di utilizzare il proprio telefono cellulare per autenticarsi. Il TPP deve implementare un meccanismo di polling per rilevare lo stato dell'operazione non appena il PSU la autorizza.

Embedded

Nell'approccio SCA embedded, il processo è interamente gestito dal TPP per conto del PSU. L'utente condivide le proprie credenziali con il TPP, che si autentica in background e gestisce direttamente l'interazione con l'ASPSP. Il fornitore di servizi deve essere registrato e autorizzato per eseguire questa operazione, e non è autorizzato a conservare alcuna credenziale condivisa dal PSU. Per aumentare la sicurezza, al PSU potrebbe essere richiesto di completare un ulteriore passaggio SCA, come l'inserimento di una one-time password, per ridurre il rischio di frode.

Varianti dei Flussi Standard

I tre flussi descritti sopra rappresentano i casi base. Tuttavia, alcuni ASPSP potrebbero richiedere informazioni aggiuntive o implementare una combinazione di due dei tre approcci. Di seguito sono riportati alcuni esempi.

Esempi

Questa sezione illustra l'esperienza utente del PSU per ciascun possibile flusso SCA:

• redirect: l'utente viene immediatamente reindirizzato a una pagina della banca per completare l'autenticazione. L'esperienza è simile a quella del proprio internet banking.
• redirect con precondizione psu-id: dopo aver fornito a Fabrick l'ID utilizzato per accedere alla propria banca, l'utente viene reindirizzato a una pagina della banca per completare l'autenticazione.
• redirect con precondizione IBAN: dopo aver fornito a Fabrick l'IBAN del proprio conto bancario, l'utente viene reindirizzato a una pagina della banca per completare l'autenticazione.
• redirect con precondizione psu-id e IBAN: dopo aver fornito a Fabrick sia l'ID utente che l'IBAN, l'utente viene reindirizzato a una pagina della banca per completare l'autenticazione.
• decoupled: l'utente si autentica sull'app della propria banca mentre Fabrick attende il completamento dell'autenticazione, fornendo eventuali informazioni aggiuntive richieste dal processo.
• embedded: l'utente inserisce i propri dati di autenticazione (username, password, token, ecc.) direttamente sulla pagina Fabrick, che valida autonomamente i dati con la banca, richiedendoli eventualmente in più passaggi.

I seguenti metodi di autenticazione si applicano allo stesso modo alla fase di aggregazione dei conti.

Autenticazione con Redirect

Nell'esempio sopra, l'utente è stato reindirizzato alla pagina di una banca di test, "Fabrick."

Ad esempio, selezionando la prima opzione (ricevere un SMS), verrà mostrata la seguente pagina:

Autenticazione con Redirect — Precondizione: psu-id

Prima di essere reindirizzato alla propria banca, all'utente viene richiesto il codice utente / ID utilizzato per accedere ai servizi bancari.

Dopo aver inserito il codice utente / ID e aver cliccato su Autorizza, l'utente viene reindirizzato alle pagine di autenticazione della propria banca.

Autenticazione con Redirect — Precondizione: IBAN

Prima di essere reindirizzato alla propria banca, all'utente viene richiesto l'IBAN del conto con cui verificherà la propria identità.

Dopo aver inserito l'IBAN e aver cliccato su Autorizza, l'utente viene reindirizzato alle pagine di autenticazione della propria banca.

Autenticazione con Redirect — Precondizione: psu-id e IBAN

Prima di essere reindirizzato alla propria banca, all'utente vengono richiesti sia il codice utente per accedere ai servizi bancari che l'IBAN del conto con cui verificherà la propria identità.

Dopo aver inserito sia l'IBAN che il codice utente / ID e aver cliccato su Autorizza, l'utente viene reindirizzato alle pagine di autenticazione della propria banca.

Autenticazione con Decoupled

Per l'autenticazione decoupled, l'utente si autentica sull'app della propria banca mentre Fabrick attende il completamento del processo, visualizzando eventuali informazioni aggiuntive richieste.

Autenticazione con Embedded

Nell'autenticazione embedded, tutti i dati necessari per autenticare l'utente presso la banca vengono inseriti direttamente sulla pagina Fabrick, che valida autonomamente i dati con la banca — richiedendoli eventualmente in più passaggi.