Why can't we do a good U Card?

To be honest, this title is a bit deliberately eye-catching, but I really want to talk about my feelings after communicating with some PayFi project parties recently.

I used to be quite optimistic about the U Card direction, after all, it is an important link in the practical use of crypto assets and connecting the real world. But after communicating with them and switching to their perspective, I realized more clearly: this track indeed has demand, but the challenges are far greater than I imagined.

No matter how much Web3 talks about 'financial freedom', it ultimately has to land in the real financial system.

And the U Card is probably the most problematic part of this landing process.

Is there a demand for U Cards? Of course there is.

In some countries/regions, the local currency is severely devalued, and in some places, there is almost a blockade on crypto assets. In this environment, if you can provide a card that allows you to 'directly spend USDT, no need to cash out, and can bind to Apple Pay, WeChat, Alipay', this is not just 'enhancing the experience', it is a 'survival solution' that many people cannot avoid.

But the difficulty with U Cards is not on the user side, but on the project side: you have to survive first.

Most people actually can't figure out how U Card project parties should profit.

The profit model of traditional bank cards mainly relies on merchant fee sharing, account management fees, and the earnings from idle funds. In contrast, U Card projects find it very difficult to earn from these areas.

Let's start with merchant fee sharing. If a user pays 100 yuan, the merchant may only receive 97 yuan, and the 3 yuan in between will be divided among the issuing bank, Visa/MasterCard, acquiring institutions, and other parties.

However, many U Card projects are essentially not real card issuers, but are affiliated with some small overseas institution, borrowing a BIN number to issue cards, and just connecting a layer of interfaces.

So you undertake all the operations, customer service, and risk control work, but the profit has long been consumed by the upstream.

You are the card issuer, but you do not participate in the clearing; you are building the product, but do not control the channels; you are doing user operations, but do not even have the right to earn commissions.

In simple terms, you are doing things, but not mastering the structure of profit distribution.

Can you make money from users? This may be a more realistic question at the moment.

I have also talked to many users, and most of their usage habits are 'temporary recharge, immediate use', buying SaaS, subscriptions, VPNs, airports... low unit price and not very frequent.

This is very similar to when I used Kraken for withdrawals, recharging temporarily only when I wanted to cash out, and usually not depositing money into it.

So the accumulation of funds on the platform is actually very low, and even if you connect to a protocol like Morpho, you can't earn much money from interest rate differentials.

Is there a way to change this?

Everyone is thinking of ways, such as creating e-commerce scenarios to control consumption paths; connecting fiat currency deposits and withdrawals to attract Web2 users; increasing wealth management, trading, and asset management modules to improve retention, etc.

But the problem also arises: these are all areas with heavy compliance and responsibility.

To connect with Web2 consumption scenarios, you need a payment license; to engage in wealth management involves securities laws and investor protection regulations; to have deposit and withdrawal channels cannot avoid the compliance system of AML/KYC. Once problems arise, it also involves compensation, arbitration, invoice compliance...

This is no longer just a 'product iteration' issue, but rather a question of whether you are a member of this system.

So the U Card business is both a high-demand scenario and a significant structural challenge.

You are doing Web3, but you rely entirely on the Web2 payment networks, banking systems, and compliance interfaces. The deeper you go, the more connection points you have with the traditional system, and the greater the risks and responsibilities.

This is the structural reality we need to face. Web3 teams are often very good at building functions and iterating products, but the financial system of the real world talks about the logic of structure, power, and responsibility distribution. Some problems cannot be solved just by writing a contract or connecting an API.

But I also believe that this direction has great prospects.

It is precisely because it is difficult that there is an opportunity.

I hope this article provides some reference value to friends who are still working in this direction, and I sincerely look forward to seeing a successful case emerging from the real structure.