top of page
Buscar

Modernização do Core Banking nativo da nuvem com Apache Kafka

  • pedrobusko
  • 20 de jan. de 2023
  • 10 min de leitura

Este Ʃ um artigo traduzido originalmente publicado dia 16/03/2022 no blog do Kai Waehner: "Cloud-native Core Banking Modernization with Apache Kafka". Assine a newsletter do Kai para se manter atualizado com novas publicaƧƵes.


A maioria das instituiƧƵes de serviƧos financeiros opera sua plataforma de core banking em tecnologias legadas de mainframe. A arquitetura monolĆ­tica, proprietĆ”ria e inflexĆ­vel cria muitos desafios para inovação e economia. Este blog post explora trĆŖs soluƧƵes bancĆ”rias abertas, elĆ”sticas e escalĆ”veis ​​desenvolvidas pelo Apache Kafka para resolver esses problemas.

A maioria das instituições de serviços financeiros opera sua plataforma de core banking em tecnologias legadas de mainframe . A arquitetura monolítica, proprietÔria e inflexível cria muitos desafios para inovação e economia. Este blog post explora uma solução aberta, elÔstica e escalÔvel desenvolvida pelo Apache Kafka para resolver esses problemas. Três soluções bancÔrias do mundo real nativas da nuvem mostram como as cargas de trabalho transacionais e analíticas podem ser criadas em qualquer escala em tempo real para processos de negócios tradicionais, como pagamentos ou relatórios regulatórios, e novos aplicativos inovadores, como negociação de criptomoedas.


O que Ć© core banking?


Core banking é um serviço bancÔrio prestado por agências bancÔrias em rede. Os clientes podem acessar suas contas bancÔrias e realizar transações bÔsicas de filiais membros ou aplicativos de software conectados, como aplicativos móveis. O core banking é frequentemente associado ao banco de varejo, e muitos bancos tratam os clientes de varejo como seus clientes de core banking. O banco de atacado é um negócio realizado entre bancos. A negociação de valores mobiliÔrios envolve a compra e venda de ações, ações e assim por diante.

As empresas geralmente são gerenciadas por meio da divisão de banco corporativo da instituição. O core banking cobre o depósito bÔsico e o empréstimo de dinheiro. As funções bancÔrias bÔsicas padrão incluem contas de transações, empréstimos, hipotecas e pagamentos.

Processos de negócios tĆ­picos do sistema operacional bancĆ”rio incluem KYC (ā€œKnow Your Customerā€), abertura de produtos, pontuação de crĆ©dito, fraude, reembolsos, cobranƧas, etc.

Os bancos disponibilizam esses serviços em vÔrios canais, como caixas eletrÓnicos, serviços bancÔrios pela Internet, serviços bancÔrios móveis e agências. O software bancÔrio e a tecnologia de rede permitem que um banco centralize sua manutenção de registros e permita o acesso de qualquer local.

AnÔlise automÔtica para relatórios regulatórios, configuração flexível para ajustar fluxos de trabalho e inovar e uma API aberta para integração com ecossistemas de terceiros são cruciais para plataformas bancÔrias modernas.


Cargas de trabalho transacionais x analĆ­ticas no core banking


Cargas de trabalho para anÔlises e transações têm características e requisitos muito diferentes. Os casos de uso diferem significativamente. A maioria dos fluxos de trabalho de core banking são transacionais.

Os SLAs são muito diferentes e são cruciais para entender para garantir o comportamento adequado em caso de problemas de infraestrutura e para recuperação de desastres:

  • RPO (Recovery Point Objective) : a perda de dados real que vocĆŖ pode viver no caso de um desastre

  • RTO (Recovery Time Objective) : o perĆ­odo de recuperação real (ou seja, tempo de inatividade) que vocĆŖ pode viver no caso de um desastre



Embora o tempo de inatividade ou a perda de dados nĆ£o sejam bons em casos de uso analĆ­tico, eles geralmente sĆ£o aceitĆ”veis ​​quando o custo e o risco sĆ£o comparados para garantir um RTO e RPO próximos de zero. Portanto, se a função de relatório para usuĆ”rios finais ficar inativa por uma hora ou, pior ainda, se alguns relatórios forem perdidos, a vida continua.

