Como integrar Banking as a Service via API no Brasil

Última atualização: 12 de julho de 2026

Principais lições deste artigo

• Integrar Banking as a Service via API no Brasil exige coordenar arquitetura técnica, conformidade regulatória e escolha de provedor.

• A Resolução Conjunta nº 16/2025 define responsabilidades, exige transparência ao cliente final e estabelece prazo de adequação até dezembro de 2026.

• O fluxo técnico padrão inclui autenticação OAuth2, abertura de contas, Pix, webhooks e emissão de cartões com segurança TLS 1.2+ e, quando necessário, mTLS.

• Boas práticas de segurança, compliance e critérios claros de seleção de provedor reduzem riscos e encurtam o tempo de lançamento.

• Com a Celcoin você acessa infraestrutura completa e licenças regulatórias para lançar serviços financeiros em semanas; conheça a solução completa.

1. O que é Banking as a Service e por que integrações via API importam no Brasil

Banking as a Service é o modelo em que uma instituição financeira autorizada disponibiliza sua infraestrutura regulatória e tecnológica via APIs para que terceiros ofereçam serviços bancários com marca própria. Apenas bancos e instituições de pagamento autorizadas pelo Banco Central podem prestar serviços financeiros nesse modelo, mesmo quando os serviços aparecem em plataformas de empresas não financeiras.

No Brasil, o Banking as a Service ganha relevância por causa da regulação de Open Finance, da alta penetração do Pix e da diversificação das fintechs. Esse contexto torna o país um dos mercados mais atrativos da América Latina para adoção do modelo. Para ERPs, varejistas e plataformas B2B, a integração via API dispensa licença própria e reduz o tempo de lançamento de produtos financeiros de meses para semanas.

As fintechs concentram boa parte da demanda por Banking as a Service no Brasil, mas o modelo já se consolida em segmentos como varejo, SaaS B2B e marketplaces.

2. Requisitos regulatórios do Bacen, LGPD e Open Finance em 2026

A Resolução Conjunta nº 16/2025 é o marco regulatório central do Banking as a Service no Brasil em 2026. Seus pontos principais são:

• A entidade tomadora de serviços de BaaS pode contratar serviços de apenas uma instituição prestadora, que permanece como única responsável perante o Banco Central por todas as obrigações regulatórias.

• A instituição prestadora deve aparecer de forma clara em todos os canais voltados ao cliente final, como contratos, boletos, cartões e comprovantes. O modelo white-label que oculta a instituição licenciada é proibido.

• Os serviços regulados pelo Art. 4º abrangem abertura, manutenção e encerramento de contas de depósito e pagamento, serviços de pagamento, credenciamento de instrumentos de pagamento e operações de crédito.

• Todas as operações de BaaS devem estar em conformidade com a resolução até 31 de dezembro de 2026, sob risco de suspensão.

• Contratos entre prestadora e tomadora devem detalhar funções, critérios de segurança, responsabilidades, remuneração e arranjos de compartilhamento de dados.

Além da Resolução Conjunta nº 16/2025, a operação de Banking as a Service precisa seguir a LGPD, controles de segurança da informação, procedimentos de KYC e regras de PLD-FT. Para empresas que participam do ecossistema de Open Finance, as normas do Banco Central sobre acesso e transmissão de dados financeiros com consentimento do usuário valem desde o início da operação.

Para atuar como provedor full-stack de Banking as a Service, a empresa precisa de autorização do Banco Central do Brasil como instituição de pagamento ou financeira, com capital mínimo atualizado entre R$ 9,2 milhões e R$ 12,4 milhões para IPs conforme normas de 2025.

3. Fluxo técnico de integração: OAuth2, contas, Pix e webhooks com exemplos

A integração técnica de Banking as a Service via API segue uma sequência de etapas. O fluxo padrão recomendado para 2026 inclui:

1. Autenticação OAuth2: solicitar um access token ao servidor de autorização do provedor de Banking as a Service usando o fluxo Client Credentials (grant_type=client_credentials). O token deve ter tempo de vida curto, entre 300 e 900 segundos, para reduzir a janela de risco em caso de comprometimento de credenciais.

