Submissão goAML rejeitada? Como diagnosticar e corrigir os erros mais comuns

As rejeições à primeira submissão fazem parte do dia-a-dia das instituições que preparam as submissões goAML à mão. Se a sua comunicação de transacções em numerário (CTR) ou a sua comunicação de operação suspeita (STR) acabou de ser devolvida pelo portal do Financial Reporting Centre (FRC), a unidade de informação financeira (UIF) do Quénia, está em boa companhia — mas isso não torna o retrabalho menos frustrante, sobretudo quando se aproxima um prazo de submissão.

O ciclo de rejeições é um dos padrões mais corrosivos nas operações de conformidade em matéria de prevenção e combate ao branqueamento de capitais e ao financiamento do terrorismo (BC/FT). Um analista passa duas horas a preparar uma submissão; esta é rejeitada; o analista passa mais 90 minutos a diagnosticar e a corrigir o problema; a submissão volta a ser rejeitada por outro erro — e passaram dois dias sem que nada tenha sido submetido, com o prazo cada vez mais próximo. Entretanto, o gestor de conformidade tem de responder a perguntas sobre a razão pela qual os indicadores de pontualidade das submissões da instituição se estão a deteriorar.

Este guia quebra o ciclo. Explica exactamente como ler um aviso de rejeição do FRC, apresenta uma referência numerada de resolução de problemas para as dez causas de rejeição mais comuns, percorre o processo de ressubmissão e mostra como evitar, logo à partida, que as rejeições aconteçam.

Compreender os avisos de rejeição goAML

O que o FRC lhe envia quando uma submissão falha

Quando o portal goAML do FRC rejeita uma submissão, gera uma resposta de rejeição que é entregue de uma de duas formas, consoante a natureza da falha:

Mensagem de erro ao nível do portal: se o ficheiro estiver de tal forma mal formado que o portal não o consiga sequer interpretar — ficheiro truncado, codificação XML inválida, carregamento corrompido —, o portal devolve de imediato uma mensagem de erro no ecrã de carregamento. Esta mensagem é breve e muitas vezes genérica (p. ex., «Não foi possível processar o ficheiro. Verifique o formato do ficheiro.»). Não contém códigos de erro detalhados. Este tipo de erro significa que o seu XML não está bem formado e tem de ser verificado ao nível estrutural antes de poder passar ao diagnóstico do esquema ou das regras de negócio.

Aviso de rejeição estruturado (ficheiro de erros XML): para os ficheiros que podem ser interpretados mas falham a validação, o portal do FRC gera um ficheiro XML de resposta de erros estruturado. Este ficheiro contém uma ou mais entradas de erro, cada uma com:

Um código de erro (p. ex., ERR_001, ERR_012, ERR_045)
Um nível de gravidade (FATAL, ERROR, WARNING)
Uma mensagem de erro em inglês simples que descreve o problema concreto
Quando aplicável, o nome do elemento XML e o valor que causou a falha
No caso dos erros de esquema: a localização XPath do elemento em falha na árvore XML

Descarregue este ficheiro de erros a partir do histórico de submissões do portal — é o seu roteiro de diagnóstico. Não tente corrigir os erros com base apenas no ecrã de resumo do portal; o detalhe do ficheiro de erros é essencial para um diagnóstico rigoroso.

Ler os códigos de erro: erros de validação do esquema versus violações de regras de negócio

Os erros de rejeição goAML dividem-se em duas categorias fundamentais, e distingui-las é o primeiro passo do diagnóstico:

Erros de validação do esquema (intervalo ERR_001 a ERR_009): significam que o seu ficheiro XML não cumpre as regras estruturais do esquema XSD goAML v5.0.2. Um campo de data contém um valor que não é uma data, um campo decimal contém uma cadeia de caracteres, falta um elemento obrigatório, um valor enumerado não consta da lista permitida. Os erros de esquema são causados pelo processo de geração do XML — seja na etapa de preparação dos dados, seja na de construção do XML. São normalmente fáceis de diagnosticar, porque o ficheiro de erros identifica o elemento e o valor exactos que falharam.

