Guia: tecnologias usadas em Banking as a Service no Brasil

Última atualização: 18 de agosto de 2026

Principais lições deste artigo

• Tomar decisões de build vs buy em BaaS exige conhecer o stack regulado brasileiro, incluindo APIs REST, OAuth 2.0, mTLS, DICT, SPI, Open Finance, Kafka, ledger de partidas dobradas e controles de segurança.

• Banking as a Service permite que uma empresa não regulada acesse licenças, APIs, compliance e liquidação por meio de um parceiro autorizado pelo Banco Central, enquanto o Core Banking também atende instituições com licença própria.

• Uma operação BaaS regulada no Brasil depende de componentes como APIs REST, Pix (SPI e DICT), Open Finance, ledger de partidas dobradas em PostgreSQL e compliance com KYC, AML, COAF e relatórios regulatórios.

• Uma arquitetura recomendada segue oito etapas claras: autenticação OAuth 2.0, KYC e AML, abertura de contas com ledger individualizado, integração Pix, registro atômico, jornada de consentimento, segurança em camadas e reconciliação automatizada.

• Para implementar uma solução completa de BaaS e Core Banking no Brasil, conheça a plataforma da Celcoin.

O que é Banking as a Service e seus componentes essenciais

Banking as a Service (BaaS) é o modelo em que uma empresa não regulada acessa infraestrutura bancária completa, com licenças, APIs, compliance e liquidação, por meio de um parceiro autorizado pelo Banco Central. O Core Banking representa a evolução desse modelo e atende tanto empresas que operam sob licença de terceiros quanto instituições que já possuem Instituição de Pagamento (IP) ou Instituição Financeira (IF) própria.

Uma operação BaaS regulada no Brasil depende de alguns componentes essenciais.

• APIs REST: interface de integração modular entre a plataforma BaaS e os sistemas do cliente, permitindo orquestrar jornadas de conta, pagamento e crédito.

• Pix: meio de pagamento instantâneo operado pelo Banco Central, que exige participação direta ou indireta no SPI e integração ao DICT para validação de chaves.

• Open Finance: ecossistema regulado de compartilhamento de dados financeiros com consentimento do usuário, com regras de segurança, UX e escopos definidos pelo Banco Central.

• Ledger de partidas dobradas: registro contábil imutável em que cada movimentação gera ao menos dois lançamentos com soma zero, o que garante integridade financeira e rastreabilidade.

• Compliance: conjunto de obrigações regulatórias perante Banco Central, Receita Federal e SUSEP, incluindo KYC, AML, COAF e relatórios como DIMP, CADOCs e CCS.

Como o ecossistema funciona na prática

Autenticar e transportar dados com segurança. A comunicação com plataformas BaaS como a Nuvende utiliza OAuth 2.0 com fluxo client_credentials via client_id e secret, combinado com assinatura HMAC, sem exigir mTLS em todos os cenários. O perfil de segurança FAPI v2.2.1 do Open Finance Brasil define o uso de Pushed Authorization Requests (PAR), assinaturas JWS com algoritmo PS256 e criptografia JWE com RSA-OAEP e A256GCM. Tokens de acesso em plataformas BaaS costumam ter validade de 3600 segundos.

Integrar Pix e DICT. Uma fintech que deseja ser participante direto do Pix precisa de autorização do Banco Central como IP, conforme a Lei nº 12.865/2013. Um participante indireto opera sob a infraestrutura de um participante direto. O DICT é consultado a cada transação para validar chaves e reduzir risco de fraude. Participantes diretos do Pix devem cumprir requisitos de disponibilidade definidos pela regulamentação do Banco Central.

Conduzir a jornada de consentimento do Open Finance. O perfil FAPI v2.2.1 define escopos de consentimento dinâmicos no formato consent:{ConsentResourceId}. As APIs de compartilhamento de dados exigem autenticação LoA2, com fator único, enquanto as APIs de iniciação de pagamento exigem LoA3, com autenticação multifator. O widget de jornada precisa seguir o Guia UX do Banco Central para garantir experiência padronizada.

Orquestrar microsserviços com Kafka. Em arquiteturas event-driven, produtores publicam eventos de domínio e consumidores reagem de forma assíncrona. Esse modelo desacopla o fluxo de pagamentos de processos como monitoramento de fraude, screening de sanções e comunicações. O padrão Outbox garante que a gravação no banco de dados e a publicação no Kafka ocorram na mesma transação, o que evita perda de eventos.

