#123: Core Banking em um mundo open: qual é o futuro do sistema operacional bancário?
W FINTECHS NEWSLETTER #123
👀 English Version 👉 here
👉A W Fintechs é uma newsletter focada em inovação financeira. Toda segunda-feira, às 8:21 a.m. (horário de Brasília), você receberá uma análise profunda no seu e-mail.
Esta edição é patrocinada pelo
O Iniciador é a plataforma completa de infraestrutura especializada em Open Finance Regulado que resolve a Iniciação de Pagamentos e o acesso a Dados.
A solução elimina as preocupações com tecnologia e conformidade, permitindo que os clientes, com licença regulatória ou utilizando a do Iniciador, se concentrem em novos produtos e no crescimento de seus negócios.
💡Traga sua empresa para a W Fintechs Newsletter
Alcance um público nichado de fundadores, investidores e reguladores que leem toda segunda-feira uma análise profunda do mercado de inovação financeira. Clique 👉aqui
As tecnologias estão cada vez mais abertas, e o core banking segue o mesmo caminho. Alguns players tornaram esses sistemas mais modulares, acessíveis e escaláveis, aumentando a flexibilidade na oferta de produtos bancários. O que antes era rígido e difícil de adaptar agora se transforma em um ecossistema colaborativo, que se adapta com mais facilidade às necessidades do mercado.
O core banking é o sistema operacional do setor financeiro. De fintechs a grandes bancos, todas as operações diárias passam por ele: crédito e débito em contas, relatórios regulatórios, integrações com outros sistemas.
Nos últimos anos, novos players desafiaram os já estabelecidos. Em 2024, o mercado cresceu de US$ 12,45 bi para US$ 13,63 bi, refletindo um CAGR de 9,5% 1. O setor está mais competitivo, e a flexibilidade deixou de ser um diferencial para se tornar uma condição de sobrevivência para os bancos e fintechs.
As mudanças no mercado reduziram as receitas das instituições, tornando inviável cobrar por transação ou adotar modelos recorrentes. Ao mesmo tempo, custos como tarifas por contas ativas e inativas e taxas por transação cobradas por fornecedores de tecnologia permaneceram. Players de core banking sem flexibilidade começaram a perder espaço para plataformas mais adaptáveis a esse novo cenário.
Algumas fintechs que operam com Banking as a Service (BaaS), também se veem em um ponto de inflexão: migrar para uma licença própria para ganhar mais controle sobre suas operações. O grande dilema para muitas dessas empresas está em "construir ou comprar". Em alguns casos, tanto bancos quanto fintechs decidiram desenvolver seus sistemas de core banking internamente, buscando a flexibilidade necessária para se manter competitivos. Foi o caso do Nubank 2 e do Revolut 3, que construíram suas próprias plataformas e processadores bancários do zero. A Stark Bank seguiu a mesma estratégia e, posteriormente, comercializou sua solução, transformando-a em uma nova fonte de receita.
Esse movimento abriu espaço para uma nova geração de empresas que unem open source e plataformas modulares para oferecer mais inovação e customização. A francesa Formance, por exemplo, captou mais de US$ 21 milhões em janeiro de 2025 para continuar desenvolvendo sua tecnologia open source para o sistema bancário. Seguindo uma trajetória semelhante, a brasileira Lerian arrecadou um pouco mais de US$ 3 milhões para também construir a próxima stack open source para serviços financeiros. A promessa de sistemas mais adaptáveis, abertos e colaborativos é atraente, mas a verdadeira questão é como construir uma comunidade que não só compre a ideia, mas também invista e se envolva com essa tecnologia. Esse é um dos assuntos da edição de hoje.
A primeira geração de core banking
Uma boa maneira de entender a história do core banking e para onde ele está indo é olhando para a evolução dos sistemas operacionais que fazem seu computador funcionar e permitem que você leia este texto.
A história dos sistemas operacionais é um reflexo das disputas e colaborações que definiram o rumo da tecnologia que vemos hoje. Nos anos de 1980, a IBM, com pressa para lançar seu novo PC, buscou um sistema operacional e, após negociações frustradas com a Digital Research, fechou uma parceria com a Microsoft. A solução foi o 86-DOS, adquirido pela Microsoft e transformado em PC DOS e MS-DOS. Com um modelo de licenciamento, a Microsoft dominou o mercado, enquanto a IBM, após um breve flerte com o OS/2, perdeu espaço para o Windows.
No mundo corporativo, sistemas como o CP/M foram pioneiros, mas foi o Unix que se destacou por entregar mais estabilidade. A grande virada veio em 1991, quando Linus Torvalds, um estudante da Finlândia, lançou o Linux, um projeto open source que transformou a inovação em um esforço global. O modelo quebrou alguns paradigmas do software proprietário, permitindo o engajamento de comunidades de desenvolvedores ao redor do mundo.
O interessante é que, apesar de ser open source, o Linux é centralizado. Linus Torvalds e a Linux Foundation mantêm controle sobre o que entra no kernel (o núcleo do sistema operacional). A fundação garante que o processo seja organizado, mas, no fim das contas, é Torvalds e outros mantenedores que decidem o que faz sentido para o sistema. Esse equilíbrio entre colaboração aberta e controle centralizado tem funcionado bem para empresas como Red Hat e SUSE, que oferecem suporte pago ao Linux.
Acredito que aqui é um bom ponto de partida para a história do core banking. Do domínio do CP/M e MS-DOS ao Windows e Linux, fica claro que, na tecnologia, competição e colaboração são duas faces da mesma moeda.
O core banking
Quando olhamos para o core banking, vemos uma evolução que se desenvolveu paralelamente aos sistemas operacionais. Vou dividir a história do core banking em quatro gerações.
Nas décadas de 1970 e 1980, vivemos a era dos mainframes. Esses sistemas monolíticos eram pouco flexíveis, tinham baixa capacidade de integração e geralmente eram desenvolvidos internamente pelos próprios bancos. Entre 1990 e 1995, surgiu a primeira geração de core banking, marcada pelo aparecimento dos primeiros players que ofereciam uma stack básica e trabalhavam com um modelo de licenciamento. Era funcional, mas ainda carecia de espaço para customização e agilidade.
Então, entre 2010 e 2015, veio a segunda geração: o core banking passou por um processo de modularização, separando seus componentes essenciais. Essa mudança abriu espaço para mais flexibilidade, facilitando a customização e a integração com outros serviços. Foi nessa geração que o modelo de negócio começou a migrar para um formato de assinatura ou serviço.
A terceira geração surgiu mais ou menos por volta de 2017 e 2019, com a chegada da nuvem — com alguns players da geração anterior se adaptando também. A migração de sistemas on-premises — que rodavam em servidores locais dentro das próprias instituições — para ambientes baseados em cloud se tornou o foco e empresas como a Mambu e Pismo se tornaram relevantes neste cenário. A escalabilidade passou a ser a palavra de ordem e permitiu que as instituições ajustassem sua infraestrutura conforme a demanda.
Agora, players como a Lerian estão dando início à quarta geração, com a arquitetura open source como a grande protagonista. O crescimento passa a ser impulsionado pelo modelo community-led growth. Em vez de depender de soluções proprietárias ou de players pouco flexíveis, as instituições ganham mais liberdade para moldar seus sistemas de acordo com suas necessidades e o surgimento de novas tecnologias.
A anatomia dos players de core banking
Para entender a stack de um core banking, podemos compará-la a um carro: cada peça, do motor às rodas, precisa funcionar em conjunto. Se uma falha, todo o sistema para. O ledger, por exemplo, é o coração de tudo. Ele é o banco de dados responsável por guardar as contas de crédito e débito, e fazer todos os cálculos de saldos e limites. Para tornar mais tangível, seria como a caixa registradora de uma loja, onde todas as transações são registradas e precisam estar organizadas para garantir que os números sempre batam no final.
A stack de governança é outro componente fundamental para sustentar essa estrutura. Ela engloba os aspectos regulatórios do core banking, desde o KYC (Know Your Customer) até o compliance fiscal e regulatório, garantindo que o banco cumpra todas as normas exigidas pelas leis do país. É como se fosse a auditoria interna do core banking, que se certifica de que tudo está dentro da regra.
O terceiro componente é a mensageria, que conecta o core banking com outros sistemas financeiros e arranjos de pagamentos. Ela funciona como uma rede de comunicação, garantindo que as transações sejam processadas e cheguem ao seu destino final. Nos EUA, isso passa por redes como o FedNow e a Clearing House, que garantem a liquidação dos valores. No Brasil, a mensageria é fornecida pelo Sistema Financeiro Nacional (SFN), que cuida da troca de informações financeiras. Aqui entram também as integrações com os boletos, os pagamentos de contas, e as conexões com as bandeiras de cartões, ou seja, qualquer sistema interno e externo é conectado pela mensageria.
Na segunda geração, a partir de 2010, os players de core banking passaram a focar no ledger. Com a concorrência aumentando e as regulamentações apertando o cerco, os bancos tiveram que reinventar suas fontes de receita sem conseguir reduzir custos na mesma proporção. No Brasil, o Banco Central proibiu a cobrança do Pix para pessoas físicas — o que antigamente era permitido para os antigos sistemas de pagamento como o TED e DOC —, enquanto nos EUA, o CFPB limitou as taxas de overdraft, minando os modelos de monetização antes garantidos.
Com as margens encolhendo e a previsibilidade de receita desaparecendo, o ledger deixou de ser apenas uma registradora de transações e passou a ser o coração da estratégia financeira. Controlar o ledger significava controlar e criar novas fontes de receitas. Algumas instituições decidiram internalizar esse componente, ganhando agilidade para testar novos modelos, ajustar custos e criar fluxos novos de receita.
Se você está gostando desta edição, compartilhe com um amigo. Isso ajudará a espalhar a mensagem e me permitirá continuar oferecendo conteúdo de qualidade de forma gratuita.
Customizar o ledger pode habilitar novos casos de uso, como permitir que bancos e fintechs integrem múltiplos ativos — moedas tradicionais, criptoativos e stablecoins — criando um diferencial competitivo. Outro exemplo é a implementação de smart contracts, que tornam os pagamentos dinâmicos e automatizam as renegociações de contratos, eliminando os intermediários — ideal para transações mais complexas.
Por fim, a personalização das transações com a DSL (Domain-Specific Languages), uma linguagem criada para resolver problemas específicos, pode eliminar a rigidez de soluções como o REST ou SQL, que são mais genéricas. O REST exige padrões fixos, enquanto o SQL, comum no gerenciamento de grandes volumes de dados, limita a flexibilidade para regras personalizadas, como split de pagamentos ou cálculos dinâmicos de juros compostos.
Com a DSL, a realidade muda. Ela permite que as empresas criem soluções com regras específicas, sem depender de múltiplas integrações ou ajustes em sistemas genéricos. Na prática, uma plataforma de pagamentos que usa uma DSL para personalizar o split de pagamentos pode criar regras automáticas baseadas em critérios definidos, como percentual de participação ou valor fixo. Se um comerciante e um fornecedor realizarem uma venda conjunta, a DSL pode dividir o pagamento entre eles de forma instantânea, ajustando as porcentagens conforme parâmetros acordados, como performance de vendas ou contrato. Isso simplifica o processo e aumenta a transparência, eliminando também os ajustes manuais.
Analisando os players
Para entender a customização de ledger, vou analisar duas empresas da geração de Cloud Core: Pismo e Mambu. A Mambu foi pioneira em cloud, mas a Pismo se destacou por oferecer um ledger completo e se tornar referência em processamento de pagamentos.
Mambu
A Mambu ainda depende de integrações com processadoras externas de pagamentos, o que pode aumentar a complexidade e os custos para os seus clientes. Desde sua fundação em 2011, a empresa se consolidou como um dos principais players no mercado de core banking baseado em nuvem. Sua arquitetura API-first e a disponibilidade em plataformas como AWS, Google Cloud e Microsoft Azure ajudaram a reduzir os custos de infraestrutura.
A Mambu adotou o conceito de Composable Banking, no qual seus clientes constroem seus serviços a partir de módulos independentes, conectando soluções externas por meio de APIs em vez de desenvolver tudo internamente. A sua camada de orquestração, o Mambu Process Orchestrator (MPO), é o seu diferencial, pois ele acelera o desenvolvimento de novos produtos financeiros, graças ao ecossistema de parcerias que a Mambu criou, integrando-se com empresas como ComplyAdvantage para AML, Marqeta para emissão de cartões, ClearBank para pagamentos em tempo real, Wise e CurrencyCloud para transações internacionais e o Stitch, que otimiza o fluxo de dados para data warehouses como Redshift e BigQuery.
Ao contrário da Pismo, que centralizou tudo em sua própria plataforma, a Mambu fechou várias parcerias para o processamento de pagamentos. O processo de pagamento e a emissão de cartões varia bastante dependendo do fornecedor. Por exemplo, o ClearBank oferece uma infraestrutura bancária via APIs, enquanto o GoCardless facilita os pagamentos recorrentes. Já a Wise otimiza as transferências internacionais com conversão de moeda em tempo real.
Em emissão e processamento de cartões, a Marqeta é um dos parceiros do ecossistema, permitindo que sejam emitidos cartões físicos ou virtuais. Ela cuida de tudo, desde a criação do cartão até a autorização de pagamento e a verificação de disponibilidade de fundos. Após a transação ser realizada, a plataforma se comunica com redes de pagamento como Visa e Mastercard para validar e aprovar a operação, com a liquidação acontecendo diretamente no sistema da Marqeta.
Embora o orquestrador tenha acelerado o desenvolvimento de novos produtos, ele exige múltiplas integrações. O processo de configuração é simples (link para a documentação 👉 aqui), com arquivos JSON importados diretamente para o MPO. No entanto, as atualizações periódicas e os ajustes necessários de configuração das integrações podem ser desafiadores para as equipes de tecnologia de bancos e fintechs, que precisam garantir a fluidez e o funcionamento em tempo real dos processos — especialmente no processamento de pagamentos.
Pismo
Enquanto a Mambu focou em construir um ecossistema, a Pismo entendeu que, para muitos players financeiros, ter um core banking é apenas o começo. Eles também precisam de uma solução de pagamento eficiente, como um cartão. Por isso, a Pismo não só oferece o ledger de contas, mas também integra o processamento de pagamentos diretamente na plataforma, eliminando fornecedores externos e reduzindo integrações e custos.
O diferencial da Pismo está em sua abordagem agnóstica: tanto a conta quanto o processador de pagamentos são desenhados para serem flexíveis, adaptando-se a diversas tecnologias e padrões globais, o que a torna capaz de atender às necessidades de bancos tradicionais e challenger banks.
A flexibilidade fica evidente na API de Contas (link para a documentação 👉 aqui), que facilita o gerenciamento de saldo, limite de crédito e dados dos clientes. As contas podem ser configuradas para diferentes tipos de uso, como crédito ou débito.
Em 2022, a Pismo mais que dobrou o número de operações, abrindo 35 milhões de novas contas e emitindo 70 milhões de cartões 4. Sua arquitetura baseada em eventos transforma cada transação em um “evento”, acionando automaticamente ações no sistema. Isso melhora o controle, facilita relatórios para reguladores e garante a conformidade regulatória, com cada operação — compra ou transferência — passando por autorização, processamento e organização contábil.
A plataforma também oferece modelos bancários, como Banking as a Service (BaaS), permitindo que clientes de diversos setores se conectem a provedores licenciados, como BTG, Celcoin, Itaú e JD Consultores, oferecendo serviços como contas digitais, transferências bancárias e empréstimos.
A Pismo, através da oferta de um ledger de contas e de processamento de pagamentos, conseguiu se expandir para outras geografias. Isso fez com que ela buscasse se conectar aos principais sistemas de pagamentos em tempo real do mundo, como o Pix no Brasil, o Faster Payments no Reino Unido e o United Payments Interface (UPI) na Índia.
Estratégias diferentes
Aqui não se trata de melhor ou pior solução, mas de uma escolha baseada nas necessidades particulares de cada banco e fintech. A Mambu focou em soluções flexíveis para instituições que precisavam escalar rapidamente, priorizando integrações externas. Já a Pismo se concentrou em oferecer uma plataforma integrada, permitindo o gerenciamento centralizado de contas e pagamentos.
O interessante é como ambas aproveitaram o potencial da nuvem para oferecer flexibilidade. A Mambu foi pioneira, mas a Pismo percebeu que, sem o processamento de pagamentos, seu modelo seria oneroso para os clientes. Podemos dizer que essa estratégia se provou certa em 2023, quando a Visa adquiriu a empresa por US$ 1 bilhão, uma transação que colocou a tecnologia financeira brasileira em evidência global e destacou a capacidade da Pismo de se integrar de forma agnóstica a outros sistemas financeiros.
A quarta geração de core banking
Quando falo da quarta geração, me refiro a uma aposta — ela ainda está em construção. O que a diferencia das gerações anteriores é a busca por flexibilidade e independência, características que o mercado busca e que a tecnologia open source pode oferecer.
A Mambu criou um ecossistema de soluções, impactando positivamente o desenvolvimento de produtos financeiros e flexibilizando o ledger. A Pismo percebeu rapidamente que, além do core banking tradicional, incorporar o processamento de pagamentos reduziria o tempo de integração com soluções externas e custos. Na quarta geração, veremos a combinação das melhores características anteriores, mas com a flexibilidade muitas vezes significando abrir mão de algo muito valioso para uma empresa de tecnologia: o código-fonte.
Neste campo, empresas como Formance e Lerian tem apostado na tese. Vou aprofundar no modelo da Lerian, mas antes, é importante entender como funciona a governança de um open source.
Entendendo a governança do open source
No início desta edição, mencionei que comparar a história do core banking com a dos sistemas operacionais ajudaria a entender a nova fase do mercado. A história do Linux é relevante para entendermos o que está em jogo aqui. No universo open source, vou usar dois exemplos: a Linux Foundation e a Apache Foundation.
Linux e Apache apostaram em um modelo aberto, permitindo que desenvolvedores e usuários participassem ativamente, o que possibilitou o crescimento orgânico de ambos os projetos. Em vez de um modelo fechado, o objetivo foi criar um ambiente colaborativo com contribuições recorrentes.
Ambos mostraram como um modelo aberto gera produtos escaláveis, mas com modelos de governança diferentes. Ambos adotaram um código aberto, mas com modelos de governança diferentes. No Linux, a governança é centralizada na Linux Foundation, com Linus Torvalds e outros decidindo sobre o kernel. Já na Apache, a governança é descentralizada, com maior autonomia para os grupos de gestão (PMCs), mas ainda com diretrizes da fundação (link para documentação 👉 aqui). Apesar de abertos, ambos mantêm controle sobre as contribuições, equilibrando flexibilidade e supervisão de formas distintas.
A chegada da Lerian
Bom, agora aterrissamos na Lerian. Analisando a evolução do core banking, fica claro que a flexibilidade é essencial para expandir uma solução. Isso fica claro nas histórias da Mambu e da Pismo, que mostraram que, além do ecossistema, o foco deve ser em entregar o que o cliente precisa de forma simples e com o menor custo.
A Lerian propõe isso ao mercado: um ecossistema open source que permita até mesmo seus concorrentes, como Pismo e Mambu, utilizarem seu ledger e desenvolverem soluções sobre ele, de forma semelhante ao que aconteceu com a Apache e Linux, por exemplo.
Por trás da Lerian estão Fred Amaral e Marilyn Hahn. Acompanho a trajetória de ambos há alguns anos e acredito que são o "perfect match" para a construção dessa solução. Fred fundou a Dock, uma empresa que se tornou referência em BaaS no mercado brasileiro, enquanto a Marilyn fundou a Banklyn, também no segmento de BaaS, que foi vendida para a Méliuz e depois para o BV.
Saber disso é importante por um motivo: eles conhecem esse mercado como poucos, desde a implementação de um BaaS até a migração para um core banking. Essa experiência se reflete na proposta da Lerian. Enquanto Pismo e Mambu seguiram caminhos distintos, a Lerian aposta na flexibilidade e customização via open source, com o produto chamado Midaz.
Apostar no open source faz sentido por alguns motivos. Com cada vez mais bancos e fintechs migrando para um core banking próprio em busca de flexibilidade, a Lerian pode ser um atalho: em vez de começar do zero, podem construir sobre uma base já testada. Além disso, o open source traz um nível maior de confiança — sua maior força está na transparência. Qualquer pessoa pode inspecionar o código, identificar vulnerabilidades e validar a segurança do sistema.
O Midaz segue o mesmo princípio de projetos open source como Apache e Linux: há regras. Assim como no Linux o segredo está no kernel, para a Lerian está no ledger. Tudo gira em torno da evolução do ledger.
O processo de contribuição 5 é simples e estruturado. Começa com a identificação do problema (quando se detecta uma necessidade ou falha no código), seguido pela solicitação de pull (um pedido para adicionar alterações), assinatura de commit (quando o contribuinte formaliza as mudanças), revisão do código (onde outros verificam a qualidade e segurança do código) e, por fim, a mescla (integração do código ao repositório principal).
A transparência é um pilar central da governança do Midaz, com todas as decisões sendo tomadas com base em uma comunicação aberta entre todos os participantes. Se surgirem conflitos, o processo de resolução começa com a mediação, podendo ser escalado para o Comitê de Direção, que garante que as disputas sejam resolvidas de maneira imparcial 6.
Construindo um ecossistema
O open source, por mais revolucionário que seja, tem um grande problema: a monetização. Não existe almoço grátis. A Lerian resolveu isso com dois modelos: community e enterprise. No community, os usuários da versão open source têm suporte por meio da comunidade no GitHub e Discord. No modelo enterprise, os clientes usam o mesmo código, mas com plugins e serviços extras.
São três modalidades: (i) Lerian Cloud (SaaS), com infraestrutura pronta e suporte completo em software, infraestrutura e cibersegurança; (ii) Managed Cloud, onde ela gerencia a infraestrutura do cliente (AWS, Azure ou GCP); (iii) 3rd-Party Managed, onde o cliente ou terceiros cuidam da infraestrutura e recebem suporte em software. Algo similar acontece com a francesa Formance, que também adota uma abordagem de plataforma modular, semelhante à AWS, permitindo que seus clientes integrem vários módulos para otimizar sua infraestrutura financeira.
A Lerian não cobra por contas ativas, inativas ou taxas de transação. O modelo de cobrança é simples e transparente: taxas de assinatura (suporte e plugins) e custos de cloud para quem usa o Lerian Cloud. Isso significa que os custos escalonam conforme o sucesso e o crescimento da empresa, tornando o modelo mais dinâmico e justo. A Lerian tem plugins próprios e de terceiros, uma estratégia similar à da Mambu. Alguns exemplos incluem Pix, boletos, processamento de cartões, contas múltiplas, regulatórios, exchange de moedas, investimentos, CRM, integrações ERP e até soluções em crypto e seguros.
Construindo uma comunidade
O sucesso no open source não acontece da noite para o dia, mas ele passa por uma comunidade engajada. Linux e Apache mostraram que construir essa base leva tempo. Para a Lerian, penso que o caminho já está sendo traçado: seus fundadores já faziam parte da indústria, o que contribui para a construção de uma sólida reputação.
Podemos analisar o desempenho da comunidade com base no engajamento do repositório da Lerian no GitHub. Nos últimos 30 dias, houve mais de 80 contribuições — os principais contribuidores ainda são membros da equipe. Será uma métrica interessante para revisitar nos próximos meses, à medida que as iniciativas de marketing continuarem evoluindo.
Acredito que um exemplo interessante em criação de comunidade é o caso da Rocketseat, uma comunidade que virou uma grande plataforma de ensino de desenvolvimento de software. Acompanho a empresa desde 2019 e lembro que, em 2020 a empresa teve o seu grande boom. Através de parcerias estratégicas, como a compra da Shawee, hackathons e workshops, eles consolidaram a marca no mercado de tecnologia. A Lerian pode testar os mesmos canais e isso poderia ser um excelente meio de atrair talentos e, ao mesmo tempo, criar um forte senso de pertencimento e missão baseada em: criar soluções flexíveis que capacitem as instituições a gerenciar suas próprias operações com autonomia, de forma aberta, colaborativa e acessível.
👉 Inscreva-se na W Fintechs e receba toda segunda-feira uma análise como essa no seu e-mail.
A Apache do core banking?
A Lerian talvez não seja o Linux do core banking, mas acredito que possa se tornar a Apache: uma fundação sólida para quem quer construir. Não se trata de substituir a Mambu ou a Pismo, e sim de oferecer a bancos, fintechs e até concorrentes uma base flexível, aberta e colaborativa de desenvolvimento. Se der certo, pode transformar a forma como o core banking é desenvolvido e escalado no mundo.
Durante minha conversa com Fred, fiquei impressionado com sua capacidade de conectar ideias e se aprofundar de forma simples em temas complexos. A primeira coisa que ele me disse, logo após eu elogiar sua trajetória profissional, foi: "E nada disso eu planejei.” Acho que isso resume bem o que é construir uma comunidade: a conexão e a contribuição humana não são planejadas, elas simplesmente acontecem quando sustentadas por alicerces sólidos. A Lerian está construindo parte dessa stack do futuro; espero que consigam.
Saúde e paz,
Walter Pereira
Disclaimer: As opiniões expressas aqui são de total responsabilidade do autor, Walter Pereira, e não refletem necessariamente as opiniões dos patrocinadores, parceiros ou clientes da W Fintechs.
https://www.thebusinessresearchcompany.com/report/core-banking-software-global-market-report
https://building.nubank.com.br/pt-br/the-spark-of-our-foundation-a-letter-from-our-founders/
https://www.fintechfutures.com/2024/03/from-start-up-to-unicorn-the-rise-of-revolut/
https://aws.amazon.com/pt/blogs/aws-brasil/como-a-pismo-processa-200-milhoes-de-eventos-por-dia-utilizando-servicos-aws/
https://github.com/LerianStudio/midaz/blob/main/CONTRIBUTING.md
https://github.com/LerianStudio/midaz/blob/main/GOVERNANCE.md