Plataforma BC/FT nas instalações do cliente ou na cloud: qual é a opção certa para os bancos africanos?

Para uma instituição financeira europeia que avalia tecnologia de prevenção e combate ao branqueamento de capitais e financiamento do terrorismo (BC/FT), a escolha entre a cloud e as instalações próprias (on-premises) é, em grande medida, uma questão de economia e de estratégia de TI. Os fornecedores de cloud oferecem quadros sólidos de protecção de dados, estruturas contratuais conformes ao RGPD (Regulamento Geral sobre a Protecção de Dados, GDPR na sigla inglesa) e centros de dados no próprio país na maioria das principais jurisdições da UE. O enquadramento regulamentar é, em geral, permissivo quanto à implementação na cloud de cargas de trabalho não sensíveis, com orientações claras sobre o que constitui uma utilização aceitável da cloud para dados financeiros.

Para um banco da África Oriental, a mesma decisão é consideravelmente mais complexa. Os requisitos regulamentares de residência dos dados estão em evolução e são, por vezes, ambíguos. A infra-estrutura de cloud na região imediata é limitada em comparação com a Europa ou a América do Norte. A fiabilidade da ligação à internet varia significativamente entre os centros urbanos e as redes de balcões rurais. E os inspectores de TI do banco central têm mostrado, historicamente, preferência por soluções que possam inspeccionar fisicamente.

Este guia ajuda os quadros superiores de conformidade e de TI das instituições financeiras da África Oriental a tomar a decisão de implementação com todo o contexto regulamentar, técnico e económico.

---

O contexto regulamentar da residência dos dados na África Oriental

Requisitos de residência dos dados do CBK

As Prudential Guidelines on Outsourcing and Cloud Computing do Central Bank of Kenya (CBK) exigem que as instituições licenciadas assegurem que os dados dos clientes e os registos de transacções permaneçam sujeitos à jurisdição legal queniana. Os requisitos concretos não proíbem de forma generalizada o armazenamento de dados financeiros na cloud — exigem que os fornecedores de cloud aceitem disposições contratuais que permitam o acesso do CBK para efeitos de inspecção, que os dados estejam acessíveis a partir do Quénia em qualquer momento e que o banco mantenha um controlo efectivo sobre os seus dados, independentemente do local onde estejam armazenados.

Na prática, os inspectores do CBK têm demonstrado graus variáveis de à-vontade com os sistemas financeiros baseados na cloud. Espera-se que os sistemas bancários centrais (core banking) funcionem em infra-estrutura dedicada, com capacidades comprovadas de resiliência e de recuperação. As cargas de trabalho de conformidade e de análise de dados — incluindo as plataformas de comunicações BC/FT — estão sujeitas a orientações menos prescritivas, mas espera-se que as instituições disponham de avaliações de risco documentadas que fundamentem a sua opção de implementação.

As disposições da Banking Act do Quénia relativas aos registos electrónicos e os requisitos de conservação de registos da Proceeds of Crime and Anti-Money Laundering Act exigem, ambos, que os registos BC/FT sejam mantidos num formato recuperável durante os períodos prescritos. O armazenamento na cloud satisfaz estes requisitos, desde que os mecanismos contratuais e técnicos garantam a disponibilidade e a integridade dos dados.

Preferência do FRC por soluções nas instalações do cliente ou numa cloud no país

O Financial Reporting Centre (FRC) do Quénia manifestou, nas suas comunicações de supervisão, preferência pelo armazenamento dos dados de conformidade BC/FT em infra-estrutura sujeita a um controlo jurisdicional queniano claro. Esta preferência não constitui uma proibição legal do armazenamento na cloud, mas é um factor que as instituições atentas à conformidade ponderam seriamente quando se preparam para as inspecções do FRC.

A preocupação prática do FRC é o acesso: em caso de investigação ou de pedido de dados, consegue o FRC obter os registos de conformidade da instituição rapidamente e sem depender da cooperação de uma entidade estrangeira? Uma implementação nas instalações do cliente, ou num centro de dados de cloud domiciliado no Quénia, responde directamente a esta preocupação. Uma implementação numa região de cloud europeia ou dos EUA, com replicação dos dados para o Quénia, também lhe responde, mas exige uma documentação contratual mais cuidada.

FIU da Tanzânia, FIA do Uganda, FIC da Zâmbia — requisitos de localização dos dados

Em toda a região, o panorama da residência dos dados é variado:

No Uganda, a Financial Intelligence Authority (FIA) e as orientações de TI do Bank of Uganda exigem que os dados financeiros sejam armazenados no Uganda, sempre que tal seja viável. O ecossistema de infra-estrutura de cloud do Uganda é menos maduro do que o do Quénia, o que faz da implementação nas instalações do cliente a via mais frequentemente escolhida pelas instituições ugandesas.

Na Tanzânia, as orientações da Financial Intelligence Unit (FIU) e do Bank of Tanzania seguem um padrão semelhante ao do Uganda, com uma expectativa geral de que os dados permaneçam sob a jurisdição da Tanzânia. A Tanzânia é um membro activo do ESAAMLG (Grupo Anti-Branqueamento de Capitais da África Oriental e Austral), com um escrutínio crescente da eficácia dos sistemas BC/FT das instituições financeiras.

Na Zâmbia, o FIC rege-se pela Financial Intelligence Centre Act e pelos respectivos regulamentos, que exigem que os registos BC/FT estejam disponíveis para inspecção sem demora injustificada. A Zambia Information and Communications Technology Authority emitiu orientações sobre a utilização da cloud que exigem a classificação dos dados e a notificação do governo nas implementações que envolvam dados pessoais de cidadãos zambianos.

No Ruanda, o National Bank of Rwanda (BNR) e o Financial Intelligence Centre (FIC) têm sido mais progressistas na sua abordagem à cloud e à adopção de tecnologia, reflectindo a estratégia tecnológica nacional mais ampla do país. O quadro do BNR permite a utilização regulada da cloud nos serviços financeiros, mediante avaliações de risco documentadas.

Em que diferem estes requisitos do RGPD europeu

As instituições europeias sujeitas ao RGPD dispõem de um quadro regulamentar maduro e pormenorizado para o tratamento de dados na cloud — incluindo cláusulas contratuais-tipo, decisões de adequação para jurisdições específicas e orientações de supervisão pormenorizadas das autoridades nacionais de protecção de dados. O RGPD gera complexidade de conformidade, mas também gera clareza.

Os quadros regulamentares da África Oriental em matéria de dados e de cloud encontram-se numa fase mais inicial do seu desenvolvimento. As orientações são menos pormenorizadas, a prática de supervisão é menos coerente e o enquadramento regulamentar evolui rapidamente. Esta ambiguidade é uma faca de dois gumes: significa que as implementações na cloud não estão claramente proibidas, mas também que não estão claramente aprovadas. As instituições que optam pela cloud têm de estar preparadas para defender a sua avaliação de risco perante inspectores que podem ter uma familiaridade limitada com a arquitectura de cloud.

---

Implementação nas instalações do cliente — os argumentos a favor

Soberania total dos dados

Uma implementação nas instalações do cliente — servidores, armazenamento e rede fisicamente localizados no centro de dados da própria instituição ou numa instalação de co-localização — oferece o nível de soberania dos dados mais elevado disponível. Os dados das transacções, as narrativas das comunicações de operação suspeita (STR), os processos dos casos e os registos de auditoria nunca saem da infra-estrutura física da instituição. Não há qualquer dependência dos compromissos contratuais, das políticas de privacidade ou da resposta de uma entidade estrangeira a processos judiciais movidos por governos estrangeiros.

Para os responsáveis seniores pela conformidade e para as comissões de auditoria preocupados especificamente com a confidencialidade dos dados das STR — que descrevem suspeitas de branqueamento de capitais por pessoas e entidades identificadas pelo nome — o armazenamento nas instalações do cliente oferece a protecção mais forte possível contra divulgações inadvertidas.

Preferência regulamentar do CBK/FRC e conforto nas inspecções

Quando os inspectores do CBK ou os supervisores do FRC visitam uma instituição para uma inspecção BC/FT, uma plataforma BC/FT alojada nas instalações da instituição permite à equipa de conformidade demonstrar directamente o sistema, mostrar aos inspectores a infra-estrutura física e dar acesso imediato a todos os registos, sem qualquer dependência da ligação à internet ou de sistemas de terceiros. Este nível de transparência reforça a confiança dos inspectores e traduz-se, normalmente, em inspecções mais tranquilas.

As instituições a quem foram apontadas deficiências tecnológicas em inspecções BC/FT anteriores optam muitas vezes pela implementação nas instalações do cliente nos projectos seguintes, precisamente porque esta retira da equação qualquer risco regulamentar associado à cloud.

