The Trouble With Categorising Cryptocurrencies As The Basis For Regulating ICOs

Securities regulators are trying to figure out whether and how to regulate Initial Coin Offerings (ICOs). In doing so, they are tending to focus on the economic function and purpose of the 'coins' or 'tokens' offered, to put them in categories that most stakeholders should understand. They are then proposing different regulatory treatments for the process of issuing the coins according to the different categories. The challenge is that tokens - like 'fiat' currencies (and barter goods, for that matter) - generally have multiple uses that are completely independent of the 'issuer' or protocol for issuing them, and which may vary from one 'holder' to the next. Therefore it is suggested that it should not be the economic function or purpose of the token itself that should drive the regulatory treatment, but the activities in which the issuers, holders and potential holders of the tokens are engaged. At any rate, before regulating or threatening the impact of existing regulation, we need to develop a much more comprehensive overview of distributed ledger technology; the role and use of 'tokens', 'coins' and 'cryptocurrencies'; and the participants and their activities. 

In its recent guidelines, the Swiss regulator (FINMA) categorises tokens into three types, although it admits hybrid forms are possible:

• Payment tokens are synonymous with cryptocurrencies and have no further functions or links to other development projects. Tokens may in some cases only develop the necessary functionality and become accepted as a means of payment over a period of time.

• Utility tokens are tokens which are intended to provide digital access to an application or service.

• Asset tokens represent assets such as participations in real physical underlyings, companies, or earnings streams, or an entitlement to dividends or interest payments. In terms of their economic function, the tokens are analogous to equities, bonds or derivatives.

FINMA says the resulting regulatory treatment may be flexible where a hybrid of the above is involved, e.g. anti-money laundering regulation would apply to utility tokens that can also be widely used as a means of payment (or are intended to be used that way in time).

