Por que deixei meu cargo de CTO para construir o core banking que o Brasil merecia

A decisão que mudou tudo

Em 2022, eu era CTO do Agente Autônomo de Investimentos da XP, dentro do Grupo Bequest. Bom salário, stock options, um time que eu tinha construído do zero. O tipo de posição que a maioria das pessoas em tech passa uma carreira inteira tentando alcançar.

Mas eu tinha um sonho que não me deixava dormir: construir uma securitizadora. A tese era clara — tokenizar recebíveis, conectar originadores ao mercado de capitais, democratizar acesso a crédito. Eu tinha o conhecimento financeiro, o background técnico e a convicção.

Então eu saí. Pedi demissão de tudo e fundei minha securitizadora.

O muro que eu bati

Para construir uma securitizadora, eu precisava de infraestrutura bancária. Contas, pagamentos, ledger, scoring de risco, compliance. O caminho óbvio: integrar com um provedor de BaaS brasileiro.

O que eu encontrei foi um pesadelo.

APIs sem padrão. Cada provedor tinha seu próprio formato proprietário. Sem ISO 20022. Sem BIAN. Sem consistência. Integrar com um significava aprender um dialeto que não funcionava em nenhum outro lugar.

Contratos leoninos só para ler a documentação. Não estou exagerando. Múltiplos provedores exigiam assinar contratos comerciais vinculantes — com compromissos de volume mínimo e cláusulas de exclusividade — apenas para acessar a documentação da API. Você não conseguia nem avaliar o produto antes de estar preso.

Sistemas legados vestindo roupas modernas. Por trás das fachadas REST estavam cores COBOL, processamento batch e atrasos de reconciliação que tornavam operações em tempo real impossíveis. 80% das vezes, as APIs não conseguiam lidar com o que o mercado realmente precisava hoje.

Suporte que não existia. Quando algo quebrava — e coisas quebravam frequentemente — suporte significava um canal de Slack compartilhado onde suas mensagens ficavam sem resposta por dias. Sem SLAs. Sem relatórios de incidentes. Sem responsabilidade.

Passei 6 meses avaliando cada provedor de BaaS no Brasil. A conclusão foi devastadora: nenhum deles conseguia suportar o que eu estava tentando construir. Nem de longe.

A decisão mais difícil: adiar o sonho

Eu tinha duas opções. Construir a securitizadora em cima de infraestrutura quebrada e rezar para que aguentasse. Ou construir a infraestrutura primeiro.

Eu escolhi o caminho mais difícil.

Adiei o projeto de securitização — o próprio motivo pelo qual eu tinha largado minha carreira — e investi tudo que eu tinha em construir um core bancário do zero. Não um wrapper em cima de sistemas legados. Não uma camada de tradução. Um core real, construído do chão, baseado em padrões internacionais.

Foi aterrorizante. Eu estava queimando economias, recusando ofertas de emprego e construindo algo que poderia levar anos antes de gerar receita. Meus amigos achavam que eu era louco. Alguns dias, eu concordava com eles.

A arquitetura que nasceu da dor

Cada decisão de design no core da Revenu nasceu de uma frustração específica que eu experimentei como cliente de BaaS brasileiro:

Event Sourcing — porque estado é mentira

Cores bancários tradicionais armazenam o estado atual: saldo = R$ 10.000. Mas como chegou ali? Um depósito? Uma reversão? Uma correção? O estado sozinho não diz.

Na Revenu, cada operação é um evento imutável:

• AccountOpened { id: acc_7x, type: checking, holder: "João Silva" }
• FundsDeposited { account: acc_7x, amount: 10000, source: pix_2x }
• TransferInitiated { from: acc_7x, to: acc_3y, amount: 5000 }

Estado é derivado, nunca armazenado diretamente. Isso nos dá auditabilidade completa, consultas temporais, zero perda de dados e debug gratuito. Quando o BACEN pergunta "o que aconteceu?", respondemos com certeza criptográfica.

ISO 20022 — nativo, não traduzido

A maioria dos cores brasileiros gera mensagens proprietárias e traduz para ISO 20022 na borda. Nós geramos pacs.008, pacs.002, camt.053 internamente. 19 tipos de mensagens nativas. Sem camada de tradução. Sem perda de dados na conversão.

É por isso que a Revenu é o único core bancário do Brasil com 100% de aderência ao ISO 20022.

BIAN (Banking Industry Architecture Network)

Não adotamos apenas ISO 20022 para mensageria — adotamos BIAN para toda nossa arquitetura de serviços. Cada microsserviço mapeia para um Service Domain do BIAN. Isso significa que nossa arquitetura fala a mesma língua que bancos globais, tornando a interoperabilidade com sistemas como Temenos, Finastra e Mambu trivial.

Ontologia FIBO

Nosso modelo de dados é construído sobre FIBO (Financial Industry Business Ontology). Cada entidade — contas, instrumentos, partes, contratos — segue as definições semânticas usadas por reguladores no mundo inteiro. Isso não é vaidade acadêmica. É o que nos permite tropicalizar formatos de pagamento brasileiros (PIX, TED, Boleto) em lançamentos de ledger internacionais que Temenos e sistemas similares entendem nativamente.

