Operações e Complaens → política e controle de transações AML

Política AML e Controle de Transações

1) Alvo e alcance

O objetivo da política AML é impedir o uso da plataforma de lavagem de fundos e financiamento do terrorismo, minimizando os falsos efeitos e a carga operacional. A política se aplica a todo o ciclo de vida de um jogador: inscrição → depósito → jogo/transferência → conclusão; e também para afiliados, provedores e parceiros de pagamento.

2) Princípios (risk-based & evidence-by-design)

1. Risk-Based Approach (RBA): Verificações e liminares dependem do perfil de risco (país, método de pagamento, comportamento, valores).
2. Layered Controls: combinação de CUS/sanções/RER, análises comportamentais e investigações manuais.
3. Evidence-by-Design: Cada solução possui artefatos: fontes de dados, capturas de tela, logs, relatórios exportados.
4. Privaciy-first: Minimização de PDN, camuflagem, acesso a papéis, política de retenção controlada.
5. Explainability: regras e modelos são interpretáveis; para ML - fici/importância/exemplo de mala.
6. Contínuo Improvement: configuração de liminares, feedback de MLRO e retro por mala.

3) Papéis e responsabilidades

MLRO (Money Laundering Reporting Officer): proprietário do processo AML, decisões finais sobre SAR/TR, comunicação com reguladores/bancos.
AML Ops: investigação, comunicação com jogadores/bancos, controle de mala SLA.
Data/BI & Risk Analytics: suporte a regras/modelos, monitoramento de qualidade de detecção.
Payments/Ops: Cumprimento de limites e procedimentos hold/reversíveis, rastreamento de transações.
Segurança/DPO: proteção de dados, acessibilidade, incidentes de privacidade.

4) Modelo de risco do jogador e segmentos

• Geo/IP/residência, documento e método KYC.
• Métodos de depósito/conclusão, múltiplidade de ferramentas de pagamento.
• Atividade: somas, frequência, winreit/lossreit, sessões noturnas, correlação com outras contas.
• Dispositivos/fingerprint, cruzamento IP/dispositivos/adereços de pagamento.

Segmentos: Low/Medium/High/Prohibited.
Motor de rotação: Low - Verificações simplificadas; High - EDD/hold/restrições.

5) KYC, sanções e PEP

Tiered KYC: 'KYC1 (identidade) → KYC2 (endereço) → EDD (documentos extras/SoF)'.
Sanções/RER: Verificação de registro, com liminares significativos de depósito/conclusão e alterações de adereços.
SoF/SoW: por desencadeador (alta velocidade, inadequação de perfil, VIP).
Retensschn: armazenamento de documentos de acordo com os requisitos de jurisdição; acesso vault/controle de emissão.

6) Controle de transações (regras e sinais)

• Velocity: espinhos rápidos de depósitos/conclusões; uma série de depósitos menores → uma grande conclusão.
• Multi-instrument: muitos cartões/carteiras diferentes em um curto período.
• Fonte/Destino mismatch: depósito de uma ferramenta, saída para outra.
• Circular: reabastecimento → taxas mínimas/lavagem de bônus → conclusão.
• Split/Estruturing: fragmentação de quantias sob liminares.
• Affiliate abuse: fluxo anormal do canal + pattern típicos de abuso.
• Device/IP risk: mudanças de dispositivo/proxy/ASN de alto risco.

• Vinerite irrealista em baixa dispersão, apostas de «conteúdo parceiro» com queixas, jogos com risco mínimo para o tráfico.

7) Controls-as-Code (fatias)

yaml control_id: AML-VELOCITY-DEP-01 scope: deposits risk_weight: 0. 8 trigger:
expr: rolling_sum(amount, 1h) > baseline_30d3
OR count_unique(payment_method, 1h) >= 3
OR count(amount < threshold_structuring, 24h) >= 5 actions:
- flag: aml_review
- limit: withdrawals "hold_24h"
- request: "KYC2_or_EDD"
evidence:
store: s3://evidence/aml/velocity/{player_id}/{ts}
fields: [amounts_1h, methods_1h, ip, device, kyc_level]
owner: mlro review_sla_days: 180

yaml control_id: AML-SRC-DST-02 scope: withdrawals trigger:
expr: payout_method!= last_successful_deposit_method actions:
- limit: withdrawals "require_same_source"
- notify: payments_team
- flag: aml_review exceptions:
- condition: method_type=="bank_transfer" AND policy. allow_bank_payouts==true evidence:
fields: [payout_method, last_deposit_method, policy_ref]

yaml control_id: AML-GAMING-PATTERN-03 scope: gameplay trigger:
expr: turnover_24h / deposits_24h > 10
AND avg_bet_risk_index < 0. 2
AND session_count_24h > 8 actions:
- flag: aml_review
- limit: bonuses "freeze"
- request: "source_of_funds"

yaml control_id: AML-RISK-SCORE inputs: [AML-VELOCITY-DEP-01, AML-SRC-DST-02, AML-GAMING-PATTERN-03, sanctions, pep]
score:
expr: w1velocity + w2srcdst + w3gaming + w4sanctions + w5pep thresholds:
- high: score>=0. 8 -> EDD + hold
- medium: score>=0. 5 -> review
- low: score<0. 5 -> auto_clear

8) Modelos e regras: compartilhamento

Rulas-first no início (rápido, explicável) + ML para priorização (busting gradiente/logreg/fichas recuperáveis).
Champion/Challenger: compara as liminares atuais com os novos modelos nas sombras.
Monitoramento Draft: controle de deslocamento de fichas, fração de bandeiras/hold, FPR/TPR.
Expainability: SHAP/função importance, malas de referência.

9) SOP (fatias)

SOP: triagem de acionamento AML

