Choosing Between a New York Money Transmitter License and BitLicense

Start With the Activity#

A fiat remittance service and a custodial crypto service raise different New York licensing questions. A product that combines them can need both a Money Transmitter License (MTL) and a BitLicense. Start with the asset, the customer relationship and the activity at each step, then decide which entity needs authorization.

The comparison below separates the principal routes. A BitLicense does not authorize every financial service, and choosing a trust charter entails banking supervision and an approved business scope.

For a prelaunch team, filing readiness means a complete application and credible plans, staff and tested controls. It does not mean conducting regulated customer transactions before authorization.

Start with the licensing scope test#

Part 200 defines virtual currency business activity by activity involving New York or a New York resident. An out-of-state incorporation does not remove that exposure. Identify the relevant customers and counterparties alongside where the business operates.

Under section 200.2(q), the five categories are receiving virtual currency for transmission or transmitting it; custody or control for others; customer-facing buying and selling; customer-facing exchange; and controlling, administering or issuing virtual currency. The transmission category excludes certain nonfinancial transactions involving no more than a nominal amount. Pure software development and dissemination is not itself a licensed activity.

Build the scope test in four passes:

• List each product action and whether it moves fiat, virtual currency or both.
• Name the entity providing each service and the customers with New York connections.
• Document custody permissions, contractual obligations and partner roles.
• Record the proposed licensing basis and the facts counsel still needs.

The example is provisional: counsel must assess the actual agreements and permissions. Customer location, custody access and the entity receiving fiat can change the result.

Choose your licensing path without guessing#

Choose according to the regulated services and the powers the business needs. A simple remittance model should not pursue a trust charter merely because the charter can support a wider set of activities.

New York Banking Law section 641 covers businesses receiving money for transmission or transmitting it, as well as selling or issuing checks. It includes specified institutional exemptions and agent provisions. Assess those against the contracts and actual flow rather than assuming every platform is a transmitter. FinCEN registration does not replace applicable state authorization.

A business chartered under New York Banking Law can conduct approved virtual currency activity without a separate BitLicense when the Superintendent has authorized it. NYDFS also explains that a limited purpose trust company can transmit money in New York without a separate MTL and can exercise fiduciary powers. The charter alone does not approve every proposed crypto activity.

For the decision record, answer two questions:

• Does the business need fiat transmission authority, virtual currency authority or both?
• Does the proposed service require fiduciary powers or another capability that favors a charter?

Map your business model to regulated activities#

Map each feature by who controls customer assets at each step. That is where licensing exposure can appear.

A crypto payout product may receive fiat from a business, buy virtual currency, hold it briefly and send it to a contractor. Trace each step through the legal entities. A partner executing conversion does not automatically cover your entity’s separate receipt or custody activity.

These four product steps help organize the review; issuance is a separate Part 200 category that must also be assessed if the product creates or administers tokens.

A software-only label cannot resolve a model in which the provider actually controls customer assets or executes regulated services. Record who holds keys, can change a destination, authorizes conversion and owes delivery to the customer.

Run one checkpoint across every feature: who controls customer assets at this step. For each row, keep a short evidence note with the permission holder, control type, proof item, and confidence level. If control is direct and confidence is not high, pause launch assumptions for that feature and send it to counsel for NYDFS scoping review. If you also need to map multistate licensing exposure, A Guide to the Money Transmission Modernization Act (MTMA) is a useful companion.

Build the compliance controls before you file#

Design controls before filing and test them without starting unauthorized business. For a new applicant, use synthetic transactions, sandbox alerts and documented exercises. If the entity already conducts legally authorized activity, distinguish that operating evidence from the proposed New York service.

Part 200 contains substantive requirements for compliance, capital, customer-asset protection, records, AML, cybersecurity, business continuity, disclosures and complaints. Use the applicable sections to build a requirement-to-control map.

For example, section 200.15 requires risk-based AML controls, independent testing, qualified compliance responsibility and personnel training. The written AML policy needs board or equivalent governing-body approval. Include sanctions controls and an escalation process appropriate to the actual services.

An internal readiness exercise can make those controls concrete:

• Assign control owners and test a simulated customer onboarding case.
• Inject a sanctions-match scenario and show the required block, reject or escalation decision.
• Reconcile a simulated custody movement through approval, asset records and the customer obligation.
• Run a service-recovery exercise and retain results, gaps and remediation owners.

Record whether each control is designed, tested or operating in an authorized business. Do not describe a simulation as a live customer transaction, and do not infer permission to launch from a successful test.

Assemble the evidence pack NYDFS will expect#

Use the current BitLicense checklist linked from NYDFS’s application page as the filing inventory. The three categories below organize internal preparation; they are not the complete required submission.

Keep each record tied to the applicant and proposed scope:

• Financial records: historical statements where available, clearly labeled projections, funding sources and the capital plan required for the proposed business.
• Compliance records: the applicable policies, responsible personnel, approval records and labeled control-test results.
• Ownership records: legal structure, organization chart, ownership and control-person information, and the required applicant disclosures.

Use a version ID, named approver and effective date for policies and plans, and attach supporting records where appropriate. Reconcile ownership, entity names and financial figures across documents before submission.

A prelaunch applicant can provide accurate plans and simulated test results without claiming an operating history it does not have. Label projections separately from historical financial statements and identify unresolved findings honestly.

Plan the application sequence and internal owners#

Treat sequencing as a control. Move in phases, and do not advance until each phase has complete evidence and internal signoff.

Sequence the work as scope analysis, authorization choice, control design and testing, checklist completion, internal review and filing. Keep customer launch conditional on the required approval and any conditions imposed.

This owner model is an internal accountability choice, not a claimed NYDFS mandate. It helps because NYDFS describes rigorous standards and states it conducts examinations and oversight of licensed entities.

Separate preparation milestones from regulatory approval:

• Plan the time needed to prepare a complete and tailored application.
• Track DFS information requests and response ownership separately.
• Do not promise a fixed approval duration; completeness does not guarantee approval.

Use a planning window with dependencies for internal scheduling. An application receipt, NMLS number or substantive-review start is not permission to launch.

Handle conditional BitLicense carefully#

A conditional license is an exercise of the Superintendent’s discretion under section 200.4(c). It can allow an applicant that has not met every Part 200 requirement at licensing to operate under specified conditions and heightened review.

The rule provides a two-year term unless renewed or the conditions are removed, and permits additional conditions, suspension or revocation. The decision considers the business, volume, risk mitigation, regulatory registrations or authorizations and relevant experience. A conditional license is not an automatic entitlement.

NYDFS’s June 2020 partner framework was published as a request for comments on a proposal. Do not treat that proposal as a standing approval for any startup that signs with a licensed partner. Establish the authority and conditions applicable to your own arrangement.

For any partner-dependent model, complete these checks:

• Verify the partner's current NYDFS authorization and match it to planned activity scope.
• Document and sign service boundaries and accountability by function.
• Set record access rights and delivery expectations in writing.
• Define breach and remediation notification responsibilities.
• Define how the business will address expiry, renewal, changed conditions or a transition to full authorization.

A service agreement can allocate tasks and record access. It cannot grant your entity regulatory authority. Obtain a clear decision on which entity is permitted to perform each regulated function before customer launch.

Avoid the failure patterns that delay approvals#

An incomplete packet or inconsistent business description can make follow-up harder. Use a short issue register to distinguish missing mandatory documents, conflicting facts and planned improvements.

Resolve material uncertainty about activity and entity scope before choosing an application. Where interpretation remains disputed, seek a pre-application discussion rather than silently choosing the easiest form.

Policies should match the service described in the application. Check ownership records, governance roles and control responsibility together; outsourced tasks still need a clearly identified accountable entity.

Use enacted rules and current NYDFS guidance for requirements. Keep proposed partner frameworks separate from granted authorizations, and avoid treating unrelated federal filings or city development plans as licensing authority.

Before submission, verify:

• The activity map identifies the responsible entities and relevant New York connections.
• Mandatory checklist items and fees are included, subject to any DFS-approved exception.
• Ownership, financial and policy documents agree on material facts.
• Test evidence is labeled accurately and does not imply unauthorized live activity.
• Conditional or partner assumptions have a documented authorization basis.
• Material unresolved issues have been reviewed with the appropriate internal owner or DFS.

These are internal quality checks. Follow the current checklist and any case-specific direction from DFS when resolving outstanding items.

Set up operating controls for day one after approval#

After approval, run the authorized service within its conditions. Carry the design and test evidence forward into production monitoring, incident handling and supervisory records.

Track permitted activities, approved entities and any limits in one authorization record. Review a material change before enabling it; adding custody, a new service or a different operating entity can require further regulatory analysis or approval.

Run post-approval controls as production work. Set fixed control attestations, maintain incident logs with timestamps and dispositions, and track policy updates with approvers and effective dates. Keep a retention map that shows where evidence lives, who can retrieve it, and how quickly it can be produced.

Design custody, payout, and transaction flows to produce audit-ready records by default. Link custody actions to approvals, attach reconciliation IDs and exception notes to payout activity, and tie monitoring alerts to the underlying account event and customer communication. The risk to avoid is fragmented evidence across finance, compliance, and operations.

For entities subject to the annual Part 500 filing requirement, April 15 is the deadline for the prior calendar year’s Certification of Material Compliance or Acknowledgment of Noncompliance, as applicable. Assess exemptions and actual compliance before selecting the filing. Use DFS’s cybersecurity resources for the applicable requirements.

The table’s daily and weekly routines are illustrative operating choices, not universal regulatory deadlines. Maintain a separate calendar for requirements imposed by the rules and the entity’s approval conditions.

Budget the application and track changes#

Section 200.5 sets a $5,000 initial BitLicense application fee, nonrefundable if the application is denied or withdrawn. This is not the total cost of launching: legal preparation, staffing, technology, capital, customer protection arrangements and ongoing supervision need separate budgets.

For counterparty checks, use the current NYDFS regulated-entity register and distinguish BitLicenses, combined licenses and trust charters. A count of approved firms does not predict your review time or prove that a partner may perform your proposed service.

Keep a dated register of unresolved decisions with the source, affected feature, owner and next review point. Useful entries include:

• Whether a new asset or feature changes the authorized activity.
• Whether a partner’s actual authority covers the service in the contract.
• Whether a conditional license needs renewal or a changed condition.

Escalate an unresolved item when it affects authorization, customer-asset protection or the launch scope. Lower-impact process improvements can retain their own owner and delivery date.

Conclusion#

Complete one activity map showing assets, entities, customer locations and control permissions. Then select the authorization route, prepare the current checklist and test the proposed controls in a permitted environment. Customer launch follows the required approval, not the filing date.