Escolher um parceiro de software é difícil. Escolher um para construir um produto que será auditado por um banco central é outro problema, e a maioria dos processos de seleção não está preparada para isso.
O checklist de sempre cobre stack, valores, tamanho do time e fuso horário. Nada disso diz se um fornecedor consegue entregar um produto que passe por uma revisão de compliance, nem o que acontece com o seu código quando o contrato termina. A seguir, o que achamos que compradores do setor financeiro deveriam realmente perguntar, e como nós mesmos respondemos a essas perguntas.
O que muda quando o software é regulado
Na maioria dos projetos, um bug custa uma release. Em um produto financeiro regulado, pode custar uma licença.
Compliance com o banco central, controles de AML e KYC, prevenção a fraude e trilhas de auditoria completas não são funcionalidades que se adicionam no final. Elas definem a arquitetura desde a primeira sprint: como você modela transações, onde armazena dados pessoais, como versiona regras de negócio que o regulador vai pedir para reproduzir daqui a dois anos.
Por isso “construímos qualquer coisa” é uma resposta fraca nesse setor. Um time que nunca operou sob essas restrições vai tomar decisões de engenharia razoáveis que viram retrabalho caro quando chega a primeira auditoria.
Cinco perguntas que valem a pena
Quem é dono da arquitetura?
Alguns fornecedores alocam engenheiros sob o seu tech lead e param por aí. Outros assumem a responsabilidade pelas decisões técnicas e suas consequências. Os dois modelos são válidos, mas não são a mesma compra, e a diferença de preço geralmente reflete isso. Deixe claro qual dos dois você está comprando.
Como o time lida com legado?
A maioria dos produtos financeiros não é greenfield. Existe um sistema central que não pode cair, escrito em uma linguagem que o time original já não mantém. Pergunte como o fornecedor modernizou um sistema enquanto ele continuava em produção, não como ele o reconstruiria do zero.
Quem responde pela qualidade?
Se o QA fica fora do time e só entra no final, os defeitos aparecem tarde e custam mais caro. Pergunte onde os testes ficam no processo de entrega e quem responde quando algo chega à produção.
Como funciona a transferência de conhecimento?
Essa é a pergunta que os compradores pulam e depois se arrependem. Documentação, propriedade do código e onboarding do seu time interno devem fazer parte do contrato desde o início, não ser uma tarefa de encerramento.
O que acontece quando o projeto termina?
Um bom parceiro deixa um sistema que o seu próprio time consegue operar. Pergunte como é o handover na prática.
Onde entram as avaliações de terceiros
Não dá para verificar quase nada disso pelo site de um fornecedor. É aí que fontes independentes fazem diferença: avaliações verificadas de clientes, certificações de segurança e cases específicos o bastante para serem checados.
Avaliações em diretórios como o GoodFirms importam porque quem fala é o cliente, e porque a plataforma verifica o projeto antes de publicar. Mas não contam a história inteira. Uma certificação como a ISO 27001 mostra como o fornecedor trata segurança da informação. Um case com escopo definido e resultados mensuráveis mostra se ele já resolveu um problema parecido com o seu. Leia os três juntos, e desconfie de qualquer fornecedor que não ofereça nenhum deles.
Como respondemos a essas perguntas
A Luby é uma empresa de engenharia de produto com escritório em Miami e centro de entrega no Brasil, construindo software para fintechs e instituições financeiras desde 2002. Temos as certificações ISO 27001 e ISO 27701 e somos parceiros AWS e Google Cloud.
Sobre propriedade da arquitetura: nossos engenheiros são responsáveis por arquitetura, entrega e qualidade. Trabalhamos como times de produto completos, não como alocação de profissionais.
Sobre legado: construímos uma plataforma de core banking em microsserviços para uma fintech de Banking as a Service que mantém 99,99% de uptime e atende mais de 50 clientes BaaS ativos, e redesenhamos a plataforma de banco digital de um fornecedor de tecnologia de core banking que atende mais de 200 bancos comunitários nos Estados Unidos, reduzindo os custos de desenvolvimento em 39%.
Sobre complexidade regulatória: projetamos e construímos um gateway de pagamentos Pix conectando os Estados Unidos e a América Latina, com roteamento inteligente de transações, prevenção a fraude e controles de AML/KYC integrados às principais instituições financeiras brasileiras.
Sobre resultados: uma transformação digital que entregamos para um banco comunitário americano aumentou a adoção digital em 45%, alcançou 92% de satisfação dos clientes e viabilizou o lançamento de sete produtos de banco digital.
Se você está avaliando parceiros
Leve as cinco perguntas acima para a sua próxima conversa com fornecedores, estejamos ou não na lista. Elas separam os times que já entregaram produtos financeiros regulados dos times que apenas acreditam que conseguiriam.
Você pode ver nosso perfil verificado e as avaliações de clientes no GoodFirms. Se quiser conversar sobre um problema específico, topamos essa conversa antes mesmo de existir uma proposta na mesa.