Indagine Empirica

Per rafforzare il proprio posizionamento competitivo AURIGA ha previsto di proporre nuovi servizi anche se nello stesso dominio di business. In particolare questi sono:

Manutenzione HW e Gestione degli ATM Multivendor. AURIGA propone di manutenere gli ATM, sia nella parte HW che in quella SW, di tutti i fornitori e quindi di gestire, per conto dei propri clienti, la rete degli ATM degli stessi.

WWS Ledger, piattaforma di validazione delle relazioni tra entità dell’ecosistema e delle transazioni del MarketPlace AURIGA basata su tecnologia blockchain

WWS Sicurezza: una soluzione completa per la messa in sicurezza del canale self service.

Questi tre servizi si collocano nel dominio di business classico di AURIGA, pertanto possono essere proposti agli attuali clienti. Nonostante questo punto di partenza, essendo innovativi c’è molta incertezza su quanto essi possano essere accettati dal mercato. Inoltre, quant’anche il mercato li accettasse c’è il problema della definizione adeguata dei contenuti desiderati dal mercato.

Considerati l’alto livello di rischio che la implementazione di questi servizi comportano, per minimizzare gli sprechi, si è ritenuto opportuno sperimentare per questi il paradigma del Lean Start Up per validare l’accettazione dei servizi da parte del mercato e del Design Thinking per la progettazione partecipata dei contenuti di ognuno dei servizi.

Lo sviluppo di questi progetti è confrontato con un altro progetto, Plan Play, che aveva lo stesso scopo di diversificazione dell’offerta. In questo progetto si è adottato il vecchio approccio del prototipo per mostrare ai potenziali clienti l’idea e acquisire clienti.

Questi tre servizi si collocano nel dominio di business classico di AURIGA, pertanto possono essere proposti agli attuali clienti. Nonostante questo punto di partenza, essendo innovativi c’è molta incertezza su quanto essi possano essere accettati dal mercato. Inoltre, quant’anche il mercato li accettasse c’è il problema della definizione adeguata dei contenuti desiderati dal mercato.

Considerati l’alto livello di rischio che la implementazione di questi servizi comportano, per minimizzare gli sprechi, si è ritenuto opportuno sperimentare per questi il paradigma del Lean Start Up per validare l’accettazione dei servizi da parte del mercato e del Design Thinking per la progettazione partecipata dei contenuti di ognuno dei servizi.

Lo sviluppo di questi progetti è confrontato con un altro progetto, Plan Play, che aveva lo stesso scopo di diversificazione dell’offerta. In questo progetto si è adottato il vecchio approccio del prototipo per mostrare ai potenziali clienti l’idea e acquisire clienti.

MANUTENZIONE HW E GESTIONE DEGLI ATM MULTIVENDOR

Descrizione del servizio

Parti di Ricambio e Manodopera con relativo spostamento necessario.

• Le parti di ricambio, la manodopera ed i tempi di trasferimento del tecnico durante l’orario di copertura contrattuale, sono inclusi nel canone di abbonamento. 

Manutenzione Preventiva.

• Servizio svolto prevalentemente durante l’esecuzione degli interventi tecnici, mirato alla massima limitazione dei fermi macchina dovuti a problemi hardware 

Servizio Gestione dei livelli di servizio e Reports

• Tale servizio prevede, attraverso strutture dedicate, l’attivazione del controllo delle performance e la realizzazione ed erogazione di opportuni reports periodici, in formati condivisi con il Cliente, per il perfetto monitoraggio delle prestazioni del servizio prestato.

Le caratteristiche di Auriga che sono difficilmente copiabili e che mantengono alto il posizionamento competitivo di Auriga sono:

• Erogazione di servizi HW, indipendentemente dai vendor, e Sw ;
• Capacità di assumere il ruolo di SPOC (Single Point Of Contact) per il customer;
• Autonomia di assistenza indipendente dalla varietà di macchine che ha il cliente
• Attenzione alla customer satisfaction che si manifesta con
  • Timeous response to client;
  • Trasparenza nell’esercizio dell’assistenza;
• Conoscenza e competenza sia delle macchine sia del loro dominio d’uso;
• Affidabilità e puntualità per i clienti.

I valori che il servizio intende conferire ai customer sono:

• Riduzione risorse interne per la gestione HW Multi Vendor
• Uniformità delle condizioni di erogazione dei servizi, indipendente dal vendor e dalle condizioni specifiche di ognuno di essi;
• Riduzione dei costi per parti di ricambio, vandalismi, extra contratto
• SPOC (Single Point Of Contact)
• Unico punto di controllo dello stato delle macchine e dello stato degli interventi richiesti
• Integrazione FLM-SLM (intesa nell’accezione di efficiente integrazione dei vari livelli di erogazione del servizio, il First Level Management, primo front-end, e il Second Level Management ossia parte applicativa, software di base..)

L’innovazione introdotta consiste nell’introduzione delle nuove procedure applicative WWS Asset Management che fornisce anche la possibilità di gestire in modo ottimizzato l’anagrafica completa dei Sistemi per essere più agili negli upgrade richiesti o per ottemperare a normative di compliance (adozione di nuovi s.o. per es.) o per aggiornamento tecnologico. Questo consente alle Banche di avere dei risparmi nella gestione dei processi di gestione del parco macchine e di upgrading dello stesso consentendo di pianificare adeguatamente gli investimenti relativi. L’Asset Management usa il WWS A.I. PREDICTIVE basato su Intelligenza Artificiale. Obiettivo di questa componente è il miglioramento della previsione dei guasti, rendendo più efficiente le attività di manutenzione preventiva così che si riducano i blocchi delle macchine a vantaggio sia dei clienti sia di AURIGA. Tale soluzione aggiungerà i seguenti valori conferiti ai customer:

• Maggiore disponibilità del servizio ATM per clienti;
• Ottimizzazione dei costi di manutenzione ed assistenza.

 

WWS ASSET MANAGEMENT

Architettura e infrastruttura

Universal Agent

WWS Asset Management è una soluzione multilivello (n-tier) altamente scalabile che combina le più avanzate tecnologie Web 3.0 con l’utilizzo di uno agent Client Multivendor e Multiplatform, Multidevice (denominato WWS Universal Agent). Tutti i servizi disponibili sono gestiti centralmente e possono essere facilmente distribuiti ed erogati su qualsiasi tipologia di terminale marca e modello Certificati.

