L'evoluzione delle piattaforme di core banking: come siamo arrivati a questo punto. Cosa ci aspetta?

Di: Niloy Sengupta

I sistemi di core banking non sono adatti a campagne pubblicitarie patinate.

Spesso descritti come tecnologie legacy, sono in realtà applicazioni mission-critical che elaborano transazioni quotidiane, aggiornamenti dei conti e altro ancora. Le banche attirano i clienti con promesse di convenienza e sicurezza finanziaria, ma sono i sistemi core a svolgere il lavoro pesante.

Questi sistemi core tendono anche a presentare ostacoli quando diventa forte la spinta alla modernizzazione.

Con il clamore che in questi giorni suscita la trasformazione nel settore bancario, è utile ricordare come i sistemi core siano diventati oggetto di discordia tra i vertici aziendali. Nell'articolo seguente è presentata una retrospettiva per capire in che modo il settore bancario potrà modernizzare efficacemente le proprie applicazioni più importanti. 

Nascita dei sistemi di core banking

I primi sistemi di core banking comparvero negli anni '80, facendo abbandonare alle banche la pratica secolare della scrittura manuale di registri e libri contabili.

Gli istituti bancari dovevano essere in grado di gestire grandi volumi di transazioni in modo rapido, affidabile ed efficiente. I sistemi di core banking di prima generazione¹ quindi si trasformarono, offrendo centralizzazione, velocità, scalabilità e affidabilità. Scritti nei linguaggi COBOL, Assembler, PL/I e JCL, questi sistemi erano monolitici, con un accoppiamento stretto dei moduli aziendali interdipendenti sottostanti quali clienti, transazioni e prodotti.

Queste applicazioni supportavano solo l'elaborazione batch e la registrazione avveniva alla fine della giornata. I saldi infragiornalieri potevano essere resi disponibili attraverso soluzioni alternative come la pubblicazione di promemoria. In tali applicazioni, la logica del business e quella di accesso ai dati erano fortemente intrecciate ² e separarle diventava difficile.

La seconda generazione di sistemi di core banking

A cavallo tra la fine degli anni '80 e l'inizio degli anni '90 i sistemi di core banking di seconda generazione ampliarono il mercato a banche regionali e realtà più piccole. I nuovi sistemi core introdussero architetture multilivello meno costose in grado di supportare l'elaborazione in tempo reale e che consentivano di separare la logica del business front-end da quella del livello intermedio e dalla logica di accesso ai dati.

Queste applicazioni erano tipicamente incentrate sul prodotto; i prodotti erano più facili da costruire e configurare e furono adottate diverse metodologie di integrazione. Poiché le applicazioni erano per natura più semplici e maggiormente basate su parametri, le banche potevano implementare nuovi prodotti, funzionalità e prezzi in un time-to-market più breve.³

L'ascesa di Internet negli anni '90 alimentò la crescita di sportelli front-office, filiali bancarie e applicazioni di banking online. Gli investimenti nelle applicazioni di core banking subirono un notevole rallentamento, mentre emergevano difficoltà di integrazione tra sistemi front-end e core.

Per superare tali vincoli, le banche cominciarono a creare o acquistare applicazioni middleware orientate ai servizi e basate su messaggi che consentivano un’integrazione più semplice e flessibile tra applicazioni front-end e back-end. Nel frattempo, framework di settore come IFX, FIX e FpML tentavano di fornire standardizzazione e interoperabilità tra istituzioni.

La terza generazione dei sistemi di core banking

Negli anni successivi al 2010 le banche hanno accelerato l'adozione del digital banking con tecnologie cloud. API REST e JSON sono diventate tecnologie popolari per l'interscambio e l'integrazione dei dati.

Di fronte al crescente numero di FinTech pronte a offrire soluzioni di nicchia e specifiche volte a migliorare l'esperienza del cliente, le banche hanno sentito l'urgenza di allearsi con loro e consentire l'integrazione. API e cloud sono diventate la forza propulsiva per ulteriori modifiche ai sistemi di core banking di prima e seconda generazione.

