Tecnologias usadas em Banking as a Service no Brasil

outubro 24, 2025

Principais lições deste artigo

O BaaS no Brasil exige integração obrigatória com SPI, DICT e Open Finance desde o primeiro dia de operação.
Arquiteturas baseadas em microsserviços, event sourcing e observabilidade são indispensáveis para atender exigências regulatórias do Banco Central.
Automação de relatórios, como CCS, DIMP e CADOCs, e controles de KYC e AML reduzem riscos e garantem conformidade contínua.
Evitar contas-bolsão, monolitos e processos manuais é essencial para escalar com segurança e reduzir a chance de penalidades.
Para implementar uma solução completa e regulada de BaaS, conheça a plataforma da Celcoin.

Última atualização: 10 de junho de 2026

Contexto regulatório e necessidade do stack BaaS

O Sistema de Pagamentos Instantâneos (SPI) é a infraestrutura de liquidação em tempo real do Banco Central que sustenta o Pix. Toda instituição participante direta do SPI deve acessar o DICT diretamente, consultando e registrando chaves, como CPF ou CNPJ, e-mail, celular ou chave aleatória, para viabilizar a iniciação de pagamentos sem que o pagador precise informar agência e conta completos. Esse requisito técnico obrigatório define o ponto de entrada do stack, porque qualquer plataforma BaaS que queira oferecer Pix precisa de conectividade certificada com o SPI e com o DICT.

Além do Pix, o Open Finance impõe APIs padronizadas para compartilhamento de dados e iniciação de pagamentos com consentimento do usuário, conforme a documentação técnica do Banco Central. A LGPD e as resoluções da SUSEP adicionam requisitos de privacidade, consentimento e reporte que atravessam todas as camadas do sistema. Para atender a esse conjunto de obrigações regulatórias de forma integrada, o stack tecnológico precisa ser construído com componentes específicos, cada um responsável por uma camada de conformidade.

Definição dos principais componentes do stack

O stack tecnológico de um BaaS regulado no Brasil é composto por camadas interdependentes. Para operar com conformidade regulatória desde o primeiro dia, cada camada precisa atender a padrões técnicos específicos e obrigações do Banco Central, e a tabela abaixo mapeia essas dependências e mostra onde a conformidade é obrigatória ou opcional.

Camada	Componente	Padrão/Protocolo	Obrigatoriedade regulatória
Conectividade com Bacen	SPI / DICT	ISO 20022, RSFN	Participantes diretos do Pix
APIs externas	Gateway RESTful + OAuth 2.0 / FAPI	OpenAPI 3.x, mTLS	Open Finance (Bacen)
Mensageria interna	Event broker (Kafka/RabbitMQ)	Eventos assíncronos	Rastreabilidade e auditoria
Core de contas	Ledger transacional	Double-entry accounting	COSIF, CCS, CADOCs
Compliance	KYC/AML + relatórios automatizados	DIMP, SCR, BacenJud	Bacen, Receita Federal, SUSEP
Infraestrutura	Kubernetes + cloud nativa	CI/CD, observabilidade	Disponibilidade e resiliência

Arquiteturas monolíticas legadas não conseguem atender a esse conjunto de requisitos com agilidade. A adoção de microsserviços permite que cada domínio, como contas, pagamentos, compliance e cartões, evolua de forma independente, com deploys sem downtime e escalabilidade horizontal.

Integração em camadas: fluxos práticos de consentimento, mensageria e liquidação

Um fluxo típico de pagamento via Pix em uma plataforma BaaS segue uma sequência clara de etapas técnicas, da iniciação ao registro da liquidação no ledger.

1. Iniciação: o cliente final aciona a API RESTful do BaaS via aplicativo. O gateway valida o token OAuth 2.0 com escopo de pagamento e roteia a requisição ao microsserviço de Pix.

2. Resolução de chave: o microsserviço consulta o DICT via conexão certificada na RSFN e obtém os dados da conta de destino, como instituição, agência, número de conta e tipo.

3. Publicação de evento: após validação de saldo e limites, o serviço publica um evento de “pagamento autorizado” no broker de mensagens. Consumidores downstream, como antifraude, ledger e notificações, processam o evento de forma assíncrona.

4. Liquidação no SPI: a mensagem de liquidação é enviada ao SPI em formato ISO 20022. O Banco Central confirma a liquidação e o evento de “pagamento liquidado” é publicado, atualizando o ledger e disparando notificações.

