Políticas de conclusão: prazos e KYC

1) Por que formalizar a política de conclusões

• reduz os tíquetes e escaladas ("Quando é que o dinheiro chega? »);
• fornece conformidade AML/KYC (idade, sanções, SoF/SoW);
• reduz o frod/charjbacks e disputas de arbitragem;
• dá SLA previsível para finanças/safort/marketing.

2) Classificação de trilhos e velocidade prevista

3) Níveis de KYC e impacto nas conclusões

Princípio: Quanto mais alto for o KYC, mais amplos são os trilhos disponíveis e maiores são os limites/velocidade.

Basic (simplificado): pequenos limites; apenas são permitidas conclusões «lentas» ou internas (para carteira/limitada A2A).
Full KYC (ID + Address + Liveness): limites padrão; acesso a roteiros bancários, Push-to-Card, esquemas rápidos locais.
EDD (estendido): grandes quantias/pagamentos frequentes; é necessário SoF/SoW (origem/estado), lista branca de destinatários, processamento acelerado.

Step-up-desencadeadores: grande montante, novo destinatário, dispositivo/geo atípico, excesso de velocidade, high-risk MCC (iGaming, quasi-dinheiro), ganho acumulado.

4) Limites e antifrode nas conclusões

• Per-transaction / Daily / Weekly / Monthly caps.
• Velocity: N pagamento/hora, soma na janela deslizante, taxa de mudança de adereços.
• Novos destinatários: abaixado com um cooling/obrigatório-off (por exemplo, 12-24 h) e step-up.
• Geo/sanções: lista deny/allow, proibição de determinados países/bancos.
• Perfil de risco: multiplicadores de limite de pontuação do cliente/sessão.
• Payout-lock: bloqueio temporário após anomalias/plugeback/ODR, antes de a verificação ser concluída.

5) Payout-status e modelo operacional

• 'requested' - pedido do usuário
• 'queued' - colocado na fila de pagamento
• 'processing' - processado pelo provedor/banco
• 'sent' - enviado para o caminho (há UTR/ARN/Trace)
• 'massled' - O destinatário/não tem finricas confirmadas
• 'failed' - falha de trilho/banco
• 'reversed/returned' - reembolso (códigos ACH R, SEPA return, FPS reject)
• 'on _ hold' - verificação de complacência/EDD/SoF
• 'canceled' - cancelado pelo usuário/operador

Artefactos: «payoutId», «requestId», «beneficiaryId», «rail», «amount/currency», «UTR/ARN/Trace», códigos de falha.

6) Fila de pagamento e arquitetura de núcleo

• Orquestrador (state machine): Roading por roteiros/limites/temporizações.
• Scheduler: contabilidade cut-off/feriados (per-rail/per-country).
• Idempotency: chave em 'requestId' + dedução de eventos.
• Provedor de webhooks: assinatura/NMAS, retraí com backoff, DLQ.
• Reconciliação: auto-recon por registros (diários) + periódico full-recon; armazenamento UTR/ARN.
• Policy Engine: Regras de CUS/Limites/Verificação e Causas de Falha (explorabilidade).
• Treasury/Liquidity: Monitoramento de sobras em bancos PSP/banco, prefanding para roteiros rápidos, rebalance.

7) Liquidez e prefanding

Roteiros rápidos (RTP/FPS/PIX/Push-to-Card/e-wallets) muitas vezes requerem prefanding.
Mantenha os limites para o provedor e auto-revalance (sweep) entre as contas.
Separe a contabilidade dos pagamentos prometidos dos débitos reais.
Insira um método automático de deserção quando a liquidez cair (alterna temporariamente para roteiros lentos).

8) Comunicações e UX

Mostrar a data/hora de entrada prevista com base no roteiro, cut-off e TZ do usuário.
Estados explicáveis: «em verificação de KYC/SoF», «aguardando janela bancária», «enviado: número UTR/ARN».
FAQ no produto: limites, prazos, roteiros suportados, o que é SoF/SoW, porque a solicitação foi rejeitada.
Novos destinatários: aviso de hold/step-up, confirmação de adereços (micro-deposit/1-cent check, teste payout).
Anti-erro UX: Máscara IBAN/BIC, validação de formato, dica BSB/Sort code, armazenamento de «modelos» dos destinatários.
Cooldown: atraso suave para perfis de alto risco com uma razão transparente.

9) Complaens: KYC/AML/EDD/SoF/SoW

KYC: ID, endereço, liveness; idade e geo-blocos.
Santo/PEP: screening em linha e cíclico; antes dos grandes pagamentos, novo cheque.
SoF/SoW: confirmação de origem de fundos/fortunas (extratos bancários, atestados de rendimentos, contrato).
Case Management: registro de soluções, processamento SLA, auditoria-trail.
Resolvível Gaming (para iGaming): colinas de retirada de bónus, verificações de auto-exclusão, limites diurnos/semanais «responsáveis».

10) Erros e retornos sobre trilhos (o que considerar)

ACH: devoluções (R01... R10), janelas NACHA, listras de bloco.
SEPA: Reject/Return/Recall; Validação IBAN, razão do código (AC04, AG01 etc.).
FPS/RTP/PIX: geralmente finalidade; a devolução é uma contraproposta separada.
Push-to-Card: Pode haver atrasos no emissor/desvio de limites.
SWIFT: comissões de correspondentes, «lifting fees», atrasos na complicação do banco destinatário.

11) Economia e comissões

Fee modelo: fix/percentual, liminares de soma, margem FX, tarifas individuais para trilhos rápidos.
Níveis KYC ↔ tarifas VIP/EDD - abaixo comissão/prioridade; Basic - maior custo de manutenção.
Custo antifrod: custo de inspeção/investimento, taxa de retorno/rejeição.
Otimização: agrupamento de pagamentos (batch), programação de roteiros «lentos» em off-peak, escolha de roteiros por soma/país/hora do dia.

12) KPI/métricas de controle

SLA cumprimento:% dos pagamentos que chegaram dentro do prazo prometido.
Time-to-Cash: Mediana/95-Percêncil do Tempo até 'sensled'.
Return/Reject rate por roteiros e razões (códigos).
Share by rail: distribuição por métodos e seus approve/setle.
ODR/queixas de atrasos/recusos.
Hold/EDD rate: proporção de pagamentos para a verificação manual; tempo médio de decisão.
Liquidity uptime: tempo em que as rotas rápidas estão disponíveis.
Cost per payout и FX impact.

13) Folha de cheque de lançamento da política de conclusões

1. Matriz de trilhos: países/divisas/limites/prazos/cut-off/feriados - no serviço de config.
2. Policy Engine: regras KYC/limites/velocity/EDD com logs explorados.
3. Orquestrador de pagamento: fila, retraí, idempotidade, webhooks com HMAC.
4. Treasury: Prefanding de caminhos rápidos, auto-revalance, limites para o provedor.
5. Provedores, playbooks, SLA, escalas.
6. OX/Comunicação: ETA por trilho, estatais, UTR/ARN, razões claras para colinas/rejeitos.
7. Recon: daily auto-recon + full-recon; alerts para «sucesso sem registro», «aging payouts».
8. Monitoramento: dashboards KPI, ansiedade de liquidez/falhas/aumento de devoluções.
9. Pacote de teste: e2e para cada trecho (sucesso/rejeição/reembolso), novo destinatário, grande quantia, temporizações do provedor.

14) Modelo de partição de políticas (para ToS/wiki)

• SEPA: T + 1 BD (até às 15h CET), SEPA Instantâneo - normalmente em até 30 minutos.
• FPS/PIX/RTP: Modo normal de minutos, mas é possível verificar até 24 horas para novos destinatários.
• ACH: T+1–T+2 BD; Same Day ACH - no lançamento de kat-off do banco.

• Até € X/dia - Basic, acima - precisa de ID + selfie; acima de € Y - SoF/SoW.
• O novo destinatário é uma colda segura até 24 horas.

• Per-txn: …, Daily: …, Weekly: … (dinâmico em nível/risco).

• SEPA/FPS — …, SWIFT — … (+ comissões de correspondentes), Push-to-Card -....

• No caso do Rejt/Return, os fundos retornarão ao balanço dentro de...; o motivo da notificação (código/descrição).

15) Respostas rápidas para a saforta

Para o fio, espere até o SE. O seu UTR/ARN é o ícone de\.
As regras de segurança (novo destinatário/valor/geo) funcionaram. Por favor, carregue o documento de a.p.
É necessário prefanding/outro limite para o canalizador. Vamos oferecer um método alternativo.
O Banco do Destinatário rejeitou (Código de\X). Verifique os adereços ou selecione outro trecho.

Currículo

Forte política de conclusões = prazo transparente + limites previsíveis KYC + orquestração de trilhos confiável. Mantenha as regras no configh, use policy engine com logs exploratórios, garanta a idempotação/Recon/Webhooks, gere liquidez e prefanding e comunique com o usuário exato ETA + UTR/ARN. Assim, você reduz o risco, mantém a complacência e aumenta a confiança sem sacrificar a taxa de pagamento.