Contratar uma fábrica de software é uma decisão técnica em quase qualquer empresa. Em uma instituição financeira, é também uma decisão de risco, e das que o regulador olha. Banco, cooperativa de crédito, administradora de consórcio, fintech e sociedade de crédito respondem pelo software que usam, inclusive quando outra empresa o construiu e o opera.
Este texto é para quem vai conduzir essa contratação: o que exigir da fábrica, por que cada exigência existe e como verificar se ela é real ou só está na apresentação comercial.
Por que contratar software é diferente no setor financeiro
A diferença central está numa frase: a responsabilidade não se terceiriza. A Resolução CMN 4.893, de 2021, que trata de segurança cibernética e da contratação de processamento, armazenamento de dados e computação em nuvem por instituições autorizadas pelo Banco Central, deixa isso claro. A instituição precisa demonstrar que avaliou o fornecedor, que o contrato prevê o que a norma pede e que sabe como sair dele.
Na prática, isso muda o que se pergunta a uma fábrica de software. Em outro setor, a conversa gira em torno de prazo, custo e funcionalidade. Aqui, antes disso, vem uma pergunta anterior: quando o auditor ou o regulador pedir para reconstruir o que aconteceu no sistema, alguém vai conseguir?
Há também uma questão de ritmo. O sistema de uma instituição financeira convive com mudança regulatória constante — novo layout de arquivo, nova regra de registro, novo prazo de adequação. A fábrica precisa conseguir evoluir o sistema sem que cada mudança vire um projeto novo.
O que exigir de uma fábrica de software
Os requisitos abaixo são os que mais aparecem na avaliação de fornecedor feita por comitês de risco e de tecnologia de instituições supervisionadas. Nenhum deles é exótico; o que costuma faltar é a comprovação.
Trilha de auditoria desde o desenho
Registro imutável de quem fez o quê, quando e a partir de onde, em cada evento sensível do sistema. A trilha precisa ser pensada na arquitetura: acrescentar log depois de o sistema estar pronto costuma gerar registro incompleto, editável ou impossível de consultar quando alguém pede.
Segregação de ambientes e de funções
Desenvolvimento, homologação e produção separados de fato, com credenciais, redes e dados distintos. E pessoas diferentes para desenvolver, aprovar e publicar em produção. As duas segregações são distintas: uma separa infraestrutura, a outra separa responsabilidades.
Controle de acesso e menor privilégio
Cada perfil acessa apenas o necessário para sua função, com autenticação por múltiplos fatores nos acessos administrativos. Vale para os usuários do sistema e também para a equipe da própria fábrica.
Localização dos dados e acesso do regulador
Onde os dados são processados e armazenados precisa estar escrito, não suposto. E o contrato precisa prever que o Banco Central consiga acessar dados e informações relevantes, inclusive quando estão sob custódia do fornecedor.
Continuidade e recuperação
Quanto tempo o sistema pode ficar fora do ar e quanto dado a operação aceita perder em um desastre são números de negócio, não de TI. A fábrica precisa desenhar a arquitetura para eles — e testar a recuperação, não só descrevê-la.
Gestão de segredos
Senhas, chaves de API e certificados guardados fora do código-fonte, em cofre com controle de acesso e rotação. Segredo em repositório é um dos achados mais comuns em avaliação de fornecedor, e um dos mais fáceis de verificar.
Plano de saída
O requisito que mais aparece em branco nos contratos. Propriedade do código, documentação, portabilidade dos dados e prazo de transição definidos antes da assinatura. A pergunta de teste é simples: se o contrato terminar amanhã, a equipe interna ou outro fornecedor consegue compilar, testar e publicar o sistema sem depender de algo que só a fábrica atual tem?
Como verificar se a exigência é real
Toda fábrica de software vai dizer que atende a lista acima. A diferença está no que ela consegue mostrar.
| Exigência | O que pedir | Sinal de alerta |
|---|---|---|
| Trilha de auditoria | Demonstração de consulta a um evento antigo em sistema real | "Os logs ficam no servidor" |
| Segregação | Desenho dos ambientes e de quem publica em produção | O mesmo desenvolvedor sobe o código e aprova |
| Acesso do regulador | Cláusula no contrato-padrão, antes da proposta | "Isso a gente vê no jurídico depois" |
| Continuidade | Registro do último teste de recuperação | Plano de continuidade que nunca foi exercitado |
| Plano de saída | Lista do que é entregue ao fim do contrato | Componente proprietário sem alternativa |
| Experiência | Sistema em produção em instituição supervisionada, com nome | Só cases anônimos ou de outros setores |
A última linha pesa mais do que parece. Fábrica que já colocou sistema em produção dentro de uma instituição supervisionada passou por avaliação de fornecedor real, com auditoria real do outro lado. Isso não se aprende em treinamento.
Os tipos de sistema que costumam ir para fábrica
Instituição financeira raramente terceiriza o núcleo contábil, mas terceiriza muito do que está ao redor dele — justamente onde o mercado não oferece produto que caiba no processo:
- Esteiras de crédito, da proposta à formalização, com políticas próprias e integração a bureaus.
- Canais de distribuição: aplicativo do associado, portal do parceiro, ponto de venda de correspondente.
- Integração com legado: conectar o núcleo antigo a canais novos sem reescrever o que funciona.
- Automação de processos operacionais que hoje correm em planilha e e-mail.
- Painéis de gestão e de risco que consolidam dados espalhados por vários sistemas.
Em cooperativas de crédito, o recorte é parecido, com uma particularidade: a cooperativa opera dentro de um sistema cooperativo, e o software precisa conversar com a central e com os padrões do sistema. Detalhamos o tema em software para cooperativas de crédito.
O que muda no processo da fábrica
Uma fábrica de software acostumada ao setor financeiro não trabalha com um processo diferente; trabalha com o mesmo processo levado mais a sério. O diagnóstico inclui o mapa regulatório do sistema. A arquitetura nasce com trilha, segregação e continuidade como requisito, não como item opcional do escopo. A homologação envolve a área de risco, não só a de negócio. E a implantação tem plano de volta escrito.
A GlassAuto formou sua engenharia nesse ambiente: tem plataformas em produção em cooperativas dos sistemas Sicredi e Cresol desde 2018, em crédito digital e seguros. É a mesma régua que aplicamos quando o cliente é de outro setor — e a que se espera de qualquer fornecedor quando o sistema movimenta dinheiro.
Os termos técnicos usados neste texto estão explicados no glossário de engenharia regulada.
Perguntas frequentes
Instituição financeira pode contratar fábrica de software externa?
Pode. A regulação não proíbe; ela exige avaliação prévia do fornecedor, previsões contratuais específicas e plano de saída, e mantém a responsabilidade na instituição contratante.
A fábrica precisa ter certificação?
A norma não condiciona a contratação a um selo específico. Certificação ajuda como evidência, mas não substitui a avaliação documentada que a instituição precisa fazer.
Cooperativa de crédito está sujeita às mesmas exigências?
Sim. Cooperativa de crédito é instituição autorizada a funcionar pelo Banco Central e está no alcance das normas de contratação de serviços de tecnologia.
Este conteúdo tem finalidade informativa e não substitui a leitura das normas vigentes nem a análise da área de compliance da sua instituição.
