Gabriel Jesus Dantas; Anaximandro Anderson Pereira Melo De Souza

DOI: 10.22167/2675-6528-202600833

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

O avanço das fraudes digitais no sistema financeiro nacional motivou a Resolução Conjunta n° 6/2023 do Banco Central do Brasil, que tornou obrigatória a troca de informações sobre suspeitas de fraude entre instituições financeiras. Contudo, a norma não especificou a operacionalização técnica dessa troca, gerando soluções fragmentadas e preocupações com a Lei Geral de Proteção de Dados Pessoais (LGPD). Diante desse cenário, o trabalho objetivou elaborar uma proposta de API padronizada, formalizada pela especificação OpenAPI, para viabilizar o intercâmbio de dados de fraude entre diferentes instituições, observando as exigências regulatórias e o princípio da minimização de dados da LGPD. Adotou-se uma abordagem qualitativa exploratória, operacionalizada por meio de Estudo de Caso único, com pesquisa documental e revisão da literatura sobre APIs RESTful e o paradigma Design-First. O produto final consistiu em um contrato técnico em YAML, contemplando operações de inclusão e consulta de registros, utilizando hashes criptográficos HMAC-SHA256 com chave setorial compartilhada para pseudonimização dos identificadores e evitando o tráfego de dados pessoais em claro. Os resultados indicaram que o artefato desenvolvido cumpriu a exigência regulatória, apresentando-se como alternativa tecnicamente consistente, segura e uniforme para mitigar a assimetria informacional que compromete a atuação coordenada das instituições financeiras no combate à fraude. A pseudonimização foi o elemento central para compatibilizar a interoperabilidade com a proteção de dados.

Palavras-chave: Arquitetura de software; Design-First; Pseudonimização; Segurança cibernética; Sistema financeiro.

1. Introdução

O sistema bancário nacional tem vivenciado, nos últimos anos, um intenso processo de digitalização. Essa transformação é impulsionada tanto pela incorporação de novas soluções tecnológicas quanto pela evolução dos hábitos da clientela. Embora essa modernização tenha proporcionado ganhos inegáveis em agilidade e conveniência para os usuários, ela também ampliou significativamente a sofisticação e a quantidade de ataques cibernéticos direcionados ao setor financeiro. De fato, conforme um levantamento da Federação Brasileira de Bancos (Febraban, 2025), o combate a fraudes e a salvaguarda dos dados dos clientes figuram hoje entre as principais prioridades das instituições. Para tanto, recursos substanciais têm sido direcionados para ferramentas de inteligência preditiva e para mecanismos de autenticação em múltiplos fatores.

Apesar desses esforços, a atuação dos bancos frente a tais delitos ainda costuma ser pontual e desarticulada. Essa fragmentação cria um desequilíbrio informacional que favorece o criminoso, permitindo que um indivíduo barrado em determinada instituição possa, sem maiores obstáculos, tentar golpes semelhantes em outra que sequer tenha conhecimento de seu histórico. Com o propósito de enfrentar essa fragilidade de natureza sistêmica, o Banco Central do Brasil (Bacen) editou a Resolução Conjunta n° 6/2023, tornando mandatório que as instituições sob sua supervisão troquem entre si dados e indícios relacionados a tentativas ou ocorrências de fraude (Bacen, 2023).

A lógica subjacente à norma regulatória é fomentar um ambiente cooperativo, no qual o conhecimento sobre ameaças cibernéticas possa ser construído e compartilhado de forma coletiva. Contudo, a referida Resolução, em especial seu Artigo 4º, embora determine a comunicação entre os sistemas envolvidos, abstém-se de fixar um formato ou padrão tecnológico específico para viabilizar essa troca. Essa lacuna técnica abre espaço para que cada instituição implemente sua própria solução, gerando um mosaico de integrações proprietárias. Tal cenário tende a encarecer projetos, prolongar prazos de desenvolvimento e, crucialmente, multiplicar os pontos sensíveis à exposição de informações. Paralelamente, os agentes do setor precisam estar rigorosamente alinhados às disposições da Lei Geral de Proteção de Dados Pessoais (LGPD), Lei nº 13.709/2018, cujos princípios impõem cuidados rigorosos em matéria de privacidade, segurança da informação e, de maneira especial, a restrição do uso de dados pessoais ao estritamente necessário para cada finalidade (Brasil, 2018).

