A aprovação que compromete sua auditoria veio da sua própria equipe. Veja como provar quem decidiu e por quê.

Imagine a situação da auditoria. O auditor seleciona aleatoriamente quarenta arquivos de clientes. O arquivo vinte e três é de um cliente cujo rosto não corresponde à foto em seu registro governamental. A verificação falhou. A conta permanece aberta mesmo assim e vem movimentando dinheiro há cinco meses.

Alguém aprovou. O auditor faz três perguntas. Quem? Com ​​que base? Essa pessoa tinha permissão para fazer isso?

Sua equipe acessa o sistema administrativo por meio de uma conta compartilhada, então a primeira resposta é "operações". Não há nenhuma observação, então a segunda resposta é um palpite. Todos com esse login podem aprovar qualquer coisa, então a terceira resposta é sim, que é a pior das três.

Nada foi hackeado. Nenhum fraudador burlou suas verificações. O controle funcionou e um dos seus funcionários o desativou para um cliente. Isso é risco interno em uma operação de compliance e, na maioria das vezes, não é crime. É um favor, um atalho em uma sexta-feira movimentada ou uma meta que precisava ser atingida.

Por que "quem decidiu?" é a pergunta do auditor.

Os padrões pelos quais você é avaliado partem do pressuposto de que seus funcionários fazem parte do risco. FATF A Recomendação 18 (abre num novo separador) exige que as instituições financeiras implementem programas de combate à lavagem de dinheiro, e sua nota interpretativa afirma que esses programas devem incluir políticas, procedimentos e controles internos, procedimentos de triagem na contratação de funcionários, treinamento contínuo e "uma função de auditoria independente para testar o sistema".

As diretrizes do Comitê de Basileia sobre a gestão adequada do risco de lavagem de dinheiro (abre num novo separador) descrevem três linhas de defesa, sendo a auditoria interna a terceira. Entre os aspectos que se espera que a auditoria avalie está "a eficácia dos funcionários do banco na implementação das políticas e procedimentos da instituição". As mesmas diretrizes afirmam que os registros devem ser suficientemente robustos para fornecer uma trilha de auditoria em caso de disputas, ações judiciais ou investigações.

Portanto, o auditor não está apenas testando se seus controles são eficazes. Ele está testando se sua equipe os seguiu e se você pode comprovar isso. Uma decisão que você não consegue atribuir a um responsável falha nesse teste, mesmo que tenha sido a decisão correta.

Existem algumas evidências sobre a frequência com que os controles falham internamente, embora se refiram a fraudes contra empregadores e não a aprovações de conformidade. ACFE O relatório " Fraude Ocupacional 2024: Um Relatório para as Nações" (abre num novo separador) analisou 1.921 casos em 138 países e territórios. Atribui 32% desses casos principalmente à falta de controles internos e outros 19% à violação de controles existentes. O caso típico levou 12 meses para ser detectado. Não encontramos dados com essa mesma precisão para violações de conformidade em mercados africanos, portanto, não os apresentaremos.

Quatro controles que respondem a isso.

Nada disso é novidade. NIST O SP 800-53 (abre num novo separador) , catálogo de controles de segurança do governo dos EUA, é uma referência útil em linguagem simples, mesmo que você não esteja obrigado a segui-lo.

• Princípio do menor privilégio. O controle solicita que você permita "apenas acessos autorizados" necessários para a execução das tarefas atribuídas. Em uma equipe de conformidade, isso significa que a pessoa que lê os alertas não pode alterar as regras que os geram.

• Uma segunda pessoa em ações delicadas. NIST A separação de funções, segundo ela, "aborda o potencial de abuso de privilégios autorizados e ajuda a reduzir o risco de atividades maliciosas sem conluio". Uma pessoa pode cometer um erro ou fazer um favor. Duas pessoas precisam concordar com isso.

• Um login por pessoa, com um segundo fator de autenticação. O catálogo exige que você identifique cada usuário de forma única e utilize autenticação multifator para contas privilegiadas. Um login compartilhado anula todos os outros controles, pois o registro só pode identificar a conta.

• Um registro de auditoria que identifica a pessoa envolvida. Os registros de auditoria devem estabelecer o que aconteceu, quando, onde, o resultado e a identidade dos indivíduos envolvidos.

Como isso se parece em Toden

Veja como cada controle se relaciona com o produto atualmente.

