Fraude na Alteração de Dados Bancários: Controlo de 3 Mãos

# Alteração de Dados Bancários de um Fornecedor: O Controlo de Três Mãos que Evita o Pagamento Errado

TL;DR: Um pedido de mudança de conta bancária de um fornecedor nunca deve ser aprovado pela mesma pessoa que o recebeu, e precisa de duas aprovações distintas de duas pessoas diferentes — três mãos no total — antes de o ERP aceitar pagar para o novo IBAN.

O ataque não precisa de hackear nada

A forma mais barata de desviar um pagamento a um fornecedor não passa por invadir um servidor. Passa por um e-mail.

O padrão, documentado ano após ano pelo Internet Crime Complaint Center (IC3) do FBI, chama-se Business Email Compromise (BEC) — nalguns casos com uma variante específica conhecida como vendor email compromise, em que o atacante compromete ou imita a conta de correio de um fornecedor real e usa-a para pedir a mudança da conta bancária onde a operadora ou a EPC deve depositar o próximo pagamento. Só em 2024, o IC3 recebeu 21.442 queixas de BEC, com perdas declaradas de 2,77 mil milhões de dólares — o segundo maior valor de perdas de todas as categorias de crime reportadas, mesmo não sendo a categoria mais denunciada em número de casos (FBI IC3, Relatório Anual 2024). Entre Outubro de 2013 e Dezembro de 2023, o total acumulado de perdas identificadas por BEC a nível global chegou a 55,5 mil milhões de dólares (FBI IC3, PSA I-091124).

O mecanismo é sempre o mesmo, com pequenas variações de encenação:

1. O atacante regista um domínio quase idêntico ao do fornecedor real (uma letra trocada, um .co em vez de .com) ou compromete de facto a caixa de correio do fornecedor.

2. Envia um e-mail ao departamento financeiro ou de contas a pagar, em tom administrativo normal — muitas vezes citando uma factura real, um número de contrato real, um nome de contacto real. "Actualizámos o nosso banco. Por favor actualizem os dados para os próximos pagamentos."

3. Anexa uma carta em papel timbrado, com selo e assinatura, tudo visualmente convincente.

4. Pede que a mudança seja aplicada antes do próximo pagamento vencer — criando urgência.

Não há malware, não há exploit, não há nada que um antivírus detecte. O ataque explora um processo, não uma vulnerabilidade técnica. E é exactamente por isso que a resposta certa não é mais segurança de rede — é controlo interno sobre um campo de dados: o IBAN do fornecedor.

Porque é que Angola tem um problema adicional

Fora de Angola, quando um pagamento vai para o IBAN errado, há normalmente algum mecanismo de recall entre bancos, ainda que lento e sem garantias. Em Angola, a análise jurídica publicada pela sociedade de advogados CAZOS sobre erros de IBAN é directa quanto a este ponto: a execução da transferência é feita pelo identificador único (o IBAN), sem verificação de correspondência entre o nome do beneficiário e o número da conta, e o risco do erro recai sobre quem ordena a transferência. Ao abrigo da Lei n.º 40/20 (Lei do Sistema de Pagamentos de Angola), o banco do ordenante deve apenas envidar esforços razoáveis para recuperar os fundos, em cooperação com o banco do beneficiário; não existe, segundo essa análise, um mecanismo legal obrigatório de recall, e a CAZOS propõe precisamente que o BNA crie um mecanismo nacional de devolução em 48 horas (CAZOS Advogados, "Erros no IBAN em Angola: Risco e Mitigação").

Ou seja: se o dinheiro sair para a conta errada, recuperá-lo depende da boa vontade do banco recebedor e da rapidez com que se age — não de um direito automático. Isto muda o cálculo de risco. Numa jurisdição onde a reversão é incerta, o único momento em que se pode efectivamente controlar o risco é antes de o pagamento ser instruído, não depois. O Banco Nacional de Angola já reconheceu a dimensão do problema ao nível dos sistemas de pagamento doméstico, emitindo o Instrutivo n.º 14/2023, de 23 de Outubro, que estabelece requisitos mínimos de informação e autenticação forte para prevenção de fraude no Sistema Multicaixa e no Sistema de Transferências Instantâneas (PTI — "BNA estabelece novos requisitos para prevenção de fraude"). Esse instrutivo dirige-se aos prestadores de serviços de pagamento e à autenticação dos seus clientes; a alteração de dados bancários de um fornecedor dentro do ERP da empresa é um ponto de controlo anterior, que fica do lado da empresa pagadora.

O controlo de três mãos, explicado sem ambiguidade

O princípio que evita este tipo de fraude não é novo — é a regra clássica de segregação de funções aplicada a um campo de dados específico. Formulado de forma concreta para dados bancários de fornecedores, funciona assim:

Mão 1 — Quem pede a alteração não é quem a aprova.

Qualquer pedido de alteração de IBAN, banco ou titular de conta de um fornecedor entra no sistema como um registo PENDENTE, criado por quem recebeu o pedido (normalmente alguém em contas a pagar ou em procurement). Esta pessoa não tem permissão de sistema para aprovar a sua própria alteração. O ERP tem de impedir isto ao nível do papel de utilizador (role), não apenas por convenção — se a mesma conta de utilizador consegue criar e aprovar o mesmo registo, o controlo não existe, existe só no papel.

Mão 2 — Primeira aprovação, com verificação fora de banda.

Uma segunda pessoa, com um papel distinto (tipicamente um responsável de procurement ou de compliance financeiro), tem de confirmar o pedido através de um canal que não seja o e-mail que originou o pedido. Isto significa ligar para o número de telefone que já estava registado no cadastro do fornecedor antes do pedido — nunca para um número indicado na própria mensagem de mudança. Só depois desta verificação telefónica confirmada é que esta pessoa regista a primeira aprovação no sistema.

