Pular para o conteúdo

PLD na Suíte Guardline

A Suíte Guardline trata prevenção a fraudes e prevenção à lavagem de dinheiro (PLD) na mesma plataforma, com o mesmo motor de decisão e a mesma interface. Fraude e PLD são dois domínios do mesmo motor: cada um tem o seu workflow, as suas regras e os seus limiares, e a instituição configura os dois no mesmo lugar, com a mesma governança e a mesma trilha de auditoria.

A PLD acrescenta ao motor o que a prevenção a fraudes não precisa: um catálogo de cenários com identidade regulatória, um alerta que é documento e não apenas decisão, a consolidação de vários disparos num único caso, e um caminho de ida e volta com a Mesa de Decisão, onde a investigação, o comitê e a comunicação ao COAF acontecem.

Esta edição descreve a operação brasileira: o catálogo de cenários segue as tipologias da Carta Circular 4.001/2020 do BACEN, os documentos são CPF e CNPJ, as contrapartes são identificadas por chave PIX ou conta, os valores são em reais e a comunicação ao COAF sai no formato do SISCOAF. A plataforma também opera em outras jurisdições da América Latina, e a edição em espanhol descreve essa operação.


A fronteira entre os módulos é fixa e é o que torna a operação auditável.

MóduloResponsabilidade na PLD
Fraud Prevention Platform (FPP)Recebe as transações, avalia cada uma contra o workflow de PLD, produz o alerta com cenário, severidade e evidência, consolida disparos repetidos e despacha o alerta para a Mesa. Oferece ao Compliance a parametrização dos cenários e a lista de alertas.
Case Management Platform (CMP)É a dona do caso. Recebe o alerta, abre ou atualiza o caso, conduz triagem, investigação, revisão e comitê, gera o XML de comunicação ao COAF no formato do SISCOAF e devolve o veredito à FPP.
Onboarding Platform (ONP)É a dona do cadastro e da matriz de risco do cliente. Apura PEP, sanções e antecedentes no onboarding e entrega esses atributos, com procedência, aos demais módulos.
InstituiçãoDecide no comitê, protocola a comunicação ao COAF no SISCOAF e mantém as suas listas próprias, carregadas manualmente ou por API.

  1. A transação entra pela integração em tempo real ou pela fila de lote, com o documento tipado (CPF ou CNPJ), o país e a moeda explícitos.
  2. O motor avalia a transação no domínio de PLD, com o mesmo enriquecimento, o mesmo perfil comportamental e as mesmas janelas que servem a fraude.
  3. Uma regra que dispara produz um alerta, porque toda regra de PLD aponta para um cenário do catálogo. O alerta nasce com o código da tipologia da Carta Circular (MOV001, EST002, PIX002 e os demais), a severidade configurada pelo Compliance e as transações que o sustentam.
  4. O avaliador por entidade roda periodicamente e produz alertas que nenhuma transação isolada produziria: acúmulos por sujeito, cenário e janela.
  5. Disparos repetidos do mesmo sujeito no mesmo cenário se consolidam num único alerta dentro da janela do cenário. O primeiro abre o caso; os seguintes somam evidência ao mesmo caso.
  6. Os alertas de severidade média e alta vão para a Mesa de Decisão; os de severidade baixa ficam registrados e agregados na FPP, à disposição do Compliance.
  7. A Mesa conduz o caso até o comitê e, quando cabe, até a comunicação ao COAF.
  8. O veredito volta: o encerramento em triagem, a decisão do comitê e o registro da comunicação chegam à FPP, atualizam o estado do alerta e entram no histórico do cliente.

Um motor, dois domínios. A instituição não mantém dois sistemas, duas bases de clientes e dois cadastros de regras. O perfil comportamental que a fraude constrói serve à PLD, e a decisão de fraude nunca é afetada por um workflow de PLD ativo.

O alerta é um documento. Cada alerta carrega sujeito com documento tipado e país, cenário com código e referência ao catálogo, severidade com a sua origem, janela, evidência guardada como retrato das transações e estado. É o que uma investigação e um dossiê regulatório precisam.

O catálogo governa. Regras sem cenário não produzem alerta. Isso impede o ruído de alertas sem tipologia e dá ao Compliance um único lugar para ligar, desligar e parametrizar cada cenário, com aprovação e histórico.

A Mesa é uma só. O caso, o comitê e a comunicação ao COAF vivem na CMP, que opera a PLD brasileira de ponta a ponta, da triagem ao XML do SISCOAF. A FPP não duplica a mesa; ela alimenta e recebe de volta.

A jurisdição é dado explícito. Documento, contraparte, tipo de operação, cenário e tela são resolvidos pela jurisdição e pela moeda que o tenant declara (Brasil e real), nunca por um padrão escondido no código.

Toda mudança de motor é provada. Antes de chegar a um ambiente da instituição, cada alteração no motor passa por uma rodada diferencial: o mesmo tráfego avaliado pela versão atual e pela nova, com zero diferença de decisão exigida para o caminho de fraude. O relatório dessa rodada acompanha a entrega.


PáginaO que cobre
Perfis e domíniosComo um tenant é de fraude, de PLD ou de ambos, e o que muda em cada caso
Ingestão e identidadeComo a transação entra, CPF e CNPJ, chave PIX e conta como contraparte, lote e replay
Cenários e tipologiasO catálogo das tipologias da Carta Circular 4.001/2020, os cenários entregues e como uma regra vira alerta
Comportamento e janelasPerfil comportamental, janelas relativas à data da transação, fluxos circulares e o avaliador por entidade
AlertasO objeto de alerta, os dois tipos, a consolidação e a lista na FPP
Mesa de Decisão e caminho de voltaO despacho para a CMP, o caso, o comitê e o veredito que retorna
Parametrização e governançaA tela de matriz do Compliance, aprovação e auditoria

Versão 18, atualizada em