Introduction to IFX
April 2010
Organization and Governance
Framework and Architecture
The IFX Standard
The BMS Repository
IFX Organization and
Governance
Who we are
Our mission
How we relate to other SDOs
How we operate
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: www.ifxforum.org
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.
History





Formed in 1997
V1 released in 1998
Incremental content in annual point releases
V2 release candidate in 2008
V2.1 April 2010
IFX Organization
IFX Board of
Directors
IFX Steering
Committee
IFX Architecture
Committee
• Manage Legal business
• Appoint Steering Committee
• Manage IFX business day-to-day
• Steering approves WG charter
• Manage IFX Specification
• Content approved by Architecture
IFX Working Groups
IFX Working Groups
IFX Working Groups
• 3 members must sponsor WG
• Define specification content
• No limit to # of WGs
• WGs are not permanent
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
IFX and ISO 20022 (UNIFI)

IFX was a founding member of the IST
Harmonization effort in 2003 which resulted in
ISO 20022 (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
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
The IFX Framework
Business Message Specification
Framework and Architecture
Service Oriented Architecture
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
 Resilient
and durable over time
and adaptable to evolving business practices
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
A Practical, Open Standard
Working
 Member-driven
Groups
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
A Managed Standard
 Strict
Design Principles
Management
 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
 The
Management Principles
standard is completely documented for business
and technology partners
 Backwards compatibility is maintained
 Peer reviews precede release
A Solid Framework
 Well-defined
Framework
Architecture
 Stateless,
multi-tiered computing model
[Server-server-server...]
 Clear description of expected behaviors
 Complete support for security and privacy
Standard Message Protocol
Request-Response-Status
Common Object Definitions
with well defined data semantics
IFX Message Framework
Easily extended
 High
Leverage Re-usability
Architecture
 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
Standard Message Protocol
Common Object Definition
IFX Message Framework
Future
Services
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.
IFX Service Framework
Messages can be routed to
SvcProvider at URL
ServiceProvider
<SvcProvider>
has
SvcProvider
Profile
<SvcProviderInfo>
Identified by
SvcProviderName
(globally unique
URL)
Offers 1 or more
SvcName
Account
Identified by
PrcSched
has
Draws from
Party
has
Service
<Svc>
Subscribes to
May be an Instance of
Interface
(Design)
Composed of
Composed of
accepts
has
Terms & Conditions
(Disclosures)
<Disc>
manifests
Optional
Behavior
<OptionProfile>
Composed of
Composed of
Operations
<OperSupt>
Composed of
Messages
<MsgSupt>
Manifests
OperRules
Messaging Protocol
Architecture
 Common
Messages act on Objects
 Common
 All
Messages act on Objects
messages get meaningful acknowledgement
MsgRq
MsgRs
Standard Request-Response
Add
Mod
Customer
Account
Del
Can
Inq
Aud
Adv
Sync
Status
Common Object Definition PaymentBill
Distributed Processing
Architecture
 Common
Message Protocol
 Reliable
Object-Message Rs
Object-Message Status
Object-Message Rq
Object-Message Rs
Object-Message Status
Service
Partner
Client
Object-Message Rq
Financial
Institution
Request-Response protocol
 Common Response behavior
[Status, Warning, Error]
The IFX Standard
Core Object Patterns
Data Types
Core Message Patterns
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
xxxRec
xxxID
+xxxInfo
+xxxEnvr
+xxxStatus
xxxInfo
dataAttributes
xxxStatus
xxxStatusCode
StatusDesc
EffDt
ApprovalId
StatusModBy
xxxEnvr
Extends BaseEnvr
CreatedDt
CreateRefIdent
ClientCreateDt
ClientBusinessDt
LastUpdateDt
LastUpdateRqUID
NetworkTrnData
PointOfServiceData
ThisObjectEnvrData
xxxStatusRec
xxxID
+xxxStatus
xxxStatus
xxxStatusCode
StatusDesc
EffDt
ApprovalId
StatusModBy
Object- Info and Envr
Key Concepts
• All objects have Info
• All objects have Envr
• All xxxEnvr extend
BaseEnvr
xxxRec
xxxID
+xxxInfo
+xxxEnvr
+xxxStatus
xxxInfo
dataAttributes
xxxStatus
xxxStatusCode
StatusDesc
EffDt
ApprovalId
StatusModBy
xxxEnvr
Extends BaseEnvr
CreatedDt
CreateRefIdent
ClientCreateDt
ClientBusinessDt
LastUpdateDt
LastUpdateRqUID
NetworkTrnData
PointOfServiceData
ThisObjectEnvrData
•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
Objects - Referencing
Key Concepts
• xxxRef is a standard element in every
object
• Object IDs are consistent data types
• Explicit support for business keys
Rationale
• Support multiple ways to
reference objects including
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
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)
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
Object Relationships
Key Concepts
• The related instances of
objects are indentified by
objectRefs
•Relationship objects are created with
xxxyyyRelAddRq
Relationship Objects
Key Concepts

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
• Relationship Objects are
true IFX objects
• They explicitly identify 2

or more relationships

• Attributes specifically
describing the
relationship are in the
PartySvcRelRec (was CustSvcRec)
Info aggregate
PartyRef
SvcRef
+PartySvcRelInfo
PartySvcRelInfo
+PartySvcDisclosureData
PartySvcDisclosureData
PartyID
DiscID
DiscInfo
+PartySvcDiscStatus
PartySvcDiscStatus
PartySvcDiscStatusCode
StatusDesc
EffDt
StatusModBy
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
Abstraction Example
Key Concept
• Abstract Aggregates must be
extended with concrete definitions
• PartyInfo is an abstract aggregate
that will manifest itself as either Org
or Person Info
• Similarly, PartyData will have either
Org or Person Data
• 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
Messages - General
Architecture
 Common
Message Protocol
 Reliable
Object-Message Rs
Object-Message Status
Object-Message Rq
Object-Message Rs
Object-Message Status
Service
Partner
Client
Object-Message Rq
Financial
Institution
Request-Response protocol
 Common Response behavior
[Status, Warning, Error]
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
Message Headers- Intro
Key Concepts
•
•
•
•
•
MsgRqHdr
CredentialsRqHdr
ContextRqHdr
FeeRqHdr
There are Rs equivalents

The message request header
aggregate contains common
information for request
messages
MsgRqHdr
AsyncRqUID
+CredentialsRqHdr
+ContextRqHdr
FeeRqHdr
CredentialsRqHdr
SubjectRole
StartSession
PartyRef
SeqNum
SecToken
ContextRqHdr
variousData
MsgAuthCode
miscAttributes
+Interface
SPName
Messages and Operations
 Message
Routing and SOA
Architecture
 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
Messages – ContextRqHdr
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
CredentialsRqHdr
SubjectRole
StartSession
PartyRef
SeqNum
abstract SecToken
SubjectRole
StartSession
PartyRef
SeqNum
SecTokenLogin
CredentialsRqHdr
or
or …
SubjectRole
StartSession
PartyRef
SeqNum
SecTokenCard
Messages – CredentialsRqHdr
Operations
Key Concepts
Rationale
• Create new functionality
by combining messages
• Define simple rules
governing processing and
error handling
•Allows explicit creation of
complex functionality using
existing messages
•Explicit operation definition
•An Operation is an
“aggregate” of messages
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
Basic field identification:
/DebitRec/DebitInfo/DebitType
/DebitRec/DebitInfo/CompositeCurAmt
•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)
As Criteria:
/DebitRec/DebitInfo/CompositeCurAmt[CompositeCurAmtType=”Debit”]
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
• Conserve bandwidth
• Protect privacy
• Align with common technology
practices
Message Headers- OperRqHdr
• OperRqHdr will always look like
a MsgRqHdr + OperRules
Key Concepts
• OperRqHdr extends MsgRqHdr
MsgRqHdr
AsyncRqUID
+CredentialsRqHdr
+ContextRqHdr
FeeRqHdr
OperRqHdr
extends MsgRqHdr
OperRules
CredentialsRqHdr
SubjectRole
StartSession
PartyRef
SeqNum
SecToken
OperRqHdr
AsyncRqUID
+CredentialsRqHdr
+ContextRqHdr
FeeRqHdr
OperRules
CredentialsRqHdr
SubjectRole
StartSession
PartyRef
SeqNum
SecToken
ContextRqHdr
variousData
MsgAuthCode
miscAttributes
+Interface
SPName
ContextRqHdr
variousData
MsgAuthCode
miscAttributes
+Interface
SPName
Messages in an Operation do
not require a MsgRqHdr.
If a MsgRqHdr is present, any
content overrides the
corresponding content in the
<OperRqHdr>.
Operations - Definition
Key Concepts
• Create new functionality
by combining messages
• Operations have name and
namespace
• Combine messages like
building an aggregate
•
•
•
•



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
Required
Optional
Repeating
…
• A special Operation can
be used to reverse the
business functionality (if
defined)
SampleOperRq
MessageARq (rpt)
MessageBRq (rqd)
MessageCRq (opt)
Operations – Rules
Key Concepts
• 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
IFX BMS Database
What it is
Capabilities
How to navigate - demo
The IFX Standard Repository
BMS Database
Produce
Specification
v1.8
IFX v2.0
Specification
IFX
Data
Specification
Data
Submit
request
Produce XML
implementation
Submit
request
Web
Interface
Choo
p a r a m se
eters
Receive documents
Request processor