The diversification of retail payment instruments places commercial businesses and their respective treasuries in the condition of having to define an acceptance strategy for innovative payment systems, including those based on cryptocurrencies. What methods of online and point-of-sale collection are envisaged and what attention should be paid when choosing payment service providers?
The sector of innovative payment systems is in rapid and constant evolution. Alongside the more traditional services based on cards and bank transfers, alternative methods are emerging that could extend collection tools with repercussions on corporate treasuries.
A business that wants to expand the range of payment tools offered to its customers is called upon to define the best acceptance strategy, being able to provide for the acceptance of tools also based on cryptocurrency on its physical and online stores.
The market for service providers that facilitate collections in virtual currencies for the benefit of merchants, is developing rapidly in the European Union, albeit amidst many perplexities and uncertainties under the regulatory profile that still await to be resolved.
Even in Italy, in the vagueness of a regulatory framework in progress, some offers developed by national players are starting to appear, albeit timidly, which are proposed to the attention of compatriot retailers.
In this article we offer a brief examination of the opportunities and constraints that a service provider designed to facilitate collections and payments in cryptocurrencies must correctly frame. The analysis, even in its synthesis, helps to illuminate those shaded areas of which one is not always aware.
The tools and technologies to pay and collect in cryptocurrency
To address the issue in detail, we believe it is useful to share a taxonomy of the tools and technologies that we will analyze in this contribution; this will facilitate (we are sure) the understanding of those who are beginners.
In the explanations offered for each terminology, we have also proposed some example cases of adoption that help to correctly map the meaning on practical applications.
The use cases refer to collection and payment transactions that take place in cryptocurrency between the customer of the commercial operation and the merchant, for which the availability of the former is independent of any fiat – crypto conversion activity that could take place at the same time as the transaction. of payment.
The alternative scenarios that provide, however, the use of prepaid cards issued on international circuits, financed (or reloaded) by flows of cryptocurrency converted at the same time as the purchase, will be dealt with in another in-depth article.
For the use cases in question, the transactional kinematics that develop at the time of payment is (simplifying) the following:
- the customer accesses his own crypto wallet from which he initiates the cryptocurrency payment transaction, being sure that he has a sufficient amount of crypto funds to pay the amount presented to him during the payment phase;
- the merchant, once the amount requested from the customer has been collected in cryptocurrency, will convert the crypto turnover into fiat funds, through an exchange platform.
We have classified these adoption cases as collections in fiat currency converted from cryptocurrency, collected against a payment in cryptocurrency.
DLT Distributed Ledger Technology
Let’s start by proposing a basic definition of DLT. Any cryptocurrency collection and payment transaction takes place through the use of Distributed Ledger or DLT technologies. They are technologies in which all the nodes of a network have the same copy of a database that can be read and modified independently by the single nodes.
On these platforms, changes to the register are regulated through consent mechanisms that allow for an agreement to be reached on the various versions of the register, despite being updated independently by the network participants.
Blockchain
The blockchain is a protocol that characterizes some DLT architectures, where the register is structured in blocks of validated transactions, linked to each other through the use of cryptographic techniques and distributed consensus mechanisms based on cryptoassets.
Cryptoasset
By cryptoasset we generally mean a digital representation of value made unique thanks to the use of cryptographic mechanisms; cryptoassets can be traded on distributed ledger platforms respecting the rules of a blockchain protocol.
Cryptographic keys and crypto wallets
The management of a transaction on the blockchain implies that an entity (it could be the customer or the merchant who, respectively, pays and collects in cryptocurrency), has two cryptographic keys kept inside specific crypto wallets:
- a public key, from which it is possible to generate one (or more) addresses representing the address to which it is possible to transfer cryptocurrency;
- a private key with which he disposes and spends – or transfers to others in turn – the cryptocurrency received.
The address derived from the public key is used to identify an account (or wallet), to which cryptoassets are associated, which can be controlled by knowing the corresponding private key. From a public key it is not possible (as it is too burdensome from a computational point of view) to trace the corresponding private key.
The private key allows the person who underlies the aforementioned address (and only him) to actually dispose of the quantity received, therefore, it must be kept in maximum safety to prevent anyone who comes into possession from having quantities that are not his own.
By way of example, let’s consider the collection method that we described above: collections in fiat currency converted from cryptocurrency, collected against a payment in cryptocurrency.
A bitcoin transaction that a generic customer can boast of being available knowing the private key of his wallet, to a bitcoin address that identifies the merchant, requires the customer (through his crypto wallet application) to digitally sign the transaction using his own private key and encrypt the cryptoasset stream using the merchant’s public key.
At the same time, a merchant who, having collected cryptocurrency, wishes to convert it into euros, will send the amount of cryptoasset available to an exchange platform (knowing the private key of his wallet), learning its address (or the addresses).
The transaction will take place similarly to what we have described for the previous case, that is, the merchant (through his crypto wallet application) will have to digitally sign the transaction using his own private key and will encrypt the cryptoasset flow using the exchange’s public key.
Multi-signature crypto wallet
One of the extraordinary opportunities offered by the blockchain lies in the possibility of controlling, or arranging, transactions in cryptoassets in compliance with a will that could be shared between several subjects.
A multi-signature crypto wallet makes it possible to satisfy this need, providing, during the creation and use phase, one or more private keys with which it is possible to authorize (or sign) the transactions.
Also in this case, we take into consideration the collection method that we described above. By way of example, we could imagine that the wallet of a commercial establishment that collects bitcoins is a multi-signature wallet, in such a way as to be able to check that the conversion transactions into euros are authorized by all those who know (or hold) the private keys.
Such a wallet would greatly facilitate the treasury management of companies which, having collected in cryptocurrency with the help of a specialized provider, need to convert the cryptoassets they have access to knowing at least one private key of the wallet.
This operation (as is evident) can take place if, only if and when, the transaction to the exchange is signed (or authorized) by all parties who know the private keys.
If the crypto vallet that collects is, on the other hand, in the sole and complete availability of the supplier, or if it were a non-multi-signature wallet, the merchant must blindly trust his supplier, trying to obtain guarantees on the deposits of crypto funds that the supplier has cashed on his own.
The case just described (not infrequent, in truth) sets up a scenario that in the world of traditional payments would be similar to the collection mandate. The provider specializing in the facilitation of cryptocurrency collections, in fact, would assume the role of “agent for the collection of cryptocurrencies”.
As we will see below, this role is not currently provided for in any Community law and, therefore, there are no rules that protect crypto funds collected on behalf of third parties.
Merchant plug-ins and merchant guarantee systems for cryptocurrency collections
In order to be able to offer a user experience to its customers without friction, and, at the same time, to ensure that the merchant collects in cryptocurrency an amount equivalent to the price expressed in euros, protected from the typical fluctuations of some cryptoassets and with the certainty that the payment transactions are actually confirmed, it is necessary that the service provider that facilitates the merchant’s collections, prepares specific applications and systems, such as to manage all the three different needs.
We will therefore deal respectively with:
Plug-in of the merchant with which the customer interacts at the time of payment;
Guarantee systems for confirmed collection transactions that ensure the merchant to collect amounts in cryptocurrency conveyed in payment transactions effectively confirmed on the blockchain, or included in a block of transactions that has a height [1] sufficient to ensure that there is no “Double-spending” [2];
Guarantee systems against fluctuations in value that must preserve the amount of the merchant’s collection from the volatility characteristic of some cryptocurrencies.
To better understand the usefulness of the merchant plug-in, we also use in this case an example that relates to the scope of the collection method described above.
We will decline this method in detail, referring to both contexts of use: online, for e-commerce transactions, physical, for transactions at points of sale.
The plug-in in question is, in the world of e-commerce, a program that runs instantly in which the customer chooses to pay for the goods in cryptocurrency.
This application (integrated in the check-out process), undertakes to present the final price in the double currency (for example € and BTC), setting the exchange rate for a certain time frame (usually not exceeding 3 or 4 minutes) , in order to allow the start of the payment from the buyer’s wallet on the latter’s initiative.
In the physical world, however, the merchant’s plug-in is fully integrated into the application that the merchant uses to accept cryptocurrency payments. This application is responsible for interacting with the customer’s crypto wallet, usually presenting a QR code that represents the address to which an amount in cryptocurrency equal to the converted euro price will have to be transferred.
An application of this type can be hosted inside a cash register, or on a POS terminal, suitably prepared, but it can also become available as a stand-alone app, installed on the cashier’s smartphone or tablet.
The responsibility of the service providers who facilitate the merchant’s collections towards the merchant itself, is also extended to protect the merchant from the risk that a payment transaction initiated by a customer’s wallet is “double-spended”.
In this sense, the supplier guarantees, as part of the service contract, that the amounts in cryptocurrency “held” in the collection wallet are actually confirmed before converting them into euros, by sending them to an exchange platform.
In order to be able to protect the merchant from the fluctuations in value typical of some cryptocurrencies, the service provider must also undertake, by defining it in the contract, to convert into euro amounts of cryptocurrency collected at the same exchange rate, calculated at the moment in which the The merchant’s plug-in presented the customer with the amount in dual currency relating to the purchase.
In other words, also in this case exemplifying for a better understanding, if at 10:00 on 19 January 2022, an asset sold by the commercial establishment worth 1,000 euros is presented by the plug-in at an equivalent bitcoin amount, adopting a specific exchange rate valid at that moment, at 11:59 pm of January 19, 2022 (assuming a daily crypto-fiat conversion), the merchant must always and in any case receive 1,000 euros (net or gross of the commissions applied to him) , regardless of the update of the € -BTC exchange rate, valid when the cryptocurrency flow that “contains” the equivalent of 1,000 euros is sent to the exchange.
In both the circumstances just examined, similar to what we have anticipated for the problem of safeguarding cryptocurrencies, which can be found in cases where the supplier acts as “agent for the collection of crypto funds”, to date there is no Community rule that imposes protection systems for the legitimate beneficiary.
Therefore, it appears relevant to provide “ad hoc” forms of guarantee, defined and accepted in the contractual framework governing the service of facilitating collections in cryptocurrency.
Transit account
Let us now analyze more closely the process of converting the cryptocurrencies collected, in the hypothesis in which the service provider operates as “agent for the collection of cryptocurrencies”.
The supplier, through the exchange platform (or platforms) he uses, once the cryptocurrency balances have been converted into equivalent balances in fiat currency, must settle with the treasury of the company that billed the sales, for which he cashed in cryptocurrency.
The existing relationships between the collection agent and the exchange platforms that it uses normally require that the post-conversion fiat funds be deposited in a current account in the name of the agent.
This account, which we will call “transit account”, will be the account from which the agent will send a wire transfer (or a flow of wire transfers) to his merchant customer, at the settlement intervals defined in the contract.
The management of this “transit account” places emphasis on the role that the service provider hitherto simply called “crypto fund collection agent” actually plays. In fact, this management (at least from this point forward) is part of a payment service, as defined by the PSD2 [3], taking the form of the activity carried out by the supplier – to all intents and purposes – a performance of payment services.
This implies that the supplier in question is a qualified intermediary (it can be a bank, a payment institution or an electronic money institution), or that it requests and obtains an authorization from the competent authority of the Member State in which it has established the reason. social security, which enables it to provide payment services.
Alternatively, the subject can operate in partnership with an authorized intermediary, which must be highlighted in the service contract with the merchant.
The fiat funds placed on the “transit account” are, beyond any doubt, third party funds (ie merchants) and, as such, must be safeguarded in compliance with the protection rules provided for by PSD2 (the so-called ” funds safeguarding rules “), as well as isolated from accounting (the so-called” ring fencing “rules).
Otherwise, the merchant runs many risks, since the “transit account” is an account that is not in the name of himself, but rather his own supplier who can access it at any time.
This is a decidedly delicate issue that has just been dealt with, which poses various problems if it is not addressed correctly. Unlike what has been explained for what concerns the collection in cryptocurrency by the service provider, where, in the absence of any sector regulation, a correct use of multi-signature crypto wallet could mitigate the risks described in this case you need to pay close attention.
Other ways of approaching the problem could be managed which, however, are difficult to deal with in the economy of this article. Therefore, we limit ourselves to observing that in the absence of specific legislation on the provision of cryptocurrency transfer services, or the extension of other sector regulations (eg that on payment services) which also includes these transactions, the role of a authorized payment intermediary could validly extend, with a view to a possible diversification of the business, covering a part of the supply chain described so far.
The merchant’s onboarding processes
Having clarified the meaning of many terms and presented a mapping of the use cases examined in this article, we now come to outline the EU regulatory framework, with reference to the obligations that the provider of a service for facilitating cryptocurrency collections must honor in merchant contracting phase.
The supplier, in the exercise of the services we have described, may plan to carry out both the custody of the cryptographic keys and the exchange activity, independently, or by making use of third parties with whom it has outsourcing relationships. In both circumstances, it can offer (or propose) respectively:
- a “custodian wallet provider” service;
- a “centralized exchange provider” service;
These activities fall within the scope of the fifth anti-money laundering directive (EU directive 2018/843 [4]) and, therefore, the supplier is obliged to carry out appropriate due diligence processes for its customers.
Voluntary self-declaration by merchants who collect in cryptocurrency
Analyzing in particular recital no. 8 of the fifth anti-money laundering directive, it should be noted that the EU legislator suggests to examine “further the possibility of allowing users to submit, on a voluntary basis, a self-declaration to the designated authorities”.
In this circumstance, there is an obligation to consider how our country has already (rectius was) carried forward with the transposition [5], in the summer of 2017, of the fourth anti-money laundering directive [6].
The Department of the Treasury, in fact, in the preparation of a ministerial decree through which it would have defined the methods and times with which the service providers relating to the use of virtual currency are required to communicate to the Ministry of Economy and Finance their operations on the territory of the Italian Republic [7], had placed in public consultation – which ended on February 16, 2018, the draft decree which includes the disclosure obligations “also commercial operators who accept virtual currencies as consideration for any service having as object goods, services or other utilities.
The initiative aims to carry out an initial systematic survey of the phenomenon, starting from the numerical consistency of operators in the sector who, when fully operational, will have to register in a special register kept by OAM [8], the Body of Agents and Mediators , to be able to carry out their business on the national territory “.
The use of the conditional and the imperfect are (still) a must. In fact, four years after the end of the public consultation referred to above, the decree has not yet been promulgated. Consequently, the planned special section of the currency changers held by the OAM has not yet been established, leaving those who, on Italian territory, wish to operate in this sector in a deep perimeter of indeterminacy.
Having said this, commercial operators who accept virtual currency as consideration for any performance relating to goods, services or other utilities, could be attracted to the fifth anti-money laundering directive in relation to what is expressed in recital 8. If this were the case, it nevertheless appears appropriate to underline the voluntary character – and not mandatory – assumed in the EU text in contrast to what is expressed in the MEF ministerial decree scheme of 2018.
NOTE
[1] The height of a block refers to the position of the block in the chain.
[2] Since each node of a DLT that implements a blockchain protocol contains the same information as the others and, in this way, it knows all the history of the transactions that took place as well as all the other nodes, how can you be sure that they are not validated blocks that contain false transactions? If there were a node that, surreptitiously, tried (and succeeded) to alter the history of transactions, by inserting a false transaction such as to generate a problem about the ownership (or the exchange of ownership) of the exchanged asset, it would run the risk of the so-called “Double Spending”. There could be the case in which the cryptoassets transferred from the merchant’s customer to the merchant, of which the latter believes he can boast the availability, is, an instant after the transfer from the customer, re-attributed to the same customer, thanks to the intervention of a node which, voluntarily, alters (in this case to the detriment of the merchant) the history of transactions. Only when the merchant tries, in turn, to transfer the cryptoassets he believes he can legitimately dispose of to others (for example when he wants to send them to the exchange), will he realize that it is as if he had never entered them. possession (so he could notice it even after a long time). On the Bitcoin blockchain, for example, it is good practice to wait until the transactions have received at least six confirmations, i.e. that they are in a block six validation cycles away, compared to the moment in which you want to have your bitcoins (usually the time waiting time is about an hour).
[3] Directive (EU) 2015/2366.
[4] Directive (EU) 2018/843.
[5] The implementation of the fourth anti-money laundering directive took place with legislative decree no. 90.
[6] Directive (EU) 2015/849.
[7] Pursuant to Article 17-bis, paragraph 8-ter of Legislative Decree no. 141 of August 13, 2010, as introduced by Article 8, paragraph 1, of Legislative Decree no. 90.
[8] Body provided for by Article 128 undecies, of Legislative Decree. September 1, 1993, no. 385.
