IFX Standard Framework

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.

Message Model

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 Model

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.

Another signficant advantage of the IFX Object Model is that it offers an easy to understand, common reference for mapping your data and your partners' data to the standard.

This diagram shows the basic container hierarchy of every object in the IFX Standard. The data attributes commonly associated with and object are found mostly in the xxxInfo segment and the current state of the object is found in the xxxStatus segment.

Here are some key concepts of the IFX Object Model:

• Every IFX object adheres to this exact same design pattern
• The names of the data elements in every object are constructed exactly the same way. You have only to substitute the name of the object for the xxx pattern in these lists to arrive at the exact tag name for specific group of data elements.
• This consistent application of rules and patterns makes it easy to extend the standard and makes it clear where your data extensions will reside

Common Object Definitions

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.

 

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.