Links Related
to this Story:

• palm.com

How the Evolution to the IrFM World is Taking Shape

B y H.R. Damon González Jr., Dover Court Consulting This is the second in a series of articles on the concept, creation, evolution and potential future of a project to standardize an important component of payment initiation systems. What you will be able to take away from this part of the story is an introduction to the specification development process, an idea of who the players are and an overview of the project's goals and guiding principles.

Review and Key Concepts In the first installment in this series, I set the backdrop for Infrared Financial Messaging (sometimes called proximity payments or transactions) by outlining its purpose and place in a payments system. An important idea in the discussion was that the development effort was not necessarily limited to a given communications technology or even, for that matter, a particular type of payment instrument.

In fact, IrFM is chiefly about creating a standardized set of "virtual railroad tracks" that are paperless, available anywhere and represent a benefit to consumers and merchants alike without burdening the rest of the infrastructure. Before we get into the project activities, however, the term "payment instrument" deserves a little more explanation because there is an important idea behind the label that plays a big role in the mechanics of the protocol and how the software and transaction equipment will support it.

A payment instrument is something, be it a credit or debit card, a check or even the side of a cow, that effectively authorizes a transfer of value. What you are actually doing with a paper check is giving written authorization for a third party (usually a bank) to move value from your account with them to another personal or business account.

Likewise, a credit card backed by a signed transaction slip or possibly a Personal Identification Number (PIN) entry allows a bank to transfer value to someone else on your behalf and simultaneously increase the balance of a loan it is making to you. In either case, the key concept, and the point of this explanation, is that whatever the instrument, the underlying mechanism is an authorization instructing a third party to transfer value.

It is all done with accounting entries executed in the bowels of a financial institution somewhere. However, as we all know, every rule has an exception, and in this instance it is the event of a buyer and seller using currency (paper money, coins and various kinds of tokens). In such cases, the value to be transferred is understood to be in the coin or the bill. There's no third party involved. Nonetheless, IrFM also will accommodate this difference in a very specific way.

But back to the point: The "authorization" concept is important for several reasons.

First, the authorization method of payment has built-in value protection so that you are never faced with something like the consequences of losing a thousand dollars in currency. A bad credit card or check transaction (among the kinds IrFM will support) can be researched and fixed; lost cash is gone forever.

Second, the authorization method, based on accounting entries, simplifies the task for IrFM's protocol by permitting replacement of paper and plastic with digital authorizations.

Third, avoiding the currency method of payment means not having to carry a pocketful of paper and coins. Currency can be reduced to a virtual equivalent in the IrFM protocol and still retain built-in protections against loss.

So now, with some of the finer points under our belts, let's get on to the project itself.

Core Values and Principles

From the beginning, the IrFM project has been guided by a handful of fundamental beliefs about its role and its development principles. These ideas, which came to give scope and direction to the effort, included both operational and environmental elements.

- Operational: Most important of these was to set an aggressive timetable for the evolution of a final specification. The thought was that documenting message sets and running a number of proofs of concept could be done simultaneously. Concurrently, a decision was taken to start the work with a small core of workers (five to seven, maximum).

The group believed that a "strike force" would be able to make speedier headway and create critical momentum while the "iron was still hot." In effect, a stake in the ground would become the rallying point for subsequent participants. This last point was important because incorporating all stakeholders was considered the best way to assure a useable standard.

- Environmental: Remember that the protocol is intended to manage a very specific component of a commercial transaction - transmitting a payment (actually, the payment authorization we discussed earlier) from a buyer to a seller and receiving confirmation of that payment back to the buyer from the seller wirelessly.

Within that context, the project also built its operating philosophy around the key direct and indirect parties to this part of a payment transaction. These parties are referred to as stakeholders, and they are consumers, merchants, financial institutions, manufacturers of point-of-sale equipment, software developers and financial services transaction processors.

Accordingly, ease-of-use, economy and simplicity for the direct stakeholders (consumers and merchants), and minimal, if any, changes to the "back-end" clearing and settlement processing systems already in place became guiding principles in the protocol development.

With these ideas as a road map, the project moved on to its work. Lifecycle of a Proposed Industry Standard

Infrared Device Association (IrDA) organizes the development of a technical specification into a number of steps, or milestones, each of which is marked by a comprehensive review and approval procedure culminating in a vote that paves the way for the next stage.

Step One begins with the creation of a business plan, internally known as a Market Requirements Document (MRD), which is presented as a justification for convening a technical working group.

Step Two involves creation and approval of a Directional Specification.

Step Three is the completion of a Draft Specification.

And finally, Step Four concludes with the publication of Final Specification. A Final Specification then will have undergone, at every step, an analysis in IrDA's Architecture Committee, Marketing Committee and Interop Committee. Likewise, each step will have been punctuated with a review and approval from the association's Board of Directors. In IrFM's case, the story began with a white paper titled "Infrared Financial Messaging," published Oct. 15, 1999, that ultimately became the de facto MRD. Throughout November and December of that year, a small core of IrDA member companies, led by CrossCheck, Inc. of Rohnert Park, Calif., started work on assembling a work plan for building the IrFM protocol.

By January 2000, the IrFM SIG was convened and the participants began writing a Directional Statement and Version 1 of the Preliminary Draft. Along with CrossCheck, the IrFM SIG included Palm Computing, ACTiSYS, VeriFone, Caliber/ZiLOG, Novalog, Visa International and Personal Solutions Corp.

By July 2000, CrossCheck, using early models of VeriFone's POS devices, infrared adapters from ACTiSYS and its internal mainframe-based risk management system, executed a real-time, production-grade wireless check authorization. Meanwhile, final refinements were being made to the Directional Statement. While work proceeded on the Directional Statement and Preliminary Draft, the next generation of a proof of concept was undergoing development.

Building on a successful first test, the project demonstrated an enhanced version of wireless check approval at PC Expo 2000 in late September 2000 in Tokyo. By the end of December 2000, several of the SIG companies had completed working payment demonstrations.

One of these wireless payments demonstrations was shown in the keynote presentation by Carl Yankowski, CEO of Palm Inc., at the CES 2001 in early January in Las Vegas (see www.palm.com and click on Company and then on Awards & Articles). In this example, he purchased a shopping bag of personal electronics from Sharper Image's SVP of Sales, who was attending an on-stage mockup of one of their stores.

It was a historic moment. Thanks to a virtualized version of a Visa credit card and equipment from Ingenico and Extended Systems Inc., Yankowski was able to use his Palm V handheld computer to effect a payment instruction that was approved via a live authorization request over Visa's credit card network. And the world will never be the same again.

At this writing, the specification is approaching its final form. It will, in all probability, be a compilation of basic profiles and use cases designed to accommodate not only today's suite of payment options but also potentially infinite permutations of buyer and seller interactions.

We can expect that in addition to scenarios involving consumers at an attended in-store POS device, the protocol ultimately will be able to manage consumer payments at unattended devices such as soda-pop machines and toll booths.

The Final Specification is expected to be presented at IrDA's November 2001 quarterly meeting for approval. Upon ratification, the specification will be published for public consumption.

Implementations based on the new specification will begin in earnest. Star Trek disciples can look forward to tapping their communicators to pay for holodeck excursions when they're not using them to warn DS9 of an impending double-inverted singularity.

The rest of us will see the first steps toward a future where money, as we know it, will lose its familiar physical form and become digital instructions in a "point-and-shoot" world.