A Resolução Conjunta nº 16/2025 elevou as exigências de governança em arranjos de Banking as a Service. O impacto principal é prático: certificações e auditorias passam a ser usadas como evidências de que a Prestadora mantém gestão e controle efetivos, mesmo quando partes relevantes da jornada do usuário (canais, integrações, coleta de dados, atendimento e tecnologia) são executadas pelo Tomador.
Assim, a Prestadora deve conseguir comprovar, de forma contínua e verificável, que os controles existem, funcionam e são acompanhados por indicadores, registros rastreáveis e medidas de correção quando necessário.
Exigências da Res. 16/2025
Deve haver verificação pré-contratual e contínua da capacidade do Tomador. Na prática, a Prestadora deve demonstrar que o Tomador assegura, ao menos, os seguintes elementos:
- Segurança e resiliência (CIA/DR): confidencialidade, integridade, disponibilidade e recuperação. (DR = disaster recovery; capacidade de restabelecer sistemas e dados após incidentes, com rotinas e testes de recuperação)
- Evidências independentes e verificáveis: acesso a evidências técnicas e, quando existentes, a relatórios emitidos por empresa independente. (relatórios com metodologia, testes e conclusão, elaborados por terceiro sem vínculo com o Tomador)
- Capacidade de monitoramento e gestão contínua: disponibilização de recursos que permitam à Prestadora acompanhar a operação e os níveis de serviço com dados atualizados. (recursos de gestão = dashboards, métricas de disponibilidade, logs, indicadores de desempenho e de risco; não se limitam a relatórios estáticos)
É essencial que a documentação e as evidências sejam mantidas atualizadas, pois a diligência não se limita ao momento de contratação. Além disso, a Prestadora deve ter capacidade de interpretar as evidências e conduzir o monitoramento, evitando terceirização da governança (depender do próprio Tomador para validar e supervisionar controles que, por desenho regulatório, devem ser acompanhados e controlados pela Prestadora).
Por fim, o contrato deve viabilizar a auditabilidade, assegurando: (i) acesso da Prestadora a certificações, relatórios e dados operacionais necessários ao acompanhamento; e (ii) previsão de acesso do BCB ao contrato, à documentação, às informações e aos códigos.
Certificação como mecanismo de evidência
A Res. 16/2025 não cria um rol de certificações obrigatórias para Tomadores. O desenho esperado é risk-based (baseado em risco), o que exige que a Prestadora defina um framework (critérios, níveis e evidências) por classe de Tomador e por serviço, com proporcionalidade (as exigências variam conforme criticidade, volume e sensibilidade de dados).
Nessa lógica, certificações e relatórios devem ser organizados em camadas, conforme o objetivo de controle:
Camada A: segurança e governança de segurança da informação
- ISO/IEC 27001 (ISMS = sistema de gestão de segurança da informação; IEC = International Electrotechnical Commission)
- ISO 27701 (extensão de privacidade para o ISMS, com controles e governança de dados pessoais)
- SDLC seguro (Software Development Life Cycle/ciclo de vida de desenvolvimento) e referências OWASP (Open Worldwide Application Security Project, referência de segurança de aplicações), quando o Tomador desenvolve canais e integrações
Camada B: evidência independente de efetividade operacional
- SOC 2 Type II (Service Organization Control 2; Type II = testado ao longo de um período, avaliando desenho e efetividade operacional de controles de segurança, disponibilidade e confidencialidade)
- SOC 1 Type II (controles relevantes para ambientes transacionais e impactos em controles financeiros, quando aplicável)
- Relatórios de auditoria especializada independente, quando existentes, para cobrir lacunas específicas do arranjo
Camada C: pagamentos e credenciais, quando aplicável
- PCI DSS (Payment Card Industry Data Security Standard; padrão de segurança para ambientes que armazenam, processam ou transmitem dados de cartão)
Camada D: continuidade e resiliência operacional
- ISO 22301 (Sistema de Gestão de Continuidade de Negócios)
- Evidências de DRP/BCP testados (DRP = Disaster Recovery Plan; BCP = Business Continuity Plan), com RTO/RPO (Recovery Time Objective/tempo máximo aceitável de indisponibilidade; Recovery Point Objective/ponto máximo aceitável de perda de dados)
Auditorias em Tomadores
A Prestadora é responsável pela integridade do arranjo, mas parte dos controles e evidências está no Tomador. O objetivo é verificar os controles do Tomador que são relevantes para o arranjo, considerando:
a) Sigilo, privacidade e escopo de amostras
Auditorias demandam logs, tickets, gravações e trilhas de onboarding, o que pode envolver LGPD e, em operações de crédito, sigilo bancário. Para viabilizar auditoria com segurança jurídica, recomenda-se estruturar um pacote com:
- Minimização (limitar ao estritamente necessário)
- Segregação de ambientes e dados (por exemplo, uso de dados mascarados quando possível)
- Regras de retenção (prazos) e confidencialidade
- Auditor independente sob NDA (acordo de confidencialidade)
b) Cadeia de terceiros e computação em nuvem
O risco frequentemente se desloca para subcontratados do Tomador: cloud, KYC, antifraude, CRM, mensageria, analytics e BPO (terceirização de processos). A auditoria fica incompleta se não alcançar a cadeia. A técnica usual é flow-down contratual (repasse das obrigações ao subcontratado), impondo padrões de segurança, direito de auditoria, reporte de incidentes e cooperação operacional.
c) Custo operacional
Auditorias extensas competem com operação 24/7 e com times de produto. Um desenho eficiente tende a combinar três trilhas:
- Assurance contínuo: SOC/ISO e evidências periódicas
- Auditoria temática: testes focados em onboarding, antifraude, incidentes e DR
- Auditoria acionável: gatilhos por incidentes relevantes, degradação de SLA e reclamações materialmente relevantes
Efetividade além do contrato
A diferença entre conformidade formal e controle efetivo está na capacidade de a Prestadora monitorar e intervir. Arranjos mais robustos geralmente incluem:
- Observabilidade compartilhada (monitoramento por métricas, logs e traces), com dashboards de disponibilidade, latência e erros
- Trilhas e logs para reconstrução de eventos e decisões
- Runbooks (manual de resposta) e escalonamento (cadeia de acionamento), com RACI (matriz de responsabilidades) e pós-incidente (análise pós-mortem e causa-raiz)
No plano contratual-operacional, o enforcement deve ser executável:
- SLA com consequências automáticas, inclusive service credits (créditos financeiros por descumprimento), plano corretivo e re-teste
- Step-in rights (direito de intervenção temporária da Prestadora) e mecanismos de interrupção controlada em incidentes graves
- KPI/KRI (indicadores de desempenho e de risco), com monitoramento de fraude, chargeback, tempos de onboarding e tempos de resolução
O que Tomadores devem esperar
Tomadores devem esperar exigências estruturadas por níveis, conforme criticidade, volume e serviço, com baseline mínimo e requisitos adicionais. Para atender com previsibilidade, a preparação material envolve:
- Governança documentada: políticas, risk register (registro estruturado de riscos), ownership (responsáveis definidos) e comitês
- Controles técnicos: IAM (Identity and Access Management/gestão de identidades e acessos), criptografia, segregação e gestão de vulnerabilidades
- Capacidade de evidência contínua: dashboards, logs e relatórios periódicos
- Governança de terceiros: flow-down e notificação tempestiva de terceirizações relevantes