Il WWS Universal Agent può essere installato su ogni terminale (finanziario e non finanziario) e convivere con ogni tipologia di applicazione (Web o Client), ed avrà il compito di eseguire, task di discovery o operatività.

La robustezza della tecnologia WWS Universal Agent, unita alla gestione centralizzata dei servizi per tutti gli endPoint, consentirà una discovery puntuale e dettagliata delle componenti HW e SW distribuite presso le filiali bancarie, a prescindere dal canale di appartenenza.

Tale componente è deputata all’interrogazione dell’ Asset (ATM, ASD, PDU, etc).  Raccoglie le caratteristiche generali del sistema ospitante: HW, SW, Sistema Operativo, Applicativi Terze parti, interrogando quando necessario le specificità di canale quali XFS (service provider Wosa), o XNFS.

L’integrazione dei plug-in consente quindi una totale scalabilità delle capabilities di device applicazion Custom (Antivirus, Checker, etc)

Architettura dipartimentale

La soluzione è composta da diversi macroservizi (centralizzati e distribuiti), tutti integrati e connessi ad un modulo centralizzato di Business Logic che ha il compito di modellare ed esporre dati e servizi, consentire l’accesso alle informazioni applicative e verso tutti i moduli che ne facciano richiesta.

Tutti gli scambi di dati tra i vari moduli, Agent, Back End, Front End, Database avvengono tramite protocollo HTTPS JSONRest,

Otre alle componenti applicative, il sistema è composto da due basi dati, una relazionale nella quale sono archiviati tutti i dati di sistema, configurazione e gerarchici ed una non relazionale, in cui vengono contenuti tutti i profili, Attuali, Storici e Cluster.

FEATURE DEL WWS ASSET MANAGEMENT

WWS Asset Management è un modulo software facente parte della piattaforma WWS, dedicato alla gestione, raccolta e analisi dei dati caratteristici di tutti gli Asset presenti presso le filiali bancarie, indipendentemente dal canale Applicativo o dal Sistema Operativo di riferimento.

WWS Asset Management è altamente scalabile che combina le più avanzate tecnologie Web 3.0 con l’utilizzo di uno specifico agent, Multivendor, Multiplatform e Multidevice denominato WWS Universal Agent. Tutti i servizi disponibili sono gestiti centralmente e possono essere facilmente distribuiti ed erogati su qualsiasi tipologia di terminale, marca e modello.

La robustezza e scalabilità della soluzione WWS Asset Management unita alla modularità e capillarità della componente WWS Universal Agent, consentirà la costruzione puntuale, dettagliata, profonda e sicura delle componenti HW e SW sul territorio a prescindere dal canale e applicazione di riferimento.

Figura 10.1. Dispositivi controllati dal WWS Agent

Il Prodotto WWS Asset Management è funzionalmente composto dalle seguenti classi funzionali:

Cruscotto: Questa sezione contiene le funzioni che permettono all’utente di avere una scheda composta da alcuni Widget di Sistema (Asset Attivi, Offline, In Cluster e Georeferenziati) ed altri personalizzati, creati dal cliente il quale potrà inserire, su una qualsiasi delle caratteristiche dell’asset (HW, SW, XFS, NXFS), il perimetro di tutti i widget disponibili nella dashboard, potrà altresì essere filtrato per arco temporale e gruppo di filiali o banca di riferimento.

