SEPA Credit Transfer/Instant

1) What SCT and SCT Inst are - and why it matters iGaming

SCT (SEPA Credit Transfer) - credit transfer in euros between banks in the SEPA zone with the calculation usually T + 0/T + 1 (depends on cut-off).
SCT Inst (SEPA Instant) - instant transfer 24/7/365 with targeted crediting within seconds (restrictions on the amount and participation of the bank - from a specific bank/provider).

Advantages for iGaming: low cost, lack of classic chargebacks, high power of attorney with regulators, predictable settlement and convenient mass payments.

2) Use cases

2. 1 Deposits (inbound)

Pool IBANs (virtual references) or virtual IBANs per customer/invoice.
For SCT Inst - the fastest "quasi-instant" onboarding of funds.
Remittance information → mapping to 'payment _ id'.

2. 2 Conclusions/payments (outbound)

Mass payments via SCT (batches) or instant cashouts via SCT Inst.
Playbook: if the recipient's bank does not support Inst, auto-folback to regular SCT.

3) Integration architecture (reference)

• Banking/PSP Layer: EU account (s), SCT/SCT Inst support, webhooks/statement files.
• Payments Core: orchestration of deposits/payments, statuses, limits.
• Risk & Compliance: Sanctioned Payer/Recipient Screening, RBA/EDD.
• Accounting & Recon: lager, mapping 'payment _ id ↔ bank_ref/EndToEndId', reporting.
• Monitoring: ETA, fault tolerance, R-code/return alerts.

• IBAN/wirth. link is issued → the client initiates a payment at his bank → SCT/SCT Inst → webhook/statement → credit in the player's balance → reconciliation.

• Request for withdrawal → verification (RBA/sanctions/IBAN validation) → SCT Inst (if available) or SCT → statuses/references → notification to the player → reconstitution.

4) Timing, cut-off and ETA

SCT: receipt T + 0/T + 1, depends on the sending time and cut-off of the bank; "bank hours/days" are possible.
SCT Inst: target real-time, 24/7; if the recipient's bank is not in the Inst network or the limit is exceeded, the transfer can be rejected/transferred to a regular SCT (according to the rules of a specific provider/bank).

UX Practice: Show dynamic ETA and explain that Inst is not available from all banks/amounts.

5) Verification of details

IBAN: length/format/checksum check (MOD97).
BIC (where needed) and bank directories for routing.
Name Check/Confirmation of Payee analogue (if available from your bank/PSP): comparing the recipient's name with IBAN reduces errors and R-codes.
Beneficial lock: whitelist previously verified details with TTL and limits.

6) Returns and R-codes (diagnostics)

• Invalid IBAN/no account found - Reject before enrollment.
• Inst Limits/Limits - Inst SCT Deviation or Folback.
• Compliance locks at the receiving bank - Return/Recall after additional verification.
• The unavailability of the recipient's bank is a technical Reject.

Operations: log the R-code, reason text and time; Run the auto-workflow (re-check IBAN/name, request clarification from the customer, escalate to compliance).

7) Compliance and risk control

KYC/KYB: levels for RBA players/partners; livnes, PoA/SoF for large amounts or anomalies.
Sanction screening of the sender/recipient (name, address, country; for legal entities - name/reg. data).
RBA limits: per-tx/per-day caps, velocity by IBAN/recipient/device.
Red flags: rapid in-out, IBAN change, split, adverse media matches.
Document flow: storage of supporting data/consents within the requirements of the jurisdiction.

8) Economics and commissions

• Bank/PSP rate for SCT/SCT Inst (per-transaction/batch/volume discount)
• possible fee for extracts/webhooks/files;
• operational: processing R-codes/manual cases/support;
• FX - only for cross conversions outside the euro (usually EUR→EUR for SEPA).

Metric: Count all-in and Time-to-Funds (before money appears in your account/customer), not just "transfer price."

9) Lager and Reconsilation

Unique identifiers: Use 'EndToEndId '/' RemittanceInfo' to map 'payment _ id ↔ bank_ref'.
Ledger tables: 'payments', 'payments', 'bank _ statements', 'recon _ lines'.
Auto-reconciliation T + 0/T + 1: amounts, commissions, statuses, unmapped lines ("hangs") - in a separate queue.
Reporting: downloads by jurisdiction, adjustment log, immutable logs.

10) Route orchestration and feilover

Selection rules: if the recipient bank/amount supports Inst → SCT Inst; otherwise - SCT.
Folback logic: Inst unavailable/high fault - auto-switch; informing the ETA in the UI.
Idempotence/anti-duplicates: key 'payment _ id/within _ id'; retrai with backoff + jitter.
Dual provider/accounts in different banks in key markets → fault tolerance.

11) UX patterns (conversion and trust)

Clearly show method (SCT/SCT Inst), ETA and fees prior to confirmation.
Check IBAN/name before sending (and format hints).

Real-time statuses: "created → sent to the bank → credited/refused/returned."

For deposits: virtual IBAN/references, QR/copying, instructions for making a payment.

12) Metrics and OKR

Approval/Success Rate по SCT/SCT Inst.
Time-to-Funds (in) / Time-to-Payout (out) p50/p95.
Inst's share of flows and its impact on conversion.
R-codes rate (by type and bank), case resolution time.
Cost of approval (all-in), cost of a manual case.
Uptime by provider/bank, delays in webhooks/statements.

13) Anti-patterns

One bank/one provider without reserve (SPOF).
No IBAN/recipient name validation.
Opaque ETAs and commissions - spike in tickets/cancellations.
No idempotency - duplicate write-offs/payments.
Ignoring R-codes and "hanging" statement lines - accounting gaps.
Mixing PII and payment logs without tokenization/access.

14) Implementation checklist (short)

• EC/PSP account (s) with SCT + SCT Inst support, signed webhooks and statement files.
• Virtual IBANs/invoice/customer references; 'payment _ id ↔ EndToEndId'mapping.
• Validation of IBAN/BIC and (where available) Name Check; whitelist props with TTL.
• RBA limits, sanctions/PEP/adverse, EDD/SoF rules.
• Inst→SCT routing and folback, idempotency, retrai.
• Lager/T + 0/T + 1 Reconstitution, Hangs Processing, Reports.
• Two banking partners/channels, degradation and incident playbook.
• UX: ETA/Fees/Real Time Statuses, Payment Instructions.
• Metrics/dashboards: AR, Time-to-Funds, R-codes, cost.
• Support training: reason for R-codes, response templates, deadlines.

15) Summary

SCT/SCT Inst is the workhorse for euro payments in iGaming: cheap, predictable and compliance-friendly. Build a double loop (Inst + standard SCT), add IBAN/name validations and a clear lager, automate the reconciliation and processing of R-codes, and in UX transparently show ETA and commissions. This way you get high conversion, fast payouts and sustainable operational performance in EU markets.