Transaction Protocols
With the XFS (eXtensions for Financial Services) software standard, ATM deployers gained the ability to offer common applications across different makes of machines
Story link
(Not) lost in translation
by Ann All, editor 11 Jan, 2004
With the XFS (eXtensions for Financial Services) software standard, ATM deployers gained the ability to offer common applications across different makes of machines.
Yet channel integration remains largely out of reach for ATM owners. They can't easily offer common services across different delivery channels because ATMs, teller stations, voice response systems, point-of-sale terminals and other devices "speak" a different language when communicating with hosts for transaction authorization.
ATM message protocols such as NCR's NDC and Diebold's 911/912 are based on ISO 85/83, a 20-year-old standard that industry observers agree looks pretty creaky in the age of Internet standards like XML.
Lost in translation
"A teller station can't run 912," said Kevin Carroll, Concord EFS' director of ATM services. "A deposit message at the teller doesn't look like a deposit message at the ATM."
Not only that, but widespread modification of the proprietary NDC and 911/912 has "added a lot of pain" to the development process for new transactions, said Rick DuVall, a senior product manager at ACI Worldwide.
"If you own your own specification (like NCR and Diebold), you can modify it any time you like. And with emulation, you have varying amounts of cooperation among the vendors. So what we've gotten in the past is a lot of unique exceptions," DuVall said.
Legacy protocols like NDC and 912 have "hit the wall" in terms of future functionality, said Stephen Risto, director of NCR's APTRA Software Center of Expertise. "ATM deployers want more commonality with other financial channels in the enterprise."
Teaming on translation
A number of vendors -- including ACI, NCR, Diebold, Fujitsu, Wincor Nixdorf , Concord EFS and Mosaic Software -- are working to give financial services a common "language" by advancing an XML-based messaging standard called the Interactive Financial eXchange (IFX).
These vendors and such heavy-hitting financial institutions as Bank of America, Citibank, Wells Fargo and Wachovia are members of the IFX Forum. The forum, which was formed in 1997, has five working groups including one devoted to ATM and point-of-sale technologies. The other groups include electronic bill presentment and payment, business banking, credit application processing and Web services.
The ATM/POS group, chaired by Bank of America, ACI and NCR, began meeting in early 2002. It produced its first standard, 1.4, in less than a year. The standard supports the "big four" ATM transactions -- cash withdrawals, transfers, deposits and account inquiries -- as well as a number of more advanced functions such as cash recycling and dispensing of non-cash media.
Risto credits 1.4's speedy production to earlier multi-vendor cooperation on the XFS standard. "Because of XFS, we had the routine of working toward a common standard down," he said.
Part of the working group's task was familiarizing other forum members -- who had Web expertise but no previous EFT experience -- with the arcane requirements of the ATM world.
"They had no concept of things like downloading and sharing DES keys, status/health messages and transaction reversals," said ACI's DuVall. "If a PC crashes, the application doesn't care. In our world, we care -- a lot."
Mike Bengtson, Mosaic's vice president of product strategy, said an education process was required on both sides. "You couldn't just read through the specification and pick it up. There was definitely a learning curve for some of the EFT veterans who were used to ISO 85/83 being considered state-of-the-art."
What's Important
ATM message protocols such as NCR's NDC and Diebold's 911/912 are based on a 20-year-old standard called ISO 85/83.
A number of ATM vendors and deployers want to update ATM messaging by introducing an XML-based standard called IFX (Interactive Financial eXchange)
One of the key advantages of IFX is its ability to make ATMs and other devices such as teller stations and POS terminals speak the same language.
The adoption of IFX will likely to make it easier for the EFT field to attract young talent, Bengtson said.
"Attracting bright young engineers was a real challenge for the EFT industry, especially in the go-go '90s when everyone was interested in the Internet. It was hard to find college graduates who were willing to work with 1970s technology," he said. "You're always going to have a learning curve with ATM, but IFX will give you the ability to use off-the-shelf development tools for ATM applications."
Mosaic is adding IFX support to its eSocket line of products, which are designed to help third-party providers integrate their services with its Postilion software platform, Bengtson said.
Later this month, forum members are expected to review and ratify Version 1.5, which adds transactions such as money order purchases, person-to-person payment and prepaid phone recharges to the standard. It's less "plain vanilla" than 1.4, said Concord's Carroll. "It has more of the functionality that our customers have been asking us for."
IFX is far more flexible than NDC and 911/912, which are "single monolithic pieces of code," NCR's Risto said. "With IFX, you're taking states-and-screens away and replacing each piece with an inherent application. Each function is broken out and handled separately."
IFX will facilitate a move away from the traditional states-and-screens environment to client server architecture, a move long advocated by NCR, Risto added.
"You're going to hear different vendors tell completely different stories about the preparedness of their architectures. With APTRA Edge (NCR's multi-vendor, XFS-based software), functions such as the inherent application, transaction authorization and error handling and recovery are already separated, even when you use NDC for messaging," he said. "Switching to IFX will simply be a matter of removing the NDC proxy and adding IFX."
Too many cooks?
Also this month, IFX Forum members will review an ATM/POS implementation guide, designed to help business and technical personnel better understand how to use IFX to create transactions. The guide is necessary, Bengtson said, because the specification is so "exhaustive," offering multiple possible "recipes" for every transaction, even a simple cash withdrawal.
"If the IFX environment gets away from us, it could become geometric," DuVall said. "If we're not careful, we could end up with a Mosaic protocol, an eFunds protocol and an ACI protocol. We want the implementation guide to be a kind of 'cookbook' that will be thought of as the de facto way of doing things."
Although there is less room for proprietary interpretation with IFX than with ISO 85/83, possible ambiguities in the specification could hamper the creation of new applications, agreed Martin Macmillan, chief executive of Level Four.
"Right now you have basically two different protocols (NDC and 911/912) and everyone emulating them," he said. "If all of the vendors decided to create their own IFX protocols rather than using a single standard, you could end up with a potential bottleneck in development."
Level Four is adding an IFX module to its suite of development and testing software in 2004's first quarter because of customer demand, Macmillan said. "No one wants to invest in a platform that's not forward compatible. All of our RFIs and RFPs from the States now include IFX."
Macmillan said testing software such as Level Four's ATM Channel Development Suite becomes more important as deployers introduce a number of new technologies, including Windows operating systems, TCP/IP networking, Triple DES encryption, IFX and more.
"The whole pace of the industry is really picking up," he said. "You can't change everything at once and just sit there with your fingers crossed wondering if it's all going to work."
Warp speed, Scotty
Most industry observers believe that widespread adoption of IFX may occur within five years or so, a pace that seems practically warp speed for the usually slow-moving financial services industry.
Market forces seem to be working in IFX's favor. While a Windows-based ATM operating system and updates of both switch and ATM software will be required, NCR's Risto said many deployers are already making those changes in conjunction with their Triple DES upgrades.
The move to IFX requires a smaller leap of technology than the switch from an OS/2 to Windows operating system, Risto said. "Once you've made the move to Windows, IFX is going to be a far smoother and more intuitive move."
DuVall said ACI is already is working with an unnamed financial institution on a "live" IFX implementation involving PIN pads at teller stations used to help reduce internal fraud. "It's really happening; it's not just smoke and mirrors," he said.
In 2004's first quarter, ACI and NCR are partnering on the first live ATM implementation, at Nebraska's First National Bank of Omaha. According to DuVall, ACI expects another customer, a large financial institution, to introduce ATMs with IFX in the second or third quarter.
The success of these early projects will help spur adoption of IFX, Risto said. "I think a number of banks are leaning forward and starting to take notes. I expect to see serious movement toward IFX in 2005."
Mosaic's Bengtson expects adoption to be driven at least partly by analysts' increased scrutiny of IT departments at many financial institutions.
"There have been a lot of efficiencies gained in the past few years in the computing world, but the financial industry hasn't caught up to them," he said. "I think you'll see some analysts beginning to ask why these publicly-traded companies are running six different processing platforms and paying so much money to support them. Using IFX to get your channels speaking roughly the same language is part of the long-term solution."
Related topics would be things such as 3DES and the Patriot Act.
Posted by Craig at January 12, 2004 02:24 PM