The hardest part of licensing isn't just the application. It's everything that happens after approval.
A decade of the BitLicense and lessons learned from cryptocurrency oversight at the state level gives DFAL applicants the most relevant precedents for what that "after" looks like.
Most DFAL coverage so far has focused on the application: what forms to expect, what documents to gather, what the timeline looks like. The DFAL-as-the-new-BitLicense framing is fair on those mechanics. Both are state-level licensing regimes for digital asset business activity. Both run through NMLS. Both empower a state regulator with examination authority, capital and liquidity discretion, and a substantive review process.
The application itself is genuinely difficult. BitLicense has issued only a small number of approvals across its decade in operation, and the review process is rigorous by design. Getting approved is its own significant accomplishment — and DFAL applicants should expect a comparable bar.
But for the companies that get through, approval is the start of the regulated relationship, not the end of the work.
What BitLicense established structurally
When New York stood up BitLicense in 2015, it created something the digital asset industry has not dealt with before at scale: a state-level licensing regime with examination authority, ongoing reporting obligations, and capital and liquidity oversight.
That structure matters more than any particular form. A license is not a one-time event. It's an ongoing relationship with your regulators — from recurring supervisory discussions to periodic onsite regulatory examinations. That deep engagement requires the licensee to keep operating in line with the conditions of approval, and to demonstrate that alignment when asked.
A central challenge for BitLicensees has been keeping operating reality aligned with what's on file. The application captures a snapshot — detailed business plans, AML programs, cybersecurity posture, and policy documents at the moment of submission. Notably, the level of specificity required for state crypto regimes — detailed information security frameworks, specific tooling, disclosures, and controls tailored to digital asset activities — can be a high bar, even for entities already operating under licensing regimes in other states that don't address cryptocurrency directly.
Operations evolve from there: products iterate, vendors change, teams turn over. And examination authority is continuous and broad. A regulator can ask for evidence of compliance at any time, across any covered activity, over the licensee's full operating history. Material business changes — new products, new control persons, new vendors — can also trigger their own detailed requirements that the original application didn't contemplate.
Maintaining that alignment, and projecting current operations through every layer of risk management, compliance, and regulatory engagement, is the actual operating burden of being licensed.
The very existence of DFAL and its adoption of evolving best practices not just from the New York Department of Financial Services but also NIST and other tailored supervisory regimes is a testament to the need for applicants and licensees to do likewise. DFAL applicants and licensees should take note: there is a need to build and scale specific to your current and projected business plans across your control environment. Given how quickly the space is moving, the days of periodic risk management and compliance and one-off examinations are gone, and entities need to move towards a real-time risk management and regulatory engagement model.
DFAL applicants who plan with these considerations in mind will fare better than applicants who treat approval as the finish line.
What that means for digital asset operators
Operating under a state crypto licensing regime brings disciplines that anyone running compliance at a bank or payments institution would recognize — but they're new territory for most digital asset companies:
- Compliance is an operating layer, not a department. It touches product, GTM/sales, engineering, customer operations, finance, and legal — and is measured by whether the company can produce evidence, on demand, that what's promised in policy is what's happening in practice.
- Audit trails have to reconcile across systems that weren't designed to talk to each other. Compliance data typically lives across multiple tools — transaction monitoring, KYC, sanctions screening, onchain analytics, and the general ledger. Many of these tools have capabilities — like full historical visibility on transaction activity — that don't have direct analogues in traditional banking, which requires different thinking. Producing a coherent picture for a regulator means those systems have to be reconcilable, not merely present.
- Documents on file should match operations on the ground. Policies and procedures submitted at application — and updated over time — should describe what the team actually does. When the two diverge, the divergence is what regulators tend to find first. Particularly given the quickly moving space, applicants should consider how their IT/cybersecurity programs and other controls evolve as the company expands into new customer segments and activities.
- Examination preparation is a continuous discipline. The infrastructure to demonstrate compliance — version-controlled policies, traceable evidence, defined ownership of every program — is harder to build retroactively than to maintain in real time.
Most DFAL coverage focuses on the application. The years of operation that follow deserve equal attention.
Where DFAL looks similar to BitLicense, and where it looks different
DFAL borrows heavily from the structural DNA of the state crypto licensing regimes that came before it. Three structural similarities matter:
- Control-based scope. DFAL anchors its scope to whether the licensee assumes "control" of customer assets — the same definitional hook that drove BitLicense's product-architecture debates. "Non-custodial" is not a magic word — regulators care whether you assume control, not what you call yourself.
- Examination authority. DFPI has the same statutory authority to examine licensees as NYDFS, administered by a regulator that has spent years building fintech-specific supervisory capacity.
- Capital and liquidity at regulator discretion. Financial Code §3207 gives DFPI broad latitude to set licensee-specific capital, liquidity, and surety expectations based on the licensee's risk profile. DFPI's published guidance signals an initial $100,000 tangible net worth and a $500,000 surety bond as application-stage starting points — both subject to upward adjustment during review based on activity volume, asset mix, custody model, and customer base.
Two DFAL-specific items worth tracking:
- The "completed application" transition concept. DFPI's proposed PRO 02-23 ties the July 1, 2026 transition window to whether an applicant has filed a completed application. A placeholder filing on June 30 is not a safe harbor.
- The MTA exemption interaction. DFPI has separately proposed clarifying when fiat money transmission incidental to DFAL-licensed activity may be relieved from California's Money Transmission Act. The dual-licensing question is genuinely live until the rule text is final.
Net: DFAL's operational profile will look more like BitLicense than not. The DFAL-specific particulars are real, but narrower than the headlines tend to make them.
What firms should be doing before they file
Not a checklist. A posture. Four moves that compound:
- Map your control points before you map your forms. Where does your product assume control of a customer's digital asset, even momentarily? Where does it pass to a vendor? Where does it return? That map is upstream of everything else — scope, custody design, disclosures, capital. Forms are downstream of the map.
- Build the operating model alongside the application package. The application is a snapshot of how you say you operate. The operating model is how you actually operate, every day, after approval. Design both in parallel — and design them to match.
- Design for examination from day one. Audit trails. Document version control. Policy ownership. Evidence collection. These aren't things to retrofit before the first exam. They're foundations that should be in place before the application is filed, because the application itself is a regulator's first read on whether you've thought about any of this.
- Treat the MTA overlap as a live question. Don't decide internally that DFAL replaces MTA for your activity until the final rule says it does. Plan for the possibility of dual licensing.
These four moves don't replace legal work. They sit underneath it. The companies that get DFAL right will be the ones that built the operating reality first, and let the application paperwork describe what was already true.
The honest line
A decade of crypto licensing has taught the industry that regulation is not a filing exercise. It's an operational discipline.
The companies that thrive under DFAL won't be defined by the slickest application package alone. They'll be the ones that can still answer an examiner's question three years later — without scrambling, without guessing, without the entire compliance posture coming undone.
That work is slower than filing an application. It's less visible. It's harder to optimize. But it's the work that determines who's still operating in California in 2030.
If you're building toward DFAL, this is where the work matters most.
RegSurety is the licensing infrastructure for digital asset businesses — built for both sides of the line. We help with licensing readiness and the application package, and the years of operating that follow: reporting cadence, renewals, exam readiness, policy versioning, and an audit log of every change.