IFX Standard Framework
The IFX standard uses a service-oriented architecture (SOA) framework for interactions between businesses and applications. The 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. Be sure to visit the Standard Content page to understand the wide variety of business capabilities supported in the Framework.
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 a 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 assumed not to be 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.
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. 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 significant 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.
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 a 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.
|Object & message model||
|Object model details||
|Object aggregation data||A deeper look at IFX Objects
|BMS Object Name||Keywords|
|Acct||Deposit Account, Loan Account, Certificate of Deposit, CD, Time Deposit, Credit Account, Rewards Account, Mortgage Account, Secured Loan Account, Unsecured Loan Account.|
|AcctAcctRel||Sweep, Interest Distribution, Overdraft, Notional Pooling.|
|AcctHold||Account Hold, Permanent Hold, Check Hold, Court Order Hold, Restriction, ACH Hold, Authorization Hold, Collateral Hold, Secured Account Hold.|
|AcctPayOff||Loan PayOff, Payoff Request, PayOff Estimate|
|AcctStmt||Account Statement, Financial Statement, Bank Statement, Interim Statement|
|AcctTrn||Transaction History, Transaction Search, Account Transaction|
|AcctTrnImg||Check Image, Deposit Slip Image|
|Alert||Notification, SMS Text,|
|Ath||Authorization, Transaction Authorization, Credit Authorization|
|Bill||Account Statement, Invoice, Notification, Billing Statement|
|Card||ATM Card, Debit Card, Credit Card, Prepaid Card, Pin Reset, Temporary PIN|
|CardAcctRel||Card Account Relationship, Credit Card Account, Card to Account Relationship|
|CardOrder||New Card Order, Pin Order|
|CardUpdate||Issuer Script Command, Prescript, Pre-Script|
|ChkAccept||Check Acceptance, Check Authorization, Check Verification, Funds Verification|
|ChkIssue||Check Issue, Positive Pay|
|ChkOrd||Check Order, Order Checks|
|CompRemitStmt||Comprehensible Remittance Statement, Lockbox|
|Credit||Credit Transaction, Deposit, Cash Deposit, Check Deposit, Merchandise Return, Check Payment, Envelope Deposit|
|CustPayee||Customer Payee, Add Biller, Add Bill|
|Debit||Debit Transaction, Withdrawal, Fee, Purchase, Purchase Cash Back, Credit Card Advance, ACH Verification|
|DepBkOrd||Deposit Book Order|
|Disc||Disclosure, Agreement, Terms And Conditions|
|Dispute||Dispute, Credit Card Dispute, Transaction Dispute|
|ForExDeal||Foreign Exchange Deal, FX|
|ForExQuote||Foreign Exchange Quote, FX|
|ForExRateSheet||Foreign Exchange Rate Sheet, Rate Inquiry, FX|
|ICCUpdate||Issuer Script Command, Prescript, Pre-Script|
|Inventory||Cards, Order Volume, Reorder Level, Seasonal Order, Stamps, Check Stock, Money Orders, Envelopes|
|MagCardUpdate||Issuer Script Command, Prescript, Pre-Script|
|MediaAcct||Media Account, Teller Drawer, ATM Container, Safe, Recycler, Cassette, Vault|
|MediaAcctTrn||Media Account Transaction, Buy, Sell, Dispense, Replenish, Set Balance|
|Note||Comments, Special Instructions, Remarks|
|Offer||Opportunity, Campaign, Products, Services|
|Party||Customer, Consumer, Prospect, User, Attorney, Ownership, Responsibility, Signatory, Organization, Retail, Trustee, Guarantor, Guardian, Executor, Administrator, Borrower, Co-Borrower|
|PartyAcctRel||Party Account Relationship, Owner, Individual, Joint Tenant, POD, Payable on Death, Power Of Attorney, POA, Trustee, Guarantor, Guardian, Executor, Administrator, Signatory, Borrower, Co-Borrower|
|PartyCardRel||Party Card Relationship, Primary, Secondary|
|PartyPartyRel||Party Party Relationship, Householding, Customer Grouping|
|PartySvcAcctRel||Party Service Account Relationship, Billpay, Account Link|
|PartySvcRel||Party Service Relationship, Service Link|
|PassbkItem||Passbook, Transaction, Printed Item|
|Pmt||Payment, Credit, ACH, SWIFT, CHAPS, CHIPS, Book Transfer, Debit Network, ePay, Federal Reserve Network, Remittance|
|PmtBatch||Payment Batch, ISO20022, PAIN, Direct Debit, Payment Cancellation, Payment Reversal, Credit Transfer|
|PmtBatchStat||Payment Batch Status, ISO20022 Payment Status Report|
|PmtEncl||Payment Enclosed Transaction, Envelope Deposit, Cash Deposit, Check Deposit|
|ProdIntRate||Product Interest Rate, APY, Rate Tier, Accrual Method, Compound, Prime, LIBOR, APR|
|PurchItem||Purchase Item, Prepaid|
|RecurChkOrd||Recurring Check Order, Recurring Model, Repeating, Instances, see ChkOrd|
|RecurPmt||Recurring Payment, Recurring Model, Repeating, Instances, see Pmt|
|RecurXfer||Recurring Transfer, Recurring Model, Repeating, Instances, see Xfer|
|Remit||Remittance, Payment, Bill, Invoice, Payable, see Pmt|
|SecObj||Security Object, PIN, Key, Encryption, Password, Certificate|
|StdPayee||Standard Payee, Biller, Creditor, Payable To|
|StopChk||Stop Check, Stop Payment|
|SvcProvider||Service Provider, Host, Application, Owner|
|TerminalObj||Terminal Object, ATM, POS, Device|
|TerminalSPObj||Terminal Service Provider Object, Host, Application, Owner|
|Trn||Transaction, Credit, Debit|
|Xfer||Transfer, Credit, Debit|
Request-Response Message Model
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.
All message responses include Status details, which can include not only success/failure indicators, but may also include the state of the data on the service provider’s system.
- Gain insight into the role of the Object-Message model
- Learn how messages can be routed to other service providers
- Understand how the Message Request Header supports authentication
Services, Service Providers
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 even 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.
In the IFX framework, it is easily conceivable that a Service Provider may be an application that collaborates with other applications and that those applications are built on different platforms with different technologies. The stateless Rq-Rs protocol and built-in recognition of Service Provider routing and data ownership are all critical to easy adaptation of the IFX model to any deployment model in any channel.