Passa dalle API, Application Programming Interfaces, la strada verso il digital banking. O, almeno, per costruire intorno alla banca un ecosistema di sviluppatori, e quindi di servizi, in grado di velocizzare il lancio di nuove funzionalità, sfruttare sinergie sul mercato, generare nuovi profitti. E competere così in piena forma nella nuova application economy.
API in banca: chi l’ha già fatto
Esperienze in questo ambito sono già state fatte da diverse realtà europee: Fidor Bank, AXA Bank, Crédit Agricole. In Italia, UniCredit a novembre 2015 organizza la seconda edizione della sua Appathon, riconoscendo pienamente il potenziale dell’API Management. Ma andiamo con ordine e capiamo meglio di che cosa stiamo parlando.
Le API nel quadro della application economy
Il termine application economy si riferisce a un mondo interconnesso e basato su applicazioni mobili, in cui il cliente ha praticamente tutto a portata di mano e di smartphone. Ian Clark, Senior Director for API Management Solutions Sales in area EMEA di CA, in un recente articolo cita una ricerca commissionata a Zogby Analytics, secondo cui il 50% dei consumatori a livello globale nell’ultimo semestre ha utilizzato almeno una app per visitare i social media, fare acquisti, cercare informazioni su un prodotto o guardare un video. Un risultato che porta Clark a definire le app come il nuovo punto di interazione tra brand e consumatore: le aziende dovranno impegnarsi per fornire esperienze digitali di qualità superiore, collegando imprese e partner ai dati aziendali.
Le API per sviluppare applicazioni rapidamente
Un’altra indagine, questa volta realizzata da Forrester Consulting, segnala che il 94% degli executive avverte una pressione crescente verso un rilascio più rapido delle app. Come farlo? Clark individua la soluzione nelle API, acronimo di Application Programming Interfaces. In termini semplici, si tratta di un set di regole che determina come due applicazioni dialogano tra loro, accedendo ai servizi aziendali in real time. Già oggi, tramite API grandi nomi come Google Maps e Facebook permettono ad altre app di “agganciarsi” alla loro offerta: sulla app di un retailer possiamo così trovare una mappa che segnala la posizione del negozio, un sistema di pagamento elettronico e strumenti di condivisione dei propri acquisti sui social network, proprio appoggiandosi ai “dati” (e alle API) di Google Maps e Facebook.
Come condividere le informazioni in una API
Clark sottolinea l’opportunità, per le aziende di ogni settore, di condividere le informazioni aziendali (non indiscriminatamente, come vedremo) tramite API verso sviluppatori, mobile app, partner e servizi cloud, con gli adeguati criteri di sicurezza, performance del sistema, scalabilità della API. Con tre passi per mantenere il controllo dei dati aziendali anche al di fuori del perimetro dei sistemi, riuscendo al contempo a lanciare servizi disruprive in tempi molto rapidi:
- integrando ed esponendo i sistemi critici di business esistenti come API, facendo dialogare i servizi tra di loro;
- permettendo alle aziende di arruolare e gestire sviluppatori di app, che avranno accesso a un portale developer in cui utilizzare l’API, costruire e testare le loro app. Un cambio di marcia significativo per l’innovazione;
- mettendo in sicurezza i dati dell’impresa all’interno delle soluzioni di API management, che garantiscono che all’API e ai dati relativi possano accedere solo applicazioni e utenti affidabili.
L’API Management nei settori bancario e assicurativo
Come si traduce tutto questo nel contesto bancario? Ne ha parlato Fausto Jori, Partner di e*finance consulting Reply, all’ultimo Reply Xchange. Anche secondo Jori le API consentono alla banca (o a una compagnia di assicurazione) di porsi al centro di un ecosistema di servizi digitali, fino ad arrivare a un approccio di Open Banking.
API Management è un altro modo di dire SOA?
No. Rispetto alla SOA, spiega Jori, ci sono tre fattori distintivi:
- Il consumatore del servizio è sconosciuto e “untrusted” per definizione. Se un attore esterno ha accesso alla lista movimenti di un cliente utilizzando un numero identificativo, gli basta cambiare numero per accedere ai movimenti di altri clienti. E questo non deve accadere: la gestione della sicurezza è diversa dagli altri casi;
- Il fattore scala è sconosciuto: l’architettura deve nascere con la possibilità di scalare, perché quando pubblicherò una app non saprò prima quanti device e persone ne faranno uso. E questo rende indispensabile un approccio cloud based;
- Il mio cliente è lo sviluppatore. Non più chi deve contrarre un prestito, ad esempio, ma chi permette ai clienti finali di confrontare il preventivo della banca con quello di altri attori.
Tre “open”: standard, data, source
Riprendendo alcune definizioni di Gartner, Jori elenca tre ambiti di “apertura” per lo scenario di un Open Banking:
- standard: questo è abbastanza ovvio, ma gli standard aperti consentono di raggiungere la massima ampiezza del business;
- data: i dati del player finanziario devono essere aperti, il che non vuol dire privi di protezione o liberamente accessibili (perché costituiscono la ricchezza della banca);
- source: nei sistemi scalabili e complessi l’open source facilita la sicurezza. L’esempio più evidente è quello delle criptomonete, che diffondono l’informazione ovunque per renderla immodificabile.
L'approccio IT driven: l’API come tool
Come tool, la API può essere utilizzata innanzitutto all’interno della banca. Costa meno, è maggiormente scalabile e gestisce anche i rapporti con servizi di terzi: in sostanza, si riducono complessità e costi. Ma è certamente l’uso esterno a offrire le potenzialità maggiori. I dati della banca diventano uno strumento per creare valore, e generare profitti, appoggiandosi ai servizi (e alla programmazione) di terzi. Questo è sostanzialmente il primo step disegnato da Jori, in cui l’API è IT-driven: una mera tecnologia con cui ridurre i costi attraverso una piattaforma flessibile e performante aperta a clienti e partner.
Open Banking Business Driven: apertura anche alle startup
L’Open Banking Business Driven allarga l’accesso alla API anche ad altri soggetti: large corporate, esercenti e startup possono sfruttare gli asset della banca per sviluppare servizi e generare profitti (ovviamente da condividere con la banca, vedremo in seguito come). La banca fornisce la API per fare business e questo è particolarmente efficace per diventare incubatori di startup particolarmente promettenti. Un altro esempio portato da Jori riguarda l’identità digitale: banche e assicurazioni hanno clienti con identità verificate in modo molto efficace. Perché non usarle per accedere anche ad altri sistemi e servizi, magari nel quadro di un framework nazionale promosso a livello governativo? Rientrano in questo ambito anche alcuni servizi di nicchia: un esempio interessante viene dalla Francia, dove una banca ha esposto i propri servizi di pagamento in ottica API e uno sviluppatore li ha utilizzati per una app di pagamento in lingua swahili, utilizzatissima dalla comunità kenyota residente Oltralpe.
L’Open Banking come ecosistema aperto
La API può evolvere fino a diventare un vero e proprio ecosistema di sviluppatori certificati dalla banca o dalla compagnia. Una community che crea e rilascia app appoggiandosi alla piattaforma della banca: le applicazioni vengono pubblicate anche su uno store privato, evitando che qualunque servizio fasullo possa cercare di intercettare i dati dei clienti. In sostanza se boom di app deve essere, meglio cercare di controllarlo garantendo il più possibile la sicurezza e l’affidabilità dei servizi.
Come monetizzare nella API economy
Ovviamente, tutto questo non per la gloria ma per generare nuovi flussi di ricavi. Ancor più importante: per continuare a competere in uno scenario nuovo in cui i player di altri settori sono ormai consci del potenziale delle API e delle community di sviluppatori. E, infatti, per sviluppare una strategia di API Management bisogna avere una idea di business. Oltre al modello “free”, che può comunque essere utile, magari in ambiti limitati, per la brand awareness, gli altri modelli sono developer pays (lo sviluppatore paga la banca, applicando poi dei costi ai clienti finali) e developer gets paid (in sostanza, una formula di revenue sharing tra banca e sviluppatore). L’importante è sapere subito come si vuole monetizzare la propria API, con un vero e proprio condizioniere.
