SWIFT e traduções internacionais

1) Quando e porquê SWIFT em iGaming

• não há nenhum trecho local (SEPA/FPS/ACH) ou é necessário um pagamento B2B para outra jurisdição;
• precisa de pagamentos a parceiros/afiliados, pagamento de impostos, grandes resgates de liquidez (off-ramp → fiat);
• é preciso uma moeda que não existe nos circuitos locais.
• Benefícios: cobertura global, alta previsibilidade para gpi. Contras: custo (fee + FX), prazo (T + 0-T + 3), complacência-fricção.

2) Mecânica básica: bancos de correspondência e rotação

O BIC do beneficiário → o banco destinatário. Se não houver relações diretas, o pagamento será feito através de correspondentes (nosso/presidente).

• Serial (MT103/ISO pacs. 008 segue em sequência bank→korr→bank).
• Cover (compartilhando pagamento e cobertura por MT202 COV/pacs. 009).
• Dados da rota: BIC do banco do beneficiário, IBAN/conta, endereço/name, às vezes intermediary bank (BIC).
• Comissão: SHA/OUR/BEN - escolhe quem paga por serviços de correspondência.

3) Mensagens e formatos: MT ⇄ ISO 20022 (MX)

MT103 (customer credit transfer), MT202 COV (revestimento), MT199/999 (free-forma), MT192/195 (levantamento/pare).
ISO 20022 (MX): pacs. 008 (credit transfer), pacs. 009 (FI-to-FI), pacs. 004 (return), camt. 052/053/054 (extratos/posting).
A mudança para a ISO é feita em muitos bancos; mantenha a dupla compatibilidade (MT entrada/saída ↔ modelo canônico no seu núcleo).

4) SWIFT gpi и UETR

gpi (Global Payments Inovation) adiciona UETR de passagem (UUID) e SLAs no tempo; dá os estados received/credited/on-hold.
Você usa o rastreador UETR no portal do banco/PSP ou por API, mostra ao jogador/parceiro os motivos compreensíveis do ETA e os atrasos.
Vincule 'payment _ id ↔ UETR ↔ provider _ ref' para dashboards e reconsilização.

5) Prazos, cut-off e calendários

Cut-off nos correspondentes/enviadores → chegou a cut-off - chance de T + 0/T + 1, senão T + 1/T + 2.
Fatores NÃO-STP: verificações manuais, nome/endereço não correspondente, BIC/IBAN nefasto, desencadeador de sanções, moeda exótica.
Leve em conta os feriados de ambos os países e a moeda → mantenha o calendário (TARGET2/US/local).

6) Comissões e FX: qual valor é dobrado

Model: `Cost per Approved (SWIFT) = bank_fee + correspondent_fee(s) + gpi_fee (если есть) + FX_margin + ops_cost (investigations/R-возвраты)`.

• SHA - Cada parte paga ao seu banco (default).
• OUR - você cobre todas as comissões, o beneficiário recebe exatamente o valor (mais caro).
• BEN - o beneficiário paga tudo (raramente adequado para B2C).
• Margem FX: fontes de cotação, spread, cut-time; fixa o curso/hora (quote id) para contabilidade e controvérsia.

7) Complaens: sanções, KYC/KYB, EDD

Sanções/PEP/adverse: screening do remetente/beneficiário/banco intermediário; correspondências pelo nome/endereço/país → hold/EDD.
End-use/SoF/SoW: solicitações de destinação de pagamento (invoice/contrato) e de origem de fundos de desencadeamento (valor/geo/pattern).
Limites RBA/velocity: caps per-tx/per-day, novos adereços → reforço da verificação.
Os dados do pagamento (remittance informa) devem ser exatos: destino, número do contrato, fatura.

8) Validações de adereços e qualidade STP

BAN/Luhn/MOD97, BIC validação, endereço do destinatário (cidade/país), purpose codes (onde necessário).
Name Check/Confirmation of Payee-equivalente - se disponível no banco/PSP.
Whitelist adereços de parceiros com TTL e revalidação.
Regra STP: Quanto mais completos forem os campos, menores serão os controles manuais e os retornos.

9) Recusos, devoluções e investigações (investigações)

• Reject antes do envio/aceitação (as validações não foram concluídas).
• Return após receber (verificações tardias, conta encerrada, sanções/EDD) - ISO pacs. 004 ou MT Return.
• Recall/Stop & Recall: pedido de cancelamento do pagamento (não garantido).
• Investimentos: correspondência MT199/999/MX camt/case, portal gpi.
• Prática: guarde códigos de causa/texto, SLA de processamento, modelos de e-mail.

10) Fluxos no produto (arbitragem)

10. 1 Inbound (recebimento de fundos)

1. Forneça adereços: BIC/IBAN/benfiquiary name/address, às vezes intermediary BIC.
2. Cliente/sócio envia MT103/pacs. 008 → o seu banco.
3. Webhook/alta (camt. 053/MT940) → inscrição no saldo, mapping por 'EndToEndId/UETR/Remit'.
4. CUE/KUS/sanções - pós-controle e, se necessário, recall/return.

10. 2 Outbound (pagamentos)

1. Pedido de verificação RBA/sanções, validação de adereços, escolha SHA/OUR/BEN e moeda/FX.
2. Enviar via API/banco-cliente → receber UETRO.
3. Monitoramento gpi, estatais, comunicação ETA, processamento return/investigation.
4. Reconsilização T + 0/T + 1 por extrato.

11) Lager, extratos e reconsilação

Identificadores: 'payment _ id ↔ UETR ↔ bank _ ref ↔ EndToEndId/RemittanceInfo'.
Extratos ISO camt. 052/053/054 ou MT MT940/942; parsing comissões/divisas/datas de câmbio.
T + 0/T + 1-combinação: somas, FX, comissões, «penduricalhos» (unmatched lines) → fila de investigações.
Relatórios/auditorias: logs imutáveis, origem do curso FX, versões dos dados contábeis.

12) Orquestra, feelover e SLA

Multi-bank/multi-PSP para moedas-chave; correspondentes de reserva.
Regras de rotação: por moeda, país, tamanho, banco SLA, valor (fee + FX).
Cut-off-aware planejador (considerando feriados).
Guias de referência SLA - ≤ T + 1, EDD manual - ≤ T + 2-T + 3; as atualizações de status gpi são near-real-time.

13) UX e comunicações

Transparência ETA e explicação de fatores (banco/país/moeda, cut-off, OUR/SHA).
Mostre o link UETR/status no gabinete do sócio/VIP.
Campos claros para adereços, dicas sobre o formato do endereço/IBAN/BIC, avisos de OUR‐komissiyakh.
Modelos de resposta return/recall/investigation.

14) Métricas e OKR

Success/Approval Rate SWIFT, доля STP.
Time-to-Funds/Time-to-Payout p50/p95.
gpi visibility% (proporção de pagamentos com rastreamento relevante).
Return/Recall/Investigation rate, tempo médio de investigação.
Costa per Approved (fee + FX + ops), FX-spread em b.p.
Falsa-positivo da complacência, parte das malas manuais.

15) Anti-pattern

Um banco/correspondente para a moeda → SPOF.
Adereços incompletos (endereço/nome/destino) → verificações manuais e Return.
Ignorar cut-off/feriado, falta de planeador.
Taxa de câmbio/hora → disputas FX.
Mix de logs PII e pagamentos sem torneamento/RBAC.
Não há mapping 'payment _ id ↔ UETR' → faixas «perdidas» e caos na safra.

16) Folha de cheque de implementação (curta)

• Contas e linhas de correspondência para as moedas de destino; 2 + bancos parceiros.
• Modelo canônico MT/ISO 20022 no núcleo; parsers camt. 052/053/054 e MT940/942.
• Integração gpi/UETR, dashboards de estatais, notificações.
• Validação IBAN/BIC, endereços; whitelist adereços; ESCOLHA SHA/OUR/BEN.
• Políticas FX: origem da cotação, fixação, limites de spread, diário.
• Sanções/KYC/KYB/RBA/EDD; modelos de documentos e gerenciamento de mala.
• Orquestra por cut-off e feriados; rotação de custo/SLA.
• Lager e T + 0/T + 1-reconsilização; Fila unmatched; relatórios.
• Playbooks return/recall/investigation; signed webhooks, idempotidade.
• Treinamento de safort: estatais gpi, códigos de causa, comunicações FX/comissões.

17) Resumos

O SWIFT é uma «artilharia pesada» para pagamentos internacionais de iGaming. Construa um circuito multi-banco com gpi/UETR, mantenha a contabilidade FX e comissão rigorosa, cumpra sanções/EDD, automatize T + 1-reconsilamento e mostre aos clientes a transparência ETA e estatais. Então, mesmo os pagamentos em cruzado complexos serão previsíveis, adequados e administrados economicamente.