Mão 3 — Segunda aprovação, de uma pessoa diferente, com autoridade financeira.

Uma terceira pessoa — normalmente o controller financeiro ou o CFO, nunca a mesma pessoa da Mão 2 — dá a segunda aprovação, revendo o histórico do fornecedor (há quanto tempo trabalha com a empresa, valor médio de facturação, se já houve alterações recentes de dados bancários) antes de confirmar. Só quando as duas aprovações distintas estão registadas é que o registo bancário passa de PENDENTE para ACTIVO.

Três mãos, três pessoas, três eventos de sistema com data, hora e utilizador registados. Nenhuma delas pode ser a mesma pessoa das outras duas.

Detalhes que decidem se o controlo funciona ou é teatro

Alguns pormenores de implementação separam um controlo real de um controlo cosmético:

Período de carência antes de o novo IBAN poder ser usado. Mesmo depois da segunda aprovação, o ERP deveria impedir o uso do novo IBAN numa corrida de pagamentos durante, por exemplo, 24 a 48 horas. Isto dá tempo para que uma notificação automática — enviada para o e-mail e telefone antigos do fornecedor, não os novos — avise "a sua conta bancária foi alterada no nosso sistema; contacte-nos imediatamente se não foi você." Se o pedido era fraudulento, esta é a rede de segurança que ainda intercepta o esquema antes do dinheiro saír.
O registo bancário anterior nunca é apagado, apenas substituído com histórico. Isto é essencial para qualquer investigação ou auditoria posterior, e é o mesmo princípio de trilho de auditoria imutável que já detalhámos a propósito de permissões e RBAC num ERP industrial — ver "Permissões que Não Mentem".
A segregação de funções tem de estar no motor de permissões, não em SOPs em PDF. Um procedimento escrito que diz "duas pessoas devem aprovar" não impede nada se o sistema permite que uma pessoa faça login com duas contas, ou que um administrador desactive temporariamente a regra "para acelerar" um pagamento urgente. As excepções são precisamente onde a fraude entra.
O gatilho de pedido de alteração deve estar ligado ao fluxo de qualificação e cadastro de fornecedores, não ser um formulário solto. Se o seu processo de procurement já trata a ficha do fornecedor como um objecto com histórico e workflow — como descrevemos a propósito da automatização do ciclo de compra a factura — ver "Procurement Automatizado em Angola" — a alteração de dados bancários é apenas mais um estado desse objecto, com as mesmas regras de aprovação.

Uma tabela para decidir o desenho mínimo

Elemento do controlo	Sem controlo (risco alto)	Controlo de três mãos
Quem cria o pedido	Qualquer utilizador com acesso à ficha do fornecedor	Registado como criador; sem permissão de auto-aprovação
Canal de verificação	Resposta ao próprio e-mail recebido	Chamada para número já registado antes do pedido
Número de aprovadores distintos	0 ou 1	2, obrigatoriamente pessoas diferentes entre si e do criador
Uso imediato do novo IBAN	Sim, no próximo pagamento	Bloqueado durante período de carência de 24-48h
Notificação ao fornecedor	Nenhuma	Automática, para contacto antigo, no momento da mudança
Registo anterior	Sobrescrito	Preservado com histórico completo

Onde a cibersegurança entra, além do controlo de processo

O controlo de três mãos resolve o processo de negócio. Mas a exposição real de uma empresa a este vector de ataque também depende de quão fácil é, na prática, comprometer ou imitar de forma convincente a caixa de correio de um fornecedor ou de um colaborador interno — através de phishing dirigido, credenciais reutilizadas, ou falta de autenticação multifactor nas contas de e-mail que gerem pagamentos. Uma avaliação de segurança que cubra especificamente estes pontos de entrada, e não apenas firewalls e antivírus, é o complemento natural ao controlo de aprovação no ERP; é o tipo de trabalho que cai dentro do âmbito do serviço de cibersegurança da Wise Hustlers.

Perguntas frequentes

Uma aprovação por e-mail entre duas pessoas já conta como "duas mãos"?

Não, se ambas as aprovações se basearem apenas no conteúdo do mesmo e-mail recebido, sem verificação por um canal independente. A robustez do controlo vem da verificação fora de banda (Mão 2), não do número de assinaturas num fio de e-mail.

E se o fornecedor insistir que a mudança é urgente e não há tempo para o período de carência?

Um fornecedor legítimo aceita um atraso de 24 a 48 horas para confirmar uma mudança de conta bancária. Pressão para saltar a verificação é, em si, um dos sinais mais consistentes descritos nos alertas de BEC do IC3 e deveria ser tratada como bandeira vermelha, não como justificação para contornar o processo.

Isto aplica-se só a fornecedores externos, ou também a mudanças de dados bancários de colaboradores (folha de pagamento)?

O mesmo princípio de três mãos aplica-se a qualquer alteração de conta de destino de pagamentos recorrentes — incluindo mudanças de IBAN de colaboradores, um vector de fraude também documentado pelo FBI IC3 em pedidos que imitam comunicações de Recursos Humanos.

O ERP já tem um workflow de aprovação de facturas. Não basta usar o mesmo fluxo para mudanças bancárias?

Não deveria ser o mesmo fluxo. Aprovação de facturas valida o que se deve pagar; o controlo de dados bancários valida para onde se paga. São riscos diferentes e, idealmente, com aprovadores parcialmente diferentes, para que o comprometimento de uma única pessoa não seja suficiente para desviar o pagamento em nenhum dos dois pontos.

Alteração de Dados Bancários de um Fornecedor: O Controlo de Três Mãos que Evita o Pagamento Errado