Sem dependência da internet para os fluxos de conformidade essenciais

As plataformas de comunicações BC/FT acedem ao portal da unidade de informação financeira (UIF) através da internet para efectuar as submissões — mas o fluxo de trabalho diário de conformidade (criação de casos, investigação, documentação, aprovação) não exige acesso à internet. Numa plataforma alojada nas instalações do cliente, os responsáveis pela conformidade podem trabalhar nos casos mesmo durante as falhas de internet, ficando as submissões em fila para serem transmitidas quando a ligação for restabelecida.

Esta resiliência é importante na África Oriental, onde a ligação à internet — sobretudo nas cidades mais pequenas e nas redes de balcões rurais — pode ser menos fiável do que nos grandes centros metropolitanos. Uma plataforma BC/FT cujo funcionamento depende inteiramente da ligação à cloud cria uma vulnerabilidade de conformidade sempre que essa ligação é interrompida.

Comparação entre CapEx único e OpEx recorrente

O perfil financeiro da implementação nas instalações do cliente difere fundamentalmente dos modelos de subscrição de cloud. A opção on-premises implica uma despesa de capital (CapEx) inicial significativa em servidores, equipamento de rede, armazenamento e infra-estrutura de centro de dados — tipicamente entre 50 000 e 150 000 USD para uma instituição de média dimensão, consoante a capacidade de centro de dados já existente. Os custos recorrentes limitam-se à manutenção, à energia, às licenças de software e ao tempo do pessoal.

Para as instituições com uma infra-estrutura de centro de dados já existente, capaz de alojar cargas de trabalho adicionais, o custo marginal da implementação nas instalações do cliente pode ser substancialmente inferior ao de uma subscrição de cloud num horizonte de 5 anos. Os directores financeiros e os administradores oriundos da banca preferem muitas vezes a previsibilidade de um activo capitalizado a uma obrigação de subscrição por tempo indeterminado.

---

Implementação nas instalações do cliente — os desafios

Custo da infra-estrutura

Nem todas as instituições dispõem de um centro de dados capaz de alojar uma plataforma BC/FT em contentores. As instituições sem infra-estrutura de servidores dedicada suportam a totalidade do custo de capital da aquisição: servidores físicos com CPU e RAM suficientes para cargas de trabalho Kubernetes, armazenamento empresarial com cópias de segurança, infra-estrutura de rede, UPS e gerador de reserva, segurança física e controlos ambientais. No Quénia, um projecto de aquisição de servidores para uma instituição de média dimensão demora tipicamente 8 a 16 semanas, desde a nota de encomenda até à conclusão da montagem em bastidor (rack-and-stack).

Requisitos da equipa de TI

Operar uma plataforma de microsserviços em contentores sobre Kubernetes exige competências de DevOps que nem todas as equipas de TI dos bancos da África Oriental possuem. A gestão de contentores, a administração de clusters Kubernetes, a configuração de políticas de rede, a gestão de segredos e os procedimentos de implementação progressiva (rolling deployment) são competências especializadas. Uma instituição sem capacidade de DevOps tem de contratar ou formar pessoal antes de conseguir manter eficazmente uma implementação nas instalações do cliente.

Não se trata de um obstáculo intransponível, mas é uma verdadeira limitação de capacidade que tem de ser tratada no plano de implementação. As plataformas concebidas especificamente para implementação bancária nas instalações do cliente incluem normalmente apoio à implementação, formação e, opcionalmente, serviços geridos contínuos para colmatar a lacuna de competências.

Gestão das actualizações de software

As implementações nas instalações do cliente obrigam a instituição a gerir as actualizações de software — obter as imagens de contentor actualizadas, testá-las em pré-produção (staging) e implementá-las em produção. É uma tarefa operacional de rotina nas organizações com práticas DevOps maduras, mas aumenta a carga de trabalho da equipa de TI e exige um processo formal de gestão de alterações. Quando é corrigida uma vulnerabilidade de segurança ou é publicada uma actualização do esquema regulamentar, a actualização tem de ser aplicada prontamente, o que exige tanto capacidade técnica como capacidade de resposta da organização.

Complexidade da recuperação de desastres

Conceber e testar uma configuração de recuperação de desastres (DR) para uma plataforma BC/FT nas instalações do cliente exige uma arquitectura bem pensada. A instituição tem de manter um local de infra-estrutura secundário (um local de DR próprio ou uma instalação de co-localização), replicar os dados do local principal para o secundário quase em tempo real e testar periodicamente os procedimentos de comutação por falha (failover). Esta infra-estrutura de DR duplica aproximadamente o custo da infra-estrutura e exige uma disciplina contínua de testes de DR para garantir que funciona de facto quando é necessária.

