Porque falha a detecção BC/FT sem qualidade dos dados: ingestão, mapeamento e regras de qualidade

Qualquer conversa sobre tecnologia de prevenção e combate ao branqueamento de capitais e financiamento do terrorismo (BC/FT) acaba por chegar à lógica de detecção — o engenho das regras de monitorização, a sofisticação do motor de filtragem, a exactidão do modelo de risco. Quase nenhuma dessas conversas começa onde o problema realmente começa: nos dados. No entanto, a detecção BC/FT raramente falha porque as regras foram mal escritas. Falha porque as regras foram alimentadas com dados incompletos, mal rotulados, duplicados ou desactualizados, e nenhuma regra, por mais bem concebida que seja, consegue detectar um padrão que os dados nunca registaram.

Porque falha a detecção BC/FT sem qualidade dos dados é a pergunta que as equipas de conformidade fazem tarde demais — geralmente durante uma inspecção, quando um regulador pergunta por que razão um padrão de fraccionamento, perfeitamente visível no sistema bancário central (core banking), nunca gerou um alerta. A resposta é, quase sempre, que o campo relevante chegou vazio, chegou num formato que o motor de monitorização não conseguia ler, ou nem sequer chegou. Este artigo percorre a camada pouco vistosa, mas decisiva, que está por baixo de cada controlo BC/FT: a forma como os dados de transacções e de clientes são ingeridos, mapeados, certificados e verificados quanto à qualidade antes de qualquer lógica de detecção ser executada. É um capítulo da história mais ampla contada no guia completo da plataforma BC/FT.

Lixo à entrada, lixo à saída: porque os dados são o verdadeiro controlo

A expressão é suficientemente antiga para ser um lugar-comum, mas em matéria de BC/FT está mais perto de uma lei da física. Uma regra de monitorização de transacções que procura depósitos em numerário ligeiramente abaixo de um limiar de comunicação só pode disparar se o montante do depósito, o indicador de numerário e a referência do cliente estiverem todos presentes, correctos e com o tipo de dados certo. Basta faltar um deles para que a regra fique em silêncio — não com um erro, mas com um resultado limpo e seguro que diz que nada de suspeito aconteceu. Esse silêncio é o modo de falha mais perigoso de todo o programa, porque tem exactamente o aspecto de um sucesso.

Veja-se o que os maus dados fazem a cada controlo, um de cada vez:

A avaliação do risco do cliente pontua o país, o sector de actividade, o produto, o canal, o comportamento e a exposição a pessoas politicamente expostas (PPE). Se o código do sector de actividade estiver em falta ou o campo do país contiver um erro de digitação em texto livre, o modelo reduz silenciosamente o peso de um factor que deveria ter assinalado, e um cliente de risco elevado é classificado como de risco baixo.
A filtragem compara nomes com listas de sanções, de PPE e de notícias negativas. Se um nome chegar truncado, transliterado de forma inconsistente ou repartido pelos campos errados, a correspondência aproximada (fuzzy matching) ou não detecta a ocorrência, ou enterra-a entre falsos positivos.
A monitorização de transacções avalia o comportamento ao longo do tempo. Se as transacções forem duplicadas por um fluxo de dados defeituoso, as regras de velocidade disparam em excesso; se um lote se perder, o fraccionamento que atravesse essa lacuna torna-se invisível.
As comunicações regulamentares compilam uma comunicação de operação suspeita ou de transacções em numerário a partir dos registos subjacentes. Se esses registos estiverem incompletos, a comunicação é rejeitada ou, pior, submetida com erros que mais tarde vêm à tona como uma constatação de inspecção.

Nenhuma destas falhas se anuncia. Degradam a detecção em silêncio, e é precisamente por isso que a qualidade dos dados tem de ser concebida como um controlo por direito próprio, e não pressuposta. A Plataforma BC/FT da Creodata trata-a dessa forma: a ingestão e os requisitos de dados são serviços de primeira linha, e não canalização acrescentada por baixo das funcionalidades «a sério». A prontidão dos dados é, na prática, um controlo do programa — a mesma disciplina que uma abordagem baseada no risco exige da pontuação de risco e da afectação de recursos, aplicada aos dados de entrada de que essas decisões dependem.

Ingestão: fazer entrar os dados sem os perder nem corromper

A maioria das instituições não tem uma única fonte de verdade. Tem um sistema bancário central, um ou mais comutadores de pagamentos (switches), um processador de cartões, uma plataforma de dinheiro móvel, uma base de dados mestre de clientes e um fornecedor de listas de sanções — cada um a falar um protocolo diferente, com um calendário diferente. O serviço de ingestão (Ingestion) existe para trazer tudo isso para a plataforma de forma fiável, qualquer que seja o formato em que cada fonte o emite.

Conectores para todas as fontes realistas

A plataforma inclui conectores para os protocolos com que as instituições realmente trabalham:

REST, para sistemas modernos e micro-serviços que expõem APIs.
SFTP, para os ficheiros em lote que os sistemas bancários centrais e de cartões ainda produzem durante a noite.
Kafka, para fluxos de eventos de grande volume, em que as transacções chegam continuamente.
CDC (captura de alterações de dados, change data capture), para ler inserções e actualizações directamente de uma base de dados de origem, sem esperar por uma extracção nocturna.
ISO 20022, a norma estruturada de mensagens financeiras para a qual as infra-estruturas de pagamento estão a convergir, em que formatos de mensagem ricos e bem tipificados transportam muito mais detalhe do que alguma vez transportaram os antigos ficheiros de largura fixa.

Suportar os cinco não é uma questão de amplitude pela amplitude. O objectivo é nunca ter de degradar uma fonte para a ajustar à ferramenta — se o sistema bancário central só consegue exportar um ficheiro SFTP nocturno, mas o switch consegue transmitir em fluxo contínuo por Kafka, cada um é ingerido com a sua fidelidade nativa, em vez de se forçarem ambos a passar pelo mínimo denominador comum.

Idempotência, reprocessamento e a fila de mensagens não entregues

Fazer entrar os dados uma vez é fácil. Fazê-los entrar exactamente uma vez, sempre, em condições reais de falha, é a parte difícil — e é aí que as integrações ingénuas corrompem silenciosamente os dados que deviam entregar.

A idempotência garante que, se o mesmo registo for entregue duas vezes — porque um fluxo voltou a tentar, uma tarefa foi reiniciada ou um ficheiro foi reprocessado —, é reconhecido e não é contado duas vezes. Sem ela, as transacções duplicadas inflacionam os volumes e as contagens de velocidade, e a monitorização dispara sobre actividade fantasma.
O reprocessamento (replay) permite voltar a executar uma fonte a partir de um ponto conhecido após uma interrupção ou uma correcção do mapeamento, para que um intervalo de actividade seja recuperado na íntegra, em vez de ficar como uma lacuna permanente no registo.
A fila de mensagens não entregues (dead-letter queue, DLQ) captura os registos que não podem ser processados — mal formados, impossíveis de interpretar ou que falham a validação — em vez de os descartar silenciosamente. Nada desaparece. Cada registo rejeitado é visível, contabilizável e recuperável depois de corrigida a causa.

Em conjunto, estes três mecanismos fazem com que a falha de um fluxo se torne um evento operacional que se pode ver e corrigir, e não um buraco invisível nos dados que vem à tona meses depois sob a forma de um alerta que nunca chegou a ser gerado. A idempotência, o reprocessamento e a DLQ são a diferença entre um fluxo que se pode certificar perante um inspector e um fluxo que apenas se pode esperar que estivesse completo.

Mapeamento e certificação: fazer com que os dados signifiquem o mesmo em todo o lado

Depois de os dados fluírem de forma fiável, é ainda preciso que signifiquem o mesmo em todas as fontes. O campo de montante no extracto do sistema bancário central, a etiqueta de valor numa mensagem ISO 20022 e a coluna txn_amt no ficheiro do switch podem descrever todos o montante de uma transacção, mas, enquanto a plataforma não souber que se trata do mesmo conceito, nenhuma regra os pode comparar.

A interface de mapeamento de campos

O serviço de ingestão disponibiliza uma interface de mapeamento de campos que permite a um analista de conformidade ou de dados ligar cada campo de origem ao modelo canónico da plataforma sem escrever código. O fluxo de origem é analisado (profiling), os seus campos são apresentados e o analista mapeia-os — o montante da transacção aqui, o identificador do cliente ali, o indicador de débito/crédito acolá —, aplicando transformações onde os formatos diferem. Isto é importante porque quem compreende o significado de um campo são os colaboradores de conformidade e de operações, não necessariamente os engenheiros de integração, e a interface de mapeamento coloca essa apreciação onde o conhecimento está.

Certificação das fontes

Mapear uma fonte não é o mesmo que confiar nela. A certificação das fontes é a etapa formal em que um fluxo recém-mapeado é validado e aprovado antes de os seus dados poderem alimentar a detecção em produção. Uma fonte só passa de «ligada» a «certificada» depois de os seus campos estarem mapeados, de a sua qualidade estar verificada e de alguém ter assumido a responsabilidade por ela. Isto dá-lhe uma resposta defensável à pergunta do inspector «como sabe que este fluxo está completo e correcto?» — porque a certificação fica registada, e não é pressuposta. Quando o fluxo em causa é o seu sistema bancário central a fornecer dados para as comunicações a jusante, a mesma disciplina estende-se à camada de comunicação; a mecânica da integração dos dados do sistema bancário central para as comunicações goAML assenta directamente num circuito de ingestão certificado.

Regras de qualidade dos dados e pontuação de prontidão

A ingestão e o mapeamento fazem entrar na plataforma dados limpos e bem rotulados. As regras de qualidade dos dados mantêm-nos assim, e a pontuação de prontidão indica — antes mesmo de activar uma regra de detecção — se os dados conseguem realmente suportá-la. Estas funções pertencem ao serviço de requisitos de dados (Data Requirements service, DRS) e são elas que transformam «pensamos que os dados estão bem» em «conseguimos demonstrar que os dados estão bem».

A matriz regra-atributo

Uma regra de monitorização não precisa de todos os seus dados; precisa de atributos específicos. Uma regra de fraccionamento precisa do montante da transacção, do indicador de numerário, da data e hora e da referência do cliente. Um controlo de filtragem de sanções precisa de campos de nome e de país completos e bem formados. A matriz regra-atributo torna esta dependência explícita: faz corresponder cada regra e cada módulo de detecção aos atributos de dados exactos que consomem.

O valor da matriz está em converter uma preocupação vaga — «os nossos dados são suficientemente bons?» — numa pergunta precisa, a que se pode responder: de que atributos depende esta regra, e cada um deles está presente, preenchido e correcto? Deixa-se de discutir a qualidade dos dados em abstracto e passa-se a medi-la face às regras que efectivamente utilizam esses dados.

Regras de qualidade dos dados e pontuação de prontidão dos módulos

Com base nessa matriz, as regras de qualidade dos dados testam continuamente os atributos que importam — verificando a completude, o formato, a validade e a actualidade. Uma regra de qualidade dos dados (DQ) pode afirmar que o campo do montante da transacção nunca é nulo, que o campo do país contém um código ISO válido ou que o formato do identificador do cliente é coerente entre fontes. As falhas são expostas e contabilizadas, em vez de ocultadas.

A pontuação de prontidão agrega essas verificações ao nível de um módulo ou de uma regra: pontua o grau de preparação dos seus dados para suportar um determinado controlo. O resultado é uma visão em semáforo da capacidade de detecção. Se não for possível executar de forma fiável uma regra de fraccionamento porque o indicador de numerário só está preenchido numa fracção dos registos, a plataforma di-lo à partida — para que se corrija o fluxo, em vez de se implementar uma regra que detectará silenciosamente menos do que devia e dará uma falsa sensação de segurança. Esta é a resposta honesta à pergunta mais incómoda em BC/FT: não «a nossa monitorização funciona?», mas «consegue funcionar com os dados que realmente temos?».

Exportação de pacotes de provas

A última peça são as provas. Quando um inspector, um auditor interno ou o seu conselho de administração lhe pede que demonstre que os seus dados são adequados à finalidade, a exportação de pacotes de provas reúne a demonstração — que fontes estão certificadas, que regras cada uma suporta, como estão a comportar-se as regras de qualidade dos dados e quais são as pontuações de prontidão. A camada de dados torna-se auditável nos mesmos termos que o resto do programa. Essa auditabilidade é a mesma disciplina, assente antes de mais nas provas, que atravessa os pacotes de provas e a preparação para auditoriasEN em todas as decisões relevantes que a plataforma regista.

Como as lacunas de dados quebram silenciosamente a detecção e as comunicações

Vale a pena dizer com clareza como a falha se propaga na realidade, porque a cadeia é curta e é o silêncio no fim dela que a torna perigosa.

Um campo chega vazio ou com o tipo errado à ingestão. Como não há nenhuma regra DQ a vigiá-lo — ou porque alguém implementou a regra de detecção sem verificar a prontidão —, a lacuna nunca é assinalada. O motor de monitorização executa a regra sobre os dados de que dispõe, e a regra, fazendo exactamente o que lhe foi pedido, não encontra nada, porque as provas de que precisava estavam em falta. Nenhum alerta é gerado. Nenhum caso é aberto. Meses depois, a mesma actividade aparece na análise do próprio regulador, e a instituição fica a ter de explicar por que razão um padrão que tinha os dados para ver nunca foi visto.

A solução não é uma regra melhor. É a disciplina descrita acima: fontes certificadas, uma matriz regra-atributo explícita, verificações contínuas da qualidade dos dados e uma pontuação de prontidão que se recusa a deixar activar uma detecção que os dados não conseguem suportar. É por isso que uma ingestão disciplinada não é uma condição prévia de uma boa monitorização de transacções — faz parte dela. A monitorização nunca é melhor do que o fluxo de dados que a alimenta, e o mesmo se aplica à filtragem, à avaliação de risco e a cada comunicação que submete.

Perguntas frequentes

Qual é a causa mais comum de falha da detecção BC/FT?

Dados em falta ou mal formados nos atributos específicos de que um controlo depende. Uma regra de monitorização que precisa de um indicador de numerário ou do montante de uma transacção produz um resultado limpo de «nada encontrado» quando esse campo está vazio, o que é indistinguível de uma verdadeira ausência de risco. A lógica da regra está geralmente correcta; os dados de entrada é que não estavam.

Porque é que a ISO 20022 é importante para a qualidade dos dados?

A ISO 20022 é uma norma de mensagens financeiras estruturada e ricamente tipificada, pelo que transporta muito mais detalhe bem rotulado do que os antigos ficheiros de largura fixa que substitui. Ingerir com essa fidelidade significa que mais atributos chegam preenchidos e com o tipo correcto, o que melhora directamente a prontidão das regras que os consomem. A plataforma ingere a ISO 20022 de forma nativa, em vez de a converter num formato plano.

O que prova realmente a «certificação das fontes»?

Que um fluxo foi mapeado para o modelo canónico, validado quanto à qualidade e formalmente aprovado antes de os seus dados alimentarem a detecção em produção. Transforma «presumimos que este fluxo está completo» numa afirmação registada e defensável que pode mostrar a um inspector — a diferença entre esperar que uma fonte esteja correcta e conseguir demonstrá-lo.

Em que difere a prontidão dos dados da simples execução das regras?

Executar uma regra diz-lhe que ela correu. A pontuação de prontidão diz-lhe se os dados que lhe estão por baixo conseguem sustentar um resultado fiável. Ao fazer corresponder cada regra aos atributos de que precisa e ao pontuar o grau de completude e de validade desses atributos, a plataforma avisa-o de que uma regra vai detectar menos do que devia antes de a implementar, e não depois de um inspector encontrar a lacuna.

A qualidade dos dados não é o pré-requisito pouco vistoso da detecção BC/FT — é a base em que a detecção assenta, e o primeiro ponto onde um programa falha quando falha em silêncio. Se quiser ver como a ingestão certificada, a matriz regra-atributo e a pontuação de prontidão funcionam em conjunto com as suas próprias fontes, marque uma demonstração e percorreremos o processo com os seus fluxos de dados à vista. Para as instituições que pretendem ajuda para estabelecer a disciplina antes da tecnologia, a nossa consultoria de conformidade em crime financeiro e a plataforma de Comunicações goAML completam o quadro, da prontidão dos dados até à submissão das comunicações.