FpML Reporting View Meeting

June 1, 2009

Agenda Current Status

◦ Technical Details◦ Current Releases◦ Issues

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

Next Steps◦ Business Justification◦ Implementations

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

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

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

Issues Pretrade and Reporting views haven’t 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?

Agenda Potential Use Cases

◦ Position Reporting◦ Portfolio Reconciliation◦ Cash Flow Matching◦ Others?

Position Reporting 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?

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

Cash Flow Matching 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?

Others? Collateral Management

Next Steps Business Justification

◦ What’s 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