Malta DLT Guidelines

Home \ VFA Legal \ Malta DLT Guidelines

Guidance on the use of Distributed Ledger Technology and the acceptance of Virtual Currencies through the implementation of a Sandbox Environment

Virtual currencies and Distributed Ledger Technology (DLT) are a new disruptive phenomenon in the digital currency and technology arena. The hype around their potential as a disrupter has been intense, with remote gaming being one of the sectors that may benefit from the use of virtualcurrencies and DLT technology. The Malta Gaming Authority’s (MGA) strategy to be at the forefrontof remote gaming regulation while embracing innovation, is balanced with the recognition that a prudent approach in this area is sensible and needed.

The characteristics of virtual currencies, while often cited as drivers for their adoption, simultaneously pose a number of risks which need to be addressed in a well-thought-out manner. The MGA is mindful that these risks need to be addressed in order to ensure that the necessary safeguards are in place to:

  1. Protect consumers;
  2. Cater for the prevention of crime and money laundering or funding of terrorism (with dueregard to the 4th Anti Money Laundering Directive); and
  3. Protect the reputation of the Maltese jurisdiction.

By consolidating perspectives of fellow stakeholders, of the online gaming industry and of key experts in these type of technologies, the Malta Gaming Authority is issuing for public consultation, criteria as set out in this paper for the establishment of a sandboxed (test and learn) live environment for virtual currency adoption within the remote gaming sector, whilst also drafting guiding principles for the application of DLT and its various adaptations within the industry.

While looking forward to receiving your feedback to this paper, on behalf of the Malta Gaming Authority, I would like to take the opportunity to thank all stakeholders who helped us reach this important juncture. Innovation is at the forefront of our strategy, coupled with a regulatory ethos which is designed to ensure a gaming ecosystem that enables economic development and innovation but most importantly continues building the necessary safeguards to prevent societal and criminal risks.




“Distributed Ledger Technology” or “DLT”means a digital or electronic database or ledger that –

  1. is distributed, decentralised, shared and replicated;
  2. may be public or private, permissioned or permissionless;
  3. is immutable and protected with cryptography; and
  4. is auditable.

A cryptocurrency is a resource of value on a decentralised peer-to-peer network. It is a math-based, decentralised convertible virtual currency that is protected by cryptography – i.e., it incorporates principles of cryptography to implement a distributed, decentralised, secure information economy. Cryptocurrency relies on public and private keys to transfer value from one person (individual or entity) to another, and must be cryptographically signed each time it is transferred.

A token represents a singular and unique type of cryptocurrency.

  1. A securitisation token represents ownership of the considered asset.
  2. A utility token grants user access to a future product or service.

A wallet, for the entire extent of the paper, refers to a cryptocurrency wallet. Such a digital wallet may store the private keys allowing one’s access to cryptocurrencies stored on the distributed ledger. A wallet may either be local or hosted. Only such wallets can allow transactions of cryptocurrencies. A combination of private and public keys is used to transfer ownership of funds in cryptocurrencies from one wallet to the other. Transactions in the cryptocurrency space are to be signed by thesender wallet’s signature script which is derivedfrom one’s private key, and sent to the receiverwallet’s address, which is in turn derived fromsuch wallet’s public key.


Smart Contract means an automatable and self- enforceable agreement in a form of technology arrangement on a DLT. Automatable and enforceable by computer code, although some parts may require human input and control. Enforceable either by legal enforcement of rights and obligations or via tamper-proof execution of computer code or by a mixture of both.

An operator in this paper refers to an online gaming operator (e.g. casino, betting platform).An entity is considered as an operator if it offers games or game portals either coming from its core team or from a third-party’s team.

A Licensee in this paper refers to an operator that has been licensed to operate a remote gaming operation by the Malta Gaming Authority.

Virtual Currency means and refers both to cryptocurrencies and to tokens.


1 Context

1.1 Introduction

This paper presents the Malta Gaming Authority’s (hereinafter ‘MGA’ or the ‘Authority’) position inregard to the acceptance of virtual currencies and the use of distributed ledger technology by operators regulated by the MGA. More specifically, it identifies and examines the details of a sandbox that will start in Q2 2018 and will last for the duration of 6 months. If the MGA deems it appropriate, the duration of the sandbox may be altered.