Event-Driven Architecture com Kafka

Cada mudança de estado emite um evento para um tópico Kafka. Não como um complemento — como a fonte primária de verdade. Nossa arquitetura inteira é EDA-nativa:

• Commands validam regras de negócio e emitem eventos de domínio
• Projections consomem eventos e constroem read models (CQRS)
• Sagas orquestram processos multi-step (transferências, liquidações)
• Consumidores externos recebem eventos via streams documentados com AsyncAPI

Isso significa que qualquer sistema — interno ou externo — pode se inscrever no stream de eventos financeiros em tempo real. Sem polling. Sem arquivos batch. Sem delays.

AsyncAPI + REST

Nossas APIs seguem dois padrões simultaneamente:

• REST para operações síncronas (criar conta, iniciar transferência)
• AsyncAPI para streaming de eventos (tópicos Kafka documentados com spec AsyncAPI)

Desenvolvedores escolhem: chamar a API e receber uma resposta, ou se inscrever no stream de eventos e reagir. A maioria usa os dois.

A camada de tropicalização

Aqui está o que torna a Revenu única no contexto global: nós fazemos a ponte entre a infraestrutura de pagamentos brasileira (SPI, SPB, CIP) e padrões internacionais.

Um pagamento PIX na Revenu gera:

• Uma mensagem pacs.008 ISO 20022 nativa para o SPI
• Um lançamento de ledger double-entry seguindo ontologia FIBO
• Um evento Kafka seguindo spec AsyncAPI
• Uma interação de serviço compatível com BIAN

Isso significa que uma instância Temenos em Londres pode entender um pagamento PIX originado em São Paulo sem nenhum middleware de tradução. Somos a Pedra de Rosetta entre a fintech brasileira e a infraestrutura bancária global.

É isso que simplifica a entrada de players como Stripe, PayPal e Adyen no mercado brasileiro. Em vez de construir integrações customizadas para cada peculiaridade brasileira, eles conectam na Revenu e ganham acesso ISO 20022-nativo a PIX, TED, Boleto e todo o ecossistema de pagamentos brasileiro.

CQRS: leituras e escritas vivem em mundos diferentes

Event Sourcing se combina naturalmente com CQRS. Na nossa arquitetura:

• Lado de escrita — valida invariantes, emite eventos, mantém consistência
• Lado de leitura — consome eventos, constrói projeções desnormalizadas, serve queries em < 5ms

Consultas de saldo batem no read model. Processamento de transferências bate no write model. Eles nunca competem por recursos.

DDD: o domínio dirige tudo

Nosso modelo usa 14 agregados DDD mapeando para conceitos bancários reais:

• Account Aggregate — saldo, limites, transições de status
• Transfer Aggregate — ciclo de vida do pagamento (initiated → processing → completed)
• Ledger Aggregate — lançamentos de partida dobrada com mapeamento COSIF
• Compliance Aggregate — máquina de estados KYC, screening PEP, scoring de risco

Cada agregado impõe suas próprias invariantes. Uma conta não pode ficar negativa a menos que o cheque especial esteja habilitado. Uma transferência não pode ser concluída se a origem estiver bloqueada.

Os resultados — 4 anos depois

O que começou como frustração é agora o core bancário mais aderente a padrões do Brasil:

• 16.7K TPS de throughput sustentado
• 100% ISO 20022 — 19 tipos de mensagens nativas
• 100% BIAN — arquitetura de serviços mapeada para domínios BIAN
• Ontologia FIBO — interoperabilidade semântica com bancos globais
• Zero inconsistências de dados — replay de eventos bate 100% com estado atual
• 14 agregados DDD cobrindo todo o domínio bancário
• ISO 27001 certificado — segurança by design

O que eu aprendi

Construir infraestrutura é o tipo mais solitário de startup. Você não tem usuários celebrando sua nova feature no Twitter. Você não tem loops de crescimento viral. Você tem bancos rodando auditorias de compliance no seu código e reguladores questionando suas decisões de arquitetura às 2 da manhã.

Mas quando uma fintech lança seu produto de crédito em 4 semanas usando suas APIs — quando um marketplace processa R$ 12M por mês pelo seu motor de split — quando um desenvolvedor diz "essa é a primeira API bancária que simplesmente funciona" — você sabe que a decisão foi certa.

Eu adiei meu sonho de securitização por 4 anos. Mas construí algo maior: a infraestrutura bancária que eu gostaria que tivesse existido quando eu comecei.

Event Sourcing não é apenas uma escolha técnica. É uma escolha filosófica. Nós escolhemos lembrar de tudo, tornar cada evento financeiro imutável e rastreável, porque é isso que sistemas financeiros regulados merecem.

O mundo do core banking antigo armazena estado e torce pelo melhor. Nós armazenamos verdade.