The true competitiveness of cryptocurrency payment projects is not about who obtains a cheap license first, but about who can first piece together a long-operating system that integrates licenses, banks, channels, on-chain risk control, customer access, contractual responsibilities, and operational discipline.

Written by: Shao Jiadian

In the past two years, more and more customers are inquiring about cryptocurrency payments.

Some focus on cross-border e-commerce payments, others on stablecoin settlements, some on U cards, some on merchant acquiring, some on embedded payments in Web3 wallets, and some traditional payment companies want to gradually transition their fiat payment services into stablecoins, exchange accounts, or on-chain settlement networks.

Most people will ask the same question when they start:

“Lawyer Shao, which license should we obtain first?”

This question is, of course, important. In payment businesses, whether traditional or cryptocurrency, one cannot bypass the need for licenses. U.S. MSB (Money Services Business registration), which is strictly a federal-level registration rather than a traditional license; state MTL (Money Transmitter License); Hong Kong MSO (Money Service Operator); Singapore MPI (Major Payment Institution license); DPT (Digital Payment Token service license); and the European CASP (Crypto-Asset Service Provider) under MiCA, all may be regulatory entrances that the project must face.

However, in practice, I increasingly feel that:

The license is merely the first step; the second step truly determines whether the project can get off the ground.

The second step is not finding banks, not finding channels, and not rushing to launch an app.

Instead, it is designing a business closed loop that can be understood and executed by banks, payment institutions, exchanges, on-chain risk control service providers, regulatory agencies, and the project’s internal team.

The license is a ticket for entry; the closed loop is the operational capability.

1. The most common misconception in cryptocurrency payment projects is believing that licenses can solve everything

Many project teams have an almost naive belief in licenses. They think that once they complete the U.S. MSB registration, they can serve global customers for stablecoin payments; once they obtain the Hong Kong MSO, they can easily receive USDT and USDC; if they see that the application costs for a certain country's VASP are low, they believe they can handle all cryptocurrency payment businesses; if they hear that an EMI or PI in a certain place can carry out electronic money and payments, they think it can naturally cover on-chain stablecoin settlements.

This understanding is dangerous.

Licenses address the question of “Do you have the qualification to sit at the table?” but do not resolve whether “Can you actually perform this business?”

Even if they are both called payments, the business differences can be significant.

Are you helping customers with fiat remittances, or facilitating stablecoin exchanges? Are you providing merchant payment tools, or creating cross-border settlement networks? Are you only providing technical interfaces, or handling customer funds directly? Are you merely displaying a third-party page, or participating in quoting, matching, clearing, and settlement? Are you allowing customers to transfer coins directly to merchants, or is the platform collecting, paying, and converting on their behalf?

Every detail’s change will lead to variations in licenses, anti-money laundering regulations, sanctions compliance, customer fund protection, contractual responsibilities, and tax risks.

For instance, Hong Kong MSO primarily corresponds to money exchange and remittance services, and does not necessarily cover virtual asset transactions, exchanges, custody, or activities related to stablecoins; U.S. MSB registration does not equal fulfilling the currency transmission license requirements of all U.S. states; and European CASP regulation under MiCA cannot simply replace the regulatory arrangement involved in traditional payments, electronic money, or bank account partnerships.

Therefore, the most perilous state for cryptocurrency payment projects is not the absence of a license, but rather obtaining a license and then believing they can do anything.

Some licenses indeed help projects secure a regulatory identity, and some licenses also facilitate account openings, financing, business partnerships, and external promotion. But the license itself does not automatically answer the most pressing questions for banks and partners: Who are the customers? Where does the money come from? Where do the coins come from? What is the purpose of the transaction? Ultimately, who does the settlement go to? What role does the platform play in all this?

If these questions are not clearly answered, having more licenses can actually expose the chaos in business design.

2. The second step is not finding banks but clarifying the business chain

Many project teams will say that after obtaining a license, the second step is undoubtedly to find banks.

This statement is only partially true.

Banks are indeed important. Without a bank account, there are no fiat deposits or merchant settlement accounts; many payment businesses simply cannot operate. But the problem is that banks do not take on projects based on a hunch; they want to see whether your business can be explained clearly, whether it can maintain sustained risk control, and whether accountability can be enforced in case of issues.

If the business chain itself is not well designed, seeking more banks will only lead to repeated failures.

What should be done first is to break down the business chain.

The first layer is the customer chain.

Who exactly does the project serve? Is it individual users or corporate clients? Is it cross-border e-commerce, gaming merchants, advertising alliances, freelancers, or Web3 project teams? What countries and regions do the customers come from? Are there American, EU, or mainland Chinese users? Are there high-risk area users? Are there users from high-risk industries like sanctioning, gambling, fraud, adult content, underground banks, or false trading?

Who the customers are determines the depth of KYC (Know Your Customer) and the risk profile of the business.

The second layer is the fund chain.

Where does the fiat come from and whose account does it enter? Is it customer funds, merchant settlement funds, or the platform's own funds? Does the platform hold customer funds? Is there a formation of a funding pool? Is there third-party collection and payment involved? Is cross-border remittance implicated? Does it need to use banks, EMIs, payment institutions, acquiring institutions, remittance institutions, or other licensed entities to complete the fund transfer?

If the fund flow is unclear, banks will not feel secure.

The third layer is the coin flow.

Where do stablecoins come from? Are they transferred onto the chain by customers themselves, or does the platform assist customers in purchasing them? Does the platform quote? Does it match? Is there custody involved? Is it handling private keys? Does it control on-chain addresses? Does it use third-party exchanges, OTCs, liquidity providers, or custodians?

In cryptocurrency payments, coin flow is more easily overlooked than fund flow. But regulators and partners are asking the same question now: Why can this coin be received? Is there any contamination in this on-chain transaction? Has the address interacted with mixers, fraud addresses, dark web markets, gambling platforms, or sanctions lists?

The fourth layer is the settlement chain.

What exactly does the merchant receive? Is it fiat or stablecoins? If the merchant receives fiat, who completed the conversion from crypto assets to fiat? If the merchant receives stablecoins, does the merchant have the capacity to accept and process stablecoins? If the currencies for customer payments and merchant receipts are inconsistent, who bears the exchange rate, slippage, fees, refunds, and chargebacks?

If this layer is not clear, disputes will be numerous.

The fifth layer is the responsibility chain.

What happens if customer funds or accounts are frozen? What if the merchant is complained about? What if the on-chain address is marked as high risk by KYT (Know Your Transaction)? What if suspicious funding sources are discovered after a transaction is completed? If regulatory or law enforcement agencies request freezing, disclosure, or cooperation, who will handle it? If there’s a disruption in a third-party channel, who bears the responsibility to customers and merchants?

Payment businesses do not fear complexity; what they fear is the absence of clear responsibilities amidst that complexity.

3. Why do many projects not fail due to the license but due to the closed loop

In recent years, I have seen many cryptocurrency payment projects, and the real bottlenecks often do not arise from “Do you have a license?”

More often, it is that the project team has a seemingly decent regulatory identity, a product that appears to work, and a technology channel that seems to be functioning, but once it gets to the bank account opening, channel due diligence, partner reviews, investor due diligence, or regulatory communications, the whole story falls apart.

These due diligence reviews will not stop at the level of “Do you have a license?” but will continue to dig deeper.

If a project claims to be merely a technology service provider, partners often further look into: Whether the customer’s funds and stablecoins have gone through accounts or wallets controlled by the platform, whether the platform participates in transaction path selection, whether it determines whether to release transactions, whether it assumes the promise of fund receipt, and whether it makes any settlement commitments to merchants.

If a project claims it does not conduct exchanges, partners usually will continue to investigate: Do the customer's payment assets match the merchant's receiving assets, whether there are any occurring exchanges between coins, conversions between coins and fiat, or rate conversions, who provides the quotes, who benefits from the price difference, and who bears the slippage and refunds.

If a project claims to simply connect third-party licensed institutions, the due diligence won’t stop there either. Partners will continue to investigate: Who establishes the customer relationship, who conducts KYC and KYT, who retains the transaction materials, who handles abnormal transactions, and who is responsible to customers and merchants when third-party services fail.

If the project uses exchanges, OTCs, liquidity providers, or custodians to complete certain processes, it will further involve a series of questions, such as the purpose of corporate accounts, transaction background materials, order and invoice retention, on-chain address screening, merchant authenticity audits, sanctions list screenings, etc.

This is the real dilemma for many projects.

What they write on their PPTs are PayFi, Crypto Payment, Stablecoin Settlement, Global Merchant Acquiring, which sounds advanced. But when it comes to due diligence, the questions become very specific: Can you explain every single cent, coin, customer, and merchant?

Payment business has never been as simple as “moving value from A to B.” The real payment business must clarify before each value transfer: Why is the transfer possible, who has the authority to transfer, who bears the risk, and who to look for in case of problems.

This is the importance of the closed loop.

4. A compliant closed loop for cryptocurrency payments must answer at least seven questions

A functioning closed loop for cryptocurrency payments must answer at least seven questions. Who is the customer? Who is the merchant? Who is collecting the funds? Who is receiving the coins? Who is converting? Who is providing custody? Who bears responsibility for AML, sanctions screening, refunds, freezes, chargebacks, erroneous transfers, on-chain asset contamination, and regulatory inquiries?

These seven questions seem simple, but they are enough to reveal the true state of most cryptocurrency payment projects.

For example, if a project claims to only perform “stablecoin payment aggregation,” then it must be further examined: What is being aggregated? Is it aggregating payment channels or aggregating exchange liquidity? Are customers placing orders through you, or are they jumping directly to a third party? Did you participate in quoting? Do you control the transaction paths? Do you receive customer assets? Have you committed to merchants on the time and amount of receipt?

Again, if a project claims it does not touch customer funds, then the actual chain needs to be checked: Are customers sending money to an account controlled by the platform? Are customers transferring stablecoins to a wallet controlled by the platform? Does the platform have the authority to decide on releasing, freezing, returning, or transferring? If so, this cannot simply be explained by saying “we don’t touch funds.”

Once more, if a project states it uses third-party licensed institutions for conversions and settlements, then it also needs to be checked: Who is the third party? What regions and businesses does the third-party license cover? In whose name is the customer relationship? Who performs KYC? Who keeps the transaction records? Who reports abnormal transactions? Who handles customer complaints? Is there a clear division of responsibilities and risk warnings between the third-party pages and the platform pages?

Cryptocurrency payment compliance is not about one-off compliance; it's about chain compliance.

Individually, a project may have licenses, banks, technology, agreements, and KYT tools. But if these elements are not integrated into the same business closed loop, there will be an awkward situation: Every component seems to exist, yet the car cannot run smoothly.

5. What lawyers really need to do is not just help clients find a cheap license

In the early stages, many projects seek out lawyers and most often ask: “Where is the cheapest license? Where is it fastest? Where is the regulation the loosest?”

This question can be asked, but it should not be the only question.

A cheap license may not support a real business, the fastest path may not withstand bank due diligence, and a location that seems to have lenient regulations may not gain recognition from mainstream partners. More realistically, cryptocurrency payment projects are often not resolved by a single license, but rather result from a combination of different entities, different licenses, different partners, and varying business boundaries.

The value of lawyers here is not just in telling project teams where to apply for licenses, but in helping project teams break down the business into a structure that is understandable by regulators, acceptable to partners, and executable by teams.

Specifically, the things to be done should include at least:

Design the entity structure, clarifying which entity is responsible for customer contracts, which entity provides technical services, which entity handles payment services, and which entity connects with exchanges, banks, or liquidity providers.

Design the licensing paths, determining which businesses must hold licenses, which can be completed through licensed partners, which businesses cannot be undertaken at this stage, and which businesses can be reserved for future upgrades.

Design fund flow and coin flow, outlining the inbound and outbound paths for every fiat and stablecoin transaction, avoiding situations where the business has effectively constituted collection and payment, unlicensed remittances, unlicensed exchanges, unlicensed custody, or unlicensed virtual asset services, but the project team still thinks it is just “technical services.”

Design the KYC, KYT, AML, and sanctions screening rules so that the frontline operational team knows which customers can enter, which need enhanced due diligence, which transactions must be intercepted, and which situations require freezing, rejecting, reporting, or terminating services.

Design the contract system, creating a cohesive set of user agreements, merchant agreements, channel agreements, liquidity agreements, risk disclosures, third-party service statements, abnormal transaction handling rules, and liability limits rather than randomly piecing together a few templates from the internet.

Design external expressions, ensuring that the official website, white papers, app pages, sales pitches, business PPTs, and actual operations are consistent. Many projects fail not due to the business itself but because they "over-promised externally but couldn't deliver internally, which regulators quickly identified as problematic."

A good compliance solution for cryptocurrency payments does not suffocate the project but allows it to understand which areas can be operated in, which areas cannot be operated in, and which areas cannot be operated in now but can be reserved for future use.

6. After the license, projects need to shift from “can we do it” to “how to do it without crashing”

Cryptocurrency payments will definitely continue to develop in the future.

Stablecoins are entering more mainstream payment and settlement scenarios, and banks, payment institutions, card-issuing organizations, exchanges, wallets, and merchant service providers are reassessing their positions. For project teams, this is undoubtedly an opportunity. But the greater the opportunity, the more specific the requirements from regulators and partners will be.

In the past, many people involved in cryptocurrency businesses liked to talk about concepts, traffic, technology, and globalization. Now it’s different. Now banks will scrutinize your fund flow, regulators will examine your license boundaries, partners will assess your liability divisions, investors will look into your sustainable compliance costs, and customers will ask who bears responsibility when problems arise.

Therefore, when it comes to cryptocurrency payments, the first priority is certainly obtaining a license.

But the second priority is definitely not to rush to find banks, not to rush to connect channels, and certainly not to rush to launch.

The second priority is to turn the entire business into a closed loop.

This closed loop must achieve at least: the business is articulated clearly, the chain can be illustrated, risk identification is possible, responsibilities are distinctly allocated, contracts are connectable, teams can execute, partners can understand, and clear answers can be provided to regulators when they inquire.

If this cannot be achieved, then the license is merely a certificate on the wall. If this can be achieved, then the license will truly become the starting point of the business.

The real competitiveness of cryptocurrency payment projects lies not in who first obtains a cheap license, but in who first pieces together a system that can operate long-term consisting of licenses, banks, channels, on-chain risk controls, customer access, contractual responsibilities, and operational disciplines.