Portals & Rails
October 27, 2014
ISO 20022 in the United States: What, When, Why, and How?
At the October 2014 Sibos conference in Boston, there was considerable discussion about the International Organization for Standardization (ISO) 20022 standard, which many major non-U.S. financial markets began moving toward a few years ago. ISO 20022 is a public international standard for financial sector global business messaging that facilitates the processing and exchange of financial information worldwide.
In Canada, adoption drivers include the use of domestic messaging standards in proprietary ways that created inefficiencies and the need for enhanced remittance data to add straight-through processing and automated reconciliation, according to a Canadian speaker at the conference. A speaker from Australia explained how the new real-time payment system that country is building will use ISO 20022, and one of the drivers is the desire for rich data to enable automation.
The United States is behind in the adoption curve, which raises the question, why? Several Sibos sessions included discussion of a study commissioned by an industry stakeholder group and conducted by the advisory firm KPMG. (The stakeholder group—which consists of representatives from the New York Fed, the Clearing House Payments Company, NACHA–The Electronic Payments Association, and the Accredited Standards Committee X9—formed to evaluate the business case of U.S. adoption of the ISO 20022 standard.)
KPMG interviewed participants of markets already moving toward adoption and found that adoption was largely driven by both infrastructure change, as in the Australian example, and regulatory requirements. In addition, many U.S. firms, beyond the large financial institutions and corporations, lack in-depth knowledge about ISO 20022. Two additional barriers in the United States are (1) the exact costs of ISO 20022 implementation are difficult to pinpoint, in part because they vary by participant, and (2) the country has no industry mandate for adopting the standard.
In one conference session, a speaker categorized some of the strategic reasons the United States should move forward, framing them in terms of the risks of nonadoption. These reasons include:
- Commercial reasons: The U.S. industry will have to bear the incremental costs of maintaining a payments system that does not integrate seamlessly with an emerging global standard.
- Competitive reasons: Many countries are experiencing such benefits of the ISO standard as increased efficiencies and rich data content, but U.S. corporations and financial institutions will fall farther behind.
- Policy reasons: The U.S. market will become increasingly idiosyncratic, with more payment transactions conducted in currencies other than the U.S. dollar.
Recommendations from the KPMG study include initiating adoption of the ISO 20022 standard in this country first for cross-border activity, starting with wires, and then ACH. The U.S. industry should then reassess domestic implementation.
Because communication is keenly important to overcoming the lack of knowledge of ISO 20022 in the U.S. market, the stakeholder group is currently focusing on educating affected groups about the key observations and findings of the KPMG study.
No particular timetable or course of action has been determined for U.S. adoption, which makes it the ideal time for industry input. What's your institution's perspective on the adoption of the ISO 20022 standard in the U.S. market?
By Deborah Shaw, a payments risk expert in the Retail Payments Risk Forum at the Atlanta Fed
October 20, 2014
Let's Talk Tokens, Part III: What Problem Does Tokenization Solve?
Portals and Rails recently embarked on a series of posts on tokenization. In the first installment, we defined tokenization and distinguished between a merchant-centric enterprise tokenization solution and payment tokens generated as an issuer-centric end-to-end solution. In the second installment, we examined several different attributes of the issuer-centric end-to-end token initiatives currently under way and considered their impact on mitigating risk. In this post, we examine the shortcomings of end-to-end token initiatives and question if they are really a coup in mitigating risks in today's environment.
The goal of payment tokenization is to substitute sensitive data—such as account numbers, expiration dates, and security codes—that criminals can use to extract monetary value with surrogate values that lack monetary value. In light of the number and depth of recent data breaches, tokenization seems like a grand idea—let's get data that fraudsters can use out of the payment transaction flow and the merchants' systems.
But current uses for these end-to-end initiatives are limited to card-on-file transactions for in-app or e-commerce payments and mobile proximity payments. I know you have to start somewhere but, in the near future, only a small percentage of transactions will use tokenization. These end-to-end initiatives are solid solutions, but are currently extremely limited. Thus, there will be a continued need for the industry to use a variety of methods to fight fraud, including the merchant-centric enterprise tokenization solutions the first installment discussed.
And isn't the point of the significant EMV investment currently under way to mitigate risks associated with counterfeit cards using compromised card data? In other words, it should render compromised card data useless. But I am hearing the EMV naysayers claiming that, in an EMV world, data compromises will still take place and, while fraudsters may not be able to counterfeit cards, they can still use that data to shop on the Internet.
Those naysayers are correct.
But let's circle back to the use cases for the current issuer-centric end-to-end token initiatives. Is tokenizing payment data for card-on-file and mobile proximity payments really going to have a material impact on preventing card-not-present fraud? Are these tokenization efforts really the best solution for this challenge? It could be many years before we regularly use our mobile phones for proximity payments. I am confident that we will be using chip-enabled cards for a significant number of transactions within two to three years. Would it be wiser to rely on solutions that leverage the chip or other security features of cards? Or maybe it's time we realize that cards weren't designed for card-not-present uses and place a higher priority on the broader adoption of existing and emerging non-card-based payment solutions in a multi-layered security approach.
Unfortunately, I do not have the answers. But these questions and topics will certainly be discussed during the upcoming Securing Remote Payments conference that the Retail Payments Risk Forum and the Secure Remote Payment Council is hosting. If you are interested in attending, please reach out to us. We will be in touch with more details.
In the next installment in this series, we'll look at new security and operational risks introduced with these token initiatives.
By Douglas A. King, payments risk expert in the Retail Payments Risk Forum at the Atlanta Fed
October 14, 2014
Mobile Biometrics: Ready or Not, Here They Come
Apple's recent announcement about the release of its mobile wallet app—called Apple Pay—energized the mobile payments community. One reason for the spike of interest is Apple Pay's use of fingerprint biometrics as an additional layer of security in validating customers and their transactions. What may have gotten a little a little lost in the chatter that followed this announcement was another, related announcement. As reported in a September 19 FinExtra story, MasterCard (MC) announced it had completed a pilot project that used a combination of facial and voice recognition on a smartphone. MC said that the trial program—which involved MC employees around the globe conducting 14,000 transactions—had a successful validation rate of 98 percent.
The Apple and MC announcements together certainly show that the future of the additional security options on smartphones looks promising. As a recent post noted, consumer research has consistently found that consumers' largest concern about using mobile phones for financial transactions is security. But are biometric technologies ready for prime time? Will their application in the payments ecosystem really give payment providers more confidence that the person they are dealing with is not an imposter?
The latest generations of Apple and Android smartphones are equipped with fingerprint scanners, cameras, and microphones, which allow for the use of fingerprint, voice, and facial recognition. But limitations exist for each of the techniques. The Apple and Android fingerprint readers, for example, were compromised within days of their initial release. And facial and voice recognition applications work best in controlled conditions of lighting and with limited background noise—an unlikely environment for a smartphone user on the go.
But security experts agree that additional customer authentication methodologies—beyond the common user ID and password entry fields—increase the overall authenticity of transactions. Numerous companies are continuing to focus their research and development efforts on improving the reliability and use of their authentication products. So while there is no "one size fits all" authentication solution over the weak and easily compromised ID-and-password method, these biometric methods represent a step forward, and are likely to improve over time.
The Retail Payments Risk Forum is taking a close look at biometrics technology and its impact on the payments system. We are working on a paper assessing biometrics and authentication methodologies that will probably be released by the end of the year. We're planning a forum to be held this upcoming spring on mobile authentication technologies. And we're continuing to write posts on the topic in Portals and Rails.
Please feel free to contact us with your suggestions on biometric issues you would like to see us address in our continuing efforts.
October 06, 2014
Starting Off on the Right Note with Mobile Enrollment
In Rogers and Hammerstein’s Sound of Music, the classic song “Do-Re-Mi” begins “Let's start at the very beginning / A very good place to start...” Such a suggestion is essential in ensuring that the person enrolling in a payments system is, in fact, who he or she claims to be. The USA Patriot Act requires financial institutions (FIs) to develop a formal customer identification program that validates the customer when the account is opened. This program must specify the documentation that is used for authentication.
However, once the account is open, FIs have greater latitude in their procedures for identifying customers when the FIs handle account access requests, such as when a customer requests a change of address or enrolls in a third-party program that uses a card that the FI has issued to the customer. At that stage, it’s up to an FI’s own risk-management policies as to what documentation to require.
This situation can be risky. For example, let’s look at what happens when a customer wants to add a payment card to a mobile wallet that a third party operates. When the customer adds the card—enrolls with the third party—how can the FI that issued the card know that not only the payment card being added but also the mobile phone itself belongs to the right individual? How can the issuer efficiently and effectively ensure that the payment card information being loaded on a phone hasn’t been stolen? Adding any sort of verification process increases the friction of the experience and can result in the legitimate user abandoning the process.
Most mobile wallet operators use several techniques to validate that both the mobile phone with the wallet and the payment card belong to the rightful customer. (These operators send a request to the issuing FI as part of their enrollment process.) Some FIs require the operator to have customers submit their payment card information along with their cards’ security code and additional data, such as the last four digits of the social security number. Others may require just the payment card number, expiration date, and card security code, although such a minimal requirement offers little protection against a stolen card being added to a criminal’s phone. Still others require the customer to submit a photo of the payment card taken with their phone to verify possession of the card. If the issuer can obtain some of the phone’s device information, it can increase the level of confidence that the authorized cardholder is using their phone.
Regardless of what process is used, having strong identification controls during the initial enrollment step is essential to a sound risk management program.
By David Lott, a payments risk expert in the Retail Payments Risk Forum at the Atlanta Fed