Violações de regras de negócio (intervalo ERR_010 a ERR_099): significam que o seu XML é estruturalmente válido e passa a validação do esquema, mas viola uma regra de negócio específica do FRC do Quénia. Um número de National ID tem o formato errado, o identificador da entidade obrigada não corresponde aos registos do FRC, um código de balcão não consta do registo do Central Bank of Kenya (CBK), uma STR com indicadores de financiamento do terrorismo (FT) tem uma narrativa insuficiente. Os erros de regras de negócio exigem a verificação dos seus dados face a fontes de referência externas (registos do FRC, registo de balcões do CBK, lista de códigos de indicador do FRC) — a correcção não está na estrutura do XML, mas nos dados subjacentes.

Prioridade: corrigir primeiro os erros de esquema, depois os erros de regras de negócio

Se o seu aviso de rejeição contiver simultaneamente erros de esquema e violações de regras de negócio, corrija primeiro os erros de esquema. Isto porque os erros de esquema podem ocultar erros de regras de negócio — o portal pode deixar de avaliar as regras de negócio depois de encontrar uma falha de esquema. Quando o seu ficheiro passar a validação do esquema, verá o conjunto completo das violações de regras de negócio, e não uma lista parcial.

Um erro comum é corrigir uma violação de regra de negócio visível e voltar a submeter, apenas para encontrar outra violação na tentativa seguinte — porque o erro de esquema a ocultava. Percorra metodicamente a lista completa de erros antes de voltar a submeter.

Os 10 motivos de rejeição mais comuns (e as respectivas correcções)

1. National ID em falta

Código de erro: ERR_045 (violação de regra de negócio) Mensagem de erro: «O número do National ID é obrigatório para as partes com id_type NATIONAL_ID.» Causa de fundo: o número do National ID do cliente não estava disponível no registo KYC (conheça o seu cliente) no momento em que o XML foi gerado, ou foi mapeado para o campo XML errado. Em alternativa, o campo do número de identificação foi preenchido, mas ficou como uma cadeia vazia, o que passa a validação do esquema mas falha a verificação da regra de negócio que exige conteúdo obrigatório não vazio. Correcção: obtenha o número do National ID do cliente no seu sistema KYC. Verifique se tem exactamente 7–8 dígitos numéricos, sem caracteres não numéricos. Preencha o elemento id_number no XML e volte a validar. Se o National ID estiver efectivamente em falta nos seus registos KYC, inicie a regularização KYC e documente a lacuna antes de voltar a submeter. Não coloque no campo do National ID um KRA PIN (número de identificação fiscal), um número de passaporte ou um número de telefone.

2. Formato de data inválido

Código de erro: ERR_001 (falha na validação do esquema) Mensagem de erro: «O elemento <transaction_date> tem o valor '25/03/2026', que não é um xs:date válido.» Causa de fundo: os campos de data no XML goAML têm de estar no formato ISO 8601: YYYY-MM-DD. Uma data exportada de um sistema bancário central (core banking) no formato de data queniano (DD/MM/YYYY) ou no formato predefinido do Excel (25-Mar-2026) falha a validação do esquema. O erro aplica-se a qualquer campo de data: transaction_date, report_date, date_of_birth, id_expiry_date. Correcção: reformate todos os valores de data para YYYY-MM-DD antes de os inserir no XML. Se o seu XML for gerado por um script ou por uma macro, acrescente a normalização do formato de data na fase de extracção dos dados — não confie no sistema de origem para exportar no formato correcto. Um padrão de expressão regular (regex) para datas válidas é ^\d{4}-\d{2}-\d{2}$. Os meses e os dias com um só dígito têm de ser completados com um zero à esquerda (p. ex., 2026-03-05, e não 2026-3-5).

3. Texto da narrativa vazio

