Choosing Between a New York Money Transmitter License and BitLicense

Introduction#

Licensing scope is the first call, not form filling. If you are evaluating New York BitLicense exposure, decide whether your activity points to a BitLicense, a limited purpose trust company path, or a narrower next step while your model is still constrained.

Start from what the New York State Department of Financial Services has clearly stated. NYDFS issued 23 NYCRR Part 200 in June 2015 under New York Financial Services Law. It also says it has granted numerous virtual currency licenses and charters under Part 200 or the limited purpose trust company provisions of New York Banking Law.

Then separate confirmed requirements from open items. In the public excerpts used here, you do not have a definitive current approval count or reliable timeline, fee, or filing duration benchmark. Keep those as open questions and validate them before tying licensing assumptions to a launch date, using the scope test, path selection checkpoints, and filing readiness checklist in this article.

Start with the licensing scope test#

Separate licensing analysis from tax residency on day one. Keep NYDFS scoping and New York personal income tax rules in different lanes before you compare a BitLicense path or a charter route.

The tax sources in this pack address personal income tax law and guidance, not BitLicense triggers. In that tax context, a person can have only one domicile, and resident status can include a day-count test tied to a permanent place of abode, including the 184-days-or-more threshold. Use that as tax context only, not as a licensing rule.

For licensing scope, anchor to NYDFS virtual currency materials. NYDFS says it issued 23 NYCRR Part 200 in June 2015 and has granted numerous virtual currency licenses and charters. Treat this as an active area where every assumption needs a documented basis.

Build the scope test in four passes:

• List each product action in plain language, such as receive, convert, hold, and payout.
• Add New York nexus evidence for each action, including customer, counterparty, and operating location.
• Assign a provisional review bucket for each action, then flag for legal confirmation.
• Score confidence as High, Medium, or Low based on documented facts. If nexus is unresolved, keep it unresolved.

Decision rule: if an item may implicate NYDFS virtual currency requirements, move it to deeper NYDFS scoping before launch commitments. Keep this page short so legal, compliance, and leadership can review it quickly and update it as facts firm up. If you want a deeper dive, read Moving From Hourly to Project-Based Rates.

Choose your licensing path without guessing#

Choose the path based on control of regulated activity, not on the label that sounds fastest. The core tradeoff is control versus dependency, and any charter substitution assumption stays open until counsel confirms it for your model.

In New York, the BitLicense rule set is described for virtual currency services tied to business activity in the state. A Money Transmitter License is state-issued, and FinCEN MSB registration does not replace state licensing. Keep that boundary explicit in your decision notes.

A Limited Purpose Trust Charter belongs in the same comparison because NYDFS oversight can include licensing or chartering. These sources do not confirm when a charter substitutes for a standalone BitLicense in your case, so mark that as requires legal confirmation.

Use two judgment rules:

• If you control core regulated functions, plan for a full license posture.
• If you are considering Conditional BitLicense, treat eligibility and timing as requires legal confirmation.

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.

Use this map as a scoping tool, not a legal conclusion. NYDFS confirms 23 NYCRR Part 200 was issued in June 2015 and says it has granted numerous virtual currency licenses and charters. This includes routes tied to limited purpose trust company provisions under New York Banking Law. Your map should be detailed enough to support either a licensing path or a charter path if counsel redirects you.

The review flags below are working labels, not a complete list of NYDFS trigger categories.

Agency versus principal structure can change how this map is assessed, but this section does not set out the legal test. A software-only label may not settle scope on its own if operations effectively direct conversion, custody, or payout.

Run one checkpoint across every feature: who controls customer assets at this step. For each row, keep a short evidence note with 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. You might also find this useful: A Guide to the Money Transmission Modernization Act (MTMA).

Build the compliance controls before you file#

File after your controls can show operating proof. If controls still exist as draft language, treat your application as not yet ready.

Start from confirmed anchors. NYDFS issued 23 NYCRR Part 200 in June 2015 and says it has granted numerous virtual currency licenses and charters under Part 200 or limited purpose trust company provisions of New York Banking Law. A BitLicense is tied to Virtual Currency Business Activity, which can fall into five activity types involving New York or New Yorkers. Scope is activity driven, not branding driven.

The sources here do not set a single mandatory pre-filing control framework, so use a practical baseline tied to your actual activities and risks. The goal is operating credibility, not longer policy documents.

To make that concrete:

