One of the greatest challenges we face today in our high-tech, interconnected world is protecting sensitive data from sophisticated cybercriminals and nation-states. Of course, the best way to protect this information is never to share it or, at least, limit with whom we share it and require them to destroy the information immediately after use. Unfortunately, this isn’t life in the 21st century. Just the opposite. We are faced every day with trade-offs between convenience and privacy. And for payments, this means that we are often sharing – and allowing the storage of – our card and bank account numbers, numbers that when compromised can allow thieves to steal our money, destroy our credit, and wreak havoc on our lives.
The widespread storage of our account numbers means that there are many more places that can be breached by criminals and nation-states. The compromise of millions of credit and debit card numbers stored at large retailers in recent years (think T.J. Maxx, Target, and Home Depot) and the ever-evolving and increasingly sophisticated nature of cybersecurity threats have forced payment system stakeholders to enhance the security of their systems.
The fortification of payment systems has taken many forms. In the world of card payments, these new defenses include chips embedded in our credit and debit cards that guard against use of fake cards at physical points of sale; convenient online controls offered by many banks that enable us to turn our cards “on” and “off” with a tap on our phone or a mouse click; and services that enable us to make mobile and online payments without having to disclose our card or bank account numbers.
This last category of defense ensures that card numbers are not shared and stored unnecessarily. This is accomplished through the use of special, limited-purpose numbers, known as tokens, which can be used in lieu of our actual card numbers in our mobile and online payments. In other words, banks, card networks, and other service providers protect sensitive data by replacing it with non-sensitive data in transaction processing. To date, tokens are most widely employed in the card space, though payment system stakeholders would like to extend the use of tokens to other payment types such as Automated Clearing House1 (ACH) and funds transfer systems. Whether tokens can be widely deployed for other types of payments may well depend on resolving a conflict between current needs to protect payment systems in a cybersecurity-vulnerable world and a mid-1990s view of payment transparency contained in the Bank Secrecy Act. (NOTE: There is a token service available in the Automated Clearing House today for the beneficiaries of commercial payments. The Clearing House Payments Company LLC launched a service in 2002 that enables corporate entities to use a token, known as a UPIC, to receive credit payments. More information about this service is available here. Payment system stakeholders would like to extend a token capability to debit payments and consumer payments in the ACH).
More about Tokenization
The conversion of sensitive data to non-sensitive data is known as tokenization. It can be achieved in many ways, and its value as a security enhancement ultimately will depend on the exact implementation. In the United States, tokenization primarily has been used in connection with card payments. However, even for card payments, the process used to tokenize card numbers (and related standards) vary in response to differences in card transaction processing (e.g., point-of-sale, e-commerce).
At a general level, tokenization in the card space relies on technology that results in the substitution of a unique number generated for a particular transaction in place of the payer’s card number. Because the technology generating the number does not rely on an algorithm, the ability to revert back to the original number is nearly impossible. The randomly generated number (the token) has no value on its own. Only the issuer of the token can associate the token with the original card number. Of course, the “token vault” that associates the token with real card numbers must be protected in accordance with very high security standards.
The use of tokens increases the level of security for card numbers in several important ways. First, and perhaps of most importance, it significantly reduces the number of databases that store the sensitive card information and therefore the number of potential targets for hackers. The token can be used in all of the merchant’s back-end systems and processes. Second, it removes reliance on encryption to protect data at rest. While encryption is an important information security tool, it is based on algorithms that a sophisticated hacker may be able to crack. Once the encryption has been cracked, the hacker would have access to the sensitive credit card numbers.
Of course, the value of tokenization in the United States could extend well beyond card numbers, and the idea that tokenization should be considered in other contexts is gaining steam. For example, in a recent white paper issued by the Federal Reserve Bank of Boston, the authors discuss the current state of tokenization and call on the industry to consider how this technology can be used to protect, among other things, demand deposit (i.e., bank) account numbers in payment systems such as ACH.
While there is always a cost when enhancing security, the costs of enabling tokens may be outweighed by the fraud losses that tokens will prevent. Who will bear this cost may determine the speed with which tokenization is adopted, but it is hard to imagine that a customer of a bank would object to having the option of using a token to guard against the possibility that the customer’s bank account number is compromised in one of the many places where it is stored today. And bank customers ultimately may demand such protection. This might be especially true of small business account holders that do not benefit from the protections afforded consumers under laws such as the Electronic Fund Transfer Act (EFTA) or Truth in Lending, and that may not have the resources of larger organizations to prevent or limit the impact of an account compromise.
Tokenization and Payments Subject to the Travel Rule
While the use of tokens in a particular payment system is generally regarded as a technology and operations issue, the ability to implement tokenization of certain business payments and even certain consumer payments over funds transfer systems may hit an unexpected legal roadblock known colloquially as the travel rule. The travel rule is contained in regulations issued by the Financial Crimes Enforcement Network (FinCEN) pursuant to the Annunzio-Wylie Anti-Money Laundering Act of 1992, which amended the Bank Secrecy Act. (NOTE: In its mission to “safeguard the financial system from the abuses of financial crime, including terrorist financing, money laundering and other illicit activity,” FinCEN acts as the designated administrator of the Bank Secrecy Act (BSA). The BSA was established in 1970 and has become one of the most important tools in the fight against money laundering.) It requires financial institutions involved in funds transfers to include certain information in their payment instructions in order to assist law enforcement investigations of money laundering and other crimes. (NOTE: The term “financial institution” is broadly defined under the travel rule to include not only banks but entities such as broker-dealers, money services businesses, certain casinos, and mutual funds. 31 CFR 1010.100(t)).
Importantly in the context of tokenization, the travel rule requires the payer’s financial institution to include in a payment instruction at the time it is sent to the next bank in the funds transfer chain, the name and, if the payment is ordered from an account, the account number of the originator. Thus, by its terms, the travel rule does not permit the use of a token as a substitute for the originator’s account number. While the travel rule also requires the payer’s financial institution to include the name and address of the payee, the account number of the payee, and any other specific identifier of the payee, the obligation to include this information is tied to actual receipt of the information from the payer. (NOTE: The originator’s bank must also include the address of the originator; the amount of the payment order; the execution date of the payment order; the identity of the beneficiary’s financial institution; and either the name and address or numerical identifier of the originator’s financial institution.) As a result, if the payer provides only the payee’s token as “the specific identifier of the payee,” then the payer’s bank satisfies this aspect of the travel rule by including the token in its payment instruction. (NOTE: The travel rule would require all subsequent financial institutions involved in the funds transfer to include the information they receive in their follow-on payment instructions. In other words, the information must “travel” with the funds transfer. Id. (f)(2)).
The travel rule has not been an issue in current tokenization efforts for cards because of the rule’s narrowly tailored scope. The rule applies to certain “transmittals of funds,” which, until recently, were limited to non-bank money transfers and wire payments (i.e., funds transfers) of $3,000 or more. (NOTE: Even if a payment is a funds transfer as defined in the regulations, the travel rule requirements do not apply if (a) the funds transfer is for an amount less than $3,000, or (b) the payer and the payee are any of the following: (i) A bank; (ii) A wholly-owned domestic subsidiary of a bank chartered in the United States; (iii) A broker or dealer in securities; (iv) A wholly owned domestic subsidiary of a broker or dealer in securities; (v) A futures commission merchant or an introducing broker in commodities; (vi) A wholly owned domestic subsidiary of a futures commission merchant or an introducing broker in commodities; (vii) The United States; (viii) A state or local government; (ix) A Federal, State or local government agency or instrumentality; or (x) A mutual fund. Also excluded are funds transfer where both the payer and payee are the same person and the payer’s financial institution and the payee’s financial institution are the same bank or broker or dealer in securities. 31 CFR 1010.410(f)(4).) This is because the rule expressly excludes a number of payment types, namely consumer funds transfers governed by EFTA, and consumer and commercial funds transfers made through an automated clearinghouse, an automated teller machine, or a point-of-sale system. In contrast, consumer and commercial payments sent over wire transfer systems and certain commercial payments sent through new payment systems such as The Clearing House’s RTP (Real-Time Payments) and other potential payment systems that may be developed are subject to the rule. Hence, expanding tokenization to these payments requires that tokens be permissible under the travel rule. (NOTE: Specifically, payments sent by a commercial entity to another commercial entity (i.e., “B2B” payments) of $3,000 or more that are sent through the RTP system are subject to the travel rule. In addition, consumer payments sent through the RTP system that are not subject to EFTA, such as, potentially, payments to or from a trust account, of $3,000 or more would be subject to the travel rule. However, it is not expected that such non-EFTA consumer payments will be common in the RTP system.)
The question that arises for those payments subject to the travel rule is whether FinCEN will interpret or revise the rule to enable the payers involved in those transactions to benefit from the enhanced data security protections afforded by tokenization. (NOTE: While the focus of this article is on tokenization of bank account numbers, the authors note that another aspect of the travel rule requires the use of true names; the use of a code name or pseudonym is prohibited. See Financial Crimes Enforcement Network, “Funds ‘Travel’ Regulations: Questions & Answers,” November 9, 2010. Available at: https://www.fincen.gov/resources/statutes-regulations/guidance/funds-travel-regulations-questions-answers. Hence, there may be additional travel rule – and sanctions screening – issues to the extent existing or future payment systems might employ aliases to protect the names of payers.) In addition to large-dollar business-to-business payments that are made over wire transfer systems, covered payments could include a consumer making a down payment on a home by wire or a small business getting paid by another business for services rendered (e.g., designing business cards) made over the RTP system. It would seem hard to justify an outcome where the benefits of the tokenization technology would not be available to consumers and small businesses when they send wires or businesses that pay each other over RTP. After all, cybercriminals do not make distinctions based on whether a particular payment is subject to the travel rule or not. Therefore, it’s important to consider the origins and purpose of the travel rule.
The travel rule was developed specifically to help remedy difficulties encountered by law enforcement in the 1990s due to the absence of payer and payee names and other identifying information in many payment instructions. The decision to include the payer’s account number was made despite concerns even at that time that such information was sensitive information, the disclosure of which created heightened fraud risk. At the time, the Treasury Department concluded that the risk of fraud was low compared with the value that inclusion of the number would have for law enforcement efforts.
In particular, the Federal Register notice adopting the final rule explained that a payer’s account number “will be particularly useful to law enforcement in cases in which delay occasioned by a search for account information would hinder the success of an investigation.” The Treasury Department also concluded that the inclusion of account numbers “will present only a minor increase in the risk of fraudulent transfers” since banks “generally have security procedures that include passwords, codewords and, in the case of electronic transmissions, confirmation to ensure that only authorized parties issue payment orders.” On balance, the Treasury Department found that the security procedures employed by banks “reduce the potential for fraud … to a level at which that risk does not outweigh the immediate and tangible benefit to law enforcement derived from the inclusion of account information in transmittal orders.”
But much has changed since 1995. At that time, the internet was in its infancy. And we did not have mobile apps, big data, or the associated threat of massive data breaches. Further, the last 20 years have seen an increasing intermediation of payments by non-bank service providers that may not employ – and are not regulated to ensure – the same level of security that banks provide to sensitive financial information. Additionally, the level of sophistication of today’s cybercriminals and the sponsorship of those criminals by nation-states is something that was not anticipated at the time the rule was implemented.
Moreover, the risk of data breach is better understood today than it was in 1995. The risk of data compromise is not isolated to the payment system over which a payment instruction is sent but, rather, flows out of the payment system and into one or more back-office applications of the entities being paid (e.g., invoicing systems, sales support) and sometimes even to third parties that work with the payee or obtain data from the payee. It is because of these risks in the current environment that efforts are being made to tokenize sensitive information and to limit the flow of sensitive information across all payment channels. What reasonably may have been construed as a low risk in 1995 can no longer be analyzed the same way.
But there is reason to be hopeful that with modern security technologies such as tokenization we can fulfill the needs of law enforcement while allowing all payers to secure their bank account numbers. Unlike the requests received from commenters in the early 1990s, no one is suggesting that the payer’s account number be entirely removed from a payment instruction. Rather, the token would take the place of the account number and would travel with the funds transfer in the same manner that the account number would have traveled.
As a condition for permitting the use of a token, FinCEN would presumably expect that the payer’s bank, which is identified in the funds transfer, could readily provide the payer’s account number associated with a token either from the bank’s own records or those of the entity operating the token vault. This might mean that the travel rule may need to be revised to place an obligation on token vault operators to store and make retrievable the account number associated with a token for a five-year period, which would correspond with the five-year period that banks must retain travel rule information for each applicable funds transfer they send.
Whether these conditions would be enough to allow FinCEN to become comfortable with the use of tokens in place of account numbers in funds transfers is not yet known. What is clear is that it will be critical to communicate with FinCEN now and to consider the needs of law enforcement as the industry continues forward with tokenizing bank account numbers.