2. Abertura de conta digital: enviar requisição POST ao endpoint de onboarding com dados de KYC do usuário final, como CPF ou CNPJ, nome, endereço e documento. O provedor executa as validações regulatórias e retorna o identificador da conta.

3. Geração de chave Pix e QR Code: registrar a chave Pix associada à conta criada e gerar cobranças via API para Pix, usando o endpoint de cobrança imediata ou com vencimento, conforme o padrão do Banco Central.

4. Configuração de webhooks: registrar a URL de callback no provedor para receber notificações assíncronas de eventos como pix_recebido, transferencia_concluida e conta_bloqueada. O endpoint receptor deve validar a assinatura HMAC ou o certificado mTLS enviado pelo provedor antes de processar o payload.

5. Emissão de cartão, quando aplicável: acionar o endpoint de emissão com dados do portador e tipo de cartão, pré-pago ou pós-pago. O provedor retorna o PAN tokenizado e os dados para embossing físico ou provisionamento virtual.

Do ponto de vista de segurança de transporte, todas as comunicações de API em ambientes financeiros regulados devem usar TLS 1.2 ou superior, com gestão completa do ciclo de vida dos certificados, incluindo emissão, rotação e revogação. Em cenários críticos, o mTLS adiciona uma camada de confiança mútua entre sistemas.

Credenciais de API precisam ficar em cofres de segredos dedicados, como AWS Secrets Manager ou HashiCorp Vault, com controles de acesso, rotação e monitoramento contínuo. Chaves estáticas sem expiração representam risco elevado e devem ser evitadas em integrações financeiras.

4. Boas práticas de segurança, compliance e critérios para escolher provedores

A segurança de APIs financeiras exige controles além da autenticação. Em 2025, 87% das organizações relataram ao menos um incidente de segurança relacionado a APIs, com crescimento médio diário de ataques de 113% em relação ao ano anterior. As práticas essenciais para integrações de Banking as a Service incluem:

• API Gateway dedicado: centralizar autenticação, autorização, rate limiting, gestão de tráfego e logging detalhado.

• Proteção contra abuso: aplicar controles baseados em IP, identidade do cliente, token e criticidade do endpoint.

• Minimização de dados: seguir a LGPD, trafegando apenas dados estritamente necessários, com acesso restrito e trilhas de auditoria.

• Controles para cartão: aplicar requisitos do PCI DSS, como criptografia, segmentação de ambiente e testes periódicos.

• Segurança no ciclo de desenvolvimento: incluir revisão de requisitos, testes de segurança, validação de dependências e remediação contínua.

Os critérios decisivos para avaliar um provedor de Banking as a Service começam pela base regulatória, com robustez perante o Banco Central e histórico de conformidade. Em seguida, a qualidade técnica se torna central, com APIs estáveis, documentação com SDKs e exemplos práticos para desenvolvedores, além de modelo de segurança com criptografia adequada.

A camada de produto complementa essa análise, com flexibilidade de funcionalidades, capacidade de personalização de jornada e escalabilidade para crescimento de volume. Por fim, o suporte operacional, com SLA, governança de incidentes e capacidade de resposta técnica, define a viabilidade de longo prazo da parceria. Essas dimensões ajudam a comparar provedores de forma estruturada.

A tabela a seguir apresenta dimensões de avaliação para orientar a seleção de infraestrutura de Banking as a Service:

Dimensão	O que avaliar	Sinal positivo	Sinal de alerta
Licença regulatória	Autorização do Banco Central, IP ou IF	Licença ativa e pública no site do Bacen	Operação via terceiro não identificado
Qualidade das APIs	Documentação, sandbox, SDKs e estabilidade	Sandbox disponível e changelog público	Documentação desatualizada ou inexistente
Segurança	OAuth2, mTLS, criptografia TLS 1.2+, PCI DSS	Certificações auditadas e publicadas	Chaves estáticas e ausência de mTLS
Escalabilidade e SLA	Uptime, suporte técnico e capacidade transacional	SLA de 99,9% ou mais e suporte especializado	SLA genérico e suporte apenas por e-mail

