1. Introduction to IFX April 2010
Organization and Governance
Framework and Architecture
The IFX Standard
The BMS Repository

2. IFX Organization and Governance
Who we are
Our mission
How we relate to other SDOs
How we operate

3. What does “IFX” mean? IFX means Interactive Financial eXchange
IFX Forum, Inc. is the formal name of the organization
The IFX Forum maintains the IFX Standard a Business Message Specification
IFX on the web:

4. Mission of the IFX Forum
The mission of the IFX Forum is to develop and promote adoption of an open, interoperable standard for electronic financial data exchange.
The IFX standard is designed to meet the business requirements of the global financial services industry in the areas it addresses.

5. History Formed in 1997 V1 released in 1998
Incremental content in annual point releases
V2 release candidate in 2008
V2.1 April 2010

6. IFX Organization IFX Board of Directors Manage Legal business
Appoint Steering Committee
IFX Steering Committee
Manage IFX business day-to-day
Steering approves WG charter
IFX Architecture Committee
Manage IFX Specification
Content approved by Architecture
3 members must sponsor WG
IFX Working Groups
Define specification content
IFX Working Groups
IFX Working Groups
No limit to # of WGs
IFX Working Groups
WGs are not permanent

7. IFX Liaison activities
We have Liaison status with ISO TC68 and SC7
We are guiding our ATM standard through ISO
IFX Forum actively engages with other standards setting organizations. We have formal agreements in place with:
X12F
ISTH
ISO TC68 (UNIFI-20022)
ISO TC68/SC7 (ATM)
BIAN

8. IFX and ISO (UNIFI)
IFX was a founding member of the IST Harmonization effort in 2003 which resulted in ISO (UNIFI) in 2004
Members from four leading industry standards organizations: IFX, TWIST, OAGi, SWIFT
The Objective:
Recommend a common core payment message/transaction that can be accepted into each of the XML standards bodies
The Result:
IFX incorporated the Payment Kernel in its 2004 release – version 1.6 8 8

9. How we operate Teleconferencing Our Members-only web site
Regular WG meetings
Monthly Steering Committee meetings
Approx annual releases
Virtual Management, Inc. handles our PR and general administration

10. The IFX Framework Business Message Specification
Framework and Architecture
Service Oriented Architecture

11. Business Message Specification
Everything is intended to satisfy real-world business requirements
Independent of specific technology
Independent of national boundaries
Independent of corporate practices
Consistent and durable over time
Resilient and adaptable to evolving business practices

12. The IFX Standard The IFX standard is:
A technology-neutral Business Message Specification
The product of dozens of man-years of expert analysis.
A powerful, scalable development framework
…practical and useful for many purposes
Between financial institutions as a communication specification
Within a financial institution as an internal messaging standard or part of its message hub
Defining outsourcing services and boundaries
As a development and testing specification

13. A Practical, Open Standard
Working Groups
Member-driven Working Groups
There must be at least 3 members sponsoring a Working Group.
Business and technology experts participate
The WG creates messages to accomplish useful business purposes and satisfy real world needs.
These messages are often implemented in production by IFX members immediately.
Historical and current working groups include:
Business Banking
ATM/POS
Branch Banking Services
Electronic Bill Presentment and Payment
Web Services

14. A Managed Standard Management Strict Design Principles
The IFX standard adheres to strict design principles needed for consistent, large-scale interoperability.
The Architecture Committee reviews ALL message proposals for technical consistency.
The BMS Database automatically generates basic segments and enforces constraints.
Strict Management Principles
The standard is completely documented for business and technology partners
Backwards compatibility is maintained
Peer reviews precede release

15. A Solid Framework Architecture Well-defined Framework
Stateless, multi-tiered computing model [Server-server-server...]
Clear description of expected behaviors
Complete support for security and privacy
IFX Message Framework
Standard Message Protocol
Request-Response-Status
Common Object Definitions
with well defined data semantics

16. Standard Message Protocol Common Object Definition
Easily extended
Architecture
High Leverage Re-usability
Work Groups extend functionality and data content to satisfy business needs
Easily customized within the framework
Basic Banking
Payment B2B/B2C
EBPP
ATM POS
ISO 20022
Branch Services
Future Services
IFX Message Framework
Standard Message Protocol
Common Object Definition

17. Service Oriented Architecture
IFX Forum spent 2 years and untold hours proving the architectural concepts, cross-platform tools and specific implementation techniques of SOA in its Web Services Working Group.
An additional 2 years of work was invested in refactoring the content for resilience and adherence to SOA.
This led to v2 of the standard which refines our service oriented approach to align more naturally with common technology and industry practices.

18. IFX Service Framework

19. Standard Request-Response Common Object Definition
Messaging Protocol
Architecture
Common Messages act on Objects
Common Messages act on Objects
All messages get meaningful acknowledgement
MsgRq MsgRs
Standard Request-Response
Add
Mod
Del
Can
Inq
Aud
Adv
Sync
Status
Common Object Definition
Customer
Payment
Bill
Account

20. Distributed Processing
Architecture
Common Message Protocol
Reliable Request-Response protocol
Common Response behavior [Status, Warning, Error]
Client
Financial Institution
Service Partner
Object-Message Rq
Object-Message Rq
Object-Message Rs
Object-Message Status
Object-Message Status
Object-Message Rs

21. Core Object Patterns Data Types Core Message Patterns
The IFX Standard
Core Object Patterns
Data Types
Core Message Patterns

22. IFX Object- The Basic Pattern
Key Concepts
All IFX Objects adhere to a basic pattern
Object Status can also be found in a named StatusRec
This pattern is enforced in the Standard Repository

23. Object- Info and Envr Key Concepts
All objects have Info
All objects have Envr
All xxxEnvr extend BaseEnvr
The “…Info” segment generally defines properties of the object that are directly maintainable by a client
The “…Envr” aggregate contains environmental data that is fixed by the server including computed properties.
BaseEnvr expresses most commonly used server-generated data. All other Envrs extend BaseEnvr

24. Objects - Referencing Key Concepts Rationale
xxxRef is a standard element in every object
Object IDs are consistent data types
Explicit support for business keys
Objects have IDs, Idents, Keys and Refs
Ident is an aggregate structure generally used to hold business keys
Object Keys and Refs resolve to a single object
Rationale
Support multiple ways to reference objects including business keys

25. Objects – Refs and Keys Key Concepts
Ref Aggregates have Keys, Records or Info segments
Keys have IDs or IDENTS qualified by the Service that assigned them
Objects can be referenced by an ID of Business key – both contained in xxxKeys
An Object reference can be the object itself – either as a serialized record or the data segment (xxxInfo)

26. Objects – Keys, Ident examples
PartyKeys example
The SvcIdent qualifies the ID or Ident. The id is unique within that environment
Any number of alternate Idents is allowed and they may be compound structures.
AcctIdent example

27. Object Relationships Key Concepts
The related instances of objects are indentified by objectRefs
Relationship objects are created with xxxyyyRelAddRq

28. Relationship Objects Key Concepts
Relationship Objects are true IFX objects
They explicitly identify 2 or more relationships
Attributes specifically describing the relationship are in the Info aggregate
Rel objects are manipulated like other IFX objects, responding to Mod, Del, etc. messages
Rel objects have data (info), status, etc.
Rel objects have references to the objects they relate

29. Data Type - Extensions Key Concepts
Extensions allow for reuse without resorting to duplication
Abstract Aggregates must be extended; they are replaced on the wire with the specific tags

30. Abstraction Example Key Concept
PartyInfo is an abstract aggregate that will manifest itself as either Org or Person Info
Similarly, PartyData will have either Org or Person Data
Key Concept
Abstract Aggregates must be extended with concrete definitions
Often it is not necessary to know whether a party is person or org - in a transaction, for example.
Therefore, whether Person or Org, they are reference with a PartyID

31. Messages - General Architecture Common Message Protocol
Reliable Request-Response protocol
Common Response behavior [Status, Warning, Error]
Client
Financial Institution
Service Partner
Object-Message Rq
Object-Message Rq
Object-Message Rs
Object-Message Status
Object-Message Status
Object-Message Rs

32. Messages - Methods Key Concepts
Messages always act on a particular object except Reversals act on messages (transactions)
The list of methods is unchanged from v1
Particular implementations of messages change to accommodate pattern normalization

33. Message Headers- Intro
Key Concepts
MsgRqHdr
CredentialsRqHdr
ContextRqHdr
FeeRqHdr
There are Rs equivalents
The message request header aggregate contains common information for request messages

34. Messages and Operations
Architecture
Message Routing and SOA
Message Headers contain Service Identification
Message Headers contain Credentials
Operations
‘Atomic’ messages can be combined to perform sequential actions in a single Rq-Rs operation

35. Messages – ContextRqHdr

36. Message Headers- Credentials
Key Concepts
CredentialsRqHdr
SubjectRole
Multiple extensions of abstract SecToken
SecTokenLogin
SecTokenCard …
The CredentialsRqHdr contains the credentials of the user / client.
Multiple credentials with different roles can be supplied
The abstract SecToken is replaced by a real Token
CredentialsRqHdr
SubjectRole
StartSession
PartyRef
SeqNum
abstract SecToken
CredentialsRqHdr
SubjectRole
StartSession
PartyRef
SeqNum
SecTokenLogin
CredentialsRqHdr
SubjectRole
StartSession
PartyRef
SeqNum
SecTokenCard or
or …

37. Messages – CredentialsRqHdr

38. Operations Key Concepts Rationale
Create new functionality by combining messages
Define simple rules governing processing and error handling
Rationale
Allows explicit creation of complex functionality using existing messages
Explicit operation definition
An Operation is an “aggregate” of messages

39. Data Type- IFXPath Key Concepts
IFXPath is a scope-limited definition of the W3C XPATH type
It describes the path to a data element
Used in Inquiry, Modify and ErrorPath
Less data on the wire conserves bandwidth and protects privacy
FieldSelect is used to select certain fields to be returned in response to inquiries or to update in a modify request.
RecSelect is used to select certain records that meet a criteria.
FieldSelect can result in full objects being returned (when Rec is the field specified)
Basic field identification:
/DebitRec/DebitInfo/DebitType
/DebitRec/DebitInfo/CompositeCurAmt
As Criteria:
/DebitRec/DebitInfo/CompositeCurAmt[CompositeCurAmtType=”Debit”]

40. Messages - Responses Key Concepts Rationale
Default behavior is to return a StatusRec
Client can request additional information
If server doesn’t support ‘Light Objects’ it must return entire record
Rationale
Conserve bandwidth
Protect privacy
Align with common technology practices

41. Message Headers- OperRqHdr
Key Concepts
OperRqHdr extends MsgRqHdr
OperRqHdr will always look like a MsgRqHdr + OperRules
Messages in an Operation do not require a MsgRqHdr.
If a MsgRqHdr is present, any content overrides the corresponding content in the <OperRqHdr>.

42. Operations - Definition
Key Concepts
Create new functionality by combining messages
Operations have name and namespace
Combine messages like building an aggregate
Required
Optional
Repeating …
A special Operation can be used to reverse the business functionality (if defined)
Operations are defined like aggregates, but contain only message names as elements
Naming convention: ends in …OperRq/Rs
Reversal Operation with same name - ends in OperRevRq/Rs
SampleOperRq
MessageARq (rpt)
MessageBRq (rqd)
MessageCRq (opt)

43. Operations – Rules Key Concepts OnError / OnWarning
Rules define processing and error behavior
Concurrent vs Sequential
OnError behavior
OnWarning behavior
Transmitted in the OperRqHdr
OnError / OnWarning
Continue
Abort
ReverseProcessed
ReverseAll
OperRules
ProcessConcurrent
OnWarning
OnError

44. What it is Capabilities How to navigate - demo
IFX BMS Database
What it is
Capabilities
How to navigate - demo

45. The IFX Standard Repository
BMS Database
DEMO