Il costo di scegliere male
Esiste un modello ricorrente nelle fintech che sono cresciute rapidamente e poi si sono bloccate: ad un certo punto, l'infrastruttura bancaria scelta all'inizio (rapida da contrattare, facile da implementare, con un prezzo interessante) è diventata il principale collo di bottiglia del prodotto.
L'applicazione non riesce a lanciare una funzionalità perché l'API del partner non la supporta. Il volume è cresciuto e il costo per transazione ha reso l'operazione non sostenibile. Un incidente presso il partner ha buttato giù il servizio per ore — e la fintech non aveva né visibilità né controllo per agire. La regolamentazione è cambiata e il fornitore ha impiegato mesi per adeguarsi.
Questi scenari hanno in comune una causa: l'infrastruttura è stata scelta in base a ciò che era necessario al momento del lancio, senza considerare ciò che sarebbe stato necessario due o tre anni dopo. E il costo della migrazione — in termini di tempo, rischio operativo e capitale — è abbastanza alto da far sì che molte fintech rimangano bloccate più a lungo di quanto dovrebbero su un'infrastruttura che ormai non serve più.
Questo articolo è una guida di valutazione strategica. Non è un tutorial di implementazione: è la mappa dei livelli che compongono l'infrastruttura bancaria, cosa valutare in ciascuno di essi e le domande a cui occorre rispondere prima di firmare qualsiasi contratto con qualsiasi fornitore.
Se stai ancora decidendo se costruire un'infrastruttura proprietaria, utilizzare il BaaS o optare per un modello white label, l'articolo Banking as a Service: cos'è, come funziona e quando conviene copre questa decisione prima di arrivare al livello di infrastruttura dettagliato qui.
As seis camadas da infraestrutura bancária
L'infrastruttura di un'operazione finanziaria digitale non è un singolo sistema — è un insieme di livelli interdipendenti, ciascuno con responsabilità specifiche e propri criteri di valutazione. Comprendere il ruolo di ogni livello è il prerequisito per qualsiasi processo di valutazione dei fornitori.
Livello 1 — Core Banking: le fondamenta
Il core banking è il sistema centrale che elabora tutte le operazioni finanziarie: creazione di conti, movimentazione dei saldi, applicazione delle regole di prodotto, registrazione delle transazioni e generazione di report. Tutto passa attraverso il core.
La scelta del core banking è la più difficile da invertire perché l'intera struttura dei dati dell'operazione — conti, cronologia delle transazioni, configurazioni del prodotto — risiede in esso. Migrare da un core banking a un altro in produzione, senza impattare sui clienti, è uno dei progetti più complessi e rischiosi di un'operazione finanziaria.
Cosa valutare:
La prima distinzione rilevante è l'architettura: sistemi legacy (mainframe, elaborazione in batch) rispetto a cloud-native (microservizi, tempo reale, API aperte). Per fintech e banche digitali, il core cloud-native è oggi lo standard — ma "cloud-native" è diventato un termine di marketing che deve essere verificato nella pratica.
Domande che rivelano la realtà dietro il discorso: il sistema elabora le transazioni in tempo reale o in batch? Le API sono RESTful con documentazione completa e sandbox funzionale? La configurazione di nuovi prodotti finanziari può essere eseguita dal team della fintech — senza aprire un ticket di assistenza per il fornitore? Quali sono i tre maggiori clienti con un profilo simile al vostro che sono in produzione oggi?
La portabilità dei dati merita un'attenzione speciale. In qualsiasi processo di valutazione, chiedete esplicitamente: se dovessimo migrare a un altro core, come funziona il processo di esportazione dei dati? In quale formato? Qual è il costo? La risposta a questa domanda rivela molto sull'atteggiamento del fornitore nei confronti del lock-in.
Per un approfondimento specifico sul core banking — architetture, criteri di valutazione ed errori comuni — l'articolo Core Banking: o que é e como escolher a plataforma certa para sua fintech copre il tema in maggiore dettaglio.
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
L'infrastruttura bancaria non è il prodotto che il cliente vede — ma è ciò che determina cosa è possibile costruire, a quale velocità, a quale costo e con quale livello di rischio.
Le fintech che trattano l'infrastruttura come una decisione tecnica — delegata interamente al team di ingegneria, con scarso coinvolgimento dei team di prodotto, compliance e finanziario — tendono a scoprire troppo tardi che le scelte fatte all'inizio hanno creato un limite massimo a ciò che possono costruire in futuro.
Le domande giuste, poste prima della contrattazione, non garantiscono che la scelta sarà perfetta. Ma garantiscono che le limitazioni note vengano accettate consapevolmente — non scoperte sotto pressione, quando il costo del cambiamento è ormai troppo alto.
Letture correlate
→ Banking as a Service: cos'è, come funziona e quando vale la pena
→ Core Banking: cos'è e come scegliere la piattaforma giusta per la tua fintech
→ BaaS vs. Embedded Finance vs. White Label: quale modello scegliere per la tua fintech
