(June 24, 2010) While NACHA’s members officially signed off this week on using the existing WEB transaction code for mobile payments that use the automated clearing house network, the working group that recommended using WEB is already at work on further developments for mobile—including the issue of whether these payments should have their own unique transaction code.

The group was set to meet on Thursday in San Diego to work out a list of priorities. Issues before the group include whether the WEB code should be expanded to cover ACH credits as well as debits, person-to-person payments via handsets, and a dedicated mobile code, according to Devon Marsh, a senior vice president at Wells Fargo & Co. who leads the NACHA Rules Work Group on Mobile ACH Payments. “The outcome of the meeting will be to see which one tops the list,” Marsh tells Digital Transactions News.

The group is also encouraging banks and processors to start using as soon as possible the new rule incorporating mobile transactions into WEB, though the rule carries a Jan. 1 effective date. “The implementation date should be viewed as a no-later-than date,” says Marsh. “There’s no reason you can’t do it today.” WEB is the existing e-check code for e-commerce debits, or payments that consumers authorize merchants to pull out of their accounts. Credits, by contrast, are payments that consumers instruct their banks to make to merchants or other parties.

The decision to forgo, for now, a dedicated transaction code for mobile payments has disappointed some observers ever since the recommendation first emerged late last summer (Digital Transactions News, Sept. 21, 2009). Currently, Herndon, Va.-based NACHA, which regulates the ACH network, cannot track mobile-transaction volume, a situation that will not change after Jan. 1. This lack of visibility has sparked concern that efforts to develop effective safeguards against fraud and other risks could be hindered before mobile payments go mainstream. “There are going to be issues with fraud and security risks unique to mobile,” notes Menekse Gencer, a former PayPal Mobile executive and founder of mobile-payments consultancy mPay Connect. “If you don’t start tracking that now, you don’t have a history. You don’t wait until it’s already hit mass market before you put a transaction code on this.”

Marsh says his group had to weigh the need for a unique transaction code—what in ACH parlance is known as a standard entry class code (SEC)—with the need to let banks act quickly and cost effectively in introducing a new service. The introduction of an SEC can be a laborious process for banks and processors, requiring extensive reprogramming and training costs. “A unique SEC is challenging from a technical point of view [in that] so many participants in the network would have to make a change that will not benefit them in the short term,” says Marsh.

The last SEC NACHA introduced was IAT, a code for international payments that went into effect in September. Software and training requirements for this code were such that NACHA allowed a 23-month lead time before implementation. “That was a very expensive project,” recalls Mike Herd, managing director of ACH network rules at NACHA. IAT was extraordinary, however. Herd estimates the usual lead time for a new SEC is nine months to a year.

Now, in addition to the SEC question, the working group will begin considering a raft of other issues surrounding mobile ACH payments. Among these will be questions concerning person-to-person transactions, seen as a natural application for mobile devices. Herd says one question is whether and how to attach information with these payments that would tell recipients, for example, why the sender is making the payment.

With the working group already starting to hammer out priorities and, ultimately, recommendations, NACHA will probably start work on new rules for mobile transactions some time in the first half of next year, Herd says.