Home » IFX Standard » Download the Standard » IFX Standard Version 1.1.0 - Release Highlights

IFX Standard Version 1.1.0 - Release Highlights

IFX 1.1.0 incorporates and builds upon IFX 1.0.2, which is a recent maintenance update to the earlier IFX 1.0.1 release. The IFX 1.1.0 Document Type Definition (DTD) that accompanies the specification is also available for review.

The major highlights of IFX 1.1.0 are:

The addition of "Asynchronous Processing" support to allow a server that is unable to complete a response in a reasonable time to complete it at a later time.
The addition of debit and credit messages that authorize, commit and reverse debits and credits for use in self-service, point-of-sale, and other applications that involve debiting or crediting an account.
The enhancement of "Deposit Account Statement Inquiry" message to support balance and transaction reporting as required in a corporate environment.
The enhancement of the "Single Payment Add" message to support business-to-business payment transactions.

A more comprehensive description of the functionality added by IFX 1.1.0 is outlined below. The purpose of this description is to provide the reader a high-level overview of the key additions. It does not identify every construct or text change made to the IFX 1.1.0 Specification. Implementers must refer to the Specification (and/or DTD) for the details of all changes introduced by IFX 1.1.0. Also, the specification identifies which constructs are planned for deprecation in the next version-change release of IFX (i.e., IFX 2.0).

Structure
- Incorporated "Asynchronous Processing" to support the case when the server cannot generate a complete response in a reasonable time. This processing is controlled via the addition of an Asynchronous Request Identifier <ASYNCRQUID>) to every message and the addition of the Asynchronous Response Information aggregate (<ASYNCRSINFO>) to the Response Status aggregate (<STATUS>). Additional text was added in Section 3.2.11.1 ( <STATUS> section) that further describes "Asynchronous Processing".
Common Elements and Aggregates
- Added new contact information aggregates to provide a composite structure to better represent contact information for a customer that can be either a person or an organization. The new aggregates are: <COMPCONTACTINFO>, <CONTACTINFO>, <PERSONINFO>, <PERSONNAME>, <ORGREC>, <ORGID> and <ORGINFO>. These aggregates functionally replace <CUSTNAME>, <CUSTCONTACT>, <CUSTNAMEADDR> and <ORGCONTACT> aggregates that will be deprecated in IFX 2.0.
- Enhanced the Bank Information and Account aggregates to provide additional information on banks and accounts for better identification and processing c ontrols. New aggregates added here are <REFINFO>, <BANKACCTFEATSUPT> and <INTERMEDIARYDEPACCT>.
- Enhanced the Settlement Information aggregate with the addition of the Payment Instruction aggregate (<PMTINSTRUCTION>) to provide more detail information regarding the payment system, format, fee charges, etc. used in the settlement process.
- Added the Composite Currency Amount aggregate (<COMPCURAMT>) to provide more information about the type of currency amount (e.g. debit, credit, late fee, etc.) and special handling required.
- Added the Network Transaction Information aggregate (<NETWORKTRNINFO>) to provide information about the network processing the transaction. This aggregate replaces <ATMTRNINFO> and <USA.ACHTRNINFO> aggregates, both which will be deprecated in IFX 2.0.
Security
- In the Signon request, added the option for the client to request suppression of echoed fields in the responses (<SUPPRESSECHO>). Whether or not the server supports echo suppression is indicated by options supported in the service profile.
- In the Signon request, added the optional aggregate <SIGNONOVERRIDE> to allow a teller or supervisor to signon to a user’s session to override functions, e.g., override a transaction fee, that could not normally be performed by the signed on user.
The Base Service
- Modified the text in Section 5.4.1.2 to clarify the intended use of Disclosure in the context of the electronic service (e.g., Internet Banking, Bill Payment, Bill Presentment). The text now distinguishes this from terms and conditions or regulatory disclosures for a Financial Institution’s or for a Biller’s product or service for which a customer is being billed. Also, added text to recommend that a new disclosure identifier <DISCID> be assigned any time that a disclosure is modified and it is important to the SP to maintain versioning of disclosures and acceptances.
- Added the Service/Account Identifier Link Modify messages (<SVCACCTIDMODRQ Rs>) that allow a customer or CSP to change the identifier associated with a particular Service Account Link. For example, in the Pay Service, the <SVCACCTIDMODRQ> would change all pending payments against a particular funding account to be applied against a new funding account.
The Banking Service
- Added 28 new messages (and 8 associated common banking service aggregates) to support debit and credit transactions and the means to authorize, commit and reverse these transactions. The debit messages are used to support transactions that incur a debit to an account, such as cash withdrawals, stamp dispensing and point-of-sale purchases. Similarly, credit messages are used to support transactions that incur a credit to an account, such as cash deposits, check deposits and point-of-sale returns.
  The specific message pairs added are:
  - Debit Authorization Add - <DEBITAUTHADDRQ/Rs>
  - Debit Authorization Modify - <DEBITAUTHMODRQ/Rs>
  - Debit Authorization Cancel - <DEBITAUTHCANRQ/Rs>
  - Debit Authorization Inquiry - <DEBITAUTHINQRQ/Rs>
  - Debit Authorization Audit - <DEBITAUTHAUDRQ/Rs>
  - Debit Authorization Synchronization - <DEBITAUTHSYNCRQ/Rs>
  - Debit Add - <DEBITADDRQ/Rs>
  - Credit Authorization Add - <CREDITAUTHADDRQ/Rs>
  - Credit Authorization Modify - <CREDITAUTHMODRQ/Rs>
  - Credit Authorization Cancel - <CREDITAUTHCANRQ/Rs>
  - Credit Authorization Inquiry - <CREDITAUTHINQRQ/Rs>
  - Credit Authorization Audit - <CREDITAUTHAUDRQ/Rs>
  - Credit Authorization Synchronization - <CREDITAUTHSYNCRQ/Rs>
  - Credit Add - <CREDITADDRQ/Rs>
  The associated banking service common aggregates added are:
  - Debit Authorization Record - <DEBITAUTHREC>
  - Debit Authorization Information - <DEBITAUTHINFO>
  - Debit Authorization Status - <DEBITAUTHSTATUS>
  - Debit Information - <DEBITINFO>
  - Credit Authorization Record - <CREDITAUTHREC>
  - Credit Authorization Information - <CREDITAUTHINFO>
  - Credit Authorization Status - <CREDITAUTHSTATUS>
  - Credit Information - <CREDITINFO>
- Enhanced the Deposit Account Statement Inquiry Response (<DEPACCTSTMTINQRS>) to encompass the essential information needed to support balance and transaction reporting as required in a corporate environment. The message supports both previous day and current day reporting as currently provided by financial institutions. Following are the modifications made to the applicable aggregates that enable the enhanced reporting:
  - <DEPACCTID> aggregate, <DEPACCTSTMTID> and <EFFDT> elements added to <DEPACCTSTMTREC> aggregate – (Note: Including the <DEPACCTID> aggregate allows for the reporting of a child account within a hierarchical account relationship.)
  - <ACCTCUR> element added to <DEPACCTID> aggregate
  - <BANKIDTYPE> element, <REFINFO> aggregate, and <COUNTRY> element added to <BANKINFO> aggregate
  - <COUNT> element added to <STMTSUMMAMT> aggregate
  - <COMPCURAMT> and <NETWORKTRNINFO> aggregates added to <DEPACCTTRNREC> aggregate – (Note: The <COMPCURAMT> aggregate facilitates the reporting of various float indices within both the deposit and transaction records. Including <NETWORKTRNINFO> aggregate permits reporting pertinent information regarding the network where the transaction was originated or settled. This allows for additional networks other than ATM’s and ACH as supported in <ATMTRNINFO> and <USA.ACHTRNINFO> aggregates respectively.)
  - <EFFDT> and <REMITADVICEREFID> elements, and < COMPCURAMT>, <COUNTERPARTYINFO> and <INVOICEINFO> aggregates added to <BANKACCTTRNREC> aggregate – (Note: Including <COUNTERPARTYINFO> provides information regarding the remitting party and the associated account information for a transaction record.)
The Pay Service
- Added an optional expiration date tag, <EXPDT>, to the < PMTAUTHSTATUS> aggregate which is part of <PMTAUTHREC> which is returned by the Financial Institution as part of the PmtAuthAddRs, PmtAuthModRs, PmtAuthInqRs, PmtAuthAudRs and PmtAuthSyncRs. It is up to the Financial Institution to determine if it wishes to make use of this tag and enforce the expiration date when the actual payment is processed.
- Enhanced the Single Payment Message to support business-to-business payment transactions. This includes global payments, payments with parent and subsidiary payer relationships, payments that can be split among multiple payees and split across multiple invoices per payee. It also incorporates the flexibility to support the four-party concept of Invoice Receiver, Payer, Payee, and Invoice Sender. It provides payment flexibility to support "on-behalf" scenarios where:
  1) the parent organization (Payer) consolidates all payments of its subsidiaries (Invoice Receivers) and makes payments on their behalf, and
  2) the parent organization (Payee) receives payments on-behalf of its subsidiaries (Invoice Senders) and distributes remittances. Three business-to-business payment cases are:
  - Single Payer, single Payee, single remittance
    Example: One debit to pay one Vendor who receives payment for invoices that the Vendor has presented to the payer
  - Single Payer, single Payee, multiple remittances
    Example: One debit to pay one A/P Vendor who receives payment on behalf of subsidiary 1, subsidiary 2, …subsidiary n.
  - Single Payer, multiple Payees, multiple remittances
    Example: One debit for payroll processor to pay multiple employees
- Added message called Recurring Payment Instance Add (<RECPMTINSTADDRQ/Rs>). The Recurring Payment Instance Add message allows a client to manually trigger the spawning of a payment instance from a Recurring Payment Model that has its frequency value defined as "Manually". This message is particularly useful when payments to a specific payee need to occur on an irregular frequency basis or when a client desires direct control of the spawning to manually override certain elements of each payment instance.
The Bill Presentment Service
- Added an optional tag <DISCID> to the <BILLERINFO> aggregate (section 8.3.1.2). This could be returned along with the existing <DISCDT> of the disclosure in a <BILLERINQ> message. If the SP determined that the <DISCDT> was more current than their stored disclosure, they could do a <DISQINQRQ>, using the <DISCID> as selection criteria.
- Added a new defined value of "RegulatoryMessage" to the tag <VIEWDETAILPREF> in <BILLINFO> to allow a biller to indicate that the detail of the bill contains regulatory information. This allows the CSP to provide the customer with this additional information in the display of summary bill information. A value of "PresRegulatoryMessage" was also added to the Options Supported <OPTSUPT> defined values in conjunction with this change.