Euronet and Fireblocks extend stablecoin infrastructure into card issuing

Euronet and Fireblocks announced an expansion into stablecoin-funded card issuing on 19 October. The planned white-label service combines Euronet’s Ren and CoreCard platforms with Fireblocks embedded wallets, allowing banks and fintechs to offer the capability inside their own applications.[1][5]

The design creates a wallet for each cardholder at onboarding. Fiat deposits convert into stablecoins before crediting, while merchants receive local currency through conventional card payments. Users keep familiar login credentials, without a separate crypto application or seed phrase to manage.[5]

Card issuing adds a customer balance to institutional payment infrastructure

The October 2025 collaboration covered settlement, pre-funding and treasury flows in Euronet’s cross-border payments business. Issuing extends that infrastructure to a customer’s spending instrument, bringing onboarding and everyday balance servicing into the relationship.[2][5]

Key control and recovery remain programme design choices

Fireblocks describes embedded wallets as wallets incorporated into an existing app. Its documentation distinguishes end-user wallet keys from the separate master key serving business vault accounts. The embedded-wallet architecture uses two signing shares: one on the user’s device and one in Fireblocks-managed secure infrastructure.[3][4]

That documented architecture explains why replacing a lost device and recovering signing capability are product functions in their own right. A programme needs to specify who can approve a recovery, how the customer regains access and which controls apply during the process. The general documentation does not establish every future Euronet programme’s precise configuration.

The operator, contracting terms, control rights and jurisdiction determine the customer’s legal relationship. Infrastructure provision alone does not identify Fireblocks as the cardholder’s regulated custodian. The branded app should identify the relevant entity and explain the balance and rights the customer holds.

A failed payment must leave an explainable balance

Reconciliation needs separate records for the deposit, stablecoin credit, spending authorisation, conversion and merchant settlement. In an illustrative failure case, an authorisation reserves funds but the merchant payment is not completed. Operations then need to identify whether a hold should be released, a conversion reversed or a refund credited. Treating all stages as one balance movement makes it harder to distinguish timing and exchange-rate differences from a missing or duplicated credit.

Programme terms must specify supported assets and countries, conversion-pricing timing, fees and refund currency. The announcement does not identify a live bank programme or a universal asset list and country timetable, so availability remains a programme-level launch question.[5]

Banks and fintechs can reuse the partners’ issuing and wallet components while concentrating on customer experience and distribution. The operational business case should include reconciliation exceptions, recovery success and support cost alongside payment volume. Those measures show whether the integrated service delivers a usable spending balance throughout both successful and failed transactions.

Report an error or submit an update