Payments That Meet the Needs of Today And Tomorrow

The time has come to stop patching the nation’s outmoded payments system. Here’s a proposal for a modern, open, and secure alternative that leverages the existing rails.

As the payments world continues on its evolution to more and more transactions performed via remote means, such as Internet, mobile, pay buttons, and chatbots, it is becoming more evident that the fundamental payments architecture constructed more than 50 years ago and patched through the years with “improvements” such as PCI, EMV, 3D Secure, tokenization, and other techniques is still not keeping up with the needs of today’s environment and, more important, future environments.

EMV deployment in the United States is a prime example of how the patchwork does not sufficiently address the issues. Yes, EMV has mitigated the counterfeit card fraud risk. But it has done nothing for the fastest-growing fraud in the fastest-growing segment—card-not-present fraud types.

Instead, the global card brands would have the industry layer on more patchwork with 3D Secure 2.0 and their flavor of tokenization to attempt to mitigate those risks. These “solutions,” if enacted, will further strengthen the global brands’ hold on the plumbing of payments to the detriment of choice, innovation, and competition.

The payments architecture cannot continue to keep up with this patchwork approach. What is needed is a new architecture, built with today’s tools by today’s payments community, that leverages the full power of current technology for all payment types and with a nod toward future needs.

To address the needs of this architecture, the Secure Remote Payment council has launched a new initiative, the Open Secure Payments Standard (OSPS). In the following paragraphs, OSPS is described at a high level. We have much work to do to move it forward. If you like the direction it is headed in, we invite you to join us in helping to develop it into the framework of the future of payments. Contact us at Info@SecureRemote??PaymentCouncil.org for more information.

Overview

The Open Secure Payments Standard is a response to an industry call for a flexible and secure framework to support multiple environments and use cases. It provides an alternative implementation path for protecting sensitive data (particularly the primary account number, or PAN) other than that which is currently supported by the global card brands.

OSPS is designed to use the cryptographic and computational capabilities of any chip-based device (e.g., card, fob, pad, wearable, computer, etc.) to protect this sensitive data, and to enable implementation without detriment to those that do so. The standard is also designed to ameliorate the shortcomings of the EMV implementation in the U.S. by incorporating additional security into a self-protecting chip.

Conceptually, OSPS supports point-to-point transaction routing for both payment and non-payment data. The card data is owned and issued by an issuing financial institution, following its own standards and program decisions and managing the application outside of the rules of the global card brands.

Each transaction in the OSPS environment must have three basic components: a cryptogram, a transaction address, and a serial number:

• The cryptogram is defined and controlled by the issuer;
• The transaction address can be anything routable;
• The serial number is a non-transactable index value.

The combination of these three components is placed on the chip in the form of a profile, which the issuer then uses to authenticate the user and/or the card.

Fundamentals: Four Overarching Principles

1. Issuer-defined authentication of the chip and/or the user

In the OSPS environment, the issuer selects its choice(s) of authentication method (e.g., PIN, biometric, out-of-band, etc.), and is responsible for authenticating either the chip or the user, or both, at the issuer’s discretion.

A cryptogram (which protects all authentication data, chip and user) is created via an issuer-selected encryption methodology. Key management is also defined by the issuer. Both should meet industry best practices.

The issuer controls the card, so it is the issuer’s responsibility to place a cryptographic secret (symmetric key, PKI private key, nonce, etc.) in the card that verifies the unique cryptogram for each transaction. The issuer (or its agent) defines and creates the secret, without a requirement for third-party involvement, therefore firmly asserting the provenance of the identity of the card as issuer-originated.

The cryptogram protects the authentication data so there is no concern about exposing any credentials such as the PAN. The cryptographic-management capabilities of the chip completely protect the card transaction. Only the serial number exists in the clear outside the cryptogram. There is no requirement for any other intervening keys (like PIN keys in terminals or communication keys at processors or networks) to protect the transaction or the card information.

2. Transaction address for message routing

Message routing in the OSPS infrastructure is performed based on the “address” specified by the issuer. The address is not limited to the Bank Information Number (BIN), as in the case of EMV or traditional card payment transactions. Rather, messages can be routed via BIN, Web service URL, routing and transit number, IP address, phone number, etc., or some combination of all of these.

The instructions that govern the routing of such transactions to the issuer reside on the chip. The transaction address on the chip provides the payment ecosystem with the means and direction of the message. The OSPS framework will also support direct routing to the issuer.

The OSPS framework is applicable to a wide variety of applications, is agnostic, and can move money, points, coins, etc., or be used for non-monetary applications, such as identity and access. Because of this, OSPS does not define or require (nor does it prohibit) application-specific functionality on the card. This is a significant departure from other standards, such as EMV.

3. Non-transactable serial number

In an effort to make transactions more secure, it is important to take sensitive data out of the equation by making it non-transactable. In the OSPS framework, the issuer treats the serial number as a unique way to link the cardholder to the issuer and the transaction. The serial number has no transaction value but is used by the issuer and others for mapping and tracking.

The issuer generates the serial number and puts this in the chip. The serial number must be unique to the issuer for the cards it issues, but the issuer can choose any scheme to create that value. The serial number does not have to be globally unique.

4. Profile

OSPS introduces the concept of a profile—the combination of required authentication method, address, and serial number—that is placed on the chip by the issuer. More than one profile can be placed on the chip, and the chip should support multiple profiles. Profiles enable the chip to route transactions on both traditional and non-traditional payment rails, at the merchant’s discretion. For example:

• An ACH transaction profile based on a routing and transit (R&T) number;
• A EMV transaction profile based on a BIN;
• Direct to an issuer profile based on a Web-service URL

At the time of transaction, the merchant/acquirer processor chooses the profile it wishes to use, and in doing so implicitly agrees to the operating rules that govern the selected profile, as well as any issuer bilateral agreements or multilateral rules with the issuer(s) or federation of financial institutions, as facilitated by networks.

Co-Existence With Existing Payment Infrastructure

To achieve widespread adoption, the OSPS framework rides on the existing payment infrastructure and demonstrates interoperability. While it is necessary to support BINs that leverage the existing payment rails, the OSPS framework is much more versatile and expansive, enabling alternative and/or direct routing capabilities through transaction addresses (e.g., URLs) to access the issuer (or issuer processor) for authorization.

Moreover, the OSPS framework must be backward-compatible with EMV, supporting the co-existence of EMV Personally Identifiable Information (PII) and PAN data with the OSPS self-protecting card data.

Again, the issuer defines the authentication method and thus governs the level of security. Some issuer processors will create definitions about what issuers must do to maintain compliance. The OSPS framework should not prescribe requirements or be subject to some intervening body (i.e., PCI), although a regulator such as the Federal Financial Institutions Examination Council (FFIEC) may make recommendations about minimum standards for safety and security.

The goal of the OSPS standard is to enable these standards to co-exist with ISO and ANSI standards, but enable the issuer to authenticate the chip and the user, eliminating the need for privileged entities between the merchant and issuer.

OSPS Stakeholders

Roles for traditional players in the payment environment may change. Debit networks, for example, may not be involved in routing a URL transaction over the Internet but they may manage the relationship between the merchant and the issuer through multilateral arrangements and provide for additional functions needed for the application, such as settlement.

Traditional stakeholders need to determine where they want to play to add value to the payment transaction under the OSPS framework. Authentication? Clearing and settlement? Agreement acceptance? Brander or marketer of OSPS? Other?

New stakeholders may be introduced into the payment environment, e.g., payment application providers, cryptography experts, new payment brands, directory-service providers, etc.

Business Case Assessment

The OSPS framework will not likely impact points of acceptance (e.g., merchant point-of-sale terminals), but chip manufacturers will need to build functionality into the chips to support the profile-selection process.

The OSPS framework could potentially offer traditional issuers a low-cost option per transaction, based on fewer transaction entities involved in the payment-transaction chain. For example, an issuer that decides to encode a chip card with a transaction address of a URL to route messages directly between a merchant and issuer/issuer processor, could result in the bypassing of the acquirers, aggregators and networks.

Ubiquity, ease of accessing services, and open standards governing the OSPS framework are essential components to achieving such direct-routing capabilities. The framework provides merchants with choices to connect to issuers or issuer processors through open standards, while providing issuers with choices of providing ubiquitous access to authorization services and ensuring maximum transaction security. This creates a win for merchants, issuers, and cardholders from an economic, quality of service, and security perspective.

Since issuers will continue to be liable when EMV is completely rolled out globally, they may be shopping for an open solution with more security than is currently afforded or made available to them by EMV. The OSPS framework delivers on this promise, accommodating more flexible rules, simplified technology implementations, broader pricing options, and cardholder benefits.

In summary, the OSPS framework leverages the existing payment rails while co-existing with current ISO and ANSI standards. Through the use of a self-protecting card, PII and other sensitive data within a payment transaction is rendered meaningless to entities other than the issuer.

—Maria Arminio is president and chief executive of Avenue B Consulting Inc.

 

Processing a Transaction Using the Open Secure Payments Standard

1. A user with an OSPS-compliant chip (in a card, smartphone, key fob, wearable, etc.) makes a purchase at a merchant.

The chip contains a cryptographic secret used for encrypting both authentication data and one or more profiles consisting of:

– Serial number (to link user to issuer and transaction)

– Transaction address (routing instructions)

– User and chip authentication method (dynamic PIN, biometric, etc.)

2. The merchant processes the transaction and authenticates the user via its preferred method. The chip generates a dynamic cryptogram using its cryptographic secret, which protects the user and card authentication data.

3. Merchant generates authorization request, choosing its preferred routing instructions to send cryptogram and serial number to issuer, directly or through a third-party intermediary.

4. Issuer uses serial number to link to user account, decrypts cryptogram to confirm user authentication data, and authorizes (or denies) transaction.

5. Issuer returns authorization response to merchant, directly or through a third-party intermediary.