june 1, 2009. current status technical details current releases issues potential use cases position...
TRANSCRIPT
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