Questo documento della Google Cloud prospettiva dei servizi finanziari (SF) del Well-Architected Framework fornisce una panoramica dei principi e dei consigli per ottimizzare il rendimento dei carichi di lavoro SF in Google Cloud. I consigli contenuti in questo documento sono in linea con il pilastro dell'ottimizzazione del rendimento del Well-Architected Framework.
L'ottimizzazione del rendimento ha una lunga storia nei servizi finanziari. Ha aiutato le organizzazioni SF a superare le sfide tecniche ed è stato quasi sempre un fattore abilitante o un acceleratore per la creazione di nuovi modelli di business. Ad esempio, gli sportelli automatici (introdotti nel 1967) hanno automatizzato la procedura di erogazione di contanti e hanno aiutato le banche a ridurre il costo della loro attività principale. Tecniche come l'aggiramento del kernel del sistema operativo e l'assegnazione dei thread delle applicazioni ai core di calcolo hanno contribuito a ottenere un comportamento deterministico e una bassa latenza per le applicazioni di trading. La riduzione della latenza ha facilitato una liquidità più elevata e stabile con spread più stretti nei mercati finanziari.
Il cloud crea nuove opportunità per l'ottimizzazione del rendimento. Inoltre, mette in discussione alcuni dei pattern di ottimizzazione storicamente accettati. Nello specifico, i seguenti compromessi sono più trasparenti e controllabili nel cloud:
- Time to market rispetto al costo.
- Rendimento end-to-end a livello di sistema rispetto al rendimento a livello di nodo.
- Disponibilità di talenti rispetto all'agilità del processo decisionale relativo alla tecnologia.
Ad esempio, l'adattamento dell'hardware e delle risorse IT a requisiti di competenze specifici è un'attività banale nel cloud. Per supportare la programmazione GPU, puoi creare VM basate su GPU. Puoi scalare la capacità nel cloud per soddisfare i picchi di domanda senza eseguire il provisioning eccessivo delle risorse. Questa funzionalità ti aiuta a garantire che i tuoi carichi di lavoro possano gestire i carichi di punta, ad esempio nei giorni di busta paga non agricola e quando i volumi di trading sono significativamente superiori ai livelli storici. Anziché spendere per scrivere codice altamente ottimizzato a livello di singoli server (ad esempio codice altamente ottimizzato in linguaggio C) o scrivere codice per ambienti di computing ad alte prestazioni (HPC) convenzionali, puoi fare lo scale out in modo ottimale utilizzando un sistema distribuito basato su Kubernetes ben progettato.
I consigli per l'ottimizzazione del rendimento contenuti in questo documento sono mappati ai seguenti principi fondamentali:
- Allinea le metriche di rendimento della tecnologia agli indicatori chiave di business
- Dai la priorità alla sicurezza senza sacrificare il rendimento per rischi non comprovati
- Ripensa l'architettura per adattarla a nuove opportunità e requisiti
- Prepara la tua tecnologia per il futuro in modo da soddisfare le esigenze di business presenti e future
Allinea le metriche di rendimento della tecnologia agli indicatori chiave di business
Puoi mappare l'ottimizzazione del rendimento ai risultati di valore di business in diversi modi. Ad esempio, in un ufficio di ricerca buy-side, uno scopo commerciale potrebbe essere quello di ottimizzare l'output per ora di ricerca o di dare la priorità agli esperimenti dei team che hanno una comprovata esperienza, ad esempio con rapporti di Sharpe più elevati. Sul lato sell-side, puoi utilizzare l'analisi per monitorare l'interesse dei clienti e, di conseguenza, dare la priorità al throughput dei modelli di AI che supportano la ricerca più interessante.
È anche importante collegare gli obiettivi di rendimento agli indicatori chiave di prestazione (KPI) di business per finanziare i miglioramenti del rendimento. Le iniziative di innovazione e trasformazione aziendale (a volte chiamate change-the-bank) hanno budget diversi e potenzialmente diversi gradi di accesso alle risorse rispetto alle operazioni di business-as-usual (BAU) o run-the-bank. Ad esempio, Google Cloud ha aiutato i team di gestione del rischio e di tecnologia di un G-SIFI a collaborare con gli analisti quantitativi del front-office su una soluzione per eseguire i calcoli di analisi del rischio (ad esempio XVA) in pochi minuti anziché in ore o giorni. Questa soluzione ha aiutato l'organizzazione a soddisfare i requisiti di conformità pertinenti. Inoltre, ha consentito ai trader di avere conversazioni di qualità superiore con i propri clienti, offrendo potenzialmente spread più stretti, liquidità più stabile e hedging più conveniente.
Quando allinei le metriche di rendimento agli indicatori di business, tieni presente i seguenti consigli:
- Collega ogni iniziativa tecnologica agli obiettivi di business e ai risultati chiave (OKR), pertinenti, ad esempio aumentando le entrate o i profitti, riducendo i costi e mitigando il rischio in modo più efficiente o olistico.
- Concentrati sull'ottimizzazione del rendimento a livello di sistema. Vai oltre la separazione convenzionale tra change-the-bank e run-the-bank e i silos front-office e back-office.
Dai la priorità alla sicurezza senza sacrificare il rendimento per rischi non comprovati
La sicurezza e la conformità legale nelle organizzazioni SF devono essere inequivocabilmente di un livello elevato. Mantenere un livello elevato è essenziale per evitare di perdere clienti e prevenire danni irreparabili al brand di un'organizzazione. Spesso, il valore più elevato si ottiene grazie a innovazioni tecnologiche come l'AI generativa e servizi gestiti unici come Spanner. Non scartare automaticamente queste opzioni tecnologiche a causa di un'idea sbagliata generale sul rischio operativo proibitivo o su una postura di conformità normativa inadeguata.
Google Cloud ha lavorato a stretto contatto con i G-SIFI per assicurarsi che un approccio basato sull'AI per l'antiriciclaggio (AML) possa essere utilizzato nelle giurisdizioni in cui gli istituti servono i clienti. Ad esempio, HSBC ha migliorato significativamente il rendimento della sua unità di criminalità finanziaria (Fincrime) con i seguenti risultati:
- Attività sospette confermate quasi due o quattro volte in più.
- Costi operativi inferiori grazie all'eliminazione di oltre il 60% di falsi positivi e al tempo di indagine concentrato solo su avvisi strategici ad alto rischio.
- Output verificabili e spiegabili per supportare la conformità legale.
Tieni presente i seguenti consigli:
- Verifica che i prodotti che intendi utilizzare possano aiutarti a soddisfare i requisiti di sicurezza, resilienza e conformità per le giurisdizioni in cui operi. Per raggiungere questo obiettivo, collabora con Google Cloud i team degli account, i team di rischio e i team di prodotto.
- Crea modelli più potenti e fornisci trasparenza ai clienti sfruttando la spiegabilità dell'AI (ad esempio, l'attribuzione del valore di Shapley). Tecniche come l'attribuzione del valore di Shapley possono attribuire le decisioni del modello a funzionalità specifiche a livello di input.
Ottieni la trasparenza per i carichi di lavoro di AI generativa utilizzando tecniche come le citazioni delle fonti, il grounding, e RAG.
Quando la spiegabilità non è sufficiente, separa i passaggi decisionali nei flussi di valore e utilizza l'AI per automatizzare solo i passaggi non decisionali. In alcuni casi, l'AI spiegabile potrebbe non essere sufficiente o una procedura potrebbe richiedere l'intervento umano a causa di problemi normativi (ad esempio, GDPR, articolo 22). In questi casi, presenta tutte le informazioni di cui l'agente umano ha bisogno per prendere decisioni in un unico riquadro di controllo, ma automatizza le attività di raccolta, acquisizione, manipolazione e riepilogo dei dati.
Ripensa l'architettura per adattarla a nuove opportunità e requisiti
L'aumento delle architetture attuali con funzionalità basate sul cloud può fornire un valore significativo. Per ottenere risultati più trasformativi, devi ripensare periodicamente la tua architettura utilizzando un approccio cloud-first.
Tieni presente i seguenti consigli per ripensare periodicamente l'architettura dei tuoi carichi di lavoro al fine di ottimizzare ulteriormente il rendimento.
Utilizza alternative basate sul cloud ai sistemi e agli scheduler HPC on-premise
Per sfruttare una maggiore elasticità, una postura di sicurezza migliorata e funzionalità di monitoraggio e governance estese, puoi eseguire carichi di lavoro HPC nel cloud o eseguire il bursting dei carichi di lavoro on-premise nel cloud. Tuttavia, per alcuni casi d'uso di modellazione numerica, come la simulazione di strategie di investimento o la modellazione XVA, la combinazione di Kubernetes con Kueue potrebbe offrire una soluzione più potente.
Passa alla programmazione basata su grafici per le simulazioni
Le simulazioni Monte Carlo potrebbero essere molto più efficienti in un sistema di esecuzione basato su grafici come Dataflow. Ad esempio, HSBC utilizza Dataflow per eseguire i calcoli del rischio 16 volte più velocemente rispetto al suo approccio precedente.
Esegui piattaforme di scambio e trading basate sul cloud
Le conversazioni con i Google Cloud clienti rivelano che il principio di Pareto 80/20 si applica ai requisiti di rendimento dei mercati e delle applicazioni di trading.
- Più dell'80% delle applicazioni di trading non ha bisogno di una latenza estremamente bassa. Tuttavia, ottengono vantaggi significativi dalle funzionalità di resilienza, sicurezza ed elasticità del cloud. Ad esempio, BidFX, una piattaforma multi-dealer di cambio valuta, utilizza il cloud per lanciare rapidamente nuovi prodotti e aumentare significativamente la disponibilità e l'impronta senza aumentare le risorse.
- Le applicazioni rimanenti (meno del 20%) richiedono una bassa latenza (meno di un millisecondo), un comportamento deterministico e l'equità nella distribuzione dei messaggi. In genere, questi sistemi vengono eseguiti in strutture di colocation rigide e costose. Sempre più spesso, anche questa categoria di applicazioni viene ripiattaformata sul cloud, sia all' edge che come applicazioni cloud-first.
Prepara la tua tecnologia per il futuro in modo da soddisfare le esigenze di business presenti e future
Storicamente, molte organizzazioni SF hanno creato tecnologie proprietarie per ottenere un vantaggio competitivo. Ad esempio, all'inizio degli anni 2000, le banche di investimento e le società di trading di successo avevano le proprie implementazioni di tecnologie fondamentali come i sistemi pub-sub e i message broker. Con l'evoluzione delle tecnologie open source e del cloud, queste tecnologie sono diventate commodity e non offrono un valore di business incrementale.
Tieni presente i seguenti consigli per preparare la tua tecnologia per il futuro.
Adotta un approccio DaaS (Data-as-a-Service) per un time to market più rapido e la trasparenza dei costi
Le organizzazioni SF spesso si evolvono attraverso una combinazione di crescita organica e fusioni e acquisizioni (M&A). Di conseguenza, le organizzazioni devono integrare tecnologie disparate. Devono anche gestire risorse duplicate, come fornitori di dati, licenze di dati e punti di integrazione. Google Cloud offre opportunità per creare valore differenziato nelle integrazioni post-fusione.
Ad esempio, puoi utilizzare servizi come BigQuery sharing per creare una piattaforma DaaS (Data-as-a-Service) pronta per l'analisi. La piattaforma può fornire sia dati di mercato sia input da fonti alternative. Questo approccio elimina la necessità di creare pipeline di dati ridondanti e ti consente di concentrarti su iniziative di maggior valore. Inoltre, le società fuse o acquisite possono razionalizzare rapidamente ed efficientemente le esigenze di licenza dei dati e di infrastruttura post-fusione. Anziché impegnarsi ad adattare e unire le proprietà e le operazioni di dati legacy, l'attività combinata può concentrarsi su nuove opportunità di business.
Crea un livello di astrazione per isolare i sistemi esistenti e affrontare i modelli di business emergenti
Sempre più spesso, il vantaggio competitivo per le banche non è il sistema bancario principale, ma il livello di customer experience. Tuttavia, i sistemi bancari legacy spesso utilizzano applicazioni monolitiche sviluppate in linguaggi come Cobol e integrate in tutta la catena del valore bancario. Questa integrazione ha reso difficile separare i livelli della catena del valore, quindi è stato quasi impossibile eseguire l'upgrade e modernizzare questi sistemi.
Una soluzione per affrontare questa sfida è utilizzare un livello di isolamento come un sistema di gestione delle API o un livello di staging come Spanner che duplica il libro dei record e facilita la modernizzazione dei servizi con analisi avanzate e AI. Ad esempio, Deutsche Bank ha utilizzato Spanner per isolare la sua proprietà bancaria principale legacy e iniziare il suo percorso di innovazione.