---

Implementação em cloud privada no Azure

Infra-estrutura Azure para a África Oriental

O Microsoft Azure opera a região South Africa North, situada em Joanesburgo, como principal centro de dados Azure ao serviço da África Oriental. É a região Azure mais próxima de Nairobi com o catálogo completo de serviços e oferece residência dos dados na África do Sul — o que fica dentro da jurisdição africana, mas não dentro das fronteiras de países concretos da África Oriental.

Não existe nenhuma região Azure no Quénia, e nenhuma está listada como disponível ou para breve. A Microsoft e a G42 anunciaram em Maio de 2024 uma região de cloud da África Oriental (East Africa Cloud Region) para o Quénia, mas não foi publicada qualquer data de lançamento, e notícias de imprensa de Maio de 2026 descreveram o projecto como parado por questões de capacidade energética e de compromissos de compra — o ministério das TIC do Quénia classificou-o como um atraso e não como um cancelamento. Para as instituições que precisam hoje de manter os dados dentro do Quénia, é a implementação nas instalações do cliente que o garante; a região South Africa North, com as protecções contratuais adequadas, é a alternativa baseada no Azure mais prática.

Os centros de dados Azure têm certificação ISO 27001 e auditoria SOC 2 Type II, e a Microsoft publica os relatórios de auditoria que um banco pode apresentar aos inspectores do CBK que avaliem uma implementação na cloud. A documentação de conformidade da Microsoft para a banca e os serviços financeiros (Banking & Financial Services) fornece a base de provas para demonstrar a conformidade regulamentar.

Serviços geridos que reduzem o esforço de TI

A principal vantagem operacional da implementação na cloud face à implementação nas instalações do cliente é a eliminação da gestão da infra-estrutura. O Azure Kubernetes Service (AKS) gere automaticamente o plano de controlo do Kubernetes — aprovisionamento de nós, correcções de segurança, distribuição por zonas de disponibilidade e dimensionamento. O Azure Database for PostgreSQL Flexible Server gere a disponibilidade, as cópias de segurança e as correcções da base de dados. O Azure Service Bus fornece filas de mensagens geridas, garantidas pelo SLA de disponibilidade de 99,9% da Microsoft.

Para as equipas de TI bancárias já sobrecarregadas com múltiplas prioridades tecnológicas, transferir a gestão da infra-estrutura para os serviços geridos do Azure pode ser mais do que suficiente para justificar o custo recorrente da subscrição.

Rapidez de implementação

A implementação de uma plataforma BC/FT na cloud é substancialmente mais rápida do que a implementação nas instalações do cliente. Sem os prazos de aquisição e de montagem em bastidor, a infra-estrutura pode ser aprovisionada através de código em horas, e não em semanas. Um calendário típico de implementação na cloud, do arranque do projecto à primeira comunicação em produção, é de 6 a 8 semanas, contra 8 a 12 semanas nas instalações do cliente (incluindo a aquisição da infra-estrutura).

Para as instituições sujeitas a pressão regulamentar para automatizar rapidamente os processos BC/FT, a vantagem de rapidez da implementação na cloud é um factor relevante.

---

Implementação híbrida — o melhor dos dois mundos

Caso de utilização: dados de conformidade nas instalações do cliente, cópias de segurança na cloud

Um modelo de implementação híbrido armazena os dados de conformidade principais — casos activos, registos de transacções, processos dos casos de STR/CTR (comunicações de operação suspeita e de transacções em numerário), registos de auditoria — em infra-estrutura nas instalações do cliente, utilizando o armazenamento na cloud para a replicação das cópias de segurança. Isto satisfaz a preferência do CBK/FRC pela soberania dos dados principais, tirando ao mesmo tempo partido da economia e da resiliência da cloud para a recuperação de desastres.

Os serviços principais da plataforma BC/FT funcionam nas instalações do cliente. As cópias de segurança nocturnas da base de dados PostgreSQL são encriptadas e replicadas para o Azure Blob Storage (South Africa North, ou outra região à sua escolha). Num cenário de recuperação de desastres, a plataforma pode ser recuperada na cloud a partir da cópia de segurança mais recente, aceitando um objectivo de ponto de recuperação de um dia e um objectivo de tempo de recuperação medido em horas.

Percurso de migração faseado para os bancos em transição a partir de sistemas legados

Para os bancos que migram de sistemas BC/FT legados para plataformas modernas, uma implementação híbrida permite uma transição faseada. A nova plataforma é implementada na cloud para as novas submissões e para os casos do período em curso, enquanto o sistema legado continua a responder às consultas de dados históricos. Com o tempo, os dados históricos são migrados para a nova plataforma e o sistema legado é desactivado. Evita-se assim uma migração de corte único («big bang»), com o risco que lhe está associado.

---

Quadro de decisão — qual é a opção certa para a sua instituição?

---

Considerações de implementação para cada modelo

Dimensionamento do hardware nas instalações do cliente

Os requisitos de hardware dependem sobretudo do volume de transacções, do número de utilizadores de conformidade em simultâneo e da frequência e da escala do processamento em lote das comunicações de transacções em numerário (CTR). Como orientação geral para os bancos da África Oriental:

Instituição de pequena dimensão (menos de 100 000 contas, um único país): 2 servidores de aplicações (8 núcleos de CPU e 32 GB de RAM cada), 1 servidor de base de dados (16 núcleos de CPU, 64 GB de RAM, 2 TB de SSD), 1 TB de armazenamento SAN para cópias de segurança.

Instituição de média dimensão (de 100 000 a 500 000 contas, 1–2 países): 3 servidores de aplicações (16 núcleos de CPU e 64 GB de RAM cada), 2 servidores de base de dados em configuração de alta disponibilidade (32 núcleos de CPU, 128 GB de RAM, 5 TB de SSD), 5 TB de armazenamento SAN com replicação para fora das instalações.

Instituição de grande dimensão (500 000 contas ou mais, vários países): recomenda-se uma avaliação profissional do dimensionamento, com base nos volumes de transacções e nos requisitos de processamento em lote concretos.

Cloud: requisitos da subscrição Azure e conectividade com as UIF

As implementações no Azure exigem uma subscrição Azure com quotas de recursos adequadas, uma configuração de peering de redes virtuais para conectividade privada e regras de grupos de segurança de rede que permitam o tráfego HTTPS de saída para os endpoints do portal da UIF relevante em cada país. Todo o acesso de entrada aos serviços de conformidade é autenticado através de chaves de API e de JWT — nenhum serviço de conformidade está acessível publicamente sem autenticação.

Os portais das UIF do Quénia, do Uganda, da Tanzânia, da Zâmbia e do Ruanda são todos acedidos através da internet pública, por HTTPS. As implementações no Azure ligam-se a estes portais através de um gateway NAT com um IP de saída estático, que pode ser incluído na lista de endereços autorizados da UIF, se necessário.

Ambos os modelos: configuração do Kubernetes, calendários de cópias de segurança e janelas de manutenção

Independentemente do modelo de implementação, a plataforma BC/FT exige:

• Um cluster Kubernetes (nas instalações do cliente: RKE2 ou K3s em servidores físicos; na cloud: AKS) com pelo menos 3 nós, para alta disponibilidade
• Uma base de dados PostgreSQL 15 com cópias de segurança automáticas configuradas para serem executadas pelo menos todas as noites, com retenção das cópias de segurança de pelo menos 90 dias para recuperação (as cópias de segurança não são o arquivo dos registos BC/FT: no Quénia, esses registos devem ser conservados durante pelo menos sete anos)
• Um registo de imagens de contentor (nas instalações do cliente: Harbor ou Docker Registry; na cloud: Azure Container Registry) para armazenar e versionar as imagens dos serviços
• Janelas de manutenção definidas para as actualizações da plataforma, agendadas fora das horas de ponta e comunicadas antecipadamente aos responsáveis da equipa de conformidade

---

Dê o próximo passo

A plataforma de comunicações goAML da Creodata foi concebida para ser implementada sem complicações nas instalações do cliente, no Azure ou numa configuração híbrida — com as mesmas funcionalidades e capacidades de conformidade, qualquer que seja o modelo de implementação. A nossa equipa de implementação já levou a cabo implementações nos três modelos em ambientes bancários da África Oriental e pode aconselhar sobre a opção mais adequada ao perfil regulamentar, à capacidade de TI e aos prazos da sua instituição.

Discuta os seus requisitos de implementação com a nossa equipa: Pedir uma demonstração em creodata.com/demo