The paper starts with a consideration of the accepted characteristics and practices regarding virtual currencies, wallets and exchanges in order to lay down the regulations and parameters that shape this sandbox. Notwithstanding these characteristics and practices, potential participants in the sandbox are to also seek direction on potential regulatory requirements from other relevant authorities, as required. The discussion then focuses on the topic of safeguards which are meant to mitigate and contain the envisaged risks. This part also addresses the conditions that define how licensees are expected to adhere to reporting and ancillary obligations when participating within this sandbox environment.

In the second part of this paper, the discussion shifts from virtual currencies to distributed ledger technology and it particularly focuses on the hosting of game logic, regulatory data and wallet structures on distributed ledgers. Subsequently, this section examines the storage of players’ funds insmart contracts, and provably fair technologies.

Lastly, the paper will conclude asserting the MGA’s position outlining how the Authority will allow theuse of virtual currencies within the gaming industry through a sandboxed test environment along with a position outlining how the Authority will allow the use of distributed ledger technology by operators in the industry.

1.2 MGA’s Consultation Objective

The MGA is continuously analysing ongoing developments in the fields of Distributed LedgerTechnology (‘DLT’) and virtual currencies including their application in various technology and innovation driven industries. Conscious of the need to remain at the forefront of innovation and to keep up with new developments in these technologies within the gaming industry, the Authority, through the sandbox being proposed in this paper, is considering allowing the application of virtual currencies and DLT by its licensees through a sandboxed environment.

The consultation objective is to gather feedback on the proposed sandbox environment from the industry and other interested stakeholders.

1.3 Pre-Consultation Activities

On the 5th of December 2017, following the conclusion of an extensive study conducted on risks associated to DLT and virtual currencies, the MGA issued a call for interested parties to share information on their virtual currency and/or DLT projects. The MGA also met with a few of these interested parties in order to understand concepts and objectives behind these projects.

During the study on risks associated to DLT and virtual currencies, the MGA also gathered extensive feedback from other relevant Authorities including the MFSA, CBM and FIAU.


2 ConsultationProcess

2.1 Period

This consultation will be open for a period of 4 weeks from date of publication ending on the 30th of April, 2018.

2.2 Queries

Industry participants and all other interested parties are invited to send their responses to this guidance paper and any other related feedback on by the date stipulated above.

2.3 Post-Consultation

It is the intention of the Malta Gaming Authority to take on-board your feedback and publish a revised final version of the guidance paper in due course.


3 VirtualCurrencies

3.1 Characteristics of virtual currencies for eligible regulation

The necessary documentation to be presented to the MGA in order to commence the evaluation process for a licensee that wishes to accept cryptocurrencies as a means of payment shall include the following:

  • a business plan clearly describing the objectives, functionality and purpose of the initiative;
  • a timeline explaining the key milestones of the project; and
  • a Personal Declaration Form for each one of the persons of responsibility as defined in the Fit

and Proper Guidelines ( Guidelines-09092015.pdf). Should there be any politically exposed persons, they will be required to fill in the Politically Exposed Person Declaration Form.

The above is additional and without prejudice to the information and documentation which is required by the MGA as part of the licence application process, in the case of a new applicant. In the case of an existing licensee, where one or more of the above has already been submitted to the MGA as part of the licensing process, the MGA shall endeavour to avoid duplication.

3.1.1 Cryptocurrencies

Only cryptocurrencies which satisfy the following criteria may be accepted:

Financial Value

  1. The technology represented by the cryptocurrency has to provide value for the network participants, address a market requirement which is yet to be met and/or help solve a problem;
  2. The underlying network is to be public, trustless and decentralised;
  3. The financial system is available to everyone without being controlled by a single entity;and
  4. It is easy for members to participate in the economy, having control of their wealth and thefreedom to invest in it as they choose.

Technological Value

  1. The technology is open source, well documented and well tested by entities separate from the core development team;
  2. There is a working product either on a test network or a main network; and
  3. The technology is secure with prompt responses to discoveries of vulnerability andperformance issues.


  1. The technology behind the cryptocurrency has a clear roadmap for development and project milestones;
  2. There are practical applications either in the present or in the future for the technology; and
  3. The cryptocurrency is operating on its separate blockchain or is utilising an existing blockchain for practical purposes.

Market Conditions

  1. The cryptocurrency has a competitive market capitalisation in comparison with the general market capitalisation that is allocated to other digital assets;
  2. There is a trading pair between the cryptocurrency and fiat currencies; and
  3. The cryptocurrency is available to trade on asset exchanges and not restricted to onegeographic region.


  1. The cryptocurrency must be necessary in order for the platform to operate. Cryptocurrencies that are classified as physical assets are not eligible for consideration;
  2. There is a fundamental reason to purchase and hold the cryptocurrency based on its futureplan and vision regarding growth and milestones. Simple fundraising is not a valid enoughpurpose;
  3. There are ways to incentivise miners, validators and other participants on the network towork in a fair manner while penalising malicious behaviour, where this is applicable.
  4. There are strict security protocols limiting scams, hacks and theft of funds.
  5. The team behind the cryptocurrency should allow a fair distribution of it (limiting the riskof a small number of investors acquiring a majority supply of the cryptocurrency);
  6. The team behind the cryptocurrency should be available to respond to feedback andquestions about the technological product and the cryptocurrency; and
  7. The business plan and the technology’s website should have an ethical and professionalcode of conduct.

For the sake of clarity, it shall remain at the MGA’s discretion to evaluate whether the above criteria,or any one of them, are satisfied by a particular cryptocurrency. Such evaluation criteria may be revised on an ongoing basis and will adopt a risk-based approach.

3.1.2 Tokens

With respect to custom tokens created by licensees or applicants, the MGA shall assess whether to accept or reject the use of such tokens on a case-by-case basis and be guided by an evaluation of the following:

  • technology;
  • company structure;
  • market applications;
  • security; and
  • human resources.For the sake of clarity, the MGA also reserves the right, in its sole discretion and applying a risk-based approach, to revise its approval or otherwise of custom tokens from time to time. The creation, and acceptance by the MGA for the purpose of this sandbox, of custom tokens is without prejudice to any other regulatory requirements that may be required by other respective authorities.

3.2 Characteristics of wallets

The characteristics of wallets storing VCs for gaming will resemble any other VC wallet. This is because a wallet has a limited set of basic operations and properties, as listed below:

  1. A wallet has an address.
  2. Funds of the specific cryptocurrency can be sent to the wallet’s address.
  3. Funds of the same currency can be withdrawn from the wallet as long as there is a sufficientbalance to allow it.

Wallets may be self-hosted by the player, or held with a custodian wallet provider, which may also be an exchange. In all cases, only wallets whose address is specifically tied to the individual player shall be admissible for use in the gaming ecosystem.

3.3 Deposits

The ensuing procedures should be followed by the operator when a player wishes to make a deposit in a cryptocurrency:

  • Verification of the details provided by the player at registration shall commence upon theplayer’s first deposit. The player has to complete their verification process within 30 days of this deposit. Failure to do so will result in the player’s account being blocked along with anyassociated funds. No withdrawal may take place before the verification process has been completed.
  • The wallet address shall form part of the player’s registered identity with an operator, andnotwithstanding the above shall be verified as pertaining to the player before any deposit is made from it.
  • Whenever a player wishes to deposit from a different wallet address, the player shall add that wallet address to his registered details with the operator, and shall verify ownership of that wallet in the same manner prior to effecting any deposit from it. Withdrawals shall only be made to wallets which have already been verified and from which deposits have been effected. In exceptional circumstances, which must be duly explained by the player in question, a player may withdraw to a different wallet address solely and exclusively after proving ownership thereof and after the operator has conducted full CDD on the player evenif the €150 threshold (refer to section 5) has not been met.
  • Any pending transactions which do not match with a player’s verified wallet address shall be logged, and the funds reversed back to the originating wallet address. By doing this, the operator verifies that the content of every wallet is not only allocated appropriately amongst players, but also linked to verified transactions. Where such reversal cannot take place, the operator shall freeze the amounts and:
    •   if a player claims to have deposited from such address within fifteen (15) days, or such longer period as the operator may stipulate in its terms and conditions, the amount maybe assigned to such player’s account if the wallet is fully verified;
    •   if no player makes such claim, or the wallet is not successfully verified, the operator shall confiscate the funds.
  • Once the above is verified, each given transaction is processed and players are assigned their own portion of the holdings for gaming purposes.In the case of operators making use of smart contracts to execute game transactions and automate payouts to a player’s personal wallet, no wager may be made by the player unless the player himself and the wallet from which the wager is made are both fully verified and CDD has been carried out.

