Home » IFX Standard » IFX Framework

IFX Framework

Background
Financial services providers and associated technology vendors evaluating the strength of any given XML-based communication standard need to take into consideration the underlying qualities that make that standard a technology worthy of investment.

The issue is not solely whether or not the given specification can handle a single set of transactions or whether it captures a unique piece of data, but also the manner in which these issues are handled. How easy is the standard to understand? How strong is the specification in its ability to meet current business needs while also leaving room for evolution? How are customizations handled while still maintaining the strict rules needed for universal compliance? How can new lines of business be integrated with the technology?

The Interactive Financial eXchange (IFX) specification is built with the recognition that no single financial transaction stands on its own, but rather is an integral part of an relationship among all of the communicating parties; a payment is not complete until a remittance is sent, an ATM withdrawal is not complete until a consumer's account has been debited, and so forth. Additionally, the nature of the conversation may need to be modified and grown to fit into changing environments.

[ Top ]

Foundation for Interoperability
About the Framework
At the foundation of the Interactive Financial eXchange (IFX) specification is its unique framework, which not only defines how all of the financial messages are communicated among parties, but also how they relate to each other. Built on best of breed design principles and developed by industry leaders representing years of experience in the financial services industry, the IFX Framework was built strong from the ground up.

The IFX Framework allows for customization and extensibility while adhering to strict implementation guidelines needed for large-scale interoperability. IFX is built with the recognition that not every single nuance of the financial conversation will be captured perfectly by the objects that have been defined. The rich set of IFX Business Objects provided can be used as a great starting point, however; the IFX Framework allows for easy standard-compliant customizations that will not create compatibility issues if implemented correctly.

The IFX Framework was not custom-built to fit into any one environment, but rather all environments. It was not built to suit only one type of application but rather to facilitate many kinds of financial conversations among many sources.

[ Top ]

Unifying Common Object Definition
In addition to the IFX Framework, 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, with a common definition for a "customer" that is used across both Payment and Bill Presentment services, multiple types of applications can leverage off of one standard to utilize that piece of data. A financial institution that wishes to offer multiple services that may be located in different business units can take advantage of the common object definition to unify the disparate systems.

[ Top ]

IFX Methodology for Adding and Extending
The IFX Framework has been designed so that whole new areas of financial conversation can be incorporated in a manner that is compatible with the ones that have been previously defined. The IFX Methodology is designed to facilitate rapid innovation in the evolution of the specification while still maintaining strict controls necessary for a universal standard.

The IFX Methodology is designed to leverage off of the Common Object Definition and the IFX Framework in order to rapidly translate real world business use cases into usable XML objects.

The first step is to take a look at the rich objects that already exist in IFX and decide whether any of them can be used either in their current state or modified for the purposes of the new functionality that is to be implemented.

Secondly, the additional functionality that is not already captured in the existing body of work is modeled against the architectural rules, making sure to take into account both data captured as well as processing rules. However, the amount of work that has been invested into the specification up to this point facilitates this step.

Third step is to define any new objects and associated methods that may be needed and how they will fit in with what is already there.

Finally, running real life use cases through the new, modified and existing objects serve to validate the new functionality.

[ Top ]