Sob a perspectiva da Engenharia de Software, o estilo arquitetural REST (Representational State Transfer), formalizado por Fielding (2000), estabeleceu os princípios que hoje orientam a construção de interfaces distribuídas escaláveis, caracterizadas por contratos stateless e recursos identificáveis por URIs. A adoção da filosofia Design-First, por sua vez, centra-se na definição prévia desses contratos por meio de especificações formais. Essa prática é reconhecidamente eficaz para que sistemas distintos dialoguem de modo estável, escalável e seguro, mesmo em contextos de grande volume de requisições simultâneas, facilitando a interoperabilidade e a manutenção (Almeida, 2025). Tais abordagens são fundamentais para desenvolver soluções robustas em ambientes complexos e regulados.

Considerando, portanto, a necessidade de harmonizar a interoperabilidade determinada pela autoridade reguladora com as salvaguardas de privacidade impostas pela legislação, este trabalho teve como objetivo geral propor o desenho de uma API (Application Programming Interface) padronizada, descrita por meio da especificação OpenAPI, voltada ao intercâmbio de indícios de fraude entre instituições financeiras, de modo a observar simultaneamente as exigências da Resolução Conjunta nº 6/2023 e a concretização técnica do princípio da minimização previsto na LGPD.

2. Material e Métodos

Este estudo configurou-se como uma pesquisa de natureza aplicada, com abordagem qualitativa e caráter exploratório. O delineamento metodológico adotado foi o Estudo de Caso único, com unidades de análise embutidas, conforme a proposição de Yin (2015). Essa escolha justificou-se pela natureza contemporânea do fenômeno investigado, que se encontrava em fase inicial de institucionalização, e pela impossibilidade de isolá-lo de seu contexto regulatório e sociotécnico.

O caso investigado concentrou-se no processo de institucionalização do compartilhamento interbancário obrigatório de indícios de fraude no sistema financeiro nacional. Esse processo foi instaurado pela Resolução Conjunta n° 6/2023 e regulamentado pela Resolução BCB nº 343/2023 (BACEN, 2023a, 2023b). Examinaram-se três dimensões como unidades de análise embutidas: a regulatória, a arquitetural e a de privacidade.

A dimensão regulatória compreendeu o conjunto normativo que delimita o compartilhamento de dados. A dimensão arquitetural abordou os padrões técnicos aplicáveis à comunicação interinstitucional em ambientes regulados. Por fim, a dimensão de privacidade referiu-se aos requisitos impostos pela Lei nº 13.709/2018 (Brasil, 2018) ao tratamento de dados pessoais no contexto estudado.

A investigação foi orientada pela proposição teórica de que é tecnicamente viável satisfazer simultaneamente a exigência regulatória de interoperabilidade e o princípio da minimização de dados. Isso seria alcançado mediante a formalização de um contrato de interface único, baseado no paradigma Design-First e em pseudonimização criptográfica, conforme a literatura especializada em arquitetura de APIs (Almeida, 2025; Fielding, 2000).

A coleta de dados apoiou-se em duas das seis fontes de evidência catalogadas por Yin (2015): a documentação e os artefatos físicos. Como fonte documental, examinaram-se os instrumentos normativos que instituíram e regulamentaram o fenômeno, incluindo a Resolução Conjunta n° 6/2023 (BACEN, 2023b), a Resolução BCB nº 343/2023 (BACEN, 2023a) e a Lei nº 13.709/2018 (Brasil, 2018).