• Assign a clear owner for each control area.
• Keep an evidence log of what ran and what happened.
• Use a testing cadence you can sustain and track missed checks to closure.
• Define escalation paths for failed controls, including who can pause changes.

Decision rule: as an internal readiness standard, avoid filing while core controls are still being built. If you cannot show recent proof on key high-risk steps in your flow, treat readiness as low.

Keep the software only assumption honest. The FAQ states software development and dissemination, as a purely technical service, does not by itself require a BitLicense, but real product use can still involve licensable activity. Related: Escaping the Algorithm: How to Build a Freelance Business That's Platform-Independent.

Assemble the evidence pack NYDFS will expect#

Treat this as an internal readiness pack, not a confirmed NYDFS filing checklist from these excerpts. The practical test is whether each document is traceable to live operating activity, not whether a PDF exists.

The excerpts still support document discipline. The SEC S-1/A example shows amendment tracking, a filing date, and a registration number. The White House report includes a section on improving AML/CFT and sanctions frameworks, and the FSOC report includes a section on regulation of crypto-asset activities. The CRPTO Act reference is explicitly conditional if enacted, so keep proposed law separate from current obligations.

Use three packet sections as an internal structure, not as NYDFS-required categories from these excerpts. Pair each with proof that controls are running:

• Financial Statements: latest signed statements plus reconciliation outputs, close checklists, and signoff records showing who reviewed exceptions.
• Compliance Policies: current policy text plus test logs, issue tickets, remediation notes, and dated approvals aligned to current operations.
• Ownership Information: cap table and control person records plus board or officer change logs so legal ownership and practical governance stay aligned.

Run a document integrity screen before labeling anything submission ready. This is an internal quality gate, not a claimed NYDFS template from these excerpts. At minimum, each artifact should include a version ID, named approver, effective date, and a pointer to supporting operating proof. If documents conflict on the same control or ownership fact, stop and reconcile before drafting application narratives.

The common failure mode is inconsistency, not missing prose. Mismatched ownership records, stale policy versions, and unsupported control claims can erode trust quickly once review begins. If any core category is below testable, pause filing and fix evidence integrity first.

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.

NYDFS provides the legal frame first: virtual currency business activity is handled under 23 NYCRR Part 200 or under limited purpose trust company provisions of New York Banking Law. Use that to set order of operations: confirm scope, choose path, build controls, finalize the evidence pack, run pre-submission review, then file.

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.

Plan timelines with explicit knowns and unknowns:

• Known: standards are rigorous, and oversight continues after licensing.
• Known: a licensed firm can still face serious deficiencies later. The Coinbase consent order references examination coverage from July 1, 2018 through December 31, 2019 and an independent consultant report in February 2021.
• Unknown from these materials: any standard approval timeline you can safely promise externally.

Use a launch window, not a single fixed date, until pre-submission review is complete. If a gate slips, move external launch commitments with it. Want a quick next step for "new york bitlicense"? Browse Gruv tools.

Handle conditional BitLicense carefully#

Treat a Conditional BitLicense as a dependency choice, not a shortcut. If you plan to rely on a licensed partner, define control boundaries before you commit to launch timing.

What is confirmed here is limited. New York virtual currency licensing sits under 23 NYCRR Part 200, and NYDFS also references the limited purpose trust company path under New York Banking Law. The materials here do not establish clear Conditional BitLicense eligibility criteria, required documents, timing, or common implementation patterns.

The tradeoff is speed versus control. Partner reliance may support faster entry, but it can also increase exposure to another firm's controls, response speed, and record quality during oversight.

Use this due diligence gate before committing:

• 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.
• Include a concrete transition trigger for full licensing readiness.

As a process warning, the OSC audit found that two of eight sampled applicants had not fully completed fingerprinting before approval. Do not treat prerequisites as cleanup work. Track completion evidence before submission.

Decision rule: use the conditional route only when partner governance, service boundaries, and transition terms are explicit, signed, and testable. If any of these remain informal, pause and evaluate the full Part 200 path or trust company path directly.

Avoid the failure patterns that delay approvals#

Delay risk can increase when scope is unresolved, operating evidence is thin, or the authority chain is mixed.

Red flag one is unresolved scope. Use a hard checkpoint before filing: document activity classification step by step against 23 NYCRR Part 200. If classification is still disputed, pause.

Red flag two is paper-only controls: policies exist, but current operating evidence is hard to produce. Red flag three often appears with it: Ownership Information, governance roles, and day-to-day control ownership do not match across core records. If those records conflict, plan for rework before filing.