The Malta Financial Services Authority says that these are all forms of "virtual currency" (i.e. digital currencies that are not backed by government - as opposed to e-money, which is the digital version of a country's 'fiat' currency). The Maltese definition of a virtual currency may also be wider, as the Swiss guidelines are only aimed at crypto-currencies - those issued or implemented using cryptographic or "distributed ledger technology".  The other differences seem to be in name only - the Maltese would refer to Swiss "payment tokens" as merely "coins" and prefer the name "securitised tokens" for the Swiss "asset tokens".

The MFSA says this approach to classifying types of “digital currency” reflects the Blockchain Policy Initiative Report of July 2017 (and an European Securities and Markets Authority statement from November 2017). 

But does it?

The crowd-sourced Blockchain Policy Initiative Report does not really give a succinct definition of 'cryptocurrency' and there is no mention of 'payment token' or 'utility token' according to my search of the pdf version. The report is a helpful, but long and discursive, explanation of distributed ledger technology (DLT).  It gives little insight into the uses of such technology beyond financial use-cases - which will likely be the majority in due course (if not already). In any event, with so many ICOs occurring so quickly, it's difficult to see how it could be comprehensive and therefore why it should be particularly reliable. It's even possible that there are initial coin offerings that are not presetned as "ICOs".

Consider "Filecoin", for example. Users can "earn" tokens for making available unused data storage capacity; the tokens become a "currency" for exchange with others; and the result is a means of those with flexible storage needs to manage their data storage costs and capacity. Couldn't this satisfy all three categories outlined above? Should a securities (or payments) regulator be involved in data storage capacity management? Should the transfer or sale of 'coins' representing storage capacity be seen as making a "payment" or "exchange" of "currency"? Consider that certain "carbon credits" or "emission allowances" are regulated securities... but why?

This underscores why we need to develop a much more comprehensive overview of distributed ledger technology; the role and use of 'tokens', 'coins' and 'cryptocurrencies'; and the participants and their activities, before regulating or threatening the impact of existing regulation. 

US Regulator Explains The Challenges For Registered CryptoFunds

The Maltese and Swiss securities regulators were not alone in focusing on cryptocurrencies over the Christmas break, as staff at the SEC were also at it in Washington DC.  Importantly, none of these regulators have poured scorn on the notion of ICOs or even funds holding cryptographic assets. All are merely concerned to signpost issues to be resolved.

While the civil law Europeans were typically eager to be as definitive as possible in how they will treat ICOs (since they believe nothing is possible unless the government spells out how it can be done), the common lawyers in the US were more circumspect (as they abide by the maxim that the law must follow commerce), merely explaining "a number of significant investor protection issues that need to be examined before sponsors begin offering these funds to retail investors."

Yet similar issues arise in relation to ICOs as for funds investing in cryptographic assets, particularly those of "securitised tokens" or "asset tokens" which are analogous to equities, bonds or derivatives in their economic function, if not the rights that attach to them.

Specifically, the SEC's concerns relate to valuation, liquidity, custody, arbitrage for exchange traded funds (ETFs), potential manipulation and other risks. For instance:

• do funds have enough information to value their crypto assets each day, including accounting for events like 'hard forks' or differences in types of currency and potential for market manipulation?

• could open-ended funds support daily redemptions?

• how would a fund arrange custody and validate the existence, exclusive ownership and software functionality of private cryptocurrency keys and other ownership records?

• an ETF is required to have a market price that would not deviate materially from the ETF’s net asset value, so in light of the fragmentation, volatility and trading volume of the cryptocurrency marketplace, how would ETFs comply with this term of their orders?

• Although some funds may propose to hold cryptocurrency-related products, rather than cryptocurrencies, the pricing, volatility and resiliency of these derivative markets generally would be expected to be strongly influenced by the underlying markets, which feature substantially less investor protection than traditional securities markets, with correspondingly greater opportunities for fraud and manipulation. So:

• Would investors, including retail investors, have sufficient information to consider any cryptocurrency-related funds and to understand the risks?

• How would broker-dealers analyze the suitability of offering the funds to retail investors?

• Could investment advisers meet their fiduciary obligations when investing in cryptocurrency-related funds on behalf of retail investors?

Assuming the industry can solve these problems, we'll be in a strange new world.

Switzerland Explains How It Will Handle Initial Coin Offerings

Not to be outdone by Malta's announcements, the Swiss regulator (FINMA) has published its own ICO guidelines, which complement earlier Guidance. Unlike Malta, there is no specific regulation proposed at this stage. But FINMA has tried to clarify that, when assessing ICOs, it will focus on the economic function and purpose of the tokens issued by the organiser, and whether they are (or will be) tradeable or transferable.  FINMA categorises tokens into three types, although admits hybrid forms are possible:

• Payment tokens are synonymous with cryptocurrencies and have no further functions or links to other development projects. Tokens may in some cases only develop the necessary functionality and become accepted as a means of payment over a period of time.

• Utility tokens are tokens which are intended to provide digital access to an application or service.

• Asset tokens represent assets such as participations in real physical underlyings, companies, or earnings streams, or an entitlement to dividends or interest payments. In terms of their economic function, the tokens are analogous to equities, bonds or derivatives.

Malta says that these are all forms of "virtual currency" (i.e. digital currencies that are not backed by government - as opposed to e-money, which is the digital version of a country's 'fiat' currency). The Maltese definition of a virtual currency may also be wider, as the Swiss guidelines are only aimed at crypto-currencies - those issued or implemented using cryptographic or "distributed ledger technology".  The other differences seem to be in name only - the Maltese would refer to Swiss "payment tokens" as merely "coins" and prefer the name "securitised tokens" for the Swiss "asset tokens". 

On the basis of the function and transferability of the relevant crypto-currency), FINMA will treat Swiss ICOs as follows (see diagram on page 8 of the Guidelines):

• Payment ICOs: For ICOs where the token is intended to function as a means of payment and can already be transferred, FINMA will require compliance with anti-money laundering regulations. FINMA will not, however, treat such tokens as securities.

• Utility ICOs: These tokens do not qualify as securities only if their sole purpose is to confer digital access rights to an application or service and if the utility token can already be used in this way at the point of issue. If a utility token functions solely or partially as an investment in economic terms, FINMA will treat such tokens as securities (i.e. in the same way as asset tokens).

• Asset ICOs: FINMA regards asset tokens as securities, which means that there are securities law requirements for trading in such tokens, as well as civil law requirements under the Swiss Code of Obligations (e.g. prospectus requirements).

This may be flexible where a hybrid of the above is involved, e.g. anti-money laundering regulation would apply to utility tokens that can also be widely used as a means of payment (or are intended to be used that way in time).

Malta's Proposals On Regulating Virtual Currencies, ICOs etc - Updated

The Malta Financial Services Authority, like other regulators, is in the process of consulting on the policy it proposes to adopt for regulating virtual currencies, the process of issuing them ("Initial Coin Offerings" or "ICOs") and the service providers involved. The MFSA has proposed new legislation that would extend create an additional regime beyond the scope of existing securities and investment regulation, to cover virtual currencies that are not deemed to be financial instruments and therefore already caught by existing laws.

The MFSA published a “Discussion Paper On Initial Coin Offerings, Virtual Currencies And Related Service Providers” in November 2017 and consultation ended on 18 January 2018. The MFSA is yet to finalise its policy or any proposed statute.

The MFSA clearly wishes to support innovation and new technologies for financial services, while ensuring effective investor protection, market integrity and financial stability.  

It’s proposed approach to classifying types of “digital currency” reflects the Blockchain Policy Initiative Report of July 2017 and an European Securities and Markets Authority statement from November 2017.  This contrasts “virtual currency” with “E-money” which is the digital representation of a fiat currency; and defines three types of virtual currency (any of which might also be cryptographic currencies operating on distributed ledger technology or DLT): 

• “utility tokens” (providing only platform or application utility rights or access rights);

• “securitised tokens” (embedding an underlying asset/commodity or rights, like quasi-shares or bonds); and

• “Coins” (that are intended to be, or have become, a means of payment). 

The MFSA is proposing to seek the adoption by the Maltese Parliament of a Virtual Currencies Act to regulate virtual currencies:

• that constitute “financial instruments” (under a test to be devised), by confirming they are subject to existing EU and national financial services regulation; and

• those that do not qualify as financials instruments, by making them subject to new “similar high level regulatory principles on transparency and merit-based regulation as those currently applicable to securities seeking a listing on a regulated market” – although they will be deemed “complex instruments” so their regulatory treatment will be akin to how such instruments are regulated under MiFID. 

Persons involved in activities related to virtual currencies would need to be "'fit and proper', have the competence, sufficient knowledge and expertise, experience, business organisation and systems necessary in the field of information technology, VCs and their underlying technologies, including but not limited to DLT."

Providers of investment services will need a separate licence to provide services in support ICOs etc in relation to virtual currencies that do not qualify as financial instruments under existing laws; and will need to set up a dedicated subsidiary for that purpose. 

All persons subject to the Act would also be subject to anti-money laundering requirements. 

There are specific proposals to regulate issuers, exchanges and investment funds (and other collective investment schemes) that deal in virtual currencies that do not qualify as financial instruments. 

Banks and payment service providers would be permitted to extend their activities to such virtual currencies, but only for clients and under a separate subsidiary licensed under the Act. 

But reinsurers, insurers and pension schemes would still be prohibited from dealing in virtual currencies for their clients or their own account. 

Update 22.02.18: The Maltese government has published a further consultation in response to submissions received on the MFSA discussion paper, which "presents a conceptual framework through which DLT Platforms can be subject to certification in Malta" which will extend to issuers of ICOs and certain service provides dealing in virtual currencies. Consultation responses are due by 9 March 2018.

Three new pieces of legislation are proposed:

• The MDIA Bill will provide for the establishment of an Authority to be known as the Malta Digital Innovation Authority.

• The TAS Bill will set out the regime for the registration of Technology Service Providers and the certification of Technology Arrangements.

• The VC Bill will set out the framework for ICOs and the regulatory regime on to the provision of certain services in relation to VCs. The intermediaries subject to the VC Bill include brokers, exchanges, wallet providers, asset managers, investment advisors and market makers dealing in VCs. 

EU Warns Firms To Act On Loss Of Financial Services Passports

The European Union has today warned financial services firms that rely on EU passports to make alternative arrangements ahead of Brexit. Separate warnings were made to ratings agencies, investment firms, insurers and reinsurers,  banks and payment services firms, auditors, providers of post-trade services (settlement and clearing), and asset management. Warnings were also issued to participants in other pan-EU licensing schemes.

This is nothing new, as explained previously, and many firms have already activated their plans to move EEA-facing operations into one of the 27 remaining EU member states.

The warning is timely, however, in case any firms are distracted by UK government "assurances" concerning potential free trade arrangements following previous EU warnings in December, which the UK government has conceded the EU is legally entitled to issue. 

Such deals do not usually deal very extensively with services, and 'most favoured nations' obligations in existing EU trade deals with third countries mean that it is very unlikely that the EU will wish to - or realistically be able to - set any kind of precedent in a deal with the UK.

The UK government's insistence on the leaving the single market and the customs union effectively rules out the UK remaining a member of the EEA (like Norway). That means the only alternative to Brexit is remaining a member of the EU.

Review of E-money Regulation: More Regulation For Retailers?

The European Commission has just reported on the status of EU e-money regulation, raising the prospect of more regulation for retailers who offer 'gift cards' and other loyalty schemes.

Electronic money, or "e-money" is basically electronically stored value that can be used to make payments to people other than the issuer, while "limited network" or 'closed-loop' stored value can only be used to pay the issuer (as with a loyalty points scheme, fuel card or gift card, for example).

E-money is not to be confused with "crypto-currencies" like Bitcoin, Ether etc. which are not considered "funds" for regulatory purposes because they are not 'fiat' currencies that are backed by governments as a matter of law ('legal tender').

The issuance of e-money was first regulated distinctly from banking by the EU in 2000, under the E-money Directive (EMD) which was replaced by a new directive (EMD2) from 2011. By then the activities of electronic money issuers/institutions (EMIs) had also become regulated under the Payment Services Directive (PSD) from 2009, which was replaced in mid-January 2018 by regulations implementing PSD2.

Inconsistencies

These directives are supposed to be applied the same way by all member states in the European Economic Area (28 EU member states plus Iceland, Liechtenstein and Norway). But the Commission has found that EMIs "engage in "forum shopping", choosing to register in the Member States that provide the most beneficial legal frameworks from their viewpoint." EMIs can then use a "passport" process to offer their services in the remaining EEA member states.

For example, the Annex to the report shows that the UK is home to 87 of the EU's 172 E-money institutions (EMIs), with Malta being the next most popular base (13) then Cyprus (10). This also means that the 87 EMIs based in the UK will need a new base in one of the remaining EEA member states from which to passport their EEA-facing services after Brexit.

The UK is also home to 19 of the EU's 74 small EMIs (who transact less than €3 million a month over a 12 month period), with the Netherlands home to 23 and Latvia 12. But small EMIs have no passport rights, anyway, so do not raise the same concerns.

Benefits of EMD2

The benefits of EMD2 were cited as more clarity and lower capital requirements than EMD1; on top of the fact that payment services regulated under PSD2 and e-money services can be provided under the EMD2 authorisation.

The Commission did not find any consumer harm associated with using e-money or redeeming it for cash (withdrawing the funds equivalent to their e-money balance to another payment account or via an ATM).

Compliance costs are said to range from 1% to 5% of overall costs (€25,000 to €500,000) offset to some degree by the reduction in capital requirements from €1 million under EMD1 to €350,000 for full EMIs under EMD2 (compared to €125,000 for full payment institutions under PSD2).

Issues

Negative factors associated with EMD2 were found to be mainly the inconsistencies in how each EEA member state views the role of an EMI's "agent" (which the EMI has to register) and "distributor" (of which an EMI just has to notify its regulator); and "limited network" or 'closed-loop' stored value, which is unregulated. The inconsistencies make it more difficult to predict the regulatory status and related requirements from case to case and state to state.

EMIs also complain that banks won't allow them to open bank accounts as easily as other types of firms, although the Commission hopes this will be improved by various access provisions in PSD2, and moves by central banks to allow EMIs (and PIs) access central bank accounts and settlement systems.

Next steps

The Commission will explore ways to improve consistency in interpreting the role of agents, distributors and "limited networks". In addition, it will consider making large 'limited network'  providers subject to some (unspecified) aspects of EMD2, even though they must already register with the local regulator when their network transaction volume exceeds €1 million over a 12 month period).

New To Payments? Try PSD2 Customer Authentication and Communication Standards!

If you are among the new entrants to the regulated payments space you should know that, in a bit to captivate and inspire a generation, the European Banking Authority has published the final 'regulatory technical standards' for payment user authentication and the secure communication of payments data. The standards should take effect in the second half of 2019, but the authorities are keen for regulated payment service providers (PSPs) to adopt them as soon as possible. They are written in legalese, but I've summarised them below in a bid to get them straight in my own head.  Grab a coffee before proceeding!

Strong customer authentication 

PSPs must know they are dealing with their own customer by applying strong customer authentication. This is subject to certain permitted exemptions outlined below. PSPs must also protect the confidentiality and the integrity of each customer's personalised security credentials. Their security measures must be documented, periodically tested, evaluated and audited by auditors with expertise in IT security and payments and operationally independent within or from the PSP.

 

Broadly, authentication must be based on two or more elements of 'knowledge' (password/PIN), 'possession' (card/device) and 'inherence' (fingerprint/iris scan). 

These elements must be subject to measures designed to prevent disclosure (in the case of knowledge) , replication (in the case of possession) and resistance against unauthorized use of device or software (in the case of inherence). 

The breach of one element must not compromise the reliability of the others. Certain measures must also mitigate the risk that a multi-purpose access device has itself been compromised. 

