1 / 45

Introduction to IFX April 2010

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?.

redford
Télécharger la présentation

Introduction to IFX April 2010

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction to IFXApril 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 BusinessMessage Specification • IFX on the web: www.ifxforum.org

  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 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

  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. 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. Messaging Protocol • Architecture • Common Messages act on Objects • Common Messages act on Objects • All messages get meaningful acknowledgement MsgRq MsgRs Standard Request-Response Mod Aud Add Del Can Inq Adv Sync Status Common Object Definition Customer Payment Bill Account

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

  21. 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 • 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 • 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. • PartyKeys example 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 • 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. Object-Message Rq Object-Message Rq Object-Message Rs Financial Institution Service Partner Client Object-Message Rs Object-Message Status Object-Message Status Messages - General • Architecture • Common Message Protocol • Reliable Request-Response protocol • Common Response behavior [Status, Warning, Error]

  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. CredentialsRqHdr CredentialsRqHdr CredentialsRqHdr SubjectRole SubjectRole SubjectRole StartSession StartSession StartSession PartyRef PartyRef PartyRef SeqNum SeqNum SeqNum SecTokenLogin SecTokenCard abstract SecToken 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 or or …

  37. Messages – CredentialsRqHdr

  38. 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 • 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 • 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 • Rules define processing and error behavior • Concurrent vs Sequential • OnErrorbehavior • OnWarningbehavior • Transmitted in the OperRqHdr • OnError / OnWarning • Continue • Abort • ReverseProcessed • ReverseAll OperRules ProcessConcurrent OnWarning OnError

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

  45. The IFX Standard Repository BMS Database DEMO

More Related