Quando 40% do lote de CTR de um banco foi rejeitado: história de uma recuperação goAML

Cenário composto, baseado em implementações típicas na África Oriental. Os dados da instituição foram anonimizados e os números são representativos, não sendo atribuíveis a um único cliente.

O mês em que as comunicações deixaram de passar

A gestora de conformidade de um banco comercial queniano de segundo escalão tinha uma rotina de que não gostava. No dia 3 de cada mês, a sua equipa exportava do sistema bancário central (core banking) para uma folha de cálculo as transacções em numerário do mês anterior, limpava-as à mão, executava uma macro que produzia o XML goAML e carregava o ficheiro no portal do Financial Reporting Centre (FRC).

Depois, restava esperar.

Num mês bom, o portal aceitava o lote e a equipa passava a outro assunto. Num mês mau — e os meses maus estavam a tornar-se a regra —, o portal devolvia um erro de validação que remetia para um elemento XSD que ninguém no edifício conseguia interpretar. Num desses meses, cerca de 40% do lote foi rejeitado. A equipa tinha quatro dias úteis para voltar a submeter antes do fim do prazo de comunicação, e nenhuma forma fiável de saber quais dos vários milhares de registos continham os erros.

Esta é a parte da conformidade em matéria de prevenção e combate ao branqueamento de capitais e financiamento do terrorismo (BC/FT) que raramente aparece nas políticas internas. A obrigação é clara. Os controlos existem. E, ainda assim, as comunicações não chegam a tempo.

O que estava realmente a falhar

Quando percorremos o processo com a equipa, as falhas concentravam-se em quatro causas, nenhuma das quais tinha a ver com o juízo de conformidade:

• Evolução silenciosa do esquema. A macro tinha sido escrita para uma versão anterior do XSD goAML. Quando o esquema passou para a v5.0.2, vários elementos opcionais tornaram-se obrigatórios e uma enumeração mudou. Ninguém tinha reconstruído a macro.
• Campos de identificação em texto livre. Os tipos de documento de identificação dos clientes eram introduzidos de forma incoerente no core banking — «National ID», «NATIONAL_ID», «ID Card» — e a camada de mapeamento transmitia-os tal como estavam.
• A lógica dos limiares vivia numa folha de cálculo. A detecção das transacções em numerário dependia de um filtro mantido por um único analista. A agregação das transacções do mesmo cliente no mesmo dia era feita a olho.
• Nenhuma verificação prévia. A primeira vez que alguém tomava conhecimento de que um ficheiro era inválido era depois de o regulador o dizer.

O último ponto é o mais importante. Todos os outros problemas eram superáveis se fossem detectados antes da submissão. Nenhum o era quando o ciclo de resposta passava pelo portal do FRC, com um prazo de quatro dias a correr.

O que mudou

O banco implementou a plataforma de comunicações goAML da Creodata numa instância dedicada (single-tenant) do Azure, a par da plataforma de core banking que já utilizava. Três coisas mudaram de sítio:

O mapeamento saiu das folhas de cálculo. Os dados de transacções e de clientes entram através de uma integração segura e são mapeados automaticamente para o modelo de dados goAML. Os tipos de identificação são normalizados face às enumerações do esquema logo na ingestão, pelo que «ID Card» nunca chega ao gerador de XML.

A detecção passou para dentro da plataforma. Os limiares das transacções em numerárioEN — incluindo as regras de agregação do mesmo dia — são configurados uma única vez e aplicados de forma coerente. As transacções que atingem o limiar surgem automaticamente, em vez de dependerem do filtro de um analista.

A validação passou para antes da submissão. Cada ficheiro gerado é validado, dentro da plataforma, face ao XSD goAML v5.0.2 em vigor. Os registos que falham são assinalados com o elemento concreto e o registo concreto, numa linguagem que permite a um analista de conformidade agir, dias antes de o ficheiro se aproximar sequer do regulador.

A vertente das STR foi tratada à parte. As comunicações de operações suspeitas passaram a ser redigidas num espaço de trabalho dedicado, e não no Word, pelo que a narrativa, as transacções associadas e as entidades relacionadas seguem juntas e podem ser reconstituídas mais tarde.

O resultado

A primeira submissão em produção saiu seis semanas após o arranque do projecto. Foi aceite à primeira tentativa, tal como as seguintes. O dia 3 de cada mês deixou de ser um acontecimento.

Dois efeitos secundários pesaram mais do que a equipa esperava:

A preparação das inspecções passou de semanas a horas. A plataforma mantém um trilho de auditoria imutável do que foi comunicado, quando, por quem e com base em que registos de origem. Quando a autoridade de supervisão perguntou como tinha sido tomada, oito meses antes, uma determinada decisão sobre um limiar, a resposta foi uma consulta, e não um projecto de arqueologia.

A equipa de conformidade deixou de se ocupar da introdução de dados. As horas antes gastas a conciliar exportações passaram a ser dedicadas àquilo para que a equipa é efectivamente paga — rever alertas e redigir narrativas de suspeita defensáveis. Num mês típico, são mais de 80 horas que deixam de ser gastas a lutar com formatos e passam a ser dedicadas à análise.

O que diríamos ao próximo banco

Há três lições deste projecto que se aplicam em geral.

As rejeições são um sintoma, não a doença. As instituições tendem a responder a um lote rejeitado acrescentando um revisor. Isso aumenta os custos e identifica talvez metade dos erros, porque os seres humanos têm dificuldade em detectar violações do XSD num ficheiro XML. A solução duradoura é uma máquina que verifique o ficheiro face ao esquema que o regulador efectivamente utiliza.

As versões do esquema mudam e ninguém lhe envia um memorando. Se a sua geração de XML depende de uma macro, de um script ou de um módulo de um fornecedor que não é acompanhado face ao XSD publicado, parta do princípio de que deixará silenciosamente de estar em conformidade. A validação face ao esquema em vigor é a única defesa fiável.

O país importa. O FRC no QuéniaEN, a FIU na TanzâniaEN, a FIA no UgandaEN, o FIC no RuandaEN e o FIC na ZâmbiaEN acrescentam, cada um, requisitos locais à base goAML. Uma plataforma que trate o «goAML» como um alvo único falhará na fronteira. As instituições presentes em várias jurisdições devem testar explicitamente as regras de cada país, em vez de presumirem que são transponíveis de um país para outro.

O banco desta história comunica hoje em duas jurisdições a partir de uma única implementação. A gestora de conformidade continua a não gostar do dia 3 de cada mês, mas por razões banais.

Leitura complementar: O guia completo das comunicações goAML · Submissão goAML rejeitada? Como diagnosticar e corrigir os erros mais comuns

Está a lidar com lotes goAML rejeitados ou a preparar uma primeira submissão? Marque uma consulta ou explore a plataforma de comunicações goAML para ver como funciona a validação segundo o esquema antes de o seu ficheiro chegar ao regulador.