Código de erro: ERR_001 (esquema) ou ERR_045 (regra de negócio) Mensagem de erro: «O elemento <reason> não pode estar vazio» ou «O campo da narrativa da STR não cumpre os requisitos mínimos de conteúdo.» Causa de fundo: o campo reason de uma submissão de STR está vazio, contém apenas caracteres de espaço em branco ou contém um texto provisório como «narrativa pendente» ou «N/A». É o mais evitável de todos os motivos de rejeição — indica que foi submetida uma comunicação incompleta. Correcção: redija uma narrativa substantiva antes de submeter. Para orientações sobre o que a narrativa deve conter e como estruturá-la, consulte Como redigir a narrativa de uma STR para o goAML: boas práticas. Em circunstância alguma submeta uma STR sem uma narrativa concluída. Se a pressão do tempo for uma preocupação, submeta com uma narrativa breve mas completa, que abranja os cinco elementos obrigatórios, e envie depois informação complementar, se necessário.

4. Narrativa demasiado curta (casos de FT)

Código de erro: ERR_045 (violação de regra de negócio) Mensagem de erro: «Uma STR com códigos de indicador de FT exige uma narrativa reforçada. A narrativa actual não cumpre o padrão mínimo de conteúdo.» Causa de fundo: a STR inclui um ou mais códigos de indicador de FT (financiamento do terrorismo), mas a narrativa no campo reason fica aquém do padrão mínimo de conteúdo que o FRC do Quénia aplica às comunicações com indicadores de FT. Na prática, o mínimo ronda as 500 palavras, abrangendo a análise completa da tipologia, incluindo o risco da jurisdição, a identificação da contraparte e a resposta da instituição. Correcção: alargue a narrativa até cumprir os padrões de comunicação de FT. As narrativas de FT têm de incluir: a identificação completa do visado, a descrição de cada transacção suspeita, a explicação da razão pela qual se suspeita de FT (e não apenas de branqueamento de capitais), a menção específica das jurisdições de risco elevado ou das partes sujeitas a sanções envolvidas, a descrição dos fluxos transfronteiriços de fundos, se aplicável, e a resposta da instituição, incluindo qualquer medida tomada em relação à conta e a notificação ao FRC. Se a sua STR envolver um verdadeiro indicador de FT, a narrativa deverá atingir naturalmente 500 palavras ou mais quando todos os elementos exigidos estiverem cobertos.

5. Código de moeda errado

Código de erro: ERR_003 (falha na validação do esquema) Mensagem de erro: «O valor 'Ksh' do elemento <transaction_currency> não consta da enumeração permitida.» Causa de fundo: o campo transaction_currency exige um código de moeda ISO 4217 exacto, de três letras. Entre as variantes quenianas habituais que falham contam-se: Ksh, KSH, K.Sh, KE, KShs, Kshs. Todas são reconhecíveis como xelins quenianos por um leitor humano, mas são inválidas na enumeração do esquema. Correcção: substitua todos os valores de moeda pelos códigos ISO 4217 exactos. O código do xelim queniano é KES. Outras moedas frequentes nas transacções bancárias quenianas: USD (dólar dos Estados Unidos), EUR (euro), GBP (libra esterlina), UGX (xelim ugandês), TZS (xelim tanzaniano). Acrescente uma tabela de consulta de códigos de moeda ao seu processo de preparação de dados, para impor os códigos correctos na origem.

6. Tipo de transacção inválido

Código de erro: ERR_003 (falha na validação do esquema) Mensagem de erro: «O valor 'CASH' do elemento <transaction_type> não consta da enumeração permitida.» Causa de fundo: o campo transaction_type só aceita os valores enumerados específicos definidos no XSD goAML. Entre os valores inválidos frequentes nas submissões de CTR quenianas contam-se: CASH, DEPOSIT, WITHDRAWAL, CASH DEP, CASH WITH, TRANSFER. Mesmo os valores cuja intenção é claramente correcta falham se não corresponderem exactamente. Correcção: utilize apenas os valores enumerados exactos permitidos pelo esquema. Nas submissões de CTR ao FRC do Quénia, os valores válidos de transaction_type são: CASH_DEPOSIT, CASH_WITHDRAWAL, CURRENCY_EXCHANGE. Não utilize abreviaturas, espaços dentro dos valores nem variações de maiúsculas e minúsculas. Se o seu sistema bancário central exportar os códigos de tipo de transacção noutro formato, acrescente um mapeamento de conversão ao seu processo de geração do XML.

