First, clarify what the balance displayed on the card actually is
What the market calls a U card may involve the user first selling stablecoins, with fiat currency entering a prepaid account before being spent; it may also be that conversion is triggered only at the time of spending; and some products use assets as collateral to provide credit. The asset ownership, payment obligations and risks of these three models are not the same. Before review, it should be confirmed whether the user holds stablecoins, a claim against the payment institution for the balance, or a credit line, and they must not all be uniformly referred to as an "on-chain bank card."
At a minimum, examine the bank card side and the crypto asset side separately
The UK FCA classifies the issuance of payment instruments and the execution of card payments as payment services, and has separate rules for the issuance of electronic money. This UK example shows that the card manufacturer, the technical processor and the institution authorized to provide financial services are not the same role. Whether the service is provided specifically by a bank, an electronic money institution or another eligible institution must be determined according to the local product structure.
On the crypto asset side, it is necessary to verify who safekeeps, who converts, and who transfers on behalf of clients. The EU MiCA classifies these as different service categories, so the financial qualification of the card issuer cannot substitute for review of the crypto side, nor can it be assumed that possessing a crypto services qualification allows one to provide bank card accounts on one's own. Qualification for cooperation with card organizations is a separate layer of arrangement.
From top-up to refund, examine transaction by transaction who owes the user money
Assume the user first transfers in stablecoins, and the project immediately converts them into fiat currency and forms a spendable balance. At this point, it should be possible to answer who holds the assets before and after conversion, to whom the user may request return, and whether merchant refunds come back as fiat currency or as repurchased coins. If coins are sold only at the time of spending, it is also necessary to explain the handling of locked quotes, insufficient balance, conversion failure and revocation of authorization.
There may be multiple contracts among the project party, the card issuing institution, the processor, and the custody and conversion institutions. The brand owner should at least obtain confirmation of the scope of services related to its own role, arrangements for fund handling and user exit. It cannot, merely on the basis of an upstream promise that cards "can be issued," assure users of account security, withdrawal at any time, or usability in any country.
First build a verifiable single product, then expand functions
It is recommended to first lock in one customer type, limited customer acquisition regions and a clear balance model, form four comparison tables covering entity, license, assets and contracts, and then proceed with technical integration testing. Functions involving credit or returns should be subject to a separate review project. The cost model should also include card processing, foreign exchange, asset conversion, refunds and service-discontinuation migration, rather than calculating only the production cost of each card.
Recommended actions
- Determine whether the model is pre-conversion, conversion at the time of spending, or credit, and do not mix balance descriptions.
- Verify the true identity and authority of the card issuer, the payment account provider and the crypto service provider.
- Map the changes in assets and claims upon top-up, spending, reversal, refund and withdrawal.
- Obtain cooperation approval for the customer-acquisition regions and specific products, and then review the marketing materials and user agreement.
This content is for general information only and does not constitute legal advice. Please consult a qualified lawyer about specific matters.
References
- Payment Services Regulations 2017 and Electronic Money Regulations 2011 — UK Financial Conduct Authority (FCA)
- Article 3 of MiCA: Definitions — EU regulations / ESMA official rulebook
- Using payment service providers — UK Financial Conduct Authority (FCA)
