SEPA Credit Transfer/Instant

1) Що таке SCT і SCT Inst - і чому це важливо iGaming

SCT (SEPA Credit Transfer) - кредитовий переказ в євро між банками в зоні SEPA з розрахунком зазвичай T + 0/T + 1 (залежить від cut-off).
SCT Inst (SEPA Instant) - миттєвий переказ 24/7/365 з цільовим зарахуванням протягом секунд (обмеження щодо суми та участі банку - у конкретного банку/провайдера).

Переваги для iGaming: низька вартість, відсутність класичних чарджбеків, висока довіреність у регуляторів, передбачуваний сеттлмент і зручні масові виплати.

2) Варіанти використання

2. 1 Депозити (inbound)

Пулові IBAN (віртуальні референси) або віртуальні IBAN на клієнта/інвойс.
Для SCT Inst - максимально швидкий «квазі-моментальний» онбординг коштів.
Призначення платежу (remittance information) → мепінг до'payment _ id'.

2. 2 Висновки/виплати (outbound)

Масові виплати через SCT (батчі) або миттєві кешаути через SCT Inst.
Плейбук: якщо банк одержувача не підтримує Inst - авто-фолбек на звичайний SCT.

3) Архітектура інтеграції (референс)

• Banking/PSP Layer: рахунок (а) в ЄС, підтримка SCT/SCT Inst, вебхуки/файли виписок.
• Payments Core: оркестрація депозитів/виплат, статуси, ліміти.
• Risk & Compliance: санкційний скринінг платників/одержувачів, RBA/EDD.
• Accounting & Recon: лейджер, мепінг'payment _ id ↔ bank_ref/EndToEndId', звітність.
• Monitoring: ETA, відмовостійкість, алерти за R-кодами/поверненнями.

• IBAN/вірт. посилання видане → клієнт ініціює платіж у своєму банку → SCT/SCT Inst → вебхук/виписка → зарахування в балансі гравця → реконсиляція.

• Заявка на виведення → перевірки (RBA/санкції/IBAN-валідація) → SCT Inst (якщо доступно) або SCT → статуси/референси → повідомлення гравцеві → реконсиляція.

4) Терміни, cut-off і ETA

SCT: надходження T + 0/T + 1, залежить від часу відправки і cut-off банку; можливі «банківські години/дні».
SCT Inst: цільовий real-time, 24/7; якщо банк одержувача не в мережі Inst або перевищено ліміт - переказ може бути відхилений/переведений в звичайний SCT (за правилами конкретного провайдера/банку).

Практика UX: показуйте динамічний ETA і пояснюйте, що Inst доступний не у всіх банків/сум.

5) Верифікація реквізитів

IBAN: перевірка довжини/формату/контрольної суми (MOD97).
BIC (де потрібен) і банківські каталоги для маршрутизації.
Name Check/Confirmation of Payee-аналог (якщо доступно у вашого банку/PSP): порівняння імені одержувача з IBAN знижує помилки і R-коди.
Beneficiary lock: whitelist раніше перевірених реквізитів з TTL і лімітами.

6) Повернення і R-коди (діагностика)

• Неправильний IBAN/не знайдено рахунок - Reject до зарахування.
• Ліміти/обмеження по Inst - відхилення SCT Inst або фолбек.
• Блокування комплаєнсу у банку-одержувача - Return/Recall після доп.перевірки.
• Недоступність банку одержувача - технічний Reject.

Операції: логуйте R-код, текст причини і час; запускайте авто-воркфлоу (повторна перевірка IBAN/імені, запит уточнень у клієнта, ескалація в комплаєнс).

7) Комплаєнс і ризик-контроль

KYC/KYB: рівні для гравців/партнерів по RBA; лівнес, PoA/SoF для великих сум або аномалій.
Санкційний скринінг відправника/одержувача (ім'я, адреса, країна; для юросіб - найменування/реєстр. дані).
RBA-ліміти: per-tx/per-day caps, velocity по IBAN/одержувачу/пристрою.
Red flags: rapid in-out (швидка перевага), зміна IBAN, дроблення, збіги по adverse media.
Документообіг: зберігання підтверджуючих даних/згоди в рамках вимог юрисдикції.

8) Економіка і комісії

• тариф банку/PSP за SCT/SCT Inst (пер-транзакція/пакет/об'ємна знижка);
• можливі fee за виписки/вебхуки/файли;
• операційні: обробка R-кодів/ручні кейси/саппорт;
• FX - тільки при крос-конверсіях поза євро (для SEPA зазвичай EUR→EUR).

Метрика: вважайте all-in і Time-to-Funds (до появи грошей на вашому рахунку/у клієнта), а не тільки «прайс за переказ».

9) Лейджер і реконсиляція

Унікальні ідентифікатори: використовуйте'EndToEndId '/' RemittanceInfo'для мепінгу'payment _ id ↔ bank_ref'.
Лейджер-таблиці: `payments`, `payouts`, `bank_statements`, `recon_lines`.
Авто-реконсиляція T + 0/T + 1: суми, комісії, статуси, непорівнянні рядки («вісяки») - в окрему чергу.
Звітність: вивантаження по юрисдикціях, журнал коригувань, незмінні логи.

10) Оркестрація маршрутів і фейловер

Правила вибору: якщо банк одержувача/сума підтримують Inst → SCT Inst; інакше - SCT.
Фолбек-логіка: недоступний Inst/висока відмова - авто-перемикання; інформування ETA в UI.
Ідемпотентність/анти-дублі: ключ `payment_id/withdrawal_id`; ретраї з backoff + jitter.
Подвійний провайдер/рахунки в різних банках на ключових ринках → відмовостійкість.

11) UX-патерни (конверсія і довіра)

Чітко показуйте метод (SCT/SCT Inst), ETA і комісії до підтвердження.
Перевірка IBAN/імені перед відправкою (і підказки формату).
Реал-тайм статуси: «створено → відправлено до банку → зараховано/відмову/повернення».
Для депозитів: віртуальні IBAN/референси, QR/копіювання, інструкції з призначення платежу.

12) Метрики та OKR

Approval/Success Rate по SCT/SCT Inst.
Time-to-Funds (in) / Time-to-Payout (out) p50/p95.
Частка Inst в потоках і її вплив на конверсію.
R-codes rate (за типами і банкам), час дозволу кейсів.
Вартість схвалення (all-in), вартість ручного кейса.
Uptime по провайдеру/банку, затримки вебхуків/виписок.

13) Анти-патерни

Один банк/один провайдер без резерву (SPOF).
Відсутність валідації IBAN/імені одержувача.
Непрозорі ETA і комісії - сплеск тікетів/відмін.
Немає ідемпотентності - дублі списань/виплат.
Ігнор R-кодів і «висять» рядків виписок - розриви в обліку.
Змішування PII і платіжних логів без токенізації/доступів.

14) Чек-лист впровадження (коротко)

• Рахунок (а) в EC/PSP з підтримкою SCT + SCT Inst, підписані вебхуки і файли виписок.
• Віртуальні IBAN/референси на інвойс/клієнта; мепінг'payment _ id ↔ EndToEndId'.
• Валідація IBAN/BIC і (де є) Name Check; whitelist реквізитів з TTL.
• RBA-ліміти, санкції/PEP/adverse, правила EDD/SoF.
• Маршрутизація Inst→SCT і фолбек, ідемпотентність, ретраї.
• Лейджер/реконсиляція T + 0/T + 1, обробка «вісяків», звіти.
• Два банківських партнера/каналу, плейбук деградацій і інцидентів.
• UX: ЕТА/комісії/статуси в реальному часі, інструкції з призначення платежу.
• Метрики/дашборди: AR, Time-to-Funds, R-codes, вартість.
• Навчання саппорту: причина R-кодів, шаблони відповідей, терміни.

15) Резюме

SCT/SCT Inst - це «робоча конячка» для євро-платежів в iGaming: дешево, передбачувано і комплаєнс-доброзичливо. Побудуйте подвійний контур (Inst + стандартний SCT), додайте валідації IBAN/імені і чіткий лейджер, автоматизуйте реконсиляцію і обробку R-кодів, а в UX прозоро показуйте ETA і комісії. Так ви отримаєте високу конверсію, швидкі виплати та стійкі операційні показники на ринках ЄС.