Descubra essa solução completa para fintechs, bancos digitais, gestoras de fundos, varejistas e ERPs.

5. Erros comuns, riscos e aplicações por perfil de empresa

Os erros mais frequentes em integrações de Banking as a Service no Brasil costumam surgir antes do desenvolvimento. Entre os principais estão escolher o provedor mais moderno sem ter equipe capaz de consumir APIs financeiras, não modelar custos na escala projetada, tratar a decisão de infraestrutura como permanente sem calcular custos de reversão e excluir compliance e jurídico do início da discussão.

Por perfil de empresa, os riscos e prioridades mudam:

• Fintechs e bancos digitais em estágio inicial: o risco principal é subestimar o tempo de integração. Implementações de Banking as a Service no Brasil tipicamente levam de 2 a 6 meses até o lançamento. A prioridade é contar com sandbox funcional e suporte técnico consultivo.

• ERPs: o desafio é integrar serviços financeiros a sistemas legados sem afetar a estabilidade do produto principal. APIs modulares e bem documentadas reduzem retrabalho.

• Varejistas: a monetização depende de uso recorrente dos serviços financeiros. Empresas muitas vezes subestimam custos de emissão, manutenção, suporte e operação, que precisam ser compensados por um plano claro de monetização.

• Empresas em crescimento acelerado: gargalos comuns incluem retrabalho manual, atrasos técnicos no lançamento de novos produtos, falta de visibilidade por sistemas desconectados e falhas de compliance durante fases de expansão.

Um ponto crítico para 2026 é a restrição de nomenclatura já mencionada para termos como Banco, Bank e Banking. Empresas que planejam usar esses termos em sua marca precisam verificar sua situação regulatória antes de contratar um provedor.

Celcoin: infraestrutura full stack para toda a jornada de serviços financeiros

A Celcoin opera com portfólio completo de licenças e tecnologia proprietária, oferecendo APIs modulares para que empresas provejam serviços bancários completos, de contas digitais e cartões até liquidação, compliance e relatórios regulatórios. Fintechs, bancos digitais, ERPs e varejistas podem começar usando as licenças da Celcoin no modelo Banking as a Service e, depois, migrar para suas próprias licenças com o Core Banking, mantendo a mesma base tecnológica. A Celcoin processa mais de R$ 30 bilhões em transações por mês e atende mais de 6 mil clientes.

A Celcoin não oferece empréstimo direto para consumidores. A Celcoin fornece infraestrutura tecnológica para que empresas ofereçam produtos de crédito aos próprios clientes.

A Celcoin estrutura sua oferta em alguns pilares principais:

• APIs modulares: integrações mais rápidas reduzem custos e prazos de desenvolvimento.

• Experiência do desenvolvedor: documentação, SDKs e sandboxes encurtam ciclos de integração e diminuem esforço de engenharia.

• Lançamento rápido: módulos pré-construídos e entrega via SaaS aceleram lançamentos e antecipam geração de receita.

• Distribuição white-label e embutida: suporte a produtos financeiros com marca própria em jornadas digitais existentes.

• Escalabilidade em nuvem: alta disponibilidade e capacidade de escalar mantêm serviços estáveis mesmo em volumes elevados.

• Pagamentos e crédito: cobertura de diversas formas de pagamento e emissão de crédito aumenta conversão, ARPU e fidelização.

• Acesso a dados: dados e análises com Open Finance permitem ofertas personalizadas e melhoram conversão e retenção.

• Compliance integrado: KYC, AML e relatórios regulatórios embutidos reduzem risco e aceleram ciclos de vendas.

• Prevenção a fraude: monitoramento com IA e autenticação robusta reduzem estornos, perdas e exposição regulatória.

• Ecossistema de parceiros: parcerias com bancos, redes e fintechs ampliam cobertura, recursos e velocidade de entrada no mercado.

Descubra essa solução completa para fintechs, bancos digitais, gestoras de fundos, varejistas e ERPs.

Perguntas frequentes

O que é necessário para integrar Banking as a Service via API no Brasil sem ter licença própria?

