Rain.xyz and the Stablecoin Payments Stack

Executive Summary

Rain.xyz is a stablecoin-native payments infrastructure provider focused on enabling card issuance and global money movement using stablecoins as a settlement and treasury layer, while presenting familiar payment surfaces (e.g., cards accepted on existing merchant networks). Rain positions itself as a “full stack” platform spanning card issuance, fiat↔stablecoin on/off-ramps, embedded wallets/accounts, compliance tooling, and cross-border money movement. citeturn17search2turn23view2turn17search18turn17search8

Rain publicly states it is a entity["company","Visa","payments network"] Principal Member and that Rain-issued cards can be used anywhere Visa is accepted (marketed as “more than 150 million merchants” and “over 150 countries”). citeturn23view2turn7view2turn11search2turn12view0

A central differentiator Rain claims is stablecoin-based settlement with Visa outside traditional banking windows. Rain announced it joined Visa’s pilot program for stablecoin settlement, transitioned settlement transactions for its Visa cards to USDC, and can “settle with Visa 7 days a week, 365 days a year.” citeturn25search0turn25search3 This maps to Visa’s broader strategy: Visa’s stablecoin settlement capabilities enable select issuer/acquirer partners to settle VisaNet obligations in stablecoins (e.g., USDC), with seven‑day availability and blockchain-based settlement rails. citeturn23view4turn25search10

Why this matters at infrastructure level: moving issuer/acquirer settlement from “banking-day windows” toward “7-day windows” can reduce prefunding/collateral and improve working capital timing—benefits Visa itself highlights for its stablecoin settlement framework. citeturn23view4turn25search10turn6view0 In a Visa case study, Visa reports USDC settlement reduced prefunding days and reduced FX fees (reported as 20–30 bps) for a stablecoin-settling card program, underscoring the treasury mechanics behind stablecoin settlement claims. citeturn6view0

Where Rain sits in the payments value chain (publicly evidenced): Rain acts as an issuing/program layer enabling partners to launch card programs and connect stablecoin balances to card and payout surfaces. Rain also emphasizes it is not a bank or custodian and that payment products are offered in partnership with licensed institutions. citeturn2view1turn23view2 In its Rain Spend corporate card terms, Rain discloses a specific issuing bank partner (entity["company","Third National Bank","us bank"]) for that product, reinforcing the “licensed partner” model even when Rain provides the program layer. citeturn3view0turn8search10

Key competitors span two clusters:

• “Stablecoin orchestration + compliance wrappers” (e.g., entity["company","Zero Hash","crypto infrastructure firm"], entity["company","BVNK","stablecoin payments firm"], entity["company","Fireblocks","digital asset infrastructure firm"]) with varying custody/regulatory footprints. citeturn24view5turn20search3turn19search12turn19search16turn24view4turn20search22
• “Large PSPs and networks integrating stablecoins” (e.g., entity["company","Stripe","payments company"]’s stablecoin payments, stablecoin financial accounts, and stablecoin issuance tooling via its Bridge acquisition; Visa’s own expanding stablecoin settlement and stablecoin-linked card initiatives). citeturn24view3turn18search9turn18search24turn18search1turn23view5turn23view4

Strategic risks (source-grounded triggers, not internal speculation):

• Network dependency concentration (Visa rules, settlement frameworks, card program compliance) is inherent to card-linked models. citeturn23view2turn22view0turn9search2
• Regulatory tightening around stablecoins and VASPs (e.g., AML/Travel Rule expectations) increases compliance burden and could constrain corridors, on/off-ramps, and counterparties. citeturn24view2
• Competitive compression as Visa expands stablecoin settlement (more partners, more chains, more stablecoins) and as Stripe productizes stablecoin acceptance, balances, and issuance—potentially commoditizing parts of Rain’s value proposition. citeturn23view4turn23view5turn18search9turn18search24turn18search1

[[PAGE BREAK]]

Traditional Card Rails Foundations

This section uses official regulatory and network/processor documentation to define roles, economics, risk allocation, and transaction flow—because the stablecoin-card stack is still anchored to these primitives at authorization, clearing, dispute, and merchant settlement layers.

Core parties and roles (four‑party model plus fintech program stack)
Merchant: accepts card payments and submits transactions for authorization and later clearing/settlement through an acquirer or its processor. The entity["organization","Office of the Comptroller of the Currency","us bank regulator"] describes the point-of-sale transaction data flowing merchant → acquirer/processor → card association network → issuer/processor during authorization. citeturn22view0

Acquirer (merchant’s bank / acquiring bank): provides merchant acquiring and routes authorization/clearing; later receives funds via settlement and pays merchants (often via ACH). OCC notes acquirers (or processors) collect merchant transaction data, transmit through the card association network, and later pay merchants under the merchant agreement; acquirers may also “pay select merchants before receiving funds,” increasing credit/liquidity exposure. citeturn22view0

Issuer (cardholder’s bank): approves/declines authorizations and posts transactions to the cardholder account after clearing; remits funds via the card association settlement process. OCC describes issuers receiving transaction data for posting and remitting funds (via Fedwire) for net settlement. citeturn22view0

Card network / card association: routes authorization and performs clearing and net settlement position calculation between issuers and acquirers. OCC explicitly describes the association role in the clearing/settlement chain and net positions. citeturn22view0

BIN / ICA and membership: OCC defines the Bank Identification Number / Interbank Card Association number as identifying the settling bank for acquiring/issuing, and describes “bank card associations” requiring membership rights/obligations under association rules. citeturn22view0

Processor (issuer processor / acquirer processor): entities directly connected to network rails providing authorization, clearing, settlement, and payment-related processing services. Visa’s developer glossary defines a “processor” this way, aligning with issuer processor roles in modern stacks. citeturn9search16

Program manager / BIN sponsor (fintech-era overlay)
In many fintech card programs, a program manager coordinates KYC/KYB, program operations, compliance processes, and integrations with issuing banks/BIN sponsorship and issuer processing. This role is often disclosed in card program legal agreements; e.g., a third-party card program agreement describes a “Program Manager” providing onboarding, settlement, and network connectivity for a card program (illustrating how these roles are contractually separated). citeturn8search11
Information not publicly available. Rain’s public site and press releases do not provide a comprehensive, global matrix of “issuer vs BIN sponsor vs program manager” roles by jurisdiction for all Rain-powered programs. Research attempted: Rain legal pages and public documentation, Rain API docs, and partner case studies; Rain API docs appear access-controlled and program terms vary by product and partner. citeturn2view4turn3view0turn2view5turn23view2

Interchange economics (what gets paid, to whom, and why it matters)
Interchange is generally paid by the acquirer to the issuer on purchase transactions, and is a primary component of what merchants pay to accept card payments. citeturn9search1turn9search3 Stripe (as a processor/acquirer-facing PSP) describes interchange as part of the transaction amount transferred from the acquiring bank to the issuing bank, compensating the issuer for its role and risk in guaranteeing payment. citeturn9search3 OCC adds operational detail: discount fees (merchant-facing) may be collected monthly, while interchange is collected daily at net settlement. citeturn22view0

Disputes and chargebacks (risk allocation and timelines)
OCC categorizes chargebacks as technical, clerical, quality, and fraud, and outlines the typical dispute path: cardholder disputes with issuer; issuer may post temporary credit; issuer requests documentation; if chargeback upheld, amount is charged back to the merchant’s account. OCC also notes a 60‑day period for a credit card consumer to report a dispute to the issuer (in the context of chargeback rights). citeturn22view0 Visa likewise frames dispute initiation as cardholder → issuer → merchant/acquirer evidence exchange. citeturn9search6turn9search2

Settlement timing, float mechanics, and who bears fraud risk (operational reality)
At the network level, OCC describes settlement as (i) transmitting sales information to issuers for collection and reimbursement and (ii) calculating/reporting net positions for cleared transactions; the issuer pays the association via Fedwire (instant transfers from Fed accounts), and the association’s settlement bank pays the acquirer via Fedwire. citeturn22view0 Merchant funding timing is governed by the acquiring bank–merchant agreement; acquirers often pay merchants by initiating ACH credits, and may delay settlement when fraud teams flag suspicious transactions. citeturn22view0 This creates the practical “float” and exposure: if acquirers pay merchants before receiving interchange settlement, the acquirer increases credit and liquidity exposure. citeturn22view0

Step-by-step traditional card transaction flow (authorization to settlement)
Below is a representative flow consistent with OCC’s regulator-grade description, with additional dispute handling grounded in Visa documentation.

1. Authorization initiation (point of sale / e-commerce): merchant captures card data + amount and transmits to acquiring bank or its processor. citeturn22view0
2. Network routing: acquirer/processor forwards authorization through the card association network to the issuer (or issuer processor). citeturn22view0
3. Issuer decision: issuer approves/declines based on account status/limits and fraud controls; decision transmits back via network to POS. citeturn22view0
4. Clearing: final transaction data is delivered from acquirer to issuer for posting, including fee calculations and currency conversion to settlement currencies. citeturn22view0
5. Settlement (issuer ↔ acquirer net positions): issuer remits funds through the association; OCC describes issuer payments via Fedwire to the association settlement bank, and funds flow issuer → association → acquirer → merchant. citeturn22view0
6. Merchant funding: acquirer pays the merchant, often via ACH, per merchant agreement terms; settlement may be delayed for fraud review. citeturn22view0
7. Dispute/chargeback (if triggered): cardholder disputes via issuer; issuer requests documentation; if upheld, the amount is charged back to the merchant’s account (merchant ultimately bears loss in upheld cases). citeturn22view0turn9search6turn9search2

[[PAGE BREAK]]

Stablecoin Settlement Architecture

This section describes documented stablecoin primitives (mint/redeem, reserves, compliance expectations) and then maps them into stablecoin-backed payment models—especially where stablecoins touch legacy rails (e.g., card settlement, fiat off-ramps, and treasury).

Stablecoin minting / redemption and reserve model (issuer level)
Stablecoins like USDC rely on issuance/redemption pathways and reserve backing disclosures to maintain parity. Circle documents USDC tokenization/redemption operationally as a flow where USD is sent to an issuer bank account, the issuer requests minting to the USDC smart contract, and redemption reverses this (burn + fiat return). citeturn10search0 Circle also states USDC and EURC are fully backed by highly liquid fiat reserves held separately from operating funds, and that reserve holdings and mint/burn flows are disclosed, with monthly third-party assurance aligned to AICPA attestation standards. citeturn24view1

On-chain settlement and “always-on” operating window (settlement layer)
Visa’s stablecoin settlement framework explicitly positions stablecoins as a settlement mechanism for VisaNet obligations, enabling faster funds movement over blockchains with seven-day availability and “no change to the consumer card experience.” citeturn23view4turn25search10 Visa further states its settlement support is expanding across additional stablecoins (e.g., USDG, PYUSD, EURC) and blockchains (e.g., Stellar, Avalanche alongside Ethereum and Solana), which matters because stablecoin settlement becomes a network feature rather than a bespoke one-off integration. citeturn23view5

Custody layer (who holds keys, who bears operational control)
Custody is frequently misunderstood in stablecoin payment stacks: the “wallet security provider” is not necessarily the regulated custodian. entity["company","Fireblocks","digital asset infrastructure firm"] explicitly distinguishes custody technology service providers from licensed custodians and states Fireblocks is “not a qualified cryptocurrency custodian” in the qualified custodian sense, while also describing operating models (direct custody/self-custody vs subcustody) and associated red flags. citeturn20search22turn20search2
This distinction matters for BD qualification because a stablecoin payments prospect may require a qualified custodian (or a regulated trust/bank custody arrangement) depending on jurisdiction, product, and customer asset-handling posture. citeturn20search22turn20search2

Compliance layers (AML/KYC/Travel Rule expectations)
The entity["organization","Financial Action Task Force","global aml standard-setter"] (FATF) updated guidance clarifies that countries should assess/mitigate risks for virtual asset activities, license/register providers, and apply AML/CFT measures to VASPs, including stablecoins and Travel Rule implementation. citeturn24view2
Many infrastructure providers productize this: Fireblocks states it embeds AML, KYC, and Travel Rule tooling into transaction flows, illustrating how compliance is operationalized in payment orchestration layers. citeturn24view4

Treasury management and liquidity provisioning (where stablecoins change the math)
Visa’s own stablecoin settlement narrative emphasizes treasury benefits: seven-day settlement windows, modernized liquidity and treasury management, and collateral reduction considerations for seven-day settling parties. citeturn23view4
A Visa-published case study of USDC settlement reports operational benefits (reduced prefunding days; reduced FX fees), framing stablecoin settlement as working-capital optimization, not only “faster payments.” citeturn6view0

Fiat on/off-ramp integration and cross-border mechanics (bridge between worlds)
The canonical “stablecoin payment” often still needs fiat interfaces—especially for payroll, merchant settlement, or cash-out. Rain’s money-in page markets fiat on-ramps (ACH, wire, SWIFT) converting local currencies to stablecoins, supporting payouts and earned wage access use cases. citeturn17search18turn12view0 Rain’s money-out page positions wallet-to-world transfers and local-currency off-ramps with 24/7/365 settlement claims. citeturn17search8turn12view0
Separately, Stripe documents a stablecoin remittance model where the sender converts local currency to a stablecoin and sends it over a blockchain network to a recipient wallet, who can hold/spend/cash out—explicitly noting 24/7 operation and reduced intermediary complexity. citeturn17search1turn24view3

Step-by-step stablecoin-backed card transaction flow (what can be documented vs what cannot)
A fully detailed “stablecoin-backed card” flow requires issuer-program specifics (ledgering, conversion timing, custody posture, settlement accounts). Across publicly available network and company documentation, the most defensible description is layered:

1. Cardholder experience: customer initiates a purchase with a network-branded card; consumer experience is unchanged even when issuer settlement uses stablecoins. citeturn23view4turn25search10
2. Merchant flow remains traditional: merchant still relies on the standard acquiring and network rails for authorization and merchant funding. This is implied by Visa’s framing (“no change to consumer card experience”) and by the regulator-defined clearing/settlement mechanics staying intact for merchants and acquirers. citeturn23view4turn22view0
3. Issuer ↔ network settlement can shift to stablecoins: for participating issuers/acquirers, Visa enables settlement of VisaNet obligations using stablecoins (e.g., USDC) over supported blockchains, enabling seven-day settlement. citeturn23view4turn25search10
4. Issuer treasury benefit: Visa highlights modernized liquidity management and collateral reduction considerations; Visa case study data illustrates reduced prefunding and FX improvement outcomes for stablecoin settlement. citeturn23view4turn6view0

Information not publicly available. Public sources do not provide a universal, issuer-agnostic specification for: (a) whether stablecoin-to-fiat conversion occurs at authorization vs clearing vs settlement, (b) how issuer processors represent stablecoin balances in ledgers, and (c) exact reconciliation schemas between on-chain settlement and network clearing files for every issuer/program. Research attempted: Visa public stablecoin settlement releases and case studies, Rain’s public pages, and third-party issuer processor case studies; the remaining details are product- and contract-specific. citeturn23view4turn25search0turn7view1turn23view2

[[PAGE BREAK]]

Rain.xyz Product and Operating Model

This section is restricted to what Rain, partners, networks, and regulators document publicly.

Product surface area (what Rain markets as the platform)
Rain positions as a full stack across:

• Cards: issuing branded cards (physical/virtual), Apple Pay/Google Pay support, global acceptance, and interchange-linked revenue opportunities for partners. citeturn23view2
• Money-in: fiat → stablecoin conversion via “ACH, wire, or SWIFT” (as described in Rain’s B2B case study) and broader “bank to blockchain” on-ramp positioning. citeturn12view0turn17search18
• Accounts: embedded “digital dollar accounts” and wallets that connect to Rain-issued cards, including “optional yield” language. citeturn17search2turn23view2
• Money-out: stablecoin transfers and local currency off-ramps, positioned for payouts/remittances. citeturn17search8turn12view0

Network settlement claims and Visa pilot participation
Rain publicly states it “settles directly with Visa in USDC, including weekends and holidays.” citeturn23view3
Rain’s press release with Visa states Rain joined Visa’s stablecoin settlement pilot, transitioned settlement transactions for its Visa cards to USDC, and can settle with Visa 7 days/week/365 days/year. citeturn25search0turn25search3 This aligns with Visa’s public stablecoin settlement program description enabling issuer/acquirer partners to settle VisaNet obligations using USDC over supported blockchains. citeturn23view4turn25search10

Tokenized receivables and on-chain credit financing (as described by Visa and Rain)
Rain claims it has “fully tokenize[d] credit card receivables,” and Visa separately describes Rain leveraging blockchain-enabled lending platforms (e.g., Credit Coop, Huma Finance) to borrow USDC secured by card receivables for “just‑in‑time funding,” and then settle directly with Visa as a pilot partner. citeturn23view3turn25search7turn25search0
This is unusually specific—because it comes from Visa’s own onchain finance content, not only Rain marketing—yet it is still described at a conceptual rather than system-diagram level (no smart contract addresses, no control framework, no waterfall mechanics disclosed). citeturn25search7turn23view3

Partnerships and ecosystem integrations (explicitly documented)

• entity["company","Nuvei","payments company"] launched a blockchain-based payments solution in LATAM with Rain, entity["company","BitGo","digital asset custodian"], and Visa, enabling merchants to use stablecoins (including USDC) for settlement and to spend via Visa-supported physical/virtual cards from a digital asset wallet. citeturn25search9turn7view0
• Rain and entity["company","Western Union","money transfer company"]: Rain announced plans to participate in Western Union’s Digital Asset Network, converting stablecoins held in Rain-powered wallets into local cash payouts at participating Western Union locations (launch details pending). citeturn11search2
• Rain + issuer processing: entity["company","Paymentology","issuer processor"] describes supporting Rain in launching physical and virtual Visa credit cards and characterizes integration of Rain “onchain infrastructure” with fiat rails, including “crypto-to-fiat” real-time transaction language. citeturn7view1
• Rain + card manufacturing: Rain states integration with entity["company","CompoSecure","card manufacturer"] (Arculus) for physical card programs. citeturn13search3turn8search0
• Example partner “end-user” programs: Rain’s case study on the Avalanche Card claims self-custody wallet control for users and support for assets including USDC and USDT for spending wherever Visa is accepted (initial region focus LATAM/Caribbean stated). citeturn11search0turn11search0

Custody relationships and banking partnerships
Rain’s legal language emphasizes it is not a bank, exchange, or asset custodian; payment products are provided with licensed institutions and cards are issued by partners licensed in their jurisdictions. citeturn2view1turn23view2
For the Rain Spend corporate card product specifically, Rain’s corporate card program terms identify the issuing bank as Third National Bank (Visa corporate card) and describe a collateralized credit line structure. citeturn3view0turn8search10

Information not publicly available. Rain does not publish a single canonical list of (a) issuing banks/BIN sponsors by jurisdiction for all Rain-powered programs, (b) custody counterparties for every program or custody model, or (c) the full set of regulatory licenses/registrations held by relevant Rain entities across markets. Research attempted: Rain legal pages (including corporate card terms), Rain trust center, Rain press releases, partner disclosures; Rain trust center appears to require gated access and did not render in accessible text via automated capture. citeturn3view0turn2view1turn23view0turn23view1

[[PAGE BREAK]]

Flow of Funds and Economics

This section provides step-by-step flows only where documentation supports each step. When flows require internal processing assumptions, they are explicitly marked as unavailable.

Flow of funds: Rain-linked consumer stablecoin card transaction

What can be stated with sources

1. User initiates purchase using a Rain-powered Visa card (e.g., Avalanche Card described as Visa-accepted spending). citeturn11search0turn23view2
2. Merchant processes via standard acquiring rails; authorization/clearing/settlement follow traditional card network routing (merchant → acquirer/processor → network → issuer/processor), per OCC baseline. citeturn22view0
3. Issuer settlement leg can use USDC: Rain states it transitioned its Visa card settlement transactions to USDC and can settle with Visa 7 days/week/365 days/year as part of Visa’s stablecoin settlement pilot. citeturn25search0turn25search3
4. Visa stablecoin settlement mechanics (general): Visa states issuer and acquirer partners can settle VisaNet obligations using USDC over supported blockchains, enabling seven-day settlement windows and treasury automation. citeturn23view4turn25search10

Information not publicly available. The following are not specified in publicly accessible Rain/Visa documentation for consumer card transactions:

• Whether the card is pre-funded with stablecoins vs credit-based vs hybrid per program.
• Where and when stablecoin↔fiat conversion happens (authorization-time vs clearing-time vs settlement-time), and which entity takes principal risk on conversion.
• Exact ledgering and reconciliation process between on-chain receipts (USDC transfers / receivable tokenization) and Visa clearing files for each program.
  Search basis: Rain card marketing pages, Rain-Visa press release, Visa stablecoin settlement materials, and Visa onchain credit content. citeturn25search0turn23view4turn25search7turn23view2

Flow of funds: Rain-enabled B2B payment (invoice/vendor scenario)

Rain provides a higher-fidelity public description at the capability layer (still not a wiring diagram).

Documented capability steps:

1. Enterprise funds via fiat on-ramp rails: Rain describes fiat on-ramps via ACH, wire, or SWIFT with conversion to stablecoins and funding to an enterprise wallet. citeturn12view0turn17search18
2. Wallet infrastructure holds stablecoins for transfers and card access. citeturn12view0turn17search2
3. Programmable cross-border transfer via API, with real-time status and metadata for audit/reconciliation (Rain marketing language). citeturn12view0turn17search8
4. Recipient spend options: (a) load funds to a Rain-issued Visa card for immediate spendability, or (b) off-ramp to bank accounts when cash settlement is required. citeturn12view0turn17search8
5. LATAM example: Nuvei describes a partnership enabling LATAM merchants to use stablecoins for faster settlement and to spend via Visa-supported physical/virtual cards from a digital asset wallet, with custody support from BitGo. citeturn25search9turn7view0

Information not publicly available. Public materials do not specify the contractual party bearing FX risk, stablecoin depeg risk, and chargeback/fraud losses in each B2B configuration (wallet-to-wallet vs card-based spend vs bank off-ramp), nor do they detail correspondent banking partners for fiat legs. citeturn12view0turn25search9turn2view1

Flow of funds: Cross-border settlement and cash-out (Western Union integration)

Documented steps (program-level, still high-level):

1. User holds stablecoins in a Rain-powered wallet (Rain describes wallet infrastructure and “Rain-powered wallets” in the Western Union announcement). citeturn11search2turn17search2
2. Conversion into local cash payout: Rain states the integration allows users to convert stablecoins into local cash payouts at participating Western Union locations (details on supported geographies/eligibility pending). citeturn11search2

Information not publicly available. The announcement does not disclose the exact on/off-ramp operator, FX execution venue, fees, or which entity acts as money transmitter/cash payout principal in each country corridor. Rain explicitly states details will be announced closer to availability. citeturn11search2turn2view1

Revenue model breakdown (documented vs not disclosed)

Documented (Rain)

• Rain explicitly markets that partners can “earn revenue through interchange,” and that service tiers vary by “interchange shared with partners” and “program fees.” citeturn23view2
• Rain Spend pricing is publicly listed as a subscription model ($0/month starter; $7,500/month unlimited), indicating at least one direct SaaS-like revenue stream in Rain’s portfolio. citeturn17search4
• Rain Spend’s corporate card terms disclose foreign purchase fee components (FX fee up to 3% and cross-border fee up to 3%), indicating fee revenue/fee pass-through categories for that specific product. citeturn8search10

Documented (ecosystem comparables relevant for qualification)

• Interchange is paid by acquirers to issuers; this is central to card-program unit economics, and network + scheme fees accrue at multiple points (issuer, network, acquirer). citeturn9search1turn9search3turn22view0

Information not publicly available. Rain does not publicly disclose:

• Interchange split percentages between Rain, issuing partners, and program partners by region.
• FX spread capture model (who sets rates; whether Rain earns spread vs passes through).
• Whether Rain earns treasury yield on reserves, and under what custody/legal structure (beyond “optional yield” marketing language).
• Any per‑API pricing schedule (Rain API docs appear gated).
  Research attempted: Rain cards pricing FAQ, Rain accounts/money-in/money-out pages, Rain legal pages, Rain API docs access attempt. citeturn23view2turn17search2turn2view0turn2view2

[[PAGE BREAK]]

Competitive Landscape and ICP Qualification

Competitive landscape (technical comparison)

Table: Technical comparison of Rain.xyz vs key infrastructure alternatives (publicly documented only)

| Provider | Core offering (documented) | Custody / asset control model (documented) | Settlement layer | ICP focus (public) | Regulatory positioning (public) | Notes: differentiators / weaknesses (publicly supportable) | |---|---|---|---|---|---|---| | Rain.xyz | Full-stack: cards + wallets/accounts + money-in/out; stablecoin settlement with Visa; multi-chain support messaging | States it is not a bank/custodian; payment products via licensed institutions; supports custodial & non-custodial wallet models (marketing) | Visa settlement in USDC 7d/365 via Visa pilot; plus on/off-ramp rails | Platforms, fintechs, neobanks, enterprises, wallets (marketing + press) | Not a bank/custodian; relies on licensed partners; Visa Principal Member (claimed) | Differentiators: Visa stablecoin settlement participation + tokenized receivables claims. Weakness: many operational details (bank partners, custody, pricing) not publicly specified. citeturn23view2turn25search0turn23view3turn2view1turn25news31 | | Stripe | Accept stablecoin payments that settle into Stripe balance in USD; broader crypto product suite; stablecoin accounts + issuance tooling (Bridge) | Stripe settles in USD to Stripe balance (merchant does not custody crypto in Stripe’s stablecoin payments flow); customer pays via crypto wallet | On-chain payment + off-chain settlement to Stripe USD balance | US businesses accepting global stablecoin payments; broader PSP base | Product terms and restricted-business policies; not positioned as card issuer | Differentiator: distribution + merchant tooling; Weakness vs Rain: not a card-issuing stack, dispute support differs (Stripe says no disputes/chargebacks for stablecoin payments). citeturn24view3turn18search9turn18search24turn18search1 | | Visa (network programs) | Stablecoin settlement for VisaNet obligations; expanding stablecoin settlement support (more coins/chains) | N/A (network) | Settlement over supported blockchains (USDC, etc.) enabling 7‑day windows | Issuers, acquirers, banks, fintech partners | Network rules + stablecoin settlement pilot programs | Differentiator: controls network settlement layer; Weakness vs Rain: does not provide end-to-end program management stack by itself. citeturn23view4turn23view5turn6view0 | | Fireblocks | Stablecoin payments orchestration layer connecting rails, issuers, liquidity, compliance tools | Explicitly not a qualified custodian; provides custody tech + workflows; custody model depends on client architecture | Orchestrates across blockchains and partners | Institutions needing secure wallet infra + payment orchestration | Embeds AML/KYC/Travel Rule tooling (product claim) | Differentiator: broad ecosystem connectivity + security workflow; Weakness vs Rain: not inherently an issuing/network membership layer. citeturn24view4turn20search22turn20search2 | | Zero Hash | API infrastructure for crypto/stablecoin funding, payouts, settlements; provides licensing wrapper | Offers custody and compliance via regulated entities; publishes licenses/disclosures | Integrates fiat rails + stablecoin rails; supports configurable settlement | Platforms wanting to add stablecoin/crypto features without building licensure | FinCEN MSB + state money transmitter licensing; publishes US licenses/disclosures | Differentiator: explicit regulatory wrapper with disclosed licenses; Weakness vs Rain: does not equal card issuance stack (card programs would still need issuer/network layer). citeturn18search11turn24view5turn20search3turn20search4 | | BVNK | Enterprise stablecoin payments infrastructure (receive/convert/settle) | Generates wallet addresses, monitors blockchain, converts and settles in fiat/stablecoin; custody posture depends on BVNK product | Stablecoin rails + fiat settlement options | Enterprises / platforms integrating stablecoin payments | Operates as EMI via System Pay Services Limited (UK FCA ref disclosed); publishes licenses/registrations help docs | Differentiator: strong enterprise payout/receive flows; Weakness vs Rain: not positioned as card issuance + network settlement partner. citeturn19search4turn19search12turn19search16 | | Coinbase (card + payments) | Consumer debit card; commerce stablecoin payment stack (Coinbase Payments) | Debit card: issued by Pathward and powered by Marqeta (explicit); commerce stack: USDC payments positioning | Cards: Visa debit acceptance; commerce: on-chain USDC rails | Consumers + commerce platforms (Shopify example claimed) | Not framed as issuer for third-party cards; Coinbase Payments is a commerce stack | Differentiator: consumer distribution + commerce rails; Weakness vs Rain: less evidence of being a third-party issuing platform for enterprises. citeturn21search25turn19search10turn19search6 |

ICP analysis and scoring rubric (BD-ready)

This rubric is an analytical framework built from Rain’s publicly stated positioning and capabilities, designed for qualifying inbound leads. It is not a claim about Rain’s internal scoring.