Manter um ledger de partidas dobradas em PostgreSQL. Cada transação gera ao menos dois lançamentos cujos valores somam exatamente zero. O ledger segue o modelo append-only, em que correções ocorrem por novos lançamentos de estorno e não por edição de registros anteriores. Os saldos são derivados por projeção sobre o journal imutável. Valores são armazenados como inteiros em unidades menores, como centavos, para evitar problemas de ponto flutuante.

Proteger a operação com KMS e WAF. Um Key Management Service (KMS) gerencia chaves criptográficas com rotação automática. Um Web Application Firewall (WAF) filtra requisições maliciosas antes de atingir as APIs. Instituições autorizadas precisam manter processos de resposta a incidentes de segurança cibernética alinhados à regulamentação do Banco Central.

Arquitetura recomendada em oito etapas

Uma arquitetura em oito etapas organiza a operação BaaS regulada no Brasil da autenticação à reconciliação contábil.

1. Autenticação OAuth 2.0. O cliente solicita um token usando o fluxo client_credentials. O servidor emite um access token com validade de 3600 segundos em média e registra o evento de autenticação.

   // Kotlin, requisição de token val client = OkHttpClient.Builder().build() val request = Request.Builder() .url("https://auth.parceiro.com.br/oauth/token") .post( FormBody.Builder() .add("grant_type", "client_credentials") .add("scope", "payments accounts") .build() ) .build() val response = client.newCall(request).execute()

2. Validação de identidade (KYC e AML). O serviço de onboarding consulta bases externas, como Receita Federal e bureaus de crédito, e registra o resultado no banco de dados com status APROVADO, PENDENTE ou REPROVADO. Operações com valores atípicos passam por monitoramento e são reportadas ao COAF conforme normas do Banco Central.

3. Abertura de conta com ledger individualizado. Cada conta recebe um conjunto próprio de contas contábeis de ativo, passivo e receita no PostgreSQL. Recursos de clientes permanecem segregados do patrimônio da instituição, em linha com as normas do Banco Central.

   -- SQL, criação de contas contábeis individualizadas INSERT INTO ledger_accounts (account_id, owner_id, type, currency) VALUES (gen_random_uuid(), :ownerId, 'ASSET', 'BRL'), (gen_random_uuid(), :ownerId, 'LIABILITY', 'BRL');

4. Integração ao DICT e ao SPI para Pix. Antes de cada transação Pix, o serviço consulta o DICT para validar a chave do destinatário. A instrução de pagamento segue para o SPI via RSFN com mensagem ISO 20022. O participante direto precisa cumprir os requisitos de disponibilidade definidos pelo Banco Central.

5. Registro atômico no ledger com partidas dobradas. A gravação do evento de pagamento, os lançamentos contábeis e a publicação no Kafka ocorrem em uma única transação ACID. Se qualquer etapa falhar, a operação inteira é revertida.

   // Java, lançamento de partidas dobradas @Transactional public void postTransfer( UUID fromAccount, UUID toAccount, long amountMinor, String idempotencyKey ) { journalRepo.insert(new Entry(fromAccount, amountMinor, "D", idempotencyKey)); journalRepo.insert(new Entry(toAccount, amountMinor, "C", idempotencyKey)); eventPublisher.publish(new TransferPosted(fromAccount, toAccount, amountMinor)); }

6. Jornada de consentimento Open Finance. O Authorization Server emite o escopo consent:{id} após autenticação LoA3 para pagamentos. O widget segue o Guia UX do Banco Central. Tokens de consentimento são armazenados com prazo de expiração definido e trilha de auditoria para revogação.

7. Segurança em camadas com WAF, KMS e monitoramento. O WAF inspeciona cada requisição antes de atingir as APIs. O KMS gerencia chaves de criptografia com rotação automática. Um sistema de monitoramento com análise em tempo real identifica padrões suspeitos de transação e apoia a prevenção a fraudes.

   // Diagrama Mermaid, fluxo de segurança sequenceDiagram participant C as Cliente participant W as WAF participant A as API Gateway participant K as KMS participant S as Serviço de Pagamento C->>W: Requisição HTTPS + mTLS W->>A: Requisição validada A->>K: Solicita chave de descriptografia K-->>A: Chave retornada A->>S: Payload descriptografado S-->>C: Resposta assinada (PS256)

8. Reconciliação automatizada e relatórios regulatórios. Um job noturno compara o ledger com o relatório de liquidação do processador, registra divergências sem correção automática e aciona o time de operações. Relatórios como DIMP, CADOCs e CCS são gerados e enviados automaticamente à RSFN.

Implementar essa arquitetura completa exige equipe técnica especializada e atualização contínua de conformidade regulatória. Veja como a Celcoin implementa essa arquitetura em produção e reduz a necessidade de construir toda essa infraestrutura internamente.

Panorama regulatório atualizado até agosto de 2026

O ambiente regulatório brasileiro para BaaS se organiza em três eixos principais de obrigação.

Banco Central. IPs autorizadas precisam manter conexão direta à RSFN e ao SPB, enviar relatórios periódicos como CCS, CADOCs, COSIF, DIMP, DES-IF, SCR e PR e seguir as normas de segurança cibernética do Banco Central. Recursos de clientes em contas de pagamento permanecem segregados do patrimônio da instituição. Operações Pix com valores atípicos exigem monitoramento automatizado e reporte ao COAF, com registros mantidos por pelo menos cinco anos. Penalidades por descumprimento incluem multas, suspensão e cassação de autorização.

Receita Federal. IPs e Sociedades de Crédito Direto (SCDs) cumprem obrigações acessórias fiscais específicas, incluindo DIMP e obrigações junto às Secretarias de Fazenda estaduais, com atenção especial para instituições sediadas no município de São Paulo.

SUSEP. Empresas que atuam no ecossistema de Open Insurance seguem resoluções da SUSEP para compartilhamento de dados de seguros, integração de pagamentos via Pix e conformidade com a LGPD.

Boas práticas de avaliação de parceiros e erros comuns

Avaliar um parceiro de BaaS ou Core Banking com critérios técnicos claros reduz risco operacional e regulatório.

• Participação direta no SPI e no DICT, com disponibilidade documentada conforme requisitos regulatórios, o que garante processamento de Pix sem intermediários adicionais.

• APIs REST com documentação completa, SDKs e ambiente sandbox disponível para testes antes da contratação, permitindo validar a integração antes de alocar recursos de engenharia.

• Ledger de partidas dobradas com segregação de recursos por cliente, sem uso de contas-bolsão, o que assegura conformidade com as exigências do Banco Central para segregação patrimonial.

• Geração e envio automatizados de relatórios regulatórios como DIMP, CADOCs, CCS e SCR, reduzindo risco de erro manual e atraso em obrigações.

• Suporte ao perfil FAPI v2.2.1 para Open Finance, com PAR, LoA3 e escopos de consentimento dinâmicos, o que evita retrabalho quando novos manuais entram em vigor.

• Medidas documentadas de resposta a incidentes cibernéticos alinhadas à regulamentação do Banco Central, com planos de contingência e comunicação.

• Modelo de remuneração baseado em transações, sem custo de setup proibitivo, o que facilita entrada no mercado e ajuste de custos ao volume.

Evitar erros recorrentes em operações BaaS protege a empresa de sanções e retrabalho técnico.

• Usar contas-bolsão. Misturar recursos de clientes com o patrimônio da instituição é irregular e tende a ser vedado pelas normativas do Banco Central. Manter um ledger individualizado por cliente é a forma correta de registrar saldos.

• Não segregar liquidez. Deixar recursos de clientes em ativos de baixa liquidez aumenta risco regulatório e de solvência, especialmente em cenários de estresse de mercado.

• Gerar relatórios de forma manual. Produzir DIMP, CADOCs e CCS manualmente eleva a chance de erro, atraso e penalidades do Banco Central, além de consumir tempo da equipe.

• Subestimar o Open Finance. Implementar apenas o compartilhamento de dados sem suportar a jornada de consentimento LoA3 para pagamentos gera não conformidade com o manual 7.0/2025 e exige refatorações posteriores.

• Usar ponto flutuante no ledger. Armazenar valores monetários em tipos float ou double provoca deriva de centavos em reconciliações de alto volume e dificulta auditorias.

Adequar a estratégia ao perfil da empresa orienta a escolha de parceiro e arquitetura.

• Fintech early-stage. Priorizar BaaS com licença do parceiro para entrada rápida no mercado e escolher infraestrutura que permita migrar para licença própria sem trocar o stack.

• Varejista. Focar em APIs para Pix, cartão white label e Open Finance para personalizar ofertas e avaliar integração com sistemas de gestão existentes.

• ERP. Buscar APIs modulares que se encaixem na plataforma de gestão sem reescrever lógica de negócio e priorizar relatórios regulatórios automatizados para os clientes do ERP.

