1. June 1, 2009

2. Current Status Technical Details Current Releases Issues Potential Use Cases Position Reporting Portfolio Reconciliation Cash Flow Matching Others? Next Steps Business Justification Implementations

3. FpML maintains a single master schema Master schema contains annotations with view-specific details, make this optional in view X put this only in view Y FpML publishes separate view- specific schemas, one per view Each view is generated from the master prior to publication Each view has documentation and examples Each view-specific schema will have its own namespace, e.g., http://www.fpml.org/FpML- 5/pretrade End users will use a view- specific schema, not the master

4. FpML 5.0 Working Draft 2 published 3 views Pretrade Very loose product representation Things like parties, notionals, and dates are optional Everything in confirmation view is available (maybe optional) Reporting Intermediate representation Key economics are required (notionals, key dates, parties) but details are not (e.g. date adjustments) Everything in confirmation view is available (maybe optional) Confirmation As current 4.x product representation Prototype to show technical capabilities Pretrade and Reporting view not validated by business experts

5. FpML 5.0 Working Draft 3 is going to publish 2 views Reporting As current 4.x product representation Contains business processes such as position reporting, portfolio reconciliation, cash flow matching, etc. Confirmation As current 4.x product representation Prototype to show technical capabilities Reporting view not validated by business experts

6. Pretrade and Reporting views havent been validated by business experts Validation rules have been defined for the Confirmation view only Some of them applicable to other views too, but others not Documentation needs to be improved Lots of duplicated information Single documentation with view variations within it?

7. Potential Use Cases Position Reporting Portfolio Reconciliation Cash Flow Matching Others?

8. The Data Standards Working Group (DSWG), a group of U.S. hedge funds, developed a message type based on FpML to send daily position reports Some FpML required fields were using default values FpML incorporated the message type in version 4.2 but without defaults The FpML schema was not relaxed Should the reporting view use the DSWG analysis as input to made some of the required elements optional?

9. FpML has defined a set of message exchanges for portfolio reconciliation They reuse the Position definition based on the DSWG work Changes in the product definition for reporting will impact these messages

10. FpML has defined a set of message exchanges for cash flow matching A trade identifier and an optional set of trade identifying items (trade date, effective date, termination date,…) must be provided to reference the trade Would a more relaxed product definition have some use with these messages?

11. Collateral Management

12. Business Justification Whats the business case for the Reporting View (if any)? Scope Purpose Users Timing and Development Implementations Future implementations that would benefit from using the Reporting View