• IFX Standard Overview
• IFX Framework
• Introduction to IFX Presentations
• IFX Versions
• IFX Subscriptions
• IFX Discussion Board

The IFX Framework

Framework Overview    Service Oriented Architecture   Message Protocol   IFX Objects   Customizing and Extending   Backwards Compatibility

Framework Overview

The IFX framework exposes obvious design patterns, standard abbreviations and common message handling techniques that make it easy to work with in any business or technical setting.  New capabilities can easily be incorporated that are immediately compatible with those previously defined.

Built with the recognition that every business superimposes its own unique practices on any standard, the framework allows for customization and extensibility while adhering to strict design principles needed for large-scale interoperability.

The IFX standard has been built for platform and technology independence and cross-industry applicability based on rich set of common objects, a reliable request-response message protocol and a consistent service-oriented architecture.

The following concepts are key to understanding the IFX framework.

• Network-connected endpoints are not necessarily managed by a single entity.
• The Request-Response Message Protocol is strictly followed to ensure reliability in stateless environments common to internet communications.
• IFX Common Object definitions include reliable identification of individual objects and the service or service provider that "owns" them.
• Design patterns and naming conventions are consistently applied

Service Oriented Architecture

The participating entities in an IFX-enabled solution can be separate financial institutions, corporations, devices, customers or service providers of many varieties – all of which may or may not have pre-established relationships with each other, may or may not reside within the same corporate walls, and may not be located within the same country.  Nevertheless, transactions must be reliably directed to and from service end-points with proper authentication, predictable error-handling and auditable results.  The IFX standard supports all of this with its service oriented architecture.

Service Providers may be single companies offering many services or multiple companies partnering to provide a single service.  The granularity of a service is defined by the institutions offering them, not IFX Forum.  This facilitates service segmentation across business boundaries, technical boundaries or both with complete flexibility within the framework.

Request-Response Message Protocol

All data exchanges are handled with a reliable request-response protocol.  Predefined messages and message formats simplify initial understanding and later extensions.

 The messaging framework includes message header information that facilitates:

• Message routing in SOA environments
• Message routing to-from service provider partners
• "Blind routing"; i.e. route messages based on header without inspecting message details
• Multiple security and authentication credentials per message
• Combining messages to perform common operations in a single step

All response messages include status indicators to maximize reliability.

Common Object Definitions

The foundation of the IFX Specification includes a set of common objects that can be used across multiple types of financial services. This facilitates the implementation of cross-service applications.

For example, a common definition for a "customer" (party) is used in EBPP type services, as owners of accounts, parties to funds transfer transactions and a variety of other business applications.  A financial institution that wants to offer multiple services (such as banking and insurance) that may be located in different business units can readily take advantage of the common object definition to unify the disparate systems.

The following tables show all of the IFX Objects as of  v2.1*.  The tables are loosely organized by common service groupings.  Note, however, that any IFX object can be used in any context dictated by business need.

Accounts   Customer/Party   Banking   ATM POS    Card     Payment    Billing     General

*More complete descriptions of IFX Objects can be found at:  http://bms.ifxforum.org/

 Accounts

Party (Customer)

Banking

Card

Payment

 Billing

 ATM-POS

 General Usage

Customizing and Extending

A standard such as IFX cannot solve every business problem for every organization and remain useful.  It must be flexible enough to adapt to different business and regulatory environments while maintaining the integrity of the framework.  IFX has published details about how to extend the standard at any level from data elements to message handling and service definition including how clients and servers should respond to extensions that are not supported.

Since all tag names in the IFX Specification follow the same naming conventions, it is relatively easy for a Financial Institution or Service Provider to design customized data extensions.  Since all objects are defined with the same structural pattern it is easy to add new objects.  And all message names are constructed the same way so it is obvious how to manage new objects whether defined in the standard or as part of a custom extension.

Backwards Compatibility

IFX is committed to maintaining backwards compatibility so that implementations are reliable even as new capabilities are added.  The stated policy of IFX is that  all specification changes that impact IFX messages must be fully compatible with the previous point revision level of the specification. Specification changes must not require changes by an implementation in order to continue processing at the same level of functionality within a major release level. 

There are 2 types of compatibility that we are concerned with:

Syntactic compatibility: is the consistent representation of message and data structure, i.e., formats, tag names, and element definitions between old and new levels of the specification.

Semantic compatibility: is the consistent operation of message function, i.e., behavioral consistency between old and new levels of the specification.

There are currently 2 major revision levels supported by IFX commonly referred to as v1.x and v2.x.  Consistent with our policy, every point release in the v1.x family from 1.1.0 – 1.8.1 is compatible with lower version releases.  We are proud to have maintained that record for over 10 years.

Version 2.x is not directly compatible with version 1.x.  The version 2.x framework imposes new structural constraints on IFX Objects; more readily adapts to modern SOA environments and deprecates elements that had been identified as obsolete in version 1.  Version 2 is the "go-forward" architecture for the IFX standard.

IFX continues to support v1.x and, within limits, adds new data elements and functionality as required by members to maintain the viability of implementations based on that architecture.

More Information

The IFX Forum continues to develop new capabilities and provides implementation guidance to members in the form of published implementation guides, email dialog and archived proposal details.  These documents can be found in the members-only sections at www.ifxforum.org.

For general information about the IFX Standard please go to http://www.ifxforum.org/standards/.