3D Secure 2.0
Principi del 3DS 2.0
Sebbene rafforzi la sicurezza con una migliore copertura dei rischi di insoluti, il protocollo 3D Secure V1 è spesso criticato per la sua mancanza di ergonomia. Infatti è responsabile di una perdita di conversioni di clienti fedeli e resta vincolante per autenticarsi su uno smartphone dove bisogna destreggiarsi tra la ricezione dell’SMS e la convalida del codice sullo stesso schermo. Il 3D Secure 2.0 si presenta come un correttivo importante con una promessa di rafforzamento della sicurezza su tutte le transazioni rendendo però il percorso cliente più semplice e senza intoppi.
Per le banche, non è più necessario richiedere sistematicamente un’autenticazione a ogni transazione. Questa si basa ora sull’analisi dei rischi corsi mediante l’utilizzo dei dati complementari e riposizionando il pagamento nel suo contesto.
I rischi di pagamenti fraudolenti sono valutati in modo migliore grazie alla condivisione da parte degli esercenti di oltre 150 dati complementari che sono inviati al momento del pagamento alla banca del consumatore. Questo nuovo approccio permette così di evitare un’autenticazione forte e sistematica. Essa sarà realizzata solo su decisione della banca emittente e per le transazioni più rischiose.
Come complemento e per essere conforme alla Direttiva dei Servizi di Pagamento 2 (DSP2), un pagamento soggetto a un’autenticazione forte dovrà riunire almeno 2 delle informazioni seguenti:
- La conoscenza di un’informazione dall’utente
(es. : password, domanda segreta, codice segreto, numero di identificazione, schema…) - Una cosa in suo possesso
(es. : telefono cellulare, dispositivo connesso, token, smartcard, badge) - Una informazione che gli appartiene e che lo caratterizza
(es. : impronta digitale, riconoscimento facciale, riconoscimento vocale, riconoscimento dell’iride…)
Le modalità di autenticazione saranno soggette a cambiamenti progressivi nel corso del tempo per non compromettere le abitudini dei consumatori..
Funzionamento del 3DS 2.0
In occasione di un pagamento online, che sia tramite un browser o uno smartphone, la banca del titolare della carta procederà a una valutazione del rischio basandosi sull’analisi contestuale di circa 150 dati provenienti:
- Dal telefono nel caso di un pagamento mobile
- Dal browser
- Dal rischio esercente
Questa operazione avviene in background e non disturba il processo di pagamento. I dati devono però essere inviati al momento della transazione.
A titolo informativo, ecco i dati scambiati:
1. Per i pagamenti su smartphone
A titolo di esempio, tra i 12 elementi comuni a tutte le piattaforme mobile troviamo:
- il tipo di piattaforma utilizzata con l’indirizzo IP del titolare
- il nome e il modello della periferica, la risoluzione dello schermo
- il sistema operativo, inclusa la sua versione
- il fuso orario e la posizione del dispositivo
2. Per i pagamenti da browser
I dati catturati dal browser del cliente sono, in alcuni casi, simili alle informazioni citate qui sopra provenienti da uno smartphone.
Sono ripartiti in 9 categorie:
- Accept Headers (intestazioni): indicano il tipo di contenuto (MIME) che il browser può capire.
- Indirizzo IP: l’indirizzo IP del PC su cui il browser sta funzionando.
- Java Enabled: indica se sul browser Java è attivo
- Lingua: indica la lingua utilizzata dal browser del titolare della carta.
- Screen Colour Depth: indica la profondità della gamma colori utilizzata per la visualizzazione delle immagini sullo schermo.
- Screen Height: indica l’altezza totale dello schermo del titolare della carta in pixel
- Screen Width: indica la larghezza totale dello schermo del titolare della carta in pixel.
- Time Zone: indica la differenza di tempo tra l’UTC e l’ora locale del titolare della carta.
- User-Agent: indica il contenuto esatto dell’intestazione HTTP User-agent.
3. Per l’analisi del rischio esercente
Per migliorare l’esattezza dell’autenticazione basata sui rischi, la banca ha la possibilità di raccogliere e utilizzare delle informazioni aggiuntive sui titolari di carta. Questi dati aggiuntivi non sono obbligatori, ma fortemente raccomandati.
- L'”account cliente”:
Riguarda i dati del cliente detenuti dall’esercente nell’ambito di un account registrato. Questo comprende delle informazioni di base come età dell’account, date di ogni modifica apportata allo stesso, indirizzo di consegna e frequenza delle transazioni, comprese le transazioni riuscite e abbandonate. - Gli acquisti:
Si riferiscono alle abitudini di acquisto del cliente, se i prodotti o i servizi acquistati sono stati ordinati in precedenza (indicatore di nuovo ordine di articoli), luogo di spedizione dell’ordine (indicatore di spedizione) e se l’ordine è acquistato in anticipo (indicatore di pre-ordine). - L’autenticazione delle transazioni passate:
Riguarda gli eventuali intoppi durante le transazioni o se il titolare della carta ha dovuto affrontare una richiesta di autenticazione supplementare. Le informazioni aggiuntive possono includere data e ora dei tentativi di autenticazione precedenti. - L’autenticazione dell’account commerciale del titolare della carta:
Questa categoria si riferisce al login cliente sull’account commerciale e se l’operazione si è svolta su un browser o un’applicazione mobile. L’informazione operativa potrebbe includere dei giustificativi relativi all’emittente e all’autenticazione di terzi, (Google ad esempio). Se l’informazione esistente non è disponibile sul titolare della carta, i dati sono parametrizzati come Guest (ospite).
L’obiettivo è quindi di arricchire la transazione con il massimo di dati contestuali per fornire tutte le garanzie all’emittente ed evitare una richiesta di autenticazione forte.
Calendario di implementazione previsto
1. Europa
Sono previste due date:
- Aprile 2019: trasferimento di responsabilità legato alla nuova direttiva. In altri termini, se un esercente può applicare il nuovo protocollo di autenticazione forte e la banca non è in grado di accettarlo, allora l’esercente beneficia di un trasferimento automatico di responsabilità.
- Settembre 2019: entrata in vigore della direttiva relativa all’autenticazione forte dei clienti. Concretamente, tutte le aziende europee avranno introdotto e applicheranno il protocollo 3D Secure 2.0
2. Canada, LAC (America latina e Caraibi) e USA
- Implementazione: agosto 2019
3. CEMEA (Europa centrale, Medio Oriente e Africa)
- Implementazione: aprile 2020
- Da qui a fine 2020, il protocollo 3D Secure 2.0 sarà quindi implementato su scala globale.
Trasferimento di responsabilità
- Le regole 3D Secure 2.0:
La transazione è completamente autenticata con 3D Secure 2.0. - Responsabilità giuridica
L’emittente è responsabile della frode.
- Le regole 3D Secure 2.0:
L’esercente è conforme a 3D Secure 2.0, l’emittente non soddisfa le misure 3D Secure 2.0. Un tentativo di autenticazione di 3D Secure 2.0 è stato iniziato. - Responsabilità giuridica:
L’emittente è responsabile della frode.
- Le regole 3D Secure 2.0:
L’esercente è completamente conforme a 3D Secure 2.0. Anche l’emittente è conforme a 3D Secure 2.0. La transazione non è autenticata per via di una contestazione. - Responsabilità giuridica:
L’esercente è responsabile della frode.
- Le regole 3D Secure 2.0:
L’esercente risponde alle regole 3D Secure 1.0 ma non a quelle 3D Secure 2.0.
Una transazione è retrocessa a livello 3D Secure 1.0., il che implica un’autenticazione completa del titolare della carta. - Responsabilità giuridica:
L’emittente è responsabile della frode. Ricordiamo tuttavia che 3D Secure 1.0 potrebbe non essere compatibile con la DSP2 (Autenticazione forte del cliente), che potrebbe comportare un piccolo intoppo nell’autorizzazione.
- Le condizioni della DSP2:
Autenticazione forte non applicata.
Nessuna esenzione applicata. - Responsabilità giuridica (Visa, MasterCard):
Rifiuto quindi nessuna autorizzazione.
- Le condizioni della DSP2:
Autenticazione forte applicata – 3D Secure 2.0 realizzato.
Nessuna esenzione. - Responsabilità giuridica (Visa, MasterCard):
L’emittente è responsabile.
- Le condizioni della DSP2:
Autenticazione forte applicata – L’emittente non prende in carico 3DS 2.0.
Nessuna esenzione.
Tentativi AAV/CAVV rinviati all’acquirente. - Responsabilità giuridica (Visa, MasterCard):
L’emittente è responsabile.
- Le condizioni della DSP2:
L’esercente ha richiesto un’esenzione di autorizzazione forte tramite la procedura di autenticazione.
Esenzione accettata dall’emittente.
Nessun intoppo. - Responsabilità giuridica (Visa, MasterCard):
L’esercente è responsabile.
- Le condizioni della DSP2:
L’esercente ha richiesto un’esenzione di autorizzazione forte tramite la procedura di autorizzazione.
Senza intoppi. - Responsabilità giuridica (Visa, MasterCard):
L’esercente è responsabile.
- Le condizioni della DSP2:
Autenticazione forte applicata dall’acquirente.
L’emittente esamina l’autenticazione e sceglie di applicare un’esenzione.
Senza intoppi. - Responsabilità giuridica (Visa, MasterCard):
L’emittente è responsabile.
- Le condizioni della DSP2:
Rifiuto da parte dell’emittente dell’esenzione dell’autenticazione forte. - Responsabilità giuridica (Visa, MasterCard):
L’emittente è responsabile.
Esenzioni possibili
Tuttavia sono previste delle esenzioni di autenticazioni forti. Tra gli altri, possiamo citare i casi di esenzione seguenti:
1. Per i pagamenti inferiori a 30 euro
Se un pagamento è inferiore a 30 euro, è applicata un’esenzione perché è considerata come una transazione di basso valore.
Ciononostante, oltre 5 transazioni esentate accumulate o se la somma delle transazioni supera i 100 euro al giorno, l’autenticazione forte del cliente può essere nuovamente richiesta.
2. Per gli esercenti con bassi rischi
CentralPay è autorizzata a effettuare, in qualità di fornitore di mezzo di pagamento, un’analisi dei rischi in tempo reale. Permette di procedere, se necessario, a un’autenticazione forte del cliente durante una transazione.
L’analisi del tasso di frode effettuata da CentralPay tiene conto del comportamento, delle spese, dello storico degli scenari di acquisto, della posizione del cliente e dell’azienda.
L’esenzione a basso rischio si applica se le soglie dei tassi di frode per gli importi indicati non sono superate.
Tasso di frode e importi:
- Tasso di frode dello 0,13% per le transazioni di un importo fino a 100 euro
- Tasso di frode dello 0,06% per le transazioni di un importo fino a 250 euro
- Tasso di frode dello 0,01% per le transazioni di un importo fino a 500 euro
3. Per i pagamenti ricorrenti (gli abbonamenti)
In caso di pagamenti ricorrenti, l’esenzione si applica nei casi seguenti:
- prima transazione autenticata in modo forte.
- Transazioni seguenti senza autenticazione se sono dello stesso importo e dallo stesso esercente.
- Le transazioni iniziate dall’esercente: risultano da un accordo esplicito (un mandato) fatto tra quest’ultimo e il cliente relativo alla frequenza delle transazioni. Si ricorda che questo copre i casi di utilizzo di transazioni ricorrenti. In questo caso l’autenticazione forte è richiesta solo alla definizione del mandato.
4. Per coloro che godono di fiducia, gli esercenti iscritti nella lista bianca
Il cliente può inserire su una lista bianca (whitelist) degli esercenti di cui ha fiducia. Gli esercenti così autenticati come “beneficiari di fiducia” sono aggiunti a una lista che viene aggiornata dalla banca del cliente. Facciamo notare che l’autenticazione forte del cliente è necessaria alla prima transazione, ma non per le successive. È necessaria anche al momento della creazione, conferma e modifica della lista bianca. Prendendo come riferimento l’ultima autenticazione forte del cliente, l’inserimento nella lista bianca, che si applica ai pagamenti tramite carta e ai bonifici bancari, permette una maggiore flessibilità per quanto riguarda gli importi, il numero di transazioni e il periodo dei pagamenti.
5. Per i pagamenti con carta aziendale
Questa esenzione copre le transazioni effettuate da dei numeri di carte virtuali o carte aziendali che servono per gestire le spese di trasferta dei dipendenti presso agenzie di viaggio online.
Solamente la banca del titolare della carta è autorizzata dalla normativa in vigore a chiedere questa esenzione, perché né l’azienda né il fornitore di mezzo di pagamento possono identificare il proprietario della carta.
6. Per le transazioni MOTO
Le transazioni Mail Orders & Telephone Orders (MOTO) non rientrano nella categoria dei pagamenti elettronici. Sono quindi esentate da una procedura di autenticazione forte del cliente.
7. Per le transazioni al di fuori dell’Europa
La transazione è esentata se l’emittente o l’acquirente di una transazione non è ubicato in Europa. Dopo l’applicazione della direttiva DSP2, le transazioni che provengono da acquirenti non europei saranno verosimilmente accettate.
Implicazioni per gli esercenti
CentralPay ha integrato tutti i processi nei suoi trattamenti per permetterti di trarre vantaggio da questa nuova versione del 3DS: maggiore sicurezza, esperienza di pagamento migliorata.
I nostri servizi sono quindi compatibili al 100% con la DSP2 e il 3D Secure 2.0.