Uma empresa sem licença própria pode operar serviços financeiros ao contratar um provedor de Banking as a Service que seja uma instituição de pagamento ou instituição financeira autorizada pelo Banco Central. Nesse modelo, o provedor assume as obrigações regulatórias perante o Bacen, enquanto a empresa contratante responde pela oferta do produto ao cliente final, pela comunicação, pela resolução de problemas e pelo tratamento de dados conforme a LGPD. A integração técnica ocorre via APIs REST com autenticação OAuth2, e a instituição prestadora deve aparecer de forma clara em todos os canais voltados ao usuário final, como exige a Resolução Conjunta nº 16/2025.

Qual é a diferença entre Banking as a Service e Core Banking?

Banking as a Service é o modelo em que uma empresa sem licença própria usa a infraestrutura regulatória e tecnológica de um provedor autorizado para oferecer serviços financeiros. Core Banking é a infraestrutura bancária completa destinada a empresas que já possuem ou estão obtendo licenças regulatórias. No Core Banking, a empresa integra sua própria licença à plataforma tecnológica do provedor, mantém controle total sobre a operação e cumpre diretamente as obrigações regulatórias perante o Banco Central. A Celcoin oferece ambos os modelos, o que permite iniciar no Banking as a Service e migrar para o Core Banking sem trocar de infraestrutura.

Como funcionam os webhooks para Pix em integrações de Banking as a Service?

Webhooks para Pix são notificações HTTP que o provedor de Banking as a Service envia ao endpoint configurado pela empresa contratante sempre que ocorre um evento relevante, como recebimento de Pix, devolução ou falha de transação. O endpoint receptor deve estar disponível via HTTPS com TLS 1.2 ou superior e validar a autenticidade da notificação por meio de assinatura HMAC ou certificado mTLS, conforme o padrão do provedor. O payload segue o formato JSON com dados da transação, chave Pix, valor, horário e identificador único. A empresa deve responder com HTTP 200 em poucos segundos para confirmar o recebimento, e o provedor deve reenviar notificações em caso de falha, seguindo a política de retry definida no SLA.

Quais obrigações regulatórias a empresa contratante de Banking as a Service precisa cumprir diretamente?

Mesmo usando a licença do provedor, a empresa contratante mantém responsabilidades diretas. Ela deve garantir que os contratos com o provedor detalhem funções, critérios de segurança, responsabilidades e arranjos de compartilhamento de dados, como exige a Resolução Conjunta nº 16/2025. Internamente, precisa estruturar processos de KYC para onboarding de clientes, políticas de PLD-FT, controles de segurança da informação e conformidade com a LGPD no tratamento de dados dos usuários finais. A empresa também responde pela comunicação transparente com o cliente final sobre qual instituição financeira é responsável pelas operações. Falhas nessas obrigações expõem tanto o provedor quanto a empresa contratante a sanções administrativas do Banco Central.

Quanto tempo leva para integrar Banking as a Service via API e lançar um produto financeiro no Brasil?

O tempo de integração varia conforme a complexidade do produto, a maturidade técnica da equipe e a qualidade da documentação do provedor. Implementações de Banking as a Service normalmente levam de 2 a 6 meses até o lançamento completo. Empresas com equipes técnicas experientes e provedores com sandbox funcional, SDKs e documentação detalhada conseguem reduzir esse prazo. Um MVP com conta digital, Pix e boleto pode ser lançado em poucas semanas quando o provedor oferece módulos pré-construídos e suporte técnico consultivo durante a integração.

Conclusão

Integrar Banking as a Service via API no Brasil em 2026 exige planejamento em cinco frentes: entender o modelo, mapear requisitos regulatórios, executar o fluxo técnico, aplicar boas práticas de segurança e alinhar a solução ao perfil da empresa. A Resolução Conjunta nº 16/2025 estabelece regras claras sobre responsabilidades, transparência e prazo de adequação até dezembro de 2026. Provedores com licença ativa, APIs bem documentadas, suporte técnico especializado e capacidade de acompanhar o crescimento da empresa, do Banking as a Service ao Core Banking, reduzem o risco regulatório e o tempo de lançamento de produtos financeiros regulados.