Comunicações goAML: o guia completo para bancos e UIF (2026)
O goAML é o sistema do UNODC com que as UIF recebem CTR e STR: o que é, quem comunica, o esquema XML, as rejeições e as regras de cada país da África Oriental.
Resposta curta: o goAML é a plataforma de comunicação e análise para a prevenção e o combate ao branqueamento de capitais e ao financiamento do terrorismo (BC/FT) desenvolvida pelo Escritório das Nações Unidas sobre Drogas e Crime para as unidades de informação financeira (UIF). As instituições obrigadas a comunicar utilizam-no para submeter comunicações de transacções em numerário (CTR) e comunicações de operações suspeitas (STR) — através do portal web da UIF, para volumes reduzidos, ou sob a forma de ficheiros XML que têm de ser válidos segundo o esquema goAML (versão 5.0.2 nas UIF da África Oriental aqui abordadas). O Quénia, o Uganda, a Tanzânia, a Zâmbia e o Ruanda utilizam-no, cada um com os seus próprios limiares, prazos e regras de preenchimento dos campos.
Se a sua instituição tem obrigações BC/FT em qualquer ponto da África Oriental, mais cedo ou mais tarde todas as conversas sobre conformidade vão dar a uma palavra: goAML. É o sistema que a sua unidade de informação financeira (UIF) utiliza para receber as comunicações, o formato para o qual os seus dados de transacções têm de ser convertidos e o guardião que decide se uma submissão é aceite ou rejeitada.
Este guia é o ponto de partida para tudo o que diz respeito ao goAML. Explica o que é o sistema, quem está obrigado a comunicar, como funcionam os principais tipos de comunicação, o que o esquema XML exige, como se tratam na prática as submissões e as rejeições e em que diferem as regras no Quénia, no Uganda, na Tanzânia, na Zâmbia e no Ruanda. Sempre que um tema merece um tratamento mais aprofundado, remetemos para um guia dedicado, para que possa ir tão longe quanto precisar.
O que é o goAML?
O goAML é uma plataforma de software integrada, desenvolvida pelo Escritório das Nações Unidas sobre Drogas e Crime (UNODC) especificamente para as unidades de informação financeira. Dá a uma UIF um sistema único para recolher as comunicações das instituições reguladas, analisá-las e difundir informações às autoridades de aplicação da lei. Mais de uma centena de UIF em todo o mundo funcionam hoje com o goAML, o que explica precisamente por que razão se tornou a linguagem comum das comunicações BC/FT em toda a região.
Para uma instituição obrigada a comunicar — um banco, uma SACCO (cooperativa de poupança e crédito), uma instituição de microfinanças, uma casa de câmbio, um prestador de serviços de pagamento ou outra entidade designada —, o goAML tem duas faces:
- O portal web, onde os responsáveis autorizados se registam, iniciam sessão, introduzem comunicações manualmente, carregam ficheiros de comunicação e acompanham os avisos de recepção.
- O esquema XML, um formato rigoroso, legível por máquina, a que todas as comunicações têm de obedecer para que o sistema as aceite.
As pequenas instituições que submetem meia dúzia de comunicações por mês podem trabalhar apenas no portal web. Para quem comunica em volume, é no esquema que a conformidade se ganha ou se perde — razão pela qual grande parte deste guia, e do conjunto de artigos para que remete, trata de acertar no XML à primeira.
Quem tem de comunicar através do goAML?
A lista exacta de «instituições obrigadas a comunicar» ou de «pessoas obrigadas» é fixada pela legislação BC/FT de cada país, mas inclui quase sempre os bancos, as instituições de microfinanças e as instituições que captam depósitos, as SACCO, as casas de câmbio, os prestadores de serviços de remessa de fundos, os operadores de dinheiro móvel, as seguradoras, os intermediários do mercado de capitais e um conjunto de actividades e profissões não financeiras designadas (APNFD), como advogados, contabilistas, agentes imobiliários e comerciantes de metais preciosos e de pedras preciosas.
Se não tem a certeza de que as suas obrigações estão a ser cumpridas de ponta a ponta — desde o dever de diligência relativo à clientela até à submissão —, a nossa equipa de consultoria em conformidade em crime financeiro trabalha com instituições de todas as dimensões para construir e testar toda a cadeia de comunicação.
CTR e STR: os dois principais tipos de comunicação
Quase tudo o que é submetido através do goAML corresponde a um de dois tipos de comunicação.
Uma comunicação de transacções em numerário (CTR) é submetida quando uma transacção em numerário atinge ou excede um limiar definido. É objectiva e baseada em regras: acima do limiar, comunica-se, quer algo pareça suspeito quer não. No Quénia, por exemplo, esse limiar é de 15 000 USD ou o seu equivalente, e o pormenor do que conta para o atingir é mais subtil do que parece à primeira vista — explicamo-lo em Limiar de CTR no Quénia: a regra dos 15 000 USD explicadaEN e percorremos uma submissão de ponta a ponta em Como submeter uma CTR ao FRC do QuéniaEN.
Uma comunicação de operação suspeita (STR) é submetida sempre que uma instituição forma uma suspeita de branqueamento de capitais, de financiamento do terrorismo ou de outro crime subjacente — sem qualquer limiar. É nas STR que o juízo, o conhecimento das tipologias e a redacção da narrativa mais contam. Para as elaborar correctamente, consulte:
- Como redigir a narrativa de uma STR para o goAML — estruturar uma narrativa defensável e pronta para a tomada de decisão.
- Biblioteca de indicadores de STR: tipologias BC/FT para os bancos do QuéniaEN — os sinais de alerta que devem desencadear uma comunicação.
- Motores de pontuação de risco BC/FT: como funcionam as recomendações automáticas de STR — como a automatização faz surgir casos candidatos sem substituir a decisão do analista.
O dinheiro móvel merece uma menção especial nesta região: a rapidez das transacções em carteira móvel e o risco de fraccionamento que comportam alteram a forma como são geradas tanto as CTR como as STR, tema que abordamos em Comunicações BC/FT do dinheiro móvel no Quénia: M-PESA, Airtel Money e goAMLEN.
O esquema XML goAML: onde as submissões passam ou falham
Uma comunicação goAML só é aceite se for válida segundo o esquema XML (XSD) publicado pela UIF. As implementações da África Oriental abordadas neste guia utilizam a versão 5.0.2 do esquema, e o esquema determina quais os campos obrigatórios, bem como os respectivos tipos de dados, listas de códigos e estrutura. Uma única data mal formatada, uma parte obrigatória em falta ou um tipo de conta inválido bastam para que toda a submissão seja devolvida.
Três guias levam-no da teoria do esquema a um ficheiro limpo e validado:
- Esquema XML goAML v5.0.2: referência dos campos obrigatórios das CTR e STR — exactamente que campos são exigidos para cada tipo de comunicação.
- Geração de XML segundo o XSD goAML v5: o guia técnico completo — gerar programaticamente XML válido segundo o esquema.
- Integração do core banking com o goAML: opções API, SFTP e CSV — extrair os dados de transacções do sistema central e encaminhá-los para o circuito de processamento.
Antes de submeter o que quer que seja no portal em produção, valide-o. O nosso validador XML goAML, gratuito e baseado no navegador, verifica um ficheiro face ao esquema v5.0.2 inteiramente no seu navegador — nenhum dado sai do computador — e a nossa biblioteca de códigos de erro goAML explica o que significa realmente cada código de rejeição.
Gerir submissões e rejeições
Mesmo ficheiros bem formados são rejeitados, e uma rejeição raramente é um beco sem saída — é um problema diagnosticável, com uma causa concreta. Os culpados mais frequentes são as falhas na validação do esquema, as discrepâncias nos dados de referência (um código que não consta da lista aceite pela UIF), os identificadores de comunicação duplicados e os registos de contas ou de partes que não cumprem as regras de negócio da UIF.
Quando o portal devolve um erro, o guia Submissão goAML rejeitada? Como diagnosticar e corrigir os erros mais comuns explica como ler a rejeição, relacioná-la com a causa de fundo e voltar a submeter sem erros. O objectivo de todas as equipas de conformidade deve ser alcançar rejeições quase nulas — ficheiros validados localmente e aceites à primeira tentativa.
País a país: o goAML na África Oriental
O esquema pode ser comum, mas o quadro legal, os limiares, os prazos e as regras de localização são nacionais. Cada um dos guias por país indicados abaixo constitui a referência de autoridade para a respectiva jurisdição, pronta a ser utilizada pelas instituições:
- Quénia — o Financial Reporting Centre (FRC), ao abrigo da POCAMLA: Comunicações goAML ao FRC do Quénia: guia completo 2026EN. Para as infracções subjacentes e a dimensão de combate ao terrorismo, consulte Conformidade com a POCAMLA e a POTA para os bancos do QuéniaEN.
- Uganda — a Financial Intelligence Authority (FIA): Comunicações goAML à FIA do Uganda: guia prático para bancosEN.
- Tanzânia — a Financial Intelligence Unit (FIU): Comunicações goAML à FIU da Tanzânia: guia prático para bancosEN.
- Zâmbia — o Financial Intelligence Centre (FIC): Conformidade goAML com o FIC da Zâmbia: guia prático para bancosEN.
- Ruanda — o Financial Intelligence Centre (FIC): Comunicações goAML ao FIC do Ruanda: guia prático para bancosEN.
O panorama regional — e a razão por que se está a tornar mais exigente — é apresentado em Panorama da conformidade BC/FT na África Oriental: perspectivas para 2026EN e em Avaliações mútuas do ESAAMLG: o que todos os bancos da África Oriental devem saber.
Automatizar as comunicações goAML
As comunicações goAML manuais não acompanham o crescimento. À medida que os volumes de transacções aumentam, introduzir comunicações à mão ou editar XML manualmente torna-se lento, propenso a erros e impossível de auditar. A automatização muda a equação económica: as transacções são extraídas do sistema bancário central (core banking), aplicam-se os limiares e as tipologias, gera-se XML válido segundo o esquema e os ficheiros são validados antes mesmo de chegarem ao portal.
Dois artigos respondem às questões de «desenvolver ou comprar» e de implementação com que todas as instituições se deparam:
- Como automatizar as comunicações BC/FT na África Oriental: uma abordagem práticaEN
- Plataforma BC/FT nas instalações do cliente ou na cloud: qual é a mais adequada para os bancos africanos? e a perspectiva de engenharia em Arquitectura de microsserviços para plataformas BC/FTEN.
A plataforma de comunicações goAML da Creodata faz exactamente isto: integra-se com o seu sistema bancário central, gera XML v5.0.2 válido segundo o esquema e valida cada ficheiro antes da submissão, para rejeições quase nulas. Para uma apresentação de uma página, que possa partilhar com a administração, consulte o resumo executivo goAML, ou marque uma demonstração para a ver a funcionar com os seus próprios dados.
Perguntas frequentes
O que significa goAML?
goAML não é um acrónimo convencional — é o nome da plataforma de comunicações BC/FT do UNODC para as unidades de informação financeira. O «AML» refere-se a anti-money laundering (combate ao branqueamento de capitais); a plataforma é utilizada pelas UIF para recolher, analisar e difundir informações financeiras.
O goAML é obrigatório?
Sempre que uma UIF tenha adoptado o goAML, a submissão através deste sistema é obrigatória para as instituições designadas como entidades obrigadas pela lei BC/FT do respectivo país. No Quénia, no Uganda, na Tanzânia, na Zâmbia e no Ruanda, os bancos e a maioria das outras instituições financeiras são obrigados a submeter as CTR e as STR através do sistema goAML, e a falta de comunicação pode implicar sanções administrativas e responsabilidade pessoal dos responsáveis em causa.
Qual é a diferença entre uma CTR e uma STR?
Uma comunicação de transacções em numerário é submetida para as transacções em numerário iguais ou superiores a um limiar definido e baseia-se exclusivamente em regras — não é necessária qualquer suspeita. Uma comunicação de operação suspeita é submetida sempre que a instituição forma uma suspeita de branqueamento de capitais ou de uma infracção conexa, sem qualquer limiar monetário. As CTR põem à prova o seu circuito de dados; as STR põem à prova o juízo dos seus analistas.
Porque são rejeitadas as submissões goAML?
Os motivos mais frequentes são XML que falha a validação do esquema, códigos de referência que não constam da lista aceite pela UIF, identificadores de comunicação duplicados e registos de partes ou de contas que violam as regras de negócio. Validar os ficheiros face ao esquema v5.0.2 antes da submissão — por exemplo, com o nosso validador XML goAML gratuito — elimina a grande maioria das rejeições.
Que versão do esquema goAML é utilizada na África Oriental?
As implementações abordadas neste guia utilizam a versão 5.0.2 do esquema XML goAML. Confirme sempre a versão em vigor publicada pela sua UIF antes de gerar ficheiros, pois as UIF actualizam periodicamente o seu esquema.
Esta é a página central dos conteúdos da Creodata sobre o goAML. Explore os guias indicados para o pormenor de cada jurisdição, ou fale com a nossa equipa de consultoria em conformidade sobre a automatização das suas comunicações de ponta a ponta.