La personalizzazione dei core legacy da parte delle banche tradizionali è arrivata al punto che la pratica di mantenere il software nella sua versione più aggiornata non è più praticabile. Intuendo una nuova opportunità, i fornitori di piattaforme hanno iniziato a riprogettare le proprie soluzioni per il cloud attraverso una combinazione di nuovi modelli architettonici e il refactoring dalle piattaforme di core banking di seconda generazione.⁴

La maggior parte di queste app core di terza generazione sono realizzate come microservizi. Una volta "containerizzate", possono essere eseguite in uno o più ambienti cloud pubblici e sono progettate per offrire l'elaborazione delle transazioni in tempo reale. La loro architettura basata su microservizi separa le funzionalità aziendali quali gestione dei clienti e dei conti, elaborazione delle transazioni, estratti conto e rendicontazione.

Le API sono naturalmente il metodo di integrazione preferito per questi nuovi core e la maggior parte dei fornitori offre anche pacchetti applicativi proprietari di tipo gateway API che forniscono pre-integrazioni con applicazioni interne e alcune applicazioni di terze parti per supportare l'ampia gamma di servizi bancari quali onboarding di nuovi clienti, assistenza, trasferimenti di denaro, gestione delle carte e altri servizi accessori.⁵

Nuova generazione: sistemi di core banking componibili

Negli ultimi anni sono comparsi sul mercato diversi nuovi fornitori di applicativi core banking. Offrono applicazioni core di nuova generazione che presentano molte somiglianze progettuali con i core di terza generazione, ma con alcune differenze degne di nota. I core di nuova generazione sono realmente cloud-native e sono stati creati da zero utilizzando microservizi senza alcun refactoring del codice.⁶

Alcune di queste applicazioni utilizzano linguaggi di programmazione all'avanguardia come Golang e RUST e adottano database più recenti come ad esempio PostgreSQL. Inoltre, tali app sono offerte come set di API con architettura "headless" che consentono scelte di integrazione flessibili senza vincolare la banca a una gamma ristretta di fornitori. Tali modelli progettuali rendono "componibili" i core liberando la componente architetturale e offrendo alle banche la flessibilità di provarli parallelamente ai core esistenti senza dover migrare in modo totale.⁷

Alcuni fornitori offrono soluzioni di nicchia come motori di billing, prezzi e fatturazione e applicazioni di assistenza clienti appositamente create per il cloud. Anche senza sostituire un sistema di core banking nella sua interezza, tali applicazioni sono concepite per funzionare in collaborazione con altri core basati su cloud e possono diventare una parte essenziale dell’ecosistema core componibile.⁸

Questi recenti progressi nei sistemi di core banking consentono innovazioni rapide che permettono alle banche di sperimentare stack di applicazioni e modelli di migrazione più recenti.

Percorsi possibili verso un core moderno

I sistemi core di vecchia generazione erano progettati per gestire grandi volumi di transazioni in modo efficiente e molto affidabile. Sotto questo aspetto i sistemi di nuova generazione, per quanto agili e flessibili e pur offrendo numerosi vantaggi per il business, non hanno ancora raggiunto il livello delle loro meno recenti controparti. Questo è il motivo principale per cui è così difficile liberarsi dei core legacy. In passato la modernizzazione del core banking era un'iniziativa ad alto rischio e con costi elevati, in cui una sostituzione radicale era l'unica scelta possibile.

Oggi esistono molteplici percorsi verso la modernizzazione del core che ottimizzano rischi, costi e impegno. Le banche possono seguire un approccio di modernizzazione iterativo e a progressione costante. Alcuni percorsi d'esempio includono:

• Core cloud-native: si configurano i core cloud-native per linee di servizio più dirette come i canali digitali e si ridimensionano gradualmente queste applicazioni, spostando progressivamente altre linee di servizio dal core legacy.
• Approccio transitorio: variante del core cloud-native, in questo caso le banche possono prendere in considerazione lo spostamento nei nuovi core di linee di prodotto più semplici come libretti di risparmio e certificati di deposito, prima di spostare conti correnti o prestiti. In alternativa, è possibile spostare nel nuovo core alcuni segmenti di clientela in base all'area geografica o al comportamento di acquisto e ripetere successivamente l’operazione.
• Svuotamento del core legacy: si spostano dal core le funzionalità di business quali gestione dei prodotti e dei prezzi, gestione dei clienti, gestione degli estratti conto e dei documenti. Questo approccio riduce il core a un semplice registro delle transazioni, in modo che in sostituzione dei moduli svuotati sia possibile costruire o acquistare microservizi.
• Approccio ibrido: combina i vantaggi del mainframe e del cloud spostando il core locale basato su mainframe in un ambiente zCloud. Questa scelta può fungere da soluzione provvisoria o essere la soluzione finale. L'approccio offre alla banca una certa flessibilità nel processo decisionale riguardo all'abbandono del mainframe senza perdere i vantaggi del cloud.

Qualunque sia il percorso scelto, la modernizzazione del core banking non deve essere trattata come un esercizio qualsiasi di trasformazione tecnologica. I cambiamenti del modello operativo, in particolare la reingegnerizzazione dei processi di business e la gestione del cambiamento da parte del personale, devono accompagnare di pari passo i cambiamenti tecnologici.

L’evoluzione dei sistemi di core banking continua

L'evoluzione dei sistemi di core banking spiega perché e come questi sistemi sono stati progettati e costruiti per soddisfare le esigenze aziendali del passato. Poiché le esigenze del business evolvono, una comprensione della loro trasformazione ci fornisce una traiettoria e le linee guida utili a modificare questi sistemi. Imparando dagli errori del passato, possiamo identificare nuove opportunità per l'innovazione futura.

Niloy Sengupta è Financial Services Consulting Partner presso Kyndryl

¹Esempi di sistemi di core banking di prima generazione negli Stati Uniti: Systematics (FIS), Hogan (DXC) e Trisyn
²Esempio: l'uso dei dati di controllo di processo in Hogan
³Gli esempi sono molteplici: Profile (FIS), DNA e Premier (Fiserv), Silverlake, CoreDirector, CIF 20/20 (Jack Henry), Bancs (TCS), Finacle (Infosys), Flexcube (Oracle) e T24 (Temenos)
⁴Nessun refactoring di codice del passato. Ciò ha consentito una certa innovazione come l'uso di linguaggi di programmazione di nuova generazione quale GoLang in Finxact.
⁵FIS ha introdotto la Modern Banking Platform (MBP) e Temenos ha trasformato T24 in Transact. Fiserv, Jack Henry, Infosys, TCS, Oracle e Finastra hanno sviluppato versioni cloud delle loro popolari applicazioni core.
⁶Riguardo a tale integrazione sono riconoscibili due diversi percorsi. Da un lato, aziende come FIS, Fiserv e Oracle preintegrano le app dal loro portfolio di prodotti, cercando di vincolare il più possibile i clienti ai propri ecosistemi. Dall'altro, TCS, Infosys, Temenos e altri offrono un approccio di marketplace in cui diverse app di terze parti sono certificate per l'operatività con i loro core tramite API.
⁷Anche questi fornitori di core dispongono di un vasto marketplace con app di terze parti certificate per l'interoperabilità e conformi a framework bancari aperti quali ISO 20022 e BIAN.
⁸Alcune di queste applicazioni sono motori per prodotto, prezzi e fatturazione offerti da Zafin, SunTec o Oracle RMB. Fanno parte di questa categoria anche le applicazioni di assistenza clienti e di onboarding come Savana.