• Funções. Cada pessoa possui exatamente uma função, e uma função é um conjunto de permissões que você escolhe. Aprovar ou rejeitar uma verificação requerverifications:reviewAnular uma decisão de fraude exigefraud_prevention:overrideMudanças nas necessidades de triagemscreening:managee a mudança de um fluxo de trabalho precisaworkflows:manageOs papéis integrados de Membro e Visualizador são somente leitura. As permissões são verificadas no servidor e ninguém pode conceder uma permissão que não possua.

• Uma sobreposição que permanece visível. Quando um revisor aprova uma verificação, ela não é reescrita. O status da verificação continua indicando o que foi encontrado, e o histórico de status lista todas as alterações, com quem as fez e quando. O revisor pode adicionar uma nota explicando o motivo, que é registrada no seu log de auditoria e na linha do tempo.

• Um controle desligado. Um fluxo de trabalho com AML Desativar a triagem não afeta ninguém, portanto, essa alteração merece ser registrada. A publicação de um fluxo de trabalho é registrada no log de auditoria. Desativar a triagem para toda a organização requer permissão específica e confirmação explícita, e também é registrado.

• Autenticação de dois fatores. Os membros fazem login com códigos de aplicativos autenticadores ou uma senha. Uma organização pode exigir autenticação de dois fatores para todos os membros, e qualquer sessão pode ser revogada imediatamente.

• O registro de auditoria. Cada entrada contém o nome e o e-mail da pessoa no momento da ação, o cargo que ocupava, a ação realizada, o registro afetado e o endereço IP. É um registro somente para adição: não há como editar ou excluir uma entrada pelo console ou pelo sistema. API Não contém números de identificação, imagens ou segredos, portanto, você pode entregá-lo a um auditor. Ações Toden As solicitações de suporte para sua conta serão registradas em seu histórico, sinalizadas como tal.

• Duas pessoas envolvidas em um relatório. A pessoa que redige um relatório de atividade suspeita nunca pode ser a mesma que o preenche. Abordamos o relatório em si na seção "Como redigir um relatório de atividade suspeita" e o trabalho que o precede na seção " Triagem de alertas e gerenciamento de casos" .

O que Toden não faz

Os limites importam mais do que as funcionalidades.

• Isso exige uma segunda pessoa apenas para uma ação: o preenchimento de um relatório. Para aprovações e exceções, a separação vem das funções que você define. Se uma pessoa detém todas as permissões, ela ainda pode fazer tudo.

• Isso não impede um funcionário determinado. Um revisor com a permissão adequada pode aprovar uma verificação reprovada. O quê? Toden O objetivo é garantir que a aprovação inclua o nome da pessoa e que o cheque recusado permaneça registrado.

• Não é possível determinar se duas pessoas compartilham o mesmo login. Exigir autenticação de dois fatores dificulta o compartilhamento. Não o torna impossível, e a política contra isso é sua.

• Decisões que seu backend toma através do API são registrados em relação ao API chave, não pessoa. Quem pressionou o botão no seu sistema está nos seus registros, não nos nossos. Veja publicável e secreto. API chaves .

• O registro de auditoria abrange Toden Não sabe nada sobre o seu sistema bancário principal, suas planilhas ou as instruções que chegaram por mensagem de chat.

• Toden não se sustenta SOC 2 ou ISO Obtivemos a certificação ISO 27001 hoje. Nossa página de segurança confirma isso e lista os controles existentes.

As expectativas do seu órgão regulador em relação aos controles internos, à verificação de antecedentes dos funcionários e à manutenção de registros variam de país para país. Citamos o seguinte: FATF , o Comitê de Basileia e NIST Aqui, não se trata do Banco Central da Nigéria ou de qualquer outro órgão regulador nacional. Isto não constitui aconselhamento jurídico para a sua situação.

Cinco coisas para verificar esta semana

• Cada pessoa tem seu próprio login? Conte as contas e depois conte as pessoas.

• A autenticação de dois fatores é obrigatória para todos ou apenas recomendada?

• Quem pode aprovar um cheque sem fundos, e essa lista é menor do que a lista de pessoas que podem visualizá-lo?

• A pessoa que altera uma regra também pode limpar os alertas gerados por ela?

• Escolha uma aprovação do mês passado. Você consegue dizer quem a concedeu e por quê, em menos de cinco minutos?

Se a última resposta for não, esse é o arquivo que o auditor irá consultar.

Quer ver quem pode fazer o quê no seu próprio espaço de trabalho? Abra o Toden console (abre num novo separador) ou leia como Toden Lida com a segurança .