Stablecoin API v1.0.4 — Release Notes

🚀 Stablecoin API Update v1.0.4 is now live! 🎉

This release adds 🇰🇪 KES (Kenyan Shilling) support alongside 🇬🇭 GHS (Ghanaian Cedi), restructures the USD remote bank account schema into explicit per-rail variants for clearer integration, and documents additional recipient fields.

✨ What's New

• 🇰🇪 KES (Kenyan Shilling) now supported across the API (mobile wallet & bank account payouts)
• 🇬🇭 GHS (Ghanaian Cedi) documented alongside KES — same rail model (note: GHS uses beneficiary_phone_number, KES uses recipient_phone_number)
• 🇺🇸 USD remote bank account schema split into four explicit per-rail variants (ACH, Domestic Wire, Int'l Wire by Account Number, Int'l Wire by IBAN)
• 🆕 New documented USD fields: account_type, recipient_relationship, bank_name
• ⛓️ Supported chains endpoint now sourced from the Web3 Engine (source of truth)

🇰🇪 KES (Kenyan Shilling)

KES is now available across the API. It appears in supported-currency enums and adds a new account_details variant with two payout rails.

Rails

For third-party recipients, provide third_party_details (recipient_first_name + recipient_last_name).

Example — mobile wallet

{
  "account_details": {
    "currency": "KES",
    "is_mobile_wallet": true,
    "recipient_phone_number": "0712345678"
  }
}

Example — bank account

{
  "account_details": {
    "currency": "KES",
    "is_mobile_wallet": false,
    "account_number": "1234567890",
    "swift_code": "KCBLKENXXXX"
  }
}

🇬🇭 GHS (Ghanaian Cedi)

GHS uses the same mobile-wallet / bank-account rail model as KES and is already supported. It's included here for reference alongside KES. ⚠️ Note the field-name difference: GHS uses beneficiary_phone_number for the mobile-wallet rail, whereas KES uses recipient_phone_number.

Rails

For third-party recipients, provide third_party_details.

Example — mobile wallet

{
  "account_details": {
    "currency": "GHS",
    "is_mobile_wallet": true,
    "beneficiary_phone_number": "0241234567"
  }
}

Example — bank account

{
  "account_details": {
    "currency": "GHS",
    "is_mobile_wallet": false,
    "account_number": "1234567890123",
    "swift_code": "GHCBGHACXXX"
  }
}

🇺🇸 USD Remote Bank Account Schema — Per-Rail Variants

The single USD variant (with a combined transfer_method enum) has been split into four explicit oneOf variants, one per rail. Each variant carries only the transfer_method value it supports and its own required-field list — making it clearer which fields are needed for each rail. No request contract change: the same payloads that worked before continue to work.

Variants

Behaviour notes

• ACH / Domestic Wire — account_number is 8–12 digits; routing_number is a 9-digit ABA. Domestic WIRE with THIRD_PARTY requires the full US address (recipient_state and recipient_postal_code required).
• International Wire — swift_code (BIC) is required; provide exactly one of account_number (up to 17 chars) or iban. routing_number is not used. For THIRD_PARTY, recipient_state and recipient_postal_code are optional.
• See Create remote bank account for the full schemas.

🆕 Additional USD Recipient Fields

The following optional fields are now documented on the USD variants:

• account_type — checking or savings
• recipient_relationship — the recipient's relationship to the sender (e.g. First Party, Employee, Vendor or Supplier, Customer, Family, Other)
• bank_name — the name of the recipient's bank

⛓️ Supported Chains

The supported chains metadata is now sourced from the Web3 Engine, which is the source of truth for supported chains. Chain values are de-duplicated and translated to the existing (legacy) chain names, so responses remain compatible.

🙌 Let us know if you need help integrating these updates!