Guide to Choosing Between US MSB and State MTL Licenses for Crypto Payment Companies

null

Original Author: Shao Jiadian Lawyer

Introduction

Most projects involved in crypto payments register as an MSB in the US early on. But once the project gets off the ground, sooner or later, a question arises: Is having only an MSB legally sufficient? This question cannot be answered based on industry intuition; it requires returning to the regulatory framework itself.

First, clarify a common misconception: MSB and state MTL are not “upgrade relationships”

Many projects mistakenly see MSB and state MTL as “lower-tier” and “higher-tier” versions, which is a typical misunderstanding. MSB (Money Services Business) is a federal-level anti-money laundering registration system regulated by FinCEN, focusing on:

• Whether KYC/AML/sanctions screening obligations are fulfilled
• Whether there are compliance risks such as money laundering or terrorist financing

State MTL (Money Transmitter License), on the other hand, is a state-level financial license, concerned with more fundamental issues:

• Whether you are qualified to conduct “funds transmission” within that state
• Whether you can legally access, control, or transfer others’ funds

In summary: the difference between the two is that MSB concerns “whether the money is clean,” while MTL concerns “whether you are qualified to handle that money.” They operate in different regulatory dimensions, and there is no legal logic to “cover MTL with MSB.”

Why many projects can operate early on with “just MSB”

It’s not regulatory leniency; rather, the business model deliberately avoids triggering state laws. In projects we have assisted, common early compliance designs include:

• Not directly targeting US natural persons
• Not providing fiat on/off ramps, only handling crypto assets
• Not maintaining customer fiat balances on the platform
• Not directly holding or controlling customer funds
• Funds always transferred through licensed third-party channels or custodians

Under these premises, the project generally does not constitute “money transmission” under state law, so MSB + internal control systems are feasible at this stage. But it’s important to emphasize: this is not an “exemption,” but rather a “not yet triggered” status.

The core issue: what exactly are the standards for triggering state MTL?

From a legal practice perspective, determining whether you need a state MTL is never about whether you call yourself a “payment platform,” but about your legal position in the funds chain. A highly practical criterion is: whether your business involves “transmitting, controlling, or possessing others’ fiat or its equivalents.”

Based on various state regulatory interpretations, the following behaviors are highly likely to be recognized as money transmission:

• Directly providing fiat payment services to US users
• Forming disposable fiat balances within the platform account
• Handling stablecoins as “currency or currency substitutes”
• Funds entering your account first, then being transferred out upon your instruction
• The platform has control over the flow, timing, or recipients of funds

Once these elements combine, relying solely on MSB becomes legally weak.

Crypto payment scenarios that practically almost require state MTL

Based on our project experience, the following business models usually prompt us to advise project teams: they need to seriously evaluate the need for state MTL, rather than “just go ahead.”

• Crypto payments or exchanges targeting US retail users
• Integrated platforms for fiat ↔ stablecoin transactions
• U-cards or crypto cards issued or used domestically in the US
• Customer funds “posted” or held within the platform system
• An integrated structure of payments + wallets + accounts

The logic is simple: the more you resemble a “bank-like” or “payment institution-like” entity, the less likely state regulators will see you as a mere technical intermediary.

Why many projects, despite knowing the risks, delay applying for MTL

The reasons are not complicated but involve costs and practical constraints. The actual thresholds for state MTL include: applying in multiple states separately, no “one license nationwide,” high surety bond amounts, ongoing capital and liquidity requirements, local compliance officers, audits, annual inspections, and the possibility of regulatory checks at any time. Therefore, many projects adopt phased strategies: designing their business structure to delay triggering MTL, outsourcing the “money handling” part to licensed institutions, and viewing MTL as a mid-to-late stage capability goal. But it’s crucial to understand that: regulatory attention often precedes your “readiness.”

A very practical self-assessment question

When conducting risk assessments for projects, I often ask: if a state regulator issues a letter today, can you clearly answer, “We do not touch, control, or transmit customer funds”? If you cannot confidently answer this, then the discussion is no longer about “whether to get MTL,” but about “when you will be deemed unlicensed.”

A more realistic compliance path: not a binary choice, but phased design

A mature US compliance approach is usually not: obtaining MSB and immediately applying for MTL across all states. Instead, start with MSB, design the business model to avoid state law triggers, gradually build internal controls, risk management, and compliance capabilities, and clearly identify which business lines constitute money transmission. Then, apply for MTL gradually, by state, by business, and by phase. From a legal perspective, MTL is not a “startup barrier,” but a reflection of “business maturity.”

Conclusion

I do not recommend that all crypto payment projects rush to obtain state MTL from the start. That’s neither realistic nor necessarily necessary. But I also do not suggest you assume: “We will only need MSB forever.”

MSB is the compliance foundation; MTL is the load-bearing structure. When you need it is not a subjective choice, but whether your business has already fallen within the scope of state law regulation. If you are already seriously contemplating this issue, it usually means—your project is no longer in the “early stage of experimentation.”