Do I need a money transmitter license for my payment app?

Building a checkout or payout tool for creators looks like ordinary software, and the thing most builders miss is that the moment you collect, hold, and pay out other people's money, you are doing money transmission, which is a licensed activity in most markets. The wall here is not the checkout screen. It is the float and the payout: holding funds that are not yours and moving them to someone else. Accepting payment for your own product is ordinary commerce. Moving money on behalf of others is a regulated financial activity, and the difference is whose money flows through you.

The card above is a real result from a compliance check. The idea tested was a synthetic example: a checkout tool for global creators that collects payments from customers worldwide, holds the funds, converts currency, and pays out to the creator's local bank, including via Pix in Brazil and UPI in India. The profile was a solo founder based in Brazil. The result was a needs review signal, not a blocked one, because moving money is a licensed activity rather than a forbidden one. The condition is the licensing path explained below.

What counts as money transmission

The regulated activity is handling other people's money as a service. Acquiring or processing card payments for merchants, issuing payment accounts, and transmitting or remitting funds all fall under it. The label changes by market, but the substance does not.

In the US, a business that transmits funds is a money transmitter and must register with FinCEN as a Money Services Business under the Bank Secrecy Act, and also hold state money-transmitter licenses. In the EU, it is a payment service under PSD2. In Brazil, it is a payment institution supervised by the Banco Central. A tool that collects, holds, and disburses funds for creators is doing this in every one of those markets at once.

Sources: FinCEN, Am I an MSB? and PSD2, Directive (EU) 2015/2366.

The line: your money versus other people's money

The engine did not block this idea. It flagged it for review, because moving money is licensed, not banned. The line that matters is whose money you touch.

A SaaS that charges its own customers for its own product or subscription is ordinary commerce. It is not money transmission, even though money changes hands. A tool that collects payments from a creator's customers, holds those funds, and pays them out to the creator is moving other people's money, and that is the regulated part. The checkout button can look identical in both cases. The regulatory position is completely different, and it turns entirely on whether the funds flowing through you are yours or someone else's.

"We are too small to need a license" is the dangerous assumption

The most common mistake is assuming a volume threshold protects you. Thresholds vary by market, and some have been removed.

In the US there is no activity threshold for the federal money-transmitter definition: transmitting funds as a business makes you a Money Services Business regardless of how little you move, though state licensing rules differ. Brazil tightened further. Under Resolução BCB 494/2025, in force since September 2025, prior authorisation is required to operate as a payment institution regardless of transaction volume, replacing the earlier volume thresholds that once let smaller operations defer authorisation. "We will get licensed once we are bigger" is not a safe plan in either market.

Source: Banco Central do Brasil (Lei 12.865/2013, Resolução BCB 494/2025); FinCEN, Am I an MSB?.

The myth versus what the law treats it as

	The common assumption	What the law treats it as
"It is just a checkout button"	Software, not finance	Holding and moving other people's funds is money transmission
"We are too small for a license"	A volume threshold protects us	The US has no threshold for the definition; Brazil removed its thresholds in 2025
"We only take a fee, we do not transmit"	A platform fee is not money transmission	Collecting, holding, and paying out funds for others is
"We are not a US company"	US rules do not reach us	Payment rules apply per market served, not by where you incorporate

The route that keeps it solo: build on someone else's license

This is not categorically off-limits to a solo founder, and that is the part the doom version of this misses. Most builders never hold the license themselves.

The standard route is to build on a licensed provider, through Banking-as-a-Service, a licensed acquirer, or a payment institution, or to operate as that provider's agent, so the regulated money movement sits under their authorisation rather than yours. The work then is to confirm that the provider's license actually covers your specific flow, the collection, the holding or float, the currency conversion, and the payout, in each market you serve, and to get that confirmation in writing.

If you are a solo founder on a small budget

The cost here is not the checkout build. It is a licensing path, or a provider relationship, that covers collecting, holding, converting, and paying out funds across every market you serve, plus the anti-money-laundering and know-your-customer duties that come with moving money. That is why a compliance check returns this kind of idea as needs review rather than a clean pass.

If that is heavy for your stage, these are not workarounds. They are different products that change the duty:

• Build on a licensed Banking-as-a-Service or payment provider whose authorisation covers your flow, and never hold the float directly.
• Or narrow the product so you never hold other people's money: facilitate the connection and let a licensed processor hold and move the funds.
• Or start in one market and confirm a single clear licensing or partner path before going multi-country.

Each of these changes whether you are holding and moving other people's money, which is what triggers the licensing in the first place.

How to validate before you build

The result shown above came from Tovrio, a compliance check that runs an idea against country specific rules before you write code. The idea tested was a synthetic case, not a real user. The result was a needs review signal with the reasons named here.

This is a validate before you build signal, not legal advice. A flag means "go confirm this with a financial-services professional before you commit," not "your specific plan is definitely unlawful." You can run your own idea through it.