SWIFT et traductions internationales

1) Quand et pourquoi SWIFT dans iGaming

• il n'y a pas de rail local (SEPA/FPS/ACH) ou un paiement B2B vers une autre juridiction est requis ;
• les paiements aux partenaires/affiliés, les paiements fiscaux, les rachats importants de liquidités (off-ramp → fiat) ;
• nécessite une monnaie qui n'existe pas sur les circuits locaux.
• Avantages : couverture globale, haute prévisibilité sous gpi. Inconvénients : coût (fee + FX), délais (T + 0-T + 3), conformité-friction.

2) Mécanique de base : banques de correspondance et routage

Le BIC du bénéficiaire est → la banque bénéficiaire. S'il n'y a pas de relation directe, le paiement passe par les correspondants (nostro/vostro).

• Serial (MT103/ISO pacs. 008 va de pair bank→korr→bank).
• Cover (partage le paiement et la couverture via le MT202 COV/pacs. 009).
• Données pour l'itinéraire : Banque BIC du bénéficiaire, IBAN/compte, adresse/nom, parfois banque intermédiaire (BIC).
• Commissions : SHA/OUR/BEN - choisir qui paie pour les services de correspondant.

3) Messages et formats : MT ⇄ ISO 20022 (MX)

MT103 (transfert de crédit client), MT202 COV (couverture), MT199/999 (forme libre), MT192/195 (rappel/stop).
ISO 20022 (MX): pacs. 008 (credit transfer), pacs. 009 (FI-to-FI), pacs. 004 (return), camt. 052/053/054 (extraits/posters).
Le passage à l'ISO est en cours dans de nombreuses banques ; conserver une double compatibilité (entrée/sortie MT ↔ modèle canonique dans votre noyau).

4) SWIFT gpi и UETR

gpi (Global Payments Innovation) ajoute l'UETR de bout en bout (UUID) et les SLAs dans le temps ; donne les statuts received/credited/on-hold.
Vous utilisez un tracker UETR dans le portail bancaire/PSP ou par API, vous montrez au joueur/partenaire un ETA compréhensible et les causes des retards.
Liez 'payment _ id ↔ UETR ↔ provider_ref' pour les dashboards et la reconsilation.

5) Délais, coupures et calendriers

Cut-off chez l'expéditeur/correspondant → est arrivé à cut-off - chance sur T + 0/T + 1, sinon T + 1/T + 2.
Facteurs non STP : contrôles manuels, non-correspondance nom/adresse, BIC/IBAN non validé, déclencheur de sanctions, monnaie exotique.
Tenez compte des jours fériés des deux pays et des devises, → tenez un calendrier (TARGET2/US/local).

6) Commissions et FX : à partir de quoi le coût

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

• SHA - chaque partie paie sa propre banque (défaut).
• OUR - vous couvrez toutes les commissions, le bénéficiaire reçoit exactement le montant (plus cher).
• BEN - le bénéficiaire paie tout (rarement adapté au B2C).
• Marge FX : sources de cotation, spread, cut-time ; fixer le cours/le temps (quote id) pour la comptabilité et les différends.

7) Conformité : sanctions, KYC/KYB, EDD

Sanctions/PEP/adverse : dépistage de l'expéditeur/bénéficiaire/banques intermédiaires ; coïncidences par nom/adresse/pays → hold/EDD.
End-use/SoF/SoW : demandes de destination de paiement (invoice/contrat) et de source de fonds dans les déclencheurs (montant/géo/modèles).
Limites RBA/velocity : caps per-tx/per-day, nouvelles informations → renforcement de la vérification.
Les données de paiement (remittance information) doivent être exactes : destination, numéro de contrat, facture.

8) Validation des détails et qualité STP

IBAN/Luhn/MOD97, BIC validation, adresse du destinataire (ville/pays), codes purpose (si nécessaire).
Nom Check/Confirmation de l'équivalent Payee - si disponible auprès de la banque/PSP.
Whitelist détails des partenaires avec TTL et revérification.
Règle STP : plus les champs sont complets, moins il y a d'inspections manuelles et de retours.

9) Refus, retours et enquêtes (enquêtes)

• Reject avant l'envoi/acceptation (aucune validation n'a été effectuée).
• Retour après réception (vérifications tardives, compte fermé, sanctions/EDD) - ISO pacs. 004 ou MT Return.
• Recall/Stop & Recall : demande de retrait de paiement (non garantie).
• Enquêtes : correspondance via MT199/999/MX camt/case, portail gpi.
• Pratique : stocker les codes de cause/texte, SLA sur le traitement, modèles de lettres.

10) Flux dans le produit (référence)

10. 1 Inbound (recevoir des fonds)

1. Vous donnez les détails : BIC/IBAN/beneficiary name/address, parfois intermediary BIC.
2. Le client/partenaire envoie le MT103/pacs. 008 → votre banque.
3. Webhook/extrait (camt. 053/MT940) → l'inscription au bilan, mapping par « EndToEndId/UETR/Remit ».
4. KWD/KUS/sanctions - post-contrôle et, si nécessaire, recall/return.

10. 2 Outbound (paiements)

1. La demande → les contrôles de la RBA/sanction, валидация des accessoires, le choix SHA/OUR/BEN et les devises/FX.
2. Envoyer via API/banque-client → recevoir l'UETR.
3. Suivi gpi, statuts, communication ETA, traitement de retour/investigation.
4. Reconsilation T + 0/T + 1 sur décharge.

11) Layer, extraits et reconsilation

Identifiants : 'payment _ id ↔ UETR ↔ bank_ref ↔ EndToEndId/RemittanceInfo'.
Extraits : ISO camt. 052/053/054 ou MT MT940/942 ; parsing commissions/devises/dates de valeur.
T + 0/T + 1-rapprochement : montants, FX, commissions, « pendentifs » (lignes non collées) → file d'enquête.
Reporting/audit : logs immuables, source du cours FX, versions des données des contreparties.

12) Orchestration, faussaire et SLA

Multi-banque/multi-PSP pour les devises clés ; correspondants de réserve.
Règles de routage : par devise, pays, taille, SLA de la banque, valeur (fee + FX).
Planificateur Cut-off-aware (sous réserve des vacances).
Points de référence SLA : Auto-case - ≤ T + 1, EDD manuel - ≤ T + 2-T + 3 ; gpi-mises à jour des statuts - near-real-time.

13) UX et communications

ETA transparent et explication des facteurs (banque/pays/monnaie, cut-off, OUR/SHA).
Montrez le lien UETR/statut dans le bureau partenaire/VIP.
Des champs clairs pour entrer les détails, des conseils sur le format d'adresse/IBAN/BIC, des alertes de OUR‐komissiyakh.
Modèles de réponse par retour/recall/investigation.

14) Métriques et OKR

Success/Approval Rate SWIFT, доля STP.
Time-to-Funds/Time-to-Payout p50/p95.
gpi visibility % (part des paiements avec suivi à jour).
Taux de retour/de récupération/d'enquête, temps moyen d'enquête.
Cost per Approved (fee + FX + ops), spread FX en p.p.
Complience fausse positive, proportion de cas manuels.

15) Anti-modèles

Une banque/correspondante par devise → SPOF.
Détails incomplets (adresse/nom/destination) → vérifications manuelles et Retour.
Ignorer cut-off/vacances, absence de planificateur.
Ne pas fixer le cours/le temps de cotation → les différends sur FX.
MIX des logs PII et des paiements sans tokenization/RBAC.
Pas de mapping 'payment _ id ↔ UETR' → pistes « perdues » et chaos dans le saphport.

16) Chèque de mise en œuvre (court)

• Comptes et lignes de correspondance en devises cibles ; 2 + banques partenaires.
• Modèle canonique MT/ISO 20022 dans le noyau ; parser camt. 052/053/054 et MT940/942.
• Intégration gpi/UETR, dashboards des statuts, notifications.
• Validation IBAN/BIC, adresses ; les détails whitelist ; sélection SHA/OUR/BEN.
• Politiques de FX : source de cotation, fixation, limites de propagation, magazine.
• Sanctions/KYC/KYB/RBA/EDD ; modèles de documents et gestion de cas.
• Orchestration par cut-off et vacances ; routage au coût/SLA.
• Layer et T + 0/T + 1-reconsilation ; File d'attente unmatched ; rapports.
• Pleybuki return/recall/investigation ; webhooks signés, idempotence.
• Formation Sapport : statuts gpi, codes de cause, communications sur FX/commissions.

17) Résumé

SWIFT - « artillerie lourde » pour les paiements internationaux iGaming. Construisez un circuit multi-banque avec gpi/UETR, gardez une comptabilité FX et des commissions strictes, respectez les sanctions/EDD, automatisez la reconsilation T + 1 et montrez aux clients des ETA et des statuts transparents. Alors même les paiements croisés complexes seront prévisibles, conformes et économiquement gérables.