However, the mere selection of features is not sufficient to ensure a safe and secure system. Meeting the goals of system safety and security will require careful consideration of the entire system including user behavior and financial transaction processes as well as hardware and software. Any electronic token system encompasses many vulnerabilities that are not fully addressed by encryption and digital signature technologies alone, but that are often attacked through faulty or negligent people and processes.
System implementation should make money-laundering, black market activities, and insider fraud difficult to effect and easy to detect. Some important system management controls, policies, and procedures in meeting this goal are discussed below.
Administrative controls can also be applied. For example, when electronic tokens are withdrawn or deposited remotely into an account, institutions could authenticate themselves to customers, as well as have the customers authenticated to the bank. Smart cards could require methods for the point-of-sale terminal device or computer to authenticate itself to the smart card. These techniques should not accidentally result in service denial to legitimate users. Additionally, "watch lists" of bad cards or tokens could be maintained to facilitate early interception of known fraudulent activities.
Certification authorities (CAs) -- Most implementations of electronic tokens will require a certifying authority, some trusted third party that vouches for the authenticity of a transacting party or identifying information such as the public key used for encryption and digital signature schemes. Consider, for example, public key digital signature mechanisms. In this case, the signing party encrypts a message with his/her private key and distributes his/her public key to the receiving party. The receiving party can decrypt the signed message with the public key and knows that only the person with the private key could have encrypted the message. But how does the receiving party know that the correct public key was sent? The public key could be included in a certificate signed with the private key of a well-known trusted third party.
Trusted third-party organizations are needed that can (1) vouch for the legitimacy of the distributed public keys and (2) certify and register ownership of the associated transaction devices. An electronic token system will probably require a hierarchy of such CAs, whose functions, policies, procedures, and interrelationships will need to be determined. For example, the following certification functions are needed: CAs who set policies for how their certificates are issued and distributed and who run the cryptographic systems, agents of the CAs who actually verify identities and/or issue certificates, and directories that publish certificates, certificate revocation lists, etc.
Issuers -- The issuers of electronic tokens must be willing to exchange the tokens they create/issue for actual money. Who should issue electronic tokens? Will each bank/government agency issue its own, individually identified electronic tokens? If so, must each entity honor and accept each other's tokens? Alternatively, will organizations issue tokens from a common pool? If so, should there be a central issuing organization? Should this be a governmental body like the U.S. Treasury or the Federal Reserve?
Should there be restrictions on who can issue electronic tokens? Should issuing organizations be licensed and/or regulated? Are international agreements and regulations required? Without sufficient controls and safeguards, a wide variety of official and unofficial currencies could be created and circulated via the NII.
Obligations -- Paper cash is obligated (backed) by the U.S. Government. Who should be obligated to honor electronic tokens? If a bank issues an electronic token, should the bank be obligated to accept it as long as it is certifiably authentic?
Liability -- Who is liable (i.e., suffers the loss) when an electronic token is lost or stolen? Should lost or stolen tokens be traced and/or replaced by the issuer as are traveler's checks, or treated like cash (i.e., not replaced)? If counterfeit electronic tokens are accepted in payment, who is liable? Is it the merchant or service provider accepting the electronic tokens, the bank or financial institution issuing the tokens, the bank or financial institution accepting the tokens, or the last person found holding the tokens when they were discovered to be counterfeit?
Escheatment -- State escheatment laws presently require accounts with unclaimed balances and unused traveler's checks to revert to the state after a specified period of time. Should electronic tokens representing digital cash similarly revert to the state if they remain unused after a specified period of time? If this practice is adopted, the electronic tokens system must be able to uniquely account for all issued and outstanding electronic tokens, and be able to determine which state is eligible to receive the funds.
Universality -- Universal service is a fundamental requirement of an electronic payment system. Anyone who wants to use electronic tokens should be able to obtain them, even if an individual does not have a bank account or a line of credit with a bank. Thus, people should be able to purchase electronic tokens with paper cash or government credits. Users should not need to be prequalified to obtain and use electronic tokens. However, since universal service should not necessarily imply anonymity, should users be required to identify themselves when purchasing tokens?
Regulation -- An electronic token system will need to support the enforcement of international, national, and state regulations preventing monetary fraud and abuse (e.g., tax evasion and money laundering). Simply setting a maximum allowable transaction size will not work because in a totally electronic world, computers could tirelessly exchange electronic tokens at the speed of light, effectively substituting one large transaction with many small ones. Rather, constraints are needed on the rate at which an individual user or device transfers money over the NII. Additionally, transaction amounts (e.g., the total amount transferred over a given period by a given user or device) should be monitored. The ability to perform this monitoring raises questions about how the electronic token system is implemented. Should tokens be tagged so that flows (perhaps of a given minimum value) of electronic currencies across geographic boundaries (e.g., states and countries) can be reliably reported? Monitoring transborder information flows without state and international cooperation will not work. A uniform international electronic commercial code and cooperation between law enforcement organizations are required.
Fees, float, and redemption -- Will users be assessed a fee (issuance charge) when purchasing electronic tokens? If so, will this charge be exacted at the time of issuance or billed for later payment? Are redemption charges appropriate? Between the time the token has been purchased and its redemption (float), the unclaimed money could be invested and could collect interest or could be treated like a cash withdrawal. Who keeps the float and for how long? Should there be any special reports or checks made at redemption, for example, to determine if the sum of payments made equals initial withdrawals?
Accounting -- There are various design alternatives regarding the extent to which electronic tokens are accounted for and by whom, and the way in which accounting records are stored. These various alternatives affect both the privacy and integrity of the transaction, often in opposing ways. Will user decrements, increments, balances, and entire transaction histories be recorded? Will records be maintained on user cards or devices, or in a control bank's or issuer's database? For how long will records be maintained? Should there be any federal, state, or local government requirements regarding accounting and recordkeeping?