SWIFT and international transfers

1) When and why SWIFT in iGaming

• there is no local rail (SEPA/FPS/ACH) or a B2B payment to another jurisdiction is required;
• need payments to partners/affiliates, tax payments, large liquidity buybacks (off-ramp → fiat);
• requires a currency that does not exist in local schemas.
• Pros: global coverage, high predictability at gpi. Cons: cost (fee + FX), terms (T + 0-T + 3), compliance friction.

2) Basic mechanics: correspondent banks and routing

Beneficiary BIC → receiving bank. If there is no direct relationship, the payment goes through correspondents (nostro/vostro).

• Serial (MT103/ISO pacs. 008 goes sequentially bank→korr→bank).
• Cover (separate payment and coverage through COV/pacs MT202. 009).
• Data for the route: beneficiary bank BIC, IBAN/account, address/name, sometimes intermediate bank (BIC).
• Commissions: SHA/OUR/BEN - choose who pays for correspondent services.

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

MT103 (customer credit transfer), MT202 COV (coverage), MT199/999 (free-form), MT192/195 (feedback/stop).
ISO 20022 (MX): pacs. 008 (credit transfer), pacs. 009 (FI-to-FI), pacs. 004 (return), camt. 052/053/054 (statements/postings).
The transition to ISO is underway at many banks; keep dual compatibility (MT in/out ↔ canonical model in your core).

4) SWIFT gpi и UETR

gpi (Global Payments Innovation) adds end-to-end UETR (UUID) and SLAs in time; gives the received/credited/on-hold statuses.
You use the UETR tracker in the bank/PSP portal or via the API, show the player/partner understandable ETA and the reasons for the delays.
Bind 'payment _ id ↔ UETR ↔ provider_ref' for dashboards and reconcilations.

5) Deadlines, cut-offs and calendars

The sending/correspondents cut-off → got to cut-off - a chance at T + 0/T + 1, otherwise T + 1/T + 2.
Non-STP factors: manual checks, name/address mismatch, invalid BIC/IBAN, sanctions trigger, exotic currency.
Take into account the holidays of both countries and currencies → keep the calendar (TARGET2/US/local).

6) Fees and FX: what makes up the cost

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

• SHA - Each party pays its bank (default).
• OUR - you cover all fees, the beneficiary receives exactly the amount (more expensive).
• BEN - beneficiary pays everything (rarely suitable for B2C).
• FX margin: quotation sources, spread, cut-time; Fix the rate/time (quote id) for accounting and disputes.

7) Compliance: Sanctions, KYC/KYB, EDD

Sanctions/PEP/adverse: screening of sender/beneficiary/intermediary banks; name/address/country matches → hold/EDD.
End-use/SoF/SoW: requests for payment purpose (invoice/contract) and source of funds for triggers (amount/geo/patterns).
RBA-limits/velocity: caps per-tx/per-day, new details → increased verification.
Payment data (remittance information) must be accurate: purpose, contract number, invoice.

8) Details validation and STP-quality

IBAN/Luhn/MOD97, BIC validation, recipient address (city/country), purpose codes (where required).
Name Check/Confirmation of Payee analogue - if available from the bank/PSP.
Whitelist details of partners with TTL and reverification.
STP rule: The more complete the field, the fewer manual checks and returns.

9) Refusals, returns and investigations (investigations)

• Reject before submission/acceptance (validation failed).
• Return after admission (late checks, account closed, sanctions/EDD) - ISO pacs. 004 or MT Return.
• Recall/Stop & Recall - Request for payment recall (not guaranteed).
• Investigations: correspondence via MT199/999/MX camt/case, gpi-portal.
• Practice: store reason codes/texts, SLAs for processing, letter templates.

10) Flows in the product (reference)

10. 1 Inbound (receiving funds)

1. Give details: BIC/IBAN/beneficial name/address, sometimes intermediate BIC.
2. The customer/partner sends the MT103/pacs. 008 → your bank.
3. Webhook/extract (camt. 053/MT940) → credit to balance, mapping to'EndToEndId/UETR/Remit '.
4. BCL/CCL/sanctions - post-control and, if necessary, recall/return.

10. 2 Outbound (payouts)

1. Application → RBA checks/sanctions, validation of details, selection of SHA/OUR/BEN and currency/FX.
2. Send via API/client bank → receive UETR.
3. gpi monitoring, statuses, ETA communication, return/investigation processing.
4. T + 0/T + 1 on discharge.

11) Lager, statements and reconsilation

Identifiers: 'payment _ id ↔ UETR ↔ bank_ref ↔ EndToEndId/RemittanceInfo'.
Extracts: ISO camt. 052/053/054 or MT MT940/942; parsing fees/currency/value date.
T + 0/T + 1-reconciliation: amounts, FX, commissions, "hanging" (unmatched lines) → investigation queue.
Reporting/audit: unchangeable logs, source of FX course, versions of counterparty data.

12) Orchestration, Feilover and SLA

Multi-bank/multi-PSP for key currencies; backup correspondents.
Routing rules: by currency, country, size, bank SLA, cost (fee + FX).
Cut-off-aware scheduler (including holidays).
SLA landmarks: auto cases - ≤ T + 1, manual EDD - ≤ T + 2-T + 3; gpi-status updates - near-real-time.

13) UX and Communications

Transparent ETAs and explanation of factors (bank/country/currency, cut-off, OUR/SHA).
Show the UETR link/status in the partner/VIP office.
Clear fields for entering details, hints on the address format/IBAN/BIC, OUR‐komissiyakh warnings.
Response templates by return/recall/investigation.

14) Metrics and OKR

Success/Approval Rate SWIFT, доля STP.
Time-to-Funds/Time-to-Payout p50/p95.
gpi visibility% (share of payments with current tracking).
Return/Recall/Investigation rate.

Cost per Approved (fee + FX + ops), FX spread in bp

False-positive compliance, share of manual cases.

15) Anti-patterns

One bank/correspondent per currency → SPOF.
Incomplete details (address/name/purpose) → manual checks and Return.
Ignore cut-off/holidays, no scheduler.
Unfix quotation rate/time → FX disputes.
MIX of PII logs and payments without tokenization/RBAC.
No 'payment _ id ↔ UETR' mapping → "lost" tracks and support chaos.

16) Implementation checklist (short)

• Accounts and correspondent lines by target currencies; 2 + partner banks.
• Canonical model MT/ISO 20022 in the kernel; camt parsers. 052/053/054 and MT940/942.
• gpi/UETR integration, status dashboards, notifications.
• IBAN/BIC validation, addresses; whitelist details; SHA/OUR/BEN selection.
• FX policies: quotation source, fixing, spread limits, journal.
• Sanctions/KYC/KYB/RBA/EDD; document templates and case management.
• Orchestration by cut-off and holidays; cost routing/SLA.
• Lager and T + 0/T + 1-reconcilation; unmatched queue; reports.
• Playbooks return/recall/investigation; signed webhooks, idempotency.
• Support training: gpi statuses, reason codes, FX/commission communications.

17) Summary

SWIFT - "heavy artillery" for international payments iGaming. Build a multi-bank circuit with gpi/UETR, keep strict FX and commission accounting, comply with sanctions/EDD, automate T + 1 reconstitution and show customers transparent ETA and statuses. Even complex cross-border payments would then be predictable, compliant and economically manageable.