1. Verificar o cartão do jogador (geo, KYC, risco, histórico).
2. Verifique fontes de dados (logs de pagamentos/jogos, comunicações por dispositivo).
3. Decidir: 'clear/request _ info/hold/EDD/SAR'.
4. Fixar as ações no sistema de malas e atualizar o status.
5. Comunicação com o jogador (modelo, data de resposta).
6. Revisão do limiar/regra (se muitos FPs).

SOP: EDD/SoF solicitação

1. Solicitação de documentos (extratos/salários/impostos).
2. Mapear somas/frequências/fontes com o comportamento na plataforma.
3. Atualizar perfil de risco, eliminar/confirmar restrições.
4. Salvar evidence e solução (assinatura MLRO).

SOP: SAR/TR suprimento

1. Recolher factos (timeline, somas, ligações, crinques).
2. Verificar deadline e formatos de jurisdição/banco.
3. Apresentar SAR/TR, fixar ID/hora/canal.
4. Atualizar status interno e restrições de conta.
5. Fallow-up até o encerramento/instruções do regulador/banco.

10) Comunicação com jogadores e parceiros

O tom é neutro e factual, sem a divulgação de regras/modelos internos.
Prazo: nítidos ETA para resposta, lembretes, fixação no tíquete.
Associados de pagamento: sincronização hold/reverso, troca de mala-ID, canal único AML.

11) Integração e dados

Payments Gateway: status de transações, método e adereços, devoluções, chargeback.
Game Plataforma: rotação/vinrate/sessão/dispersão, anomalias.
Device Graph: fingerprint/comunicações de dispositivos/sessões/IP.
KYC/PEP/Santidades: provedor de screening para eventos e horários.
Case Management: estatais, SLA, registro de soluções, embalagem SAR/TR.

12) Indicadores de qualidade (KPI/OKR)

• TPR/Recall por mala confirmada, FPR (falsas bandeiras) ↓ QoQ.
• Precision по High-risk > X%; Auto-clear Rate для Low-risk > Y%.
• Case Priorization Accuracy (N superior% dá M% de descobertas).

• Time-to-Triage (P95), EDD Turnaround, Hold Duration (mediana).
• SAR/TR SLA (fornecimento de prazo ≤), devoluções/marceback após medidas de ↓ AML.
• Model/Rule Drift - dentro dos corredores permitidos.

• Perda de frod/lavagem de ↓, relógio de operação/mala ↓.
• Player Experience: Queixas sobre processos AML, NPS sobre jogadores honestos.

13) Governance e segurança

Políticas de acesso: somente AML/MLRO vislumbram campos sensíveis; auditorias de leitura.
Retensschn: prazo de armazenamento das malas/documentos; limpeza automática.
Registro: todas as ações de mala e edição de regras/modelos.
Dual Control: Alterações críticas de regras/liminares exigem duas confirmações.
Testes CI: sintaxe de regras, liminares conflitantes, cenários de regressão.

14) Folhas de cheque

• Dados de transações/jogos/dispositivos foram verificados.
• Os métodos de depósito/retirada foram mapeados.
• Foram verificadas sanções/RER/geo.
• Selecionou um tipo de solução correto ('clear/hold/EDD/SAR').
• Registado ETA e comunicação ao jogador.

• Tempo completo e soma, ligações com outras contas.
• Artefatos de confirmação (tábuas/logs/extratos).
• O formato e o canal correspondem a uma demanda.
• Os estados e restrições internos foram atualizados.
• Controlar instruções posteriores.

• O limite/janela do tempo é razoável.
• Há uma avaliação FP/TP, um efeito empresarial.
• O monitoramento da deriva e dos carros estão configurados.
• O playbook da triagem foi atualizado.
• Realizado com um revezamento MLRO/Compliance.

15) Anti-pattern

Liminares universais «para todos os países» sem RBA.
Hold sem ETA/comunicação, malas penduradas.
Modelos ML sem explicabilidade ou registro de versões.
Descarga manual/SAR sem padrões de evidence e controle de prazos.
Falta de comunicação, pouca integração com pagamentos.
Não há registo regular sobre falsos efeitos.

16) 30/60/90 - plano de implementação

• Aprovar política AML, papéis (MLRO/AML Ops) e matriz RBA.
• Execute o Controls-as-Code básico (velocity, src/dst mismatch, gaming pattern).
• Incluir KYC tiers + sanções/RER, criar modelos SOP (triagem/EDD/SAR).
• Introduza o armazenamento de evidence e a política de retenção.

• Ligar o agregador de risco-score, o roteiro automático das malas e os relatórios SLA.
• Iniciar o campeão/challenger para liminares e assistente de priorização ML.
• Integrar payments/game/device gráfico em um único perfil de jogador.
• Treinar os comandos, ajustar os modelos de comunicação, incluir as regras autônomas.

• Reduzir FPR de 20% sem perder Recall; reduzir o Time-to-Triage em ≥ 30%.
• Atingir SLA SAR/TR = 100% no prazo; Fechar todas as malas.
• Auditar internamente o design e a eficiência dos controles; fixar a OKR para o próximo trimestre.

17) FAQ

Q: Como equilibrar segurança e UX?
A: Routagem RBA: para low-risk - limpeza automática, para medium - consultas fáceis, para high - EDD/hold. Transparência ETA e comunicações.

O que fazer com VIP e limites elevados?
A: EDD obrigatório, revisão periódica do SoF/comportamento, conclusão vinculada severa (fonte-to-nature), limites adicionais.

Quando escalar para o banco/regulador?
A: Com bandeiras vermelhas confirmadas/suspeitas dentro do prazo jurisdicional; após a consulta do MLRO e a fixação da evidência.