Esses critérios também servem como checklist para comparar fornecedores. Avalie o banking da Celcoin usando esses pontos técnicos e verifique o encaixe com a sua operação.

Tabela institucional 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 mensais e atendendo mais de 6 mil clientes, incluindo fintechs, bancos digitais, ERPs e varejistas. A solução full stack abrange BaaS para empresas não reguladas e Core Banking para instituições com licença própria, mantendo a mesma base tecnológica em toda a jornada de crescimento.

A Celcoin não oferece nenhum tipo de empréstimo para consumidores. A Celcoin fornece a infraestrutura tecnológica para que empresas consigam ofertar produtos de crédito aos seus clientes.

A tabela a seguir resume as principais funcionalidades do banking da Celcoin e os benefícios diretos para a sua operação.

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 que 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.
Escalabilidade com confiabilidade	Solução com alta disponibilidade e escalável na nuvem mantém serviços funcionando em altos volumes e protege a receita.
Cobertura de diversas possibilidades de pagamentos, incluindo crédito	Oferecer 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.

Perguntas frequentes

Qual a diferença entre Banking as a Service e Core Banking no contexto regulatório brasileiro?

A diferença principal está na licença usada na operação. No BaaS, a empresa atua sob a licença do parceiro e consome serviços financeiros por meio das APIs desse parceiro. No Core Banking, a instituição integra sua própria licença IP ou IF à infraestrutura do parceiro e mantém conformidade com RSFN, SPB e relatórios regulatórios sem precisar construir esse stack internamente. Essa abordagem evita a troca de tecnologia quando a empresa obtém sua licença.

Por que o ledger de partidas dobradas é obrigatório em operações BaaS reguladas no Brasil?

O Banco Central exige que recursos de clientes em contas de pagamento permaneçam segregados do patrimônio da instituição. O ledger de partidas dobradas garante essa segregação de forma auditável, pois cada movimentação gera ao menos dois lançamentos com soma zero e o journal segue o modelo append-only, com correções feitas por novos lançamentos. Qualquer auditor ou regulador consegue reconstruir o saldo de qualquer conta em qualquer momento histórico. Operar com contas-bolsão, misturando recursos de clientes com o patrimônio da instituição, é irregular e tende a ser vedado pelas normativas do Banco Central.

Quais linguagens de programação e tecnologias são mais usadas em BaaS no Brasil em 2026?

O COBOL ainda é a principal linguagem utilizada em backends de instituições financeiras e governos no Brasil, especialmente em projetos legados de grandes bancos. Kotlin cresce como alternativa moderna sobre a JVM, com sintaxe mais concisa e interoperabilidade total com Java. Go (Golang) é adotado em microsserviços cloud-native e ferramentas de infraestrutura. PostgreSQL se consolida como banco de dados relacional predominante para ledgers de partidas dobradas, com suporte a transações ACID, isolamento SERIALIZABLE e constraints de unicidade para idempotência. Kafka é o sistema de mensageria mais usado em arquiteturas event-driven de plataformas de pagamento de alto volume.

Como o Open Finance impacta a decisão de build vs buy para fintechs e ERPs?

Implementar Open Finance internamente exige suporte ao perfil FAPI v2.2.1, gestão de escopos de consentimento dinâmicos, autenticação LoA2 e LoA3, widget de jornada alinhado ao Guia UX do Banco Central, relatórios regulatórios e integração com o diretório de participantes. Cada componente tem custo de desenvolvimento, manutenção e atualização contínua à medida que o Banco Central publica novos manuais. Para a maioria das fintechs early-stage e ERPs, contratar um parceiro que já mantém essa infraestrutura atualizada reduz o tempo de entrada no mercado e o risco regulatório e libera a equipe de engenharia para focar no produto principal.

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

IPs autorizadas pelo Banco Central enviam relatórios como DIMP, CADOCs, CCS, SCR, DES-IF, COSIF e PR, além de cumprir obrigações junto à Receita Federal e, no caso de instituições em São Paulo, à SEFAZ-SP. Automatizar esses relatórios reduz risco de erro manual, garante envio dentro dos prazos regulatórios e diminui o custo operacional de compliance. Plataformas de Core Banking com conexão direta à RSFN e ao SPB conseguem gerar e transmitir esses arquivos automaticamente a partir dos dados registrados no ledger.

Conheça o banking da Celcoin e veja como automatizar essa rotina regulatória.