Em cargas de trabalho transacionais dentro de uma plataforma de core banking, RTO e RPO precisam ser o mais próximo possível de zero, mesmo no caso de um desastre (por exemplo, se um datacenter completo ou região de nuvem estiver inoperante). Se a plataforma de core banking perder transações de pagamento ou outros eventos necessÔrios para o processamento de conformidade, o banco estarÔ em apuros.


Plataformas de core banking legadas


Os avanços na Internet e na tecnologia da informação reduziram o trabalho manual nos bancos e aumentaram a eficiência . O software de computador foi desenvolvido décadas atrÔs para realizar operações bancÔrias essenciais, como registro de transações, manutenção de cadernetas, cÔlculos de juros sobre empréstimos e depósitos, registros de clientes, balanço de pagamentos e saques.


Software bancÔrio em execução em um mainframe


A maioria das plataformas de core banking de empresas de serviços financeiros tradicionais ainda rodam em mainframes . As mÔquinas, sistemas operacionais e aplicativos ainda fazem um ótimo trabalho. SLAs como RPO e RTO não são novos. Se você observar os produtos e documentos de mainframe da IBM, verÔ que os principais conceitos são semelhantes às tecnologias nativas de nuvem de ponta. Tempo de inatividade, perda de dados e requisitos semelhantes precisam ser definidos.

A arquitetura de solução forneceu as garantias necessÔrias. O código IBM DB2, IMS, CICS e Cobol ainda opera cargas de trabalho transacionais muito estÔveis . Um mainframe IBM z15 moderno, anunciado em 2019, oferece até 40 TB de RAM e 190 núcleos. Isso é muito impressionante.


Aplicativos de mainframe monolƭticos, proprietƔrios e inflexƭveis


Então, qual é o problema com plataformas legadas de core banking rodando em um mainframe ou outra infraestrutura semelhante?

  • MonolĆ­tico : os aplicativos legados de mainframe sĆ£o aplicativos monolĆ­ticos extremos. Isso nĆ£o Ć© comparĆ”vel a um aplicativo da Web monolĆ­tico dos anos 2000 em execução no IBM WebSphere ou em outro J2EE. / Servidor de aplicativos Java EE. Ɖ muito pior.

  • ProprietĆ”rio : IMS, CICS, MQ, DB2 e outros. sĆ£o tecnologias muito maduras. No entanto, os tomadores de decisĆ£o da próxima geração, arquitetos de nuvem e desenvolvedores esperam APIs abertas, infraestrutura bĆ”sica de código aberto, as melhores soluƧƵes e SaaS com liberdade de escolha independente para cada problema.

  • InflexĆ­vel : a maioria dos aplicativos legados de core banking fazem seu trabalho por dĆ©cadas. O código Cobol Ć© executado. No entanto, nĆ£o Ć© compreendido ou documentado. Os desenvolvedores Cobol tambĆ©m sĆ£o escassos. A Ćŗnica opção Ć© estender os aplicativos existentes. AlĆ©m disso, a infraestrutura nĆ£o Ć© elĆ”stica para aumentar e diminuir de maneira definida por software. Em vez disso, as empresas precisam comprar hardware por milhƵes de dólares (e ainda pagar uma fortuna adicional pelas transaƧƵes).

Sim, o mainframe suporta tecnologias atualizadas como DB2, MQ, WebSphere, Java, Linux, Web Services, Kubernetes, Ansible, Blockchain! No entanto, isso não resolve os problemas existentes . Isso só ajuda quando você cria novos aplicativos. No entanto, novos aplicativos geralmente são feitos com infraestrutura e estruturas modernas nativas da nuvem, em vez de depender de conceitos legados.


Otimização e redução de custos de aplicativos de mainframe existentes


As seƧƵes acima analisaram a arquitetura corporativa com RPO/RTO em mente para garantir tempo de atividade e sem perda de dados. Isso Ć© crucial para os tomadores de decisĆ£o responsĆ”veis ​​pelo risco e receita da unidade de negócios.

