Software de conformidade BC/FT para bancos, SACCO e fintechs do Quénia.
Detecte o risco. Fundamente a decisão.
Filtragem de sanções e de pessoas politicamente expostas (PPE), monitorização de transacções, classificação de risco do cliente, gestão de casos e comunicações de operações suspeitas (STR) e de transacções em numerário (CTR) ao Financial Reporting Centre, num único espaço de trabalho de analista. Uma única base de código serve tanto um banco de primeira linha (tier 1) como um pequeno intermediário — na cloud ou nas instalações do cliente (on-premises), com paridade de funcionalidades.
Menos um problema de BC/FT do que um problema de fragmentação.
A pontuação de risco está numa folha de cálculo, a filtragem de sanções numa ferramenta separada, os alertas de transacções num terceiro sistema — e as provas que um inspector pede estão dispersas por caixas de correio e unidades partilhadas. Ferramentas pontuais e processos manuais criam mais risco do que aquele que eliminam.
O custo não é apenas operacional. Um programa de prevenção e combate ao branqueamento de capitais e financiamento do terrorismo (BC/FT) que não consegue apresentar as suas provas quando lhe são pedidas é difícil de defender, por mais diligente que a equipa realmente seja.
- As decisões não podem ser reconstituídas
Quando um regulador ou um auditor pergunta porque é que um cliente foi classificado como de baixo risco, ou porque é que um alerta foi encerrado, a resposta está na memória de alguém ou num e-mail apagado, e não num registo imutável.
- O trabalho é duplicado e incoerente
O mesmo cliente é filtrado num sistema, pontuado noutro e investigado num terceiro, sem uma visão partilhada de como essas decisões se relacionam.
- As folhas de cálculo não acompanham o crescimento nem resistem ao escrutínio
Os modelos de pontuação manuais e as listas de vigilância improvisadas ficam desactualizados, não têm histórico de versões e não oferecem qualquer controlo segundo o princípio dos quatro olhos sobre as derrogações que mais importam.
O que muda quando o programa assenta num único registo.
Filtragem, classificação de risco, monitorização, casos e comunicações partilham o mesmo contexto de entidade — pelo que as provas estão lá quando a pergunta surge.
Os dados, a regra, a pontuação e o raciocínio estão à distância de um clique, num registo de auditoria só de acréscimo (append-only).
A correspondência multi-alfabeto e adaptada às definições regionais, um fluxo estruturado de tratamento de falsos positivos e a resolução de entidades retiram os quase-homónimos da fila.
O caso, a diligência reforçada e o ciclo de vida SAR/STR estão no mesmo espaço de trabalho, que entrega ao goAML a submissão propriamente dita.
Os módulos são licenciados por nível e activados por inquilino — primeiro a filtragem e a classificação de risco, a monitorização e a IA quando estiver preparado.
Concebido para a POCAMLA e para o Financial Reporting Centre.
A Proceeds of Crime and Anti-Money Laundering Act (POCAMLA) do Quénia, os seus regulamentos e as orientações do FRC definem o que uma instituição obrigada tem de fazer. Cada dever abaixo corresponde a um módulo, pelo que as provas estão onde um inspector as irá procurar.
Identificar os clientes e os seus beneficiários efectivos, e classificar o seu risco
Classificação de risco do cliente com seis factores (país, sector de actividade, produto, canal, comportamento e exposição a PPE/sanções) e derrogações sujeitas ao princípio dos quatro olhos, e um grafo de beneficiários efectivos para os clientes que são pessoas colectivas.
Aplicar diligência reforçada às PPE estrangeiras e aos clientes de risco mais elevado
Um fluxo de diligência reforçada dentro da gestão de casos, com revisões periódicas agendadas automaticamente por escalão de risco, para que um processo de alto risco não fique desactualizado.
Filtrar com base nas listas de sanções da ONU e do Quénia, que exigem o congelamento no prazo de 24 horas após uma designação
Correspondência multi-alfabeto e adaptada às definições regionais com listas sincronizadas a partir de fornecedores como Dow Jones e World-Check, e carregamento manual das listas que a própria instituição mantém, como a Domestic List do Quénia. Cada lista tem controlo de versões, e os painéis de actualidade dos dados mostram que a filtragem foi feita com dados actuais.
Monitorizar de forma contínua as transacções complexas, invulgares e de montante elevado
Um motor de regras que funciona em lote e em fluxo contínuo, com regras iniciais alinhadas com tipologias, um ambiente de testes retrospectivos e promoção com controlo de versões, alimentado por conectores REST, SFTP, Kafka, CDC ou ISO 20022.
Comunicar as STR no prazo de dois dias e as transacções em numerário de 15 000 USD ou mais até à sexta-feira dessa semana
Um ciclo de vida de rascunho, revisão, aprovação e submissão, com tratamento dos avisos de recepção. O XML goAML é gerado e validado pela plataforma de comunicações goAML da Creodata, com descarregamento manual se o portal estiver indisponível.
Conservar os registos durante pelo menos sete anos e mostrar as provas às autoridades de supervisão
Um registo de auditoria só de acréscimo por detrás de cada decisão, pacotes de provas para as inspecções, um portal do regulador só de leitura e um registo de obrigações que transforma as novas circulares e alterações do FRC em tarefas acompanhadas.
Fontes: POCAMLA, artigos 44, 46 e 47A; POCAML Regulations, 2023 (artigos 26 e 40); e o regulamento de sanções de 2026 (Prevention of Terrorism). Este quadro relaciona as capacidades do software com as obrigações quenianas; não constitui aconselhamento jurídico. Para o registo e a submissão através do goAML, consulte o guia goAML para o Quénia; para apoio na concepção do próprio programa, consulte os nossos serviços de consultoria BC/FT.
Cada ecrã, o mesmo contexto de entidade.
Da primeira filtragem de um cliente à comunicação submetida, cada acção decorre no mesmo espaço de trabalho — sem saltar entre ferramentas. Percorra os ecrãs reais que um analista e o responsável pela comunicação de operações suspeitas (MLRO) utilizam todos os dias.
| Match | Query | Confidence | Top reason |
|---|---|---|---|
| a91f3c… | Fatima Al-Mansouri | 0.924 | PEP list exposure |
| c20b7e… | João da Silva | 0.871 | Sanctions partial |
| e4d109… | Apex Holdings Ltd | 0.642 | Adverse media |
| 7b8a52… | Chen Xiaoming | 0.588 | Name-only match |
| 1f60aa… | Wei Logistics | 0.512 | High-risk geography |
Onze módulos, activados consoante o nível de licença.
Active apenas aquilo para que um inquilino tem licença — o resto permanece oculto.Sincronização com fornecedores (Dow Jones, World-Check), carregamento manual, controlo de versões e painéis de actualidade dos dados — para que a filtragem seja sempre feita com listas actuais, e o possa comprovar.
Correspondência multi-alfabeto e adaptada às definições regionais em sanções, PPE e notícias negativas, com um fluxo de tratamento de falsos positivos — para que os analistas dediquem o seu tempo às correspondências genuínas, e não aos quase-homónimos.
Avaliação do risco do cliente (CRA) com seis factores (país, sector de actividade, produto, canal, comportamento e exposição a PPE/sanções) e derrogações sujeitas ao princípio dos quatro olhos — para que cada classificação tenha um histórico verificável.
Linguagem de regras (DSL) em lote e em fluxo contínuo, ambiente de testes retrospectivos, laboratório de afinação e promoção com controlo de versões — para que uma alteração de regra seja testada e rastreável antes de disparar em produção.
Filas de trabalho, ciclo de pedidos de informação (RFI), pausa e retoma de SLA, grafo de casos ligados e diligência reforçada — para que nenhum alerta ultrapasse o prazo sem responsável, e os casos relacionados sejam vistos em conjunto.
Ciclo de vida do rascunho à submissão, com os modos «FRC Kenya direct» e «goAML universal» e o descarregamento manual como recurso — para que uma comunicação possa ser enviada mesmo quando um portal está indisponível.
Entidades resolvidas, ligações, agrupamentos e um grafo de beneficiários efectivos integrados na área de trabalho do caso — para que um analista veja quem está realmente por detrás de um cliente sem sair do caso.
Conectores REST, SFTP, Kafka, CDC e ISO 20022 com idempotência, reprocessamento (replay) e uma fila de mensagens não entregues (dead-letter queue) — para que um fluxo nocturno falhado nunca se torne uma lacuna silenciosa na monitorização.
Ambiente de execução ONNX e registo de modelos próprio, activação segundo o princípio dos quatro olhos, um interruptor de emergência e as 3 principais razões SHAP — para que cada pontuação de IA possa ser explicada a um inspector, e desactivada com um clique.
Uma versão só de leitura, federada via OIDC, para as autoridades de supervisão, com pacotes de provas e avisos de recepção — para que uma inspecção decorra sobre provas partilhadas e não sobre anexos de e-mail.
Registo de obrigações, integração de avisos de alteração e acompanhamento, por inquilino, das tomadas de conhecimento — para que uma nova circular se torne uma tarefa acompanhada, e não uma surpresa na próxima inspecção.
Cada pontuação de IA vem acompanhada das suas razões — e quem decide é uma pessoa.
Os modelos são executados no próprio processo, num ambiente de execução ONNX com um registo de modelos próprio. A activação exige o princípio dos quatro olhos, um interruptor de emergência está à distância de um clique e cada inferência fica registada com a versão do modelo e um hash dos dados de entrada.
Construído uma vez. Implementado em qualquer lugar, para qualquer sector.
O mesmo binário serve um banco global com um regulador, nas instalações do cliente, e um pequeno intermediário, na cloud. A diferença está na configuração e na licença — não no código.
Abstracções de duplo backend fazem com que cada funcionalidade funcione de forma idêntica no Azure e no seu próprio Kubernetes — o mesmo código, com paridade validada.
Os módulos são activados por nível. Os endpoints verificam a licença; tudo o que não está licenciado fica oculto.
Para todas as instituições quenianas que têm de manter um programa BC/FT e responder por ele.
Concebido para as instituições obrigadas ao abrigo da POCAMLA, que respondem perante o Financial Reporting Centre e perante o seu regulador sectorial, e para as suas congéneres sujeitas à FIA no Uganda, à FIU na Tanzânia e ao FIC na Zâmbia e no Ruanda.
Instituições que captam depósitos, supervisionadas pelo Central Bank of Kenya e pela SASRA, sujeitas à totalidade das obrigações de filtragem, monitorização e comunicação.
Empresas de pagamentos e de crédito licenciadas pelo CBK, com fluxos de grande volume e em tempo real, que precisam de monitorização em fluxo contínuo e de uma filtragem rápida e multi-alfabeto.
Empresas supervisionadas pela IRA, pelo CBK e pela CMA. As equipas mais pequenas começam pela filtragem, pela classificação de risco e pelo essencial da gestão de casos, e activam mais módulos depois.
Casinos, agentes imobiliários, comerciantes de metais preciosos e pedras preciosas, advogados e contabilistas, trazidos para o regime BC/FT pela POCAMLA e pelas suas alterações.
Software de conformidade BC/FT em toda a África Oriental.
O mesmo software serve instituições obrigadas em mais quatro mercados. O regulador e o perfil de comunicação mudam; o código não.
Perguntas frequentes.
Este software BC/FT foi concebido para o Quénia?
Sim. Foi concebido para as instituições obrigadas ao abrigo da Proceeds of Crime and Anti-Money Laundering Act (POCAMLA) do Quénia: filtragem de sanções e de PPE, classificação de risco do cliente, monitorização de transacções, gestão de casos com diligência reforçada e comunicações STR/CTR ao Financial Reporting Centre (FRC) através do goAML. O mesmo software serve instituições no Uganda, na Tanzânia, na Zâmbia e no Ruanda; a diferença entre países está na configuração, não no código.
O software submete as STR e as CTR ao FRC?
Sim, através do goAML. As comunicações de operações suspeitas e de transacções em numerário seguem, no software BC/FT, um ciclo de vida de rascunho, revisão, aprovação e submissão, com tratamento de novas tentativas, reconciliação e avisos de recepção. O próprio XML goAML é gerado e validado pela plataforma de comunicações goAML da Creodata antes de chegar ao portal do FRC, e é possível recorrer a um descarregamento manual se o portal estiver indisponível.
Quanto custa um software BC/FT no Quénia?
Não existe uma tabela de preços pública. Cada funcionalidade é licenciada separadamente e agrupada nos níveis Starter, Growth e Enterprise, pelo que um orçamento depende dos módulos que activar e de a implementação ser feita no Azure ou nas instalações do cliente. Uma demonstração é o caminho mais rápido para obter um orçamento adequado à sua instituição.
Uma SACCO ou uma instituição de microfinanças pode começar em pequena escala?
Sim. O nível Starter abrange a filtragem, a classificação de risco do cliente e o essencial da gestão de casos, na cloud. O nível Growth acrescenta a monitorização de transacções, as comunicações STR/CTR e os conectores de ingestão, de que uma SACCO ou uma instituição de microfinanças que capte depósitos precisará para cumprir os deveres de monitorização e comunicação da POCAMLA. Os módulos são activados por inquilino, pelo que subir de nível acrescenta capacidades sem recomeçar do zero.
Onde ficam alojados os nossos dados, e podemos executar o software nas nossas instalações?
A edição cloud funciona no Microsoft Azure como Azure Managed Application. Se os dados tiverem de permanecer no seu próprio centro de dados, a edição on-premises funciona em Kubernetes com Postgres 16, RabbitMQ, MinIO, OpenSearch e Keycloak e tem as mesmas funcionalidades: abstracções de duplo backend mantêm as duas edições idênticas, pelo que uma instituição que tenha de manter os dados no país não fica com um produto inferior.
Quanto tempo demora a implementação?
Depende do número de módulos com que começar e da forma como os seus dados chegam. A filtragem e a classificação de risco precisam dos dados de clientes; a monitorização de transacções precisa também de fluxos de transacções, que se ligam por REST, SFTP, Kafka, captura de alterações de dados (CDC) ou ISO 20022, com reprocessamento (replay) e uma fila de mensagens não entregues (dead-letter queue), pelo que um carregamento falhado fica visível em vez de passar despercebido. Após a definição do âmbito, propomos um percurso faseado até à sua primeira entrada em produção.
Trata-se de um programa BC/FT completo ou apenas de uma ferramenta de comunicação?
É o programa completo — avaliação do risco do cliente, filtragem, monitorização de transacções, gestão de casos, resolução de entidades e mais. As comunicações STR/CTR são uma das funcionalidades, e a submissão goAML propriamente dita é entregue à plataforma de comunicações goAML da Creodata, dedicada a esse fim.
Temos de adoptar todas as funcionalidades de uma só vez?
Não. Cada funcionalidade é um serviço independente, licenciado separadamente. A activação de módulos por inquilino permite começar pelo que precisa e activar outros serviços ao longo do tempo.
Como é que a plataforma trata as decisões de IA para efeitos de auditoria?
Cada elemento de IA mostra a etiqueta do modelo e da versão, as três principais explicações SHAP e uma percentagem de confiança, e exige uma decisão humana: aceitar, modificar ou rejeitar. As decisões são registadas com a versão do modelo, um hash dos dados de entrada e o resultado SHAP, e os modelos só podem ser activados com aprovação segundo o princípio dos quatro olhos, com um interruptor de emergência e reversão disponíveis.
Do alerta à SAR/STR submetida, sem sair do espaço de trabalho.
Veja a plataforma BC/FT a funcionar com uma fila de alertas realista, ajustada ao seu pacote sectorial, numa demonstração ao vivo.