How to Structure Platform Fees Without Violating Money Transmission Laws

How platform fees interact with money transmission laws based on funds flow, not product labels#

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:

• Product defines how fees and payout flows are structured.
• Engineering implements where funds are recorded or held in practice.
• Finance owns reconciliation, timing, and exception handling.
• Compliance maps the real flow to licensing and BSA-obligation analysis.

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.

What to prepare before you design fee logic#

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.

Assign owners and set one decision date#

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.

Gather live customer and partner documents#

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.

Define launch jurisdictions and access boundaries#

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.

Build one evidence folder for review#

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.

Map the full funds flow before discussing exemptions#

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.

Map the live transaction flow from authorization to payout#

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.

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.

Make fee timing explicit#

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#

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#

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.

Set a hard checkpoint before exemption analysis#

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.

Classify your model against money transmission triggers#

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 live flow#

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:

1. Who receives money or monetary value first?
2. Who can move it onward?
3. Who can delay, reroute, or release it?
4. What record proves each handoff?

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 framing#

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 legal positions as hypotheses to prove#

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:

• signed contracts defining party roles
• checkout and payout disclosures users actually see
• sample settlement and exception reports
• ledger examples showing fee timing and payout timing
• one real failed-payout trace and one refund trace

Flag mismatches immediately, especially when contract language and operational control do not match.

Pause launch if fund control is unclear#

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.

Compare your fee structure options before you commit#

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#

Start with a directional comparison, then replace assumptions with facts from counsel, partner diligence, and your funds-flow map.

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#

Validate fee visibility before finance signs off on unit economics. Request the same evidence for each option:

• one sample settlement file
• one sample monthly invoice or fee statement
• one refund trace
• one dispute trace
• one failed payout or reversal trace
• the exact user-facing fee disclosure shown at checkout and payout

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 compliance and operations work#

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 an explicit stop rule before integration#

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 your regulatory path by state and scope#

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.

Build the matrix around real access, not just incorporation state#

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.

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.

Test state definitions with targeted reference checks#

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.

Layer federal obligations on top of the state answer#

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 the launch gate and document it like a product requirement#

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.

Build compliance controls into product and operations#

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.

Put KYC and AML gates before payout commitment#

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.

Make every movement explainable with idempotency and a ledger#

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.

Create SAR escalation paths with real ownership#

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.

Split Virtual Currency Business Activity from fiat controls#

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.

Test drift after launch, not just before go-live#

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.

Build the legal and partner evidence pack#

Your evidence pack should show that legal theory, product behavior, and contracts match in production, including failure paths.

Assemble a counsel-ready packet from live product facts#

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.

Align contract language with fee timing, custody boundaries, and disclosures#

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.

Include partner-facing control evidence, not only legal conclusions#

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.

Document ownership and change triggers before assumptions go stale#

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 log. 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.

Validate launch readiness with failure scenarios#

Launch readiness here means one thing: your structure still works when normal payment flows break, and your evidence stays trustworthy under pressure.

Run tabletop tests on the highest-risk failure paths#

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.

Validate evidence quality in operations triage#

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.

Pre-agree a rollback path for structure changes#

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.

Hold one production-readiness review with named ownership#

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.

Common mistakes and how to recover fast#

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.

Mistake 1. Saying "We are just software"#

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.

Mistake 2. Stretching one exemption across all states#

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.

Mistake 3. Netting logic product and finance cannot explain#

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.

Mistake 4. Treating FinCEN/MSB steps as the complete answer#

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.

Conclusion and copy-paste launch checklist#

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.

Map the full funds flow before discussing status#

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.

Classify trigger risk from documented facts, not labels#

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.

Compare structure options only after the risk picture is written down#

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.

Run state and federal analysis as separate but connected tracks#

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.

Implement controls and keep evidence before expansion#

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:

• Funds-flow diagram documented and aligned with operating records
• State matrix documented with counsel-reviewed assumptions where applicable
• Federal obligations assessed for applicable FinCEN/BSA relevance
• Chosen structure documented with explicit tradeoffs and no-go conditions
• Controls, contracts, and incident response tested in failure scenarios
• Expansion criteria documented before adding jurisdictions or payment features

After completing the checklist, use the Gruv docs to map implementation details for controls, traceability, and payout operations.