No entanto, o terceiro aspecto além da receita e do risco é o custo . Além de fornecer uma infraestrutura elÔstica e flexível para a plataforma de core banking de próxima geração, as empresas também se afastam de soluções legadas por motivos de custo.

As empresas economizam milhões de dólares apenas transferindo dados de um mainframe para o streaming de eventos moderno:



Por exemplo, o streaming de dados permite que o Royal Bank of Canada (RBC) economize milhões de dólares transferindo dados do mainframe para o Kafka. Aqui estÔ uma citação do RBC:

ā€œ … resgatar dados fora do mainframe, de maneira nativa da nuvem, baseada em microsserviƧos… [para] … reduzir significativamente as leituras no mainframe, economizando custos de infraestrutura fixa RBC (OPEX). O RBC manteve a conformidade com os regulamentos bancĆ”rios e a lógica de negócios e agora pode criar novos aplicativos usando a mesma arquitetura baseada em eventos. ā€

Leia minha postagem de blog dedicada se quiser saber mais sobre descarregamento, integração e migração de mainframe para o Apache Kafka .


Plataformas de core banking modernas e nativas da nuvem


Este post não é apenas sobre descarregamento e integração. Em vez disso, analisamos exemplos do mundo real em que o core banking nativo da nuvem substituiu os mainframes legados existentes ou permitiu que novas empresas FinTech começassem do zero em um ambiente de nuvem em tempo real de ponta para competir com os concorrentes tradicionais do FinServ.


Requisitos para uma plataforma bancƔria moderna?


Aqui estão os requisitos que coloco regularmente na lista de desejos de executivos e arquitetos líderes de empresas de serviços financeiros para novas infraestruturas e aplicativos bancÔrios :

  • Processamento de dados em tempo real

  • Infraestrutura escalĆ”vel

  • Alta disponibilidade

  • Verdadeiro desacoplamento e manuseio de contrapressĆ£o

  • Modelo de custo econĆ“mico

  • Arquitetura flexĆ­vel para desenvolvimento Ć”gil

  • Escalabilidade elĆ”stica

  • Interfaces baseadas em padrƵes e APIs abertas

  • FunƧƵes extensĆ­veis e separação de interesses orientada por domĆ­nio

  • Autenticação segura, autorização, criptografia e registro de auditoria

  • ImplantaƧƵes independentes de infraestrutura em ambientes de borda, hĆ­bridos e multirregionais/multinuvem

O que são infraestrutura e aplicativos nativos da nuvem?


E aqui estão os recursos de uma infraestrutura genuinamente nativa da nuvem para criar um sistema bancÔrio central de última geração:

  • Processamento de dados em tempo real

  • Infraestrutura escalĆ”vel

  • Alta disponibilidade

  • Verdadeiro desacoplamento e manuseio de contrapressĆ£o

  • Modelo de custo econĆ“mico

  • Arquitetura flexĆ­vel para desenvolvimento Ć”gil

  • Escalabilidade elĆ”stica

  • Interfaces baseadas em padrƵes e APIs abertas

  • FunƧƵes extensĆ­veis e separação de interesses orientada por domĆ­nio

  • Autenticação segura, autorização, criptografia e registro de auditoria

  • ImplantaƧƵes independentes de infraestrutura em ambientes de borda, hĆ­bridos e multirregionais/multinuvem

Acho que você entendeu o que quero dizer aqui: adotar uma infraestrutura nativa da nuvem é fundamental para o sucesso na criação de software bancÔrio de última geração . Não importa se você

  • estĆ£o no local ou na nuvem

  • Ć© um jogador tradicional ou uma startup

  • concentre-se em um paĆ­s ou idioma especĆ­fico ou opere em regiƵes ou mesmo globalmente

Apache Kafka = infraestrutura nativa da nuvem para cargas de trabalho transacionais em tempo real


Muitas pessoas pensam que o Apache Kafka não foi criado para transações e deve ser usado apenas para anÔlise de big data. Esta postagem de blog explora quando e como usar o Kafka em arquiteturas resilientes de missão crítica e quando usar a API de transação integrada.

O Kafka Ć© um sistema distribuĆ­do e tolerante a falhas que Ć© resiliente por natureza (se vocĆŖ o implantar e operar corretamente). Nenhum tempo de inatividade e nenhuma perda de dados podem ser garantidos, como em seu banco de dados favorito, mainframe ou outras plataformas principais.

A escalabilidade elÔstica e as atualizações contínuas permitem uma infraestrutura de fluxo de dados flexível e confiÔvel para cargas de trabalho transacionais para garantir a continuidade dos negócios . O arquiteto pode até estender um cluster entre regiões com ferramentas como Confluent Multi-Region Clusters . Essa configuração garante zero perda de dados e zero tempo de inatividade , mesmo no caso de um desastre em que um datacenter esteja totalmente inoperante.

O post ā€œ Global Kafka Deployments ā€ explora as diferentes opƧƵes de implantação e suas compensaƧƵes com mais detalhes. Confira minha postagem no blog sobre cargas de trabalho transacionais versus analĆ­ticas com Apache Kafka para obter mais informaƧƵes .


Apache Kafka em serviƧos bancƔrios e financeiros


A ascensão do streaming de eventos em serviços financeiros estÔ crescendo loucamente. A integração e o processamento contínuos de dados em tempo real são obrigatórios para muitos casos de uso. Muitos departamentos de negócios no setor de serviços financeiros implantam o Apache Kafka para cargas de trabalho transacionais de missão crítica e anÔlise de big data, incluindo core banking . Alta escalabilidade, alta confiabilidade e uma infraestrutura aberta elÔstica são as razões críticas para o sucesso do Kafka.

Para saber mais sobre diferentes casos de uso, arquiteturas e exemplos do mundo real no setor de FinServ, confira o post ā€œ Apache Kafka na indĆŗstria de serviƧos financeiros ā€œ. Os casos de uso incluem

  • GestĆ£o de fortunas e mercado de capitais

  • Risco de mercado e crĆ©dito

  • CĆ­ber seguranƧa

  • Modernização de TI

  • Banco de varejo e corporativo

  • ExperiĆŖncia do cliente

SoluƧƵes modernas de core banking nativas da nuvem com tecnologia Kafka


Agora, vamos explorar o exemplo específico de soluções de core banking nativas da nuvem construídas com o Apache Kafka . As subseções a seguir mostram três exemplos do mundo real .


Thought Machine – Correção e escala em uma Ćŗnica plataforma


O Thought Machine é um sistema operacional de core banking inovador e flexível. Os principais recursos da solução da Thought Machine incluem

  • Software de core banking nativo da nuvem

  • Cargas de trabalho transacionais (24/7, perda zero de dados)

  • Mecanismo de produto flexĆ­vel alimentado por contratos inteligentes (nĆ£o blockchain)

O sistema operacional de core banking nativo da nuvem permite que um banco alcance uma ampla escala de personalização sem precisar alterar nada na plataforma subjacente . Isso Ć© altamente vantajoso e parte crucial de como sua arquitetura Ć© um contrapeso ao ā€œespagueteā€ que surge em outros sistemas quando a customização e a funcionalidade da plataforma nĆ£o estĆ£o separadas.



A palestra do Kafka Summit da Thought Machine de 2021 explora como o sistema bancÔrio principal da Thought Machine, 'Vault', foi construído em uma nuvem primeiro com o Apache Kafka em seu coração. Ele aproveita o streaming de eventos para permitir o processamento assíncrono e paralelo em escala , focando especificamente nos padrões de arquitetura para garantir a 'correção' em tal ambiente.


10x Banking – Canalize transaƧƵes agnósticas em tempo real


O 10X Banking fornece uma plataforma de core banking nativa da nuvem . Em sua palestra no Kafka Summit , eles falaram sobre a história do core banking e como eles aproveitam o Apache Kafka em conjunto com outras tecnologias de código aberto em sua plataforma comercial .



A abordagem 10x nativa da nuvem fornece ciclos de vida de produtos flexíveis . O tempo de colocação no mercado é um benefício importante . As organizações não precisam começar do zero. Um modelo de dados e ferramentas unificados permitiram focar nos problemas de negócios.