In the case of operators accepting payments in fiat currency as well as VCs, each VC shall be treated separately and exchanging between one VC and another shall not take place within the operator’secosystem. Provided that the acquisition of the operator’s custom tokens may take place on the operator’s platform if such acquisition is made for the use of the custom token in a closed-loopscenario within the operator’s platform. For the sake of clarity, in any such case the operator may sellits custom tokens to its registered players for fiat currency on its own platform, in order for such players to make use of the custom tokens on the operator’s platform itself, provided that the custom tokens may not be taken out of the operator’s platform and any withdrawals to be made shall be effected in fiat currency after converting the custom tokens, on the operator’s platform, at the sameexchange rate at which they were acquired.

Operators may wish to make use of third parties that accept cryptocurrencies from players whilst allowing the operator itself to deal solely in fiat currency. Such third parties may only be used if in possession of the relevant licence from a regulator within the EU or EEA, or any other jurisdiction which is deemed to provide equivalent safeguards.

The general principle is that the operator shall only allow each player to deposit and withdraw from one wallet address per VC. If the operator allows more than a single wallet for the same VC, then fullCDD shall be carried out on the player irrespective of whether the €150 threshold (refer to section 5) has been met.


For the sake of clarity:

  • Deposits in fiat currency shall only serve for the placement of wagers in fiat currency, and withdrawals shall be effected in fiat currency;
  • Deposits in VC shall only serve for the placement of wagers in the same VC, and withdrawals shall be effected in the same VC; and
  • Acquisitions, exchanges and, or sale of cryptocurrency by players on the operator’s platform and, or through the operator’s wallets shall not be permitted except when this is implemented in a closed-loop scenario.

3.4 Placing limits on players’ deposits in VCs

The value of VCs in relation to fiat currencies may go through periods of high volatility. In order to ensure that this volatility does not undermine the safeguards that financial limits aim to introduce, such limits are to be considered in Euro terms even where the deposit is made in a VC. Further detail on the exchange rate to which operators are expected to refer to is included in section 3.5 hereunder.

Currently, operators are required to maintain player-specified limits for fiat currencies; rather than include VCs within the same limit, operators should add a distinct player-specified ceiling for VCs that isdistinctfromthefiatcurrencylimit.Figure1illustratesthisprocess. Throughoutthedurationofthe sandbox, and without prejudice to deposit, wagering and, or loss limits which a player may set in terms of regulation 43 of the Remote Gaming Regulations (S.L. 438.04 of the Laws of Malta), no operator may accept deposits and, or wagers in VC by a player exceeding the equivalent of one thousand euros(€1000) per month (hereinafter the “maximum amount”). Nevertheless, and without prejudice to the general obligations of the operator to adhere to applicable anti-money laundering legislation, upon cumulative deposits or wagers, as the case may be, of one hundred and fifty euros (€150) or more ina rolling period of one hundred and eighty (180) days, customer due diligence obligations shall be triggered, as envisaged in section 5 hereof.

For the sake of clarity, in the same manner as deposit, wagering and, or loss limits, the maximum amount is considered on a player-to-operator level. Hence, a player can deposit the “maximum amount” with every operator they have an account with.

Due to the aforementioned high volatility, it is likely that during the lifetime of this sandbox, playersmay deposit a sum which is less than the “maximum amount”. However, after a period of time – perhaps without even playing a game, they might end up with a total that is significantly higher orlower than the “maximum amount”. As a result, the “maximum amount” will be defined through acumulative (summation) approach; when a player attempts to deposit funds into an account, the value in Euro terms will be considered at a rate at which time the funds deposited reached the operator.

In order to ensure the attainment of the objective of safeguarding players and the gaming ecosystem through the imposition of the maximum amount, either of two implementation scenarios are deemed acceptable. It should be noted that the two scenarios are completely distinct from one another and both the components and the conditions presented in each one are not applicable to the other.

Scenario 1

In this scenario (Figure 3), the operator has a maximum of one wallet for every supported cryptocurrency. The players issue deposits to the address of that wallet and use their account with the operator to notify that they just made a deposit from a certain wallet’s address. If the deposited amount respects the “maximum amount” and the deposit limit set by the player, if any, the funds are kept in the operator’s wallet and are made available to the player’s account for gaming use. Otherwise,if the operator receives a transaction without first being notified from a player’s account, the fundsare sent back to the originating wallet. In this scenario, the operator does not assign an individual wallet to each player. Instead, every player is assigned ownership of a balance virtually segregatedwithin one of the operator’s holding wallets, as represented hereunder in Figure 3.

Scenario 2

In this scenario (Figure 4), the operator assigns a gaming wallet for each currency to every player’saccount. The MGA only accepts this case if the operator has an intermediate wallet structure comprised of one or more wallets. Such an intermediate setup is used to accept deposits from theplayer’s personal external source of funds. However, in contrast to that scenario, if the deposited amount is within the “maximum amount”, the funds are forwarded to the player’s respective VCgaming wallet rather than allocating players a share of the operator’s wallet. The intermediate wallet reverses incoming transactions if they exceed the “maximum amount” and/or the funds come from awallet that is not expected to make a deposit. The player uses the account with the operator to inform of an incoming deposit and get feedback from the operator of the deposit being awaited.

This option is acceptable to the MGA because it not only guarantees, but also proves in a transparent fashion that the operators participating in this exercise place a hard limit on the deposits that a player can make. It also allows for reversal of funds in case of incoming funds of which the operator is not informed beforehand, and allows for implementation of restrictions on withdrawal where these are necessary in view of any applicable legal requirements.

3.5 Calculation of Exchange Rate

A major issue concerning the use of VCs within a regulated industry such as gaming is that due to their volatility, there exist significant differences between exchange rates of the same cryptocurrency amongst different exchanges. For the purpose of this consultation, the mechanism of determining the rate of exchange upon which to base the relation of value between the aforementioned cryptocurrencies and traditional fiat currencies throughout the sandbox duration, is yet to be decided and will be determined by the time the sandbox environment is published. For the sake of clarity, this designation will solely be for the purpose of calculating the exchange rate between a cryptocurrency and the Euro with regards to player-specified limits, the ‘maximum amount’ as defined herein, andthe calculation of any fees due to the MGA.

With regard to custom tokens the MGA shall, on a case-by-case basis, indicate the exchange to be used solely for those respective tokens approved for the purposes of this sandbox. Where the custom tokens do not have a fiat pair on any exchange which offers the necessary safeguards from the MGA’sperspective, the value thereof shall be assessed by using the exchange rate of such custom token withEthereum, and subsequently using such value assessed against Ethereum’s Euro value in order toderive the Euro value of the custom token.

For the sake of clarity, this position, as with other requirements within the sandbox environment, is subject to ongoing revision based on developments.

3.6 Player Liability Reporting

Any VC that the MGA deems suitable for the purpose of this sandbox is to be represented in theplayer’s liability report filed at the end of the month in the same way as with any fiat currency. Inaddition to the player’s holdings in a VC, the value in Euro terms is also to be represented. Due to the high rates of volatility, operators are to use the exchange rate of the last day of the month at 12:00:00 pm (noon) in UTC time for this purpose. The currency’s respective exchange rate specified by the MGA is to be used for obtaining this rate.

In addition to the players’ liability reports, with respect to VCs, any operators partaking in this exercise are to present a report of any failed return transactions (with respect to any invalid deposits) so as to be able to explain any money being held in their wallets without any ownership.


4 DistributedLedgerTechnology

4.1 Hosting of Games, regulatory Data and Wallets on distributed ledgers

For the duration of this sandbox, the MGA will accept games that are hosted fully or partially on a blockchain environment, provided that the operator shall ensure that the gaming service is not unduly disrupted by such operational setup.

In addition, the MGA also accepts the hosting of games on the operators’ servers whilst distributedledger technology is used in order to maintain the transparency and prove the fairness of these games. (For example: random number generator results).

Assigning wallets on distributed ledgers

As previously mentioned, all operators involved in the sandbox are to have their own wallets of all supported VCs either for fund storage or as an intermediate wallet. All of the collective players’ funds are stored either in the operator’s wallets or in their own wallets assigned to them by the operator (in the latter case, the operator shall only assign to each player a maximum of one wallet per VC). This is without prejudice to operators making use of smart contracts to execute wagers and payouts.

Furthermore, all payments received in a certain unit of VC must be returned by the operator in the same unit. At no point will the operator and/or players be allowed to transfer funds between different VCs on the gaming/betting platform. These platforms are not to be used as an exchange. Without prejudice to the generality of its powers, the MGA reserves the right at all times to ask for logs of any player and any wallet in the range of any date and time.

In the interest of player protection and due to the fact that VCs are considered as an anonymous- equivalent source of funds, the following withdrawal methodology is acceptable with respect to aplayer’s withdrawal of funds from the operator (cashing out). The operator shall only allow a player to withdraw funds to the same wallet that made the deposit. If this transaction fails or is not possible for technical reasons, the player is to be notified of such an issue. In order to add another wallet that is eligible for withdrawal, the player is to prove ownership of such a wallet in the same manner as ownership of the wallet used to make the deposit would have been verified. It is the operator’sresponsibility to ensure that this is achieved in a manner which adheres to its obligations in terms of AML/CFT. The means by which sufficient verification may be achieved include, but are not limited to:

  • Requiring the player to deposit a minimum amount of €1.00 in the equivalent value of the cryptocurrency at hand. For the sake of this argument, this amount is referred to as the “proof of wallet ownership deposit”. Once this is confirmed by the operator, the wallet will beavailable for a withdrawal. It is the duty of the operator to also reimburse the player for the“proof of wallet ownership deposit” in addition to the original sum that the player would liketo withdraw; or
  • Requiring the player to cryptographically sign the wallet with his private key, where this is possible.Withdrawal procedures shall, in addition and without prejudice to what is stated in this position paper, be in accordance with the relevant provisions of the Remote Gaming Regulations and any other applicable legislation.Deposits directly from exchanges shall only be accepted if the player is assigned a unique wallet and, or equivalent means of identification by the exchange, such that funds may be reversed to the same address from which the deposit originated and be accurately attributed to the same individual making the deposit. In the absence of these criteria, the operator shall also inform the players that funds

    cannot be funded back to a wallet belonging to an exchange. This applies both to player withdrawalsand reverse transactions when the “maximum amount” limit is exceeded. Furthermore, the operatoris to clearly notify the player of any terms and conditions regarding who should incur the transaction charges when depositing and/or withdrawing funds.

    The logging of successful and failed deposits and withdrawals is imperative so that the operator can be able to handle direct communication with players in the case of funds not being received from aplayer’s account or from an external wallet. By keeping logs of wallet addresses, transaction amountsand timestamps, the operators have the ability to verify whether a player’s complaint is legitimate, inwhich case a proper reimbursement of funds is possible, ensuring player protection.

    Furthermore, the MGA will not accept situations in which players can deposit funds and withdraw them without using them for gaming. As stated earlier, the wallets assigned by operators are to be used for gaming purposes and not merely to store funds. Each operator is to implement measures in order to ensure that this is achieved, applying a risk-based approach.

    4.2 Smart Contracts

    Smart contracts may, and in some cases must, be deployed for various reasons in an operation in which the technical setup is partly or wholly based on DLT. The MGA’s main regulatory focus is theiruse for the purpose of executing game transactions, in particular where funds pertaining to the player and held in a self-hosted wallet are held in escrow by a smart contract, which based on the outcome of the game then executes the payout to the player’s wallet, or transfers the player’s wager to the operator’s wallet, as the case may be.

    In such cases, this shall only be allowed when the following minimum criteria are satisfied:

    •   The wallet is verified as part of the player’s identity before any wager can be made;
    •   The necessary safeguards are in place to ensure that self-exclusion or player-specified limits,if any, and the ‘maximum amount’ are in all cases adhered to; and
    •   The smart contract is deployed in such a manner that it can be revoked, or neutered in anyother manner which the relative DLT permits, should a flaw in the outcomes generated by its code be discovered.As aforementioned in Section 3.2, no player may wager on a platform which makes use of smart contracts to automate payouts unless full CDD has been carried out on such player, including verification of the wallet from which the wager is made.

    4.3 Provably fair games

    The idea of provably fair gambling aims to provide assurance to the player of the true randomness of the outcome by means which the player himself can verify, rather than relying on testing and certification which the player himself cannot attest to. There are several distinct methods of providing such means of verification.

    The MGA finds it acceptable for operators to use such provably fair means of generating pseudo- randomness. Nevertheless, the requirement for certification of the random number generation, and any other element which the MGA may deem appropriate, by an independent testing body capable of conducting such test, shall not be dispensed with because the outcome is verifiable through DLT.

    5 Anti-MoneyLaundering

    On 5th February 2018, the MGA and the Financial Intelligence Analysis Unit (the ‘FIAU’) issued a revisedconsultation document (the ‘Implementing Procedures’) on the application of anti-money laundering and combating the funding of terrorism requirements to anyone who is licensed to provide a service involving the wagering of a stake with monetary value in games of chance, including games of chance with an element of skill, via electronic means of distance communication upon request from therecipient of said services, with the opportunity to win prizes of money or money’s worth.

    For the sake of clarity, the requirements stemming from such document, when finalised, shall be equally applicable to operators that are accepted within the sandbox environment envisaged herein.

    Moreover, operators shall ensure that their policies and procedures are developed and applied in such a manner as to duly cater for the risks which may arise, or be exacerbated by, the use of cryptocurrencies or custom tokens as a funding method and, or the deployment of smart contracts to automate payments, where applicable. Below is a list of non-exhaustive requirements which must be adhered to by operators within the sandbox environment over and above the obligations envisaged in terms of the Implementing Procedures, the Prevention of Money Laundering Act (Cap. 373 of the Laws of Malta) and the Prevention of Money Laundering and Funding of Terrorism Regulations (S.L. 373.01 of the Laws of Malta):

    • The details required for identification and verification of the customer (section 3.2 of the Implementing Procedures) shall include the wallet address/es to be used;
    • The threshold triggering CDD obligations in terms of section 3.3.2 of the Implementing Procedures shall be one hundred and fifty euros (€150):Provided that where smart contracts are used to automate payouts, verification shall be fully completed before any wager may be made in terms of section 4.2 of this Guidance document;For the purposes of applying the risk-based approach, cryptocurrencies and custom tokens shall be considered to be high risk Funding Methods in terms of Appendix 1 of the Implementing Procedures.

    6 Location ofTechnical  Infrastructure

    In December 2015, the MGA issued Guidelines on Technical Infrastructure hosting Gaming and Control Systems for licensees in remote gaming (the ‘Guidelines’). These guidelines do not take into account the possibility of hosting certain components on a partially or completely decentralised infrastructure. In terms of such Guidelines, the hosting architecture must be located in Malta and, or any EU/EEA Member State, or in any other third country jurisdiction wherein the Authority is satisfied that the same principles can be obtained.

    When a public distributed ledger is used to host components, the operator does not have control over who becomes a node in that ledger and where the relative equipment is located. Hence, where the Authority deems a proposed technical infrastructure based partly or wholly on a public blockchain to be acceptable, this requirement shall not prejudice such approval. This is without prejudice to theoperator’s duty to comply with all other obligations stemming from any applicable legislation or otherbinding instruments.

    7 Concluding remarks

    The MGA would like to thank all stakeholders in advance for their feedback on this guidance paper. The MGA is seeking detailed feedback from stakeholders before publishing its sandbox framework for cryptocurrencies.

    This consultation is open until 30th of April, and it is the intention of the Authority to issue a final version of the sandbox environment following consultation.