Scoring model overview (100 points total)
Product use-case fit (0–20): Does the prospect explicitly need (a) card issuance, (b) stablecoin settlements, (c) wallets/accounts, or (d) on/off-ramps? Rain markets all four as core platform pillars. citeturn17search2turn23view2turn17search18turn17search8

Volume potential (0–15): Evidence of high-frequency spend or large payout volume (e.g., payroll, marketplaces, B2B supplier payments). Rain positions itself for payroll/payout modernization and B2B settlement. citeturn7view3turn12view0

Geographic footprint (0–10): Multi-region programs benefit from Rain’s “global” positioning; Visa acceptance claims imply cross-border reach, but licensing/availability must be validated on call. citeturn23view2turn2view1

Regulatory exposure (0–15): Higher if the prospect touches high-risk corridors, cash-out, or quasi-banking features; stablecoin providers face AML/CFT/Travel Rule expectations (FATF). citeturn24view2turn11search2

Stablecoin usage intensity (0–10): Does the product require holding/transferring stablecoins vs using them as a hidden settlement layer? Rain and Stripe both support “invisible plumbing” narratives, but operating implications vary. citeturn7view6turn24view3

Urgency signals (0–10): Clear trigger events—new market launches, replacing slow cross-border settlement, launching card programs in weeks—align with Rain’s marketed time-to-launch. citeturn23view2turn12view0

Treasury sophistication (0–10): Prospects with working-capital sensitivity may value stablecoin settlement’s seven-day windows and reduced prefunding/FX friction (Visa narrative). citeturn23view4turn6view0

Integration complexity (0–10): Higher when the prospect demands non-custodial control, multi-chain, custom flow-of-funds, or bespoke compliance routing; Rain and peers market modularity and multi-chain support, but implementation burden must be qualified. citeturn23view2turn23view3turn13search2

Qualification call “must-answer” checklist (infrastructure-level)

• Which entity is the regulated issuer / who holds network membership for each market? (Rain: Visa Principal Member claim; licensed partners still used; must clarify per program.) citeturn23view2turn2view1
• What custody model is required (self-custody vs subcustody) and who is the qualified custodian if needed? citeturn20search22turn11search0
• Where does FX occur, and who bears principal risk? Information not publicly available without program specifics; must be obtained during diligence. citeturn2view1turn12view0
• Is the flow card-based (chargebacks/fraud exposure) or wallet-based (irreversibility, different dispute posture)? citeturn22view0turn24view3
• Settlement preference: fiat-only, stablecoin-only, or hybrid; whether seven-day settlement is required (Visa stablecoin settlement). citeturn23view4turn25search0

[[PAGE BREAK]]

Risk and Regulatory Landscape

This section focuses on documented requirements, exposures, and risk vectors at the intersection of card rails and stablecoin rails.

Card network compliance and program obligations
Card programs are subject to detailed network rules and dispute processes. OCC highlights that strict card association rules govern chargebacks and that high chargeback volumes can trigger penalties/fines from card associations; it also emphasizes fraud and operational controls in merchant processing and settlement. citeturn22view0 Visa publishes merchant-facing dispute management guidance and stepwise dispute handling, reflecting formalized dispute workflows across issuers/acquirers/merchants. citeturn9search2turn9search6

Chargeback and fraud risk allocation (card-linked stablecoin programs inherit this)
Even if issuer settlement uses stablecoins, merchant-side chargebacks remain a core risk mechanism in card payments. OCC describes how chargebacks can be upheld by issuers and charged back to merchants, and notes merchant processing banks can be liable for merchant fraud and factoring/laundering behaviors. citeturn22view0
This is a critical qualification point: a “stablecoin card” does not eliminate chargebacks; it can shift treasury settlement timing while leaving dispute rails intact. citeturn23view4turn22view0

Stablecoin regulatory scrutiny and AML/KYC obligations
FATF guidance requires countries to license/register VASPs and apply AML/CFT measures, including stablecoin-related guidance and Travel Rule implementation expectations. citeturn24view2
Operationally, infrastructure providers embed these requirements: Fireblocks states sanctions screening, AML/KYC, and Travel Rule are embedded into transaction workflows, demonstrating how providers anticipate multi-jurisdiction compliance demands. citeturn24view4

Custody and consumer protection obligations
Custody posture drives regulatory and operational risk. Fireblocks documents that “custody technology service providers are usually regulated differently than licensed custodians,” and warns against misrepresenting who controls keys (a proxy for whether a license might be required). citeturn20search2turn20search22
For regulated “wrapper” providers, Zero Hash publishes extensive money transmitter licensing disclosures, including warnings that virtual currency is not FDIC/SIPC insured and that transactions may be irreversible—consumer protection disclosures that shape BD diligence for stablecoin payment flows. citeturn24view5turn20search3

