Sistemas Avaliados

• Sistema Atual (Backoffice) — https://backoffice.bmv.global
• Sistema Legado (Backoffice) — https://legado-backoffice.bmv.global

Fornecedor Avaliado

• Multiledgers — https://multiledgers.com

• Módulos Funcionais e Operacionais
• Governança de Dados, Identidade e Rastreabilidade
• Usabilidade e Aderência ao Sistema Legado
• Riscos Técnicos, Operacionais, Financeiros e Jurídicos
• Lacunas Funcionais e Ausência de Componentes Críticos
• Análise Comparativa entre Sistema Atual e Legado

Área: Tecnologia da Informação/Gestão Operacional

Gestor Operacional: Luiz Paulo Gonçalves Miguel de Jesus

Data de Emissão

05 de janeiro de 2026

Este dossiê possui caráter técnico, deliberativo e auditável, fundamentado em evidências observáveis em ambiente produtivo, análises comparativas com o sistema legado e registros documentais anexos. Seu conteúdo pode subsidiar decisões estratégicas, contratuais, operacionais e jurídicas, bem como ações de reestruturação tecnológica.

(Leitura Obrigatória)

Este relatório técnico tem como objetivo consolidar, de forma estruturada, rastreável e auditável, os principais pontos críticos identificados no sistema BMV (https://backoffice.bmv.global), desenvolvido pela Multiledgers. A análise contempla não conformidades técnicas, falhas de concepção, erros de lógica, lacunas operacionais, riscos de escalabilidade e fragilidades relevantes de governança, todos com impacto direto na continuidade operacional, na confiabilidade dos processos e na credibilidade institucional da BMV.

O sistema BMV, elemento central para a operação da organização, foi concebido e implementado a partir de uma replicação direta do sistema legado, sem que tivesse sido conduzida uma reengenharia estrutural adequada dos fluxos operacionais, das regras de negócio e da arquitetura tecnológica subjacente.

Como consequência direta dessa abordagem de “cópia e adaptação”, o sistema atual apresenta os seguintes efeitos combinados e críticos:

• Reprodução integral de problemas históricos já conhecidos no sistema legado;
• Manutenção de ineficiências estruturais previamente identificadas e não tratadas;
• Introdução de novos riscos operacionais, técnicos e de segurança, decorrentes da ausência de modernização arquitetural e de governança sistêmica adequada.

Essa combinação compromete a maturidade tecnológica da plataforma e impede que o sistema atenda aos requisitos mínimos exigidos pelo modelo de negócio da BMV, especialmente nos seguintes eixos críticos:

Automação

Funcionalidades essenciais dependem excessivamente de processos manuais, resultando em lentidão operacional, maior propensão a falhas humanas e uso ineficiente de recursos, impactando diretamente a produtividade e a previsibilidade da operação.

Escalabilidade

A arquitetura do sistema não foi projetada para sustentar crescimento consistente de volume transacional, base de usuários ou complexidade operacional, criando limitações estruturais à expansão segura e sustentável do negócio.

Governança e Rastreabilidade

Foram identificadas deficiências relevantes nos mecanismos de auditoria, rastreabilidade de ações e controle do ciclo de vida de dados e transações, comprometendo a governança, a gestão de riscos e o atendimento a potenciais exigências regulatórias, contratuais e institucionais.

Confiabilidade Operacional

A base tecnológica e a lógica sistêmica apresentam fragilidades que afetam diretamente a previsibilidade, a estabilidade e a integridade das operações, ampliando o risco de falhas operacionais e inconsistências sistêmicas.

Este Dossiê Técnico de Avaliação foi elaborado para subsidiar decisões estratégicas, táticas e estruturais no mais alto nível da organização, constituindo-se como instrumento formal de governança, cobrança técnica, mitigação de riscos e suporte à tomada de decisão.

Destinatários Primários

• Diretoria Executiva
  Suporte à tomada de decisão sobre investimentos, priorização estratégica e direcionamento tecnológico.
• Comitê Decisório
  Avaliação, aprovação e acompanhamento de planos de ação corretivos e estratégias de mitigação de riscos sistêmicos.
• Área Técnica / Tecnologia da Informação
  Definição de requisitos estruturais, padrões mínimos de qualidade, arquitetura, governança e critérios objetivos de evolução do sistema.
• Área Jurídica
  Análise de riscos contratuais, de conformidade, responsabilidade e aderência do fornecedor às obrigações técnicas assumidas.

Além de seu caráter técnico, este documento constitui a base formal e auditável para:

• Alinhamento estratégico interno, assegurando compreensão clara e homogênea da criticidade do cenário atual por todos os stakeholders;
• Cobrança técnica rigorosa do fornecedor, fundamentada em evidências objetivas, critérios mensuráveis e princípios de governança;
• Avaliação de renegociação, reestruturação ou eventual redefinição contratual, caso se conclua que o modelo vigente não atende aos requisitos mínimos de segurança, escalabilidade, confiabilidade e governança exigidos pela BMV.

O presente documento tem como finalidade estabelecer uma base informacional sólida, técnica e verificável para a gestão, correção e evolução do sistema BMV, contemplando os seguintes objetivos centrais:

Registro Formal de Não Conformidades

Catalogar, de forma estruturada, todas as falhas, inconsistências, bugs e deficiências identificadas no sistema.

Identificação e Classificação de Riscos

Expor e analisar os riscos inerentes à operação da plataforma, abrangendo dimensões operacionais, tecnológicas, financeiras e jurídicas.

Suporte à Decisão Estratégica

Constituir acervo documental apto a subsidiar decisões estratégicas de alto impacto, com base técnica e evidencial.

Referencial para Intervenções Estruturais

Servir como padrão técnico e ponto de partida para correções pontuais, projetos de reengenharia profunda ou eventual substituição integral do sistema.

A avaliação do Sistema BMV foi conduzida a partir de uma abordagem técnica, prática e comparativa, com foco na identificação de não conformidades estruturais, riscos operacionais e lacunas de governança, evitando análises teóricas ou desconectadas da realidade operacional. Foram adotados os seguintes métodos:

Utilização em Ambiente Produtivo

Análise do sistema em uso real, considerando cenários operacionais efetivamente executados pelas equipes internas e clientes, permitindo a identificação de fragilidades práticas e recorrentes.

Análise Comparativa com o Sistema Legado

Verificação sistemática das funcionalidades, fluxos e regras de negócio do sistema atual em contraste com o sistema legado, com foco em perdas funcionais, divergências conceituais e regressões operacionais.

Estudo dos Fluxos Operacionais

Avaliação dos fluxos críticos de negócio, identificando pontos de intervenção manual, dependências externas, quebras de automação e fragilidades de rastreabilidade.

Observação Técnica Direta

Registro técnico das limitações estruturais, inconsistências funcionais e lacunas de governança observadas durante a operação, sem a utilização de inferências ou hipóteses não verificáveis.

Referência aos Anexos

Os fluxos detalhados, exemplos práticos, registros operacionais e evidências técnicas que fundamentam esta metodologia encontram-se consolidados no Anexo I – Evidências Técnicas e Operacionais e no Anexo II – Matriz de Paridade Funcional (Sistema Legado x Sistema Atual).

Os desafios identificados ao longo da avaliação foram organizados em macroáreas temáticas, com o objetivo de facilitar a leitura executiva, o enquadramento de riscos e a definição de prioridades estratégicas. As não conformidades e lacunas observadas concentram-se nas seguintes áreas:

• Fundação e Legado: Aspectos estruturais relacionados à arquitetura herdada e à ausência de reengenharia sistêmica.
• Processos e Automação: Fragilidades nos fluxos transacionais e dependência excessiva de intervenções manuais.
• Tecnologia Blockchain: Limitações na integração, automação e uso efetivo da blockchain como componente estrutural do sistema.
• Governança de Dados e Identidade: Problemas de unificação de identidade, rastreabilidade e consistência dos dados.
• Cadastro e Gestão de Usuários: Inconsistências cadastrais, ausência de ciclo de vida adequado e lacunas de governança.
• Movimentações, Saldos e Rastreabilidade: Divergências conceituais, perda de padronização e dificuldades de auditoria.
• Conformidade e Fluxos de Aprovação: Fragilidades nos controles documentais e nos processos de validação.
• Acesso e Operação Interna: Aspectos relacionados ao uso do sistema pelo back-office e à execução operacional.
• Usabilidade e Experiência do Usuário: Barreiras de interação que elevam o risco operacional e o retrabalho.
• Sustentação e Governança Operacional: Deficiências no suporte técnico, ausência de SLA e fragilidade na governança do serviço.

Referência aos Anexos: A relação completa de não conformidades, exemplos práticos e impactos associados a cada área está detalhada nos Anexos I, II e III.

5.1 Replicação sem Reengenharia

O sistema atual foi concebido a partir de uma replicação direta das estruturas, lógicas e conceitos do sistema legado, sem a realização de uma reengenharia profunda que considerasse os novos requisitos de escala, automação e governança do modelo de negócio da BMV. Essa abordagem manteve limitações históricas e transferiu fragilidades estruturais para o novo ambiente tecnológico.

5.2 Consequências Estruturais

Como consequência direta dessa herança não reestruturada, foram observados:

• Acúmulo significativo de dívida técnica;
• Fragilidade no processo de evolução e manutenção do sistema;
• Dependência recorrente de operações manuais;
• Baixa adaptabilidade a cenários de crescimento.

Referência aos Anexos: A análise comparativa entre arquitetura legada e atual encontra-se detalhada no Anexo II – Matriz de Paridade Funcional.

6.1 Visão Geral do Fluxo Atual (AS-IS)

Além dos fluxos de movimentação de saldo, observa-se fragilidade estrutural semelhante no processo de solicitação e emissão da CDE – Certidão de Disponibilidade de Estoque, apesar da existência de uma página dedicada no sistema. O fluxo atual permanece majoritariamente manual e externo ao sistema, com dependência de e-mail, aprovações humanas sequenciais e emissão de boleto fora da plataforma.

Fluxo AS-IS – Solicitação de CDE:

1. Cliente realiza a solicitação por e-mail;
2. Back-office (BMV) analisa e solicita aprovação interna;
3. Emissão manual de boleto via plataforma externa (OMIE);
4. Cliente realiza o pagamento fora do sistema;
5. Após confirmação manual, a CDE é emitida e enviada por e-mail.

Esse modelo não configura uma jornada digital, apesar da existência de interface sistêmica, caracterizando uma funcionalidade incompleta e não operacionalizada.

6.2 Análise Técnica e Operacional

O fluxo atual de CDE apresenta os seguintes problemas críticos:

• Dependência integral de canais externos (e-mail e plataforma de cobrança);
• Ausência de integração sistêmica com meios de pagamento;
• Falta de vínculo automático entre solicitação, boleto, compensação bancária e emissão da certidão;
• Necessidade de validação manual pós-pagamento;
• Back-office atuando como executor, e não como supervisor.

Apesar da existência da página de solicitação no sistema, o fluxo não é end-to-end, o que compromete seu propósito funcional.

6.3 Enquadramento como Não Conformidade Estrutural

A situação observada no fluxo de CDE não pode ser classificada como limitação pontual ou melhoria futura, pois:

• O processo já possui interface dedicada;
• A expectativa funcional já está implicitamente criada para o usuário;
• O modelo atual viola princípios mínimos de automação transacional, rastreabilidade, escalabilidade e governança financeira.

Trata-se, portanto, de não conformidade estrutural, equivalente aos fluxos de movimentação de saldo e pedidos de certificados.

6.4 Diretriz de Correção (TO-BE)

O fluxo ideal de solicitação de CDE deve ser reestruturado para operar integralmente dentro da plataforma, contemplando:

• Solicitação realizada diretamente na carteira do cliente;
• Aprovação sistêmica ou administrativa registrada no sistema;
• Emissão automática de boleto via integração API (ex.: OMIE ou provedor equivalente);
• Disponibilização imediata do boleto ao cliente na plataforma;
• Monitoramento automático da compensação bancária;
• Emissão automática da CDE após confirmação de pagamento;
• Atuação do back-office restrita a exceções e auditoria.

O papel do back-office deve ser supervisório, e não operacional.

6.5 Integração com Meios de Pagamento (Ponto Crítico)

A manutenção da emissão de boletos fora do sistema representa:

• Risco operacional elevado;
• Quebra de rastreabilidade financeira;
• Fragilidade na conciliação;
• Dependência excessiva de validação manual.

Recomenda-se a integração via API com o provedor de cobrança atualmente utilizado (OMIE) ou equivalente, garantindo:

• Vínculo direto entre solicitação e pagamento;
• Confirmação automática da compensação;
• Gatilhos sistêmicos para liberação da CDE;
• Registro auditável de todo o ciclo financeiro.

Referência aos Anexos: Os fluxos AS-IS e TO-BE da solicitação de CDE encontram-se documentados no Anexo I – Evidências Técnicas e Operacionais, juntamente com os fluxos de intenção de movimentação e pedidos de certificados.

(Com referência visual aos fluxos operacionais – AS-IS x TO-BE)

7.1 Visão Geral e Enquadramento Técnico

A Blockchain constitui pilar central do modelo de negócio da BMV, sendo a base conceitual da tokenização das UCSs, da rastreabilidade das transações e da confiabilidade do sistema. No entanto, a análise técnica do sistema atual evidencia que essa tecnologia não está integrada de forma estrutural ao core transacional da plataforma.

Conforme ilustrado na Figura 1 – Jornada das UCSs no Sistema BMV (AS-IS) versus Jornada das UCSs na Blockchain (TO-BE), observa-se uma dissociação clara entre os fluxos operacionais internos do sistema e a camada blockchain, resultando em processos fragmentados, dependentes de intervenção manual e sem rastreabilidade automática ponta a ponta.

Figura 1 – Jornada das UCSs no Sistema BMV (AS-IS) x Jornada das UCSs na Blockchain (TO-BE)
(Fluxograma anexo elaborado pela equipe técnica da BMV)

7.2 Uso Atual da Blockchain (Modelo AS-IS)

No modelo atualmente implementado, a Blockchain é utilizada de forma passiva e registral, atuando apenas como repositório posterior de informações, sem participação ativa na automação, validação ou governança das operações.

De acordo com o fluxo superior apresentado na Figura 1 (Jornada das UCSs dentro do Sistema BMV), o ciclo de vida das UCSs ocorre majoritariamente fora da Blockchain, passando por etapas como:

• Geração de Safra
• Particionamento interno
• Custódia
• Trading / Investimento
• Transferências
• Fila de Vendas
• Aposentadoria

Nesse modelo:

• O particionamento das UCSs ocorre internamente no sistema;
• A distribuição entre produtor, BMV e associação não é refletida automaticamente na Blockchain;
• As wallets não são criadas de forma sistêmica;
• A atualização de saldos e registros blockchain depende de ações manuais posteriores.

Essa abordagem compromete a integridade do modelo de tokenização e impede que a Blockchain exerça seu papel como camada de confiança e motor transacional do sistema.

7.3 Fragilidades Estruturais Identificadas

A análise técnica identificou fragilidades estruturais críticas no modelo atual:

• Criação manual de wallets para produtores, associações e entidades;
• Replicação manual do particionamento das safras na Blockchain;
• Ausência de sincronização automática de saldos entre o sistema e as wallets;
• Inexistência de filas blockchain-orientadas para aposentadoria e movimentações;
• Risco elevado de inconsistência, erro humano e retrabalho operacional.

Essas fragilidades tornam o modelo operacional incompatível com cenários de crescimento, múltiplas safras e aumento do volume transacional.

7.4 Modelo Recomendado – Blockchain Integrada ao Core (TO-BE)

O fluxo inferior da Figura 1 (Jornada das UCSs dentro da Blockchain – Polkadot) representa o modelo estrutural recomendado, no qual a Blockchain deixa de ser acessória e passa a integrar o núcleo transacional do sistema.

Nesse modelo:

• Cada produtor, associação e a BMV possuem uma wallet única, persistente e automática, criada no momento do cadastro;
• A geração de safra dispara automaticamente o particionamento tokenizado;
• A distribuição das UCSs ocorre conforme a regra de negócio:
  • 1/3 para o produtor
  • 1/3 para a BMV
  • 1/3 para a associação
• Novas safras não geram novas wallets, mas sim abastecimentos automáticos nas wallets existentes;
• Todas as movimentações são registradas como transações blockchain rastreáveis;
• A aposentadoria de UCSs ocorre por meio de filas de processamento, garantindo ordem lógica, consistência de saldo e rastreabilidade completa.

Esse modelo assegura mutabilidade auditável, integridade transacional e escalabilidade real do sistema.

7.5 Filas de Processamento, Saldos e Rastreabilidade

A existência de filas de processamento é elemento crítico para o equilíbrio operacional do ecossistema BMV. No modelo recomendado:

• Cada aposentadoria ou movimentação de UCS entra em uma fila lógica de execução;
• O sistema valida automaticamente saldo disponível, entidade proprietária e ordem cronológica;
• A Blockchain registra saldo anterior, quantidade aposentada ou transferida, saldo final e hash da transação.

Esse mecanismo garante que, por exemplo, ao aposentar 3 UCSs de um produtor com saldo de 50 UCSs, o sistema atualize corretamente o saldo, preserve o histórico completo e mantenha rastreabilidade plena para auditoria futura.

7.6 Limitações do Modelo Atual em Escala

A ausência dessa integração estrutural gera riscos críticos em cenários de escala:

• Inviabilidade de operar múltiplas safras simultâneas;
• Necessidade de criar wallets retroativas para safras já processadas (ex.: safra 2010);
• Comprometimento das safras futuras devido a inconsistências acumuladas;
• Impossibilidade de garantir rastreabilidade completa das UCSs;
• Exposição elevada a riscos operacionais, financeiros e jurídicos.

No estado atual, a continuidade das subidas de safra sem a correção estrutural da camada blockchain amplifica o retrabalho e a dívida técnica, colocando em risco a integridade de todo o ecossistema.

7.7 Diretrizes Técnicas Mandatórias

Com base na análise e no fluxo TO-BE apresentado, estabelecem-se como diretrizes técnicas obrigatórias:

• Criação automática de wallets no cadastro de entidades;
• Integração direta da Blockchain ao core transacional;
• Distribuição automática de UCSs conforme regra de negócio;
• Uso de filas de processamento para aposentadorias e movimentações;
• Registro completo, auditável e rastreável de todas as transações;
• Eliminação de qualquer dependência manual para tokenização e controle de saldo.

Referência aos Anexos: Anexo I – Evidências Técnicas e Operacionais; Anexo III – Matriz de Risco; Anexo V – Cenários de Tokenização e Movimentação de UCSs.

8.1 Identidade de Negócio Não Unificada

O sistema não adota uma identidade de negócio única e consistente, utilizando identificadores técnicos distintos entre tabelas e módulos.

8.2 Impactos Observados

Essa abordagem compromete:

• A rastreabilidade dos dados;
• A consistência das informações;
• A segurança e confiabilidade em processos de auditoria.

Referência aos Anexos: Os impactos práticos e exemplos de inconsistência encontram-se descritos no Anexo III – Matriz de Risco do Sistema BMV.

9.1 Inconsistências de Dados Cadastrais

Nomes Incompletos: Em alguns cenários, o sistema exibe apenas o primeiro nome do usuário, mesmo quando o cadastro foi corretamente preenchido com nome e sobrenome.

Análise: Essa falha compromete a identificação inequívoca do cliente, impacta relatórios operacionais e gerenciais e fragiliza a governança dos dados cadastrais. A exibição incompleta do nome em diferentes telas gera inconsistência na experiência do usuário e aumenta o risco de duplicidade ou erro na interpretação de registros.

Referência ao Anexo: As evidências técnicas, incluindo a relação de telas afetadas e registros operacionais associados, encontram-se detalhadas no Anexo I – Evidências Técnicas e Operacionais.

9.2 Gestão de Usuários (Inativação e Exclusão)

Arquivamento Lógico Ausente: Não há um processo formal e estruturado para o arquivamento lógico de usuários que deixaram de interagir com o ecossistema (e-commerce), mantendo registros inativos na base operacional ativa.

Impossibilidade de Exclusão Definitiva: Inexiste funcionalidade para a exclusão física e permanente de cadastros (clientes ou registros), inclusive em casos de erro de preenchimento, duplicidade ou encerramento da relação comercial.

Análise: A ausência de mecanismos adequados para o gerenciamento do ciclo de vida dos usuários gera acúmulo indevido de dados, aumenta a dívida técnica da base cadastral e impacta negativamente a performance do sistema. Além disso, expõe a empresa a riscos de compliance e governança da informação, ao manter registros desnecessários, desatualizados ou incorretos na base ativa.

Referência ao Anexo: O detalhamento do fluxo operacional atual, bem como a avaliação de riscos associados, encontra-se descrito no Anexo III – Matriz de Risco do Sistema BMV.

10.1 Divergência na Nomenclatura e no Mapeamento dos Estados de Saldo

Foi identificada uma inconsistência estrutural entre o sistema atualmente em uso e o sistema legado no que se refere à nomenclatura, classificação e mapeamento dos estados de saldo associados às movimentações financeiras.

Como exemplo, uma mesma operação é registrada no sistema atual como DIS > DIS, enquanto no sistema legado a movimentação equivalente é apresentada como RES > APO. Essa divergência evidencia desalinhamento conceitual e semântico entre os ambientes, comprometendo a correta interpretação da natureza da transação e seus impactos sobre os saldos.

Referência ao Anexo: A matriz comparativa completa entre os estados de saldo do sistema legado e do sistema atual encontra-se no Anexo II – Matriz de Paridade Funcional (Sistema Legado x Sistema Atual).

10.2 Esclarecimento e Posicionamento do Fornecedor (Multiledgers)

Em resposta formal, a Multiledgers esclareceu que a limitação de filtros na tela de movimentações foi uma decisão intencional de escopo, adotada com o objetivo de acelerar a disponibilização da plataforma e permitir a rápida operacionalização das transações com clientes externos da BMV.

• A tela de movimentações foi previamente apresentada e discutida com a equipe da BMV;
• Optou-se conscientemente pela redução do número de filtros, entendendo-se que três categorias seriam suficientes no momento inicial;
• A limitação não configura bug ou falha técnica, mas decisão estratégica de priorização funcional e time-to-market;
• A ampliação dos filtros deverá ser tratada como nova demanda, sujeita a replanejamento e redefinição de prioridades.

Referência ao Anexo: O posicionamento formal do fornecedor e os registros de alinhamento encontram-se consolidados no Anexo I – Evidências Técnicas e Operacionais.

10.3 Análise Técnica Independente

Embora o posicionamento do fornecedor descarte a caracterização de defeito técnico isolado, a análise técnica independente identificou que a ausência de padronização de nomenclaturas, combinada à redução funcional em relação ao sistema legado, gera impactos relevantes sob as perspectivas técnica, operacional e de governança.

Foram identificadas as seguintes consequências:

• Geração de ruído operacional, dificultando a leitura correta das movimentações e seus efeitos reais sobre os saldos;
• Prejuízo à auditoria e à rastreabilidade, comprometendo validações históricas, conciliações e auditorias independentes;
• Risco de inconsistência conceitual, com desalinhamento entre regras de negócio do sistema atual e conceitos consolidados no legado;
• Dependência de conhecimento tácito, exigindo interpretação implícita por parte dos usuários, elevando o risco operacional.

Adicionalmente, observou-se que:

• Todas as movimentações estão sendo registradas como “Distribuição”, independentemente de sua natureza real;
• Não há identificação clara do tipo de transação (transferência, distribuição, reserva, aposentadoria, etc.);
• Inexistem filtros essenciais para análise e segregação das movimentações.

Como consequência prática, operações de transferência podem ser interpretadas como distribuições, distorcendo a lógica financeira e contábil do fluxo.

Referência ao Anexo: Os cenários analisados e os exemplos de distorção de classificação encontram-se detalhados no Anexo II – Matriz de Paridade Funcional.

10.4 Enquadramento no Dossiê

Este item permanece classificado como Não Conformidade Funcional de Governança e Usabilidade, não por erro de implementação técnica isolado, mas por inadequação estrutural ao modelo operacional, financeiro e de controle historicamente consolidado pela BMV.

Trata-se de uma não conformidade de impacto transversal, afetando confiabilidade, auditoria, conciliação e governança dos dados transacionais.

10.5 Contexto de Urgência e Importância Estratégica

A ausência de padronização nos estados de saldo, aliada à limitação funcional de filtros, representa risco sistêmico elevado nos pilares de Governança, Conformidade e Auditoria. Essas inconsistências reduzem a confiabilidade dos dados transacionais e afetam a credibilidade da plataforma perante auditorias externas, parceiros institucionais e questionamentos regulatórios ou jurídicos.

As ações necessárias não configuram melhorias de usabilidade ou ajustes estéticos, mas correções mandatórias de alinhamento funcional e estratégico, indispensáveis para garantir integridade dos saldos, rastreabilidade histórica das operações e validação segura em processos de conciliação financeira.

A regra de negócio associada a este tema deve ser tratada como diretriz de correção de alto risco, sendo inegociável para a saúde operacional, financeira e jurídica da BMV.

11.1 Falha no Fluxo de Reenvio de Documentos

Foi identificada falha no fluxo de reenvio de documentos, na qual documentos reenviados após correção permanecem indevidamente com status de “recusado”, mesmo após novo upload. Essa inconsistência indica quebra na lógica de atualização de status e controle de estados do documento, comprometendo o fluxo de validação e gerando bloqueios operacionais artificiais, retrabalho e dependência de intervenções manuais.

Do ponto de vista de governança, trata-se de não conformidade funcional crítica, com impacto direto em auditorias, SLA operacionais e experiência do usuário interno.

Referência ao Anexo: Os fluxos afetados e os registros de inconsistência encontram-se detalhados no Anexo I – Evidências Técnicas e Operacionais.

11.2 Ausência de Versionamento Documental

Foi constatada a inexistência de mecanismo formal e sistemático de versionamento documental, incluindo controle de versões, histórico de alterações, autoria, data de modificação e trilha de auditoria. Essa lacuna compromete a governança da informação, a rastreabilidade histórica e a confiabilidade dos registros, além de dificultar auditorias, validações regulatórias e controles de mudança. Trata-se de não conformidade relevante, incompatível com ambientes que exigem integridade da informação e responsabilidade técnica claramente atribuída.

Referência ao Anexo: A avaliação de impacto e os riscos associados à ausência de versionamento encontram-se descritos no Anexo III – Matriz de Risco do Sistema BMV.

Foram identificadas deficiências relevantes na experiência do usuário, incluindo:

• Ausência de sinalização clara de campos obrigatórios;
• Carência de tooltips, legendas e orientações contextuais;
• Interfaces com navegação e interação pouco intuitivas.

Análise

Essas limitações aumentam a curva de aprendizado, elevam a incidência de erros operacionais e impactam negativamente a eficiência do uso do sistema.

Referência ao Anexo: Os exemplos práticos e evidências relacionadas à usabilidade encontram-se consolidados no Anexo I – Evidências Técnicas e Operacionais.

13.1 Controle de Acesso e Gestão de Perfis

O sistema BMV apresenta um mecanismo de controle de acesso bem estruturado e tecnicamente adequado, baseado em um menu granular de permissões, que permite o gerenciamento detalhado dos níveis de acesso por perfil de usuário. A plataforma contempla múltiplos níveis de acesso, variando desde clientes até administradores (ADM), possibilitando a definição precisa de permissões para visualização, execução e gestão de funcionalidades. Do ponto de vista de segregação de funções e controle de permissões, o sistema demonstra maturidade técnica e não apresenta não conformidades relevantes nesse aspecto.

13.2 Lacuna Estrutural de Auditabilidade das Ações

Apesar da robustez no controle de acesso, foi identificada uma lacuna estrutural relevante relacionada à auditabilidade e rastreabilidade das ações executadas no sistema. Atualmente, não é possível identificar de forma clara e rastreável qual usuário executou determinada ação, quando a ação foi realizada (data e hora) e o contexto operacional da alteração.

Essa limitação afeta operações críticas, tais como:

• Lançamento e alteração de safras;
• Execução e processamento de movimentações;
• Alterações manuais em registros operacionais;
• Processamento de transações sensíveis.

Em telas como Movimentações, por exemplo, não há indicação visível ou facilmente acessível do usuário responsável pela transação, o que inviabiliza a identificação de autoria em caso de erro, inconsistência ou necessidade de investigação operacional.

13.3 Impactos Operacionais e de Governança

A ausência de trilha de auditoria gera impactos diretos nos seguintes pilares:

• Rastreabilidade operacional: dificuldade na reconstrução de eventos e análise de causa-raiz;
• Auditoria interna e externa: limitação na comprovação de autoria e responsabilidade;
• Governança de dados: fragilidade no controle de alterações críticas;
• Gestão de riscos: aumento da dependência de conhecimento tácito e comunicação informal.

Cabe destacar que essa funcionalidade não foi identificada de forma clara nem no sistema atual nem no sistema legado, indicando que sua adoção exige alteração estrutural, e não simples correção pontual.

13.4 Classificação da Não Conformidade

Não Conformidade Estrutural de Governança e Auditabilidade.

Trata-se de uma lacuna relevante em sistemas que operam com transações, registros sensíveis e exigência de rastreabilidade, sendo incompatível com boas práticas de governança corporativa e tecnológica.

13.5 Diretriz Técnica Recomendada

Recomenda-se a implementação de um mecanismo formal de trilha de auditoria (audit trail), contemplando, no mínimo:

• Identificação do usuário responsável pela ação;
• Data e hora da execução;
• Tipo de operação realizada (criação, alteração, exclusão, processamento);
• Entidade afetada (safra, movimentação, usuário, entre outras).

Essa diretriz deve ser tratada como requisito estrutural de governança, e não como melhoria opcional, sendo essencial para elevar o nível de maturidade, confiabilidade e auditabilidade do Sistema BMV.

Referência ao Anexo: Os exemplos práticos, fluxos afetados e evidências da ausência de rastreabilidade encontram-se detalhados no Anexo I – Evidências Técnicas e Operacionais.

Esta seção descreve as principais deficiências identificadas na prestação de suporte técnico ao Sistema BMV e na governança que orienta os processos operacionais associados. Os pontos aqui apresentados impactam diretamente a disponibilidade da aplicação, a produtividade das equipes e a experiência dos clientes finais, tornando essencial a sua correção para garantir estabilidade, previsibilidade e escalabilidade do serviço.

14.1 Tempo de Resposta e Efetividade Operacional

Foi identificado um padrão recorrente de lentidão no atendimento por parte da equipe de suporte técnico, inclusive em demandas de baixa complexidade ou correções pontuais. Solicitações consideradas simples frequentemente levam dias para retorno ou resolução, comprometendo a continuidade das operações e a eficiência dos fluxos internos.

Em diversos cenários, a equipe de desenvolvimento apresentou dificuldades para destravar operações críticas do sistema. Como consequência, clientes que já haviam efetuado pagamentos de transações ficaram impossibilitados de prosseguir com seus processos por períodos prolongados, chegando a aguardar 3, 4 ou até 5 dias para a normalização do serviço.

Mesmo após a liberação dessas operações, observou-se a recorrência de novos erros ou falhas sistêmicas (bugs), o que gerou interrupções sucessivas e retrabalho. Esse ciclo contínuo de correções reativas evidencia a ausência de estabilização adequada do ambiente e resulta em um fluxo de trabalho pouco produtivo, afetando diretamente a performance operacional da empresa.

14.2 Ausência de Acordo de Nível de Serviço (SLA) e Impactos na Governança

A inexistência de um Acordo de Nível de Serviço (SLA) formal, documentado e amplamente comunicado representa uma falha crítica na governança operacional do Sistema BMV. Atualmente, não há critérios objetivos e transparentes que definam prioridades, tempos máximos de resposta e resolução ou fluxos claros de escalonamento.

Na prática, qualquer solicitação cujo tempo estimado de execução ultrapasse 20 minutos passa automaticamente a ser classificada como melhoria, independentemente de se tratar de uma correção simples ou ajuste necessário para o funcionamento adequado do sistema. Nessas situações, o atendimento fica condicionado à aprovação de níveis hierárquicos superiores da empresa prestadora, incluindo, em alguns casos, a diretoria.

Esse modelo gera entraves operacionais recorrentes, pois até mesmo correções básicas — como ajustes de layout em tabelas ou correções visuais — ficam paralisadas caso extrapolem esse limite de tempo. A ausência de critérios claros e previamente acordados resulta em: falta de previsibilidade no atendimento das demandas; dificuldade para destravar pendências operacionais; desalinhamento de expectativas entre as equipes técnicas e os usuários; e impossibilidade de planejamento adequado das atividades operacionais.

Além disso, não existem definições formais sobre: critérios de priorização (Crítica, Alta, Média ou Baixa); prazos-alvo de resposta e solução (Target Times); e fluxo estruturado de escalonamento, permitindo que demandas não resolvidas avancem automaticamente para níveis superiores de suporte ou desenvolvimento.

Essa lacuna de governança compromete a mensuração de desempenho do suporte, dificulta a responsabilização em casos de falhas e impacta directamente a disponibilidade e a confiabilidade da aplicação. Como consequência, o cenário atual tem limitado a capacidade de escalar os serviços de forma sustentável, prejudicando tanto a operação quanto a estratégia de crescimento das partes envolvidas.

Diante desse contexto, torna-se fundamental estabelecer, de forma clara e acordada entre os envolvidos, o tempo efetivamente dedicado ao projeto, os limites de atuação do suporte e os critérios objetivos para distinção entre correções e melhorias, a fim de destravar pendências recorrentes, aumentar a eficiência operacional e garantir maior previsibilidade e estabilidade ao Sistema BMV.

A implementação urgente de um SLA estruturado é recomendada como medida essencial para assegurar um padrão mínimo de qualidade, governança e desempenho do serviço prestado.

Os riscos identificados ao longo desta avaliação foram consolidados por categoria, considerando impacto operacional, probabilidade de ocorrência e efeito sistêmico sobre a operação da BMV. Estes riscos não são hipotéticos: decorrem de falhas estruturais observadas em ambiente produtivo e devidamente evidenciadas nos Anexos Técnicos.

15.1 Riscos Operacionais

• Dependência excessiva e recorrente de processos manuais para execução de transações básicas;
• Gargalos estruturais no back-office, inviabilizando ganhos de escala;
• Dificuldades recorrentes na análise de movimentações, saldos e históricos;
• Aumento do retrabalho operacional e da exposição a erro humano;
• Impossibilidade de operação fluida sem intervenção constante de equipes internas.

15.2 Riscos Financeiros

• Atrasos no processamento de transações já pagas por clientes;
• Risco de alocação incorreta de UCS (safra, núcleo ou entidade equivocada);
• Fragilidade na conciliação financeira e na validação de saldos;
• Elevação contínua do custo operacional para sustentar o mesmo volume transacional;
• Dificuldade de comprovação clara e tempestiva de eventos financeiros.

15.3 Riscos Tecnológicos

• Arquitetura herdada do sistema legado sem reengenharia adequada;
• Uso da Blockchain de forma passiva, sem integração funcional ao core;
• Ausência de automação na criação e abastecimento de wallets;
• Baixa rastreabilidade técnica e inconsistência de identificadores;
• Dependência estrutural de intervenções humanas para processos sistêmicos.

15.4 Riscos Jurídicos e de Conformidade

• Fragilidade na comprovação de integridade e autoria das transações;
• Exposição relevante em auditorias externas e questionamentos regulatórios;
• Dependência de controles manuais para processos críticos;
• Risco de contestação contratual por não atendimento a requisitos funcionais essenciais;
• Dificuldade de sustentação probatória em cenários de litígio.

15.5 Riscos Estratégicos

• Inviabilidade de crescimento em escala (20 a 30 mil clientes);
• Comprometimento da credibilidade do modelo BMV perante parceiros e investidores;
• Dependência excessiva do fornecedor atual para operação básica;
• Limitação severa da capacidade de evolução tecnológica do negócio.

As recomendações a seguir não tratam de melhorias incrementais, ajustes cosméticos ou otimizações pontuais. Tratam-se de diretrizes estruturais obrigatórias para garantir a sustentabilidade técnica, operacional e jurídica do sistema.

16.1 Reengenharia do Core Transacional

• Redesenhar fluxos críticos com foco em automação end-to-end;
• Separar claramente execução sistêmica de supervisão humana;
• Eliminar dependências manuais para transações básicas.

16.2 Automação como Princípio Estrutural

• Automatizar transferências padrão, abastecimentos e movimentações recorrentes;
• Restringir aprovação humana a exceções justificadas;
• Implementar processamento assíncrono e filas de execução.

16.3 Integração Efetiva da Blockchain

• Criar wallets automaticamente no cadastro de entidades;
• Abastecer wallets automaticamente a cada safra;
• Garantir vínculo direto e verificável entre blockchain, saldos e movimentações.

16.4 Revisão Integral da Governança Técnica

• Unificar identificadores de negócio;
• Padronizar nomenclaturas, estados e filtros;
• Estabelecer SLA formal e mensurável;
• Definir roadmap técnico com marcos claros e verificáveis.

O detalhamento completo das não conformidades identificadas neste dossiê encontra-se documentado nos Anexos Técnicos, que constituem parte integrante e indissociável deste relatório.

Este corpo principal estabelece:

• O enquadramento formal das não conformidades;
• Os critérios de criticidade e governança;
• A obrigatoriedade de correção;
• O vínculo direto com SLA técnico-operacional.

As não conformidades constantes nos anexos:

• Não configuram backlog evolutivo;
• Não são sugestões de melhoria;
• Não estão sujeitas a postergação sem justificativa formal;
• Possuem caráter mandatório e auditável.

18.1 Natureza do Registro

Esta seção consolida os ajustes definidos como obrigatórios, imediatos e não negociáveis, constituindo instrumento formal de cobrança técnica e operacional ao fornecedor.

Os itens aqui enquadrados impactam diretamente:

• Continuidade operacional;
• Governança do sistema;
• Confiabilidade dos dados;
• Capacidade de auditoria;
• Conformidade regulatória;
• Escalabilidade do modelo BMV.

Este registro possui caráter deliberativo, vinculante e auditável, sendo complementado pelas evidências constantes nos Anexos Técnicos.

18.2 Enquadramento de SLA e Obrigação do Fornecedor

• Os prazos de correção devem ser formalmente apresentados;
• Cada entrega deve conter evidência funcional e validação;
• Entregas parciais ou incompletas não serão aceitas;
• O descumprimento caracteriza quebra de SLA técnico-operacional.

18.3 Vínculo com Anexos Técnicos

Os registros desta seção referenciam diretamente:

• Anexo I – Evidências Técnicas e Operacionais;
• Anexo II – Linha do Tempo de Suporte;
• Anexo III – Matriz de Risco;
• Anexo IV – Matriz de Paridade Funcional;
• Anexo V – Cenários de Tokenização e Movimentação de UCSs;
• Anexo VI – Registro de Comunicação WhatsApp.

Este dossiê fornece base técnica, documental e objetiva para:

• Avaliação de cumprimento contratual;
• Caracterização de quebra de SLA;
• Análise de riscos de continuidade do sistema;
• Apuração de responsabilidades técnicas e operacionais;
• Sustentação técnica em eventuais questionamentos jurídicos.

Estado Atual do Sistema

O sistema BMV, em seu estado atual, não atende aos requisitos mínimos de maturidade tecnológica, automação, governança de dados, rastreabilidade operacional e capacidade de escala necessários para sustentar, de forma segura, confiável e contínua, o modelo de negócio da organização.

Esclarecimento sobre a Natureza da Avaliação

Ressalta-se, de forma inequívoca, que esta avaliação possui natureza estritamente técnica, orientada à qualidade do serviço sistêmico entregue — e não à qualidade do atendimento prestado pela equipe de suporte. A equipe responsável demonstra postura colaborativa e diligente, atuando dentro das limitações impostas pelo modelo atual.

Contudo, esforço operacional e boa vontade não substituem arquitetura adequada, automação consistente, escalabilidade e governança técnica efetiva.

Classificação Inadequada de Falhas

Falhas estruturais e funcionais vêm sendo recorrentemente enquadradas como "melhorias evolutivas", quando, na realidade, configuram não conformidades mandatórias. Essa abordagem posterga correções críticas, distorce prioridades técnicas e mantém a operação exposta a riscos operacionais, financeiros, jurídicos e reputacionais relevantes.

Impacto no Cliente Final

O impacto direto dessas limitações sobre o cliente final merece destaque crítico. Clientes que já efetuaram pagamento de transações não podem aguardar dias para conclusão de processamento que deveria ocorrer de forma automática e imediata.

Interrupções dessa natureza geram paralisações artificiais na cadeia de prestação de serviços, afetando diretamente a qualidade percebida, a previsibilidade operacional e a confiança do mercado. Esses atrasos aumentam o risco de questionamentos contratuais e regulatórios, gerando risco reputacional elevado junto a clientes, parceiros e investidores.

⚠️ Ponto Crítico: Ausência de Integração Efetiva da Blockchain

Há um ponto técnico de gravidade máxima que se sobrepõe a todas as demais análises: a ausência de integração efetiva, automação e escalabilidade da camada de Blockchain.

A proposta conceitual e estratégica do sistema BMV está diretamente associada à tokenização, sendo a Blockchain o pilar central do modelo de negócio — e não um componente acessório. No entanto, conforme demonstrado neste relatório, a Blockchain atualmente opera de forma passiva, manual, não orquestrada e sem capacidade de escala, inviabilizando seu papel como motor transacional, mecanismo de rastreabilidade e base de confiança do sistema.

Sem uma Blockchain escalável, integrada e governada sistematicamente, não há tokenização viável, e consequentemente não há sustentação técnica para o modelo de negócio proposto.

Viabilidade de Escala

Do ponto de vista estratégico, o modelo operacional atual não comporta operação de maior escala. A dependência excessiva de processos manuais, aliada à fragilidade da camada blockchain, impede crescimento seguro, previsível e auditável.

Para expandir operações, é indispensável estabelecer nível substancialmente mais elevado de confiança no sistema, o que somente será possível por meio de correções estruturais profundas, priorizadas a partir da Blockchain.

Capacidade Técnica e Compromisso

Há capacidade técnica para evolução da solução. Contudo, essa evolução não ocorrerá sem:

• Dedicação adequada de tempo;
• Priorização executiva clara;
• Comprometimento estrutural por parte do fornecedor.

O projeto exige tratamento à altura de sua criticidade estratégica, com alocação de esforço compatível com a responsabilidade envolvida, de modo que a solução funcione de forma sustentável e equilibrada para ambas as empresas.

Cenários de Decisão para a Diretoria

A responsabilidade pela decisão estratégica recai sobre a Diretoria, que deverá deliberar, de forma objetiva e responsável, entre: