El coste de elegir mal
Existe un patrón recurrente en fintechs que crecieron rápido y se estancaron: en algún momento, la infraestructura bancaria elegida al principio —rápida de contratar, fácil de implementar, con un precio atractivo— se convirtió en el principal cuello de botella del producto.
La aplicación no puede lanzar una funcionalidad porque la API del socio no la soporta. El volumen creció y el coste por transacción hizo que la operación fuera inviable. Un incidente en el socio interrumpió el servicio durante horas —y la fintech no tenía visibilidad ni control para actuar—. La regulación cambió y el proveedor tardó meses en adaptarse.
Estos escenarios tienen en común una causa: la infraestructura se eligió en función de lo que se necesitaba en el momento del lanzamiento, sin considerar lo que se necesitaría dos o tres años después. Y el coste de migrar —en tiempo, riesgo operativo y capital— es lo suficientemente alto como para que muchas fintechs se queden atrapadas más tiempo del que deberían en una infraestructura que ya no les sirve.
Este artículo es una guía de evaluación estratégica. No es un tutorial de implementación —es el mapa de las capas que componen la infraestructura bancaria, qué evaluar en cada una y las preguntas que deben responderse antes de firmar cualquier contrato con cualquier proveedor—.
Si todavía estás decidiendo entre construir tu propia infraestructura, usar BaaS o decantarte por un modelo de marca blanca, el artículo Banking as a Service: qué es, cómo funciona y cuándo vale la pena cubre esa decisión antes de llegar al nivel de detalle de infraestructura que se describe aquí.
As seis camadas da infraestrutura bancária
La infraestructura de una operación financiera digital no es un único sistema; es un conjunto de capas interdependientes, cada una con responsabilidades específicas y criterios de evaluación propios. Comprender el papel de cada capa es el prerrequisito para cualquier proceso de evaluación de proveedores.
Capa 1 — Core Banking: la base
El core banking es el sistema central que procesa todas las operaciones financieras: creación de cuentas, movimiento de saldos, aplicación de reglas de producto, registro de transacciones y generación de informes. Todo pasa por el core.
La elección del core banking es la más difícil de revertir porque toda la estructura de datos de la operación (cuentas, historial de transacciones, configuraciones de producto) vive en él. Migrar de un core banking a otro en producción, sin afectar a los clientes, es uno de los proyectos más complejos y arriesgados de una operación financiera.
Qué evaluar:
La primera distinción relevante es la arquitectura: sistemas heredados (mainframe, procesamiento por lotes) frente a cloud-native (microservicios, tiempo real, API abiertas). Para las fintechs y los bancos digitales, el core cloud-native es el estándar actual, pero "cloud-native" se ha convertido en un término de marketing que debe verificarse en la práctica.
Preguntas que revelan la realidad detrás del discurso: ¿el sistema procesa transacciones en tiempo real o por lotes? ¿Las API son RESTful con documentación completa y sandbox funcional? ¿La configuración de nuevos productos financieros puede realizarla el equipo de la fintech, sin abrir un ticket de soporte para el proveedor? ¿Cuáles son los tres clientes más grandes con un perfil similar al suyo que están en producción hoy en día?
La portabilidad de datos merece especial atención. En cualquier proceso de evaluación, pregunte explícitamente: si necesitamos migrar a otro core, ¿cómo es el proceso de exportación de datos? ¿En qué formato? ¿Cuál es el coste? La respuesta a esta pregunta revela mucho sobre la postura del proveedor con respecto al lock-in.
Para una profundización específica en core banking (arquitecturas, criterios de evaluación y errores comunes), el artículo Core Banking: o que é e como escolher a plataforma certa para sua fintech aborda el tema con más detalle.
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
La infraestructura bancaria no es el producto que el cliente ve, pero es lo que determina qué es posible construir, con qué velocidad, a qué coste y con qué nivel de riesgo.
Las fintechs que tratan la infraestructura como una decisión técnica —delegada por entero en el equipo de ingeniería, con poca participación de producto, cumplimiento y financiero— suelen descubrir demasiado tarde que las elecciones tomadas al principio crearon un límite máximo para lo que pueden construir en el futuro.
Las preguntas correctas, planteadas antes de la contratación, no garantizan que la elección sea perfecta. Pero garantizan que las limitaciones conocidas se acepten conscientemente, no que se descubran bajo presión, cuando el coste de cambiar ya es demasiado alto.
Lecturas relacionadas
→ Banking as a Service: Qué es, cómo funciona y cuándo vale la pena
→ Core Banking: Qué es y cómo elegir la plataforma adecuada para tu fintech
→ BaaS frente a finanzas integradas frente a marca blanca: Qué modelo elegir para tu fintech