Cross-border compliance and sanctions exposure (documented at the framework level)
FATF explicitly ties VASP obligations to cross-border information sharing and Travel Rule compliance. citeturn24view2 Payment orchestration providers highlight sanctions screening as a built-in requirement for global stablecoin flows. citeturn24view4
Information not publicly available. Public sources do not provide Rain’s corridor-by-corridor sanctions/compliance operating procedures, nor the specific screening vendors or rule tuning. This must be verified in diligence and contract review. citeturn2view1turn23view3

[[PAGE BREAK]]

Strategic Outlook and Technical Appendix

Strategic analysis (source-backed signals, then interpreted implications)

Source-backed market signals

• Visa is scaling stablecoin settlement support (more stablecoins, more chains, broader stability settlement framework) and explicitly enables issuer/acquirer settlement in USDC over blockchains with seven-day windows. citeturn23view4turn23view5
• Stripe has operationalized stablecoin payments (customers pay via crypto wallets; settlement to USD balance), expanded stablecoin money management capabilities, and launched stablecoin issuance tooling via Bridge (“Open Issuance”). citeturn24view3turn18search9turn18search24turn18search1
• Rain is publicly positioned as a Visa stablecoin settlement pilot participant, with USDC settlement for its Visa card obligations and tokenized receivables narrative; Visa additionally describes Rain using lending protocols for just-in-time USDC funding secured by receivables. citeturn25search0turn25search7turn23view3

Reasoned strategic interpretation (explicitly not a claim about internal systems)

• Margin compression risk concentrates at commoditized layers: stablecoin on/off-ramp conversion, basic wallet infrastructure, and “vanilla” stablecoin acceptance (Stripe-style). As Stripe and Visa productize stablecoin settlement/acceptance at scale, providers without proprietary risk, compliance, or distribution moats may face pricing pressure. citeturn23view5turn18search24turn24view3
• Disintermediation vectors likely come from (a) networks expanding direct stablecoin settlement to more issuers/acquirers and (b) large PSPs embedding stablecoins as a default settlement method. If Visa’s stablecoin settlement becomes broadly available and standardized, some of Rain’s differentiation shifts toward program operations, compliance, and distribution rather than “stablecoin settlement access” alone. citeturn23view4turn25search10
• Rain’s defensibility, based only on public evidence, appears to rest on: (i) being integrated into Visa’s pilot settlement + operationalizing seven-day settlement, (ii) building/operating credit receivables tokenization concepts and related financing efficiency (as Visa describes), and (iii) bundling issuance + wallets + on/off-ramps into a single integration. The degree to which this is defensible depends on execution, regulatory durability, and network relationships—details not fully public. citeturn25search7turn23view2turn23view3

Technical appendix (infrastructure fluency pack)

Glossary (selected, source-grounded)

• Authorization: approving/declining a transaction before purchase finalization; routed merchant → acquirer/processor → network → issuer/processor and back. citeturn22view0
• Clearing: delivering final transaction data from acquirers to issuers for posting; includes fee calculations and currency conversion to settlement currencies. citeturn22view0
• Settlement: transmitting sales information for collection and reimbursement to merchant; also calculating net positions for issuers/acquirers on cleared transactions. citeturn22view0
• Chargeback: dispute-driven reversal/chargeback process; OCC categories include technical, clerical, quality, and fraud; Visa details merchant/issuer/acquirer dispute workflow. citeturn22view0turn9search6turn9search2
• Stablecoin settlement (Visa): ability for issuer/acquirer partners to settle VisaNet obligations using USDC over supported blockchains, enabling seven-day windows. citeturn23view4turn25search10
• Custody technology service provider vs qualified custodian: Fireblocks describes custody tech providers as often regulated differently than licensed custodians and states Fireblocks is not a qualified custodian; custody model depends on who controls key material. citeturn20search22turn20search2

BD diligence questions (designed to force clarity without assumptions)

• “Show the exact flow-of-funds diagram you use for regulators and network partners—who holds assets at each step?” (OCC emphasizes transaction + funds flow complexity with third parties.) citeturn22view0
• “What is the settlement asset and window (fiat vs USDC; 5-day vs 7-day), and which Visa stablecoin settlement rails/chains are used?” citeturn23view4turn25search0turn23view5
• “Which entity bears chargeback losses and fraud losses under network rules?” citeturn22view0turn9search2
• “Are you a VASP in the relevant jurisdictions, and how do you meet Travel Rule and sanctions screening expectations?” citeturn24view2turn24view4
• “What custody model is required (self-custody vs subcustody), and do you need a qualified custodian?” citeturn20search22turn20search2

Public-data gaps checklist (explicitly confirm on discovery; do not infer)

• Issuing/banking partners by market (only partially disclosed via specific product terms such as Rain Spend). citeturn3view0turn2view1
• Exact stablecoin↔fiat conversion timing and principal risk bearer for each program configuration. Information not publicly available. citeturn25search0turn23view2turn22view0
• Rain API specifications (Rain API docs appear gated). Information not publicly available. citeturn2view0turn23view2
• SOC 2 / PCI report details: Rain markets SOC 2 compliance; trust center appears gated and did not render in accessible capture. Information not publicly available. citeturn23view3turn23view0turn23view1