O custo de escolher errado
Existe um padrão recorrente em fintechs que cresceram rápido e travaram: em algum momento, a infraestrutura bancária escolhida no início — rápida de contratar, fácil de implementar, com preço atraente — virou o principal gargalo de produto.
O aplicativo não consegue lançar uma feature porque a API do parceiro não suporta. O volume cresceu e o custo por transação tornou a operação inviável. Um incidente no parceiro derrubou o serviço por horas — e a fintech não tinha visibilidade nem controle para agir. A regulação mudou e o provedor demorou meses para se adequar.
Esses cenários têm em comum uma causa: a infraestrutura foi escolhida com base no que era necessário no momento do lançamento, sem considerar o que seria necessário dois ou três anos depois. E o custo de migrar — em tempo, risco operacional e capital — é alto o suficiente para que muitas fintechs fiquem presas mais tempo do que deveriam em uma infraestrutura que já não serve.
Este artigo é um guia de avaliação estratégica. Não é um tutorial de implementação — é o mapa das camadas que compõem a infraestrutura bancária, o que avaliar em cada uma e as perguntas que precisam ser respondidas antes de assinar qualquer contrato com qualquer fornecedor.
Se você ainda está decidindo entre construir infraestrutura própria, usar BaaS ou optar por um modelo white label, o artigo Banking as a Service: o que é, como funciona e quando vale a pena cobre essa decisão antes de chegar no nível de infraestrutura detalhado aqui.
As seis camadas da infraestrutura bancária
A infraestrutura de uma operação financeira digital não é um único sistema — é um conjunto de camadas interdependentes, cada uma com responsabilidades específicas e critérios de avaliação próprios. Entender o papel de cada camada é o pré-requisito para qualquer processo de avaliação de fornecedor.
Camada 1 — Core Banking: a fundação
O core banking é o sistema central que processa todas as operações financeiras: criação de contas, movimentação de saldos, aplicação de regras de produto, registro de transações e geração de relatórios. Tudo passa pelo core.
A escolha do core banking é a mais difícil de reverter porque toda a estrutura de dados da operação — contas, histórico de transações, configurações de produto — vive nele. Migrar de um core banking para outro em produção, sem impactar clientes, é um dos projetos mais complexos e arriscados de uma operação financeira.
O que avaliar:
A primeira distinção relevante é a arquitetura: sistemas legados (mainframe, processamento em batch) versus cloud-native (microsserviços, tempo real, APIs abertas). Para fintechs e bancos digitais, o core cloud-native é hoje o padrão — mas "cloud-native" virou um termo de marketing que precisa ser verificado na prática.
Perguntas que revelam a realidade por trás do discurso: o sistema processa transações em tempo real ou em batch? As APIs são RESTful com documentação completa e sandbox funcional? A configuração de novos produtos financeiros pode ser feita pelo time da fintech — sem abrir chamado para o fornecedor? Quais são os três maiores clientes com perfil similar ao seu que estão em produção hoje?
A portabilidade de dados merece atenção especial. Em qualquer processo de avaliação, pergunte explicitamente: se precisarmos migrar para outro core, como é o processo de exportação de dados? Em qual formato? Qual é o custo? A resposta a essa pergunta revela muito sobre a postura do fornecedor em relação ao lock-in.
Para um aprofundamento específico em core banking — arquiteturas, critérios de avaliação e erros comuns — o artigoCore Banking: o que é e como escolher a plataforma certa para sua fintech cobre o tema com mais detalhe.
Camada 2 — APIs e integrações: o que você consegue construir
As APIs são a interface entre a infraestrutura bancária e o produto que o usuário final experimenta. A qualidade das APIs define diretamente o que é possível construir — e o custo de construir.
O que avaliar:
Cobertura funcional: As APIs cobrem todos os produtos que você precisa lançar no go-live e no roadmap de 12 meses? Cada funcionalidade que não está disponível via API vai exigir negociação com o fornecedor, desenvolvimento adicional ou uma gambiarra técnica que vai custar caro mais tarde.
Qualidade da documentação: Documentação desatualizada ou incompleta multiplica o tempo de integração. Antes de contratar, peça acesso ao portal de developers e tente, com o seu time técnico, fazer uma integração básica no sandbox. A experiência do desenvolvedor no sandbox é um proxy confiável da experiência em produção.
Estabilidade e versionamento: APIs que quebram sem aviso ou que forçam migrações urgentes criam custo operacional contínuo. Pergunte qual é a política de versionamento, qual é o prazo de suporte para versões anteriores e com que frequência houve breaking changes nos últimos 12 meses.
Modelo de autenticação e segurança das APIs: OAuth 2.0 com tokens de curta duração é o padrão atual. APIs com autenticação por chave estática ou sem TLS mútuo são sinais de alerta de segurança.
Padrões abertos versus proprietários: APIs construídas sobre padrões abertos (REST, JSON, OAuth) são mais fáceis de integrar, têm mais documentação disponível no mercado e criam menos lock-in do que APIs proprietárias com protocolos específicos do fornecedor.
Camada 3 — Compliance e regulação: a camada que não pode falhar
Compliance não é uma feature opcional — é uma condição de operação. E em uma operação financeira, ele atravessa praticamente todas as outras camadas da infraestrutura.
O que avaliar:
KYC e onboarding regulatório: O processo de validação de identidade dos clientes precisa ser robusto o suficiente para cumprir as exigências do Banco Central e da LGPD, e ágil o suficiente para não prejudicar a conversão no onboarding. Pergunte qual é a taxa de aprovação automática versus revisão manual, qual é o prazo médio de aprovação e como são tratados os casos de borda (documentos com má qualidade, inconsistências cadastrais).
AML e prevenção à lavagem de dinheiro: Os controles de monitoramento de transações suspeitas são de responsabilidade da operação — mesmo no modelo BaaS ou white label, onde o banco licenciado é o responsável regulatório primário. Entenda quais controles estão embutidos na plataforma e quais precisam ser complementados pela fintech.
Relatórios regulatórios: O Banco Central exige uma série de relatórios periódicos das instituições — SCR, BACEN 3040, relatórios de Pix, entre outros. Esses relatórios são gerados automaticamente pela plataforma? Quem é responsável pela submissão? Como as atualizações regulatórias são incorporadas — e qual é o prazo típico?
Responsabilidade regulatória no contrato: No modelo BaaS ou white label, a distribuição de responsabilidade entre o provedor e a fintech precisa estar explicitamente mapeada no contrato. Em caso de incidente regulatório, quem responde perante o BC? Essa questão precisa de análise jurídica especializada — não apenas da leitura do contrato padrão do fornecedor.
Camada 4 — Segurança e identidade: o que protege os dados e as operações
Segurança em uma operação financeira não é apenas proteção contra ataques externos — é a combinação de autenticação robusta, criptografia adequada, gestão de acessos e auditorias periódicas que garantem que apenas as operações corretas acontecem, pelos atores corretos, nas condições corretas.
O que avaliar:
Autenticação forte (MFA): O processo de autenticação dos usuários finais precisa equilibrar segurança e experiência. Autenticação multifator é obrigatória para operações financeiras de maior valor. O suporte a biometria, tokens TOTP e autenticação via dispositivo confiável deve estar disponível na plataforma.
Criptografia de dados em repouso e em trânsito: Dados financeiros e pessoais precisam ser criptografados tanto em armazenamento quanto em transmissão. TLS 1.2 ou superior é o mínimo aceitável para comunicação. Pergunte sobre o modelo de gestão de chaves de criptografia — quem controla as chaves e qual é o processo de rotação.
Gestão de acessos internos: Quem na sua equipe tem acesso a quais dados e operações? O sistema suporta controles de acesso granulares com registro de auditoria? Cada ação sensível precisa ser rastreável para fins de conformidade e investigação de incidentes.
Certificações e auditorias: O fornecedor tem certificação PCI-DSS (para operações com cartão)? Passou por auditoria SOC 2? Realiza pen tests periódicos com relatórios compartilháveis com clientes? A ausência dessas certificações não é necessariamente um bloqueador — mas a presença delas é um sinal de maturidade operacional.
Gestão de incidentes de segurança: Qual é o processo de notificação em caso de incidente de segurança? Qual é o prazo de comunicação à fintech e, se necessário, ao BC e aos usuários afetados? A LGPD exige notificação à ANPD em casos de vazamento de dados pessoais — o fornecedor tem processo para suportar esse fluxo?
Camada 5 — Disponibilidade e operação 24/7: o SLA que importa de verdade
Serviços financeiros não têm horário comercial. Pix opera 24 horas por dia, 365 dias por ano. Um incidente às 23h de uma sexta-feira tem o mesmo impacto — ou mais — do que um incidente no meio de uma terça-feira.
O que avaliar:
SLA contratado versus SLA histórico: O SLA de 99,9% no contrato representa menos de 9 horas de indisponibilidade por ano. Mas o que importa não é apenas o número anual — é a distribuição dessas indisponibilidades. Dez minutos por dia são matematicamente equivalentes a uma janela de 60 horas consecutivas no SLA anual, mas têm impactos completamente diferentes na operação. Peça dados históricos de disponibilidade com granularidade de incidente, não apenas o índice agregado.
Arquitetura de redundância: O fornecedor opera em múltiplas zonas de disponibilidade? Existe failover automático em caso de falha de componente? Como é tratada a degradação parcial — quando alguns serviços ficam indisponíveis mas outros continuam operando?
Janelas de manutenção: Quando e como são realizadas manutenções planejadas? Há comunicação prévia com prazo suficiente? Para operações com obrigações regulatórias de disponibilidade — como participantes diretos do Pix — janelas de manutenção não comunicadas têm consequências específicas com o BC.
Observabilidade para o cliente: A fintech tem acesso a dashboards de status em tempo real? Existe um canal de comunicação dedicado para incidentes? Qual é o SLA de resposta inicial em caso de incidente crítico? Operar sem visibilidade da infraestrutura do parceiro é um dos maiores pontos cegos em uma operação financeira.
On-call e escalada: Como é o processo de suporte fora do horário comercial? Existe uma linha de escalada para incidentes críticos que afetam todos os clientes? Qual é o tempo médio de resolução para incidentes de Severidade 1?
Camada 6 — Observabilidade interna: o que você consegue ver
A observabilidade da sua própria operação — independentemente do que o fornecedor disponibiliza — é a diferença entre gerenciar proativamente e descobrir problemas pelos clientes.
O que avaliar:
Acesso a dados transacionais em tempo real: Você consegue ver, em tempo real, o volume de transações, a taxa de erro, a latência de processamento e os alertas de anomalia? Ou depende do dashboard do fornecedor — que pode ter um atraso de minutos a horas?
Logs e rastreabilidade de transações: Em caso de disputa ou investigação, você consegue reconstruir o histórico completo de uma transação específica — cada etapa, cada sistema envolvido, cada timestamp? A ausência de rastreabilidade completa é um risco operacional e regulatório.
Alertas e monitoramento proativo: Você tem alertas configurados para anomalias — pico de erros, queda de volume, latência acima do threshold — que chegam antes que os clientes comecem a reclamar? O monitoramento reativo (descobrir pelo suporte) é incompatível com o SLA de uma operação financeira séria.
Integração com ferramentas próprias: Os dados da operação são exportáveis para as ferramentas de observabilidade que o seu time já usa — Datadog, Grafana, New Relic, ou equivalentes? Ou você está preso ao portal do fornecedor?
Build vs. Buy vs. Parceiro tecnológico: a decisão de execução
Com as seis camadas mapeadas, a pergunta de execução é: para cada camada, você constrói internamente, contrata um fornecedor especializado ou usa um parceiro tecnológico que abstrai a complexidade?
A resposta raramente é a mesma para todas as camadas. Uma fintech pode construir internamente a camada de produto e experiência do usuário — onde a diferenciação competitiva acontece — enquanto usa fornecedores especializados para compliance, segurança e core banking.
Os critérios que orientam essa decisão em cada camada:
Construir internamente faz sentido quando a camada é fonte de diferenciação competitiva, quando o time tem expertise suficiente para construir com qualidade e quando o custo de construção é menor do que o custo de dependência de fornecedor no longo prazo.
Contratar um fornecedor especializado faz sentido quando a camada é commodity — onde a diferenciação não está no produto, mas na confiabilidade e no compliance — e quando o custo de construção excede o custo de contratação em qualquer horizonte de tempo relevante.
Usar um parceiro tecnológico completo (BaaS ou white label) faz sentido quando o objetivo é lançar rapidamente, quando o time técnico não tem experiência em sistemas financeiros de missão crítica e quando a customização necessária está dentro do escopo que o parceiro oferece.
O modelo híbrido — construir o que diferencia, contratar o que é commodity — é o que a maioria das fintechs maduras opera. O erro mais comum é tentar construir tudo internamente por razões de controle, sem uma análise honesta do custo de oportunidade.
10 perguntas de due diligence técnica para qualquer fornecedor
Independentemente de qual camada ou qual fornecedor está sendo avaliado, estas dez perguntas cobrem os pontos que mais frequentemente revelam problemas que não aparecem nas apresentações comerciais:
Quais são os clientes com perfil similar ao nosso que estão em produção há mais de 12 meses na sua plataforma — e podemos falar com o CTO ou VP de Engenharia de pelo menos dois deles?
Qual foi o maior incidente de disponibilidade dos últimos 12 meses, quanto tempo levou para resolver e como foi a comunicação com os clientes afetados?
Como é o processo de atualização quando o Banco Central publica uma nova regulação ou atualiza uma existente — quem é responsável, qual é o prazo típico e há custo adicional?
O contrato permite exportar todos os dados da nossa operação em formato aberto a qualquer momento, sem custo adicional?
Quem são os engenheiros responsáveis pela plataforma — e qual foi a rotatividade do time técnico nos últimos 12 meses?
Como é o processo de suporte em incidentes Severidade 1 às 2h de um domingo — quem atende, em quanto tempo e com qual capacidade de ação?
Quais são os limites técnicos da plataforma — volume máximo de transações por segundo, número máximo de contas, tamanho máximo de payload — e como esses limites foram testados em produção?
Qual é o roadmap dos próximos 12 meses e como os clientes influenciam as prioridades de desenvolvimento?
Como funciona o processo de pen test e auditoria de segurança — quem realiza, com qual frequência e os relatórios são compartilhados com clientes?
Se precisarmos encerrar o contrato antes do prazo, qual é o processo, qual é o custo e qual é o prazo para devolução completa dos dados?
Conclusão: infraestrutura como decisão estratégica
A infraestrutura bancária não é o produto que o cliente vê — mas é o que determina o que é possível construir, com qual velocidade, a qual custo e com qual nível de risco.
Fintechs que tratam infraestrutura como uma decisão técnica — delegada inteiramente para o time de engenharia, com pouco envolvimento de produto, compliance e financeiro — tendem a descobrir tarde demais que as escolhas feitas no início criaram um teto para o que podem construir no futuro.
As perguntas certas, feitas antes da contratação, não garantem que a escolha será perfeita. Mas garantem que as limitações conhecidas sejam aceitas conscientemente — não descobertas sob pressão, quando o custo de mudar já é alto demais.
Leituras relacionadas
→ Banking as a Service: o que é, como funciona e quando vale a pena
→ Core Banking: o que é e como escolher a plataforma certa para sua fintech
→ BaaS vs. Embedded Finance vs. White Label: qual modelo escolher para sua fintech