Complementaram-se as fontes documentais com normas técnicas de referência para a dimensão arquitetural, como a especificação OpenAPI 3.0.3 (OAI, 2020), as RFCs 6749 e 7519 (IETF, 2012, 2015), a norma ABNT NBR ISO/IEC 27002 (ABNT, 2022) e a publicação NIST SP 800-107 (NIST, 2012). Adicionalmente, utilizou-se a literatura científica especializada em arquitetura de software distribuída (Almeida, 2025; Fielding, 2000) para fundamentar as decisões de projeto.

Como fonte de artefato físico, considerou-se a própria especificação de API desenvolvida ao final do estudo, a qual foi submetida a validação sintática. O processo analítico e de desenvolvimento do artefato foi conduzido em três etapas sequenciais, visando garantir a rastreabilidade entre as evidências coletadas e o produto final.

Na primeira etapa, realizou-se a análise de conteúdo das fontes normativas. A partir dessa análise, derivaram-se os requisitos funcionais, relativos às operações que o sistema deveria oferecer para viabilizar o compartilhamento, e os requisitos não funcionais, vinculados a aspectos de segurança e proteção à privacidade.

Na segunda etapa, os requisitos identificados foram convertidos em especificações técnicas formalizadas, seguindo a filosofia Design-First, que preconiza a elaboração do contrato da interface antes de qualquer esforço de codificação. Essa etapa compreendeu três atividades encadeadas para a construção do artefato.

A primeira atividade consistiu na modelagem dos schemas de dados, estruturados com base na técnica de pseudonimização. Utilizou-se o algoritmo criptográfico HMAC-SHA256 com chave setorial compartilhada, aplicado sobre os identificadores dos titulares (CPF/CNPJ), em consonância com o princípio da minimização previsto no Art. 6º, III da Lei nº 13.709/2018 (Brasil, 2018).

A segunda atividade correspondeu à especificação dos endpoints, por meio da definição das rotas e dos respectivos métodos HTTP. Esses métodos foram responsáveis por suportar o ciclo de vida das informações de fraude, contemplando as operações de inclusão e de consulta de registros.

A terceira atividade dedicou-se à configuração dos mecanismos de segurança, estabelecidos em duas camadas complementares. Na camada de transporte, adotou-se a autenticação mútua via mTLS. Na camada de aplicação, empregou-se a autorização baseada em tokens JWT, obtidos via fluxo client_credentials do protocolo OAuth 2.0.

Na terceira etapa, o artefato resultante foi materializado em arquivo no formato YAML, em conformidade com a especificação OpenAPI 3.0.3 (OAI, 2020). Esse arquivo foi submetido a validação sintática por meio do editor Swagger Editor, procedimento que permitiu assegurar a correção formal do contrato técnico e sua plena reprodutibilidade.

Por fim, registrou-se que o desenvolvimento deste trabalho não envolveu participação direta de pessoas nem manipulação de dados pessoais identificáveis. Essa situação foi devidamente atestada pelo Formulário de Direcionamento Ético (FDE).

3. Resultados e Discussão

Os resultados da pesquisa são apresentados e discutidos em conformidade com o processo analítico adotado, que se desdobrou em três etapas principais: a extração de requisitos a partir de fontes documentais, a construção do artefato técnico proposto e sua subsequente validação sintática. A interpretação dos achados foi realizada à luz da literatura especializada em arquitetura de APIs e segurança da informação, com foco na aderência às exigências regulatórias e na delimitação do escopo do artefato desenvolvido. Esta abordagem sistemática garantiu a rastreabilidade entre as evidências coletadas e o produto final, conforme a metodologia estabelecida.

Requisitos derivados da análise documental

A análise de conteúdo das fontes normativas, que incluiu a Resolução Conjunta nº 6/2023, a Resolução BCB nº 343/2023 e a Lei nº 13.709/2018 (LGPD), permitiu a derivação sistemática dos requisitos que guiaram o desenvolvimento da API. Da Resolução Conjunta nº 6/2023, especialmente seu Artigo 4º, foram extraídos os requisitos funcionais essenciais: a capacidade de registrar indícios de fraude e a funcionalidade de consultar o histórico desses indícios entre as instituições financeiras autorizadas pelo Banco Central do Brasil (BACEN, 2023b). Esses requisitos formaram a base para as operações fundamentais da API.

