A BitLicense is mandatory the moment a business performs any of five defined virtual currency activities involving New York or New York residents under 23 NYCRR Part 200. If that test applies to you, the first move is not drafting a business plan. It is pulling the BitLicense Application Checklist and building a near‑operational compliance and technology stack, because NYDFS will not begin substantive review until the file is complete.
What the BitLicense covers and who must apply
The New York State Department of Financial Services administers Part 200 as a standalone virtual currency licensing regime, separate from money transmission law and distinct from most other US state frameworks. It applies to anyone conducting "virtual currency business activity" tied to New York or New York residents, regardless of where the company is incorporated.
Section 200.2(q) enumerates five licensable activities: receiving virtual currency for transmission or transmitting it; storing, holding, or maintaining custody on behalf of others; buying and selling virtual currency as a customer business; performing exchange services; and controlling, administering, or issuing a virtual currency. A custodial wallet provider, an exchange matching New York buyers and sellers, and a stablecoin issuer with New York redemption rights all fall inside this net.
Merchants accepting crypto for goods and purely non‑custodial software (wallets that never touch customer keys) generally sit outside scope. A New York BitLicense obligation can attach to an out‑of‑state or offshore firm the instant it onboards New York residents, which is the single most common surprise for founders assuming geography protects them.
Pre-application checklist: what you need before you file
NYDFS runs the process through the Nationwide Multistate Licensing System, the same infrastructure used for money transmitter licensing nationally. Build your file in this order:
- Open an NMLS company account and record the NMLS identification number; it must appear on every hard‑copy attachment you later submit.
- File Form MU1 (company) and MU2 (individual control persons) with accurate ownership and organisational detail.
- Assemble corporate records: certificate of formation, bylaws or operating agreement, capitalisation table, and an organisational chart showing every affiliate.
- Prepare audited financial statements where available, or credible pro forma projections if the business is pre‑revenue.
- Complete background checks and fingerprinting for every control person and beneficial owner above the disclosure threshold.
- Draft the technical and compliance attachments the BitLicense Application Checklist specifically demands: AML programme, cybersecurity programme, business continuity plan, and custody policy.
Missing or thin attachments at this stage are the single biggest driver of delay once the file reaches NYDFS.
How much capital and bond will NYDFS require?
There is no published fixed capital minimum. Under 23 NYCRR §200.8, the Superintendent sets capital requirements case by case, weighing transaction volume, the nature of assets held, and the firm's overall risk profile.
Customer protection is more concrete. Section 200.9(a) requires either a surety bond or a trust account sized to cover customer liabilities.
- Guidance commonly cites a practical floor of $500,000 for the bond or trust account, though the Superintendent can require more as volume grows.
- Custodial obligations generally demand one‑to‑one asset backing, so customer virtual currency cannot be commingled, lent, or rehypothecated.
- A supervisory assessment under §206 funds NYDFS's ongoing oversight, billed quarterly with an annual true‑up rather than a single fixed fee.
Pro Tip: Model your bond or trust account against projected transaction volume twelve months out, not launch‑day volume. NYDFS will ask why your protection scales with growth, and "we'll increase it later" reads as an unfinished plan.
Which compliance controls must exist before you file?
NYDFS expects a working control environment, not a policy binder written the week before submission. Two regimes stack on top of each other here.
The federal baseline comes from the Bank Secrecy Act and FinCEN registration as a money services business: a written AML programme, customer due diligence, ongoing transaction monitoring, and SAR and OFAC screening processes. New York layers its own expectations on top, including travel rule compliance for qualifying transfers and enhanced recordkeeping tailored to virtual currency.
Separately, 23 NYCRR Part 500 imposes New York's standalone cybersecurity rule on BitLicensees:
- A designated Chief Information Security Officer reporting to the board.
- Periodic penetration testing and vulnerability assessments with documented remediation.
- Annual certification of compliance and prompt reporting of qualifying cybersecurity incidents.
- A named compliance officer with direct board reporting lines and independent testing of the AML and cybersecurity programmes.
Reviewing account security fundamentals against current practitioner standards, such as account security best practices, is a useful sanity check before you finalise your own cybersecurity documentation.
Pro Tip: Build an exam‑ready documentation index before you file, not after approval. NYDFS examiners will ask for the same evidence repeatedly across the licence's life, and a poorly indexed archive costs far more in year two than in month one.
How long does the BitLicense process actually take?
The mechanics start on NMLS: open the company account, file MU1/MU2, and keep the NMLS identification number on every attachment thereafter, including paper submissions.
- Preparation and drafting (three to six months). Corporate records, AML and cybersecurity policies, and technical architecture documentation are compiled and internally reviewed.
- Completeness review. NYDFS checks the file against the BitLicense Application Checklist before any substantive analysis begins. Missing attachments, inconsistent ownership disclosures, or undocumented technical controls generate deficiency letters and reset the clock.
- Substantive review. Examiners assess capital adequacy, custody arrangements, and control effectiveness once the file is facially complete.
- Conditional approval and final issuance. Some applicants receive a conditional licence under §200.4 while final conditions are satisfied.
Practitioner experience places realistic total timelines at 12 to 30 months or longer, with incomplete submissions and complex ownership structures the primary cause of the longer end. Firms that invest six to twelve months in pre‑application readiness routinely cut months off substantive review, because examiners spend less time chasing missing evidence.
Common pitfalls that delay or derail applications
Completeness, not substance, is where most applications stall. NYDFS will not open a meaningful technical or capital review until the checklist is satisfied, so a facially incomplete file simply sits.
- Checklist gaps: missing attachments, unsigned policies, or inconsistent figures between MU1/MU2 and supporting exhibits.
- Related‑entity exposure: activities performed by affiliates or group companies can pull the whole group into NYDFS's scope, particularly where a parent or sister entity touches New York users.
- Document sprawl without version control, making it hard to prove which policy version was actually operative on a given date.
Map your corporate group's virtual currency activity across every jurisdiction before you file, not after a deficiency letter asks about an affiliate you had not disclosed.
Pro Tip: Treat every submitted document as a permanent audit record. Build a rapid‑response template now for deficiency letters, so a request that arrives on a Friday does not sit unanswered until Monday.
BitLicense or trust company charter: which fits your model?
Some founders bypass the BitLicense entirely by chartering a limited purpose trust company under New York Banking Law. The two paths diverge on more than paperwork.
A trust company charter carries fiduciary powers a BitLicense does not, useful for custody‑heavy or asset‑management models. A standalone BitLicense suits firms focused on exchange, transmission, or exchange services without fiduciary ambitions, though money transmission implications still apply. Capital regimes differ too: trust charters typically demand a different, often higher, capital and governance standard reflecting broader permissible activities.
The right choice depends on your intended product roadmap and capital appetite, not administrative convenience. A firm planning tokenised custody or trust services should model the charter route early, since retrofitting fiduciary powers onto an existing BitLicense later is far harder than choosing correctly at formation. Engage counsel before selecting a structure, because switching paths mid‑application effectively restarts the clock.
What happens after the BitLicense is approved?
Licensing is the start of a supervisory relationship, not the end of one. NYDFS expects ongoing evidence that the controls described in your application remain operative.
- Quarterly financial statements and audited annual statements, with NYDFS retaining examination access to books and records at any time.
- Annual cybersecurity certification under Part 500, continuous incident reporting obligations, and periodic AML programme testing to confirm the controls still match actual transaction patterns.
- A recurring supervisory assessment under §206, billed quarterly with an annual true‑up, meaning regulatory cost is a permanent operating line, not a one‑off launch expense.
Budget for examiner visits and document requests as a standing cost centre. Firms that treat post‑licence compliance as maintenance rather than a fixed obligation tend to fall behind on certifications within eighteen months of approval.
Do you need a full BitLicense or does a limited exemption apply?
Not every business touching virtual currency needs the full licence. NYDFS has carved out specific limited exemptions, and misreading them in either direction wastes months.
Merchants and consumers using virtual currency solely to buy goods or services for their own use fall outside Part 200's scope entirely. Non‑custodial software developers who never control customer keys or funds are similarly outside the licensable activities defined in §200.2(q). A limited business activity framework also exists for firms operating at very small scale, though this exemption is narrow and conditional, not a general safe harbour for early‑stage startups.
The test is functional, not descriptive. Calling your product a "wallet" or a "platform" in marketing copy does not determine your regulatory status. What matters is whether you actually receive, transmit, store, buy, sell, exchange, or control virtual currency on behalf of New York residents. A custody feature buried inside an otherwise non‑custodial app can trigger the full licensing requirement even if custody was never the intended core product.
Where the analysis is genuinely ambiguous, run a documented scope assessment against each of the five enumerated activities individually rather than against the business model as a whole. Some products trigger licensing through one narrow feature while the rest of the platform would otherwise sit outside scope. Document that assessment in writing before launch. If NYDFS later questions your exemption claim, a contemporaneous, reasoned analysis carries far more weight than a retrospective justification built after enforcement contact.
How should you engage NYDFS during the application?
Engagement with NYDFS works best as a structured, documented dialogue rather than a single submission followed by silence. Firms that treat the process as purely transactional tend to accumulate avoidable deficiency letters.
Consider a preliminary meeting before formal filing, particularly where your business model sits near the boundary of a licensable activity or where your corporate structure spans multiple jurisdictions. A short pre‑application conversation can surface scope questions or documentation expectations that would otherwise only emerge weeks into a completeness review. Not every applicant needs this step, but any founder uncertain whether a feature triggers licensing should seek clarity before, not after, filing.
Once the application is submitted, respond to information requests promptly and completely. Partial responses that address only part of a deficiency letter tend to generate follow‑up requests, extending the completeness review further than a single, thorough response would have. Keep a single point of contact managing NYDFS correspondence internally, so responses stay consistent across departments and no request is answered twice with conflicting information.
Requests for clarification on ambiguous checklist items are a normal part of the process, not a sign of a failing application. Framing questions specifically, referencing the exact checklist item or regulatory provision in question, gets faster and more useful answers than open‑ended queries. Keep a written log of every NYDFS communication, including informal calls, so the compliance record stays complete if a later examiner asks how a particular scope question was resolved.
What documentation and policy manuals does the application need?
The BitLicense Application Checklist is, in practice, a demand for a working policy library, not a set of one‑page statements. Each required policy needs to read as something the business actually operates under, complete with version history and named owners.
At minimum, expect to produce a written AML programme covering customer due diligence, ongoing monitoring, and SAR filing procedures; a cybersecurity programme satisfying Part 500's CISO, testing, and incident reporting requirements; a business continuity and disaster recovery plan; and a custody and asset segregation policy demonstrating one‑to‑one backing for customer holdings. Consumer protection and complaint‑handling procedures round out the customer‑facing side of the file.
Corporate documentation runs alongside these: formation documents, an ownership and control chart reaching every beneficial owner above the disclosure threshold, and audited or credible pro forma financial statements. Where the business relies on third‑party technology providers or custodians, include the underlying service agreements and evidence of due diligence performed on those partners.
Every policy should carry a version number, an effective date, and a named approver, ideally at board or senior management level. NYDFS examiners will ask which version was operative at a given point in time, and a policy library without version control cannot answer that question convincingly. Store architecture diagrams, penetration test reports, and incident response runbooks alongside the written policies, since Part 500 cybersecurity evidence needs to demonstrate the programme in operation, not merely on paper.
How should startups build compliance frameworks before applying?
Founders often assume compliance infrastructure can be built in parallel with the application. In practice, NYDFS expects the controls to already be operating, not merely documented, by the time the file is submitted.
Start with governance. Appoint a designated compliance officer and, separately, a CISO with genuine authority and board reporting lines, even in a lean startup structure. NYDFS examiners look for evidence that compliance sits inside the organisational chart with real reporting weight, not as an afterthought assigned to whoever had spare capacity.
Build the AML programme around actual transaction monitoring tooling, not a policy description of a future system. If the technology stack is not yet live, document the implementation timeline and interim manual controls that will operate until automated monitoring goes live. The same logic applies to cybersecurity: a written policy describing penetration testing that has never actually happened will not satisfy Part 500's evidentiary expectations.
Run an internal gap analysis against the BitLicense Application Checklist before drafting a single policy. Identify which controls already exist, which need building, and which require external expertise the founding team does not have in‑house. This sequencing prevents the common failure mode of writing polished policies that describe controls the business has not yet implemented, a mismatch NYDFS examiners are quick to spot during substantive review.
How often must a BitLicense be renewed?
A BitLicense itself does not carry a fixed multi‑year expiry date requiring full reapplication in the way some professional licences do. Instead, NYDFS supervision operates on a continuous basis, with the licence remaining in force provided the holder maintains compliance and meets its recurring reporting obligations.
That continuous model does not mean renewal‑equivalent work disappears. Annual cybersecurity certification under Part 500 functions as a yearly compliance checkpoint, requiring the CISO and senior management to formally attest that the cybersecurity programme meets regulatory standards. Quarterly financial statements and audited annual statements create a recurring reporting rhythm that NYDFS treats as evidence the licensee remains fit to hold the licence.
Material changes to the business, ownership, or control structure typically require prior notice or approval, functioning as informal checkpoints where NYDFS re‑examines whether the original licensing basis still holds. A change of control event, in particular, can trigger a review closer in substance to a fresh application than a simple update.
Budget compliance resources as an ongoing annual cycle rather than a one‑time cost absorbed at launch. Firms that under‑resource the certification and reporting cadence after approval tend to fall behind within the first eighteen to twenty‑four months, precisely when growth is consuming most of the team's attention.
How does NYDFS coordinate with other regulators?
A BitLicense sits inside a wider regulatory perimeter, not apart from it. Holding the licence does not exempt a firm from federal obligations that apply regardless of state licensing status.
FinCEN registration as a money services business runs in parallel with BitLicense obligations, and the AML programme built to satisfy Part 200 must also meet Bank Secrecy Act requirements enforced federally. Sanctions screening against OFAC lists operates under federal authority independent of NYDFS, meaning a firm cannot treat state licensing as a substitute for federal AML infrastructure.
Where a licensee also engages in securities or derivatives‑adjacent activity, tokenised products in particular can draw scrutiny from the SEC or CFTC depending on how the asset is structured and marketed. NYDFS licensing addresses virtual currency business activity specifically; it does not confer clearance under securities law for a token that functions as an investment contract. Firms operating across state lines also need to track money transmitter licensing requirements in other states where they have customers, since a New York BitLicense does not substitute for licensing obligations elsewhere in the country.
Coordinating these overlapping regimes from the outset, rather than treating NYDFS as the only regulator that matters, prevents a common failure pattern: a firm secures its BitLicense only to discover a federal registration gap or an unresolved state money transmitter question that had been deprioritised during the New York process.
CRYPTOVERSE perspective: why completeness beats speed
Founders consistently underestimate how much of the BitLicense timeline is self‑inflicted. The instinct to file early and iterate with NYDFS afterwards is exactly backwards. Examiners will not meaningfully engage with capital or custody questions until the checklist is satisfied, so a rushed filing does not save time. It just moves the delay later and disguises it as regulatory slowness.
A gap analysis against the BitLicense Application Checklist before drafting a single policy, paired with early mapping of related‑entity exposure, catches the failures that actually cost months: undocumented affiliate activity, cybersecurity evidence that describes controls rather than proving them, and capital modelling that ignores twelve‑month growth. Our Bermuda licensing work follows the same principle across a different regulator: readiness before submission, not correction after rejection.
— CRYPTOVERSE
How Cryptoverselawyers supports your BitLicense readiness
Legal consultancy firms work with founders on exactly the gap the completeness review exposes: turning policy drafts into an examiner‑ready file. That includes a readiness assessment against the BitLicense Application Checklist, drafting AML and cybersecurity evidence that satisfies Part 500's certification standard, capital and bond modelling under §200.8 and §200.9(a), and direct liaison with NYDFS during deficiency responses.
Our team has run comparable licensing projects across blockchain and virtual asset regulatory frameworks in multiple jurisdictions, including advisory work spanning VARA, DFSA, and FSRA regimes in the UAE, so the discipline of building an exam‑ready file translates directly to New York's process. If your business model sits near the boundary of the five enumerated activities, or you are choosing between a BitLicense and a trust company charter, a readiness call before you file is the highest‑leverage hour you can spend. Book a document review with Cryptoverselawyers to identify checklist gaps before NYDFS does.
Sources
- Virtual Currency Business Licensing | Department of Financial Services
- How to get a BitLicense: New York's crypto licensing guide | ComplyOne
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
FAQ
Do I need a BitLicense if my company is based outside New York?
Yes, if you serve New York residents. Geographic reach under Part 200 is based on where your users are, not where your company is incorporated, so an out‑of‑state or offshore exchange onboarding New York customers falls inside scope.
How long does the BitLicense application process take?
Practitioner experience places realistic timelines at 12 to 30 months or longer, with incomplete submissions the main driver of delay. Six to twelve months of pre‑application readiness work typically shortens the substantive review phase.
What is the minimum bond or trust account NYDFS expects?
There is no single fixed figure written into the regulation, but guidance commonly cites a practical floor of $500,000 for the surety bond or trust account under §200.9(a). The Superintendent can require a higher amount based on transaction volume and risk profile.
Can Cryptoverselawyers help with a BitLicense application?
Yes. Cryptoverselawyers supports readiness assessments, drafts AML and cybersecurity documentation aligned with Part 500, and liaises with NYDFS on deficiency responses throughout the application.
Is a trust company charter better than a BitLicense?
It depends on your product roadmap. A limited purpose trust company charter under New York Banking Law carries fiduciary powers a standalone BitLicense does not, making it preferable for custody‑heavy or asset‑management models, while a BitLicense generally suits exchange and transmission‑focused businesses.