Introduction and Table of Contents

The diagrams on the following pages provide a general, big-picture viewof the IFX Business Message Specification (BMS) including object inter-relationships, data organization and otherkey concepts.

These diagrams should not be considered a canonical representation of the specification; only the published BMS can be relied upon as canonical.

In This Document(Incomplete sections)

Diagramming Legend

Account Object

Party Object

Relationship Objects

Object References

Transactions

Card-CardOrder-CardUpdate

ATMs

Bill Payment and Presentment

Payment

Remittance

Bill-Biller

Recurring Models

Service-Service Provider

Messages

Message Structure

Diagramming Legend

These diagrams are rendered with an informal diagrammingtechnique that is usefully aligned with the nature of the IFX Business Message specification.In keeping with the object-oriented principles upon which the IFX standard is based, the diagrams illustrate the data model as object containerswhich include data containers (Aggregates)and individual data elements. Informally, we refer to these as container diagrams.

Objects are shown as shaded boxes.

IFX Objects all adhere to the pattern shown at the right. The IFX Specification makes no assumptions about the actual physical storage techniques used to create/maintain the data represented by the objects. /
Every object in the IFX specification is constructed using this pattern. The remainder of this document will focus on the xxxInfo segment when describing the objects because that is the aggregate that contains the distinguishing attributes of each object.
This legend describes the typographical and annotation conventions.

/ Aggregates are collections of data elements.

They can be envisioned as containers. / Aggregates can contain a mix of simple elements and other aggregates.

/ Abstract Aggregates are special types of aggregate that facilitate reuse of data structures. They are replaced with non-abstract structures in messages.

Account Object

The Acct Object is of course a core component of the IFX standard. This diagram illustrates that there is a significant amount of data associated with an Account. When implemented, many of the data containers (aggregates) shown in this diagram may be stored in separate tables in a relational database or legacy file structures. In other cases, such as pricing data for example, the data may be accessible from various application interfaces.

Key Concept:
The IFX object model is not intended to dictate data storage techniques. Rather it is intended to capture all of the data typically associated with a business concept – in this case, Account.
With this understanding, it is possible to quickly ascertain which messages will result in the creation and maintenance of certain data. /

Party Object

Another core component of the IFX model is the Party Object. In earlier versions of the specification this was shown as Customer, but in version 2.x the concept was refined and now supports the ability to distinguish whether a customer/party is a business or individual without being burdened with that detail when it is not germane to the business activity.

The Party object is one of the most complex structures in the IFX specification. It makes extensive use of Abstract Aggregates (described on the next few pages) and is involved in many relationships as well (PartyAcctRel, PartyPartyRel, PartySvcRel, PartyCardRel).

The base attributes of the Party object are shown here as the abstract aggregate PartyInfo.
Key Concept:
Abstract Aggregates provide a mechanism to ensure that certain data patterns are enforced across similar objects without resorting to duplication of the data. This concept is most likely familiar to programmers using object oriented languages.
The PartyInfoabstract aggregate illustrates this concept in non-technical terms. The data shown here is pertinent to all parties, whether persons or organizations. At this level, “parties” can be referred to generically. /

OrgPartyInfo is a concrete realization of the PartyInfo aggregate when the party is an organization rather than an individual. OrgPartyInfo includes many attributes that are of interest when a “customer” is a company rather than an individual. Notice that this organization-specific aggregate includes all of the base PartyInfoplus data specific to Organizations.

Key Concept: Abstract Aggregates must be extended to be used. The extensions of abstract aggregates are often referred to as concrete aggregates and it is the concrete extensions that actually appear ‘on the wire’ in messages.
While Abstract Aggregates provide common structure for common elements, the Extension(s) add details particular to its purpose.
Abstract Aggregates are also used to provide a generic name for a concept that has different physical implmentations (e.g. Locator for phone number, postal address, email address) /

PersonPartyInfo is a concrete realization of the PartyInfo aggregate when the party is an individual (person).PersonPartyInfoincludes many attributes that are of interest when a “customer” is an individual or person, not a company or other organization. Notice that this person-specific aggregate includes all of the base PartyInfoplus data specific to Persons.

Key Concept:
Not only do Aggregate structures provide a named collection of related data in the IFX Specification;aggregates are often structured to maximize re-use.
That usage can be seen here in the Employment aggregate where we re-use the OrgData aggregate. (Employment data is often required for credit checks and loan accounts.)
OrgData, as used here, includes information about the organization where a person works without requiring that an object be created for every employer of every person-type party in your system. /
It is often desirable to include party information in contexts that do not require a full-fledged object reference or where storing such objects is impractical. That is how the OrgData aggregate, a concrete extension of PartyData , is used here to capture details about an employer.

Relationship Objects

The IFX model includes a number of objects that encapsulate the relationships between other objects and capture attributes unique to the relationship. This diagram shows all(7)of themas of v2.5. The directional lines indicate which objects are referenced.

The xxxRef aggregates are always constructed with a consistent pattern of data elements, shown below.

Careful examination of the xxxRef pattern reveals that the reference to other objects is not restricted to a key reference, although key references are typical.
It possible to pass the entire referenced object (xxxRec) or its relevant data attributes (xxxInfo) as the “reference” in a message to a client or server – especially useful when the recipient may not have access to the data store where the referenced object physically resides.
Finally, xxxRef aggregates are not restricted to use in relationship objects. Any object may reference another using this construct. (e.g. the references to the Disclosure object in this diagram.) /
The Info segments of relationship objects always contain references (xxxRef) to the specific related objects and consequently there are always two xxxRef aggregates within the xxxyyyRelInfo aggregate.
The generalized naming pattern for all relationship objects is XxxYyyRel where Xxx and Yyy are object names and “Rel” indicates the object carries information about the relationship between Xxx and Yyy. For example, PartyAcctRel is an object that captures attributes of the relationship between a Party and an Account. Notice that PartySvcAcctRel refers to Acct to another relationship (PartySvcRel) object.

Object References

Objects often refer to other objects. The IFX specification uses a particular pattern described on the previous page to name and facilitate such references.The following table shows all direct references to objects from other objects.(Note: the italicized names are pseudonyms for other objects.)

Object Referenced / Where Referenced / Object Referenced / Where Referenced / Object Referenced / Where Referenced
Acct / AcctAcctRelInfo / Bill / RemitDetail / ForExQuote / ForExDealInfo
Acct / AcctHoldInfo
Acct / AcctTrnInfo / CardOrder / CardInfo / Party / BillInfo
Acct / CardAcctRelInfo / Party / CredentialsRqHdr
Acct / CompRemitStmtInfo / Card / CardAcctRelInfo / Party / PartyAcctRelInfo
Acct / CreditInfo / Card / CardOrderInfo / Party / PartyCardRelInfo
Acct / DebitInfo / Card / CardUpdateInfo / Party / PartyPartyRelInfo
Acct / PartyAcctRelInfo / Card / PartyCardRelInfo / Party / PartySvcRelInfo
Acct / PartySvcAcctRelInfo / RelParty / PartyPartyRelInfo
Acct / PassbkInfo / Credit / DisputeInfo
Acct Pseudonyms / Credit / FeeRqHdr / PartySvcRel / PartySvcAcctRelInfo
CreditRtnAcct / RecurPmtInfo / Credit / FeeRsHdr
FromAcct / DfltPmtData / Pmt / RemitInfo
FromAcct / PmtInstruction / CustPayee / RemitInfo
FromAcct / XferInfo / Remit / PmtCreditDetail
IntDistAcct / IntDispData / Debit / DisputeInfo
RelAcct / AcctAcctRelInfo / Debit / FeeRqHdr / SecObj / SecEncryptKey
ToAcct / XferInfo / Debit / FeeRsHdr / SecObj / SecSignKey
ToAcct / XferPayee
SecuredAcct / AcctHoldInfo / Disc / BillerInfo / StdPayee / CustPayeeInfo
SubAcct / AcctStmtInfo / Disc / PartySvcAcctRelInfo
Disc / PartySvcRelInfo / Svc / PartySvcRelInfo
AcctTrn / AcctStmtInfo / Disc / SvcInfo / Svc / SvcProviderInfo
AcctTrn / AcctTrnImgInfo
AcctTrn / DisputeInfo / ForExDeal / XferInfo / Trn / MediaAcctTrnInfo
AcctTrn / DisputeItems / RelatedForExDeal / ForExQuoteInfo

Transactions

Financial services typically involve transactions and accounting entries. Here we will focus on these transaction types; Debit, Credit andXfer. Payments also typically result in transactions against an account but the payments topic is covered separately in this document.

There are several IFX Objects that represent or create transactions.
Key Concept: The AcctTrn object supports the inquiry of transaction data for all financial transactions of an account. As such, the AcctTrn object does not support methods such as Add, Mod, Del, etc. since transactions are added by other means such as DebitAdd, CreditAdd, etc.

Card-CardOrder-CardUpdate

Debit and Credit cards are fundamental to financial services of all kinds.

Notice
Key Concept:

ATMs

The IFX Specification includes a significant amount of material related to ATM.

Notice
Key Concept:

Bill Payment and Presentment

IFX was a pioneer in setting a message standard for Electronic Bill Presentment and Payment (EBPP). This diagram illustrates the object and data relationships associated with this capability.

Note:This diagram includes both objects (shadowed) and data aggregates.
In this diagram, green tinted boxes relate to Party concepts, Gray tinted boxes relate to Payment concepts, Blue tinted boxes relate to Bills and Orange tinted boxes relate to Remittance information
Payments may be created without Bills or Remittance information. /

IFX references to billers, payees, creditors, debtors, etc. can be readily mapped to ISO 20022 terminology as indicated here.

Ultimate DebtorData / DebtorData / CPPData / The IFX Specification does not make any assumptions about intermediaries. Any IFX payment message may be forwarded through any number of intermediary agents. / CreditorData,Payee, FSPayee, StdPayee, / Biller, Ultimate CreditorData

Payment

Although conceptually quite straight-forward, the data associated with payments can be quite complex including references to invoice details, creditor and debtor details and accounts involved in the payment transaction.

Key Concept:
In v2.x the terminology for creditors, debtors and agents was aligned with ISO 20022 /

Remittance

Although conceptually quite straight-forward, the data associated with payments and remittances can be quite complex.

Notice
This is just a placeholder. It needs to be tidied up.
Key Concept: /

Bill-Biller

The diagrams below illustrate the IFX objects for Bill and Biller.

Key Concept: Although it would be possible in the abstract to consider a Biller as a type of party, the Biller is represented in the IFX specification as an object in its own right.
Notice that both the Biller object and the Bill object reuse many of the Party data constructs. /

Recurring Models

Often transactions are scheduled to recur on a regular basis. IFX supports this with Recurring Models. In order to avoid ambiguity with the abbreviation for “record” (Rec) we use the abbreviation Recur to indicate recurring model information. IFX supports recurring models for Check Orders (ChkOrd), Payments (Pmt) and Transfers (Xfer).

Notice
Key Concept:

Service-Service Provider

The IFX standard is based on the fundamental business premise that Service Providers deliver Services to clients (parties).

Service Providers (SvcProvider) provide services (Svc) to various parties. Clients may be required to acknowledge or accept certain conditions as described in Disclosures (Disc).
This is just a placeholder. It needs to bereviewed.
Key Concept:
Messages are directed to a particular service of a service provider. This is identified as the SvcIdent which is present if every message in the MsgRqHdr. /

Messages

IFX Messages, aka methods, adhere to some specific patterns. Each method has a content template that is overlaid on the specific object which is the subject of the action. Most of the concepts are covered quite well in the Orientation deck available on the web site

Data Maintenance

The first few methods have strong parallels to the classic CRUD operations; Create, Read, Update, Delete. These are also readily mapped to RESTful concepts. (POST, GET, PUT and DELETE)

IFX / CRUD / REST / Description
Add / Create / POST / Create an object and assign it a unique ID
Inq / Read / GET / Find one or more objects and return requested attributes
Mod / Update / PUT / Modify/Update the attributes of an existing object.
Del / Delete / DELETE / Remove an object. Regardless of whether the object is logically deleted or physically deleted by the server the object is no longer accessible by an IFX message an cannot be re-activated. The affect is permanent as far as the client is concerned.
Deleting an object may or may not delete related objects based on business rules implemented by the server.

State Management

Two special methods facilitate efficient state management – StatusInq, StatusMod. The third message described here (Advise) can be used to notify a client of a state change that can be discovered with a follow-up StatusInq from the client.

StatusMod / All IFX objects have a status and many messages will modify the status of an object to reflect the effect a message had on the object (e.g. Canceled).
In other cases it is necessary to change the status of an object directly to reflect its current state. For example, processing a transaction whose status is "Pending" changes the object status to "Processed". Use StatusMod to change its status without affecting anything else about the object
StatusMod returns a StatusRec not an object.
StatusInq / The StatusInq request provides a mechanism to discover the current state of an object.
Adv / The xxx Advise message is used to notify interested parties that an xxx object was created or modified. The Advise Request message contains the object record information or object id
The Advise message set does not imply any action to take such as add, or update. It is up to the receiving entity to decide what action to take based on the contents of the Advise message.

Data Integrity

These messages facilitate tracing an audit trail of changes to an object and synchronizing 2 or more separate data stores.

Aud / The xxx Audit message supports the ability for the client to trace the message history for all changes impacting the specified xxx object.
Sync / The xxx Sync messages provide the ability for a client device to be brought up to date on changes made to the specified xxx object in a system of record (SOR).

Transaction Control

Financial transactions often require specific authorization prior to acceptance. It is also true that some transactions must be canceled or reversed.

AuthInq / The Authorization Inquiry message is used to request an inquiry of authorization information for the specified object.
AuthMod / The Authorization Modify message is used to change authorization information for the specified object.
Can / Cancel is usually used to stop pending or in-process actions related to an object such as a transaction.
Cancel does not delete a targeted object; it will usually change the status of the targeted object to "Canceled". (Typically a transaction should not be deleted as it invalidates audit trails, etc.) In this respect it resembles a StatusMod message.
The Cancel response message can send a full object back.
Rev / The xxx Reversal message is used to reverse the effect of a message. Reverse targets a previous message that targeted an object. Its effect is dependent on the message it is reversing rather than the object.
A client uses Reverse when it does not know the result of the message it is attempting to reverse. Only one message can be reversed.
If a Reverse arrives before the message being reversed, the message identified by RqUID should be dropped when it is encountered.

Message Structure

IFX messages all conform to specific patterns which include message request, message response and message header. Specific methods such as Add, Mod, Inq, etc. have structures particular to their purpose within the constraints of Rq-Rs protocol. Note, however, that every object implements methods the same way.

Notice / [Need diagram of Request-response skeleton]
Key Concept:
Message content is data.
Messages are represented in the IFX BMS repository as Aggregate structures. This facilitates reuse of key components such as MsgRqHdr and has the added benefit of supporting the “Message Where Used” links in the BMS UI. /