The cost of choosing wrong
There is a recurring pattern in fintechs that grew quickly and then stalled: at some point, the banking infrastructure chosen at the beginning — quick to sign up for, easy to implement, with an attractive price — became the main product bottleneck.
The app cannot launch a feature because the partner's API does not support it. The volume grew, and the cost per transaction made the operation unviable. An incident at the partner's end took the service down for hours — and the fintech had neither visibility nor control to take action. The regulation changed, and the provider took months to adapt.
These scenarios share a common cause: the infrastructure was chosen based on what was needed at the moment of launch, without considering what would be needed two or three years later. And the cost of migrating — in terms of time, operational risk, and capital — is high enough that many fintechs stay trapped longer than they should in an infrastructure that no longer serves them.
This article is a strategic evaluation guide. It is not an implementation tutorial — it is a map of the layers that make up the banking infrastructure, what to evaluate in each one, and the questions that need to be answered before signing any contract with any provider.
If you are still deciding between building your own infrastructure, using BaaS, or opting for a white label model, the article Banking as a Service: what it is, how it works, and when it is worth it covers this decision before reaching the detailed infrastructure level discussed here.
As seis camadas da infraestrutura bancária
The infrastructure of a digital financial operation is not a single system — it is a set of interdependent layers, each with specific responsibilities and its own evaluation criteria. Understanding the role of each layer is the prerequisite for any vendor evaluation process.
Layer 1 — Core Banking: the foundation
Core banking is the central system that processes all financial operations: account creation, balance movements, application of product rules, transaction recording, and reporting. Everything goes through the core.
The choice of core banking is the hardest to reverse because the entire data structure of the operation — accounts, transaction history, product configurations — lives within it. Migrating from one core banking system to another in production, without impacting customers, is one of the most complex and risky projects in a financial operation.
What to evaluate:
The first relevant distinction is the architecture: legacy systems (mainframe, batch processing) versus cloud-native (microservices, real-time, open APIs). For fintechs and digital banks, a cloud-native core is now the standard — but "cloud-native" has become a marketing term that needs to be verified in practice.
Questions that reveal the reality behind the pitch: does the system process transactions in real-time or in batch? Are the APIs RESTful with complete documentation and a functional sandbox? Can the configuration of new financial products be done by the fintech's team — without opening a ticket for the vendor? Who are the three largest clients with a profile similar to yours who are in production today?
Data portability deserves special attention. In any evaluation process, ask explicitly: if we need to migrate to another core, what is the data export process like? In what format? What is the cost? The answer to this question reveals a lot about the vendor's stance on lock-in.
For a specific deep dive into core banking — architectures, evaluation criteria, and common mistakes — the article Core Banking: o que é e como escolher a plataforma certa para sua fintech covers this topic in greater detail.
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
Banking infrastructure is not the product the customer sees — but it is what determines what is possible to build, at what speed, at what cost, and with what level of risk.
Fintechs that treat infrastructure as a technical decision — delegated entirely to the engineering team with little product, compliance, and financial involvement — tend to find out too late that the choices made at the beginning created a ceiling for what they can build in the future.
The right questions, asked before hiring, don't guarantee the choice will be perfect. But they do ensure that known limitations are consciously accepted — not discovered under pressure when the cost of changing is already too high.
Related readings
→ Banking as a Service: what it is, how it works, and when it is worth it
→ Core Banking: what it is and how to choose the right platform for your fintech
→ BaaS vs. Embedded Finance vs. White Label: which model to choose for your fintech