A plataforma 10x é uma plataforma SaaS segura, confiÔvel, escalÔvel e em conformidade com as regulamentações que minimiza a carga e os custos regulamentares. Ele é construído em um design orientado por domínio com desacoplamento real entre cargas de trabalho transacionais e anÔlises/relatórios.

Kafka é um hub de dados dentro da plataforma abrangente para anÔlises, transações e segurança cibernética em tempo real. O Apache Kafka não é a bala de prata para todos os problemas . Portanto, a 10x escolheu uma abordagem de ponta para combinar diferentes estruturas de código aberto, produtos comerciais e ofertas de SaaS para criar a estrutura bancÔria nativa da nuvem.

Veja como o 10X Banking construiu uma plataforma de core banking nativa da nuvem para permitir anÔlises em tempo real e em lote com um único pipeline de streaming de dados aproveitando a arquitetura Kappa :



Os principais componentes incluem Apache Kafka para streaming de dados, alƩm de Apache Pinot e Trino para anƔlise .


Custodigit – investimentos criptogrĆ”ficos seguros com streaming e orquestração de dados com estado


Custodigit Ʃ uma plataforma bancƔria moderna para ativos digitais e criptomoedas . Ele fornece recursos e garantias cruciais para investimentos criptogrƔficos seriamente regulamentados:

  • Armazenamento seguro de carteiras

  • Enviando e recebendo no blockchain

  • Negociação atravĆ©s de corretoras e bolsas

  • Ambiente regulamentado (um aspecto fundamental e nenhuma surpresa, pois este produto vem da SuƭƧa - um mercado muito regulamentado)

Kafka Ć© o sistema nervoso do banco central da arquitetura de microsserviƧos da Custodigit . Os aplicativos Stateful Kafka Streams fornecem orquestração de fluxo de trabalho com o padrĆ£o de design ā€œ distribuĆ­do sagaā€ para a coreografia entre microsserviƧos . Kafka Streams foi selecionado por causa de:

  • microsserviƧos enxutos e desacoplados

  • gerenciamento de metadados no Kafka

  • estrutura de dados unificada em microsserviƧos

  • API de transação (tambĆ©m conhecida como semĆ¢ntica exatamente uma vez)

  • escalabilidade e confiabilidade

  • processamento em tempo real em escala

  • uma linguagem especĆ­fica de domĆ­nio de nĆ­vel superior para processamento de fluxo

  • processos com estado de execução longa

Cobri Custodigit e outras plataformas blockchain/cripto em uma postagem de blog separada: Apache Kafka como Data Hub for Crypto, DeFi, NFT, Metaverse – Beyond the Buzz .


Core banking nativo em nuvem fornece escala elƔstica para cargas de trabalho transacionais


O software de core banking moderno precisa ser elÔstico, escalÔvel e em tempo real . Isso é verdade para cargas de trabalho transacionais como KYC ou pontuação de crédito e cargas de trabalho analíticas, como relatórios regulatórios. O Apache Kafka permite o processamento de cargas de trabalho transacionais e analíticas em muitas soluções bancÔrias modernas.

Thought Machine, 10X Banking e Custodigit são três exemplos nativos de nuvem desenvolvidos pelo ecossistema Apache Kafka para habilitar a próxima geração de software bancÔrio em tempo real. O Open Banking é obtido com APIs abertas para integração com outros serviços de terceiros.

A integração, descarregamento e substituição posterior de tecnologias legadas, como mainframe, por tecnologias modernas de streaming de dados comprovam o valor comercial em muitas organizações. Kafka não é uma bala de prata, mas o hub de dados central e de missão crítica para integração e processamento de dados em tempo real.


Como vocĆŖ aproveita o streaming de dados para cargas de trabalho analĆ­ticas ou transacionais? Conecte comigo e com o Kai no LinkedIn e vamos discutir isso! Mantenha-se informado sobre as novas postagens do blog assinando a newsletter.

Ā 
Ā 
Ā 

Pedro Busko's blog

©2022 by Pedro Busko's blog. Proudly created with Wix.com

bottom of page