XML

One of the basic challenges of XML developers is formulating best practices and design guides for defining their XML content. This is especially pervasive in industry communities, which is why there has been a growth of community-based XML specifications and standards.

In the financial industry, the Interactive Financial eXchange (IFX) Forum has been working for over seven years to develop a business message specification to satisfy the need for a community vocabulary and messaging specification in the retail and commercial banking arenas. But IFX is much more than just a community vocabulary. IFX provides design rules and a framework to successfully achieve consistency and interoperability, within a bank and between a bank and other entities.

About the IFX Forum
The IFX Forum is a nonprofit, market-driven organization comprising financial service institutions, service providers, and technology vendors working together to develop interoperable specifications to satisfy the needs of the financial services industry.

The organizational structure consists of the following:

• Steering committee: Acting executive body
• Architecture committee: Oversees IFX framework and architectural rules
• Working group(s): Formed as needed, facilitates messages based upon business requirements

The basic goal of the IFX Forum is to create reusable messages supporting a wide variety of applications that enable interoperability between heterogeneous environments. To achieve these goals, the forum leverages the following:

• Defined design rules: IFX strives for reuse, interoperability, object orientation, and extensibility.
• A structured message framework: Messages are consistently structured and have defined rules on how they are to be processed to allow both the client and server to have pre-defined and consistent expectations.
• Platform and technology independence: IFX may be implemented on any transport and computing platform.
• Interaction model independence: IFX can be used for real-time and batch transactions.
• Work with other organizations: IFX proactively works with other organizations to ensure, in areas of overlap, there is consistency and interoperability.

How IFX Messages Are Designed
While the great majority of IFX implementations are developed using XML, IFX has not been designed solely with XML in mind; rather, it is built as a technology-independent business semantic. IFX is then implemented in a technology, primarily XML. This separates the business semantic from the container (XML) and even the transport (such as HTTP or MQ).

By providing these points of isolation, the IFX Forum working groups can focus on their business subject matter - the requirements and workflow to satisfy business needs. The output of the working groups is then reviewed by a standing architecture committee, which ensures consistency and functionality before these enhancements are incorporated into the overall specification. The end result of this process provides comprehensive reusable messages and aggregates (complex structures) mutually agreed upon by financial institutions and software vendors alike.

As an example, the Interest Rate Information Aggregate, <IntRateInfo>, describes the necessary information to fully define interest rate information. The additions of usage constraints and descriptions provide for the semantic need and context that some XML vocabularies have not considered. <IntRateInfo> can now be reused in whatever messages need interest rate information, such as an Account Inquiry (see Table 1).

And the XML rendering of this structure may look like the following:

<IntRateInfo>
	<Rate>5.25</Rate>
	<Desc>Mortgage Rate: Pending Approval</Desc>
</IntRateInfo>

Note: In this example, only two elements are presented because that may be all that is necessary to satisfy the particular business requirement.

A Real-World Example
So what does this all mean exactly? Imagine a service, such as Funds Transfer, which is a common service banks provide. Customers may transfer funds from several different delivery channels, such as the branch teller, call center, Web banking, or even an ATM device. IFX Forum members working together capture the general requirements and the differences in requirements that one particular channel might have from another. All of these requirements are then defined as part of a common Funds Transfer service. Now a developer can provide a single code base for several different delivery channels. This is the embodiment of the goals of service-oriented architectures. This same solution can also be used to satisfy the need for a Web service.

Web Services: the Next Step
The latest technology driver to arrive is Web services. Web services promise application-to-application communication. Ensuring this functionality is one of the key drivers for the future of the IFX specification, and formal interoperable definitions will be provided with IFX 2.0. Web services support will further promote the communication between banks and service providers, such as bill pay providers and check ordering providers.

As an example, a bank customer may log onto his or her online banking Web site, which uses IFX, to place an order for new checks. The bank has partnered with a check printer that has exposed an IFX "Check Order" Web service. The customer places an order through the online bank. The request is submitted directly to the check printer. A successful response is then transmitted from the check printer back to the bank. The bank then conveys the successful response to the customer. All of this is transparent to the customer, but the real benefit is the integration and cost savings between the bank and check printer.

IFX and Interoperability
We have seen several examples of interoperability with IFX, from the ability to have a single code base work with multiple delivery channels to the upcoming support of Web services enabling better communication with banking partners. The IFX Forum also works to interoperate with other standards bodies. A testament to this is the IST (International Standardization Team) Harmonization team, a joint effort between the IFX Forum, SWIFT (Society for Worldwide Interbank Financial Telecommunication), TWIST (Treasury Workstation Integration Standards Team), and OAGi (Open Applications Group, Inc.) that recently completed a definition of a comprehensive payment kernel to enable straight-through processing (STP) and interoperability of payments between the different standards bodies. This common kernel will reduce manual processing points and further promote standardization across international banking lines.

Participation in the Development Process
As previously stated, the IFX Forum is a market-driven organization. Forum members bring forward business cases and requirements which in turn grow the specification. Members gain the added benefit of networking with other members, obtaining information in a timely manner, and receiving expert advice. The IFX Forum releases new versions of the specification up to twice a year. Members are well aware of the enhancements long before the official release, which allows them to incorporate the latest enhancements by the time the latest release is made publicly available. (For more information on the IFX Forum and membership, please visit www.ifxforum.org.)

Developing Your Own IFX-Based Solution
So what should you look for in developing an IFX-based solution? The answer truly depends on your business needs. IFX is not a specification that has to be fully implemented; you can pick and choose the messages necessary to support your business services. Thus, in a small-scale environment, such as a bill pay provider, you may only have to implement a handful of messages. There are many implementations of IFX like this, where a service provider or even a financial institution has implemented just a few messages to support a new service. This is an excellent solution for small services such as bill payments, check ordering, or even currency exchanges.

A more interesting example is that of a financial institution interested in leveraging IFX across the enterprise. Here is the opportunity for an institution to bind the benefits of IFX to an SOA. Because of its high reuse and object-oriented design goals, many portions of the specification can be coded once and reused as a service component for multiple services and/or channels. Structures for things like postal addresses, where the business rules are channel independent, can be defined once as a single module and used as "code off the shelf," plugging the module into the many different messages that use it in IFX.

When developing your IFX solution, you should be aware of some risks. Because IFX does not define requirements for infrastructure, implementations between business partners must agree on such things as transport and enveloping. Simply because an entity has an IFX implementation, that does not mean you can merely "plug in" and be up and running. In some cases, because of transport layer differences, adapters may be necessary to perform some minor translation.

Implementers of IFX should also be aware of the risks of deviating greatly from the specification. An "IFX-ish" implementation may not provide you with much return on investment when you are attempting to integrate with a business partner or service provider using IFX. By aligning yourself with IFX and working with the IFX Forum to evolve the specification where necessary, you can achieve interoperability benefits. A well-designed IFX implementation can help reduce integration timelines from months to weeks. And by shedding proprietary solutions, you can now more easily make changes in a heterogeneous environment.

Conclusion
IFX provides many design benefits for XML developers in the financial industry. By leveraging IFX for XML related projects, not only do developers gain a huge head start in comparison to defining their own messages, they also have the added benefit of industry agreement on functionality. The benefits of using IFX will continue to grow as financial institutions and software vendors continue to build and support IFX implementations, further reducing proprietary development efforts.