---
eip: 2020
title: E-Money Standard Token
author: Julio Faura <julio@adhara.io>, Fernando Paris <fer@io.builders>, Daniel Lehrner <daniel@io.builders>
discussions-to: https://github.com/ethereum/EIPs/issues/2407
status: Stagnant
type: Standards Track
category: ERC
created: 2019-05-10
requires: 20, 1066, 1996, 2009, 2018, 2019, 2021
---

## Simple Summary

The E-Money Standard Token aims to enable the issuance of regulated electronic money on blockchain networks, and its practical usage in real financial applications. 

## Actors

#### Operator
An account, which has been approved by an account to perform an action on the behalf of another account.

## Abstract

Financial institutions work today with electronic systems, which hold account balances in databases on core banking systems. In order for an institution to be allowed to maintain records of client balances segregated and available for clients, such institution must be regulated under a known legal framework and must possess a license to do so. Maintaining a license under regulatory supervision entails ensuring compliance (i.e. performing KYC on all clients and ensuring good AML practices before allowing transactions) and demonstrating technical and operational solvency through periodic audits, so clients depositing funds with the institution can rest assured that their money is safe.

## Motivation

There are only a number of potential regulatory license frameworks that allow institutions to issue and hold money balances for customers (be it retail corporate or institutional types). The most important and practical ones are three:
* **Electronic money entities**: these are legally regulated vehicles that are mostly used today for cash and payments services, instead of more complex financial services. For example prepaid cards or online payment systems such as PayPal run on such schemes. In most jurisdictions, electronic money balances are required to be 100% backed by assets, which often entails holding cash on an omnibus account at a bank with 100% of the funds issued to clients in the electronic money ledger.
* **Banking licenses**: these include commercial and investment banks, which segregate client funds using current and other type of accounts implemented on core banking systems. Banks can create money by lending to clients, so bank money can be backed by promises to pay and other illiquid assets.
* **Central banks**: central banks hold balances for banks in RTGS systems, similar to core banking systems but with much more restricted yet critical functionality. Central banks create money by lending it to banks, which pledge their assets to central banks as a lender of last resort for an official interest rate.

Regulations for all these types of electronic money are local, i.e. only valid for each jurisdiction and not valid in others. Regulations can vary as well dramatically in different jurisdictions — for example there are places with no electronic money frameworks, on everything has to be done through banking licenses or directly with a central bank. But in all cases compliance with existing regulation needs to ensured, in particular:
* **Know Your Customer (KYC)**: the institution needs to identify the client before providing them with the possibility of depositing money or transact. In different jurisdictions and for different types of licenses there are different levels of balance and activity that can be allowed for different levels of KYC. For example, low KYC requirements with little checks or even no checks at all can usually be acceptable in many jurisdictions if cashin balances are kept low (i.e. hundreds of dollars)
* **Anti Money Laundering (AML)**: the institution needs to perform checks of parties transacting with its clients, typically checking against black lists and doing sanction screening, most notably in the context of international transactions

Beyond cash, financial instruments such as equities or bonds are also registered in electronic systems in most cases, although all these systems and the bank accounting systems are only connected through rudimentary messaging means, which leads to the need for reconciliations and manual management in many cases. Cash systems to provide settlement of transactions in the capital markets are not well-connected to the transactional systems, and often entail delays and settlement risk.

The E-Money Standard Token builds on Ethereum standards currently in use such as [ERC-20], but it extends them to provide few key additional pieces of functionality, needed in the regulated financial world:
* **Compliance**: E-Money Standard Token implements a set of methods to check in advance whether user-initiated transactions can be done from a compliance point of view. Implementations must `require` that these methods return a positive answer before executing the transaction.
* **Clearing**: In addition to the standard [ERC-20] `transfer` method, E-Money Standard Token provides a way to submit transfers that need to be cleared by the token issuing authority off-chain. These transfers are then executed in two steps:
    1. transfers are ordered
    1. after clearing them, transfers are executed or rejected by the operator of the token contract
* **Holds**: token balances can be put on hold, which will make the held amount unavailable for further use until the hold is resolved (i.e. either executed or released). Holds have a payer, a payee, and a notary who is in charge of resolving the hold. Holds also implement expiration periods, after which anyone can release the hold Holds are similar to escrows in that are firm and lead to final settlement. Holds can also be used to implement collateralization.
* **Funding requests**: users can request for a wallet to be funded by calling the smart contract and attaching a debit instruction string. The tokenizer reads this request, interprets the debit instructions, and triggers a transfer in the bank ledger to initiate the tokenization process.
* **Payouts**: users can request payouts by calling the smart contract and attaching a payment instruction string. The (de)tokenizer reads this request, interprets the payment instructions, and triggers the transfer of funds (typically from the omnibus account) into the destination account, if possible. Note that a redemption request is a special type of payout in which the destination (bank) account for the payout is the bank account linked to the token wallet.

The E-Money Standard Token is thus different from other tokens commonly referred to as "stable coins" in that it is designed to be issued, burnt and made available to users in a compliant manner (i.e. with full KYC and AML compliance) through a licensed vehicle (an electronic money entity, a bank, or a central bank), and in that it provides the additional functionality described above, so it can be used by other smart contracts implementing more complex financial applications such as interbank payments, supply chain finance instruments, or the creation of E-Money Standard Token denominated bonds and equities with automatic delivery-vs-payment.

## Specification

```solidity
interface EMoneyToken /* is ERC-1996, ERC-2018, ERC-2019, ERC-2021 */ {
    function currency() external view returns (string memory);
    function version() external pure returns (string memory);
    
    function availableFunds(address account) external view returns (uint256);
    
    function checkTransferAllowed(address from, address to, uint256 value) external view returns (byte status);
    function checkApproveAllowed(address from, address spender, uint256 value) external view returns (byte status);
    
    function checkHoldAllowed(address from, address to, address notary, uint256 value) external view returns (byte status);
    function checkAuthorizeHoldOperatorAllowed(address operator, address from) external view returns (byte status);    

    function checkOrderTransferAllowed(address from, address to, uint256 value) external view returns (byte status);
    function checkAuthorizeClearableTransferOperatorAllowed(address operator, address from) external view returns (byte status);
    
    function checkOrderFundAllowed(address to, address operator, uint256 value) external view returns (byte status);
    function checkAuthorizeFundOperatorAllowed(address operator, address to) external view returns (byte status);
    
    function checkOrderPayoutAllowed(address from, address operator, uint256 value) external view returns (byte status);
    function checkAuthorizePayoutOperatorAllowed(address operator, address from) external view returns (byte status);
}
```

### Mandatory checks

The checks must be verified in their corresponding actions. The action must only be successful if the check return an `Allowed` status code. In any other case the functions must revert.

### Status codes

If an action is allowed `0x11` (Allowed), or an issuer-specific code with equivalent but more precise meaning must be returned. If the action is not allowed the status must be `0x10` (Disallowed), or an issuer-specific code with equivalent but more precise meaning.

### Functions

#### currency

Returns the currency that backs the token. The value must be a code defined in [ISO 4217](https://en.wikipedia.org/wiki/ISO_4217).

| Parameter | Description |
| ---------|-------------|
| - | - |

#### version

Returns the current version of the smart contract. The format of the version is up to the implementer of the EIP.

| Parameter | Description |
| ---------|-------------|
| - | - |

#### availableFunds

Returns the total net funds of an account. Taking into consideration the outright balance and the held balances.

| Parameter | Description |
| ---------|-------------|
| account | The account which available funds should be returned |

#### checkTransferAllowed

Checks if the `transfer` or `transferFrom` function is allowed to be executed with the given parameters.

| Parameter | Description |
| ---------|-------------|
| from | The address of the payer, from whom the tokens are to be taken if executed |
| to | The address of the payee, to whom the tokens are to be transferred if executed |
| value | The amount to be transferred |

#### checkApproveAllowed

Checks if the `approve` function is allowed to be executed with the given parameters.

| Parameter | Description |
| ---------|-------------|
| from | The address of the payer, from whom the tokens are to be taken if executed |
| spender | The address of the spender, which potentially can initiate transfers on behalf of `from` |
| value | The maximum amount to be transferred |

#### checkHoldAllowed

Checks if the `hold` function is allowed to be executed with the given parameters.

| Parameter | Description |
| ---------|-------------|
| from | The address of the payer, from whom the tokens are to be taken if executed |
| to | The address of the payee, to whom the tokens are to be transferred if executed |
| notary | The address of the notary who is going to determine whether the hold is to be executed or released |
| value | The amount to be transferred. Must be less or equal than the balance of the payer |

#### checkAuthorizeHoldOperatorAllowed

Checks if the `checkAuthorizeHoldOperatorAllowed` function is allowed to be executed with the given parameters.

| Parameter | Description |
| ---------|-------------|
| operator | The address to be approved as operator of clearable transfers |
| from | The address on which behalf holds could potentially be issued |

#### checkOrderTransferAllowed

Checks if the `orderTransfer` function is allowed to be executed with the given parameters.

| Parameter | Description |
| ---------|-------------|
| from | The address of the payer, from whom the tokens are to be taken if executed |
| to | The address of the payee, to whom the tokens are to be paid if executed |
| value | The amount to be transferred. Must be less or equal than the balance of the payer |

#### checkAuthorizeClearableTransferOperatorAllowed

Checks if the `authorizeClearableTransferOperator` function is allowed to be executed with the given parameters.

| Parameter | Description |
| ---------|-------------|
| operator | The address to be approved as operator of clearable transfers |
| from | The address on which behalf clearable transfers could potentially be ordered |

#### checkOrderFundAllowed

Checks if the `orderFund` function is allowed to be executed with the given parameters.

| Parameter | Description |
| ---------|-------------|
| to | The address to which the tokens are to be given if executed |
| operator | The address of the requester, which initiates the funding order | 
| value | The amount to be funded |

#### checkAuthorizeFundOperatorAllowed

Checks if the `authorizeFundOperator` function is allowed to be executed with the given parameters.

| Parameter | Description |
| ---------|-------------|
| operator | The address to be approved as operator of ordering funding |
| to | The address which the tokens are to be given if executed |

#### checkOrderPayoutAllowed

Checks if the `orderPayout` function is allowed to be executed with the given parameters.

| Parameter | Description |
| ---------|-------------|
| from | The address from whom the tokens are to be taken if executed |
| operator | The address of the requester, which initiates the payout request | 
| value | The amount to be paid out |

#### checkAuthorizePayoutOperatorAllowed

Checks if the `authorizePayoutOperator` function is allowed to be executed with the given parameters.

| Parameter | Description |
| ---------|-------------|
| operator | The address to be approved as operator of ordering payouts |
| from | The address from which the tokens are to be taken if executed |

## Rationale

This EIP unifies [ERC-1996][ERC-1996], [ERC-2018][ERC-2018], [ERC-2019][ERC-2019] and [ERC-2021][ERC-2021] and adds the checks for the compliance on top of it. By this way the separate EIPs are otherwise independent of each other, and the E-Money Standard Token offers a solution for all necessary functionality of regulated electronic money.

While not requiring it, the naming of the check functions was adopted from [ERC-1462][ERC-1462].

## Backwards Compatibility

This EIP is fully backwards compatible as its implementation extends the functionality of [ERC-1996][ERC-1996], [ERC-2018][ERC-2018], [ERC-2019][ERC-2019], [ERC-2021][ERC-2021] and [ERC-1066][ERC-1066].

## Implementation

The GitHub repository [IoBuilders/em-token](https://github.com/IoBuilders/em-token) contains the work in progress implementation.

## Contributors
This proposal has been collaboratively implemented by [adhara.io](https://adhara.io/) and [io.builders](https://io.builders/).

## Copyright
Copyright and related rights waived via [CC0](../LICENSE.md).

[ERC-20]: ./eip-20.md
[ERC-1066]: ./eip-1066.md
[ERC-1462]: ./eip-1462.md
[ERC-1996]: ./eip-1996.md
[ERC-2018]: ./eip-2018.md
[ERC-2019]: ./eip-2019.md
[ERC-2021]: ./eip-2021.md