Complementarmente, a Resolução BCB nº 343/2023 (BACEN, 2023a) forneceu os requisitos relativos aos atributos mínimos que deveriam compor cada registro de fraude a ser compartilhado. Esses atributos são cruciais para garantir que as informações trocadas sejam padronizadas e contenham os dados necessários para a identificação e análise de padrões de fraude. A Lei nº 13.709/2018 (Brasil, 2018), por sua vez, foi a fonte dos requisitos não funcionais, que impuseram restrições significativas ao tráfego de informações pessoais. Estes requisitos incluíram a minimização de dados (Art. 6º, III), a segurança no tratamento (Art. 6º, VII) e a pseudonimização (Art. 5º, XI), todos fundamentais para proteger a privacidade dos titulares.

O mapeamento detalhado entre os dispositivos normativos e os requisitos incorporados ao artefato demonstrou uma correspondência direta, reforçando a aderência da proposta ao arcabouço regulatório vigente. Por exemplo, o requisito funcional de registro de indício de fraude foi atendido pelo endpoint POST /fraudes, enquanto a consulta de histórico de indícios foi implementada pelo endpoint GET /fraudes/{hash_identificador}. A minimização de dados e a pseudonimização foram concretizadas pelo campo `hash_identificador` utilizando HMAC-SHA256, e a segurança no tratamento foi garantida por mTLS, OAuth 2.0 e JWT assinado, além da formalização do contrato a priori via Design-First, alinhado à ABNT NBR ISO/IEC 27002 (ABNT, 2022).

É importante salientar que, embora a Resolução BCB nº 343/2023 enumere um conjunto mais extenso de atributos para o registro de fraudes, o artefato desenvolvido neste trabalho contemplou apenas os quatro atributos centrais considerados mínimos viáveis. Essa decisão de projeto foi tomada em favor da parcimônia e da construção de um produto mínimo viável, reconhecendo-se que a ampliação do esquema para incluir a totalidade dos campos exigidos pelo regulador constitui um desdobramento natural e futuro para o trabalho. Esta limitação, contudo, não comprometeu a validação dos princípios fundamentais de interoperabilidade e proteção de dados no escopo definido.

Desenvolvimento do artefato: schemas, endpoints e segurança

A conversão dos requisitos identificados em especificações formais foi realizada seguindo a filosofia Design-First, resultando em três conjuntos de decisões arquiteturais interligadas. A arquitetura geral da solução proposta, que visa o compartilhamento de indícios de fraude (ACIF), foi concebida para permitir um fluxo bidirecional de informações entre as instituições participantes. Este desenho incorporou duas camadas complementares de segurança e definiu o papel crucial de uma autoridade certificadora setorial na custódia dos elementos criptográficos que sustentam a operação segura da rede, garantindo a integridade e a confidencialidade das comunicações.

O primeiro conjunto de decisões arquiteturais concentrou-se na modelagem do schema `IndicioFraude`, que representa a estrutura central da especificação da API. A principal escolha técnica neste ponto foi a implementação da pseudonimização por meio do campo `hash_identificador`. Este campo foi projetado para transportar o identificador do titular, seja Cadastro de Pessoa Física (CPF) ou Cadastro Nacional da Pessoa Jurídica (CNPJ), após ser submetido ao algoritmo criptográfico HMAC-SHA256 com uma chave setorial compartilhada. Essa abordagem assegurou que informações sensíveis não trafegassem em texto claro entre as instituições, cumprindo rigorosamente o princípio da minimização de dados da LGPD (Art. 6º, III) (Brasil, 2018).