7. Identificador da entidade obrigada em falta

Código de erro: ERR_045 (violação de regra de negócio) Mensagem de erro: «O identificador da entidade obrigada não corresponde ao registo do FRC. Campo: reporting_entity_id.» Causa de fundo: o número de registo da entidade no FRC (FRC Entity Registration Number) que consta do XML não corresponde ao número registado junto do FRC, ou o campo está ausente ou vazio. Entre as causas frequentes contam-se: erros de transcrição no número de registo, variações no formato do nome (o esquema exige o nome exacto, tal como registado) e submissões feitas com o número FRC de uma filial quando se pretendia usar o da empresa-mãe (ou vice-versa). Correcção: obtenha o número de registo da sua instituição no FRC directamente a partir do seu certificado de registo no FRC — o documento original, e não um número de memória. Copie-o carácter a carácter para o XML. O formato é FRC/INST/YYYY/NNNN. Confirme que o reporting_entity_name no XML também corresponde exactamente ao nome registado da entidade. Guarde o número correcto no ficheiro de configuração da geração do XML, para eliminar os erros de reintrodução.

8. Referência de comunicação duplicada

Código de erro: ERR_008 (violação de regra de negócio) Mensagem de erro: «O número de referência da comunicação [valor] já foi submetido anteriormente. Cada submissão tem de ter uma referência única.» Causa de fundo: a sua instituição submeteu anteriormente uma comunicação com o mesmo valor de report_reference. Isto pode acontecer quando: uma comunicação rejeitada é submetida de novo através da função Resubmit, mas é gerada por engano uma nova referência; a mesma comunicação é submetida duas vezes devido a uma confusão na navegação do portal; ou a sua lógica de geração de referências não garante a unicidade (p. ex., uma referência baseada apenas na data, sem número sequencial). Correcção em caso de ressubmissão: ao voltar a submeter uma comunicação anteriormente rejeitada, utilize a função Resubmit do portal e indique o identificador da submissão original — não altere o número de referência da comunicação. O FRC acompanha as correcções sob a referência original. Correcção em caso de submissão efectivamente duplicada: gere um novo número de referência único. Actualize o seu esquema de geração de referências para incluir um número sequencial incremental (p. ex., NSBK-CTR-20260325-004), em vez de uma referência baseada apenas na data ou num hash, que pode colidir.

9. Código de indicador inválido

Código de erro: ERR_045 (violação de regra de negócio) Mensagem de erro: «O código de indicador [valor] não é reconhecido na lista de referência de indicadores do FRC do Quénia.» Causa de fundo: o campo indicator_codes contém um ou mais códigos que não existem na referência actual de códigos de indicador do FRC. Isto acontece quando: um analista escreve os códigos de indicador à mão e comete um erro de transcrição; são utilizados códigos da implementação de outra UIF (códigos genéricos do FATF, o Grupo de Acção Financeira ou GAFI, face aos códigos do FRC do Quénia); ou o FRC actualizou a sua lista de códigos de indicador e a lista de referência da sua instituição não foi actualizada. Correcção: obtenha a lista de referência actual dos códigos de indicador do FRC do Quénia directamente junto do FRC ou na secção de dados de referência do portal goAML. Substitua todos os códigos inválidos pelos códigos correctos da lista actual. Se mantiver uma tabela de consulta de códigos de indicador no seu sistema de conformidade, actualize-a face à lista actual do FRC. Considere acrescentar a validação dos códigos de indicador à sua lista de verificação prévia à submissão.