Para o Open Finance, o fluxo de consentimento segue o padrão FAPI com redirecionamento OAuth, registro de consentimento em base de dados auditável e expiração controlada conforme as regras de participação do Banco Central. Esse modelo de integração em camadas permite reaproveitar componentes de segurança, mensageria e auditoria tanto para Pix quanto para Open Finance.

Descobrir a solução completa do banking da Celcoin para fintechs, bancos digitais, gestoras de fundos, varejistas e ERPs.

Panorama regulatório atual (Bacen, LGPD, SUSEP) e tendências

O Banco Central exige que Instituições de Pagamento e Instituições Financeiras enviem relatórios periódicos via RSFN, incluindo CCS, CADOCs, COSIF, DIMP, SCR e DES-IF. A automação desses reportes é condição operacional, não diferencial competitivo, porque atrasos ou inconsistências geram penalidades e podem resultar em suspensão de licença.

A LGPD impõe controles de consentimento, minimização de dados e direito ao esquecimento que afetam diretamente o design do banco de dados e dos fluxos de KYC. A SUSEP regula o Open Insurance com requisitos análogos ao Open Finance e exige APIs padronizadas e gestão de consentimento para seguradoras e insurtechs.

A tendência para 2026 é a convergência entre Open Finance, Open Insurance e iniciação de pagamentos em um ecossistema unificado, com maior exigência de rastreabilidade de eventos e auditoria imutável em logs de acréscimo. Para atender a essas exigências crescentes sem comprometer a agilidade operacional, plataformas BaaS precisam adotar práticas de arquitetura que equilibrem conformidade e escalabilidade.

Boas práticas de arquitetura, governança e observabilidade

Plataformas BaaS de produção no Brasil adotam um conjunto de práticas que se complementam para garantir resiliência, conformidade e capacidade de evolução contínua.

Microsserviços com domínios bem definidos: separar contas, pagamentos, cartões, compliance e relatórios em serviços independentes reduz o raio de impacto de falhas e permite atualizações regulatórias sem parada total do sistema. Essa separação cria dependências distribuídas que precisam ser rastreadas de forma consistente, e esse é o papel do event sourcing.

Event sourcing e CQRS: armazenar todos os eventos de negócio como fonte de verdade garante auditoria completa e facilita a reconciliação com os relatórios do Bacen. Para que esse modelo funcione em produção, a plataforma precisa de visibilidade em tempo real sobre o comportamento de cada serviço e de cada fluxo de evento.

Observabilidade em três pilares: métricas como latência, taxa de erro e throughput, além de logs estruturados e rastreamento distribuído, são indispensáveis para cumprir os SLAs de disponibilidade exigidos pelo Bacen para participantes do Pix. Essa visibilidade orienta decisões de capacidade e prepara a infraestrutura para lidar com picos de demanda.

Infraestrutura Kubernetes com autoscaling: picos de volume, como datas comemorativas ou campanhas de varejo, exigem escalabilidade horizontal automática sem degradação de latência. O autoscaling baseado em métricas de uso complementa a observabilidade e reduz o risco de indisponibilidade em momentos críticos.

Segurança por design: mTLS entre microsserviços, rotação automática de certificados, vault para segredos e autenticação multifator para operadores formam a base de segurança em ambientes regulados. Esses controles sustentam os requisitos de LGPD, Open Finance e Open Insurance e reduzem a superfície de ataque.

Erros comuns a evitar

Operar com contas-bolsão: estruturas em que recursos de múltiplos clientes finais são mantidos em uma única conta da instituição são irregulares e vedadas pelas normativas do Banco Central. Cada cliente final deve ter conta individualizada com saldo segregado. Mesmo com contas individualizadas, a conformidade regulatória depende de reportes precisos, e esse é um ponto em que muitas plataformas ainda falham.

Relatórios manuais: gerar CCS, DIMP ou CADOCs manualmente aumenta o risco de erro e atraso. A automação via integração direta com a RSFN é o único caminho sustentável em escala e reduz o esforço operacional recorrente.

KYC sem biometria e validação de documentos: processos de onboarding sem validação biométrica e checagem em listas de restrição, como PEP, OFAC e COAF, expõem a instituição a risco de AML e sanções regulatórias. Esses riscos se somam aos de reporte manual e podem comprometer a continuidade da operação.

