On June 24, the five-year anniversary of New York’s virtual currency licensing regime known as the BitLicense, the New York Department Financial Services (DFS) published new guidance and FAQs related to approval for use of specific currencies and the licensing process, as well as a proposed conditional licensing framework. The measures offer important insight for companies holding or considering applying for a BitLicense and represent the most significant changes and proposed changes since the regulation’s initial issuance in 2015.
Guidance for Adoption or Listing of Virtual Currencies
Under the BitLicense regime, licensees and approved charter holders under the New York Banking Law (collectively, “VC Entities”) are required include virtual currencies (“coins”) they plan to “list” in their initial application to DFS. Historically, in order to list new assets VC Entities were required to go back to DFS to seek approval. Given the proliferation in coins available over the past five years this became a cumbersome and time-consuming system. In order to remedy this issue, in December of 2019, DFS issued proposed guidance to allow licensees to “offer and use new coins in a timely and prudent manner.” After receiving public comments, DFS has now published final guidance creating “two separate frameworks designed to enhance speed and efficiency in a VC Entity’s adoption or listing of coins.” These two frameworks include (1) “a general framework for a VC Entity’s creation of a firm-specific policy for the adoption or listing of a new coin, without DFS’s prior approval, through the process of self-certification” and (2) “a general framework for the process of Greenlisting coins for wider usage.”
VC Entities wishing to self-certify the use of coins must create a coin-list policy in accordance with the DFS framework and such policy must be approved by DFS. According to DFS, the coin-listing policy must “include robust procedures that comprehensively address all steps involved in the review and approval of coins” and should only result in approval if the VC Entity concludes listing is consistent with standards contained in the BitLicense regime.
Notably, the guidance states that “a VC Entity cannot self-certify any coin that may facilitate the obfuscation or concealment of the identity of a customer or counterparty” meaning “no privacy coin can be self-certified.” Similarly, VC Entities “cannot self-certify any coin that is designed or substantially used to circumvent laws and regulations (for example, gambling coins).” Notably, the guidance does not define the term “privacy coin” or “gambling coin,” nor are such terms defined in the BitLicense regulations. Such coins are not completely banned under the guidance, but would require specific DFS approval as opposed to approval through self-certification.
Coin-listing policies must adhere to certain minimum standards related (1) governance, (2) risk assessment, and (3) monitoring. With respect to governance, the guidance requires the board of directors or equivalent body approve the coin-listing policy and each new listed coin. It also includes provisions related to conflicts of interest, record keeping, periodic reviews of the listing policy, and notifying DFS of instances of non-compliance. In addition, no changes or revisions to the policy can be made without prior written approval from DFS.
With respect to a risk assessment, the guidance states a VC Entity must “perform a comprehensive risk assessment designed to ensure that the coin and the uses for which it is being considered are consistent with the consumer protection and other standards embodied in [the BitLicense regime] and with the safety and soundness of the VC Entity.” The guidance then goes on to list 11 different risks that must be assessed for each new coin. For example, among other risks, VC Entities must assess “cybersecurity risk,” “risks associated with actual or potential conflicts of interest,” and “regulatory risks including those relating to federal regulations from the Financial Crimes Enforcement Network (FinCEN), the US Commodity Futures Trading Commission (CFTC), and the US Securities and Exchange Commission (SEC).” While not explicitly stated, the reference to CFTC and SEC suggest that VC Entities must be particularly cautious when considering listing of coins that might be considered a security under SEC rules or a derivative product under CFTC rules.
With respect to monitoring, the guidance states that “once a VC Entity begins using a new coin, the VC Entity should have policies and procedures in place to monitor the coin to ensure the VC Entity’s continued use of the coin remains prudent.” Such monitoring includes (1) periodic re-evaluation, (2) “adoption, documentation, and implementation” of internal controls to manage risks associated with listed coins, and (3) a process for de-listing coins.
Notably, for VC Entities with an approved coin-listing policy, while prior DFS approval is not required, such entities must “provide written notice to DFS of its intent to use the coin, including details of its specific use and purpose” prior to using the coin.
VC Entities without an approved coin-listing policy, must continue to seek pre-approval from DFS, unless the coin is contained in the DFS “Greenlist” (discussed below).
DFS has published a Greenlist of approved coins that VC Entities may list without obtaining specific approval from DFS or going through the self-certification process. Coins can be added to the Greenlist through two mechanisms. First, coins can be directly approved by DFS. Second, coins that are approved by three “different and unrelated entities” through the self-certification process will be added to a public list of coins in a “Greenlist Waiting Period.” After six months the coin will be added to the Greenlist unless a VC Entity delists or stops using a given coin, in which case “DFS may decide whether or not to continue with the Greenlist Waiting Period based on any information it considers relevant.” Notably, coins are Greenlisted for “a specific use” as opposed to general purpose use. It is unclear from the guidance how broadly such uses will be construed. At present, the Greenlist includes two uses: “custody” and “listing.” However, these terms are not defined by DFS or in the BitLicense regulations and it is not clear if these are the only uses that DFS will consider adding to the Greenlist.
During the Greenlist Waiting Period, VC Entities can still seek to use the coin through either direct DFS approval or through the self-certification process. A VC Entity must have “policies and procedures in place to monitor its adoption and use of any coin on the Greenlist to ensure the VC Entity’s continued use of the coin remains prudent.”
The current Greenlist contained on DFS’s website is included below. Thus far, seven coins have been approved for “custody” and “listing” and an additional two coins have been approved for custody, but not for listing.
The guidance states that VC Entities must provide their customers with written disclosures regarding offered coins, including whether a coin was approved by the Greenlist, self-certification, or specific DFS approval.
Notice Regarding Application Procedures
Industry has long complained the BitLicense application process is complex, lengthy, and, in some cases, lacks transparency. In a new notice published on the DFS website, it acknowledges these industry critiques and states that “in DFS’s experience, an underlying cause for these concerns is that BitLicense applications are often submitted without all the necessary documents and information.” In order to increase “transparency and speed in the BitLicense application review process,” DFS announced two new “practices.”
First, DFS will only begin a “substantive review” when an application includes “all the documents required … and each such document appears to be adequate on its face in terms of organization and level of detail.” DFS further explains that, “Applications that are not yet in this state will be deemed unready for substantive review until the missing items have been provided, and will generally not be reviewed, except for an initial intake process to determine whether substantive review is appropriate.” According to DFS this new practice will improve the review process by (1) expediting the review of applications considered ready for substantive review, (2) resulting in more applications being ready for substantive review by limiting “any incentive for applicants to submit partial applications,” and (3) resulting in “more effective and efficient use of DFS’s resources.”
Second, DFS will limit the number “deficiency letters” issued for a given set of requirements. A deficiency letter is a letter outlining a deficiency in a given portion of an applicant’s materials that must be remedied for a license to be issued. According to DFS, “these letters will include a return date by which a complete response is due” and “if all deficiencies involving a particular application requirement or set of requirements have not been fully and effectively addressed by the end of the response period for the third deficiency letter addressing the requirement(s), DFS may, without further notice, deny the application.” DFS explains that this policy will benefit applicants that diligently advance their applications once in the substantive review period and allow for more effective use of DFS resources.
The new practices announced by DFS underscore the importance of having a fully completed and well-crafted application package and responding promptly and fully to DFS deficiency letters, as well as working with experienced counsel that can assist in crafting policies and procedures likely to be approved by DFS. Whether the new practices will in fact speed processing times for applicants remains to be seen.
In addition to the guidance, discussed above, DFS also released a revised set of FAQs. The revised FAQs contain summaries of the new coin-listing frameworks and license application procedures. The FAQs also include a number of helpful responses regarding the scope of the BitLicense, for example, clarifying that “many” stablecoins are considered Virtual Currency under the BitLicense regime and that “writing software that allows customers to self-custody Virtual Currency in a wallet would not, in and of itself, require a BitLicense.”
Proposed Conditional Licensing Framework
Under the current BitLicense regulations, DFS may, at its discretion, grant a “conditional license” to an applicant that “does not satisfy all of the regulatory requirements upon licensing.” Conditional licenses may be granted for two years during which an entity must satisfy conditions imposed by DFS. At the end of the conditional license period DFS can allow the license to expire, remove the conditional status of the license, or extend the conditional license period. The conditional license mechanism was intended to provide an onramp to start-ups with more limited resources that may not meet all of the DFS requirements at the time of their application, but have a clear roadmap to come into full compliance in the future. However, to date, this conditional license has been of little interest to most members of industry given the inherent uncertainties of the process and significant resources required to obtain even a conditional license.
The proposed conditional licensing framework published by DFS recognizes the challenges facing some firms including the “rigorous application process, which can involve a significant expenditure of time and resources for applicants.” In order to ameliorate these challenges, DFS proposed a conditional licensing framework “to allow a new entrant to work in collaboration with an authorized BitLicensee or a holder of a New York limited purpose trust charter … during the term of the conditional BitLicense.” As explained by DFS, an applicant “seeking to engage in virtual currency business activity in New York under a Conditional License would collaborate and engage with an authorized VC Entity for various services and support, such as those relating to structure, capital, systems, personnel, or any other support needed.” DFS adds that it expects entities granted conditional licensing will eventually seek a full BitLicense. The proposed framework contains five steps:
- An applicant will provide DFS a draft “service level or similar agreement” between the applicant and a VC Entity;
- An applicant will submit certain additional documents and information based on the type of business the applicant plans to conduct and the risks presented by that business;
- DFS will conduct a substantive review of the application materials;
- If approved, DFS and the applicant will enter into a “supervisory agreement” that details, among other considerations, “the activities in which the Applicant may engage, the requirements it must meet, division, apportionment and sharing of responsibilities and liabilities with the VC Entity, and the oversight DFS will conduct with respect to the Applicant;” and
- Upon completion of the supervisory agreement, DFS will issue the applicant a conditional license.
DFS is seeking comments from all interested parties regarding the proposed framework and lists 11 specific questions for which it is “particularly interested in receiving comments.” Both VC Entities and entities considering conducting business with VC Entities should review the proposed framework and consider submitting a comment with guidance from experienced counsel.
Notably, the proposed framework seems principally aimed at resolving the issue of entities seeking to provide certain services to VC Entities. For example, an entity wishing to provide custody solutions for a New York based VC Entity could be a potential candidate under the proposed framework. The framework seemingly has less utility for entities not looking to collaborate with existing VC firms, but rather to compete with those firms. For example, an entity looking to establish a new virtual currency exchange in New York to compete with other providers in the state would be unable to do so under the framework unless it found a willing VC Entity partner.
Steptoe will continue to monitor and provide updates on this proposed framework as DFS’s process unfolds.