IFX Version 2.0

1
IFX Version 2.0

• Building upon the
• Service Oriented foundation of IFX v1

2
Announcing v2.0a!

• Version 2 continues our commitment...
• To a business-first approach
• a Business Message Specification, driven by
  business use-cases
• independent of specific technologies
• To a service oriented approach
• from business services to SOA ,
• from stateless to REST
• Of cooperation with other standards setting
  organizations
• v.2 addresses shortcomings of v1 that can only be
  addressed by breaking backwards compatibility
• A decade of evolution
• A decade of learning
• A decade of implementation experience

IFX Forum will continue to support v1.x.
3
Public Comment period

• v2.0a is available now for public comment
• Because IFX is committed to a long-term policy of
  backward compatibility in a major release, we
  reserve the privilege to correct errors
  discovered during this comment period.
• We will formally conclude the public comment
  period within 3 6 months.
• Go to www.ifxforum.org and pull down the IFX
  Standard menu

4
Introducing...

• Specification Repository
• What it is
• How it can be accessed
• Its value to IFX members
• Its value to non-members subscription access
• Specification Details
• Key Concepts, Rationale, Comparisons
• Objects, Messages, Services - generally
• Customer, Party, Account specifically
• Interfaces, Operations - conceptually
• Object oriented documentation
• Object-centric approach
• Abstract Aggregates
• Aggregate Extensions

5
IFX BMS Repository

• Key Concepts
• IFX is a documented standard, not a document
• Generates consistent content
• Enforces data integrity

• Rationale
• Improve navigation
• Improve integrity
• Generate schema and documentation.

• Tomorrow
• Demo of db UI
• Demo of Schema generation

v1.x
v2.x

• A 900 page MS-Word document

• A fully interactive database repository
• Generate HTML hyper-linked specification
• Generate XML schema
• Support various queries

6
The IFX Standard Repository
The original concept
7
Objects - Structure

• Key Concepts
• Consistent structure
• Distinguish manageable attributes from read-only

• Rationale
• IFX Objects have a state and set of data
  attributes that can be maintained without sending
  the entire object over the wire

• Tomorrow
• The specifics of the IFX Object pattern

v1.x
v2.x

• Conceptually consistent, but not structurally
  consistent
• Modifications are whole record replacements
• IFX defined inquiry capabilities

• Structurally consistent
• Modify only those attributes necessary
• More robust inquiry
• Privacy protection

8
Objects Lighten Up!

• Rationale
• Support a mechanism to refer to one or more
  fields or aggregates in a message or object
• Add flexibility to Selection criteria in
  Inquiries
• Enrich information about error conditions
• Protect data privacy

• Key Concepts
• Lightweight inquiry
• Lightweight maintenance
• IFXPath is a scope-limited definition of the W3C
  XPATH type

v1.x

• Tomorrow
• IFXPath examples
• In Mod, Inq and Responses

• Full record replacement
• IFX defines which fields are available for
  selection
• Full records returned from AddRq, ModRq, InqRq

v2.x

• Client can specify which data is returned from
  server

9
Objects - Referencing

• Key Concepts
• objRef is a standard element
• Object IDs are consistent data types

• Rationale
• Support multiple ways to reference objects
  including business keys

• Tomorrow
• More about Ident
• Much more about Ref

v1.x
v2.x

• Only way to reference to an object is by its ID
• Some IDs are aggregate structures

• Objects have IDs, Idents and Refs
• Ident is an aggregate structure generally used to
  hold business keys
• Object Refs resolve to a single object

10
Messages - General

• Key Concepts
• Service Wrappers are gone
• MsgHeaders contain transport specific
  instructions
• MsgHeaders contain read-only data

• Rationale
• The Service Wrapper concept inhibits
  modularization
• Internet transports have evolved significantly

• Tomorrow
• Much more about headers
• Credentials

v1.x
v2.x

• Messages are constrained to services, represented
  on the wire by Service Wrappers

• Continued support of the concept of Interfaces,
  but defined by implementers.

11
Messages FieldSelect

• Key Concepts
• Modify only desired attributes
• Inquire with complete flexibility
• Responses can be tailored

• Rationale
• Conserve bandwidth
• Protect privacy
• Align with common technology practices

• Tomorrow
• IFXPath

v1.x
v2.x

• Full record inquiry
• Full record replacement

• Client can specify which data is returned from
  server
• Modify only those attributes necessary
• More robust inquiry
• Privacy protection

12
Messages - Responses

• Key Concepts
• Default behavior is to return a StatusRec
• Client can request additional information
• If server doesnt support Light Objects it must
  return entire record

• Rationale
• Conserve bandwidth
• Protect privacy
• Align with common technology practices

• Tomorrow
• Detail 1
• Detail 2

v1.x
v2.x

• Full record inquiry
• Full record replacement
• Full record response

• If server doesnt support Light Objects it must
  return entire record

13
Service Profiles

• Key Concepts
• Services are no longer defined by IFX
• Service wrappers dropped

• Rationale
• Businesses must have flexibility to define
  service boundaries
• Continue to support blind-routing of messages
  to SPs

• Tomorrow
• Service Profile details
• Activating Services
• Describing Interfaces

v1.x
v2.x

• Service Profiles describe messages supported
• Service Profiles are virtual object

• Service Profiles describe services and interfaces
• Service Profiles are true IFX objects

14
Customer
Party

• Key Concepts
• Party replaces Customer
• Party can be a person or an organization
• Partys have a relationship to accounts at the FI

• Rationale
• CustID was too many things to too many aggregates
• Reuse the common party info whether Organization
  or Person

• Tomorrow
• Authentication
• IssuedIdent
• PartyRef

v1.x
v2.x

• Customer is an object
• Customer signs on
• One authentication per session

• Party is the object
• Transactor authenticates
• Multiple authentications supported
• OBO easier to support

15
Accounts

• Key Concepts
• Significantly re-factored in v2
• AcctRef replaces xTypeAcctId in 75 other
  elements
• Added new objects AcctStmt, AcctTrnImg, AcctTrn

• Rationale
• Simplify referencing accounts in transactions
  Ignore details not needed to conclude
  transactions
• Simplify spec maintenance
• Address naming inconsistencies

• Tomorrow
• Refactoring details
• PartyAcctRel

v1.x
v2.x

• Various Acct Types are XORd in transactions
• Each new Transaction requires duplicate
  maintenance
• Adding new Acct types is significant effort

• AcctRef greatly simplifies things
• Party-Acct association supports role-based
  authorizations

16
Relationship Objects

• Key Concepts
• Maintainable objects store references to related
  objects (such as Party-Acct)
• Leverages objectRef concept

• Rationale
• Be explicit about the details of related objects
• Support multiple relationships between objects

• Tomorrow
• Party-Acct details
• ERD illustrations

v1.x
v2.x

• Sometimes supported by repeating elements
• Sometimes related objects are embedded

• Explicitly create Rel objects (such as
  PartyAcctRel, PartySvcRel, SvcAcctRel)
• Rel objects have Info that contain information
  about the relationship (such as Role)

17
Foreign Exchange

• Key Concepts
• Completed redesign - existing messages replaced
  and new messages added
• Enhanced functionality supports more business
  processes and use cases

• Rationale
• Support common business practices such as
  offering a rate and accepting a deal
• Solved limitations and inconsistency issues in
  existing messages

• Tomorrow
• A bit more

v1.x
v2.x

• Includes robust objects for Rate Quotes, Deals
  (Contracts) and Rate Sheets
• Supports cross-currency, two-way pricing models,
  FX swaps, FX offsets, one-step deal process

• Minimal messaging support
• Does not include explicit Cancel for Quotes, or
  Rate Sheets
• No support for cross-currency
• Limited options for Deal types and
  characteristics

18
Card Object

• Key Concepts
• Standard IFX Object
• Will have Party-Card and Card-Acct relationship
  objects

• Rationale
• Formalize Management and Servicing of cards
• Support association of cards with persons and
  accounts

• Tomorrow
• All working groups joint meeting with focus on
  Card

v1.x
v2.x

• Minimal messaging support

• New Working Group will focus on this object and
  its interactions throughout the BMS

19
Operations

• Key Concepts
• Create new functionality by combining messages
• Define simple rules governing processing and
  error handling

• Rationale
• Allows explicit creation of complex functionality
  using existing messages

• Tomorrow
• Operation Definition
• Operation Rules

v1.x
v2.x

• Documented Business Rules govern processing rules
  for related messages
• Example ATM Implementation Guide
• No message support

• Explicit operation definition
• An Operation is an aggregate of messages

20
Interfaces

• Key Concepts
• An Interface forms a contract between service
  provider and IFX client
• Packages messages and operations

• Rationale
• Flexible replacement for fixed service wrappers
• Allows modularized schema generation

• Tomorrow
• How are Interfaces defined

v1.x
v2.x

• Fixed Service wrappers defined by IFX
• Defines groups of functionality
• IFX schema must be hand crafted to simplify and
  make it usable

• Interfaces can be defined for business areas by
  the forum or by service providers

21
Summarizing

• Key Concepts
• BMS Repository
• Generate XML Schema
• Available to members and subscribers
• Object formalization
• Structure
• Referencing
• Abstraction and Extension
• Capturing object relationships
• Data types

• Messages
• Drop Service Wrappers
• Changes to Authentication
• Light Objects Field Select
• Operations
• Define your own Interfaces

• Specific Objects
• Party Replaces Customer
• Account
• Service Profile
• Foreign Exchange
• Card

IFX v2.0a is available now for public review.
IFX Forum will continue to support v1.x.
22
Questions?
23
Details

• Holding place for extra details about various v2
  concepts

24
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

25
Object- Info and Envr

• Key Concepts
• All objects have Info
• All objects have Envr
• All xxxEnvr extend BaseEnvr

• The Info aggregate generally defines the
  modifiable properties of the defined object
• The Envr aggregate defines properties of the
  object environment including computed properties.
  
• BaseEnvr expresses most commonly used
  server-generated data. All other Envrs extend
  BaseEnvr

26
Object- Data Types, etc

• Key Concepts
• There are a few new data constructions
• Abstract Aggregates
• IFXPath is a scope-limited definition of the W3C
  XPATH type

• Abstract Aggregate
• Timeframe
• Measurement
• External standard references (Codes)
• IFXPath (next page)

27
Object- IFXPath

• Key Concepts
• IFXPath is a scope-limited definition of the W3C
  XPATH type
• Used in Inquiry, Modify and ErrorPath

IFXPath limitations

• Primary purpose of a path field is to refer to
  one or more fields or aggregates in a message or
  object
• Fully qualified
• Locations must always be fully qualified
  (specified from the xxxRec).
• Comparative predicates will be limited to , ?,
  lt, gt, lt, gt.
• In ErrorPath
• Location is fully qualified relative to the
  original Rq.
• Positional predicates are supported to indicate
  which of the multiple occurrences are in question.

28
Services - SvcProfile
v1.x
v2.x

• Services are defined by IFX
• SvcProfile is virtual object
• Service Wrappers are a message construct
• Customers sign-on and deliver messages

• Services are defined by you
• Service Profiles are true objects
• Service Wrappers are gone
• Users authenticate and customers are a party in
  messages or transactions

29
v1.x Service-Account Linkage
30
v2. Party-Account-Service
31
v2. Relationships
32
v2. Relationships

• Relationship objects are created with
  xxxyyyRelAddRq

v2.x

• 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
• Activating a service for a particular customer is
  accomplished via PartySvcRelAddRq which creates
  the necessary PartySvcRelRec.

33
v2. Party
34
PARTY USES SEVERAL NEW V2 CONCEPTS

• PartyInfo is an abstract aggregate that will
  manifest itself as either Organization or Person
  Info

35
v2. Party

• PartyData is an abstract aggregate that will
  manifest itself as either Organization or Person
  Data

36
v2. Party-Account-Service
37
v1.x v2.x Transition, part 1
Customer will be replaced with Party
Service Profiles become true IFX objects

• Service Profiles are objects
• Services are defined by implementer

38
RELATIONSHIP OBJECTS EXAMPLE

• Key Concepts
• The related instances of objects are indentified
  by objectRefs

• Relationship objects are created with
  xxxyyyRelAddRq

39
Relationship Objects

• 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

• 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

40
Abstractions

• Key Concept
• IFX defines some aggregates as Abstract

• PartyInfo is an abstract aggregate that will
  manifest itself as either Organization or Person
  Info

41
Abstractions

• Key Concept
• Extending aggregates is key to consistent
  structures and re-use

• PartyData is an abstract aggregate that will
  manifest itself as Org/Person Data

42
Message Headers- Intro

• The message request header aggregate contains
  common information for request messages

• Key Concepts
• MsgRqHdr
• CredentialsRqHdr
• ContextRqHdr
• FeeRqHdr
• There are Rs equivalents

43
MESSAGE HEADERS- CREDENTIALS

• 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
  

• Key Concepts
• CredentialsRqHdr
• SubjectRole
• Multiple extensions of abstract SecToken
• SecTokenLogin
• SecTokenCard

or
or
44
Message Headers- Fees

• Use DebitRef to specify the fee
• Complete Info aggregate or
• Reference existing Info aggregate in message
• Use AcctRef to specify account to which fees
  should be charged
• CreditRef can be used for rebates

• Key Concepts
• Fees can be specified for an operation or a
  message in the header
• Uses DebitRef or AcctRef

FeeRqHdr
DebitRef CreditRef AcctRef ChargeRegulation
45
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
ltOperRqHdrgt.
46
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

47
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)
48
Operations Rules

• OnError / OnWarning
• Continue
• Abort
• ReverseProcessed
• ReverseAll

• Key Concepts
• Rules define processing and error behavior
• Concurrent vs Sequential
• OnError behavior
• OnWarning behavior
• Transmitted in the OperRqHdr

OperRules
ProcessConcurrent OnWarning OnError
49
Interfaces - Definition

• Key Concepts
• Not an IFX object
• Does not appear on the wire
• Definition can be as a schema or wsdl
• Must contain
• Namespace, Name, Version
• All messages and operations supported by the
  interface

50
Messages Selection

• Using the industry standard XPATH construct
  allows implementers more flexibility in data
  retrieval.

• Key Concepts
• Selection uses the new IFXPath data type