• Risorse: Questa sezione contiene le funzioni che permettono, di gestire ogni terminale, confrontare sia le differenze tra due specifici terminali appartenenti al medesimo cluster, per una qualsiasi delle informazioni del profilo completo, sia di confrontare un singolo asset in due particolari momenti storici.
• Task: Questa sezione contiene le funzioni che consentono all’utente di schedulare l’esecuzione di azioni (anche massive) sul sistema in particolari momenti della giornata. Il sistema impone vincoli sulle schedulazioni per determinati tipi di attività, in modo da impedire la richiesta di operazioni troppo onerose in finestre temporali limitate o che potrebbero entrare in conflitto.
• Manutenzione: Questa funzionalità consente di visualizzare e disporre gli interventi di manutenzione preventiva, prodotti dalla engine di Inteligenza artificiale WWS A.I. Predictive.
• Report: L’applicativo permette di effettuare della reportistica immediata e schedulata tra un insieme di 10 Report, preconfezionati, per i quali potrà essere definito, l’UOG (Unità Organizzativa Gestionale (es: Filiale, Area, Direzione, Banca)  e il periodo temporale di riferimento.
• Configurazione: Quest’area permette di Gestire e Visualizzare secondo le seguenti tipologie di informazioni:
  • Generiche: Nomi Canali, Famiglia Dispositivi, Classi XFS o XFSN
  • Filiale: informazione anagrafiche della Filiale, Banca di appartenenza e Asset collegati
  • Cluster: Creazione, Modifica, e Cancellazione
  • Software: Nome Processi, Librerie, ed eseguibili e Cluster di riferimento
  • Altre: Destinazione Risultati dei Task e codici European Court Report (ECR)

Le feacture essenziali sono:

• Dashboard
• Widget Builder
• Georeferenziazione
• Multilingua
• Raccolta profili HW e SW dei sistemi ATM
• Censimento Automatico di  Asset
• Gestione del Lifecycle
• Asset Compliace
• Asset Compare
• Task management
• Manutenzione
• Distribuzione
• Reportistica
• Notifiche
• Asset Fraud Behavior
• Configurazione

Maggiori dettagli su ognuna delle feature citate sono riportate di seguito.

WWS A.I. PREDICTIVE

WWS A.I. PREDICTIVE è un software dedicato all’erogazione di servizi di Intelligenza Artificiale, per lo studio dei dati, la costruzione di previsioni, trend di andamento, Deep Learning, chatbot.

Nello specifico, verrà illustrato, l’utilizzo di questi servizi da parte del prodotto WWS Asset Management finalizzato all’erogazione delle funzioni di Manutenzione Predittiva.

Nel diagramma sotto riportato, illustriamo il processo di condivisione ed elaborazione dei dati di funzionamento con tra i prodotti coinvolti nel processo di funzionamento, Incident Management, e gestione dei terminali.

Il modulo Predictive Maintenance

Questo è deputato all’erogazione di raccomandazioni di manutenzione HW predittiva.

Attraverso l’uso del Machine Learning e dell’intelligenza artificiale è in grado di fornire raccomandazioni sulla manutenzione degli ATM per tutte le filiali presenti in una determinata area.

WWS A.I. PREDICTIVE è diviso in due sottomoduli: Forecasting e Strategy.  Il modulo di intelligenza artificiale Forecasting si occupa dello studio dei dati operativi, assicurativi, fisiologici ed organizzativi, di tutti gli ATM presenti nella filiale e utilizza algoritmi di machine learning, per produrre delle previsioni di operatività di ogni ATM presente in filiale. Il modulo Strategy, utilizzando metodi di intelligenza artificiale, analizza i possibili scenari e trasforma queste previsioni in raccomandazioni per la manutenzione.

I flussi relativi ai movimenti vengono ricevuti in formato CSV o letti direttamente dal database del cliente, rielaborati e registrati nel database del prodotto WWS Asset Management. A questo punto i dati relativi alla configurazione ed operatività delle filiali e degli ATM vengono trasferiti nel database di WWS A.I. PREDICTIVE. Una volta salvati nel database WWS A.I., i risultati vengono passati di nuovo a WWS Asset Management attraverso WWS Monitoring.

Impronta digitale per gli ATM

Questa è rappresentata da tutte le informazioni riguardanti le periferiche presenti in un modello ATM e che lo differenziano rispetto agli altri modelli presenti sul mercato.

Sono presenti ad esempio informazioni sul tipo di stampante utilizzata, al produttore, al chipset, alla RAM, al sistema operativo, etc.

Queste informazioni vengono immagazzinate nei database WWS A.I. e aggiornate in tempo reale, considerando i tassi di guasto, i tempi di funzionamento, gli interventi di manutenzione effettuati su ogni singolo componente oltre ovviamente alle caratteristiche tecniche.

WWS A.I. al momento conosce già la maggior parte dei modelli di ATM prodotti dai principali vendor ed è in grado di incrociare questi dati con quelli provenienti dal monitoraggio degli ATM in modo da migliorare l’accuratezza delle previsioni relativamente agli interventi di manutenzione.

Ad esempio: se è noto che la stampante utilizzata sulla macchina X prodotta dal vendor A è la stessa della macchina Y prodotta dal vendor B e che dopo circa 3500 ore ha bisogno di essere sostituita, il sistema suggerirà un intervento di manutenzione per la stampante installata sulla macchina Y dopo aver registrato che il tempo di attività si sta avvicinando alle 3500 ore.

Forecasting.

È il modulo applicativo deputato allo studio delle serie storiche dei dati operativi ed alla previsione dei loro andamenti futuri utilizzando Machine Learning (ML), Reti Neurali Artificiali (ANN), Long-Short Term Memories (LSTM), Boosted & Bagged Trees (BBT) e Random Forests (RF), oltre ad altri algoritmi di A.I. proprietari. Il ML utilizza metodi statistici per migliorare progressivamente la performance di un algoritmo nell’identificazione del pattern nei dati.

Il sistema di intelligenza artificiale di WWS A.I. per la Manutenzione Predittiva prende in input l’anagrafica e le configurazioni delle filiali e dei loro ATM, lo stato delle periferiche all’atto della previsione, i giorni di chiusura ed apertura delle filiali e le operazioni di manutenzione degli ATM negli ultimi due anni. Grazie al monitoraggio delle macchine è inoltre possibile conoscere in tempo reale informazioni riguardo l’operatività di ogni periferica per un dato ATM.

Training dei modelli

Prima dell’avvio in produzione, è necessario eseguire alcuni step obbligatori con dei dati di produzione, per poter avere dei risultati migliori, e soprattutto allineare il modello e garantire un livello di previsione adeguato al contesto. Una volta ottenuti i dati verrà fatto un “exploratory data analysis”, ovvero lo studio delle caratteristiche dei dati per scoprire anomalie, pattern e formulare delle ipotesi. Successivamente verrà svolto un “data cleaning” dove saranno effettuate tutte le modifiche necessarie al dataset rimuovendo le osservazioni non pertinenti dall’analisi o i missing values. Sono poi necessarie delle procedure di “data wrangling” che permettono di trasformare i dati in entrata in formati utili per la formulazione delle previsioni.

Al fine di aumentare la capacità predittiva dell’algoritmo prescelto è necessario uno step di “feature engineering”, ossia la creazione di nuove feature che possono risultare molto importanti nella previsione delle movimentazioni degli ATM. Alcuni esempi sono location (posizione della filiale e dell’ATM all’interno della filiale), feature estratte dalle date (feature che identificano se la data in esame è un giorno lavorativo, feriale o festivo oppure può essere estratto il giorno della settimana, la settimana del mese ecc.), trend, stagionalità, e feature che provengono dall’anagrafica (vendor, modello, tasso di guasto delle periferiche).

In questo senso gli algoritmi di WWS A.I. per la Manutenzione Predittiva sono in grado di analizzare i dati storici e di incrociarli con i dati giornalieri provenienti dagli ATM tramite l’utilizzo dell’Universal Agent (il cui funzionamento è illustrato nella sezione prerequisiti) e dai dati di funzionamento ricevuti dal Gestore Terminale in modo da fornire delle previsioni basate sui dati storici, sulle informazioni provenienti dal mercato (statistiche del produttore, problemi noti, etc..) e sullo stato attuale delle macchine.

Verrà poi eseguito un processo di “model validation” e “cross-validation”, al fine di confermare la bontà del modello e fornire stime più stabili per migliorare e generalizzare ulteriormente il modello.

Dopo aver individuato ed installato e configurato il set di modelli predittivi più adatti, essi verranno creati e salvati così da poter essere utilizzati. Questi modelli vengono richiamati ogni volta che è necessario produrre le previsioni che servono al modulo Strategy. Al completamento del processo sopra decritto, le periferiche di ogni ATM saranno mappate e viene creata un’impronta digitale per ogni modello.

Esecuzione giornaliera

Una volta caricati i dati anagrafici delle filiali e degli ATM, le ultime operazioni, ed altre informazioni necessarie per fare le predizioni, viene eseguito un processo di “data cleaning” dei nuovi dati, ovvero quei dati che non sono stati utilizzati per fare il training dei modelli. Il passo successivo è rappresentato dal “data preprocessing”, lo step dove vengono eseguite feature engineering e data wrangling.  Le informazioni di cui i modelli hanno bisogno per aumentare la loro capacità predittiva vengono aggiunte e vengono inoltre fatte le procedure che permettano di trasformare i dati in entrata in formati utili per la formulazione delle previsioni. Una volta che i dati sono nel formato adatto alla necessità del modello, questo viene chiamato e vengono prodotte le previsioni.

Le previsioni sono generalmente strutturate in modo da coprire un arco temporale di 30 giorni.

Strategy

È il modulo che si occupa di trasformare i risultati ottenuti dai modelli previsionali del modulo Forecasting in raccomandazioni per il business. In particolare, una volta ottenute le previsioni per la finestra temporale da analizzare, la strategia simula i possibili scenari in questo arco temporale e fornisce dei suggerimenti per gli ordini.

Il modulo necessita di parametri che provengono da:

• WWS Universal Agent
• Messaggi di funzionamento inviati dal Gestore Terminale
• Impronta Digitale degli ATM
• Dati forniti dal cliente

Nel setup iniziale è necessario che il cliente fornisca alcuni dati che altrimenti non potrebbero essere recuperate (anagrafica delle filiali, informazioni relative alle SLA contrattuali, anno di produzione e messa in opera dei terminali, etc.).

Parametri Area/Filiale

Questi parametri possono essere rappresentativi delle caratteristiche di un gruppo di filiali appartenenti alla stessa area geografica, o accomunate soltanto da:

• Orario di apertura pubblico: identifica l’orario di apertura al pubblico della filiale
• Orario di apertura effettivo: identifica l’effettivo orario osservato dalla filiale (potrebbe non coincidere con l’orario di apertura al pubblico)
• Posizione geografica: è composta dalle info relative a latitudine e longitudine, nonché alla provincia e regione di appartenenza.
• Calendario chiusure: giorni in cui la filiale è chiusa e non possibile effettuare manutenzione.
• Tipologia di Località (Balneare, Urbane, Montana, etc.)

Parametri ATM

I parametri relativi agli ATM contengono sia le informazioni relative alla posizione dell’ATM che quelle riguardanti le singole periferiche.

Caratteristiche degli ATM

• Logistica: indica se ATM è interno, vestibolare, esterno o esternalizzato.
• Vendor: Produttore ATM
• Model info: informazioni relative al modello
• Tempo di utilizzo del dispositivo: quotidiano (es: quante ore lavora) e totale (da quanti anni è attivo).
• Caratteristiche SW
• Tasso di guasto delle periferiche
• Maintenance time: tempo necessario per l’esecuzione dell’intervento (Es. Next Business Day)
• Anno di produzione

Processo di sviluppo

Coerentemente con il processo di Lean- Startup il progetto si è sviluppato producendo tre MVP.

MVP I

Presentazione della proposta della soluzione ai clienti. In questa fase si è provveduto ad organizzare meeting con i clienti target per la presentazione della soluzione con il relativo set funzionale ipotizzato. In tale sede si sono definiti i requisiti emergenti del prototipo per coloro che hanno mostrato interesse alla soluzione.

Tempo-persona speso: 70 gg-persona

MVP II

Realizzazione di una prima versione del prototipo da presentare ai clienti. Determinato in base alla priorità dei requisiti concordati con i clienti che avevano mostrato interesse alla soluzione nella prima fase. Grazie all’uso del prototipo si è potuto definire anche l’ambiente custom e specifiche architetture di sistema da adottare. Il prototipo si basava su simulazioni sviluppate sulla base dei dati storici forniti dai clienti per le loro specifiche situazioni afferenti i servizi. Qui si sono potuti applicare i principi del design Thinking attraverso i quali si è potuto realizzare una progettazione partecipata della nuova soluzione.

Tempo-persona speso: 210 gg-persona

MVP III

Realizzazione ed esecuzione della sperimentazione in campo, presso i clienti che si sono mostrati interessati dopo aver visionato la prima versione del prototipo, della seconda versione del prototipo.

Tempo-persona speso: 1. 300 gg-persona

Lavori Futuri

A fronte dell’esito positivo del prototipo in seconda versione, sono iniziate le attività di sviluppo incrementale in base al set funzionale definito e concordato con ciascun cliente.

Analisi

Con il primo MVP Auriga si è assicurata che i potenziali clienti riconoscessero come valido il problema di cui si stava proponendo la soluzione e sono emerse le caratteristiche principali del servizio. Si è anche rilevata la potenziale adesione di clienti che assicuravano ad Auriga circa 700 macchine da assistere (non importava il numero di clienti perché le entrate sono guidate dal numero di macchine).

Con il secondo MVP si è potuto fare uno smoke test della soluzione concepita da Auriga, si sono potuti rilevare bisogni più dettagliati e si sono potuti definire anche i prezzi che avrebbero reso possibile l’acquisizione dei servizi da parte delle imprese. Inoltre un certo numero di partecipanti alla dimostrazione si è detta disponibile a provare sia il prototipo presentato sia le sue evoluzioni. Il tasso di conversione da potenziale aderente a sperimentatore del prototipo ha mantenuto il 90% della coorte di 700 macchine e se ne sono aggiunte altre 200 raggiungendo così una linea di base di 800 macchine. A questo punto si sono potuti calcolare con buona affidabilità: la profittabilità del nuovo servizio; il costo di acquisizione di nuovi clienti (pressoché nullo inizialmente perché si stava insistendo sui clienti già in essere), ripetibilità dell’acquisto che, s’era compreso, dipendeva dalla qualità del servizio vista la competitività della politica di prezzo che si era ipotizzata con i potenziali clienti. Con queste informazioni si è potuto fare un piano di sviluppo con un ragionevole rischio.

Il terzo MVP è stato il risultato del piano di cui si è detto prima con questo la coorte delle 800 macchine è risultata tutta disponibile a sottoscrivere un contratto appena fossero sistemati alcuni dettagli. Tale coorte si è estesa con customer che hanno portato la linea di base a 1200 macchine.

WWS SICUREZZA

Introduzione

Gli Automated Teller Machines (ATMs) contengono una considerevole quantità di denaro e elaborano dati sensibili dei clienti per processare prelievi/versamenti e operazioni bancarie. Nel passato i criminali si focalizzavano principalmente su attacchi fisici per raggiungere il denaro contenuto all’interno della cassaforte degli ATMs. Catturavano inoltre i dati dei clienti contenuti nella banda magnetica sugli ATMs utilizzando dispositivi anti-skimming durante l’inserimento della carta. Ora, invece, i criminali sempre più utilizzano attacchi di tipo logico per manipolare il software di un ATM per dispensare contante o per catturare dati sensibili dei clienti. Questi attacchi logici sono diventati sempre più sofisticati e la loro esecuzione è tipicamente ben organizzata. Sono progettati per rubare i dati sensibili dei possessori della carta come PAN, PIN e il numero di conto corrente o per dispensare contante rimanendo inosservati il più a lungo possibile e danneggiano la riservatezza, l’integrità e l’autenticità dei dati transazionali.

Problema

Le reti ATMs sono basate sul protocollo Internet e fronteggiano gli stessi attacchi di altre reti basate su IP come ad esempio attacchi di tipo “denial of service”, “sniffing”, “man-in-the-middle” o “eavesdropping”. La comunicazione tra ATM e Host può essere utilizzata come punto d’ingresso per lanciare attacchi remoti. Tra i clienti di Auriga è utile citare il caso di Iccrea che ha subito una frode ben congegnata perpetuata sulla sua rete di ATM che, tramite un malaware che si agganciava al firmware dei dispositivi di cash-out, è riuscita a far dispensare importanti quantità di contante su più apparati “a comando”. Sul posto, al momento della erogazione del contante, erano presenti dei complici che hanno così recuperato il denaro lasciando l’ATM completamente vuoto (in un ATM ci possono essere anche 180.000€).

Proposta di soluzione

La soluzione proposta da Auriga è il prodotto WWS Cyber Security basato su Checker ATM Security fornito da GMV. Il Checker è un prodotto di cyber-security specificamente disegnato per gli ATMs e i Kiosks che aiuta gli istituti bancari a proteggersi dagli attacchi logici in maniera veloce e efficace.

Il Checker protegge le applicazioni software degli ATMs, le loro librerie e l’integrità del sistema operativo. Controlla l’esecuzione di processi legittimi ed impedisce l’esecuzione di malaware tramite l’utilizzo delle whitelist coniugato con una capacità di firewall configurabile a livello applicativo. È inoltre in grado di monitorare l’utilizzo delle periferiche di un ATM come ad esempio le tastiere, i pannelli operatore e i driver USB per bloccare ogni possibile attacco; previene lo sniffing dei dati con una comunicazione criptata VPN-based e garantisce la conformità allo standard PCI-DSS impedendo la memorizzazione dei dati della carta in chiaro.

Il Checker inoltre fornisce una console centralizzata che monitora un ampio spettro di funzionalità che vanno dagli allarmi operativi, alla gestione delle whitelist e alla loro configurazione/download sul parco ATM. In questo modo è possibile garantire che questa combinazione di feature di sicurezza possano essere gestite in maniera facile, sicura ed appropriata in una rete multi-vendor di ATM all’interno di una organizzazione bancaria complessa.

Proposizione di valore

WWS Cyber Security è il primo prodotto progettato specificatamente per rafforzare la sicurezza degli ATMs, dei Kiosks e dei sistemi self-service finanziari in generale;

WWS Cyber Security, grazie a Checker, conferisce una feature efficiente ed efficace di auto-apprendimento che aiuta l’utilizzatore a costruire una whitelist in circa due giornate di lavoro. Questa funzionalità consiste nella possibilità di registrare tutte le azioni che avvengono durante l’operatività di un ATM che vengono poi tradotte in automatico in regole all’interno della whitelist.

WWS Cyber Security, grazie al Checker, riesce, in un unico prodotto controllato in maniera centralizzata, a controllare la sicurezza dei processi, delle comunicazioni e dei device dell’ATM utilizzando le whitelist, il firewall integrato, la gestione dei processi java e il controllo sull’accesso ai device dell’ATM;

WWS Cyber Security è un prodotto molto “light” in termini di memoria e CPU impegnate sugli ATM in modo tale da non interferire sulla normale operatività delle macchine. Inoltre è “compatto” nel senso che con un unico agente è in grado di controllare la sicurezza a 360 gradi;

La manutenzione nel tempo degli agent installati sulle macchine e l’evoluzione delle whitelist è molto lineare ed intuitiva utilizzando la console centralizzata.

Processo di implementazione

Coerentemente con il processo di Lean- Startup il progetto si è sviluppato producendo tre MVP.

MVP I

Presentazione della proposta della soluzione ai clienti.

Tempo-persona speso: 148,6 hh

Con questo primo ciclo si è mostrata interessato il cliente ICCREA.

MVP II.

Realizzazione del primo prototipo di WWS Cyber Security e progettazione partecipata della soluzione per renderla il più aderente possibile ai bisogni del potenziale cliente.

Tempo Persona speso: 230 hh

È stata di fondamentale importanza la capacità di controllo centralizzato che ha soddisfatto le aspettative del cliente ICCREA che ha scaricato la soluzione per provarla.

MVP III.

Il primo impianto in sperimentazione del Checker sia lato server che client e la creazione delle prime 8 whitelist necessarie per la messa in sicurezza degli ATMs di Iccrea;

Il supporto on-site di una risorsa per il mantenimento nel tempo delle whitelist.

Tempo persona speso: 487,2

Il cliente è stato soddisfatto grazie alla velocità di costruzione delle whitelist e di deploy in campo.

In 3 mesi si è messo in sicurezza l’intera rete di ATM di ICCREA composta da oltre 2.000 macchine completando con successo i seguenti passi:

Installazione e configurazione di WWS Cyber Security, sia client che server, in ambiente di collaudo e di produzione;

Preparazione di 8 whitelist su 4 vendor (Wincor, Diebold, NCR e Sigma) sia su sistema operativo Windows 7 sia su Windows XP;

Rollout della soluzione in produzione su tutte le macchine della rete ATM di ICCREA.

FUTURI SVILUPPI

Sono da verificare con i metodi detti in precedenza i seguenti possibili sviluppi:

Integrazione con la console Auriga WWS Server: si può integrare la console del checker che riporta lo stato e gli eventi di sicurezza per ogni ATM con lo stato di funzionamento applicativo riportato dalla console Auriga WWS Server. In questo modo, come valore aggiunto, si possono evidenziare eventuali malfunzionamenti applicativi dovuti alle restrizioni di sicurezza forzate dalle whitelist del Checker.

Integrazione con le procedure bancarie di monitoraggio: normalmente tutti gli istituti bancari hanno un prodotto di monitoraggio che li consente di tenere sotto controllo le prestazioni e lo stato di tutta la rete di ATM. Questo per ogni componente applicativa presente sulle macchine come l’applicazione bancaria Vassallo, l’antivirus, il software preposto al download degli aggiornamenti, ecc.. La proposta di Auriga è quella di fornire un micro servizio per l’esportazione delle informazioni sullo stato del checker per tutta la rete ATMs e di integrarlo nel meccanismo di monitoraggio bancario.

Integrazione con le procedure bancarie di manutenzione tecnica degli ATM: la presenza del Checker sulla macchina ostacola il lavoro di manutenzione della stessa effettuato da un tecnico. Il Checker infatti blocca tutti i programmi, eseguibili, script non espressamente consentiti tramite la whitelist ed i programmi di diagnostica di un tecnico non sono normalmente inclusi per ragioni di sicurezza. Per evitare ritardi nell’intervento tecnico, dovuti al fatto di dover temporaneamente disabilitare il Checker sulla macchina tramite azione manuale sulla console centralizzata, è possibile rendere automatico la fase di sblocco. Ad esempio tramite una APP o da pannello operatore il tecnico potrebbe inserire le sue credenziali, gli estremi della macchina su cui deve fare l’intervento e, tramite WWS Server, autenticare la richiesta e sbloccare il Checker sulla macchina.

Analisi

Come nel caso precedente si è proceduto con l’approccio Lean Startup attraverso passi analoghi. In questo caso con il primo MVP Auriga si è assicurata che, in questo caso, un potenziale cliente riconoscesse come valido il problema di cui si stava proponendo la soluzione. Bastava questo cliente come linea di base perché da solo avrebbe reso significativo l’investimento del progetto perché rappresentava 2.000 macchine da mettere in sicurezza. Inoltre, data l’importanza del cliente l’adozione da parte sua del prodotto-servizio avrebbe accreditato quest’ultimo così che sarebbe stato altamente probabile aumentare il numero di clienti.

Nel I MVP sono emerse le caratteristiche principali che il cliente richiedeva al prodotto. Si è anche rilevata la potenziale adesione di clienti che assicuravano ad Auriga, come si è detto 2,000 macchine da mettere in sicurezza. Anche in questo caso non importava il numero di clienti perché le entrate sono guidate dal numero di macchine.

Con il II MVP si è potuto fare uno smoke test della soluzione concepita da Auriga, si sono potuti rilevare bisogni più dettagliati e si sono potuti definire anche i prezzi che avrebbero reso possibile l’acquisizione del prodotto-servizio da parte del potenziale cliente. Inoltre il potenziale cliente si è detto disponibile a provare sia il prototipo presentato sia le sue evoluzioni. La probabilità di conversione da potenziale a cliente utilizzatore della soluzione si è valutata molto alta, circa certezza. A questo punto si sono potuti calcolare con buona affidabilità: la profittabilità del nuovo prodotto-servizio; la replicabilità della fornitura della soluzione allo stesso cliente che, s’era compreso, dipendeva dalla qualità del servizio vista la competitività della politica di prezzo che si era ipotizzata con il potenziale cliente. Con queste informazioni si è potuto fare un piano di sviluppo con un ragionevole rischio.

Il III MVP è stato il risultato del piano di cui si è detto prima con questo il potenziale cliente ha accettato di sperimentare il prodotto-servizio su tutte le 2.000 macchine che aveva in rete. Il successo della sperimentazione determina l’acquisto della soluzione.

Plainpay

Introduzione

Il progetto plainpay nasce nel 2009 sulla base di una serie di considerazioni sull’evoluzione del canale mobile che prevedeva l’aumento degli utenti smartphone rispetto a quelli PC

Si è quindi progettata una applicazione mobile in grado di fornire funzionalità finanziare di diverso tipo tramite l’utilizzo di tecnologia QR-Code.

Un QR Code è un codice a barre bidimensionale (o codice 2D) a matrice, composto da moduli neri disposti all’interno di uno schema di forma quadrata. Viene impiegato per memorizzare informazioni generalmente destinate ad essere lette tramite un telefono cellulare o uno smartphone. In un solo crittogramma sono contenuti 7.089 caratteri numerici e 4.296 alfanumerici.

Il nome QR è l’acronimo dell’inglese quick response (risposta rapida), in virtù del fatto che il codice fu sviluppato per permettere una rapida decodifica del suo contenuto.

Scenari di utilizzo

Effettuare acquisti senza contante tra  (Consumer to Business | Consumer to Consumer | Business to Business) senza l’utilizzo dei circuiti convenzionali di moneta elettronica (POS, Carta di Credito), riducendo notevolmente le percentuali di commissione.

Mario Rossi ha attivato il servizio sul suo iPhone e si reca presso Auriga Abbigliamento, società convenzionata PlainPay ed effettua il pagamento di un jeans utilizzando il suo cellulare.

Mario Rossi, avvia l’app e dal menu seleziona PAGA e mediante la fotocamera acquisisce i dati per il pagamento dal QR code del negozio …

… Indica l’importo e il PIN di pagamento e CONFERMA il pagamento

Mario Rossi, riceve l’SMS di notifica e sul terminale dell’esercente arriva la mail di notifica del pagamento.

Prelievo Cardless, l’applicazione mobile PlainPay interagisce con un terminale ATM e permette il prelievo senza l’utilizzo della carta.

Il meccanismo è simile al pagamento C2B, l’ATM presenta un QR-Code che l’APP plainpay legge per creare una sessione tra lo smartphone e l’ATM

A questo punto l’ATM esegue i comandi che riceve dal server di gestione sulla base della richiesta configurata su mobile (ad esempio prelievo di 100€ e stampa dello scontrino).

• Altre applicazioni ipotizzate
• Pagamento web
• Pagamento rette scolastiche
• Pagamento bollettini
• Pagamento biglietti di ingresso (musei, mostre, monumenti, ecc.)

Implementazione

Auriga decise di procedere con l’implementazione del sistema in modo da poter offrire il prodotto finale ai propri Clienti, assumendosi il rischio e costo dello sviluppo.

Il costo complessivo del progetto in giorni persona è stato pari a 1500 gg-persona di cui 700 gg-persona per la prima versione (2011-2012) e altri 800 gg-persona (2012-2013) sperimentazione con CartaSi nel tentativo di renderlo funzionalmente più ricco attraverso i risultati della stessa sperimentazione.

Purtroppo il prodotto non è mai decollato per una serie di motivazioni tra cui:

Necessità di adozione da parte della Banca di un prodotto di mobile banking dove spesso esisteva già una soluzione attiva;

Scarsa disponibilità da parte delle Banche a creare un ecosistema per la soluzione;

Concorrenza diretta da parte dei circuiti di credito/debito che non volevano perdere quote di mercato.

Al momento il prodotto è utilizzato da poche realtà per l’implementazione del prelievo cardless sugli ATM.

Analisi

In questo caso si è proceduto con l’approccio Lean Startup. Le conseguenze sono state che solo dopo aver investito 2.000 gg-persona Auriga ha constatato che il prodotto concepito non fu accettato dal mercato. È evidente lo spreco generato.

È opportuno rilevare anche che già al primo stadio di sviluppo si erano spesi ben 1.500 gg-persona. Quindi utilizzare l’approccio per prototipi piuttosto che per MVP risulta essere ad alto rischio di sprechi.

Prelievo PSD2

Il progetto Prelievo PSD2 nasce sulla base delle nuove opportunità fornite dall’entrata in vigore della PSD2, che ha dato ufficialmente inizio quella che può essere definita la digital transformation del mondo bancario: la nuova direttiva è vista infatti come la chiave di volta nella rivoluzione che sta investendo il mondo dei pagamenti, sia da parte delle banche sia da parte di quei soggetti definiti fornitori di servizi di tipo bancario.

Il concetto cardine della PSD2, cioè l’esistenza di API per l’accesso a servizi bancari, abilita una serie di iniziative come quella ipotizzata da Auriga, il prelievo cardless tramite PSD2. Questa capacità di inter operare con il mondo bancario genera la necessità di avere un meccanismo adeguato per la tracciatura e riconciliazione delle operazioni tra i vari attori. Ancora una volta una nuova tecnologia, quella dei ledger distribuiti su blockchain, fornisce una valida soluzione come meglio descritto in seguito.

Auriga ha sviluppato un nuovo modulo di WWS, WWS Open API, per rispondere alle esigenze e opportunità offerte dalla PSD2, questo nuovo add-on permette alle banche e alle Terze Parti (TPP) una più facile interconnessione tramite l’esposizione e il consumo di una serie di API che abilitano le funzionalità richieste dalla normativa PDS2 e più in generale della filosofia Open Banking.

In aggiunta a questo prodotto è stato ipotizzato un sistema per abilitare il prelievo in circolarità utilizzando le API PSD2 e per tale motivo due ulteriore moduli sono stati ipotizzati e analizzati con processo Design Thinking.

WWS Ledger, come parte integrante dello scenario scaturito dall’Open Banking è prevista una (o più) Blockchain di supporto alle relazioni tra entità dell’Ecosistema e alle transazioni del MarketPlace sottostante. In particolare, ma non esaustivamente, WWS Ledger fornirà supporto per la gestione di

Relazioni tra le entità in termini di servizi offerti e consumati, andando a definire in modalità sintetica e digitale gli accordi e i reciproci impegni

Settlement e clearing, fornendo le evidenze certificate di tutte le interazioni e occorrenze dei servizi utilizzati

Peer to Peer ledger, andando a salvare in modo immutabile le transazioni e i cambiamenti di stato tra entità dell’Ecosistema

WWS Ledger gestisce una blockchain di tipo Permissioned Ledger, con ruoli diversificati.

WWS Smart Agent, Per una smart integration di soluzioni SelfService preesistenti è stato concepito questo Smart Agent che permette di estendere il range di funzionalità senza complesse modifiche del SW di gestione dei dispositivi. Si basa su di un concetto di wrapping XFS che garantisce una semplice installazione e manutenzione dell’Agent.

Sono stati identificati diversi scenari di applicabilità della soluzione come meglio descritto di seguito

Scenario 1

Questo è il caso più semplice, di fatto il prelievo da conto viene erogato tramite API PSD2.

Banca Accettatrice: è la Banca che gestisce gli ATM e deve ricevere un pagamento pari all’importo del prelievo+ fees – Banca 1

Banca Pagatrice: è la Banca con cui l’utente ha un rapporto di conto corrente che sarà utilizzato per avviare il pagamento via API PSD2 da parte dell’APP. Può essere l’erogatrice dell’APP usata dall’utente – Banca 1

Mobile APP: è l’applicazione mobile Plain Pay gestita da WWS che abilita l’interazione con l’ATM e gestisce l’accesso ai servizi PSD2 (e.g. strong authentication)

ATM: è il dispositivo self service che eroga il contante.

WWS: è la soluzione omnicanale che gestisce tutti gli elementi dell’operazione. A seconda di dove il WWS è installato (Banca 1 o Auriga) si configura il ruolo di TPP.

Il semplice diagramma di sequenza qui riportato indica graficamente il flusso operativo della funzione e le relative relazioni tra entità coinvolte.

Il flusso è semplificato in quanto ci possono essere operazioni di supporto (ad esempio la verifica del saldo prima di selezionare un importo specifico da prelevare) e personalizzazioni richieste da parte delle Banche aderenti al servizio.

Scenario 2

In questo caso la Banca Accettatrice non coincide con quella Pagatrice, si configura appieno lo scenario abilitato dalla PDS2.

Lo scenario è reso comunque immediatamente attuabile dalla appartenenza delle due Banche allo stesso centro servizi di gestione ATM che utilizza WWS per la gestione degli ATM e può erogare Plain Pay.

Gli elementi attivi di questo scenario restano gli stessi (Accettatrice, Pagatrice, Mobile App, …) cambia solo la direzione dell’operazione di pagamento (che diventa inter Banca) e la rendicontazione che può tener conto dei due sistemi informativi coinvolti (quindi ad esempio fornire un flusso di riconciliazione operazioni alla Banca Pagatrice in aggiunta a quello già erogato per la Accettatrice)

In questo caso il centro servizi si configura nel ruolo di TPP.

Scenario 3

In questo caso la Banca Accettatrice e quella Pagatrice non condividono lo stesso ambiente operativo (centro servizi) ma resta valido lo scenario abilitato dalla PDS2.

Lo scenario è reso comunque immediatamente attuabile dalla presenza di WWS in entrambe le banche e la capacità di WWS di effettuare il routing di operazioni verso altre istanze di WWS.

Per semplicità di rappresentazione si è ipotizzato che la Banca Pagatrice sia l’erogatrice del servizio Plain Pay, ma naturalmente questo non è richiesto in quanto un qualsiasi ente configurato come TPP può svolgere il compito.

Come nel caso 2 l’operazione di pagamento è inter Banca e la rendicontazione che può tener conto dei due sistemi informativi coinvolti (quindi ad esempio fornire un flusso di riconciliazione operazioni alla Banca Pagatrice in aggiunta a quello già erogato per la Accettatrice).

Scenario 4

Questo scenario non implica l’adozione di WWS da parte di entrambe le Banche ma solo da parte della Pagatrice (o di un TPP/IF puro).

Lo scenario di interazione dell’utente con l’App resta invariato ma l’ATM è quello di una qualsiasi Banca Accettatrice che ha stipulato un accordo con la Pagatrice e che installa quindi il WWS Agent sui propri ATM e i moduli WWS Open API, Gestione ATM Remoto e Ledger a livello server.

Il WWS agent direttamente connesso con il Modulo WWS della Accettatrice gestisce l’operazione fisica sul terminale XFS, presentando all’utente una UI simile a quella dell’App.

Il modulo WWS può quindi fornire tutte le informazioni di riconciliazione ai sistemi della Accettatrice, e anche fornire un punto centralizzato di verifica della materialità sull’ATM in quanto lo smart agent può tener traccia di tutte le operazioni effettuate sul terminale.

Lo smart agent di WWS viene installato in aggiunta alla soluzione esistente ed è caratterizzato dai seguenti elementi

Lo XFS Wrapper, questo componente estende le funzionalità dello XFS manager standard fornendo (in maniera trasparente alla applicazione esistente) l’accesso alle periferiche e il controllo della interazione con il terminale.

Lo Smart Agent, che pilota le funzionalità aggiuntive (ad esempio il prelievo PSD2) in congiunzione con il WWS remoto. L’agent è un oggetto autoconsistente, la logica di business è definita su WWS e non necessita di aggiornamenti pilotati da applicazioni esterne.

Lo Smart Agent UI Container, che può sovrapporsi alla UI dell’applicazione esistente e ospitare la navigazione delle funzionalità aggiunte dello Smart Agent

Lo Smart Agent può essere attivato da diversi eventi e condizioni, ad esempio la pressione di un tasto specifico sull’EPP o anche un wake-up remoto inviato da WWS quando l’utente identifica l’ATM su cui operare tramite QR code.

Scenario 5

Questo scenario prevede l’estensione ad una rete di esercenti (ad esempio Tabaccai) la possibilità di erogare contante tramite dispositivi di ricircolo che riferiremo nel seguito come punti di prelievo.

Questo offre la possibilità di gestire in modo efficace il surplus di cassa e di ottimizzarne la giacenza, nonché validare formalmente le banconote fornite all’Utente.

Alcuni elementi supplementari sono presenti nello scenario, in particolare

Cash Handler: è un dispositivo di ricircolo banconote compatto che può essere installato nell’esercizio convenzionato e gestito direttamente dall’esercente. Questi potrà alimentarlo tramite semplici operazioni di deposito che andranno a incrementare la disponibilità del punto di prelievo e contestualmente certificheranno le banconote come valide. Il totale versato resta nella piena diponibilità dell’esercente finché non viene dispensato all’Utente.

Esercente: è il gestore del punto di prelievo che alimenta il CH e lo gestisce contabilmente con il supporto della console (web o app) di WWS. È da notare che Plain Pay fornirà agli utenti finali tramite geolocalizzazione l’esercente convenzionato più vicino con la specifica disponibilità.

Valutazione del progetto

Conformemente ai principi del Lean Startup si è proceduto con

Un’analisi del contesto tecnologico/normativo/strategico in cui posizionare il nuovo prodotto; costo in gg-persona = 12.

Una disanima degli scenari con indicazione dei processi sottostanti; costo in gg-persona 8.

Una stima dei potenziali costi di implementazione; costo in gg-persona 3.

Data la complessità della soluzione come I MVP si è predisposto una serie di presentazioni per illustrare ai potenziali Clienti la soluzione. Il costo di produzione ed erogazione di tali presentazioni è stato pari a 23 gg-persona.

Tali presentazioni sono state discusse con i referenti delle istituzioni finanziarie a cui abbiamo proposto la soluzione in modo da raccogliere i loro feedback e completare l’analisi funzionale e strategica.

Purtroppo in questa fase di confronto con i Clienti è emerso che il prodotto non rispondeva a specifiche esigenze di business da parte loro, con conseguente mancanza di committment specifico nella realizzazione della soluzione.

Auriga ha quindi deciso di non procedere oltre con il progetto Prelievo PSD2, congelando le attività allo stato attuale.

Analisi

Anche questo tratta un progetto che purtroppo è fallito, ma con l’approccio Lean Startup l’investimento che si è fatto prima di rilevare il fallimento del progetto è stato pari a 23 gg-persona.