Credentials and Code

Authentication credentials must be masked when displayed and not fully readable as they are being entered; not stored in plaintext; and must be protected from unauthorized disclosure. 

PSPs must document how they encrypt credentials or render them unreadable. 

The creation, processing and routing of credentials must be done in secure environments that accord with industry standards. 

Specific requirements govern the process of associating the user with credentials; delivery; authentication of devices and software; and the renewal, destruction, deactivation and revocation of credentials.

Authentication must result in the generation of an authentication code that is only accepted once by the PSP when the payer uses it to: access the payer’s payment account online, initiate an electronic payment transaction or to carry out any action through 'a remote channel which may imply a risk of payment fraud or other abuse'. 

No information on any of the authentication elements can be derived from the disclosure of the authentication code; nor can it be possible to generate a new authentication code based on the knowledge of any previous code. The code must not be able to be forged. 

Where the authentication has failed to generate an authentication code, it must not be possible to identify which of the authentication elements was incorrect. 

No more than 5 failed authentication attempts can take place consecutively before the authentication tool is blocked, either temporarily (based on certain factors) or permanently (after a warning). The user has 5 minutes of inactivity after being authenticated before access must time-out. 

Dynamic linking!

The payer must be made aware of both the amount of the proposed payment transaction and of the proposed payee. The authentication code must also be ‘dynamically linked’ (specific to) the amount and the payee. Any change to the amount or the payee must result in the invalidation of the authentication code  that was generated. 

PSPs must ensure the confidentiality, authenticity and integrity of the amount of the transaction and the payee throughout all of the phases of the authentication; as well as the information displayed to the payer including the generation, transmission and use of the authentication code.

Transaction monitoring

PSPs must monitor interaction with their customers to detect unauthorised or fraudulent payment transactions, taking into account elements which are typical of the user when normally using the credentials and, at a minimum, the following risk-based factors: 

• lists of compromised or stolen authentication elements; 
• the amount of each payment transaction; 
• known fraud scenarios in the provision of payment services; 
• signs of malware infection in any sessions of the authentication procedure; and
• where the access device or software is provided by the PSP, a log of the use of the device or software and the abnormal use of the device or software. 

Exemptions from strong customer authentication

The permitted exemptions (subject to transaction monitoring, and quarterly assessments to be shared with the FCA on request) are: 

• checking the balance or the last 90 days of transactions without entering sensitive payment data; 
• a contactless payment of up to €50, a series of up to €150 or 5 consecutive contactless payments; 
• payment at an unattended parking or transport ticket terminal;
• the payee is included in a list of trusted payees (unless adding to or changing the list); 
• recurring payments (after authenticating for the first);
• transfers between the users’ own accounts with the same PSP; 
• a remote electronic payment of up to €30, consecutive payments of up to €100 or 5 consecutive remove electronic payments; 
• commercial payment processes or protocols where the FCA is satisfied they guarantee at least the same level of security as under PSD2; 
• low risk remote electronic payment transactions (based on certain risk factors) where: 

o the fraud rate is below the relevant reference rate; 

o the amount is below a specific threshold; and 

o the PSP’s real time risk analysis hasn’t identified certain specified problems. 

Secure communcations

A PSP's communication sessions must be protected against the capture of authentication data transmitted during authentication, and against manipulation by unauthorised parties based on certain communication standards. These include secure identification of payer’s and payee’s devices; traceability of both the transactions and the interaction with the user and other participants in transactions; and a secure access interface between payer and online payment accounts. 

The access interface must allow for access by the user’s chosen account information service providers (AISPs) and payment initiation service providers (PISPs), although access by AISPs and PISPs can be facilitated via a dedicated interface that meets certain requirements. 

Wakey-wakey!

The End.