Geração de XML segundo o XSD goAML v5: o guia técnico completo

Se alguma vez tentou construir de raiz uma comunicação goAML em XML, já sabe que o processo é bastante mais complicado do que parece à primeira vista. A versão 5.0.2 do esquema goAML do Escritório das Nações Unidas sobre Drogas e Crime (UNODC) define mais de 200 elementos, muitos deles com restrições de enumeração rigorosas, todos dispostos numa hierarquia profundamente aninhada, com conjuntos diferentes de elementos obrigatórios consoante esteja a gerar uma comunicação de transacções em numerário (CTR) ou uma comunicação de operação suspeita (STR). As unidades de informação financeira (UIF) de cada país acrescentam depois requisitos de validação adicionais ao esquema de base — e esses requisitos mudam.

A maioria das primeiras tentativas de geração de XML goAML falha na submissão. A comunicação parece correcta num editor de texto. O XML está bem formado. Mas o portal da UIF devolve um erro de validação num campo situado três níveis abaixo na hierarquia das partes, formatado correctamente para todos os outros países excepto este. O programador faz uma correcção, gera novamente o ficheiro, volta a submeter e depara-se com um erro diferente. O ciclo de iterações pode levar dias.

Este guia destina-se aos responsáveis de informática, programadores e arquitectos técnicos encarregados de construir ou avaliar capacidades de geração de XML goAML. Aborda a estrutura do esquema, os pontos de falha mais comuns, as extensões específicas de cada país e a arquitectura de um circuito robusto de geração de XML.

---

Visão geral do esquema XML goAML v5.0.2

Historial do esquema goAML

O software goAML do UNODC passou por várias revisões importantes do esquema desde a sua implementação inicial, em meados da década de 2000. A versão 3 do esquema foi a versão dominante entre as UIF que o adoptaram primeiro e ainda se encontra em implementações antigas de algumas UIF. A versão 4 introduziu alterações estruturais significativas nos elementos de transacção e de parte, melhorando o suporte a estruturas de propriedade complexas e a transacções transfronteiriças.

A versão 5.0.2 — a versão actual, implementada em todas as cinco UIF de países membros do ESAAMLG (Grupo da África Oriental e Austral contra o Branqueamento de Capitais) — introduziu novos aperfeiçoamentos estruturais, alargou os conjuntos de enumeração dos tipos de transacção e dos tipos de documento de identificação e formalizou o mecanismo de extensão que as UIF nacionais utilizam para impor requisitos de validação adicionais para além do esquema de base do UNODC.

Um ponto crucial: quando o UNODC publica uma actualização do XSD, nem sempre se trata de uma alteração retrocompatível. Código que gerava XML v4 válido pode gerar XML v5 inválido em determinadas combinações de elementos. Qualquer implementação de geração de XML tem de estar fixada na versão exacta do esquema implementada pela UIF de destino e ser actualizada quando essa UIF migrar.

Estrutura do esquema: Report → Transaction → Party → Account → ID Document → Address

A hierarquia do documento XML goAML segue uma estrutura lógica que espelha a comunicação de informação financeira no mundo real:

Report é o elemento raiz. Contém a identificação da entidade comunicante, os metadados da submissão, os dados da pessoa que efectua a comunicação e um ou mais registos de transacção.

Os elementos Transaction situam-se imediatamente abaixo do Report. Cada transacção tem um tipo, um montante, uma moeda, uma data e uma descrição. Uma única comunicação pode conter várias transacções — o que é comum nas CTR em que um cliente efectuou várias transacções em numerário no período de comunicação.

Os elementos Party descrevem as pessoas singulares ou colectivas envolvidas numa transacção. As partes estão ligadas às transacções através dos elementos from_person, to_person, from_entity e to_entity, cada um dos quais contém o registo aninhado da parte. Uma parte que surja em várias transacções pode ser referenciada por identificador, em vez de ser integralmente repetida em cada transacção.

Os elementos Account registam as contas financeiras envolvidas — números de conta bancária, códigos de tipo e a instituição financeira em que a conta está domiciliada. As contas estão ligadas ao respectivo lado da transacção (from_account, to_account).

Os elementos ID Document situam-se dentro dos registos de pessoas e registam o bilhete de identidade nacional, o passaporte, a carta de condução e outros documentos de verificação da identidade. O National ID é obrigatório para as pessoas quenianas, nos termos das regras de validação do FRC do Quénia.

Os elementos Address registam as moradas físicas ou postais das pessoas e das entidades. As regras de validação das moradas variam de país para país — algumas UIF exigem o pormenor ao nível da rua; outras aceitam apenas o país no caso das partes não residentes.

Diferenças de esquema entre STR e CTR

Embora a estrutura de base do esquema seja comum às comunicações de operações suspeitas e às comunicações de transacções em numerário, há diferenças significativas quanto aos elementos obrigatórios, opcionais ou proibidos:

As CTR exigem transaction_amount com precisão decimal exacta, CASH como tipo de transacção e o pormenor completo das contas de ambos os lados da transacção. O montante do limiar da CTR e o código da moeda têm de ser rigorosamente coerentes com o limiar declarado no perfil do país. Várias transacções em numerário do mesmo período de comunicação podem ser consolidadas numa única CTR.

As STR exigem o campo is_suspicious definido como true, um elemento reason não vazio que descreva por que razão a transacção é suspeita, um texto narrativo com extensão e substância significativas, pelo menos um código de indicador que remeta para uma tipologia de branqueamento de capitais conhecida da lista de indicadores da UIF e os dados de reporting_person. Os elementos de transacção de uma STR podem incluir transacções que não são em numerário e padrões de fraccionamento que, individualmente, ficam abaixo dos limiares das CTR.

Descarregar o XSD oficial do UNODC

O UNODC disponibiliza os ficheiros do esquema XSD goAML através do seu portal oficial de documentação goAML. A fonte de referência para os ficheiros XSD, as notas de versão e as orientações de validação é a página do produto goAML do UNODC. Deve também ser consultada a documentação do portal da UIF de cada país, uma vez que as UIF publicam extensões do esquema específicas do país e documentos com regras de validação, a par do esquema de base do UNODC.

Recomenda-se vivamente que descarregue o XSD directamente do portal da UIF do país de destino, em vez de recorrer a uma fonte de terceiros, pois as extensões nacionais alteram o esquema de base de formas que nem sempre estão reflectidas na documentação geral.

---

A estrutura do documento XML goAML

Segue-se um exemplo anotado de uma CTR goAML v5.0.2 bem formada, relativa a uma entidade comunicante queniana fictícia. Todos os dados de entidades e de pessoas são inteiramente fictícios.

<?xml version="1.0" encoding="UTF-8"?>
<Report xmlns="http://goaml.unodc.org/goaml/en">
  <!-- Reporting entity identification — must match FIU registration exactly -->
  <rentity_id>KE-FRC-12345</rentity_id>
  <rentity_branch>NAIROBI-HQ</rentity_branch>

  <!-- Submission metadata -->
  <submission_code>E</submission_code>          <!-- E = Electronic -->
  <report_code>CTR</report_code>                <!-- CTR or STR -->
  <entity_reference>CTR-2026-0001</entity_reference>  <!-- Internal reference -->
  <fiu_ref_number></fiu_ref_number>             <!-- Blank on first submission; FIU populates on acceptance -->
  <submission_date>2026-03-25</submission_date>  <!-- YYYY-MM-DD strictly required -->
  <currency_code_local>KES</currency_code_local> <!-- ISO 4217 currency code -->

  <!-- Reporting person — the compliance officer or designated MLRO -->
  <reporting_person>
    <gender>M</gender>               <!-- M or F — not Male/Female -->
    <title>Mr</title>
    <first_name>James</first_name>
    <last_name>Mwangi</last_name>
    <birthdate>1980-05-15</birthdate>  <!-- YYYY-MM-DD — not optional for Kenya FRC -->
    <id_number>12345678</id_number>    <!-- National ID of reporting person -->
    <!-- Address and phone elements follow here -->
  </reporting_person>

  <!-- One or more transaction elements -->
  <transaction>
    <transactionnumber>TXN-2026-00123</transactionnumber>
    <transaction_location>NAIROBI-CBD-BRANCH</transaction_location>
    <date_transaction>2026-03-24</date_transaction>  <!-- Date of transaction -->
    <teller>T001</teller>                             <!-- Teller/officer ID -->
    <currency_amount>
      <amount>1250000.00</amount>    <!-- Exactly 2 decimal places required -->
      <currency_code>KES</currency_code>
    </currency_amount>

    <!-- Transaction type — must be valid enumeration value from XSD -->
    <transaction_type>CASH_DEPOSIT</transaction_type>

    <!-- The depositing party (from side) -->
    <from_person>
      <gender>F</gender>
      <title>Ms</title>
      <first_name>Wanjiru</first_name>
      <last_name>Kamau</last_name>
      <birthdate>1985-11-20</birthdate>
      <id_number>87654321</id_number>
      <id_type>NATIONAL_ID</id_type>   <!-- Enumeration — must match XSD allowed values -->
      <address>
        <address_type>HOME</address_type>
        <city>Nairobi</city>
        <country>KE</country>  <!-- ISO 3166-1 alpha-2 -->
      </address>
    </from_person>

    <!-- The receiving account (to side) -->
    <to_account>
      <institution_name>First National Bank Kenya</institution_name>
      <institution_code>KE-FRC-12345</institution_code>
      <account>
        <account_number>1234567890</account_number>
        <account_name>Wanjiru Kamau</account_name>
        <account_type>SAVINGS</account_type>  <!-- Enumeration -->
        <currency_code>KES</currency_code>
        <opened>2022-06-15</opened>
      </account>
    </to_account>
  </transaction>

</Report>

Este exemplo ilustra vários requisitos de formatação críticos, analisados em pormenor nas secções seguintes. A estrutura está correcta para uma CTR básica, mas as comunicações em produção exigem elementos adicionais para padrões de transacção complexos, várias partes envolvidas e comunicações com várias transacções.

---

Elementos obrigatórios e opcionais por tipo de comunicação

A tabela seguinte reúne os principais elementos e os respectivos requisitos nos tipos de comunicação CTR e STR. As extensões específicas de cada UIF são referidas, mas não enumeradas de forma exaustiva — consulte sempre a documentação de validação em vigor do país em causa.

---

Desafios comuns na geração de XML

Problemas de codificação: UTF-8 sem BOM

As implementações do portal goAML são notoriamente rigorosas quanto à codificação de caracteres. A declaração XML tem de especificar a codificação UTF-8 e o ficheiro tem de ser guardado em UTF-8 sem marca de ordem de bytes (BOM, Byte Order Mark). As bibliotecas XML orientadas para Windows escrevem muitas vezes, por omissão, um BOM UTF-8, o que leva o portal goAML a rejeitar a submissão com um erro de codificação que é frequentemente diagnosticado, por engano, como um erro de esquema.

Se o seu XML é gerado num sistema Windows com o XmlWriter do .NET, certifique-se de que constrói o writer com new UTF8Encoding(false) — o parâmetro false suprime explicitamente a escrita do BOM. Em Python, utilize encoding='utf-8' sem a variante utf-8-sig. Esta é uma das falhas silenciosas mais comuns nas implementações de XML de primeira geração.

Rigor no formato das datas: sempre YYYY-MM-DD

Todos os campos de data do esquema goAML exigem o formato ISO 8601: YYYY-MM-DD. Os sistemas bancários centrais (core banking) da África Oriental armazenam e exportam frequentemente as datas no formato DD/MM/YYYY, o formato legível mais corrente na região. Uma camada de transformação tem de normalizar todas as datas recebidas antes de entrarem no circuito de geração de XML.

As datas armazenadas como números de série do Excel (comuns nas exportações CSV de alguns sistemas bancários centrais) exigem uma transformação diferente. No sistema de datas do Excel, 1 de Janeiro de 1900 corresponde ao número de série 1; 25 de Março de 2026 corresponde ao número de série 46106. Qualquer sistema de geração de XML que consuma dados de transacções exportados do Excel tem de tratar explicitamente esta conversão.

Precisão decimal: exactamente duas casas decimais

Os elementos de montante têm de ser formatados com exactamente duas casas decimais. Um montante de 1 250 000 KES tem de aparecer como 1250000.00 — não como 1250000, nem como 1,250,000.00 (sem separador de milhares), nem como 1250000.0. O XSD define os elementos de montante como xs:decimal com uma restrição fractionDigits de 2. Os montantes resultantes de operações de divisão no código têm de ser explicitamente arredondados e formatados antes de serem inseridos no XML.

Campos booleanos: true/false em minúsculas

O elemento is_suspicious e os restantes campos booleanos do esquema goAML utilizam o tipo boolean do XML Schema, que aceita true e false (em minúsculas) ou 1 e 0. Muitos programadores, sobretudo os que trabalham em linguagens com representações booleanas que não distinguem maiúsculas de minúsculas, geram inadvertidamente True, False, TRUE ou FALSE — valores que falham todos a validação do esquema. Algumas implementações do portal goAML aceitam 1/0, mas isso varia; utilize sempre true/false para garantir a máxima compatibilidade.

Restrições de enumeração: tipos de transacção e de documento de identificação

O esquema goAML define conjuntos de enumeração rigorosos para elementos como transaction_type, id_type, account_type, gender, address_type e submission_code. Cada valor inserido nestes elementos tem de corresponder exactamente a um dos valores permitidos definidos no XSD. Se o seu sistema bancário central utilizar tabelas de códigos diferentes — por exemplo, armazenando os tipos de transacção como códigos numéricos como 01, 02, 03 —, é necessária uma camada de mapeamento de códigos que os converta nos valores de enumeração goAML antes da geração do XML.

Este mapeamento é também específico de cada país. O esquema alargado do FRC do Quénia acrescenta valores de tipo de transacção para os canais de dinheiro móvel (MOBILE_WALLET_MPESA, MOBILE_WALLET_AIRTEL, MOBILE_WALLET_TKASH) que não constam do esquema de base do UNODC. Gerar uma comunicação com um tipo de transacção do esquema de base para uma transacção de dinheiro móvel submetida ao FRC do Quénia passará a validação do XSD de base, mas falhará a validação nacional.

Espaços em branco e elementos vazios

O esquema goAML tem regras específicas sobre elementos vazios e elementos em falta. Para os elementos opcionais sem valor, a abordagem correcta é omitir totalmente o elemento do XML gerado — e não incluir uma etiqueta vazia. <fiu_ref_number></fiu_ref_number> é, tecnicamente, XML bem formado, mas algumas implementações do portal goAML rejeitam-no como inválido segundo o esquema quando o elemento está definido com uma restrição minLength de 1. O comportamento correcto é omitir totalmente fiu_ref_number quando não há valor para preencher.

Inversamente, os elementos obrigatórios que têm um valor não podem ter espaços em branco no início nem no fim. <institution_code> KE-FRC-12345 </institution_code> falhará a validação nas implementações rigorosas. Todos os valores de texto devem ter os espaços iniciais e finais removidos antes da inserção.

---

Extensões XML específicas de cada país

Como o FRC do Quénia alarga o XSD de base

O Financial Reporting Centre (FRC) do Quénia publica um perfil de validação que alarga o XSD de base do UNODC com requisitos obrigatórios adicionais. As extensões específicas do Quénia mais significativas são:

Obrigatoriedade do National ID: para qualquer nacional queniano que surja como from_person ou to_person numa comunicação, os elementos id_number e id_type são obrigatórios — e não opcionais, como no esquema de base. O id_type tem de ser NATIONAL_ID para os cidadãos quenianos. Os cidadãos estrangeiros têm de indicar PASSPORT.

Classificação do canal de dinheiro móvel: as transacções que envolvam M-PESA, Airtel Money ou T-Kash têm de utilizar os valores de enumeração alargados de transaction_type do FRC (MOBILE_WALLET_MPESA, MOBILE_WALLET_AIRTEL, MOBILE_WALLET_TKASH) e têm de incluir o elemento mobile_money_agent_code quando a transacção tiver sido efectuada através de um agente.

Data de nascimento obrigatória para a pessoa que comunica: embora o esquema de base do UNODC trate a data de nascimento como opcional no elemento reporting_person, as regras de validação do FRC do Quénia tornam-na obrigatória. As comunicações sem a data de nascimento da pessoa que comunica são rejeitadas.

Limiar das CTR: o limiar das CTR no Quénia é de 15 000 USD ou o seu equivalente em qualquer outra moeda, nos termos do artigo 44(6) da POCAMLA e do artigo 40(1) do regulamento POCAMLR 2023 (Circular n.º 4 de 2023 do FRC). Cada transacção em numerário, considerada individualmente, que seja igual ou superior ao limiar tem de ser comunicada, registando-se no XML da CTR o montante na moeda original, a taxa de câmbio aplicada e o contravalor em USD. A actividade do mesmo dia abaixo do limiar não é agregada numa CTR; quando aparenta ser fraccionamento, a instituição submete uma STR.

Extensões do FIC da Zâmbia

O Financial Intelligence Centre (FIC) da Zâmbia aplica o seu próprio perfil de validação sobre o esquema de base do UNODC. As principais diferenças em relação ao Quénia incluem o código da moeda (ZMW), limiares de CTR diferentes e enumerações de tipos de transacção específicas da Zâmbia. O FIC exige também o número de registo comercial (Business Registration Number) das partes que são entidades, que corresponde a um campo diferente do preferido pelo FRC do Quénia.

As instituições que se expandem do Quénia para a Zâmbia não podem reutilizar um motor de geração de XML configurado para o Quénia sem alterar a configuração do perfil de validação.

Porque é que um único modelo XML não funciona em todos os países

Esta é a razão de fundo pela qual os geradores de XML goAML prontos a usar, construídos para um único país, falham quando são implementados em ambientes com vários países. O XSD de base do UNODC fornece o invólucro estrutural. As UIF nacionais aplicam depois regras de validação que alteram os elementos obrigatórios, alargam os conjuntos de enumeração e acrescentam elementos inteiramente específicos do país. Um modelo codificado de forma rígida para o FRC do Quénia gerará XML inválido para a FIA do Uganda, e vice-versa.

Um motor de geração de XML multipaís em produção tem de ser conduzido por perfis de configuração específicos de cada país, que declarem as regras de validação aplicáveis, os campos obrigatórios, as extensões de enumeração e os dados do ponto de acesso (endpoint) da UIF de cada país de destino.

---

Validação XSD no código

Validação de esquemas XML em .NET com XmlSchemaSet

Em .NET, a validação XSD goAML é feita com a classe System.Xml.Schema.XmlSchemaSet, em conjunto com um XmlReader configurado com definições de validação. O processo carrega o ficheiro XSD (ou os ficheiros, se a extensão nacional for um XSD sobreposto separado), acrescenta-o ao conjunto de esquemas e valida face a ele o documento XML gerado antes de tentar a submissão.

Os erros de validação são expostos através de uma função de retorno (callback) ValidationEventHandler, que deve capturar a mensagem de erro completa, o número da linha no XML de origem e o caminho do elemento no esquema. Estas três informações são essenciais para diagnosticar que parte da estrutura da comunicação falhou a validação e porquê. As implementações em produção devem registar todos os erros de validação com o contexto completo da comunicação, para permitir um diagnóstico e uma correcção rápidos.

A etapa de validação tem de ocorrer depois de concluída a geração do XML, mas antes de o documento ser serializado no conteúdo a submeter (payload). Tentar validar a meio da geração (enquanto o documento ainda está a ser construído) produz erros enganadores, porque os elementos obrigatórios que só serão acrescentados mais tarde são assinalados como em falta.

Validação em Python com lxml

Os programadores Python que utilizam a biblioteca lxml dispõem da classe lxml.etree.XMLSchema para a validação baseada em XSD. O padrão consiste em analisar o ficheiro XSD para um objecto XMLSchema e, em seguida, chamar .validate() sobre a árvore do documento gerado. O atributo XMLSchema.error_log fornece a lista completa dos erros de validação, com informação sobre o caminho.

Uma subtileza do lxml: a biblioteca é rigorosa no tratamento dos espaços de nomes (namespaces). A declaração xmlns do esquema goAML tem de figurar no elemento raiz e corresponder exactamente ao espaço de nomes declarado no XSD. Um erro comum é gerar um ficheiro XML com um URI de espaço de nomes ligeiramente diferente (por exemplo, com uma barra final, ou com en em vez de EN), o que faz o esquema falhar com um erro «no matching global element declaration», em vez de um erro específico ao nível do campo.

A abordagem Java com ligações JAXB

Os programadores Java que trabalham com o goAML utilizam habitualmente o JAXB (Java Architecture for XML Binding) para gerar as ligações (bindings) de classes Java directamente a partir do XSD. O compilador xjc lê o XSD e produz classes Java anotadas para cada tipo do esquema, juntamente com o código de marshalling e unmarshalling. A geração das comunicações passa então a ser uma questão de construir grafos de objectos Java e de os converter (marshalling) em XML — o marshaller JAXB aplica automaticamente as restrições do esquema durante a serialização.

A abordagem JAXB tem a vantagem da segurança de tipos em tempo de compilação: campos com o tipo errado ou valores obrigatórios em falta tornam-se erros de compilação, e não falhas de validação em tempo de execução. A desvantagem é que regenerar as ligações JAXB quando o XSD muda obriga a recompilar e a reimplementar o código dependente.

Ferramentas de validação XSD online para testes

Durante o desenvolvimento e os testes de actualização do esquema, as ferramentas de validação XSD online proporcionam um ciclo de retorno rápido sem exigir um ambiente de desenvolvimento local. Ferramentas como FreeFormatter.com e XMLValidation.com aceitam o carregamento de ficheiros XSD e XML e devolvem mensagens de erro de validação pormenorizadas. São úteis para verificações rápidas de coerência, mas não devem substituir a validação automatizada no circuito de implementação — as ferramentas online podem não suportar todas as funcionalidades dos esquemas XSD, e os dados sensíveis de clientes nunca devem ser carregados em validadores públicos.

---

Construir um circuito robusto de geração de XML

Um circuito de geração de XML goAML de nível de produção tem cinco camadas distintas, cada uma com uma responsabilidade específica.

1. Camada de normalização dos dados

Os dados de transacções provenientes dos sistemas bancários centrais chegam em formatos que não são imediatamente utilizáveis em XML goAML. A camada de normalização trata da conversão do formato das datas (DD/MM/YYYY → YYYY-MM-DD), da normalização da precisão dos montantes, da uniformização da codificação de caracteres e da remoção dos caracteres especiais proibidos em XML (bytes nulos, certos caracteres de controlo). Aplica também o truncamento do comprimento dos campos quando os dados recebidos excedem o comprimento máximo definido no esquema.

2. Camada de validação das regras de negócio

Antes de começar a geração do XML, a camada de validação das regras de negócio verifica se os dados do caso reunidos satisfazem todos os requisitos semânticos do tipo de comunicação. Numa CTR: o montante da transacção é igual ou superior ao limiar? O número da conta está presente? O tipo de transacção é um tipo de transacção em numerário? Numa STR: existe pelo menos um código de indicador? A narrativa não está vazia e tem uma extensão adequada? O campo is_suspicious está correctamente definido?

Detectar os erros semânticos nesta camada, antes da geração do XML, produz mensagens de erro muito mais úteis do que detectá-los como falhas de validação XSD depois da geração.

3. Camada de geração do XML

A camada de geração do XML recebe os dados normalizados e validados face às regras de negócio e constrói o documento XML goAML. Os construtores com conhecimento do esquema (builders) — classes ou funções que constroem elementos específicos do esquema a partir de objectos do modelo de dados — são o padrão de arquitectura recomendado. Cada construtor é responsável por um tipo de elemento (PersonBuilder, AccountBuilder, TransactionBuilder) e aplica a formatação, o mapeamento das enumerações e a lógica de inclusão/exclusão de elementos adequados ao perfil do país de destino.

O XML gerado deve ser serializado em memória, numa cadeia de caracteres ou numa matriz de bytes, antes de ser escrito em disco ou submetido, para que a camada de validação o possa inspeccionar antes de sair do sistema.

4. Camada de validação pós-geração

A camada de validação pós-geração aplica ao documento XML gerado o XSD específico do país que foi carregado. Todos os erros de validação são registados com o contexto completo. Se existir algum erro de validação, a comunicação é assinalada para revisão em vez de ser submetida. A equipa de conformidade vê o campo concreto que falhou a validação e a regra do esquema que violou, o que permite um diagnóstico rápido sem necessidade de intervenção dos programadores.

5. Camada de submissão e acompanhamento

Depois de o documento XML passar a validação pós-geração, a camada de submissão transmite-o ao portal da UIF. As respostas à submissão — confirmações de aceitação, mensagens de rejeição com códigos de motivo e números de referência atribuídos pela UIF — são capturadas e guardadas associadas ao registo da comunicação original. As respostas pendentes são consultadas periodicamente até ser recebido um estado final. Os pormenores das rejeições são apresentados à equipa de conformidade com orientações para a correcção e a nova submissão.

---

Quando utilizar um motor de geração de XML pronto a usar

O encargo de manutenção quando o UNODC actualiza o XSD

O UNODC já publicou várias versões do XSD do esquema goAML, e esta tendência vai continuar. Quando uma UIF nacional implementa uma nova versão do XSD, o código interno de geração de XML tem de ser actualizado, testado e implementado — muitas vezes sob pressão de tempo, porque as UIF fixam prazos para a migração. Se o seu motor de geração de XML for mantido internamente, cada actualização do esquema vai parar à secretária da sua equipa de desenvolvimento, em concorrência com as outras prioridades de desenvolvimento.

Actualizações das regras de cada país

O FRC do Quénia publica periodicamente orientações de validação actualizadas. Quando é acrescentado um novo valor de enumeração de tipo de transacção (por exemplo, com a entrada de um novo operador de dinheiro móvel no mercado), todos os mapeamentos de enumeração codificados de forma rígida na sua base de código interna têm de ser actualizados. Quando é introduzido um novo campo obrigatório nas STR, o modelo de dados da sua gestão de casos tem de ser alargado, o seu fluxo de trabalho tem de ser actualizado para recolher os novos dados e o seu código de geração de XML tem de ser actualizado para preencher o novo elemento.

Uma plataforma pronta a usar inclui estas actualizações no seu modelo de licenciamento — as alterações do esquema são um problema do fornecedor, não seu.

Quadro de decisão: desenvolver ou comprar

Para as instituições com grandes equipas de desenvolvimento internas, profundos conhecimentos de tecnologia de conformidade e uma necessidade estratégica de lógica de geração de XML altamente personalizada, o desenvolvimento interno pode justificar-se. Para a maioria das instituições financeiras da África Oriental, o perfil económico e de risco favorece claramente uma plataforma concebida para o efeito e mantida por especialistas na conformidade com o esquema goAML.

---

Dê o passo seguinte

A plataforma de comunicações goAML da Creodata para a prevenção e o combate ao branqueamento de capitais e ao financiamento do terrorismo (BC/FT) inclui um motor de geração de XML pronto para produção, mantido face ao XSD goAML v5.0.2 em vigor, com perfis de validação específicos para o FRC do Quénia, a FIA do Uganda, a FIU da Tanzânia, o FIC da Zâmbia e o FIC do Ruanda. O motor trata automaticamente da codificação, da formatação decimal, da normalização das datas, do mapeamento das enumerações e da validação XSD — as equipas de conformidade interagem com formulários estruturados, não com XML.

Veja o motor de geração de XML em funcionamento numa demonstração em directo: Peça uma demonstração em creodata.com/demo

Perguntas frequentes

Para que versão do esquema goAML devo gerar o XML?

A versão 5.0.2 é o esquema implementado pelas UIF da África Oriental abordadas neste guia. Fixe o seu gerador na versão exacta publicada pela sua UIF e volte a testar quando esta migrar: as versões do UNODC nem sempre são retrocompatíveis, pelo que XML que era válido segundo a v4 pode falhar em determinadas combinações de elementos da v5.

Porque rejeita o portal goAML um ficheiro que é válido localmente?

Normalmente, por uma de quatro razões: uma marca de ordem de bytes (BOM) UTF-8 escrita por uma biblioteca XML do Windows; uma extensão nacional que o seu XSD local não inclui, como os tipos de transacção de dinheiro móvel do FRC do Quénia; um elemento opcional vazio que deveria ter sido omitido; ou uma verificação de regras de negócio executada após a validação do esquema — um número de entidade comunicante que não corresponde ao registo da UIF, ou uma referência de comunicação duplicada.

Que formatos de data, montante e booleano exige o XSD goAML?

As datas seguem exclusivamente o formato ISO 8601 YYYY-MM-DD. Os montantes são xs:decimal, com exactamente duas casas decimais e sem separadores de milhares (1250000.00). Os booleanos são true ou false, em minúsculas. As exportações do core banking em DD/MM/YYYY, as datas em número de série do Excel e valores como True ou FALSE têm de ser normalizados antes da geração.

Qual é a estrutura de uma comunicação XML goAML?

Report → Transaction → Party → Account → ID document → Address. Uma comunicação contém uma ou mais transacções; cada transacção identifica as partes de ambos os lados (from_person ou from_entity, to_person ou to_entity), as respectivas contas, documentos de identificação e moradas. Uma CTR exige tipos de transacção em numerário e o pormenor completo das contas; uma STR exige is_suspicious definido como true, uma narrativa substantiva no campo reason e pelo menos um código de indicador.

Onde posso descarregar o XSD goAML oficial?

Na documentação goAML do UNODC — e, mais importante ainda, no portal da sua própria UIF, porque as extensões nacionais alteram o esquema de base. Valide face à cópia publicada pela UIF, e não face a uma cópia descarregada de terceiros.