Red flag four is source quality. Anchor legal framing to NYDFS primary materials, including 23 NYCRR Part 200. Treat other materials carefully. The FederalRegister.gov Web 2.0 page says it is not an official legal edition and should be checked against the official Federal Register for legal research. The OCC item shown there is a proposed rule dated 03/02/2026 with comments through 05/01/2026. The 04/27/2023 congressional hearing on spot market regulatory gaps is context, not binding law.

Use this pre-filing kill-switch checklist. If any item is true, stop submission:

• Classification remains unresolved under Part 200.
• Operating evidence for key control claims is missing.
• Ownership Information conflicts with governance or control-owner assignments.
• A key legal statement treats a proposed rule or informational page as final authority.
• NYDFS primary materials are not clearly reflected in the internal legal memo.
• Open issues do not have a named owner and closure date.

If a kill switch fires, fix evidence integrity first, then resume filing.

Set up operating controls for day one after approval#

Approval starts supervision, not the end of preparation. For a New York BitLicense launch, treat any control that cannot produce current evidence as a day-one risk.

Under 23 NYCRR Part 200, a BitLicense is required for virtual currency business activity in New York State, and applications must be submitted to and approved by NYDFS. NYDFS also identifies its Virtual Currency Unit teams as responsible for application oversight and ongoing monitoring of licensees, so plan your first 90 days for possible supervisory questions.

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.

If your entity is subject to 23 NYCRR Part 500, use cybersecurity timing as a hard calendar anchor. DFS states Part 500 was enacted on March 1, 2017 and amended in 2020 to move annual certification filing from February 15 to April 15. Put April 15 on the control calendar and build monthly support files so certification is assembled continuously.

If your stack supports policy gates, audit trails, and reconciliation checkpoints, turn them on where appropriate. End the first quarter with one rule: if any control area cannot produce complete evidence on schedule, reduce exposure, remediate, then scale.

Keep a known vs unknown tracker for 2026 changes#

Use one shared tracker to separate what is confirmed from what is unresolved before launch decisions are made.

In this excerpt set, the confirmed items are date signals only. They are an S-1/A filed on March 4, 2026, a Form 10-K for the fiscal year ended December 31, 2025, and a CRS report dated 02/15/2023. Treat these as freshness markers, not licensing answers.

Keep unresolved items clearly labeled, including current license holder counts, timeline expectations, and Conditional BitLicense practice status. Do not fill those gaps with estimates.

For each assumption, track affected pathway, expected authority, confidence label, impact, owner, and next review point. Use strict confidence labels:

• High confidence: directly supported by the provided primary text.
• Medium confidence: partially supported, with interpretation or recency risk.
• Low confidence: no direct support yet, or conflicting signals.

Decision rule: if an assumption is low confidence and high impact, escalate for legal confirmation before customer launch.

The NYC Blockchain Plan calls for mechanisms to track progress and coordinate efforts. Apply that discipline here while keeping licensing conclusions tied to NYDFS authority.

Conclusion#

The winning move is disciplined sequencing: confirm scope first, choose your authorization path second, and file only when controls are operating with evidence, not assumptions.

From the confirmed record, firms conducting Virtual Currency Business Activity in New York must be authorized by NYDFS through either a BitLicense or a Limited Purpose Trust Charter. New York's framework includes 23 NYCRR Part 200, issued in June 2015, and authorized firms are subject to ongoing supervision. The practical question is not only whether you can file, but whether your operation is ready to be supervised.

Your immediate next step is simple: complete the scope verdict table and path matrix before investing in full application drafting. In that same pass, label each assumption as confirmed, provisional, or unresolved, and escalate unresolved high-impact items before you lock launch commitments.

Do not treat policy text as a substitute for operating proof. The enforcement record highlights failure modes such as deficient partner due diligence and deficient AML and transaction monitoring programs. Keep your standard at evidence you can retrieve and defend.

Use one rule tomorrow: proceed only when all three gates are true.

1. Scope gate: activities are mapped to Virtual Currency Business Activity and New York nexus.
2. Path gate: BitLicense or Limited Purpose Trust Charter is selected, with unresolved points clearly flagged for legal review.
3. Evidence gate: AML-related controls to guard against money laundering and other illicit activity are live, tested, and documented for supervisory review.

This keeps confidence anchored to what NYDFS has clearly stated while separating confirmed requirements from unresolved assumptions. Want to confirm what's supported for your specific country/program? Talk to Gruv.