10. Formato do número de conta divergente

Código de erro: ERR_045 (violação de regra de negócio) Mensagem de erro: «O formato do número de conta não corresponde ao padrão esperado para a instituição obrigada.» Causa de fundo: o campo account_number contém um valor que não respeita o formato de número de conta registado pela sua instituição junto do FRC ou do CBK. Isto pode acontecer quando se combinam números de conta de sistemas diferentes (formato de número de conta do sistema bancário central, formato de conta do CBK, formato internacional IBAN), quando os zeros à esquerda são eliminados durante a exportação dos dados, ou quando os números de conta incluem códigos de balcão ou de produto que não fazem parte do número de conta propriamente dito. Correcção: confirme o formato exacto do número de conta que a sua instituição registou junto do FRC — normalmente é o mesmo formato utilizado no reporte regulamentar ao CBK. Aplique uma formatação coerente no seu processo de geração do XML: se os seus números de conta têm 13 dígitos com zeros à esquerda, assegure que a exportação preserva esses zeros (problema frequente no Excel). Se o seu sistema guardar os números de conta com códigos de balcão ou de produto incorporados, retire esses componentes antes de incluir o número de conta no XML da CTR/STR.

Como voltar a submeter depois de corrigir os erros

Processo de ressubmissão no portal do FRC

O processo de ressubmissão correcto depende de estar a corrigir uma submissão rejeitada ou a apresentar uma alteração a uma submissão aceite:

Submissões rejeitadas: aceda ao histórico de submissões no portal do FRC e localize a submissão rejeitada pelo respectivo número de referência. Utilize a opção Resubmit (e não New Report) e carregue o ficheiro XML corrigido. O portal associa o ficheiro corrigido ao registo da submissão original, preservando a cronologia da submissão para efeitos de cumprimento dos prazos. Não altere o valor de report_reference no XML corrigido — o FRC tem de conseguir fazer corresponder a comunicação corrigida à original.

Alterações a submissões aceites: se uma submissão aceite continha um erro que só descobriu depois da aceitação, contacte directamente o FRC (ver, mais abaixo, a secção sobre o recurso directo ao FRC) antes de tentar submeter uma alteração. O FRC indicará se é adequada uma alteração no portal, uma STR complementar ou uma correcção formal por escrito, consoante a natureza do erro.

Ressubmissão dentro do prazo — a submissão continua a ser atempada?

Nos termos da POCAMLA e dos respectivos regulamentos, as CTR (transacções em numerário de 15 000 USD ou mais) têm de ser submetidas até à sexta-feira da semana em que ocorreu a transacção que as desencadeou (artigo 44(6) da lei e artigo 40 dos regulamentos). As STR têm de ser submetidas no prazo de dois dias a contar da data em que surgiu a suspeita (artigo 44(2)). O FRC mede a pontualidade entre a data do facto desencadeador e a data da primeira submissão, e não a data de uma ressubmissão bem-sucedida.

Isto significa que, se a sua primeira tentativa de submissão foi feita dentro do prazo mas foi rejeitada, a sua instituição tentou, ainda assim, submeter atempadamente. A rejeição e a ressubmissão ficam documentadas no histórico de submissões do portal. Contudo, se a sua primeira tentativa de submissão ficar fora do prazo devido a atrasos internos — e não devido à rejeição e à ressubmissão —, não há qualquer protecção. Submeta a tempo, corrija os erros a tempo e volte a submeter o mais depressa possível.

Conserve um registo da data e hora (timestamp) da sua primeira tentativa de submissão. Numa inspecção regulamentar ou numa auditoria BC/FT, esse registo demonstra a intenção de submeter atempadamente, mesmo que a submissão inicial tenha sido rejeitada.

Documentar a rejeição e a correcção no trilho de auditoria de conformidade

Cada submissão rejeitada e a ressubmissão subsequente têm de ficar documentadas nos registos de conformidade da sua instituição. A documentação deve incluir:

O número de referência e a data de submissão da comunicação rejeitada
Os códigos de erro recebidos e as mensagens de erro
As correcções concretas feitas aos dados e a origem dos dados corrigidos
A data e o número de referência da ressubmissão bem-sucedida
O nome do responsável pela conformidade que fez as correcções e o nome do responsável que aprovou a ressubmissão

Esta documentação cumpre dois objectivos: demonstra aos reguladores que a sua instituição leva a sério a qualidade das submissões e responde às rejeições de forma sistemática, e fornece um rasto de provas essencial caso o FRC levante questões sobre uma comunicação específica meses ou anos mais tarde.

Prevenir as rejeições antes que aconteçam

Lista de verificação antes da submissão (10 verificações)

Percorra esta lista de verificação para cada CTR ou STR antes de a carregar no portal do FRC:

Verificação do formato das datas: todos os campos de data estão no formato YYYY-MM-DD, sem excepções.
Verificação do National ID: todos os registos de partes de nacionalidade queniana contêm um National ID numérico de 7–8 dígitos no campo id_number.
Verificação dos códigos de moeda: todos os valores de transaction_currency são códigos ISO 4217 exactos de três letras (KES, USD, EUR, etc.).
Verificação do tipo de transacção: todos os valores de transaction_type pertencem à enumeração permitida.
Unicidade da referência da comunicação: o report_reference não foi utilizado em nenhuma submissão anterior.
Verificação do identificador da entidade obrigada: o reporting_entity_id corresponde exactamente ao seu certificado de registo no FRC.
Verificação dos códigos de balcão: todos os valores de branch_code correspondem a balcões da sua instituição registados no CBK.
Completude da narrativa (STR): o campo reason contém uma narrativa substantiva que abrange os cinco elementos obrigatórios.
Verificação dos códigos de indicador (STR): todos os valores de indicator_codes constam da lista de referência actual de indicadores do FRC.
Validação do esquema XSD: passe o XML por um validador XSD local, face ao esquema XSD goAML v5.0.2, antes de o carregar.

Por que razão um motor de validação detecta os erros antes de chegarem ao FRC

Um motor de validação goAML concebido para o efeito aplica as duas camadas de validação — conformidade com o esquema XSD e conformidade com as regras de negócio do FRC do Quénia — ao seu ficheiro XML antes de este sair da sua instituição. O motor de validação conhece:

Cada campo obrigatório e o formato exigido
Cada valor enumerado do esquema
A regra de formato do National ID do FRC do Quénia
O registo de códigos de balcão do CBK
O número de registo da sua instituição no FRC
A lista de referência actual dos códigos de indicador do FRC
O padrão mínimo de conteúdo das narrativas de FT

Quando o motor encontra um erro, interrompe o fluxo de submissão e apresenta o erro com uma descrição em inglês simples e a correcção concreta a fazer nos dados. O analista de conformidade corrige os dados, volta a gerar o XML e o motor de validação volta a correr. Só um ficheiro que passe todas as validações é apresentado para submissão.

Esta abordagem transforma a validação: de actividade de diagnóstico posterior à rejeição, passa a ser um controlo de qualidade anterior à submissão. O resultado final: os erros são detectados e corrigidos dentro do seu próprio processo, antes de o ficheiro chegar ao portal.

De rejeições rotineiras a rejeições quase nulas com a validação automatizada

Passar da geração manual do XML para a validação automatizada muda o local onde os erros são detectados. As verificações que o portal do FRC faria à recepção correm primeiro dentro da sua instituição, pelo que um ficheiro com um erro de esquema ou de regra de negócio nunca chega ao portal. O ciclo de retrabalho reduz-se à correcção dos dados na origem, a pressão dos prazos associada às ressubmissões repetidas diminui e os analistas de conformidade deixam de dedicar o seu tempo à depuração de XML para se dedicarem ao verdadeiro trabalho de conformidade — rever casos, analisar padrões, preparar narrativas de qualidade.

