Esquema XML goAML v5.0.2: referência dos campos obrigatórios das CTR e STR

Quando um responsável pela conformidade submete uma comunicação de transacções em numerário (CTR) ou uma comunicação de operação suspeita (STR) ao Financial Reporting Centre (FRC) do Quénia, o portal goAML do FRC não recebe um formulário nem uma folha de cálculo. Recebe um ficheiro XML que tem de estar rigorosamente em conformidade com o esquema XSD goAML v5.0.2 — uma especificação, aplicável por máquina, de cada elemento, tipo de dados, restrição de comprimento e regra estrutural que uma comunicação válida tem de cumprir.

A maioria das rejeições de submissões tem origem numa de duas causas de fundo: a equipa de informática da instituição obrigada gerou um ficheiro XML que não cumpre o esquema, ou a equipa de conformidade preparou dados que não satisfazem os requisitos de campos obrigatórios específicos do Quénia, que se sobrepõem ao esquema de base. Ambos os problemas são evitáveis com o material de referência adequado.

Este artigo é essa referência. Apresenta uma análise completa, campo a campo, dos elementos XML obrigatórios nas submissões CTR e STR ao FRC do Quénia, dos tipos de dados e das restrições de formato que cada campo impõe e das regras de localização específicas do Quénia que se aplicam para além do XSD de base. Os programadores de informática que constroem circuitos de geração de XML e os responsáveis pela conformidade que verificam a qualidade dos dados antes da submissão encontrarão aqui tudo aquilo de que precisam.

---

Compreender o esquema XSD goAML v5.0.2

O que significa a validação segundo o esquema XSD e porque é importante

Um XSD (XML Schema Definition, ou definição de esquema XML) é uma especificação formal, escrita em XML, que define a estrutura admissível, os nomes dos elementos, os tipos de dados, as restrições de valores e a cardinalidade (obrigatório ou opcional, número mínimo e máximo de ocorrências) de cada elemento de um documento XML correspondente.

Quando o portal goAML do FRC recebe a sua submissão XML, passa o ficheiro por um validador de esquema XSD antes de qualquer analista humano o ver. O validador verifica cada elemento do ficheiro face às regras definidas no esquema XSD goAML v5.0.2. Se algum elemento violar alguma regra — um campo obrigatório em falta, uma data no formato errado, uma cadeia de caracteres que excede o comprimento máximo, um valor enumerado que não consta da lista permitida —, o validador devolve um erro de validação do esquema e toda a submissão é rejeitada.

A validação do esquema é binária: o ficheiro ou passa na totalidade ou falha. Um ficheiro com 99 elementos correctos e uma data mal formatada falha de forma tão definitiva como um ficheiro com erros estruturais de fundo. É por isso que a validação XSD antes da submissão não é opcional — é o padrão mínimo de qualquer processo de geração de CTR ou STR.

Os seis níveis de aninhamento do esquema

O esquema XSD goAML v5.0.2 organiza os dados da comunicação numa estrutura hierárquica de seis níveis. Compreender esta hierarquia é essencial para os programadores que escrevem código de geração de XML e para as equipas de conformidade que revêem o XML produzido.

Nível 1: Report (comunicação) — O elemento raiz do documento XML. Contém os campos do cabeçalho da comunicação que identificam o tipo de comunicação, a instituição obrigada, a data da submissão e o responsável pela conformidade encarregado da comunicação. Todas as CTR e STR começam por este elemento.

Nível 2: Transaction (transacção) — Um ou mais elementos de transacção aninhados no Report. Cada elemento Transaction descreve uma única transacção financeira, incluindo a data, o montante, a moeda e o tipo. É gerada uma CTR por cada transacção elegível igual ou superior ao limiar equivalente a 15 000 USD. Uma STR contém normalmente um ou mais elementos Transaction ligados à actividade suspeita comunicada.

Nível 3: Party (parte) — Cada Transaction contém elementos Party que identificam as pessoas singulares ou as entidades de cada lado da transacção. As partes são tipificadas pela sua função: from_person ou from_entity para o lado do débito, to_person ou to_entity para o lado do crédito. Num depósito em numerário, o cliente é o from_person e o banco é o to_entity.

Nível 4: Account (conta) — Os elementos Account estão aninhados nos elementos Party. Contêm o número da conta, o código do balcão, o tipo de conta e a moeda de denominação da conta pela qual a transacção passou. É obrigatório um elemento Account sempre que o número da conta seja conhecido.

Nível 5: ID (identificação) — Os elementos de documento de identificação estão aninhados nos elementos Party do tipo pessoa. Registam o tipo de documento de identificação (National ID, passaporte, alien ID), o número do documento, o país emissor e, quando aplicável, a data de validade. Para os nacionais quenianos, o elemento National ID é obrigatório.

Nível 6: Address (morada) — Os elementos Address estão aninhados nos elementos Party (pessoas e entidades). Registam o país, o condado/estado, a cidade/localidade e a morada da parte. No mínimo, o país e a localidade são obrigatórios nas submissões ao FRC do Quénia.

Diferenças entre as estruturas de esquema das STR e das CTR

As STR e as CTR utilizam o mesmo esquema subjacente, o XSD goAML v5.0.2. Distinguem-se pelo valor do elemento report_type (CTR ou STR) e pelos campos obrigatórios específicos que se aplicam a cada tipo.

Nas CTR, os campos obrigatórios centram-se em dados de transacção precisos: montantes, moedas, tipos de transacção e identidade do cliente verificada com um National ID. O campo da narrativa não se aplica.

Nas STR, o foco dos campos obrigatórios passa para a fundamentação da suspeita: o campo reason (a narrativa) é obrigatório e tem de ser substantivo; o campo is_suspicious tem de estar definido como TRUE; os códigos de indicador têm de estar preenchidos; e a narrativa tem de ligar as transacções a uma tipologia BC/FT (branqueamento de capitais e financiamento do terrorismo) reconhecida. Os dados das transacções continuam a ser exigidos, mas o conteúdo analítico da comunicação tem maior peso no esquema.

Extensões específicas na configuração do FRC do Quénia

O esquema XSD goAML v5.0.2 de base, tal como distribuído pelo Escritório das Nações Unidas sobre Drogas e Crime (UNODC) para utilização por todas as unidades de informação financeira (UIF) participantes, contém um conjunto normalizado de elementos aplicáveis a nível mundial. O FRC do Quénia configurou o portal para impor campos obrigatórios e regras de negócio adicionais, específicos do enquadramento regulamentar e financeiro do Quénia. Estes incluem:

• National ID obrigatório para os nacionais quenianos (o esquema de base trata a identificação como recomendada, e não obrigatória)
• Classificação obrigatória do canal de dinheiro móvel nas transacções M-PESA, Airtel Money e T-Kash
• O código do balcão tem de corresponder a um balcão registado no Central Bank of Kenya (CBK)
• O número de registo da entidade no FRC (FRC Entity Registration Number) tem de estar presente e corresponder exactamente aos registos do FRC
• Mínimo reforçado para a narrativa nos casos com indicadores de financiamento do terrorismo (TF) — na prática, 500 palavras ou mais

Estas regras específicas do Quénia são aplicadas na camada de validação das regras de negócio, após a validação do esquema. Um ficheiro pode passar a validação XSD e, ainda assim, falhar nas verificações das regras de negócio do FRC.

---

Campos obrigatórios das CTR — referência completa

Tabela 1: campos do cabeçalho da comunicação

Nota específica do Quénia sobre reporting_entity_id: o formato do número de registo da entidade no FRC é FRC/INST/YYYY/NNNN. Mesmo variações mínimas — espaços no fim, letras minúsculas, omissão das barras — provocam a rejeição ERR_045 por violação de regra de negócio. Copie o número directamente do seu certificado de registo no FRC e valide-o carácter a carácter.

Nota específica do Quénia sobre report_reference: a referência única da comunicação não pode ser reutilizada entre submissões. A maioria das instituições utiliza um formato que combina o código da instituição, o tipo de comunicação, a data e um número sequencial (p. ex., NSBK-CTR-20260325-001). As referências duplicadas provocam a rejeição com o erro ERR_008.

Tabela 2: campos da transacção

Códigos de canal do Quénia para as transacções de dinheiro móvel:

Nota sobre transaction_type no dinheiro móvel: se um cliente depositar numerário num agente M-PESA e o valor for creditado numa conta bancária, o transaction_type é CASH_DEPOSIT e o channel é MOBILE_WALLET_MPESA. O tipo de transacção descreve a natureza do movimento de numerário; o canal descreve o mecanismo.

Tabela 3: campos de identidade do cliente (específicos do Quénia)

Regra crítica do Quénia — formato do National ID: os números do bilhete de identidade nacional queniano (National Identity Card) têm exactamente 8 dígitos numéricos. Sem letras, sem hífenes, sem espaços. O formato é NNNNNNNN. Os erros mais comuns incluem:

• Submeter um número de 7 dígitos (cartões mais antigos, emitidos antes de 1990 — continuam a ser números de identificação válidos de 7 dígitos e devem ser submetidos com 7 dígitos, sem zeros à esquerda)
• Incluir o número de série do cartão em vez do número de identificação
• Submeter um número KRA PIN (que começa por uma letra) como National ID
• Submeter o número do passaporte de um nacional queniano quando existe um National ID

Para os cidadãos estrangeiros, o id_type tem de ser PASSPORT e tem de ser submetido o número do passaporte. O FRC não aceita outros tipos de documento de identificação estrangeiros em substituição do passaporte quando a comunicação respeita a partes não quenianas.

---

Campos obrigatórios das STR — referência completa

A STR utiliza a mesma estrutura de esquema que a CTR para os campos de transacção e de identidade. Os campos obrigatórios adicionais, específicos das STR, concentram-se no cabeçalho da comunicação (a secção de fundamentação da suspeita) e nos elementos de análise do caso.

Nota sobre o comprimento do campo reason: embora o máximo do esquema para o campo reason seja de 4 000 caracteres, a validação das regras de negócio do FRC impõe mínimos práticos consoante o tipo de indicador. Casos correntes de branqueamento de capitais (ML): mínimo de cerca de 200 caracteres (aproximadamente 30–40 palavras). Casos com indicadores de TF: mínimo de cerca de 3 000 caracteres (aproximadamente 500 palavras). Uma narrativa que cumpra o mínimo técnico, sendo embora insuficiente quanto à substância, passará a validação do esquema, mas dará origem a pedidos de informação complementar do FRC.

Nota sobre indicator_codes: os códigos de indicador têm de constar da lista de códigos de indicador publicada pelo FRC do Quénia. Submeter códigos personalizados ou códigos da implementação da UIF de outro país provoca a rejeição ERR_045 por violação de regra de negócio. Consulte o artigo relacionado Biblioteca de indicadores de STR: tipologias BC/FT para os bancos do Quénia (2026)EN para a referência actual dos códigos de indicador do FRC do Quénia.

Campos de transacção nas STR: todos os campos de transacção da tabela das CTR acima se aplicam às submissões de STR. A diferença essencial é que uma STR pode estar ligada a transacções que, individualmente, ficam abaixo do limiar de CTR equivalente a 15 000 USD — o critério para submeter uma STR é a suspeita, não o montante.

---

Regras de validação específicas do Quénia

Validação do formato do National ID

Como descrito acima, o FRC do Quénia aplica uma validação rigorosa do formato dos números de National ID. A regra de validação verifica:

1. Tipo de documento NATIONAL_ID — o campo tem de conter exactamente 7 ou 8 dígitos numéricos (7 nos documentos mais antigos, 8 nos emitidos aproximadamente a partir de 1991)
2. Ausência de caracteres alfabéticos, espaços, hífenes ou outros separadores
3. O número de identificação não pode ser composto só por zeros nem pela repetição de um único dígito (p. ex., 00000000 e 11111111 falham as verificações de plausibilidade)

A forma mais fiável de passar esta validação é extrair o número de identificação directamente de uma fonte KYC verificada e executar uma verificação de formato antes da submissão. Muitos bancos guardam os números de identificação nos seus sistemas KYC com espaços à esquerda ou concatenados com números de série — elimine todos os caracteres não numéricos antes de os incluir no XML.

Regras de classificação do canal de dinheiro móvel

O FRC do Quénia exige que as transacções de dinheiro móvel sejam classificadas com os códigos de canal definidos na Tabela 2 acima. As regras de classificação são as seguintes:

• Qualquer transacção iniciada através do M-PESA, independentemente de a origem ou o destino final ser uma conta bancária, tem de utilizar MOBILE_WALLET_MPESA
• Uma transferência do banco para o M-PESA, da conta bancária do cliente para o número M-PESA a ela associado, é classificada como MOBILE_WALLET_MPESA
• Um depósito em numerário num agente M-PESA creditado numa conta bancária é CASH_DEPOSIT, com o canal MOBILE_WALLET_MPESA
• Os levantamentos de numerário em ATM têm de utilizar ATM_CASH, e não BRANCH_CASH
• Os depósitos em numerário através de agentes bancários (p. ex., Equity Agents, Co-op Kwa Jirani) têm de utilizar AGENT_CASH

Utilizar o código de canal errado — ou omitir o campo do canal nas transacções de dinheiro móvel — provoca a rejeição ERR_045 por violação de regra de negócio.

Requisito de comprimento reforçado da narrativa com indicadores de TF

Nas STR que incluam qualquer código de indicador de TF (Terrorist Financing, financiamento do terrorismo), a prática do FRC do Quénia exige que a narrativa do campo reason cumpra padrões reforçados de comprimento e de pormenor. Embora o esquema XSD não imponha um número de palavras, a validação das regras de negócio do FRC assinala as STR com indicadores de TF cujas narrativas tenham menos de cerca de 3 000 caracteres (aproximadamente 500 palavras) para revisão manual e provável pedido de informação complementar.

As narrativas de TF têm de incluir, para além dos cinco elementos habituais: a(s) jurisdição(ões) de risco elevado concretamente envolvida(s), os nomes de quaisquer entidades ou pessoas sancionadas referidas nos alertas de filtragem, o canal e o mecanismo da transferência de fundos e a resposta da instituição, incluindo qualquer congelamento de conta ou notificação regulamentar.

Campos que o FRC do Quénia torna obrigatórios para além do XSD de base

Os campos seguintes são opcionais no XSD goAML v5.0.2 de base, mas são tratados como obrigatórios pela camada de regras de negócio do FRC do Quénia:

---

Erros de validação XML mais comuns e como os corrigir

---

Automatizar a geração de XML para evitar erros de esquema

Porque é que a geração manual de XML conduz a rejeições

Cada ficheiro XML montado manualmente é um produto artesanal — e os produtos artesanais introduzem erro humano. Os tipos de erro que provocam rejeições são exactamente os erros que os seres humanos cometem: uma data formatada como DD/MM/YYYY em vez de YYYY-MM-DD, um montante que inclui uma vírgula como separador de milhares, um valor de tipo de transacção quase certo mas ligeiramente diferente, um National ID com um espaço à esquerda herdado da exportação KYC.

Quando a geração de XML é feita manualmente — seja num editor de texto, numa macro Excel ou num script feito à medida —, as rejeições à primeira submissão são uma ocorrência rotineira, e cada uma acrescenta ao calendário de submissão um ciclo de retrabalho: encontrar o erro, corrigir os dados, gerar novamente o ficheiro e voltar a submeter.

O que um motor de XML automatizado faz de diferente

Um motor automatizado de geração de XML, concebido especificamente para a conformidade com o esquema goAML, elimina sistematicamente estes modos de falha:

• Mapeamento de campos com conhecimento do esquema: cada campo de entrada é mapeado para o nome exacto do respectivo elemento no XSD goAML. Não há transcrição manual de nomes de elementos.
• Imposição dos tipos de dados na entrada: os campos de data só aceitam datas válidas e produzem-nas no formato YYYY-MM-DD. Os campos decimais eliminam os caracteres de formatação e impõem duas casas decimais.
• Validação das enumerações: os campos de tipo de transacção, canal e tipo de documento de identificação são seleccionados entre os valores enum exactos permitidos — sem introdução de texto livre.
• Aplicação das regras de negócio do Quénia: o formato do National ID, o registo do código do balcão, a classificação do canal de dinheiro móvel e a correspondência do número de registo da entidade no FRC são todos validados antes de o XML ser gerado.
• Validação XSD na saída: o XML gerado é validado face ao XSD goAML v5.0.2 antes de ser disponibilizado para submissão. Os ficheiros que falham a validação não são apresentados ao responsável pela conformidade enquanto o problema de dados subjacente não for resolvido.
• Detecção do limiar por transacção, com conversão cambial: cada transacção em numerário é avaliada em tempo real face ao limiar equivalente a 15 000 USD, ficando a taxa de câmbio aplicada registada na CTR.

O resultado é um circuito de submissão que produz sempre ficheiros XML válidos segundo o esquema e conformes com as regras do FRC do Quénia — com uma taxa de rejeição que se aproxima de zero.

---

Perguntas frequentes

Quais são os seis níveis do esquema XSD goAML v5.0.2?

Report (a raiz, com o cabeçalho que identifica o tipo de comunicação, a instituição, a data da submissão e o responsável pela conformidade); Transaction (data, montante, moeda e tipo); Party (from_person ou from_entity do lado do débito, to_person ou to_entity do lado do crédito); Account (número, código do balcão, tipo e moeda); ID (tipo de documento de identificação, número, país emissor e validade); e Address (país, condado, localidade e rua). Um ficheiro falha a validação se qualquer nível violar uma regra, por mais pequena que seja.

Que campos exige o FRC do Quénia para além do esquema goAML de base?

O número do National ID para os nacionais quenianos, o código do balcão (verificado face ao registo de balcões do CBK), o canal de dinheiro móvel nas transacções M-PESA, Airtel Money e T-Kash e, nas STR, os campos action_taken, date_of_suspicion e tipping_off_acknowledged. Estes campos são impostos pela camada de regras de negócio do FRC após a validação XSD, pelo que um ficheiro pode passar o esquema e, ainda assim, ser rejeitado.

Que formato deve ter um National ID queniano num ficheiro goAML?

Sete ou oito dígitos numéricos, sem espaços, hífenes nem letras, e não um valor implausível, como uma sequência só de zeros. Elimine todos os caracteres não numéricos do registo KYC antes da geração; um formato errado desencadeia o erro de regra de negócio ERR_045.

Em que diferem os ficheiros CTR e STR no esquema?

Partilham o mesmo XSD e distinguem-se pelo elemento report_type. Uma CTR centra-se em dados de transacção precisos e na identidade verificada, sem narrativa. Uma STR tem de conter uma narrativa substantiva no campo reason, is_suspicious definido como true, códigos de indicador e uma ligação a uma tipologia reconhecida — e a narrativa tem de ser mais longa e mais pormenorizada quando está presente um indicador de financiamento do terrorismo.

Quais são os erros de validação goAML mais comuns?

Datas que não estão no formato YYYY-MM-DD (ERR_001), montantes com símbolos ou separadores de milhares (ERR_002), tipos de transacção que não constam da enumeração (ERR_003), um id_number em falta (ERR_004), códigos de moeda não ISO, como Ksh (ERR_005), um campo reason vazio numa STR (ERR_006), um report_reference duplicado (ERR_008) e um reporting_entity_id que não corresponde ao registo do FRC (ERR_012). A tabela acima indica a correcção de cada um.

Construa o seu circuito de submissão sobre uma base de esquema fiável

Compreender o esquema XML goAML é a base de um processo fiável de submissão de CTR e STR. Quer a sua instituição esteja a construir o seu próprio circuito de geração de XML, quer esteja a avaliar uma plataforma concebida para o efeito, a referência de campos e as regras de validação deste artigo dão-lhe aquilo de que precisa para acertar à primeira submissão de forma consistente.

A plataforma goAML da Creodata trata automaticamente de todo o ciclo de vida da conformidade com o esquema — do mapeamento dos campos e da imposição dos tipos de dados, passando pela validação das regras de negócio específicas do Quénia, até à produção de XML validado segundo o XSD. A sua equipa de conformidade concentra-se na análise; a plataforma trata dos requisitos técnicos de submissão.

Veja a plataforma em funcionamento numa demonstração em directo.

Pedir uma demonstração → https://www.creodata.com/demo

---

Artigos relacionados:

• Como submeter uma CTR ao FRC do Quénia: guia passo a passoEN
• Submissão goAML rejeitada? Como diagnosticar e corrigir os erros mais comuns
• Como redigir a narrativa de uma STR para o goAML: boas práticas