Original Author: Lawyer Shao Jiadin
In the last two years, more and more clients have been asking about cryptocurrency payments.
Some are engaged in cross-border e-commerce payments, some in stablecoin settlements, some in U Cards, some in merchant acquiring, some in Web3 wallet-built-in payments, and also traditional payment companies wanting to gradually connect their original fiat collection and payment services to stablecoin, exchange accounts, or on-chain settlement networks.
Most people start by asking the same question:
"Lawyer Shao, which license should we get first?"
This question is certainly important. Doing payment business, whether traditional or cryptocurrency-based, cannot bypass licensing. 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 license), DPT (Digital Payment Token) service permission, European MiCA's CASP (Crypto-Asset Service Provider)—these can all become mandatory regulatory entry points for a project.
But in practice, I have increasingly felt one thing:
The license is only the first thing; the second thing truly determines whether a project can actually get off the ground.
This second thing is not finding a bank, not finding a payment channel, nor is it rushing to launch an app.
It is designing a business closed-loop that can be jointly 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 admission ticket; the closed-loop is the operational capability.
The Most Common Mistake in Cryptocurrency Payment Projects is Thinking a License Solves Everything
Many project owners have an almost naive faith in licenses. After completing US MSB registration, they feel they can offer stablecoin payment services to global clients; after getting a Hong Kong MSO, they think they can easily incorporate USDT and USDC; seeing a country's VASP (Virtual Asset Service Provider) application cost is low, they assume it can handle all crypto payment business; hearing that an EMI (E-Money Institution) or PI (Payment Institution) in a certain place can handle electronic money and payments, they think it naturally covers on-chain stablecoin settlement.
This understanding is dangerous.
Licenses address the question of "are you qualified to sit at the table," not "whether you can actually conduct this specific business."
Even when called 'payment,' the business differences can be vast.
Are you helping clients with fiat remittances, or helping them with stablecoin exchange? Are you providing merchant payment tools, or building a cross-border settlement network? Are you only providing technical APIs, or actually handling client funds? Are you only displaying third-party pages, or participating in pricing, matching, clearing, and settlement? Are you letting clients transfer coins to merchants themselves, or is the platform collecting, paying, and exchanging on their behalf?
Every nuanced change will cause variations in licensing, anti-money laundering, sanctions compliance, client fund protection, contractual liability, and tax risks.
For example, the Hong Kong 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 also does not equal completing all state-level money transmitter license requirements; the regulation of CASPs under Europe's MiCA cannot simply replace the regulatory arrangements involved in traditional payment, e-money, or bank account cooperation.
Therefore, the most dangerous state for a cryptocurrency payment project is not having no license, but thinking you can do anything after obtaining one license.
Some licenses can indeed give a project a regulatory identity, and some are indeed beneficial for opening accounts, financing, business partnerships, and external promotion. But licenses themselves do not automatically answer the questions banks and partners care about most: Who is the client? Where does the money come from? Where do the coins come from? What is the purpose of the transaction? Who is the ultimate payee? What role does the platform actually play in the middle?
If these questions aren't answered clearly, having more licenses might actually expose the chaos in the business design.
The Second Thing is Not Finding a Bank, but Explaining the Business Flow Clearly
Many project owners would say the second thing after licensing is, of course, finding a bank.
This is only half right.
Banks are certainly important. Without bank accounts, without fiat on-ramps, without merchant settlement accounts, many payment businesses simply cannot run. But the problem is, banks don't take on projects based on feelings; banks want to see if your business can be clearly explained, if risk control can be sustained, and if liability can be assigned if problems arise.
If the business flow itself is not well-designed, contacting more banks is just repeating the rejection.
What should really be done first is to break down the business flow.
The first layer is the client flow.
Who exactly does the project serve? Individual users or corporate clients? Cross-border e-commerce sellers, gaming merchants, advertising networks, freelancers, or Web3 projects? Which countries and regions do the clients come from? Are there US persons, EU residents, or users from mainland China? Are there users from high-risk jurisdictions? Are there high-risk industries like sanctioned entities, gambling, fraud, adult content, underground banks, or false trade?
Who the client is determines the depth of KYC (Know Your Customer) and also sets the risk baseline for the business.
The second layer is the fund flow.
Where does fiat come from, whose account does it enter—client funds, merchant settlement funds, or platform's own funds? Does the platform hold client funds? Does it form a pool of funds? Does it involve collection and payment on behalf of others? Does it involve cross-border exchange? Does it need to complete fund transfers through banks, EMIs, payment institutions, acquirers, remittance institutions, or other licensed entities?
If the fund flow is unclear, banks won't be comfortable.
The third layer is the coin flow.
Where do stablecoins come from? Are they transferred on-chain by the client themselves, or does the platform help clients purchase them? Does the platform provide quotes? Does it match trades? Does it provide custody? Does it handle private keys? Does it control on-chain addresses? Does it use third-party exchanges, OTC desks, liquidity providers, or custodians?
In cryptocurrency 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 accepted? Is this on-chain transaction tainted? Has the address interacted with mixers, scam addresses, darknet markets, gambling platforms, or sanctions lists?
The fourth layer is the settlement flow.
What does the merchant actually receive? Fiat or stablecoins? If the merchant receives fiat, who completes the conversion from crypto assets to fiat in between? If the merchant receives stablecoins, does the merchant itself have the ability to receive and handle stablecoins? If the client's payment currency and the merchant's receiving currency differ, who bears the exchange rate, slippage, fees, refunds, and chargebacks?
If this layer is unclear, there will be many disputes.
The fifth layer is the liability flow.
What happens if client funds or accounts are frozen? What if a merchant is complained about? What if an on-chain address is flagged as high-risk by KYT (Know Your Transaction monitoring)? What happens if a suspicious source of funds is discovered after a transaction? Who handles requests from regulators or law enforcement to freeze, disclose, or assist in investigations? If a third-party channel is interrupted, who is liable to the client and merchant?
Payment business is not afraid of complexity; it's afraid of complexity without clear liability boundaries.
Why Many Projects Don't Fail at Licensing, But at the Closed-Loop
In recent years, I've seen many cryptocurrency payment projects, and the part that ultimately blocks them often isn't "whether they have a license."
More often, the project owner has a seemingly decent regulatory status, a product that seems to work, and a technical channel that seems to be connected. But as soon as they reach the stages of bank account opening, channel due diligence, partner review, investor due diligence, or regulatory communication, the entire story falls apart.
These due diligence processes don't stop at the level of "do you have a license," but continue to drill down.
If a project claims to be only a technology service provider, partners will typically look further: Do client funds and stablecoins pass through accounts or wallets controlled by the platform? Does the platform participate in routing selection? Does it decide whether to release the transaction? Does it guarantee arrival? Does it make settlement commitments to merchants?
If a project claims not to do exchange, partners will usually continue to check: Is the client's payment asset the same as the merchant's receiving asset? Does currency exchange, crypto-to-fiat exchange, or currency conversion happen in between? Who provides the quote? Who takes the spread? Who bears slippage and refunds?
If a project claims to only connect to third-party licensed institutions, due diligence won't stop there either. Partners will continue to examine: Under whose name is the client relationship actually established? Who completes KYC and KYT? Who retains transaction records? Who handles abnormal transactions? Who is responsible to the client and merchant if the third-party service fails?
If a project uses exchanges, OTC desks, liquidity providers, or custodians to complete certain steps, it will further involve issues like corporate account usage, transaction background documentation, order and invoice retention, on-chain address screening, merchant authenticity verification, sanctions list screening, and so on.
This is the real dilemma for many projects.
The PPT says PayFi, Crypto Payment, Stablecoin Settlement, Global Merchant Acquiring—it sounds very advanced. But once due diligence begins, questions become very specific: Can you explain every single dollar, every single coin, every single client, every single merchant?
Payment business is never as simple as "moving value from A to B." Real payment business is about first answering clearly before each value transfer: Why can it be transferred, who has the right to transfer it, who bears the risk, and who is accountable if something goes wrong.
This is the importance of a closed-loop.
The Compliance Closed-Loop for Cryptocurrency Payments Must Answer at Least Seven Questions
A functional cryptocurrency payment closed-loop must answer at least seven questions. Who is the client? Who is the merchant? Who collects the money? Who collects the coins? Who does the exchange? Who provides custody? Who bears the responsibility for AML (Anti-Money Laundering), sanctions screening, refunds, freezes, chargebacks, misdirected transfers, on-chain asset contamination, and regulatory inquiries?
These seven questions may seem simple, but they are enough to reveal the true nature of most cryptocurrency payment projects.
For example, a project says it only does "stablecoin payment aggregation." Then you must look further: What is being aggregated? Payment channels or exchange liquidity? Does the client place an order on your platform, or do they directly jump to a third party? Do you participate in quoting? Do you control the transaction path? Do you receive client assets? Do you promise the merchant arrival time and amount?
Another example, a project claims it doesn't touch client funds. Then look at the actual flow: Does the client send money to an account controlled by the platform? Does the client transfer stablecoins to a wallet controlled by the platform? Does the platform have the authority to decide to release, freeze, return, or transfer? If yes, this cannot be explained away by simply saying "doesn't touch funds."
Yet another example, a project says it uses third-party licensed institutions to complete exchange and settlement. You must also look: Who is the third party? Which regions and business activities does the third party's license cover? Under whose name is the client relationship? Who does KYC? Who keeps transaction records? Who reports abnormal transactions? Who handles client complaints? Is there clear separation of liability and risk disclosure between the third-party page and the platform's page?
Cryptocurrency payment compliance is not point-based, but flow-based.
Looked at individually, a project might have a license, a bank, technology, agreements, KYT tools. But if these things are not integrated into the same business closed-loop, you get an awkward situation: every component seems to exist, but the car just doesn't run smoothly.
What Lawyers Really Need to Do is Not Just Help Clients Find a Cheap License
Many early-stage projects like to ask lawyers: "Where is the cheapest license? Which place is fastest? Where is regulation the loosest?"
This question can be asked, but it shouldn't be the only one.
A cheap license may not support real business; the fastest path may not survive bank due diligence; places with seemingly loose regulation may not gain recognition from mainstream partners. More realistically, cryptocurrency payment projects are often not solved by one license, but are the result of combining different entities, different licenses, different partners, and different business boundaries.
The value of a lawyer here is not just telling the project where to apply for a license, but helping the project structure its business into a framework that regulators can understand, partners can accept, and the team can execute.
Specifically, the work should at least include:
Designing the entity structure, clarifying which entity is responsible for client contracting, which for technical services, which for payment services, and which interfaces with exchanges, banks, or liquidity providers.
Designing the licensing path, determining which business activities require self-held licenses, which can be completed through licensed partners, which cannot be done at the current stage, and which can be reserved for future upgrades.
Designing fund and coin flows, mapping out the in-and-out path for every fiat and stablecoin transaction, avoiding situations where the business actually constitutes collection/payment on behalf of others, unlicensed remittance, unlicensed exchange, unlicensed custody, or unlicensed virtual asset services, while the project owner still thinks it's just "technical services."
Designing KYC, KYT, AML, and sanctions screening rules, so the frontline operational team knows which clients to accept, which require enhanced due diligence, which transactions must be blocked, and which situations require freezing, rejection, reporting, or service termination.
Designing the contract system, making the User Agreement, Merchant Agreement, Channel Agreement, Liquidity Agreement, Risk Disclosures, Third-Party Service Declarations, Abnormal Transaction Handling Rules, and liability boundaries into a coherent set, rather than just piecing together a few templates from the internet.
Designing external communication, ensuring consistency between the official website, whitepaper, App pages, sales pitches, business PPTs, and the actual business. Many projects don't fail because of the business itself, but because "what is promised externally is too much, what is delivered internally is insufficient, and regulators see problems at a glance."
A good cryptocurrency payment compliance solution doesn't strangle the project; it lets the project know what can be done, what cannot be done, and what cannot be done now but can be reserved for later.
After Licensing, Projects Must Move from 'Can It Be Done' to 'How to Do It Without Capsizing'
Cryptocurrency payment will certainly continue to develop.
Stablecoins are entering more mainstream payment and settlement scenarios; banks, payment institutions, card networks, exchanges, wallets, and merchant service providers are all reassessing their positions. For project owners, this is an opportunity. But the greater the opportunity, the more specific the requirements from regulators and partners will become.
In the past, many people doing crypto business liked to talk about concepts, traffic, technology, globalization. Now it's different. Now banks will look at your fund flow, regulators will look at your license boundaries, partners will look at your liability division, investors will look at your sustainable compliance costs, and clients will ask who is responsible if something goes wrong.
So, for cryptocurrency payments, the first thing is certainly licensing.
But the second thing is definitely not rushing to find a bank, not rushing to connect channels, nor rushing to launch.
The second thing is to make the entire business a closed-loop.
This closed-loop should at least achieve: the business can be clearly explained, the flow can be diagrammed, risks can be identified, liabilities can be clearly assigned, contracts are aligned, the team can execute it, partners can understand it, and you can answer regulators' questions.
If this cannot be achieved, a license is just a certificate on the wall. If it can be achieved, the license will truly become the starting point of the business.
The real competitiveness of a cryptocurrency payment project is not who gets a cheap license first, but who first assembles the license, bank, channels, on-chain risk control, client admission, contractual liability, and operational discipline into a system that can operate long-term.