Uma taxa de rejeição elevada não é uma característica inevitável das comunicações goAML. É o resultado previsível de um processo manual aplicado a uma norma altamente técnica. A validação automatizada faz do êxito à primeira tentativa a regra.

Quando recorrer directamente ao FRC

Se o portal não apresentar uma mensagem de erro clara

Se o portal do FRC responder à sua submissão com uma mensagem de erro genérica («não foi possível processar a submissão») sem gerar um ficheiro de erros estruturado, o seu XML pode estar tão mal formado que o portal não o consegue interpretar. Neste caso:

Valide o seu XML face ao esquema XSD goAML v5.0.2 com um validador local (xmllint, XML Notepad ou o validador em linha de freeformatter.com)
Verifique se o ficheiro XML está codificado em UTF-8, sem caracteres de marca de ordem de bytes (BOM)
Verifique se a extensão do ficheiro é .xml (e não .txt, .csv ou qualquer outro formato)
Confirme que o ficheiro foi gerado sem caracteres binários ou nulos introduzidos pelo processo de exportação

Se o ficheiro passar a validação local mas o portal continuar a apresentar um erro genérico, recorra ao serviço de apoio (helpdesk) do FRC.

Se o seu XML válido estiver a ser rejeitado (possível problema do portal do FRC)

Ocasionalmente, o portal do FRC sofre problemas técnicos que levam à rejeição indevida de submissões válidas. Entre os indícios de que isso pode estar a acontecer contam-se:

Várias instituições a relatarem o mesmo tipo de rejeição em simultâneo
O código de erro da rejeição é desconhecido e não está documentado nas orientações disponíveis do FRC
Uma submissão que passou todas as validações prévias e que já tinha sido submetida com êxito anteriormente (mesmo formato, mesma instituição) é rejeitada pela primeira vez

Se suspeitar de um problema do lado do portal, documente minuciosamente as provas da sua validação prévia antes de contactar o FRC. Poder demonstrar que o seu ficheiro passa a validação XSD reforça significativamente o seu pedido.

Contacto do serviço de apoio do FRC

Para problemas técnicos de submissão que não possam ser resolvidos através das ferramentas de autosserviço do portal, contacte directamente o Financial Reporting Centre do Quénia:

Sítio web: frc.go.ke (utilize os contactos aí publicados)
Portal goAML: goaml.frc.go.ke

Quando contactar o FRC sobre um problema com uma submissão específica, indique: o número de registo da sua instituição no FRC, o número de referência da submissão, os códigos de erro recebidos e uma descrição das medidas que já tomou para diagnosticar e resolver o problema. Este contexto permite ao serviço de apoio do FRC ajudá-lo mais rapidamente.

Acabe de vez com o ciclo de rejeições

Todas as submissões goAML rejeitadas são evitáveis. Os erros que provocam as rejeições — formatos de data errados, National ID em falta, valores enumerados inválidos, narrativas vazias, números de referência duplicados — não resultam de uma ambiguidade regulamentar complexa. Resultam de um processo manual de tratamento de dados e de geração de XML pouco adequado ao rigor que o esquema goAML exige.

A plataforma goAML da Creodata quebra o ciclo de rejeições ao automatizar as duas camadas de validação — conformidade com o esquema XSD e conformidade com as regras de negócio do FRC do Quénia — antes de qualquer ficheiro ser submetido ao portal do FRC. O motor de validação prévia da plataforma executa automaticamente todas as verificações desta página, sempre, para cada comunicação.

Quando passa de um processo de submissão manual para uma plataforma automatizada, as rejeições por erros de esquema e de regras de negócio deixam de ser um acontecimento rotineiro — porque a máquina verifica o esquema sempre, sem cansaço, sem saltar etapas e sem que a pressão dos prazos leve a atalhos.

Veja como a plataforma goAML da Creodata reduz as rejeições à primeira submissão para valores quase nulos.

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

Artigos relacionados: