The license is just the beginning: where are the winners and losers of crypto payments?
Original author: Attorney Shao Jiayao
Original title: To make crypto payments, the first thing is a license; what is the second thing?
In the last two years, more and more customers are asking about crypto payments.
There are those that accept payments from cross-border e-commerce, those that use stablecoin payments, those that use U cards, those that accept payments from merchants, those that make built-in payments in Web3 wallets, and traditional payment companies that want to slowly receive the original fiat currency payment services into stablecoins, exchange accounts, or on-chain settlement networks.
Most people ask the same question as soon as they come up:
“Attorney Shao, which license should we get first?”
This is certainly an important question. When it comes to payment services, whether it's traditional payments or encrypted payments, it's impossible to bypass a license. US MSB (Money Services Business Registration, money services business registration, strictly speaking, registration at the federal level rather than a license in the traditional sense), state MTL (Money Transmitter License), Hong Kong MSO (Money Service Operator, Money Service Operator), Singapore MPI (Major Payment Institution License), The DPT (Digital Payment Token) service license and CASP (Crypto\ -Asset Service Provider, Crypto Asset Service Provider) under MiCA in Europe may all become regulatory entrances that the project must face.
But in practice, I feel one thing more and more strongly:
The license is only the first thing; the second thing really determines whether the project can run or not.
This second thing is not looking for a bank, not a channel, or launching an app right away.
Instead, design a closed loop of business that can be understood and executed by banks, payment institutions, exchanges, on-chain risk control service providers, regulators, and internal project teams.
A license plate is an admission ticket, and a closed loop is the ability to operate.
The most common misconception with crypto payment projects is that a license will solve everything
Many project parties have an almost naive belief in licenses. After completing the US MSB registration, I felt that I could make stablecoin payments to customers around the world; when I got the Hong Kong MSO, I felt that USDT and USDC could be easily connected; seeing that a country's VASP application costs were low, I thought I could use it to undertake all cryptographic payment services; I heard that EMI or PI could use electronic money and payments, and I felt that it could naturally cover stablecoin settlements on the chain.
This understanding is dangerous.
The license addresses the question of “are you qualified to stand at the card table”; it does not solve the question of “can you do this business exactly”.
Also called payment, the business difference can be huge.
Are you helping customers remit coins, or do you help customers complete stablecoin exchanges? Are you a provider of payment collection tools or a cross-border settlement network? Are you only providing technical interfaces, or are you actually handling customer funds? Are you only showing third party pages, or are you participating in quoting, matching, clearing, and settlement? Do you let customers transfer their coins to the merchant themselves, or do you use the platform to collect, pay, and exchange them on your behalf?
Every detail change will result in changes in licensing, anti-money laundering, sanctions compliance, customer fund protection, contractual liability, and tax risks.
For example, the Hong Kong MSO itself mainly supports money exchange and remittance services, and of course does not cover virtual asset transactions, exchange, escrow, or stablecoin-related activities; US MSB registration is not equivalent to completing all US state-level money transmission license requirements; nor can CASP regulation under European MiCA simply replace the regulatory arrangements involved in traditional payment, electronic money, or bank account cooperation.
Therefore, the most dangerous state of crypto payment programs is not that they don't have a license, but that after getting a license, they think they can do anything.
Some licenses do allow projects to obtain regulatory status, while others are actually beneficial for account opening, financing, business cooperation, and external promotion. But the license itself doesn't automatically answer the bank's and partner's biggest concern: Who is the customer? Where did the money come from? Where do coins come from? What is the purpose of the transaction? Who will make the final payment? What role does the platform play in the middle?
If these questions aren't answered clearly, the more licenses, the easier it is to expose the chaos of business design.
The second thing is not to find a bank, but to explain the business link clearly
Many project parties will say that the second thing after a license is of course to find a bank.
This statement is only half right.
Banks are of course important. Without a bank account, no fiat deposit, and no merchant settlement account, many payment businesses simply can't run. But the problem is that banks don't accept projects based on feelings; what banks need to look at is whether you can clearly explain this business, can you continue risk control, and whether you can be held accountable if something goes wrong.
If the business link itself isn't well designed, finding any number of banks will just run into trouble over and over again.
What should really be done first is to break up the business link.
The first layer is the customer link.
Who exactly does the project serve? Are you an individual user or a corporate customer? Is it a cross-border e-commerce, game merchant, ad network, freelancer, or Web3 project party? What countries and regions are customers from? Are there any Americans, EU residents, or mainland Chinese users? Are there users in high-risk areas? Are there any high-risk industries such as sanctions, gambling, fraud, adult content, underground money stores, or false trade?
Who the customer is determines the depth of KYC (Know Your Customer, Know Your Customer), and also determines the risk undertone of the business.
The second layer is the capital link.
Where did fiat money come from, and whose account is it customer funds, merchant settlement payments, or the platform's own funds? Does the platform hold clients' funds? Is there a pool of funds? Do you accept payment on delivery? Is there a cross-border exchange involved? Do I need to transfer funds through a bank, EMI, payment institution, receipt agency, money transfer agency, or other licensed entity?
Banks are not at ease when the flow of funds is unclear.
The third layer is the coin flow link.
Where do stablecoins come from? Does the customer transfer the chain themselves, or does the platform help the customer make the purchase? Does the platform offer quotes? Is it a match? Hosted? Do you handle private keys? Do you control the on-chain address? Are third-party exchanges, OTC, liquidity providers, or custodians used?
In crypto payments, currency flows are more likely to be overlooked than capital flows. But regulators and partners are now asking the same question: Why can this coin be collected? Is this on-chain transaction polluting? Has the address been exposed to coin mixers, fraudulent addresses, dark web marketplaces, gambling platforms, or sanctions lists?
The fourth layer is the settlement link.
What exactly did the merchant receive? Received fiat or stablecoins? If the merchant receives fiat currency, who is in between to complete the conversion of the crypto asset to the fiat currency? If a merchant receives stablecoins, does the merchant itself have the ability to receive and process stablecoins? Who is responsible for intermediate exchange rates, slippage, processing fees, refunds, and chargebacks if the customer's payment is not in the same currency as the merchant's payment?
If this level is unclear, there will be a lot of disputes.
The fifth layer is the link of responsibility.
What if a client's funds or account has been frozen? What should I do if the merchant is sued? What if an on-chain address is marked as high risk by KYT (Know Your Transaction, On-Chain Transaction Monitoring)? What should I do if the source of funds is suspicious after the transaction is completed? Who will handle a letter from a supervisory or law enforcement agency requesting freezing, disclosure, or cooperation in an investigation? Who is responsible for customers and merchants when third party channels are interrupted?
The payment business is not afraid of complexity; the fear is that there are no boundaries of responsibility after it is complicated.
Why do so many projects die in a closed loop instead of a license plate
I've seen quite a few crypto payment projects over the past few years, and the place where I actually get stuck in the end is often not “having a license or not.”
More often than not, it is the project party that has a regulatory identity that looks good, a product that looks like it can run, and a technical channel that seems to have already been picked up, but once it comes to bank account opening, channel due diligence, partner review, investor due diligence, or regulatory communication, the whole story can't go on.
These due diligence will not stop at the level of “do you have a license?” but will continue to be dismantled.
If the project says that it is only a technical service provider, partners usually take a closer look: whether the customer's funds and stablecoins go through accounts or wallets controlled by the platform, whether the platform participates in transaction path selection, whether it decides to release transactions, whether it undertakes payment promises, and whether it makes settlement promises to merchants.
If the project says it doesn't do the exchange itself, the partner usually continues to look: whether the customer's payment assets are consistent with the merchant's payment assets, whether currency exchange, currency exchange, or exchange rate conversion occurred in the middle, who provided the quotation, who obtained the price difference, and who is responsible for the slippage and refund.
If the project says it's only connecting to a third-party licensed institution, due diligence won't end there. Partners will continue to look at: who actually establishes the customer relationship, who completes KYC and KYT, who keeps the transaction data, who handles abnormal transactions, and who is responsible to the customer and merchant when the third party service fails.
If the project uses an exchange, OTC, liquidity provider, or custodian to complete certain aspects, it will continue to involve a series of issues such as corporate account usage, transaction background materials, order and invoice retention, on-chain address screening, merchant authenticity review, and sanctions list screening.
This is the real dilemma for a lot of projects.
What is written on the PPT is PayFi (Payment Finance), Crypto Payment (crypto payment), Stablecoin Settlement (stablecoin settlement), and Global Merchant Settlement (Global Merchant Payment), which sounds very advanced. But once everything is done, the question becomes very specific: can you explain every sum of money, every coin, every customer, and every merchant?
The payments business has never been as simple as “moving value from A to B”. The real payment business is about answering clearly before every transfer of value: why it can be transferred, who has the right to transfer, who bears the risk, and who to call if there is a problem.
That's the importance of closing the loop.
The closed loop of crypto payments compliance requires at least seven questions to be answered
A closed loop of cryptographic payments that can run requires at least seven questions to be answered. Who is the customer? Who is the merchant? Who's collecting the money? Who is receiving coins? Who is redeeming? Who's hosting it? Who is responsible for AML (Anti-Money Laundering), sanctions screening, refunds, freezes, chargebacks, mistransfers, on-chain asset contamination, and regulatory inquiries?
These seven questions may seem simple, but they are enough to put most crypto payment projects in their original form.
For example, one project says it's just doing a “stablecoin payment aggregation.” So let's keep watching: What is aggregation? Is it an aggregated payment channel or an aggregated exchange liquidity? Does the customer place an order with you, or are they directly directed to a third party? Did you participate in the offer? Is there any control over the transaction path? Have you received customer assets? Have you promised the merchant the payment time and payment amount?
Another example is a project that says it doesn't touch customer funds. Then it depends on the actual link: did the customer transfer the money to the account controlled by the platform? Are customers transferring stablecoins to wallets controlled by the platform? Does the platform have the right to decide to release, freeze, return, or transfer? If so, this isn't an explanation for the past with the phrase “don't touch capital.”
Another example is a project that says it uses a third-party licensed agency to complete the exchange and settlement. That also depends on: Who is the third party? Which regions and businesses are covered by third party licenses? Who owns the customer relationship? Who does KYC? Who keeps the transaction data? Who reports abnormal transactions? Who handles customer complaints? Are there clear lines of responsibility and risk reminders between third party pages and platform pages?
Crypto payments are not a single point of compliance; they are link compliance.
Seen separately, projects may have licenses, banks, technology, agreements, and KYT tools. But if these things aren't put into the same closed loop of business, an embarrassing situation will occur: every part seems to be there, but the car just doesn't run smoothly.
What lawyers really need to do is not just help clients find a cheap license
Many people look for lawyers in the early stages of a project, and their favorite question is: “Where is the cheapest license? Where is the fastest? Where is the loosest regulation?”
You can ask this question, but you can't just ask this one.
Cheap licenses may not support real business, the fastest path may not be able to overcome bank due diligence, and places where regulations seem lax may not be recognized by mainstream partners. More realistically, crypto payment projects can often be solved without a license, but rather the result of a combination of different actors, different licenses, different partners, and different business boundaries.
The value of a lawyer here is not only to tell the project party where to apply for a license, but to help the project party break up the business into a structure that can be understood by supervision, accepted by cooperation, and executed by the team.
Specifically, the things to do include at least:
Design the main structure to clarify which entity is responsible for customer contracts, which entity is responsible for technical services, which entity is responsible for payment services, and which entity connects with exchanges, banks, or liquidity providers.
Design a license path to determine which businesses must have their own license, which businesses can be completed through licensed partners, which businesses cannot be carried out at this stage, and which businesses can be reserved for future upgrades.
The capital flow and currency flow were designed to clearly draw the entry and exit path of each fiat currency and stablecoin to prevent the business from actually forming a cash on delivery, unlicensed remittance, unlicensed exchange, unlicensed escrow, or unlicensed virtual asset service, but the project party itself thought it was just a “technical service.”
Design KYC, KYT, AML, and sanctions screening rules to let frontline operations teams know which customers can enter, which customers need to enhance due diligence, which transactions must be blocked, and which situations require freezing, refusing, reporting, or termination of services.
Design a contract system to create a set of user agreements, merchant agreements, channel agreements, liquidity agreements, risk disclosure, third-party service statements, abnormal transaction handling rules, and exemption boundaries, rather than randomly compiling several templates from the Internet.
Design external expression to make the official website, white paper, app page, sales speech, business PPT consistent with actual business. Many projects die not because of the business itself, but because of “talking too much to the outside world, not being able to do it internally, and there is a problem with supervision.”
A good crypto payment compliance plan doesn't control the project, but rather lets the project know where it can be done, where it can't be done, and where it can't be done now but can be reserved later.
After the license plate, the project must go from “can it be done” to “how to do it so it doesn't roll over”
Crypto payments will definitely continue to evolve in the future.
Stablecoins are entering more mainstream payment and settlement scenarios, and banks, payment institutions, card issuers, exchanges, wallets, and merchant service providers are all re-evaluating their positions. For the project parties, this is of course an opportunity. But the greater the opportunity, the more specific the regulatory and partner requirements will be.
In the past, many people were in the crypto business and liked to talk about concepts, traffic, technology, and globalization. It's not the same now. Now banks will look at your capital flow, supervision will look at your license boundaries, partners will look at your allocation of responsibilities, investors will look at your sustainable compliance costs, and customers will ask who is responsible for problems.
So, to make crypto payments, the first thing to do is of course a license.
But the second thing, I'm definitely not in a hurry to find a bank, nor am I in a hurry to pick up the channel, let alone go online.
The second thing is to turn the entire business into a closed loop.
This closed loop must at least be achieved: the business can be clearly explained, the links drawn, the risks identified, the responsibilities shared, the contract can be received, the team can execute it, the partners can understand it, and the regulatory questions can be answered.
If you can't do that, the license plate is just a certificate on the wall. If this can be achieved, the license will truly become the starting point of the business.
The real competitiveness of crypto payment projects is not who gets a cheap license first, but who first combines licenses, banks, channels, on-chain risk control, customer access, contractual responsibility, and operational discipline into a system that can operate for a long time.
Twitter:https://twitter.com/BitpushNewsCN
Compare the TG exchange group:https://t.me/BitPushCommunity
Compare TG subscriptions:https://t.me/bitpush