A escolha do algoritmo HMAC-SHA256, em detrimento do SHA-256 convencional, foi estratégica para mitigar riscos de segurança. O CPF, por exemplo, possui um espaço finito de aproximadamente 10¹¹ combinações válidas, um volume que, em teoria, poderia permitir a um atacante com acesso à base compartilhada reverter os hashes por meio de um ataque de dicionário em tempo computacionalmente viável (NIST, 2012). A incorporação de uma chave setorial compartilhada no processo de derivação do hash, no entanto, tornou a reversão computacionalmente inviável sem o conhecimento dessa chave, mesmo diante do espaço finito de documentos. Este desenho garantiu que a pseudonimização atendesse materialmente aos dispositivos da LGPD relativos à minimização (Art. 6º, III) e ao conceito de dado pseudonimizado (Art. 5º, XI), conforme preconizado pela literatura em segurança por design (ABNT, 2022; Almeida, 2025).

Contudo, a adoção de uma chave setorial única introduziu um ponto crítico de concentração de risco. Um eventual comprometimento dessa chave implicaria a exposição retrospectiva de todos os identificadores pseudonimizados que trafegaram na rede. Para mitigar este risco, o desenho da API pressupõe a existência de uma autoridade coordenadora, como o próprio Banco Central do Brasil ou uma entidade por ele delegada, responsável pela custódia, rotação e revogação da chave em uma infraestrutura de módulo criptográfico dedicado. Embora alternativas criptográficas mais sofisticadas, como os protocolos Oblivious Pseudorandom Functions (OPRF) e Private Set Intersection (PSI), existam na literatura, sua adoção elevaria significativamente a complexidade operacional da rede, e por isso não foram contempladas no escopo deste trabalho.

O segundo conjunto de decisões arquiteturais envolveu a especificação dos endpoints da API. A estrutura desenvolvida contemplou dois recursos complementares para o compartilhamento de indícios de fraude. A operação de inclusão de um novo indício é realizada por meio de uma requisição HTTP POST para o recurso `/fraudes`. Já a operação de consulta do histórico de indícios é efetuada por meio de uma requisição HTTP GET para o recurso `/fraudes/{hash_identificador}`. A escolha por retornar um arranjo paginado de objetos na consulta por hash permite à instituição consulente obter uma visão temporal completa do histórico associado ao identificador, mitigando a assimetria de informação que o estudo buscou resolver.

A padronização das respostas de erro, utilizando o schema `ErroResposta`, e a adoção de códigos de status HTTP semanticamente consistentes foram decisões importantes para reduzir a ambiguidade na comunicação interinstitucional. Este aspecto é reconhecido na literatura como crítico para integrações entre sistemas heterogêneos (Almeida, 2025; Fielding, 2000), pois garante que as instituições possam interpretar de forma unificada as mensagens de sucesso ou falha, facilitando a depuração e a manutenção da interoperabilidade. A API, portanto, foi projetada para ser robusta e previsível em suas interações.

O terceiro conjunto de decisões referiu-se à configuração dos mecanismos de segurança, que foram estruturados em duas camadas complementares, seguindo as recomendações da literatura especializada em arquiteturas financeiras reguladas (ABNT, 2022; Almeida, 2025). Na camada de transporte, foi adotado o mutual TLS (mTLS), que estabelece autenticação bidirecional entre as instituições participantes. Este mecanismo impede o estabelecimento de conexões por partes não credenciadas, garantindo a confidencialidade e a integridade dos dados em trânsito. A autenticação mútua é fundamental para assegurar que apenas entidades confiáveis possam se comunicar na rede.

Na camada de aplicação, empregou-se o fluxo `client_credentials` do protocolo OAuth 2.0 (IETF, 2012), por meio do qual as instituições obtêm tokens de acesso na forma de JSON Web Tokens (JWT) assinados, conforme RFC 7519 (IETF, 2015), junto a uma autoridade certificadora setorial. Essa combinação de segurança, alinhada aos padrões já chancelados pelo Banco Central do Brasil no âmbito do Open Finance Brasil (BACEN, 2020), assegura a rastreabilidade completa de cada operação. Os tokens JWT contêm `claims` como `iss` (identificador da instituição emissora), `sub` (identificador da instituição consumidora), `exp` (timestamp de expiração), `scope` (escopo de acesso, como `fraudes:read` e `fraudes:write`) e `org_id` (identificador da organização no diretório de participantes), permitindo um controle granular e auditável das permissões e ações.

O encadeamento temporal das interações em uma operação de registro de indício de fraude demonstra a robustez do sistema. Inicialmente, a instituição notificante obtém um token JWT da Autoridade Certificadora Setorial via mTLS e fluxo `client_credentials`. Com o token assinado, a instituição envia a requisição POST /fraudes, também protegida por mTLS e contendo o JWT no cabeçalho `Authorization`. A API ACIF valida a assinatura do JWT e, se aprovada, persiste o indício de fraude na base compartilhada, retornando um status de sucesso. Este processo garante que cada etapa da comunicação seja autenticada e autorizada, desde o estabelecimento do canal até a confirmação do armazenamento do recurso.

Validação sintática e análise crítica

O artefato resultante das três etapas de construção, materializado em um arquivo YAML de aproximadamente 300 linhas, foi submetido a uma validação sintática rigorosa. A submissão do arquivo ao editor Swagger Editor permitiu verificar a conformidade sintática integral do documento em relação à especificação OpenAPI 3.0.3 (OAI, 2020). Este procedimento não resultou na ocorrência de avisos ou erros de validação, confirmando a correção formal do contrato técnico e assegurando sua plena reprodutibilidade por profissionais que venham a adotá-lo como referência de implementação. Essa validação formal é crucial para a interoperabilidade e a adoção da API no ecossistema financeiro.

Sob a perspectiva dos pontos positivos, a metodologia Design-First demonstrou ser altamente eficaz, produzindo um contrato agnóstico à linguagem de programação. Essa característica é fundamental para facilitar a adoção da API por instituições com pilhas tecnológicas heterogêneas, promovendo a interoperabilidade sem impor barreiras de tecnologia específicas. Além disso, a formalização prévia do contrato permitiu um mapeamento direto e auditável entre os dispositivos normativos e os elementos técnicos da API, conforme evidenciado na análise dos requisitos. Este atributo é reconhecido pela ABNT NBR ISO/IEC 27002 (2022) como um elemento central da abordagem de `security by design`, garantindo que a segurança seja considerada desde as fases iniciais do projeto.

No entanto, o trabalho também identificou limitações que merecem explicitação. Em primeiro lugar, o schema `IndicioFraude` contemplou apenas quatro atributos centrais, enquanto a Resolução BCB nº 343/2023 enumera um conjunto mais extenso de informações. Essa escolha foi uma decisão de projeto em favor da parcimônia e da construção de um produto mínimo viável, e a ampliação do schema para cobrir a totalidade dos campos exigidos pelo regulador é um desdobramento natural para trabalhos futuros. Em segundo lugar, a validação conduzida limitou-se à dimensão sintática, não abrangendo validações de desempenho, escalabilidade ou implementação de referência, atividades que ultrapassavam o escopo de um artefato de produto mínimo viável.

Em terceiro lugar, o desenho da API concentrou-se primariamente na interface de comunicação entre as instituições, não abordando os desafios de governança da autoridade certificadora setorial, a custódia da chave HMAC setorial, tampouco a arquitetura de persistência distribuída dos registros. Embora esses elementos sejam essenciais para a operacionalização plena do ecossistema de compartilhamento de fraudes, foram deliberadamente excluídos do escopo para manter a parcimônia e o foco na lacuna técnica identificada na introdução do estudo. Essas limitações, embora reconhecidas, não invalidam a contribuição central do artefato para a interoperabilidade e proteção de dados.

Em síntese, a pesquisa demonstrou a viabilidade técnica de uma API padronizada para o compartilhamento de indícios de fraude, formalizada pela especificação OpenAPI, que atende simultaneamente à exigência regulatória de interoperabilidade da Resolução Conjunta nº 6/2023 e ao princípio da minimização de dados da LGPD. A pseudonimização por meio de HMAC-SHA256 com chave setorial compartilhada emergiu como o elemento central para compatibilizar esses dois regimes, impedindo o tráfego de identificadores pessoais em texto claro e mitigando a assimetria informacional que compromete a atuação coordenada das instituições financeiras no combate à fraude. O artefato desenvolvido oferece uma alternativa tecnicamente consistente, segura e uniforme para o setor.

4. Conclusão

O presente estudo buscou propor o desenho de uma API padronizada, formalizada pela especificação OpenAPI, para viabilizar o intercâmbio de indícios de fraude entre instituições financeiras, harmonizando as exigências da Resolução Conjunta nº 6/2023 com o princípio da minimização de dados da LGPD. Verificou-se que a análise das normativas regulatórias permitiu a derivação de requisitos funcionais, como o registro e a consulta de indícios de fraude, e não funcionais, como a segurança e a pseudonimização. O artefato técnico desenvolvido, um contrato em YAML, incorporou a pseudonimização dos identificadores por meio de hashes criptográficos HMAC-SHA256 com chave setorial compartilhada, uma escolha que se mostrou eficaz para impedir o tráfego de dados pessoais em texto claro, mitigando riscos de ataques de dicionário. Adicionalmente, implementaram-se camadas de segurança robustas, com mTLS no transporte e OAuth 2.0 com JWTs assinados na aplicação, assegurando a autenticação e a autorização das operações. A metodologia Design-First, adotada no processo, demonstrou sua eficácia ao gerar um contrato agnóstico à linguagem de programação e permitir um mapeamento direto e auditável entre as exigências regulatórias e os elementos técnicos da API. A principal contribuição do trabalho reside na oferta de uma alternativa tecnicamente consistente, segura e uniforme para o sistema financeiro, capaz de mitigar a assimetria informacional que compromete a atuação coordenada das instituições no combate à fraude, com a pseudonimização como pilar central para compatibilizar a interoperabilidade com a proteção de dados.

Contudo, o estudo reconheceu algumas limitações. O schema IndicioFraude contemplou apenas quatro atributos centrais, uma decisão de parcimônia que não abrangeu a totalidade dos campos previstos na Resolução BCB nº 343/2023. A validação do artefato restringiu-se à dimensão sintática, sem incluir testes de desempenho, escalabilidade ou a criação de uma implementação de referência. Além disso, o desenho da API focou na interface de comunicação, sem aprofundar nos desafios de governança da autoridade certificadora setorial, na custódia da chave HMAC ou na arquitetura de persistência distribuída dos registros. Como desdobramentos futuros, sugere-se a ampliação do schema para incluir todos os atributos regulatórios, a realização de validações de desempenho e escalabilidade, e a investigação de protocolos criptográficos mais avançados, como Oblivious Pseudorandom Functions e Private Set Intersection, para reduzir a concentração de risco associada à chave setorial única.

Referências Bibliográficas

Banco Central do Brasil [BACEN]. 2023a. Resolução BCB nº 343, de 4 de outubro de 2023. Dispõe sobre as medidas necessárias à execução do compartilhamento de dados e informações sobre indícios de fraudes de que trata a Resolução Conjunta nº 6, de 23 de maio de 2023. Diário Oficial da União, Brasília, DF, 6 out. 2023. Seção 1, p. 112.

Brasil. 2018. Lei nº 13.709, de 14 de agosto de 2018. Lei Geral de Proteção de Dados Pessoais (LGPD). Diário Oficial da União, Brasília, DF, 15 ago. 2018. Seção 1, p. 59.

Federação Brasileira de Bancos [FEBRABAN]. 2025. Pesquisa Febraban de Tecnologia Bancária 2025 Volume 1. Disponível em: https://portal.febraban.org.br/pagina/3106/1117/pt-br/pesquisa. Acesso em: 29 out. 2025.

Fielding, R.T. 2000. Architectural Styles and the Design of Network-based Software Architectures. Tese de Doutorado em Informação e Ciência da Computação. University of California, Irvine

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy