Piccola guida su come un ente bancario dovrebbe scegliere una soluzione che gli permetta di mantenere il suo posto sul mercato.
La Payment Service Directive (PSD2) è una nuova regolamentazione europea che dovrà essere rispettata nel settore finanziario-bancario sin dall’inizio del 2018. Questa direttiva porterà a maggiori cambiamenti per gli enti che operano in questo settore.
I principali cambiamenti previsti si riferiscono alla necessità di fornire interfacce ai cosiddetti fornitori terzi, di rafforzare i sistemi di autenticazione dei clienti bancari e di fornire il l’autentificazione tramite due o più elementi (multi factor authentication), e questo per la maggior parte delle opzioni di pagamento. In questo modo, i fornitori di servizi di autenticazione saranno anche in grado di fornire servizi utili a dare informazioni sui pagamenti e sui conti dei clienti. Inoltre saranno anche in grado di rivendere servizi bancari sotto forma di offerte “pacchetti” che propongono nuovi benefici per i portafogli dei clienti. Immaginate ad esempio l’attrattività dei servizi bancari aggiuntivi che potrebbe proporvi, nel suo pacchetto di offerte, il vostro operatore di telecomunicazione oppure la vostra catena preferita di supermercati?
Per quanto unanime l’opinione degli esperti di settore sulle conseguenze di questa direttiva, sulle banche, è bene precisare anche i vantaggi che apporterà. Ad esempio, una banca che ha che ha già aperto interfacce di accesso ad un fornitore ha automaticamente accesso ad una base di clienti molto più ricca di quella che è riuscita a riunire in un approccio diretto con i suoi canali classici. Questo dato viene rafforzato se consideriamo la rete di penetrazione delle aziende telco in seno alla popolazione (oltre il 100 %) a confronto di quella delle banche (massimo 60%); anche le catene di supermercati hanno una rete di penetrazione, in aree non-urbane, superiore a quella delle banche.
Perciò, le banche devono adoperarsi ad offrire interfacce, da un lato affidabili e, dall’altro, quanto più sicure possibili, vista la sensibilità altissima delle informazioni che saranno l’oggetto delle transazioni. Le banche annunciano già che vi sarà una grande competizione. In questo senso, gli enti che opteranno per interfacce facili all’uso, con funzionalità estensive potrebbero fare una scelta vincente per essere più attrattive e quindi in miglior posizione per negoziare termini preferenziali nei contratti commerciali con i fornitori di servizi.
Cosa dovrebbe quindi fare una banca? Dovrebbe innanzitutto sviluppare interfacce verso le sue applicazioni interne ed esporle alle parti terze. Queste interfacce (API) dovranno quindi essere sviluppate e poi testate costantemente in termini di sicurezza, poiché l’industria bancaria è, per essenza, un mondo dinamico. Pure le risorse umane impegnate saranno decisive, sia nel momento dello sviluppo delle interfacce e sia durante le connessioni con i sistemi del fornitore di servizi. Dovranno inoltre garantire una presenza continua, e permanente per assicurare la perfetta gestione delle stesse.
Esistono già applicazioni che risolvono in modo esaustivo questi bisogni? Si, esistono: fanno parte delle soluzioni della categoria API Management. Però ogni ente finanziario deve saper scegliere nella gamma di prodotti disponibili quello che fa per lui: per questa ragione ho scelto di presentare qui un compendio che aiuti le banche nella valutazione delle possibili soluzioni
In primo luogo, bisogna chiedersi quali sono i passi decisivi che deve compiere la banca e le funzionalità chiave che vuole mettere a disposizione dei fornitori. In questo modo, i dirigenti potranno assicurarsi che la soluzione di API Management scelta non solo risponderà veramente ai bisogni attuali e futuri, ma soprattutto garantirà alla loro banca una posizione di favore sul mercato, in primis di fronte alle scelte della concorrenza.
Un primo passo può essere la scelta di una soluzione già leader del mercato nel suo campo, o perlomeno in quella dei nuovi challengers così come riportato negli studi indipendenti di nicchia (ad esempio i rapporti Gartner).
Poiché le API che bisognerà sviluppare saranno al servizio di un’applicazione di una banca, cioè uno degli obiettivi privilegiati dagli attacchi cibernetici, il primo aspetto da verificare è che offra funzionalità robuste nel campo della sicurezza informatica. In questo senso, le domande da porre nel dialogo con i rivenditori sono soprattutto le seguenti: l’API richiesto avrà una protezione “by design” contro le minacce? Sarà coerente con le metodologie della community dell’Open Web Application Security Project (OWASP)? Permetterà un’integrazione facile con le applicazioni di tipo Single Sign-On oppure Identity Management garantendo una sicurezza completa di tutte le applicazioni terze, mobili e cloud?
In un secondo tempo, bisogna imperativamente considerare che si parla di un’applicazione che dovrà essere capace di supportare centinaia di migliaia o addirittura milioni di transazioni, ad unità di tempo, e quindi si pone il problema, per le banche, di verificare la scalabilità del prodotto. L’API richiesto sarà in grado di mantenere una performance di alto livello nei giorni di picco, come ad esempio durante il periodo natalizio? Potrà effettuare misure di prioritization, di routing intelligenti e dinamici delle richieste provenienti dalle applicazioni che vi saranno collegate?
Un terzo elemento di grande importanza, visto che l’applicazione dovrà anche competere con altri fornitori, è quello della flessibilità dell’applicazione e della sua facilità d’uso, non solo per la banca stessa, ma soprattutto per i partner esterni all’ente. Bisogna immaginare ad esempio un fornitore di servizi che intende collegare le sue operazioni a due banche diverse. La prima banca gli offre un’API facile da usare, flessibile, con interfacce di amministrazioni ergonomiche ed accoglienti, mentre l’API della seconda banca riscontra tanti problemi. I clienti potrebbero avere errori d’utilizzazione, e di conseguenza il fornitore dovrebbe rivolgersi alla banca per risolvere i vari casi. In queste condizioni, il fornitore raccomanderà ai suoi clienti i servizi della prima banca, anche nel caso in cui questi siano un po’ più costosi paragonati a quelli del secondo ente bancario. Non vi pare uno scenario già conosciuto oggi?
Gli ultimi aspetti da valutare, anche se non sono per nulla di ultima importanza, sono quelli legati alla facilità di realizzare delle API dedicate alle applicazioni mobili, tenendo conto che i nostri supporti IT mobili sono numericamente già ben superiori a quelli fissi. In un altro registro, la banca deve avere la possibilità di controllare con esattezza i tipi di accesso usati e di contabilizzarli in vista della fatturazione. Personalmente, considererei anche la possibilità di offrire un accesso diretto dal cloud verso l’applicazione della mia banca. Anche qui, bisogna tener conto che la migrazione verso il cloud ha già raggiunto una massa critica che rende inarrestabile questo trend. E quindi, perché no, a me piacerebbe poter creare un’API con funzionalità di “drag and drop”. Perché a questo punto, come utente, mi è indifferente il fatto di dovermi collegare con un’applicazione che non ha più di base un supporto, ma una base di dati o un’altra fonte di dati.
In conclusione, se fossi un amministratore di banca, vorrei che la mia soluzione di API Management fosse molto scalabile, coprisse tutto il ciclo di vita di un API e mi offrisse la possibilità di creare un nuovo API in pochi minuti. Soprattutto, esigerei che mi fornisca un supporto mobile di qualità con funzionalità avanzate di amministrazione per la mia banca e per i partner che si collegheranno alle risorse della mia banca. Così, nello stesso tempo, potrei assicurare anche ai clienti della mia banca non solo il controllo totale sui diritti che gli sono conferiti dai fornitori di servizi TPP, ma anche di avere la possibilità, in qualsiasi momento, di attivare/disattivare opzioni oppure di accedere alle nuove funzionalità proposte dalle applicazioni.
Mihai Scemtovici, direttore generale SolvIT Networks
