A key value proposition of NFC-enabled phones for consumers is speed. No need to search your wallet or purse for the right card; just wave that ubiquitous phone by the reader and pass on by. NFC payments will certainly be quick, but I doubt they'll be much quicker than today's magstripe and smart cards. Does it really matter whether I swipe, dip, or tap my card? So why should anyone care about NFC?

I believe the value comes when NFC is used for multiple purposes in the same transaction. The real time-saver lies in replacing the need for my loyalty card, coupons, and payment card with a single tap of the phone. But is this really achievable?

During our experiments with NFC, we found it to be too time consuming to open each of three files to read the contents representing loyalty, coupons, and payment. It took roughly two seconds per file, which doesn't sound slow, but it moves the consumer from a "tap" to a "tap and hold."

o avoid this issue, we combined the data from all three files into a single one, using separators between the data types. This works well, enabling the consumer to simply tap to handle the combined data exchange with POS. But realistically, the data is owned by three different organizations, and they will want their own files.

So far we've just talked about reading data. Writing data takes a big longer, and moving the phone away from the reader during a write operations will cause an error. When a coupon is redeemed, we may want to erase it, or add a new one during checkout. This extends the time even longer.

The fastest approach might be to simply store a read-only unique identified on the phone that a third party can link to a loyalty number, list of coupons, and payment choices on some far away server. Forcing all the work to the back-end servers would certainly simplify the role of NFC but also require the POS to be online.

I'm no NFC expert, so I'd love to hear from one that can explain how we're going to deliver on the promise of speed.