In the past two years, we've seen a surge in clients inquiring about crypto payments. These include companies handling cross-border e-commerce payments, stablecoin settlements, USB cards, merchant acquiring, Web3 wallet-embedded payments, and traditional payment companies looking to gradually integrate their fiat currency payment and collection services with stablecoins, exchange accounts, or on-chain settlement networks. Most people immediately ask the same question: "Attorney Shao, which license should we obtain first?" This is certainly an important question. In the payment business, whether traditional or crypto, licensing is indispensable. The US MSB (Money Services Business registration, strictly speaking, 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), DPT (Digital Payment Token) service license, and Europe's MiCA CASP (Crypto-Asset Service Provider) are all regulatory hurdles that projects may have to overcome. However, in practice, I've increasingly felt that a license is only the first thing; the second thing truly determines whether a project can succeed. This second thing isn't finding a bank, finding a payment gateway, or rushing to launch an app. It's designing a closed-loop business model 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. A license is the entry ticket; a closed loop is the operational capability. The most common misconception among crypto payment projects is that a license can solve everything. Many project teams have an almost naive faith in licenses. Completing a US MSB registration doesn't automatically grant the right to handle stablecoin payments and receipts for global clients; obtaining a Hong Kong MSO license doesn't mean you can easily integrate USDT and USDC; seeing low VASP application costs in a certain country leads to the assumption that it can handle all crypto payment business; hearing that an EMI or PI license allows for electronic money and payments in a certain region naturally means it can also cover on-chain stablecoin settlements. This understanding is dangerous. Licenses address the question of "whether you are qualified to stand at the table," not "whether you can actually conduct this business." Even within the same term "payment," the business operations can be vastly different. Are you helping clients with fiat currency remittances or stablecoin exchanges? Are you providing client payment collection tools or building a cross-border settlement network? Are you merely providing the technical interface or actually handling client funds?Are you merely displaying third-party pages, or are you involved in quoting, matching, clearing, and settlement? Are you having customers transfer their tokens to merchants themselves, or is the platform handling collection, payment, and exchange on their behalf? Every change in these details will lead to changes in licensing, anti-money laundering, sanctions compliance, customer fund protection, contractual liability, and tax risks. For example, Hong Kong's MSO primarily corresponds to money exchange and remittance services, and does not automatically cover virtual asset trading, exchange, custody, or stablecoin-related activities; US MSB registration does not equate to fulfilling all state-level money transfer license requirements in the US; and European MiCA's CASP regulation cannot simply replace the regulatory arrangements involved in traditional payments, e-money, or bank account partnerships. Therefore, the most dangerous state for crypto payment projects is not the lack of a license, but obtaining one and believing they can do anything. Some licenses do indeed grant projects regulatory status, and some are indeed beneficial for account opening, financing, business cooperation, and external publicity. However, a license itself will not automatically answer the questions that banks and partners care about most: Who are the customers? Where does the money come from? Where does the token come from? What is the purpose of the transaction? To whom is the final settlement made? What role does the platform actually play in the middle? If these questions aren't clearly answered, having more licenses will only expose the chaos in the business design. Many project teams say that the second thing after obtaining licenses is, of course, to find a bank. This is only half right. Banks are certainly important. Without bank accounts, fiat currency deposits, and merchant settlement accounts, many payment services simply cannot operate. But the problem is, banks don't accept projects based on gut feeling. They look at whether your business can be clearly explained, whether you can maintain continuous risk control, and whether you can hold people accountable if problems arise. If the business chain itself isn't well-designed, finding more banks will only lead to repeated setbacks. What should really be done first is to break down the business chain. The first layer is the customer chain. Who exactly does the project serve? Individual users or corporate clients? Cross-border e-commerce, game merchants, advertising networks, freelancers, or Web3 project teams? From which countries and regions are the customers? Are there Americans, EU residents, or users from mainland China? Are there users from high-risk areas? Are there high-risk industries such as those involved in sanctions, gambling, fraud, adult content, underground banks, or fraudulent trade? Who the customers are determines the depth of KYC (Know Your Customer) and the underlying risks of the business. The second layer is the funding chain. Where does the fiat currency come from, and into whose account? Is it customer funds, merchant settlement payments, or the platform's own funds? Does the platform hold customer funds?Does it form a fund pool? Does it involve collection and payment on behalf of others? Does it involve cross-border remittance? Does it require the transfer of funds through banks, EMIs, payment institutions, acquiring institutions, remittance institutions, or other licensed entities? If the fund flow is unclear, banks will not feel comfortable. The third layer is the coin flow chain. Where does the stablecoin come from? Is it transferred on-chain by the customer themselves, or is the platform helping the customer purchase it? Does the platform provide quotes? Does it match transactions? Is it custodian? Does it handle private keys? Does it control on-chain addresses? Does it use third-party exchanges, OTC markets, liquidity providers, or custodian institutions? In crypto payments, the coin flow is more easily overlooked than the fund flow. But regulators and partners are now asking the same question: Why can this coin be received? Is this on-chain transaction contaminated? Has the address been exposed to mixers, fraudulent addresses, dark web markets, gambling platforms, or sanctions lists? The fourth layer is the settlement chain. What does the merchant actually receive? Fiat currency or stablecoins? If the merchant receives fiat currency, who completed the conversion of crypto assets to fiat currency? If a merchant receives stablecoins, does the merchant have the capability to receive and process them? If the customer's payment and the merchant's receipt currency are inconsistent, who bears the costs of exchange rates, slippage, fees, refunds, and chargebacks? If this layer is unclear, disputes will be numerous. The fifth layer is the responsibility chain. What happens if a customer's funds or account are frozen? What happens if a merchant is complained about? What happens if an on-chain address is marked as high-risk by KYT (Know Your Transaction)? What happens if the source of funds is found to be suspicious after a transaction is completed? Who handles letters from regulatory or law enforcement agencies requesting freezing, disclosure, or investigation? Who bears responsibility to customers and merchants if a third-party channel is interrupted? Payment businesses aren't afraid of complexity; what's dangerous is the lack of clear responsibility boundaries after complexity. In recent years, I've seen many crypto payment projects, and the real bottleneck is often not "whether or not they have a license." More often than not, a project team presents a seemingly legitimate regulatory status, a product that appears viable, and a technical channel that seems to be already in place. However, once they reach the stages of opening a bank account, conducting due diligence on the channel, reviewing partners, conducting due diligence on investors, or communicating with regulators, the whole story falls apart. These due diligence processes don't stop at "Do you have a license?" but delve deeper. If a project claims to be merely a technology service provider, partners will typically investigate further: whether the client's funds and stablecoins pass through accounts or wallets controlled by the platform, whether the platform participates in selecting transaction paths, whether it decides to approve transactions, whether it undertakes payment guarantees, and whether it makes settlement commitments to merchants.If a project claims it doesn't handle exchanges, partners will typically continue to investigate: whether customer payment assets match merchant receipt assets, whether there were any cryptocurrency-to-cryptocurrency exchanges, fiat currency exchanges, or currency conversions, who provides the quotes, who profits from the price differences, and who bears the slippage and refunds. If a project claims it merely connects to licensed third-party institutions, due diligence won't end there. Partners will continue to investigate: under whose name are customer relationships established, who completes KYC and KYT, who stores transaction data, who handles abnormal transactions, and who is responsible to customers and merchants in case of third-party service failures. This is the real dilemma many projects face. The PowerPoint presentations mention PayFi (Payment Finance), Crypto Payment, Stablecoin Settlement, and Global Merchant Acquiring—sounding very advanced. But once due diligence begins, the questions become very specific: can every transaction, every coin, every customer, and every merchant be explained? Payment business is never as simple as "moving value from A to B." True payment business requires clearly answering the following questions before each value transfer: Why is the transfer allowed? Who has the right to transfer? Who bears the risk? Who is responsible for any problems? This is the importance of a closed loop. A functional crypto payment closed loop must answer at least seven questions: Who is the customer? Who is the merchant? Who receives the money? Who receives the tokens? Who performs the exchange? Who is in custody? Who bears the responsibility for AML (Anti-Money Laundering), sanctions screening, refunds, freezes, chargebacks, erroneous transfers, on-chain asset contamination, and regulatory inquiries? These seven questions seem simple, but they are enough to expose the true nature of most crypto payment projects. For example, a project claims to be merely a "stablecoin payment aggregator." Then we need to examine further: What is being aggregated? Is it a payment channel aggregator or a liquidity aggregator? Do customers place orders through you, or are they directly redirected to a third party? Do you participate in pricing? Do you control the transaction path? Do you receive customer assets? Have you promised merchants arrival times and amounts? Another example is a project claiming it doesn't handle customer funds. That depends on the actual transaction process: Did the customer transfer money to an account controlled by the platform? Did the customer transfer stablecoins to a wallet controlled by the platform? Does the platform have the authority to release, freeze, refund, or transfer the funds? If so, this cannot be explained away simply by saying "we don't handle funds." For example, a project might claim to use a licensed third-party institution for exchange and settlement. In that case, we need to examine: Who is the third party? What regions and businesses does the third party's license cover? Under whose name are the customer relationships registered? Who conducts KYC?Who stores transaction data? Who reports abnormal transactions? Who handles customer complaints? Are there clear divisions of responsibility and risk warnings between third-party pages and platform pages? Encrypted payments are not a single-point compliance issue, but a chain of compliance. Individually, a project may have licenses, banks, technology, protocols, and KYT tools. But if these things are not integrated into a unified business loop, an awkward situation arises: every component seems to be there, but the car just won't run smoothly. Many early-stage projects, when consulting lawyers, often ask: "Where is the cheapest license? Where is the fastest? Where is the most lenient regulation?" This is a valid question, but not the only one. A cheap license may not support real business operations, the fastest path may not pass bank due diligence, and seemingly lenient regulations may not gain mainstream partner approval. More realistically, encrypted payment projects are often not solved by a single license, but rather the result of a combination of different entities, different licenses, different partners, and different business boundaries. The value of a lawyer here is not just telling the project team where to apply for a license, but helping them break down the business into a structure that regulators can understand, partners can accept, and the team can execute. Specifically, the tasks include at least the following: Designing the main architecture, clearly defining which entity is responsible for customer signing, technical services, payment services, and interfacing with exchanges, banks, or liquidity providers. Designing licensing pathways, determining which businesses require self-licensing, which can be completed through licensed partners, which cannot be done at this stage, and which can be reserved for future upgrades. Designing fund and currency flows, clearly outlining the inflow and outflow of every fiat currency and stablecoin to avoid situations where the business actually constitutes unlicensed collection and payment, unlicensed remittance, unlicensed exchange, unlicensed custody, or unlicensed virtual asset services, but the project team believes it is only a "technical service." Designing KYC, KYT, AML, and sanctions screening rules, ensuring the frontline operations team knows which customers are eligible, which require enhanced due diligence, which transactions must be blocked, and in what situations services need to be frozen, rejected, reported, or terminated. Designing a comprehensive contract system, creating a unified set of user agreements, merchant agreements, channel agreements, liquidity agreements, risk disclosures, third-party service statements, abnormal transaction handling rules, and disclaimers, rather than simply piecing together templates from the internet. Design your external communication channels to ensure consistency between the official website, white paper, app pages, sales scripts, business PPTs, and actual business operations.A good crypto payment compliance solution doesn't stifle projects, but rather clarifies their capabilities, limitations, and future potential. Crypto payments will undoubtedly continue to grow. Stablecoins are entering more mainstream payment and settlement scenarios, prompting banks, payment institutions, card issuers, exchanges, wallets, and merchant service providers to reassess their positions. This presents an opportunity for projects. However, the greater the opportunity, the more specific the requirements from regulators and partners will become. Banks now examine cash flow, regulators the boundaries of licenses, partners the division of responsibilities, investors the sustainable compliance costs, and customers the accountability for problems. Therefore, the first priority in crypto payments is obtaining a license. The second priority is not rushing to find banks, connect to payment gateways, or launch. The second priority is creating a closed-loop business model. This closed loop should at least ensure: a clearly defined business, a clearly defined workflow, identifiable risks, clearly defined responsibilities, a robust contract, a capable team, comprehensible to partners, and the ability to answer regulatory questions. If this isn't achieved, a license is just a certificate on the wall. Only when this is achieved will a license truly become the starting point for business. The real competitiveness of crypto payment projects isn't about who gets a cheap license first, but about who can first assemble a system that integrates licensing, banks, channels, on-chain risk control, customer onboarding, contractual liability, and operational discipline into a system that can operate sustainably in the long term. [Attorney Shao Jiadian]