Banking Standard
3.2.2 Verso l’Open Banking: gli Open Banking Standard
È altrettanto interessante introdurre un ulteriore elemento dalla portata di grande cambiamento e di potenziale crescita per l’intero settore bancario, ovvero l’affermazione dell’approccio Open e la definizione di standard condivisi dai diversi paesi europei e non solo, che stabilirebbero il quadro per la sicurezza e la protezione dei consumatori, puntando su una maggiore condivisione dei dati. L’obbiettivo della riflessione riguardante questo nuovo impulso all’innovazione dei servizi finanziari non è descrivere in modo puntuale gli aspetti tecnici previsti, ma piuttosto offrire una visione sulle potenzialità di questa iniziativa, che richiede lo sforzo di molti operatori, al fine di creare un ambiente condiviso tra tutti i partecipanti.
148
L’Open Banking Standard è iniziativa promossa per primo dal Regno Unito che, in vista dei cambiamenti delle normative bancarie dell'UE, tramite il Dipartimento del Tesoro britannico (HM Treasury) pubblicò nel 2013 un rapporto che spiegava come le interfacce di programmazione potessero essere un ottimo strumento per l'utilizzo di dati condivisi e aperti senza compromettere la sicurezza o la privacy; alla fine del 2015 l’ente ha istituito l’Open Banking Working Group (OBWG), a cui si è aggiunto l'indagine dell'Autorità di Concorrenza e Mercato (CMA) sul mercato bancario al dettaglio nel Regno Unito207, che oltre a soddisfare le previsioni governative, ha ridefinito gli standard che dovranno essere attuati entro il 2019 per innovare davvero il settore finanziario. Diversi mesi dopo, all'inizio del 2016, questo gruppo di lavoro ha pubblicato un manuale, The Open Banking Standard, che indica come i dati finanziari dovrebbero essere creati e condivisi, che definisce le caratteristiche che le API, viste come interfaccia ideale di condivisione delle informazioni, dovrebbero avere e spiega come l'accesso ai dati stessi dovrebbe essere fornito208. Qui di seguito uno schema riassuntivo estratto dal documento del OBWG:
207 risultati dell’indagine consultabili nella sezione CMA di Gov.uk
208 per approfondimenti “The Open Banking Standard. Unlocking the potential of open banking to
149
I clienti richiedono che ormai i dati siano condivisi rapidamente, ma questo non è sempre facile a causa di barriere tecniche, nonché anche per tematiche legali legate alla privacy. Al fine di fornire accesso a questi, lo Standard Open Banking consiglia l'utilizzo di API aperte per operazioni bancarie. È importante notare che l’essere aperta non significa che i dati inclusi siano disponibili per tutti, ma semplicemente che le suddette API consentano d’aprire la tecnologia e lo standard. Infatti l'accesso a dati privati in un'API aperta può essere ottenuto solo con il consenso dei proprietari dei dati e deve inoltre rispettare gli standard tecnici e di sicurezza; ma questa impostazione genererebbe vantaggi a più parti, per esempio agli sviluppatori, fornendo indicazioni su come aprire, accedere e condividere informazioni. Questo "regolamento" aiuterà i professionisti a sviluppare servizi più specifici che soddisfino le reali esigenze dei fornitori e degli utenti finali. Anche l’industria bancaria avrà una semplificazione delle relazioni con i propri clienti; ovviamente ne beneficeranno le Pmi, i cui processi amministrativi potrebbero essere in gran parte automatizzati, ma tutto ciò porterebbe, con i dati transazionali disponibili in modo sicuro, un aiuto importante anche agli enti di sicurezza i quali potrebbero offrire, nel caso di frodi, un monitoraggio e notifica migliori. Dopotutto obbiettivi importanti di questo processo sono certamente la trasparenza, la lotta contro la corruzione e la cattiva gestione bancaria e finanziaria, anche se un loro raggiungimento appare un processo lungo e complicato.
Dunque lo Standard Open Banking suggerisce di costruire una soluzione aperta, federata e in rete, in contrapposizione ad un sistema centralizzato che irrigidisce il mercato, creando inefficenze e riducendone la competizione. Le Open API devono essere rese disponibili sotto una licenza che consenta d’essere liberamente utilizzata e distribuita, abbassando le barriere alla partecipazione ad un’ampia community di sviluppatori. Altro esempio che ci viene in aiuto per parlare brevemente degli aspetti più tecnici di questi strumenti è sicuramente uno dei progetti che riguarda l’Open Banking più maturo ed interessante, ovvero l’Open Bank Project. Nato in Germania nel 2010, fondato da Simon Redfern, CEO di TESOBE, società di software tedesca con sede a Berlino, specializzate nello sviluppo di interfacce di programmazione in linguaggio Scala e Python, che rappresenta l'embrione del progetto Open Bank. Questo si concretizza in un'API a codice aperto e un app store che consente alle istituzioni finanziarie di utilizzare il lavoro di sviluppatori per migliorare i propri prodotti e
150
servizi, con l’ambizione maggiore di creare un’ecosistema di applicazioni di terze parti per la clientela. Oltre a nessuna dipendenza da un provider, questa applicazione fornisce un'interfaccia tecnica uniforme per tutti i programmatori e uno spazio sicuro per la creazione di nuovi servizi nel front-end di una banca o istituto finanziario. Si potrebbe pensare che ciò aumenti notevolmente l'insicurezza e la violazione della privacy del cliente, ma questo non avviene in realtà perchè il suo processo di registrazione è sempre fatto dal lato bancario, per cui vengono garantiti in ogni momento, i requisiti di sicurezza della banca, dato che né l'API né le applicazioni hanno accesso al nome utente e alla password. Inoltre il fatto che la base di programmazione fornita dal Project sia open-code garantisce una sicurezza notevole, poiche’ gli errori possono essere risolti più rapidamente grazie al lavoro di più sviluppatori che utilizzano l'interfaccia. Dunque i vantaggi collegati a questa iniziativa sono evidenti, e ad essi si aggiungono una riduzione dei costi di manutenzione e integrazione delle applicazioni nel proprio sistema, maggiore controllo e sicurezza sulle informazioni e dati sensibili, oltre ad una grande developement community. Le integrazioni nei conti bancari di nuovi prodotti avvengono tramite API REST, cioè un’applicazione per la trasmissione di informazioni. La REST (Representational State Transfer) rappresenta un’architettura di sistema per lo scambio di dati in un’ambiente scalabile e utilizzabile da diversi dispositivi. Non parliamo di uno standard di fatto o di un protocollo ma di un metodo per sviluppare web services, che consente la rappresentazione dei dati in un formato consumabile da differenti devices e ambienti di sviluppo. Infatti, mentre all’inizio Internet era concentrato solo su una richiesta HTTP che procedeva a generare una pagina HTML da consultare con un browser, adesso la situazione e’ cambiata radicalmente, dato che i web server processano informazioni che posso scambiarsi con altre applicazioni e aggiornare dati presenti su server diversi sempre con richieste HTTP specifiche.
Oggi questa architettura è usata da quasi tutte le società che erogano servizi o strumenti di sviluppo per i loro prodotti: le chiamate REST vengono usate su moltissime API per richiedere informazioni di qualsiasi genere, ad esempio Maps e Youtube209.Quindi con un trasferimento di questo tipo si ottengono e si modificano le informazioni, che
151
vengono scambiate in diversi formati tra i quali il JSON (JavaScript Object Notation), uno dei più popolari per lo scambio di dati, di facile elaborazione per le macchine con i vari linguaggi di programmazione210. Inoltre viene garantita un adeguata protezione grazie al protocollo di sicurezza aperto OAuth, ampiamente utilizzato, che permette l'autorizzazione di API con un metodo di sicurezza standard e semplice, sia per applicazioni portatili che web211.
Come abbiamo già detto il progetto berlinese ha pure un proprio store nel quale si possono trovare utili interfacce sviluppate e facilmente integrabili. Questo approccio, lo sviluppo di un marketplace dove rendere pubbliche e concedere in licenza le app sviluppate, è stato seguito anche da BBVA, con il lancio di BBVA API Market, frutto del lavoro di un anno della banca spagnola con sviluppatori e imprese. BBVA è diventata una delle prime grandi banche del mondo ad offrire l’Open Banking, con un’iniziale commercializzazione di otto API attraverso il market proprietario, cosicchè le aziende, le startup e gli sviluppatori saranno in grado di costruire nuovi prodotti e servizi accedendo e integrando i dati bancari del cliente (con la loro autorizzazione) nelle loro applicazioni.
"Aprendo commercialmente i nostri dati e servizi, BBVA sta trasformando in una realtà open banking, che mira a stimolare la concorrenza nel settore, ma che in realtà sta cercando di diventare una piattaforma su cui costruire nuove esperienze digitali. Questa è un'opportunità di business guidata dal cliente "
dice Derek White, responsabile globale delle customer solutions BBVA212. Inizialmente solo i clienti spagnoli di BBVA potranno trarre vantaggio dal mercato ma la banca intende rilanciare il programma anche verso i clienti USA nel prossimo anno, prima di espandersi ulteriormente in Turchia, Messico e l'America Latina. Ma anche aziende provenienti da resto del mondo potranno richiedere l'utilizzo dei singoli set di dati della clientela, a patto che venga concesso il permesso. Ci saranno anche alcuni
210 “Open Bank Project: how open APIs are changing the banking sector”, BBVAopen4u, 2016 211 Definizione OAuth, Wikipedia
152
set di dati aggregati anonimi commercialmente disponibili con i dati ripartiti geograficamente o per settore. Il lancio di questa iniziativa viene dopo che l’istituto ha speso l’intero 2016 per esplorare questo modello di business e per studiare come farlo funzionare meglio per la clientela. Durante questo periodo, più di 1.500 aziende e sviluppatori sono registrati nel portale sperimentale per avere una prima sensazione delle possibilità che le API di BBVA possono garantire alle proprie attività. Un esempio delle opportunità che si potrebbero generare grazie a questo mercato è sicuramente l'API dei prestiti: terze parti possono informare i clienti quando hanno accesso a un prestito pre-approvato dalla banca ma oltre a ciò l’app può essere integrata nel processo di checkout per consentire ai clienti di finanziare l'acquisto di un prodotto o di un servizio di terze parti con un finanziamento emesso dallo stesso ente213. La strategia Open API è un elemento chiave del processo di trasformazione, che permetterà di diventare a chi promuove iniziative del genere il motore d'innovazione per altre aziende.
Punti d’attrito tra PSD2 e GDPR
Tutto ciò in un contesto di grandi cambiamenti normativi che avrà certamente dei risvolti sulle soluzioni tecniche da adottare; abbiamo detto come la disciplina sulla regolamentazione generale della protezione dei dati (GDPR), nonché la Direttiva sui Servizi di pagamento (PSD2) mirino a stabilire le condizioni legali per lo sviluppo e la fornitura di servizi di pagamento nell'Unione Europea, cercando anche di regolare i rapporti di conflitto tra i fornitori di servizi di pagamento presenti sul mercato e i nuovi provider. Tra le questioni che la Commissione, insieme alle disposizioni della EBA, ha e sta attivamente trattando c’è il non meno importante argomento della sicurezza IT, che è stata modificata e resa più rigida. Uno dei problemi che la PSD2 ha delegato all’Autorià bancaria, che va certamente a toccare anche aspetti trattari dalla GDPR, è il trattamento dello Screen Scraping, ovvero il processo di raccolta di dati che appaiono sullo schermo di un dispositivo da un'applicazione per tradurlo in una visualizzazione di un'altra applicazione. Nonostante questo suoni potenzialmente pericoloso per la
153
protezione dei dati del cliente in caso di un suo uso dannoso, ci sono motivi importanti per utilizzare lo “strappo dello schermo”, se utiizzato con il consenso del consumatore finale, dato che attraverso questa procedura possono essere create interfacce che forniranno un accesso diretto ai propri conti o servizi privati. Il problema però si presenta quando i clienti confidano nel software di terze parti per raccogliere e utilizzare i propri dati ma le banche, dal canto loro, non dispongono dei sistemi e degli strumenti adeguati per controllare ogni soggetto che offre la propria schermata, accedendo al proprio conto bancario. Se si tratti o meno di un problema che merita un intervento normativo è un punto di contesa.
Recentemente sull’argomento, l'Autorità bancaria europea (EBA) ha respinto un emendamento alla direttiva sui servizi di pagamento proposto dalla Commissione europea per consentire la prosecuzione della “raschiatura” dello schermo, esprimendo il proprio malcontento per l'intenzione della CE di modificare il progetto di standard tecnici di regolamentazione già definito. La prima bozza della relazione dell'EBA, pubblicato nel febbraio 2017, dopo 18 mesi di lavoro intensivo, ha sollevato obiezioni soprattutto da parte degli operatori del fintech214 per l'attuazione di standard dautenticazione del cliente ingombranti, oltre ai divieti di screen scraping a favore dell'accesso bancario ai dati dei clienti tramite API dalle banche. In sostanza significa che quest’ultime possono negare questo tipo di accesso diretto attraverso la loro “porta d'ingresso”, se forniscono un'altra possibilità di accesso indiretto tramite il software da esse sviluppato. A questo proposito, la CE ha risposto chiedendo all'EBA di lasciare la possibilità di schermatura dello schermo come meccanismo di backup nel caso in cui le interfacce bancarie non funzionino correttamente. Contro i nuovi entranti sostenuti dalla Commissione Europea si è schierata però la Federazione Bancaria Europea (EBF), che ha sostenuto che la riservatezza dei dati dei clienti, della sicurezza informatica e dell'innovazione sarebbero tutti a rischio se gli standard EBA e lo scraping dello schermo continuasse ad essere concesso215. Gli enti bancari, invece, sostengono la loro posizione ribattendo che che queste disposizioni non hanno nulla a
214 Una coalizione composta da 62 imprenditori e sostenitori del fintech ha affermato che le riforme forniranno alle banche i mezzi per controllare i dati condivisi, mettendo in svantaggio i nuovi entranti 215 “Fintechs fight plan to bar screen scraping and protect European banks”, CNBC, 2017
154
che fare con l'onere di compliance che queste devono sostenere rispetto ai competitors, ma che la simulazione dell’operazioni compiute da parte dell’utente sullo schermo possono minacciare la privacy dei dati dei clienti e della sicurezza in rete. Il risultato di questa diatriba è un compromesso in cui verranno effettuati rigorosi controlli e bilanci sull’attività e conformità delle API delle banche216. Analizzando la questione da più punti di vista si può giungere a conclusioni diverse, tra di loro discordanti: dal lato dell’istituto di credito e di un regolatore, impedire lo “strappamento” dello schermo rende molto più semplice implementare i sistemi e i controlli che rendono più difficile la raccolta e la distribuzione non autorizzata di dati della clientela tra terzi, fornendo agli enti bancari l'autorità finale su chi può accedere tramite la propria API. Invece, dalla prospettiva degli operatori del fintech, questo divieto ostacola l'innovazione e l'avanzamento della tecnologia, nonostante si sia visto negli ultimi anni un importante aumento della domanda di servizi innovativi di pagamento online e fornitura di prodotti finanziari attraverso nuove piattaforme digitali. Si prevede che la domanda di tali servizi crescerà esponenzialmente con una maggiore consapevolezza dei consumatori sia in termini di educazione finanziaria che nel trattamento dei propri dati. Ma certamente le banche potrebbero non essere incentivate a cambiare le proprie API per accogliere nuove tecnologie create da player fintech, ritardando con tutta evidenza l'innovazione. Infine, dal un punto di vista del consumatore, l’argomentazione da una e dall’altra parte può essere più o meno vantaggiosa, ma un ruolo cruciale avrà l'introduzione del GDPR ed i possibili conflitti che potrebbero sorgere con la concomitante entrata in vigore della PSD2. Dal maggio 2018 la normativa sul trattamento dei dati sarà un vero e proprio spartiacque tra quello che c’era prima, ovvero le molte legislazioni discendenti dalla Direttiva madre in ambito Data Protection (la n°95/46) e tutto quello che verrà dopo, ovvero l’applicazione di un quadro normativo comune a tutto il territorio UE, volto ad uniformare la disciplina della tutela dei dati personali.
Ma la nuova Payment Service Directive potrebbe presentare alcuni punti di attrito con quelli che sono i dettami della General Data Protection Regulation. Un primo rilievo
155
lo si rinviene nell’art. 94 della Direttiva, rubricato “Protezione dei dati personali” dove nessuna menzione è fatta alla GDPR che, sebbene al momento non sia applicabile, sarà in vigore dal prossimo anno; un primo indice del fatto che l’Unione, non ha probabilmente preso in debita considerazione il suo stesso obiettivo di uniformare la disciplina sulla protezione dei dati personali quando ha implementato la direttiva PSD2. Problemi ad esso collegati potrebbero nascere in caso vengano comunicati tutta una serie di informazioni personali dei clienti da parte delle banche ai nuovi TPP, che abbiamo introdotto nel secondo capitolo, con tutto ciò che questa operazione comporta in termini di compliance al Regolamento Europeo sui Dati. Inoltre anche in tema di diritto alla portabilità dei dati e conseguentemente del diritto alla interoperabilità previsti dall’art. 20 della GDPR possono sorgere problematiche di difficile soluzione, visto che i dati richiesti dai TPP sono soggetti alla titolarità da parte delle banche e di conseguenza, nel rispetto del principio dell’accountability presente in tutto il regolamento, esse devono necessariamente garantirne la sicurezza in un’ottica di protezione del soggetto interessato. C’è da chiedersi come si comporterà la banca in caso di sospetto che la richiesta provenga effettivamente da un ente che offre servizi innovativi ma che non è in grado di garantire le misure necessarie alla protezione del dato; potrebbe rifiutarsi di rispondere alla richiesta, violando quindi l’art. 20 del GDPR ed esponendosi ad un rischio di sanzione217.
Emersi solo alcuni degli interrogativi che potrebbero presentarsi in futuro, è evidente che la maggior parte dei lavori relativi all'applicazione e alla promozione dell’Open Banking Standard non siano di carattere tecnico: se in genere i consumatori sembrano essere disposti a sfruttare le opportunità offerte, le problematiche sono più legate alla governance, alla sicurezza, alla responsabilità, alla regolamentazione. Si può dire che l’affermazione degli standard aperti nel settore bancario non è semplicemente un modo per esplorare nuove fonti di reddito e aumentare i profitti ma è un passo verso un modello economico più sostenibile e più aperto, che cura l’interesse di coloro che vi partecipano. In questo clima di rivitalizzazione, le API agiscono come un catalizzatore
217 “GDPR Vs PSD2: una possibile antinomia nella legislazione UE”, Consulente Legale
156
per il processo di apertura e condivisione di spazi con terzi218. Riguardo questo punto, l'economia mondiale ha affrontato non più di 10 anni fa da una recessione devastante e paralizzante che ha lasciato il settore dei servizi finanziari probabilmente al suo punto più basso in termini di fiducia dei consumatori dopo la Grande Depressione del 29’. La maggior parte dei regolamenti introdotti dal 2008 sono dunque stati mirati ad aumentare la fiducia nel settore, garantendo la protezione dei consumatori. A seguito della crisi dei subprime i regolatori in tutto il mondo hanno richiesto una rigorosa conformità che limita o talvolta esprime il divieto di offrire prodotti che sono considerati rischiosi per i clienti al dettaglio e gli investitori219. In questo senso proibire pratiche potenzialmente rischiose per i risparmiatori può sembrare la cosa giusta da fare, ma nell’ottica innovatrice delle prossime regolamentazioni sulla protezione dei dati e del mercato dei pagamenti tutto ciò potrebbe sembrare contraddittorio, in un'epoca considerata “il decennio del fintech”. Invece di vietare e ostacolare le potenzialità e i conseguenti benefici che potrebbero essere generati dalle financial tecnologies, sarebbe importante lavorare verso due direzioni. Innanzitutto sarebbe consigliabile creare un'autorità indipendente che definisca condizioni e provvedimenti volti a favorire l’evoluzione del mercato della finanza digitale, ma che effettui anche dei controlli sugli operatori e garantisca degli obblighi di conformità a chi vuole avviare la propria attività. Si potrebbe ad esempio fare riferimento ad una versione dell'Ufficio di Facilitazione per il FinTech (FFO) istituito da parte della Autorità Monetaria di Hong Kong con compiti e poteri ampliati. E’ evidente come non non bastino dunque autorità europee come l’EBPR o l’EBA per la supervisione del fenomeno a livello continentale, ma servano autorità nazionali che coordinino