Na sexta-feira, 17 de julho, saiu no Diário Oficial a Portaria CVM/PTE nº 177: está criado o Grupo de Trabalho de Tokenização (GTT), reunindo 14 áreas da autarquia sob coordenação das superintendências de Desenvolvimento de Mercado e de Supervisão de Securitização. O mandato é de 120 dias, prorrogáveis por 30 — mas a entrega que importa tem prazo mais curto: uma proposta de regime regulatório experimental para a tokenização em 60 dias.
Traduzindo o ato administrativo: a tokenização de valores mobiliários no Brasil, que vinha operando numa zona cinzenta regulatória, acaba de ganhar relógio. Quem emite, custodia ou negocia ativos tokenizados — ou tem isso no roadmap do próximo trimestre — tem dois meses para chegar à discussão com o dever de casa feito.
O que o GTT vai olhar — e por que agora
O escopo declarado cobre o ciclo de vida completo do valor mobiliário em registro distribuído: registro, depósito, custódia, negociação e liquidação em DLT, com a cibersegurança incluída no mandato. É a CVM assumindo a ponta que lhe cabe na divisão de competências do mercado cripto brasileiro: ativos virtuais em geral seguem com o Banco Central; quando o token representa um valor mobiliário, a casa é a CVM — e é exatamente essa fronteira que o regime experimental deve organizar.
O timing não é acidente. O capital chegou antes da norma: no início do mês, a maior emissora de stablecoins do mundo liderou um aporte de R$ 100 milhões no Mercado Bitcoin destinando os recursos, explicitamente, a investimentos tokenizados e mercados de capitais on-chain. Quando o dinheiro institucional aponta para um mercado, o regulador acelera o mapa. Os dois relógios — o do capital e o da norma — estão sincronizados.
Regime experimental não é liberação — é laboratório com regras
Vale precisão conceitual: regime experimental é um ambiente controlado para testar modelos de negócio sob regras adaptadas e supervisão próxima, antes da norma definitiva. Não é dispensa de regulação; é regulação em escala de teste. Para quem participa, o ganho é duplo: operar com segurança jurídica durante o experimento e influenciar o desenho da norma que valerá para todos — o GTT prevê a participação de agentes externos na discussão.
O risco de ficar de fora é o espelho disso: quem opera hoje na zona cinzenta e ignora o processo pode descobrir, na proposta de 60 dias, que seu produto foi reclassificado — e que as regras foram desenhadas por quem sentou à mesa.
Quem precisa se mexer, e o mapa de quatro passos
Perfil
Exposição ao regime que vem
Emissor de tokens de recebíveis, imobiliários ou de renda fixa
Enquadramento do ativo: valor mobiliário ou não? A resposta define o regulador, o registro e o regime de oferta.
Plataforma de distribuição/negociação
Registro e regras de negociação e liquidação em DLT — núcleo do escopo do GTT.
Custodiante de tokens
Evidências de segregação, guarda e cibersegurança — item expresso do mandato.
Fintech com tokenização no roadmap
Janela para desenhar o produto já compatível com o experimento, em vez de retrofit depois.
1. Inventário: o que exatamente você tokeniza (ou pretende) e qual papel exerce em cada operação — emissor, distribuidor, custodiante.
2. Enquadramento atual: cada token, testado contra o conceito de valor mobiliário. Onde houver dúvida, documente a dúvida — ela é o seu mapa de risco.
3. Evidências: custódia, segregação, trilhas de registro e controles ciber organizados como quem vai mostrá-los — porque vai.
4. Canal de participação: acompanhe o GTT e prepare contribuição. Sessenta dias passam rápido, e a cadeira à mesa é para quem chega com posição escrita.
O que a Tridvo entrega: o mapa regulatório do seu produto tokenizado — inventário, enquadramento, lacunas de evidência — integrado ao roadmap, para o produto crescer dentro do desenho que vem, não contra ele.
Desde 1º de julho está em vigor a fase de transição da régua de capital mais dura que o mercado de fintechs brasileiro já enfrentou. A Resolução Conjunta CMN/BCB nº 14/2025, publicada em novembro, mudou a lógica do capital mínimo de fintechs: o piso deixou de ser definido pelo tipo de licença e passou a ser calculado pela atividade efetivamente exercida. E o recorte divulgado nesta semana mostra que o problema não é de 2028 — é de agora.
Segundo levantamento publicado pelo Valor a partir de dados do Banco Central, 339 instituições — 19% das 1.751 analisadas — já não atendem às exigências do primeiro marco da transição, neste mês. É o retrato imediato de um número que o regulador havia antecipado no Relatório de Estabilidade Financeira de maio: quando a regra estiver plena, em janeiro de 2028, serão 679 instituições desenquadradas, 39% do universo analisado, com deficiência agregada de capital superior a R$ 8 bilhões.
Os dois números são pontos do mesmo cronograma. O 679 é o tamanho do filme; o 339 é o fotograma de julho — e ele diz que um quinto do mercado começou a transição já devendo.
O que mudou: da licença para a atividade
No modelo anterior, o capital mínimo era uma etiqueta da licença: instituição de pagamento, R$ 1 milhão a R$ 9 milhões conforme a modalidade. A RC 14/2025, acompanhada da Resolução BCB nº 517/2025 (que criou a taxonomia unificada de atividades), inverteu a lógica: o que define o seu piso é o que você faz, não o que a sua autorização diz.
Na prática, o cálculo soma parcelas: uma base por categoria de atividade exercida — concessão de crédito, intermediação, custódia e administração de recursos, prestação de serviços — mais componentes adicionais, como a parcela associada ao custo de estruturação da operação. Uma instituição de pagamento que também faz crédito e custódia soma os pisos dessas atividades, e o resultado fica muito acima do patamar histórico: as novas faixas para IPs vão de R$ 9,2 milhões a R$ 32,8 milhões, conforme o conjunto de atividades.
O contexto político, aliás, sopra na mesma direção da régua: no dia 9, o ministro da Fazenda cobrou publicamente mais supervisão sobre fintechs — declaração, não norma, mas o tipo de declaração que costuma antecipar rigor, não afrouxamento.
O cronograma: quatro marcos até 2028
A exigência não chega de uma vez. A diferença entre o capital atual e o novo mínimo deve ser coberta progressivamente:
Marco
Data-limite
% da diferença coberta
1º marco
31/12/2026
25%
2º marco
30/06/2027
50%
3º marco
31/12/2027
75%
Regra plena
01/01/2028
100%
Dezoito meses até o primeiro marco parecem folga — mas aporte de capital, reorganização societária ou redução de escopo são decisões que levam trimestres para executar, não semanas. E quem está entre os 339 já começou o relógio devendo.
Como fazer a conta, em quatro passos
1. Inventarie as atividades efetivamente exercidas — não as autorizadas. Use a taxonomia da BCB 517/2025 como referência e liste o que a operação realmente faz hoje.
2. Some as parcelas correspondentes a cada categoria, incluindo os componentes adicionais aplicáveis ao seu porte e modelo.
3. Compare com capital social integralizado e patrimônio líquido atuais e calcule o gap total.
4. Distribua o gap pelos quatro marcos e leve o resultado para a próxima reunião de sócios — porque a resposta quase sempre envolve decisão societária, não apenas contábil.
O erro que infla o mínimo — e as rotas de adequação
O erro mais comum que temos visto: manter autorizações para atividades que a fintech não exerce. Na lógica nova, autorização parada pode significar parcela de capital exigida à toa. Enxugar o escopo — devolver o que não se usa — é rota legítima de adequação, e muitas vezes a mais barata.
As demais rotas o próprio Banco Central listou ao comentar o cenário: reforçar patrimônio, sair do sistema ou se fundir. Cada uma tem prazo e custo próprios; o que nenhuma delas admite é começar em cima do marco.
Um ponto que conecta este tema ao que escrevemos em maio sobre [a seletividade do capital]: investidor que analisa fintech em 2026 já pergunta pelo enquadramento na RC 14. Chegar à conversa sem a conta feita não impede a rodada — muda o preço dela. E, com a lista de 339 circulando, a pergunta deixou de ser hipotética.
O que a Tridvo entrega: o mapeamento de atividades pela taxonomia nova, o cálculo do gap por marco e o desenho da rota de adequação entram no diagnóstico que fazemos com fintechs Série A–C — com a tradução do resultado para a narrativa de captação, que é onde a conta vira valor.
Em dezembro de 2025, o Banco Central publicou a Resolução BCB 538. Em 1º de março de 2026, o prazo de adequação encerrou. Se você ainda não tem evidências documentadas dos 14 controles mínimos — esta leitura é urgente.
O que mudou — e por que importa agora
A Resolução BCB nº 538, publicada em 18 de dezembro de 2025, não é uma atualização cosmética. Ela altera a Resolução BCB 85/2021 e redefine o que o Banco Central entende por segurança cibernética no ecossistema de pagamentos.
A norma se aplica diretamente a instituições de pagamento (IPs), corretoras e distribuidoras. Ou seja: se você opera como IP — e a maioria das fintechs de Série A-C opera —, a BCB 538 é o seu novo padrão mínimo. Sem exceção.
O prazo de adequação era 1º de março de 2026. Já passou. O que o BCB passou a buscar nas fiscalizações não são mais políticas de segurança bem redigidas. São evidências: logs, trilhas auditáveis, relatórios de pentest assinados, planos de ação com data de implementação.
“A fintech precisa demonstrar, de forma clara e rastreável, que seus controles existem, são aplicados e são monitorados.” — Dra. Laura Cunha, especialista em Direito Empresarial
A diferença entre a norma anterior (BCB 85/2021) e a BCB 538 é exatamente essa: saiu o modelo baseado em princípios gerais, entrou o modelo prescritivo. O regulador não deixa mais margem de interpretação.
Os 14 controles mínimos — e o que cada um significa na prática
A BCB 538 expande o Art. 3º da resolução anterior e estabelece 14 procedimentos e controles obrigatórios. Não são sugestões de boas práticas. São requisitos técnicos verificáveis. Veja o que sua equipe precisa ter documentado e operacional:
Controle
O que exige na prática
1. Autenticação e MFA
Verificação de identidade forte, especialmente em acessos privilegiados e ambientes do Pix/STR
2. Criptografia
Proteção de dados em trânsito e em repouso, com gestão de chaves privadas inacessíveis a terceiros
3. Prevenção e detecção de intrusão
Sistemas ativos de monitoramento, não apenas políticas escritas
4. Proteção contra vazamento de dados (DLP)
Controles técnicos que impeçam exfiltração de dados sensíveis
5. Rastreabilidade de operações
Logs completos e auditáveis, com prazos de retenção definidos por tipo de operação
6. Backup e recuperação
Planos testados de continuidade — o BCB quer saber se o plano funciona, não se existe
7. Gestão de vulnerabilidades
Processo contínuo e estruturado, não varreduras ocasionais
8. Pentest anual independente
Obrigatório. Profissional ou empresa independente. Relatório retido por 5 anos
9. Hardening de sistemas
Configurações mínimas de segurança em todos os sistemas críticos
10. Proteção de rede e perímetro
Isolamento lógico e físico de ambientes críticos (Pix, STR, RSFN)
11. Gestão de certificados digitais
Ciclo de vida documentado e controlado
12. Segurança em APIs
Revisão de segurança de APIs próprias e de parceiros integrados
13. Threat Intelligence (CTI)
Monitoramento ativo na internet aberta, deep web e dark web — obrigatório
14. Segurança no desenvolvimento
Controles de segurança integrados ao pipeline de desenvolvimento (CI/CD, code review)
Dois controles merecem atenção especial de founders e CTOs: o pentest anual independente e o Threat Intelligence.
Pentest anual: A independência é requisito literal da norma. Se o mesmo fornecedor que gerencia sua infraestrutura também realiza o pentest, o BCB pode questionar a imparcialidade — e a evidência perde validade. Os relatórios precisam ser mantidos por pelo menos 5 anos, junto com os planos de ação de remediação.
Threat Intelligence: Não é mais opcional. O BCB exige que sua instituição monitore ativamente menções à marca, credenciais expostas e ameaças na dark web. Postura reativa — esperar o incidente acontecer — deixou de ser aceitável regulatoriamente.
Por que o BCB publicou isso agora
A BCB 538 não surgiu do nada. Ela é a resposta regulatória a dois fenômenos simultâneos que tornaram o sistema de pagamentos brasileiro um vetor crítico de risco:
Volume do Pix: O sistema registrou 36,9 bilhões de operações no primeiro semestre de 2025. Em dezembro de 2025, um único dia bateu 313 milhões de transações. Escala nessa magnitude transforma qualquer vulnerabilidade técnica em risco sistêmico.
Custo dos incidentes: O relatório IBM Cost of a Data Breach 2025 aponta custo médio de R$ 8,92 milhões por violação no setor financeiro brasileiro — acima dos R$ 7,19 milhões da média geral do país. O elemento humano está envolvido em 60% das violações (Verizon DBIR 2025).
Superfície de ataque expandida: Open Finance, APIs com parceiros, fintechs em nuvem pública — o ecossistema de pagamentos é hoje uma rede de integrações. Cada ponto de conexão é uma porta potencial.
A BCB 538 é publicada em conjunto com a Resolução CMN 5.274/2025, que aplica os mesmos padrões para bancos tradicionais. O sinal é claro: o regulador quer simetria técnica entre bancos e fintechs. Independentemente da licença, a robustez da defesa cibernética precisa ser idêntica e auditável.
“Cibersegurança deixou de ser item de conformidade e passou a integrar a arquitetura de valor do sistema financeiro.” — InfoMoney, fevereiro 2026
O que muda para o C-Level: segurança entra na pauta do Conselho
Essa é a mudança que mais impacta founders e executivos: a BCB 538 torna cibersegurança um tema obrigatório na agenda da diretoria e do conselho.
Os reportes periódicos às instâncias de governança agora precisam contemplar: incidentes cibernéticos relevantes do período, resultados de testes de continuidade, resultados de pentests e análises de vulnerabilidade — todos com planos de ação documentados.
Traduzindo: se o seu CTO reporta cibersegurança apenas para o time técnico, isso precisa mudar. O BCB quer ver que a alta administração está envolvida e informada. E vai verificar isso durante fiscalizações.
Para CMOs e equipes de growth, há um impacto indireto relevante: a norma amplia os controles de segurança para o desenvolvimento de software — incluindo revisão de código, testes de segurança em aplicações e análise de bibliotecas open-source. Campanhas que dependem de integrações técnicas (pixels, SDKs, APIs de parceiros) passam a precisar de revisão de segurança documentada.
⚠ Ponto de atenção para fintechs em nuvem: a BCB 538 exige isolamento físico e lógico de ambientes críticos. Instâncias de computação em nuvem devem ser dedicadas e apartadas de outros sistemas. Provedores de nuvem não podem ter acesso às chaves privadas da instituição. Se você usa cloud compartilhado para o ambiente Pix ou STR, essa arquitetura precisa ser revisada.
O risco de não conformidade — antes e depois do prazo
O prazo de 1º de março de 2026 já encerrou. O que isso significa, na prática, para quem ainda não completou a adequação?
Primeiro, o risco regulatório direto: o BCB pode iniciar processo administrativo sancionador, aplicar multas e, em casos graves, suspender ou revogar autorizações de funcionamento. Para IPs em processo de captação ou renovação de licença, a ausência de evidências de conformidade é um bloqueio imediato.
Segundo, o risco reputacional e de captação: investidores de Série B e C já incluem questões de conformidade regulatória no processo de due diligence. Uma fintech sem documentação de pentest ou sem programa de Threat Intelligence estruturado vai encontrar questões difíceis de responder numa sala de Term Sheet.
Terceiro, o risco operacional: fintechs que não monitoram deep e dark web não sabem se credenciais de colaboradores ou clientes já foram comprometidas. A ausência de Threat Intelligence não significa ausência de ameaças — significa ausência de visibilidade.
Como transformar conformidade em vantagem competitiva
Compliance tem duas faces. A face óbvia é o custo de não cumprir. A face que a maioria ignora é o valor de cumprir com documentação, visibilidade e comunicação.
Fintechs que documentam seus 14 controles, realizam pentest anual independente e estruturam um programa de CTI têm um ativo concreto para usar em três contextos:
Pitch de captação: Investidores de Série B e C em setores regulados querem ver maturidade operacional. Um relatório de pentest recente, assinado por empresa independente, e um programa de Threat Intelligence documentado são provas de governança — não apenas de conformidade.
Onboarding de clientes enterprise: Empresas maiores que integram com sua API vão questionar sua postura de segurança. Ter evidências auditáveis encurta esse ciclo de vendas.
Comunicação de marca: Marcas que comunicam proativamente sua maturidade em segurança constroem confiança antes de qualquer incidente. Após um incidente, essa confiança é muito mais difícil de recuperar.
A diferença entre cibersegurança como custo e cibersegurança como ativo é, na maioria dos casos, documentação e comunicação. Os controles técnicos muitas vezes já existem — o que falta é torná-los auditáveis e visíveis.
Checklist de adequação: onde você está agora?
Se você quer uma leitura rápida da maturidade da sua fintech frente à BCB 538, avalie os 8 pontos abaixo:
[ ] Pentest anual realizado: Por empresa ou profissional independente do seu fornecedor de infraestrutura, com relatório documentado.
[ ] Plano de ação de pentest: Com vulnerabilidades identificadas, prazos de remediação e evidências de correção — retido por 5 anos.
[ ] Threat Intelligence ativo: Monitoramento de internet aberta, deep web e dark web, com processo documentado.
[ ] MFA em ambientes críticos: Especialmente acessos administrativos e conectividade RSFN/Pix/STR.
[ ] Isolamento de ambientes Pix/STR: Lógico e físico, com acesso de terceiros (incluindo cloud) restrito às chaves privadas.
[ ] Rastreabilidade de operações: Logs com prazos de retenção definidos por tipo de operação e auditáveis.
[ ] Segurança no desenvolvimento: Revisão de código, análise de dependências open-source e testes de segurança em aplicações documentados.
[ ] Reporte à diretoria: Cibersegurança na pauta do conselho, com evidências de que a alta administração está informada.
Se você marcou menos de 5 itens, o gap é material. Se marcou entre 5 e 7, o problema provavelmente não é a implementação técnica — é a documentação e a evidência auditável.
O próximo passo
A BCB 538/2025 consolidou uma transição que vinha acontecendo há anos no mercado financeiro: cibersegurança saiu da área de TI e entrou na estratégia de negócio. Não é mais possível tratar conformidade como tarefa do time técnico e crescimento como tarefa do time de produto. As duas agendas se cruzam — e precisam ser gerenciadas de forma integrada.
Na Tridvo, a nossa abordagem para adequação à BCB 538 combina diagnóstico regulatório, estruturação de evidências e comunicação de maturidade. Não apenas para cumprir a norma — mas para transformar o que é obrigatório em diferencial competitivo.
Quer saber onde está o gap da sua fintech frente aos 14 controles da BCB 538? Fazemos o diagnóstico e entregamos a matriz de adequação em 48h. Sem achismo, sem relatório genérico.
Perguntas Frequentes (FAQ)
O que é a Resolução BCB 538/2025?
A Resolução BCB nº 538/2025 é a norma publicada pelo Banco Central do Brasil em 18 de dezembro de 2025 que atualiza as regras de segurança cibernética para instituições de pagamento (IPs), corretoras e distribuidoras. Ela substitui a Resolução BCB 85/2021 e estabelece 14 controles mínimos obrigatórios, com prazo de adequação até 1º de março de 2026.
A BCB 538/2025 se aplica a fintechs?
Sim. A BCB 538/2025 se aplica diretamente a instituições de pagamento (IPs), que é a licença operada pela maioria das fintechs de Série A-C no Brasil. Bancos tradicionais e cooperativas de crédito seguem a norma espelho: Resolução CMN nº 5.274/2025. As exigências técnicas são equivalentes nas duas normas.
Quais são os 14 controles obrigatórios da BCB 538/2025?
Os 14 controles mínimos obrigatórios da BCB 538/2025 são: (1) autenticação e MFA, (2) criptografia, (3) prevenção e detecção de intrusão, (4) proteção contra vazamento de dados (DLP), (5) rastreabilidade de operações, (6) backup e recuperação, (7) gestão de vulnerabilidades, (8) pentest anual independente, (9) hardening de sistemas, (10) proteção de rede e isolamento de ambientes críticos, (11) gestão de certificados digitais, (12) segurança em APIs, (13) Threat Intelligence com monitoramento de dark web, e (14) segurança no desenvolvimento de software.
O pentest anual da BCB 538 precisa ser feito por empresa independente?
Sim. A BCB 538/2025 exige que o teste de intrusão (pentest) seja realizado por profissional ou empresa independente da instituição — ou seja, não pode ser o mesmo fornecedor que gerencia sua infraestrutura de segurança. Os relatórios, planos de ação e evidências de remediação devem ser documentados e mantidos por pelo menos 5 anos.
O que é Threat Intelligence e por que a BCB 538 a exige?
Threat Intelligence (CTI) é o monitoramento ativo de ameaças cibernéticas em fontes abertas, deep web e dark web — incluindo credenciais vazadas, menções à instituição e movimentações de grupos criminosos. A BCB 538/2025 torna esse monitoramento obrigatório porque a maioria dos incidentes financeiros começa por credenciais comprometidas, e uma postura reativa (esperar o ataque acontecer) deixou de ser regulatoriamente aceitável.
Qual é o prazo da BCB 538/2025?
O prazo de adequação à Resolução BCB 538/2025 era 1º de março de 2026 para instituições já em funcionamento na data de publicação (18 de dezembro de 2025). O prazo já encerrou. Fintechs que não completaram a adequação estão sujeitas a fiscalização, processo administrativo sancionador e, em casos graves, suspensão ou revogação da licença de funcionamento.
Qual é a diferença entre a BCB 538/2025 e a CMN 5.274/2025?
As duas normas têm conteúdo técnico equivalente — são normas espelho publicadas no mesmo dia (18/12/2025). A diferença está no escopo: a CMN 5.274/2025 se aplica a instituições financeiras (bancos, cooperativas de crédito); a BCB 538/2025 se aplica a instituições de pagamento (IPs), corretoras e distribuidoras. Ambas têm o mesmo prazo: 1º de março de 2026.
O que o Banco Central fiscaliza na BCB 538/2025?
O BCB não busca apenas políticas escritas — busca evidências de que os controles existem, são aplicados e são monitorados. Isso inclui: logs com trilhas auditáveis, relatórios de pentest assinados por empresa independente, planos de ação de remediação com datas, documentação de testes de continuidade e reportes formais de cibersegurança à diretoria e ao conselho.
Fintechs em nuvem precisam se adequar à BCB 538/2025?
Sim, com requisitos específicos. A BCB 538/2025 exige isolamento físico e lógico de ambientes críticos (Pix, STR, RSFN) — inclusive em nuvem. Isso significa que instâncias de computação em nuvem devem ser dedicadas e separadas de outros sistemas. Provedores de nuvem não podem ter acesso às chaves privadas da instituição. Arquiteturas de nuvem compartilhada para ambientes críticos precisam ser revisadas.
