<p>Watched any movies in Beta format lately? Didn't think so. Back when Beta and VHS were battling it out, few people chose Beta – leaving VHS the ultimate survivor. (At least until the advent of DVD, but that's another story.) What killed Beta wasn't inferior technology; in fact, most engineers will tell you it was the superior technology. But there was a much bigger selection of movies in VHS, which is why most of us took that route. Beta and VHS were competing options that performed the same function. Similarly, when it comes to transaction processing, credit unions can choose from among competing standards that facilitate the electronic exchange of data – something that's vital in our increasingly networked world. But is it better to choose the OFX standard, or IFX, or XML? It's a common question – but one that doesn't really compare apples to apples. A better understanding of each can help your credit union make the most informed decision. OFX (Open Financial Exchange) is a messaging protocol created by Microsoft, Intuit and Checkfree in 1997 and used by over 1,400 financial institutions today to enable the exchange of financial data electronically. It provides functionality in four main areas: Internet banking, bill payment, bill presentment, and investment/tax services. Its greatest distinguishing feature vs. IFX is that it enables the interface of Internet banking applications with personal financial management packages like Quicken and Money, eliminating the need for manual data entry. It also supports the data exchange required for investment and tax documents (like W-2s and 1099s), while IFX doesn't. While it wasn't always the case, the most current version of OFX is XML compatible. In fact, both OFX and IFX utilize XML as the fundamental underlying protocol. IFX (Interactive Financial Exchange) is likewise a messaging protocol that enables the exchange of data across multiple providers and platforms. While it doesn't support Quicken or Money, IFX does appear more technically robust than OFX in some cases, allowing for more finely detailed functionality. For instance, it supports the transaction requirements of ATMs and appears to have the advantage in supporting commercial processing. One of its key drawbacks is that it's developed at a later point in time than OFX, in turn slowing its adoption. Currently, IFX is found primarily in highly specialized software applications vs. the conspicuously mainstream applications using OFX. However, the consortium behind IFX has picked up steam and now appears to be developing support for new functionality faster than the OFX group. Promising initiatives include the current draft of a loan origination specification that is available for comment. XML (Extensible Markup Language) isn't a third option, though it's often misconstrued to be. Instead, XML is the underlying, foundational technology that both OFX and IFX use to perform their messaging functions. It's like using a piece of steel to make a bike and a car; both will get you to your destination, but they work very differently. The primary function of XML is to put data into a "meta data" format. That's a fancy way to say that XML provides self-explanatory tags to tell you what the data is – whether it's an account number, a balance, or some other information. XML provides that tag before the data and again after the data. Traditionally, a typical payroll record might have looked something like this: 00147000456789437926666061420020154937 Pretty hard to figure out what the other computer system is trying to tell you to post and to which account. In XML, rapidly becoming the lingua franca of data exchange as we try to connect more and more disparate computers more easily, this same data might look like this: 147 456789 437926666 06142002 154937 Each set of XML messages is also validated against a specialized file called a schema, which contains rules that the XML server uses to verify the structure of the XML data and to validate the data itself, i.e. monetary amount, alphanumeric data, field lengths, etc. The beauty of these tags is that they tell you, in plain English, what kind of data you're looking at. So let's say you've just purchased a third-party software package and want to interface it to your core system – a familiar scenario. If the two suppliers have built XML compatibility into their software, each application will much more readily recognize the data being communicated by the other – facilitating an easier, faster interface process. The Bottom Line Like Beta and VHS, both OFX and IFX (utilizing XML behind the scenes) will continue to survive alongside each other for a time. Which will eventually emerge as the market's preferred choice will depend much on their incorporation into mainstream applications. That in turn will be driven by the extent to which their respective consortiums see a business advantage to funding such development, and the degree to which industry standard message definitions emerge and are widely accepted. It may take some time before the landscape becomes clear. Some technology folks believe that over time, the two will simply merge and become a single standard. What can your credit union do in the meantime? First, know what standards your current or prospective core system supplier is using to facilitate data exchange. You can argue the finer points of OFX vs. IFX; but what's more important is that your supplier is employing some type of XML-based strategy. XML is rapidly gaining acceptance and being adopted for high-demand applications – from Internet banking and bill payment, to voice response systems, wireless banking and more. As the challenge of managing increasingly mixed hardware and software environments continues, so too will the need to get their disparate components interacting effectively. And having XML under the hood is the best way to accomplish that goal – quickly, affordably, and efficiently. Second, be wary of any supplier that disdains open standards in favor of an API (application programming interface). It's true that an API will accomplish the task of interfacing one system with another. But APIs are proprietary and non-transferable from one application to the next. That means each time the supplier has to connect with another party's applications, it will require a new development effort all over again – slowing down deployment and increasing costs. As long as credit unions continue to choose technology components from multiple sources and members continue to demand electronic delivery channels, there will remain a vital need to interface dissimilar applications effectively. With true open standards in place – backed by the power of XML – that process can be done on a "one to many" basis, resulting in faster, more affordable implementations.</p>