Arquitetura monolítica para compliance: embutir regras de compliance em um monolito impede atualizações rápidas quando o Banco Central altera normas, o que ocorre com frequência. Essa limitação aumenta o tempo de resposta a mudanças regulatórias e amplia o risco de não conformidade temporária.

Ausência de circuit breakers: dependências síncronas sem circuit breaker entre microsserviços propagam falhas em cascata, comprometendo a disponibilidade do Pix e gerando obrigações de reporte de incidentes ao Banco Central. Evitar esses erros é crítico, porque diferentes perfis de empresa enfrentam prioridades técnicas distintas ao implementar BaaS, e entender essas prioridades ajuda a focar os esforços de arquitetura nos pontos de maior impacto.

Aplicações reais por perfil de empresa

Fintechs e bancos digitais em estágio inicial: utilizam o BaaS para operar sob licença de terceiros enquanto desenvolvem produto e base de clientes. O stack precisa suportar onboarding digital, Pix, cartão pré-pago e relatórios regulatórios desde o MVP, com flexibilidade para evoluir para licença própria no futuro.

Varejistas de grande porte: integram serviços financeiros, como conta digital, cartão white label e Pix, diretamente no aplicativo ou ERP de loja para aumentar fidelização e criar nova linha de receita. A prioridade técnica é integração via APIs RESTful bem documentadas, com baixo tempo de implementação e alta disponibilidade.

ERPs: embarcam serviços financeiros, como pagamento de fornecedores, gestão de recebíveis e Pix automático, diretamente na plataforma de gestão dos clientes. O diferencial técnico é a capacidade de processar alto volume de transações B2B com automação de conciliação e relatórios fiscais.

Instituições já licenciadas, como IPs e IFs: migram para Core Banking moderno para eliminar dependência de sistemas legados, automatizar reportes ao Banco Central e ganhar capacidade de lançar novos produtos sem ciclos longos de desenvolvimento. Essa migração reduz custo de manutenção e aumenta a previsibilidade operacional.

Tabela de funcionalidades da Celcoin

A Celcoin opera com portfólio completo de licenças e tecnologia proprietária, mediando mais de R$ 30 bilhões em transações mensalmente para mais de 6 mil clientes, de fintechs em estágio inicial a bancos digitais consolidados, além de varejistas e ERPs. A plataforma cobre todo o stack descrito neste guia: conectividade com SPI e DICT, Open Finance, Core Banking, KYC e AML, relatórios regulatórios automatizados e infraestrutura cloud-nativa. A tabela abaixo traduz cada componente técnico do stack em benefícios operacionais concretos para sua empresa.

Funcionalidade da Celcoin	Benefício para sua empresa
APIs modulares	Integrações mais rápidas, com redução de custos e prazos de desenvolvimento.
Experiência e suporte ao desenvolvedor	Documentação, SDKs e sandboxes reduzem ciclos de integração e custos de engenharia.
Capacidade de lançamento rápido	Módulos pré-construídos e entrega via SaaS aceleram lançamentos e melhoram o tempo para geração de receita.
Distribuição white-label e embutida	Suporte a produtos financeiros com marca própria em diferentes canais digitais.
Escalabilidade com confiabilidade	Solução com alta disponibilidade e escalável na nuvem mantém serviços funcionando mesmo com altos volumes e protege a receita.
Cobertura de diversas possibilidades de pagamentos, incluindo crédito	Oferta de pagamentos e emissão de crédito aumenta conversão, ARPU e fidelização.
Acesso a dados e personalização	Dados e análises via Open Finance permitem ofertas personalizadas e melhoram conversão e retenção.
Compliance e conformidade como princípio	KYC, AML e relatórios integrados reduzem risco regulatório e aceleram ciclos de vendas.
Prevenção de fraude e controles de risco	Monitoramento baseado em IA e autenticação robusta reduzem estornos, perdas e exposição regulatória.
Força do ecossistema de parceiros da Celcoin	Parcerias e integrações com bancos, redes e fintechs ampliam cobertura, recursos e velocidade de entrada no mercado.

Essa combinação de funcionalidades técnicas e benefícios de negócio permite que empresas de diferentes portes lancem e escalem serviços financeiros com menor risco e maior previsibilidade.

Conhecer a plataforma completa do banking da Celcoin para sua operação.

Perguntas frequentes

Qual a diferença entre SPI e DICT no contexto do Pix?

O SPI é a infraestrutura de liquidação bruta em tempo real operada pelo Banco Central, por onde as mensagens financeiras do Pix trafegam e são liquidadas. O DICT é o diretório que armazena as chaves Pix e os dados cadastrais das contas associadas a essas chaves. Uma plataforma BaaS usa o DICT para resolver a chave do destinatário, obtendo instituição, agência e conta, e depois usa o SPI para liquidar a transferência. Instituições participantes diretas do Pix precisam manter conectividade certificada com ambos os sistemas via RSFN.

O que é necessário para uma empresa não regulada oferecer serviços financeiros no Brasil?

Uma empresa sem licença própria de Instituição de Pagamento ou Instituição Financeira pode operar serviços financeiros utilizando a licença de um parceiro BaaS regulado pelo Banco Central. Nesse modelo, toda a responsabilidade regulatória, como KYC, AML, relatórios ao Banco Central e segregação de saldo dos clientes finais, recai sobre o parceiro licenciado. A empresa não regulada acessa os serviços via APIs e oferece os produtos com sua própria marca. Quando a empresa crescer e decidir obter licença própria, pode migrar para um Core Banking mantendo a mesma base tecnológica, sem necessidade de reconstruir a infraestrutura.

Quais relatórios regulatórios uma IP precisa enviar ao Banco Central e como automatizá-los?

Instituições de Pagamento com contas individualizadas precisam enviar, entre outros, CCS, CADOCs, COSIF, DIMP, SCR e DES-IF. Todos esses reportes são transmitidos via RSFN com formatos e periodicidades definidos pelo Banco Central. A automação é feita por meio de módulos de compliance integrados ao Core Banking, que coletam dados transacionais em tempo real, geram os arquivos nos formatos exigidos e os transmitem automaticamente nos prazos regulatórios, eliminando processos manuais e reduzindo o risco de inconsistências.

Como o Open Finance impacta a arquitetura técnica de uma plataforma BaaS?

O Open Finance exige que a plataforma implemente APIs padronizadas pelo Banco Central para compartilhamento de dados cadastrais, transacionais e de produtos, além de iniciação de pagamentos, todas protegidas pelo padrão FAPI com OAuth 2.0 e mTLS. Isso implica adicionar um servidor de autorização compatível com FAPI, um módulo de gestão de consentimentos com ciclo de vida auditável, que inclui criação, uso, revogação e expiração, e endpoints de dados que respeitem os schemas definidos pelo Banco Central. A plataforma também precisa registrar-se no Diretório de Participantes do Open Finance e manter certificados digitais atualizados. Para empresas que atuam como receptoras de dados, o impacto é menor, enquanto para as que transmitem dados ou iniciam pagamentos o esforço de implementação é maior e requer atualização contínua conforme novas fases e versões de API são publicadas.

Quanto tempo leva para integrar uma solução BaaS e começar a operar?

O prazo varia conforme a complexidade da operação e a qualidade da documentação do provedor. Com APIs bem documentadas, SDKs disponíveis e ambiente de sandbox, integrações simples, como conta digital com Pix, podem ser concluídas em dias. Operações mais complexas, que envolvem cartão, Open Finance, relatórios regulatórios e migração de base de clientes existente, podem levar de semanas a alguns meses. O fator determinante é a disponibilidade da equipe de engenharia do cliente e a clareza dos requisitos de negócio, e provedores que oferecem suporte técnico especializado durante a integração reduzem significativamente esse prazo.

Conclusão: escolha de infraestrutura moderna e regulada

O stack tecnológico para BaaS no Brasil não é opcional em nenhuma de suas camadas, porque conectividade com SPI e DICT, APIs para Pix em padrão ISO 20022, Open Finance com FAPI, automação de relatórios regulatórios, KYC e AML integrados e infraestrutura cloud-nativa com observabilidade são requisitos de operação, não de diferenciação. A diferenciação está na qualidade da implementação, na latência das APIs, na cobertura dos relatórios automatizados, na velocidade de onboarding e na capacidade de evoluir o stack conforme o Banco Central publica novas normas.

Empresas que tentam construir esse stack internamente enfrentam anos de desenvolvimento, alto custo de manutenção regulatória e risco de descontinuidade tecnológica. A alternativa é partir de uma infraestrutura já certificada, conectada e em produção, que permita focar no desenvolvimento de produto e na experiência do cliente final.