US RTP: real-time payments

1) What is RTP and where iGaming needs it

• instant payments (cash-out/withdrawals) to players and affiliates,
• fast B2B transfers (limited by bank policies),
• "crediting in seconds" without chargebacks like cards.

Key differences from ASN/cards

Only credit push (initiator pays), without debits → lower the risk of "unauthorized write-offs."

Final finalization: No classic chargebacks; returns - through separate consent scenarios.
ISO 20022 messages, real-time statuses.

2) Networks and coverage

• RTP® Network (The Clearing House) is historically the first large-scale RTGS 24/7/365.
• FedNow℠ (Federal Reserve) - the second rail with comparable logic of "instant" credit transfers.

• check the availability of RTP/FedNow by beneficiary,
• switch to alternative (ACH Same Day, card push) when unavailable.

3) Messages and functions

Credit Transfer - instant transfer "schet→schet" (routing & account).
Request-for-Payment (RfP) - request for payment: convenient for deposits "with the initiative of the merchant" (the user confirms in his bank).
Advice/Status - accepted/posted/failed, reason codes.
Remittance/Invoice data - field for assigning payment and mapping to 'payment _ id'.

4) iGaming User Cases

4. 1 Payments (outbound)

VIP cashout in minutes: when RTP is available, the recipient has a real T0 with finalization.
Fallback logic: no RTP → try FedNow; → ACH Same Day/card push limits are not available/exceeded.

4. 2 Deposits (inbound)

Via RfP: generate an account, the client confirms in the bank's application → instant crediting.
RTP does not work through pull models (no debits) - use ACH/A2A for auto-debits, if necessary.

5) Finalization, cancellations and returns

Finality of calculation: after acceptance - funds are credited, there is no "chargeback."

Cancellation before posting - only if the recipient's bank has not yet accepted (narrowly).
Return after crediting - through a request to the beneficiary/his bank (Request for Return of Funds) or mutual settlement by a separate counter transaction. The decision is at the goodwill of the recipient/bank, without a guarantee.

Conclusion: you need pre-risk before sending (OFAC/KYC/velocity/negative lists), since it is much more difficult to "roll back" a payment than in ASN/cards.

6) Compliance and risk control

KYC/KYB of sender and beneficiary (by risk segment).
OFAC/sanctions - before dispatch.
RBA limits: per-tx/per-day by player, by device/bank/geo; velocity and behavioral signals (rapid in-out, new details).
Whitelist details (routing/account) with TTL and reverification.
Name-matching/CoP analogue (if available from the provider) reduces erroneous payments.

7) Integration and orchestration

7. 1 Payout flow (reference)

1. The player creates an output request.
2. Checks: KYC/OFAC/RBA/limits; routing/account validation.
3. Route solution: RTP? → FedNow? → ACH Same Day/Push-to-Card.
4. Sending Credit Transfer, accepting status (accepted/posted/failed).
5. Update in the lager, player notification, reconsilation.

7. 2 Deposit flow (RfP)

1. Generation of Request-for-Payment linked to 'payment _ id' and TTL.
2. The client confirms with his bank; you receive an enrollment notification.
3. 'payment _ id ↔ bank_ref ↔ end2end/trace'mapping, balance crediting, reconciliation.

7. 3 Fallback and idempotency

The'withdrawal _ id/payment _ id 'key is idempotent.
Backoff + jitter for status repeats; prohibition of double departure.
Auto-switch link when 'unsupported/limit/reach/unavailable'.

8) Lager and Reconsilation

Unique links: 'payment _ id/within _ id ↔ bank_msg_id ↔ end2end/UETR analogue (if issued)'.
Reconciliation T + 0/T + 1: statuses, amounts, provider commissions, unmatched lines → a separate queue.
Journals: version of rules/limits at the time of decision, signature of webhooks, status chain.

9) Economy and SLA

Cost: provider fee for RTP/FedNow + operating costs (support/incident analysis). Often cheaper than cards, more expensive than standard ACH.
SLA: real "instantaneous" (seconds) when rail is available; ETA communication in UI is mandatory.
"Cost per Approved" approach: count all-in (fee + ops + fallback share), not just the rate per transaction.

10) UX patterns

Show "Instant Payout" only if details pass RTP/FedNow; otherwise - "Until the end of the day (Same Day ACH)."

Verification of details before sending; understandable errors and format hints.
Transparent ETAs and possible fallback, push enrollment notifications.

For RfP: timer TTL, button "Send again," statuses "waiting for confirmation → credited."

11) Metrics and OKR

Share RTP/FedNow in payouts and its impact on Time-to-Payout p50/p95.
Success Rate RTP/FedNow, fallback rate и причины (no-participant/limit/unavailable).
Cost per Approved by Channel, Savings vs Card.
False-positive compliance, share of manual cases.
Uptime/latency of the provider, delays in webhooks/statuses.

12) Anti-patterns

Sending RTP without OFAC/KYC/velocity control (cannot be "returned").
Lack of fallback routes and idempotency (duplicates or payment failures).
No whitelisting/reverification of details - an increase in errors and fraud.
Opaque ETA/commissions → tickets and mistrust.
One provider/one bank per market → SPOF.

13) Implementation checklist (short)

• RTP + FedNow contracts/provider, statuses and signed webhooks.
• RBA limits per-tx/per-day, OFAC/KYC, velocity; whitelist props with TTL.
• Routing: RTP → FedNow → ACH Same Day/Push-to-Card; idempotency.
• RfP support for deposits; TTL and 'payment _ id' mapping.
• Lager and T + 0/T + 1 reconsilation; unmatched/incident queue.
• Дашборды: Success/Share, Time-to-Payout, fallback-rate, cost-per-approved, uptime.
• UX: verification of details, clear ETA/statuses, notifications.
• Playbooks: rail inaccessibility, exceeding limits, return of free will.

14) Summary

US RTP is the perfect rail for instant and final payouts in iGaming. Build a two-rail scheme (RTP + FedNow) with smart routing and strict pre-risk, add RfP for quick deposits, keep a lager/reconvolution and transparent UX. This way you get seconds before enrollment, predictable transactions and a controlled cost.