One major multinational corporation emphasized its enthusiasm for XML by calling all of its banks to an XML workshop, Baydalla says. "They want to start moving to XML this year. They found out that some banks were ready to support this move and some were not.

"U.S. regional financial institutions are generally less prepared for XML than the multinational banks," he adds. "Conversion is likely not going to happen right away. It depends on the ability of the banks to extract the information to be conveyed."

General Electric launched its first XML message traffic in August, communicating both payments and direct debits with RBC. "We are especially excited about moving direct debits to XML," reports GE deputy treasurer Dennis Sweeney. "We will roll it out first in Europe, where many banks are already using XML because of SEPA. Historically, each European country had its own rules and formats for direct debit. With SEPA, we're hoping to be able to use one consistent standard across Europe."

Sweeney expects messages about incoming payments to contain the more robust remittance information that XML is built to carry–like the invoice number, purchase order number and discounts taken–which will help to automate cash application for electronic payments and give GE useful information about its customers' payment practices, he says.

"XML is the great equalizer," observes Joe Spatarella, vice president of sales and marketing at Online Banking Solutions in Atlanta. "It makes it easy to transcend the barriers posed by different standards. It requires less intervention by people. With data normalized, file transfers blend into straight-through processing. We're hearing lots of requests from banks about becoming XML-capable. It's where everyone wants to move."

What's great about XML, says Brieske, is that it's standardized and truly dynamic. It promises to wipe out the many differences among bank payment and reporting protocols. "Banks are choosing to abandon their past practice of introducing proprietary differences into how they use global standards," he notes. "Each bank has its own EDI flavor. They aren't truly interoperable." Treasuries or their technology vendors had to customize interfaces to download and apply reports from multiple banks.

Once the migration to ISO 20022 XML is complete, there will be one format, one flavor and real interoperability, Brieske claims. Reconciliation will become truly automatic, he insists. XML uses very clear, defined fields. Companies can put an end-to-end reference number in a specially defined field of a payment message, such as "pain.001.001.02 credit transfer initiation," and it will come back in the appropriate specific field, untouched by any bank, in the reporting message, he explains. "It will always be in the same spot, regardless of the bank. It will be fully intact. It will make the auto-reconciliation process work better."

One benefit of XML, the large amount of granular data it can convey, will be particularly useful in bringing straight-through processing to accounts receivable and accounts payable and making supply chains far more automated, says Maggie Scarborough, managing director of FinServ Strategies in Baltimore. "It will move large amounts of data, like payments with full remittance information, in ways that don't rely on the Web," she explains. And XML will do that globally, Scarborough adds. "We're likely to see more and more integration of customer AP systems with supplier AR systems." The systems will talk to each other without human touches, she suggests.

If that sounds like the rebirth of electronic invoice presentment and payment (EIPP), in a way it is. More versatile technology is bringing new life to the goal of automating the settlement aspect of supply chains, Scarborough reports. When EIPP was attempted in the late 1990s, technological hurdles made widespread adoption cost-prohibitive. Now it's easier to achieve greater integration at a lower cost, she points out. Moreover, the economic crisis and tight credit have upped the ante for tight working capital management, and technology, aided by XML, is providing the tools to do it.

Interest also is high in another XML-based application, electronic bank account management (eBAM), which may work through SWIFT but doesn't have to, reports Tom Durkin, e-commerce executive for file and integration services at Bank of America. The key is establishing a digital identity for users.

"Users have a lot of frustration with multiple tokens, certificates and cards," Durkin says. "We can create a single digital identity for a user, at the individual level, not the corporate level." That ID is all the user needs to perform authorized tasks across the whole bank, he adds.

Ten B of A clients are already using digital signatures in a pilot that started in August. "It goes way beyond account openings," Durkin notes.

The dawn of practical applications of XML is not the only high-tech breakthrough that is exciting treasury operations managers. Integration through "mashups" is also taking a great leap forward. Software innovations are bringing "deep linkage" to treasury operations, reports Eric Campbell, chief technology officer at Bottomline Technologies in Portsmouth, N.H. The idea is to create invisible linkages among a variety of applications a treasury pro may be using. Instead of logging onto one application to do one task, then logging onto another for the next, different applications can learn to speak to each other so that the user has no sense of jumping back and forth.

It will be like shopping online, Campbell says. The catalog from which you make selections is a different application from a different vendor than the one you use to check out your purchases and pay, but the shopper never feels the jolt of moving from one application to another, he explains.

As software evolves, it's increasingly possible that treasury software vendors can embed each other's applications in their own, or that treasury or IT staffs can do that embedding, Campbell reports. "We show them how to apply the process," he says. "Once they see how to do it, they can replicate it across other applications. Banks have done it. Now corporate treasuries are looking at it."

It's easy to get carried away with the potential of new technology. On the ground, its practical value sometimes falls short of the promise, says Bruce Lynn, managing partner at Financial Executives Consulting Group in Darien, Conn. "Workstation vendors are guilty of overselling," he says. "But corporations don't always use helpful features but stick with inefficient workflows. That's why execution may not live up to plan and leave treasury staffs disillusioned. Some of the modules that drove the ROI case for getting the software end up never being used."

Systems are impressive when used fully, but for many companies, acquiring them amounts to overkill, Lynn argues. "You need a pick-up but they sell you a dump truck. Watch out for the gap between how tool builders think and how tool users think." Success can depend on training, he says.

From a historical perspective, treasury technology has grown through two stages and is entering a third, suggests Elaine Filus, a principal in the technology practice of consulting firm Treasury Strategies. The first, Treasury 1.0, was transaction-oriented, all about getting out the wires, finding balances and setting the cash position. Treasury workstations were developed in the 1.0 era to satisfy that demand. The second stage, Treasury 2.0, brought more demand for data collection and analysis, and that's where many of the specialist technology vendors got their start, Filus says. "Processing platforms were not enough," she says. "People expected decision-support tools."

Treasury 3.0 is still in its early stages, but it involves managing risk and liquidity at a very strategic level and gets closer to delivering treasury intelligence, not just parsed treasury data. Filus uses FiREapps as an example. In the 2.0 world, it would show total FX exposure, both locally and in the aggregate. In the 3.0 world, it not only collects but massages the data, applying the company's rules and policies, and presents the company with decisions it must make, she explains. "In 3.0, you find more alerts, more projections, more warnings of approaching violations, more presentation of choices."

Filus cites Debt Compliance Services' covenant violation software as an example of Treasury 3.0 because it spots trends that point toward covenant violations and sounds a warning while there is time to make corrections.

As software specialists come to own their niches, generalists look for ways to sign specialists up as partners, if they don't buy them outright, Filus notes. She cites SunGard's partnership with FiREapps and Wall Street Systems' partnerships with Reval and Misys. She also notes Wall Street Systems' purchase of Speranza and Open Technologies' acquisition of Weiland Financial.

Filus sees a technology continuum, with installed software at one end, and application service provider (ASP) and software as a service (SaaS) hosting at the other end, with SaaS becoming the preferred deployment method. SaaS represents a higher level of service and a more radical degree of outsourcing than ASP, she says. "In the ASP world, the provider might collect the scheduled reports from your banks and display them in the system, but if one bank failed to report, treasury would have to follow up," Filus says. "In the SaaS world, the provider would contact a bank that failed to report and fix the problem for the treasury."

Automation Gets Under Way

Michael Edmonds is realizing solid gains for US Magnesium, a privately held, midsize manufacturer of magnesium and chlorine products in Salt Lake City. "Two years ago, 99% of our disbursements from AP were by check. Today 80% of it is electronic," reports Edmonds, US Magnesium's chief financial and administration officer, who joined the company two years ago from Rio Tinto, where he supervised a shared service center that dealt with AP and AR on a larger, more automated scale.

Outgoing payments flow from US Magnesium's Oracle ERP system to Wells Fargo Bank, where they are executed, primarily through the ACH, Edmonds explains. The flow from Oracle to Wells is not seamless, but requires an adapter to bridge the file transfer. US Magnesium looked into building an adapter but found that an off-the-shelf adapter from Sierra Atlantic, a Wells partner, was the quickest, most efficient way to get the job done, Edmonds reports.

Now US Magnesium is using the flip side of its AP solution for AR, employing Wells Fargo's Receivables Manager tool to get a daily transmission of incoming payments from the bank lockbox. "We'll get a file from the bank with customer remittance information that will be ready for automatic cash application," Edmonds reports. While the solution was still being implemented at press time, he expects "a hit rate of better than 90%" automatic application.

US Magnesium is also exploring ways to automate bank reconciliation with electronically transmitted files in BAI formats. That will free up the assistant controller, who has been tied up with manual reconciliation tasks. Altogether, the automation projects will let US Magnesium shrink its AP and AR staff from three to two, Edmonds reports. –Richard Gamble

Beaming Over Cash and Currency

Nothing is more manual than dumping coins and currency from a cash register drawer into a deposit bag and driving it to a night depository box at a bank branch. Wires and ACH long ago made it possible to move value without moving substance. Then remote deposit capture dematerialized paper checks. Coins and currency constitute the last challenge, and Janet Bridges, director of treasury at Chick-fil-A, the Atlanta fast-food brand, is meeting it.

Chick-fil-A is a leader in using what Bridges calls "Smart Safe," a safe that now sits in the back office of 400 Chick-fil-A franchise restaurants, 25% of its 1,500 stores. Another 200 stores are committed to implementing it by the end of this month. Instead of hauling cash to the bank every night, restaurant operators feed it into the locked safes. Only armored courier Loomis, which owns the safes, can open them, not store personnel.

Storing money in a safe on the premises is hardly new. What's special about this is that every night Loomis electronically reads a record showing what has been deposited that day, then communicates it to Wells Fargo, its partner bank.

If a store deposits $1,000 on a Monday, that means $1,000 of good funds is available to Chick-fil-A in its concentration account on Tuesday morning, Bridges explains, even though the $10 and $20 bills are still sitting in the safe. Loomis comes in physically two or three times a week to service the safe and take away surplus cash.

Getting deposit credit for money that has yet to leave the store means improved cash availability for Chick-fil-A, which manages the stores' cash under its contract with franchisees. But safety and productivity are at least as important. The cash is less likely to tempt staff or would-be robbers.

"The restaurant operators love it," Bridges reports. "They say it's like having another employee." The safe won't accept check deposits. "There has been some talk about linking it with a check scanner for remote deposit," she says, "but we don't get many checks, so it's not a high priority here." –Richard Gamble

For more on advances in financial technology, see Mobility, Agility and Clouds Ahead.