Platform fees do not decide money-transmitter risk by themselves. The real test is how funds move, who controls them, and what evidence your team can show for each state and federal obligation.
Platform fees alone are not the legal test for money-transmitter risk. The risk turns on what your product does with customer funds in practice, including whether it receives value from one party to send to another.
This guide looks at platform fees money transmission laws through a funds-flow-first lens because labels are not the legal test. The practical question is whether your design looks like receiving value from one party to send to another.
FinCEN's interpretive guidance, issued May 9, 2019, is explicit that money-transmitter status is a facts-and-circumstances determination. Terms like "marketplace payouts," "creator earnings," or "contractor disbursements" are not conclusions by themselves. If your team cannot clearly show who controls funds at each step, when funds are released, and what happens during delays, your launch assumptions are not ready.
This work is cross-functional:
Treat every exemption or "software-only" position as something you may need to prove.
One more guardrail. FinCEN's guidance does not create new requirements, and it is not exhaustive. A model not specifically listed can still carry BSA obligations, so "not mentioned" is not a green light. Use this article to map funds flow, test control points, and decide what must be true before launch with counsel.
This pairs well with our guide on California Money Transmitter License Requirements for First-Time Filers.
Before you write fee logic, assemble a pre-design packet and set one decision deadline. That keeps product behavior, legal review, reconciliation, and implementation aligned before decisions harden.
| Prep item | What to gather or define | Key detail |
|---|---|---|
| Owners and decision date | Accountable owners across product, legal, finance ops, and engineering | Set one go/no-go review date; document the transaction flow before payout, principal-agent roles, and who can change payout timing |
| Live documents | Current payment terms, payout terms, checkout UX copy, and partner contracts tied to your payment rail | Work from live versions with clear dates |
| Launch states and access boundaries | Where you plan to launch, where users can access the service, and any blocked-access boundaries | Replace broad labels like "US only" with a written state list |
| Evidence folder | Prior compliance memos, change logs, records tied to transmittals of funds, and the documents above | Keep official legal references in a dedicated subfolder |
Assign accountable owners across product, legal, finance ops, and engineering, and set one go/no-go review date. Each owner should document the transaction flow before payout, principal-agent roles, and who can change payout timing.
Collect the current payment terms, payout terms, checkout UX copy, and partner contracts tied to your payment rail. Work from live versions with clear dates so your review matches what users and partners actually see.
List exactly where you plan to launch and where users can access the service, and document any blocked-access boundaries. Replace broad labels like "US only" with a written state list.
Create one folder for counsel and partner review that includes prior compliance memos, change logs, records tied to transmittals of funds, and the documents above. Keep official legal references in a dedicated subfolder.
Before finance signs off, map the fee logic against real settlement timing, payout timing, and exception handling.
Do not analyze exemptions until you can show, end to end, how money moves in production. For money transmission analysis, this map is the core artifact because it shows who receives funds, who controls timing, and when value is released.
Include, at minimum, authorization, processor accept or reject, settlement, ledger posting, fee application or invoicing, payout initiation, payout success or failure, and payee receipt. If you support ACH and wires, map them separately. The OCC payment-systems booklet includes both ACH and wire transaction-and-settlement flow artifacts, which is a practical reminder that rail behavior differs.
| Stage | Include in map | Questions to answer |
|---|---|---|
| Authorization | Authorization | Who controls funds, what record proves the handoff, and who can change timing |
| Processor accept or reject | Processor accept or reject | Who controls funds, what record proves the handoff, and who can change timing |
| Settlement | Settlement | Who controls funds, what record proves the handoff, and who can change timing |
| Ledger posting | Ledger posting | Who controls funds, what record proves the handoff, and who can change timing |
| Fee application or invoicing | Fee application or invoicing | Who controls funds, what record proves the handoff, and who can change timing |
| Payout initiation | Payout initiation | Who controls funds, what record proves the handoff, and who can change timing |
| Payout success or failure | Payout success or failure | Who controls funds, what record proves the handoff, and who can change timing |
| Payee receipt | Payee receipt | Who controls funds, what record proves the handoff, and who can change timing |
At each handoff, answer three questions: who controls funds, what record proves the handoff, and who can change timing. If engineering cannot point to a real event, queue, or status, the map is still too abstract.
This is where teams often blur software pricing and fund movement. Show whether fees are taken as a gross deduction, a separate invoice, or a post-settlement debit. Do not label any model as safe by default. Instead, document the facts: who sets the fee, who can change it after authorization, and when it is netted or collected.
Run a three-way check across product terms, processor settlement reporting, and your internal ledger. If those disagree on fee timing, stop and fix the model before legal analysis.
List every entity in the chain with legal entity names, including your platform, payment processor, bank partner, payer, payee, and any intermediary involved in instructions or fund movement.
If contracts mention an agency or delegation relationship, mark where it appears and what activity it is intended to cover. Do not assume that relationship exists or helps unless the contract language and actual flow match.
Keep this section factual. Money transmitter analysis depends on receiving and transmitting value, and state treatment is not uniform, so this map should be usable for state-by-state review later.
Add real exception paths, not just the happy path. Include refunds, reversals, failed payouts, returned payments, held balances, and unresolved-funds states. These are often the points where timing or routing control becomes most visible.
For each major exception type, attach evidence: sample webhook payloads, ledger records, settlement or return reports, and one real support case. A clean diagram without operational records is not enough.
Do not start exemption analysis until engineering and finance ops sign the map. Engineering confirms each box maps to a real service, event, or status. Finance ops confirms each movement reconciles to both internal ledger entries and external reports. If useful, keep a short internal-control checklist with the map. The OCC materials include both an internal control questionnaire and a 12 CFR 7.1026 compliance worksheet as examples of control artifacts alongside flow documentation.
If you cannot explain fund control at each handoff on one page, pause there before discussing exemptions. A one-page funds-flow map is the minimum evidence pack for a launch decision.
Start with a facts-first screen. If your platform receives value and transmits value to another party, treat that flow as potential money-transmission risk until the facts clearly support a different conclusion. Classify each live flow against concrete triggers, then document what is still unproven.
Apply a receipt-and-transmission check to each real flow, not just the happy path: customer payment, payout, refund, reversal, failed payout reissue, and held-funds states.
For each flow, answer these four questions on one page:
If your answer depends on labels like "we are only software," you do not have a usable classification yet.
Test each flow against FinCEN's facts-and-circumstances framing, and mark results as provisional. FinCEN states that money-transmitter status depends on facts and circumstances, and its May 9, 2019 interpretive guidance does not cover every possible fact pattern.
Build a short matrix for each model you actually run: what value is received, what value is transmitted, which entity acts, and which facts are still incomplete. If a model is not explicitly described in guidance, do not treat that as "no issue." It may still carry BSA obligations.
Treat MSB status, payment-processor positioning, and agent-of-payee arguments as hypotheses to prove, not launch assumptions.
Use an evidence pack with the following:
Flag mismatches immediately, especially when contract language and operational control do not match.
Pause launch if your team cannot explain legal control of funds at each handoff on one page. That is a design warning, not a documentation issue.
Your counsel-ready memo should clearly state where value is received, where it is transmitted, who controls release, and what remains unresolved. If you cannot produce that memo, rework the flow before debating exemptions.
If you want a deeper dive, read this guide to outsourcing money transmission to a MoR.
Choose the structure that matches your actual funds flow, not the story you would prefer to tell about it. If you need multi-state scale soon, run early diligence across partner-led processing, Merchant of Record (MoR), and direct licensing so timeline assumptions are tested, not assumed. If payments is a core moat, direct money-transmitter licensing may still be worth deeper evaluation.
Start with a directional comparison, then replace assumptions with facts from counsel, partner diligence, and your funds-flow map.
| Path | Timeline factors to verify | Regulatory/control scope to verify | Operational burden to verify | Partner dependency to verify | Fee/margin mechanics to verify | No-go condition |
|---|---|---|---|---|---|---|
| Direct licensing as a money transmitter | State and federal workstreams, including AML/BSA requirements | Direct responsibility for regulated-program controls; confirm obligations state by state | Ongoing control, monitoring, and notice/compliance checkpoints | Map required third-party dependencies and oversight | Model using actual fee schedules and billing timing from your providers and accounts | Stop if payments is not strategic enough to justify ongoing state analysis plus federal AML/BSA obligations |
| Partner-led processing through a payment processor | Partner readiness, onboarding sequence, and contract timing | Control boundaries should be explicit in contract and operating procedures | Map ownership for operational, fraud, and third-party-risk controls | Dependency is contract- and process-driven; verify escalation rights | Use settlement files and invoices to map line-item vs netted vs later-billed fees | Stop if your product requires fund-control actions the partner will not expressly permit |
| Outsourcing regulated flow to a Merchant of Record (MoR) | Provider fit, onboarding sequence, and contract timing | Do not assume legal treatment from the label alone; confirm role allocation in contract and counsel review | Map ownership for disputes, ledger corrections, exceptions, and approvals | Dependency is contract- and process-driven; verify service levels and change controls | Validate commercial split, billing mechanics, and reporting granularity | Stop if required ownership of merchant relationship, fee presentation, or dispute posture is not contractually supported |
Speed matters, but control and accountability are the real dividers. More direct control over fund movement can bring more direct regulatory and operational responsibility.
Validate fee visibility before finance signs off on unit economics. Request the same evidence for each option:
Then confirm whether platform fees are shown as line items, netted from proceeds, or billed later. Transaction-based pricing attaches fees to executed transactions, while asset-based schedules can be charged monthly in advance; some commission schedules are charged monthly in arrears, and fees can vary by account type and change over time. If finance cannot tell exactly when fees hit the ledger, your margin model is not decision-ready.
Price the compliance and operations work, not just the legal theory. The money-transmitter regulatory frame includes both state and federal layers, including AML and BSA, so direct licensing is an ongoing control model, not a one-time setup.
For partner-led and MoR models, risk ownership can shift rather than disappear. Compare them through an operational, fraud, and third-party-risk lens, then map who owns dispute communication, ledger correction, exceptions, and final approvals. If ownership is unclear on paper for one dispute and one failed payout, the model is not mature enough to price.
Set one explicit stop rule per option before integration starts. This prevents sunk-cost escalation.
For direct licensing, stop if leadership will not fund ongoing regulated-program staffing and controls. For partner-led processing, stop if contract terms leave fund-control boundaries unclear. For MoR, stop if internal teams still expect your platform to control billing or dispute outcomes without explicit contractual support.
If speed is the immediate constraint, run first-pass diligence on partner-led, MoR, and direct-licensing options with the same checklist. If long-term strategy depends on owning payment design and control, evaluate direct licensing with explicit state-plus-federal compliance planning.
You might also find this useful: Same-Day ACH for Platforms: How to Speed Up Contractor Payments Without Wire Transfer Fees.
If your scorecard points to outsourcing regulated flow for launch priorities, review Merchant of Record options before locking your architecture.
Decide this state by state, with one hard gate. No production launch until counsel issues written state and federal position memos for the exact funds flow you plan to ship.
Start with the states where users can actually sign up, pay, or receive payouts. Build one row per launch state with at least: user access, definition risk, exemption availability, licensing posture, federal overlay, counsel questions, and launch status.
| State-row field | What to record | Evidence mentioned |
|---|---|---|
| User access | Where users can actually sign up, pay, or receive payouts | Current funds-flow map; user fee and payout disclosures; relevant partner contract terms; product access controls by state |
| Definition risk | Definition risk for the launch state | Current funds-flow map; user fee and payout disclosures; relevant partner contract terms; product access controls by state |
| Exemption availability | Exemption availability for the launch state | Current funds-flow map; user fee and payout disclosures; relevant partner contract terms; product access controls by state |
| Licensing posture | Licensing posture for the launch state | Current funds-flow map; user fee and payout disclosures; relevant partner contract terms; product access controls by state |
| Federal overlay | Federal overlay for the launch state | Current funds-flow map; user fee and payout disclosures; relevant partner contract terms; product access controls by state |
| Counsel questions | Open counsel questions for the launch state | Current funds-flow map; user fee and payout disclosures; relevant partner contract terms; product access controls by state |
| Launch status | Launch status for the launch state | Current funds-flow map; user fee and payout disclosures; relevant partner contract terms; product access controls by state |
Treat definition risk, exemption availability, and licensing posture as separate decisions. Then attach evidence to each row: current funds-flow map, user fee and payout disclosures, relevant partner contract terms, and product access controls by state. That keeps decisions tied to the shipped flow instead of assumptions.
Use each target state's money transmission statutes and regulator guidance as reference checks to pressure-test your assumptions and remind the team that state definitions can diverge.
Do not treat one state analysis as universal. State licensing requirements can differ across jurisdictions, and regulators may impose different conditions.
Map federal duties in parallel with state analysis. There is no federal money transmitter license: federal treatment is MSB registration and compliance, while state licensing is separate and complementary.
Add a federal column in your matrix for Bank Secrecy Act obligations under 31 U.S.C. § 5311 et seq. and related AML and KYC expectations for your model. For each state row, document who owns the live compliance responsibilities in practice, not just in contract summaries.
Set a strict go or no-go rule. No production traffic and no state-expansion toggle until counsel provides written memos covering both state licensing posture and federal compliance posture for the shipped flow.
Version those memos with the supporting artifacts: funds-flow map, state matrix, user-facing disclosures, state access controls, and relevant partner agreements. If fee timing, payout logic, or control points change, refresh the legal position before launch changes go live.
For a step-by-step walkthrough, see Money Transmission Modernization Act and State Licensing Decisions.
A legal position only works if the product enforces it. After counsel clears the funds flow, turn that guidance into blocking rules, traceable records, and clear ownership before live payouts begin.
If your model, partner setup, or regulatory obligations require KYC or AML review, run those checks before a payout instruction is created or funds are marked releasable. Letting users become payable first and stopping payouts later can create reversals, support escalations, and partner friction.
Gate on the statuses that control your live flow: verified, under review, jurisdiction-restricted, or blocked pending investigation. In staging, an account that fails required verification should never move from "eligible to earn" to "eligible to pay out." Keep release evidence with the rule version and event history.
The core operational question is simple: can you explain who moved what, when, and why? Use idempotent event handling and ledger-backed traceability so retries, duplicate webhooks, or manual replays are less likely to create duplicate fees or payouts.
Record each movement as its own traceable entry: fee assessment, hold, reversal, payout initiation, payout failure, retry, and refund. Test replay of the same inbound event and confirm the ledger changes once. If finance ops cannot trace a failed payout back to the original authorization and fee logic in one chain, you may be carrying audit and partner risk.
If your structure makes you responsible for suspicious activity monitoring, build explicit escalation logic for Suspicious Activity Reports (SAR) and related recordkeeping. SAR reporting and recordkeeping are critical controls, and U.S. oversight spans both federal and state layers.
Assign owners for each decision point: alert review, hold placement, legal or compliance escalation, and case-file preservation. Your evidence pack should be complete enough to reconstruct the event path, related alerts, and partner communications.
If you plan to enable Virtual Currency Business Activity, run it as a separate control track. State scope can include exchanging, transferring, or custodying virtual currency and digital assets, and state harmonization remains uneven even with Model Act adoption activity in 2024.
Define separate controls for asset type, routing, and jurisdictional eligibility based on where customers are served. Use a state-by-state enablement table that blocks unsupported assets or routes before activation. If you apply the highest standard across jurisdictions, make the tradeoff explicit: lower exposure, higher operating cost.
Controls can drift after launch as product logic, payout timing, and partner behavior change. Run recurring tests for uncleared holds, reversals that fail to unwind fee entries, duplicate events, and reconciliation breaks between your ledger and partner reports.
Review exceptions against counsel memos, the state matrix, the funds-flow map, and partner agreements. If manual overrides rise or unresolved breaks accumulate, pause state expansion until the control gap is fixed.
We covered this in detail in A Deep Dive into Florida's Money Transmitter License Rules.
Your evidence pack should show that legal theory, product behavior, and contracts match in production, including failure paths.
Build four artifacts that align with each other: funds-flow diagram, role definitions, exemption analysis, and a state matrix. They should reflect real checkout, onboarding, payout timing, refund handling, and exception behavior.
If you use a partner structure, define each party's role plainly. Where a licensee designates your platform to act on its behalf, some state statutes use authorized delegate. Maine defines this as a person a licensee designates to engage in money transmission on the licensee's behalf. If that applies, show where the designation appears in contracts and operating procedures.
Quick check: ask engineering and finance ops whether the packet matches production behavior, including refund paths, holds, and payout retries.
Your agreements should describe the same control points your product enforces. For internal consistency, document fee timing, who holds funds at each step, what happens on payout failure, and who can reverse, retry, or suspend movement.
Also align contracts, onboarding, and checkout disclosures. Illinois' Uniform Money Transmission Modernization Act synopsis lists key program areas: reporting and records, authorized delegates, timely transmission, refunds and disclosures, prudential standards, and enforcement. Use that as a consistency checklist so customer-facing language and legal documents do not diverge.
Partners typically need operating proof, not just a memo. Include evidence for monitoring, record preservation, and escalation tied to your model's obligations, including Bank Secrecy Act requirements where applicable.
If your structure raises balance-sheet or safeguarding questions, add a focused note on Prudential Standards implications relevant to your model. Keep this scoped to what is relevant. Do not overreach past the facts you can support.
Set explicit owners and triggers for re-analysis when pricing, onboarding, ownership, or payout logic changes. Include governance changes as a trigger: Maine's definition of control includes power to vote at least 25% of outstanding voting interests.
Keep a dated legal-reference check in the pack. In Illinois, the older Transmitters of Money Act is stated as repealed on January 1, 2025, so older legal references can become stale and should be revalidated before expansion.
Launch readiness here means one thing: your structure still works when normal payment flows break, and your evidence stays trustworthy under pressure.
If you run tabletop exercises, choose the failure paths that are highest risk for your operation, then confirm what the ledger shows, what the customer sees, who can act, and which contract or partner rule informs that action. Capture one evidence bundle per scenario so later decisions are traceable (for example: transaction records, status proof, ledger entries, support handling, and owner).
Do not rely on stale risk assumptions. A New York audit of BitLicense oversight identified outdated AML information in approvals, including a case with nearly 4 years between assessment and approval.
Use triage reviews to separate routine processing issues from structure issues and catch documentation gaps early. Exact dashboard breakdowns are an internal design choice, not a requirement established by the cited audit.
The same New York audit found missing or incomplete review evidence in sampled licensing oversight. That included incomplete fingerprinting in two of eight sampled applicants, undocumented tax-warrant verification actions, and missing required financial-report submissions.
As an internal readiness practice, legal, product, and finance can align on one rollback path if partner or regulator feedback changes the required structure. Define what pauses first and who owns external communications.
If you run a final cross-functional readiness review, set named ownership for each failure path, ensure each owner can point to a governing document, and confirm production behavior matches that document.
If a partner, bank, or regulator challenges your model, recover by freezing expansion, narrowing scope, and rebuilding your position from current facts and records, not old assumptions.
Recovery: Re-map custody and control facts immediately, then re-run your analysis.
FinCEN's framing is facts-and-circumstances driven, and its "business model" lens is the subset of facts relevant to that determination. Rebuild your map from payer authorization through settlement, fee capture, refunds, reversals, failed payouts, and held funds. The check is practical: engineering, finance, and legal should all be able to explain the same control-of-funds story from one recent live transaction.
Recovery: Rebuild your state matrix from live product behavior and retest each jurisdictional row.
Do not assume one theory carries nationwide, and do not rely on example-matching alone. FinCEN explicitly notes that models not listed in its guidance may still carry BSA obligations. Treat each state row as launch-ready only when product behavior, contracts, disclosures, and partner role align in that row.
Recovery: Separate fee-related events and restore ledger-level traceability.
Break out principal movement, platform fee, refund, reversal, reserve release, and payout failure into distinct ledger events with shared transaction IDs. Then test both directions: customer event to ledger, settlement, and payout, and ledger entry back to user-visible behavior. If the system only reconciles net totals, your controls may hide where practical control of funds sits and can create filing errors.
Recovery: Align federal and state obligations before relaunch.
FinCEN guidance is interpretive and does not create new regulatory requirements, so filing posture alone is not a substitute for a current model analysis. Before reopening, confirm your federal position, state matrix, partner contracts, and production behavior all describe the same operating model. If flagged late, remediate in jurisdictional cohorts and reopen only where evidence is complete and internally consistent.
Use this sequence in order: document real fund movement, classify risk from those facts, choose structure with explicit tradeoffs, separate state and federal analysis, then test controls before you scale.
Show payer authorization, receipt of funds or value, fee-deduction timing, payout release, refunds, reversals, failed payouts, and held-balance paths. Keep one version that matches production logs and reconciliations.
FinCEN states money-transmitter status is a facts-and-circumstances determination. Your memo should clearly show who receives value, who controls it at each handoff, who directs onward transmission, and when liability ends. If your exact model is not named in guidance, do not assume obligations are out of scope.
Document the chosen model, the tradeoffs you are accepting, and a clear no-go condition that forces redesign. Keep supporting evidence with that decision set: contracts, user disclosures, ledger examples, and exception-handling notes.
For states, maintain a launch matrix by jurisdiction with counsel-reviewed assumptions where applicable. For federal scope, record applicability based on the model you are actually shipping.
Test failure scenarios such as duplicate events, refund races, stuck holds, payout returns, and ledger or customer-status mismatches. Reconfirm your risk assessment before adding jurisdictions, rails, or CVC-related features.
Use the checklist below as an internal working checklist, not as a substitute for counsel analysis:
After completing the checklist, use the Gruv docs to map implementation details for controls, traceability, and payout operations.
No. Platform fees alone are not the legal test. The answer depends on the actual funds flow, including who receives value, who controls release and timing, and what happens in refunds, reversals, failed payouts, and held-funds states.
Assume there is no universal minimum checklist. Analyze state licensing posture and federal MSB, AML, BSA, and KYC obligations separately for the exact funds flow, and do not launch until counsel issues written memos for the shipped model. If digital assets are in scope, add the applicable California DFAL timing to your plan.
Do not assume a later switch will be clean. Different structures change contracts, control boundaries, disclosures, and operating ownership, so counsel will need to compare both models on the actual facts. Keep transaction-level records, contracts, funds-flow maps, and operational evidence clean now if you want optionality later.
Treat agent-of-payee and payment-processor positions as legal theories to prove, not labels that are safe by default. Test whether contracts, disclosures, and operations all support the same control and liability story for each state where you launch.
Give counsel a current funds-flow map, state launch plan or matrix, partner agreements, user-facing payment and payout disclosures, and live terms with clear dates. Include fee timing, refund, reversal, failed payout, and held-funds paths, plus ledger examples tied to real transactions. Also provide the documented method for determining when transmission liability is extinguished.
Pause when you cannot evidence when transmission liability ends. Also pause when contracts, disclosures, settlement reporting, and ledger behavior do not match, or when fee timing and exception paths are not traceable. If digital-asset scope is expanding, refresh state review before scaling.
Avery writes for operators who care about clean books: reconciliation habits, payout workflows, and the systems that prevent month-end chaos when money crosses borders.
Priya specializes in international contract law for independent contractors. She ensures that the legal advice provided is accurate, actionable, and up-to-date with current regulations.
Educational content only. Not legal, tax, or financial advice.
**Start with the business decision, not the feature.** For a contractor platform, the real question is whether embedded insurance removes onboarding friction, proof-of-insurance chasing, and claims confusion, or simply adds more support, finance, and exception handling. Insurance is truly embedded only when quote, bind, document delivery, and servicing happen inside workflows your team already owns.
Treat Italy as a lane choice, not a generic freelancer signup market. If you cannot separate **Regime Forfettario** eligibility, VAT treatment, and payout controls, delay launch.
**Freelance contract templates are useful only when you treat them as a control, not a file you download and forget.** A template gives you reusable language. The real protection comes from how you use it: who approves it, what has to be defined before work starts, which clauses can change, and what record you keep when the Hiring Party and Freelance Worker sign.