OTC Derivatives
Reverse Engineering ofFpML Schema
Work Plan
SWIFTStandards
June 2004
Version 1.0
This version 1.0 is the original draft version of the project plan for the development of standards for the OTC Derivatives Reverse Engineering of FpML Schema project.
This initial version lays out the principles and way forward for the development.
Table of contents
1.Introduction......
2.Background and scope......
2.1Background......
2.2Scope......
3.Delivery Approach......
3.1Product Description(s)......
3.2Development Approach...... 4
4.Project Organisation...... 5
4.1Project Structure......
4.2Project Plan Overview......
5.Project Dependencies...... 7
6.End of document......
1.Introduction
The purpose of this project is to model a segment of the OTC derivative business area on the basis of the existing FpML schema.
This model will be constructed using the UNIFI (ISO 20022) development and modelling methodology. It will take into account the model that has been developed for the treasury market.
Once the model will have been built and validated by the Reverse Engineering Validation Group, the final deliverable will bea business model and XML schemas for a segment of the OTC derivative business area.
2.Background and scope
2.1Background
Currently, different standards for interest rate derivatives are available to the financial market. They may address different needs, eg, the front and the middle office needs.
The FpML organisation has developed a standard in XML format for interest rate derivatives that was originally aimed for front office usage. The need for a financial institution to adopt only one standard throughout the whole life cyle of a trade, and the requirement to avoid divergence of standards for OTC derivative products, have led SWIFT to promote the use of UNIFI (ISO 20022) to FpML.
Like SWIFT, ISDA/FpML has become a liaison organisation to ISO, in order to participate in the UNIFI (ISO 20022) message development process. It is expected that FpML will participate in the UNIFI (ISO 20022) Registration Management Group and in the Standards Management Group that will oversee and validate the development of OTC derivatives products.
To help FpML gauge the implications of convergence, it has been agreed that SWIFT will build a model based on the FpML business requirements of an IRD Confirmation and will generate the UNIFI (ISO 20022) standards from the model. The purpose of this exercise is to compare the resulting UNIFI (ISO 20022) schemas with the original FpML schemas and analyse the impact of a migration by FpML to UNIFI (ISO 20022).
2.2Scope
Foreword
FpML and SWIFT have agreed to limit the modelling exercise to the business modelling and the schema generation of a vanilla interest rate swap confirmation.
The scope of the project is:
1To build a business model for a vanilla interest rate swap trade on the basis of FpML business requirements.
2To build a logical model (including messages) supporting the creation of a confirmation of a vanilla interest rate swap trade executed between two financial institutions.
For additional details please refer to paragraph 3.2. “Development approach” below.
The Reverse Engineering Validation Group will validate final scope and requirements.
3.Delivery Approach
3.1Product Description(s)
The major end-deliverables that will be produced are:
-MS Office documentation extracted from the Standards Workstation, containing the description of the business model.
-XML physical standards.
-MS Office documentation extracted from the Standards Workstation, containing the description of the physical standards.
-MS Office documentation containing the description of the impact of a migration by FpML to UNIFI (ISO 20022).
3.2Development Approach
The ISO 20022 methodology will be used for the development phase:
The business model level will include the information relevant for the processing of a vanilla trade confirmation (conforming to the ISO 20022 Development methodology).
Although the modelling stages will follow the modelling methodology, we will rely heavily on the FpML existing schemas.
The logical level of the modelling exercise will concentrate on the design of the message retained as an integral part of the standards development.
Rational Rose will be used to produce the modelling files in UML.
Automated reports based on the Rational Rose files will be generated and adapted to provide basic documentation in MS Office format. MS Office documents will be used to exchange feedback with the working groups.
The message standards produced will be in ISO 20022 XML syntax.
4.Project Organisation
4.1Project Structure
This section lists the functional groups together with their corresponding roles and responsibilities.
4.1.1SWIFTStandards Project Team
Role / ResponsibilitiesStandards Team Leader / Ms Jamie Shay: Project accountability
Standards Project Leader / MsFrançoise Massin: Co-ordination of the project
Business Analyst / Ms Françoise Massin
- Provide business knowledge;
- Writing and revision of the working documents and final deliverables;
- Communication with the Reverse Engineering Validation
- Organisation of the meetings.
Modelling Engineers / Ms Françoise Massin and Mr Stéphane Canon:
- Provide modelling knowledge;
- Create and update the model;
- Ensure that the model is in line with the UNIFI (ISO 20022) modelling methodology;
- Consolidation with other modelling projects;
- Contact with UNIFI (ISO 20022) Registration Authority (RA);
Business Solution Manager / MrAdrianWalton
- Liaises with the market
4.1.2Reverse Engineering Validation Group
- Role:
The role of thisgroup is to:
-provide business input on the modelling of the interest rate swap vanilla trade;
-identify and describe the business activities;
-identify and define precisely the specific business elements related to interest rate derivatives.
-validate the business model and related standards;
- Profile:
Standards or modelling knowledge is not a prerequisite, business knowledge is key.
The participants must have a good knowledge of the FpML standards for Interest Rate Derivatives.
- Composition:
The responsibility to select the group members will be shared between FpML and SWIFT.
- Communication:
It is foreseen that continuous consultation be organised either with face to face meetings or with feedback documents exchanged via e-mail. Conference calls will also be scheduled. One physical meeting is planned to take place.
4.2Project Plan Overview
Please note that the following task list will be updated and adapted during the course of the project.
Tasks / Responsible / Deliverables / Timing1. Produce and send :
- Project Plan to Reverse Engineering Validation Group
- Preparatory documentation for first meeting
- Project plan
- Preparatory documentation for 1st meeting
1st week July 2004
2. Feedback on preparatory documents by Reverse Engineering Validation Groupto SWIFT / Reverse Engineering Validation Group /
- Feedback e-mail/document
3. 1stReverse Engineering Validation Group / Group and SWIFT /
- Business model and schema for Vanilla IRD trade
4. Final ratification of Reverse Engineering / Reverse Engineering Validation Group /
- List of discrepancies between FpML schema and UNIFI schema
5.Project Dependencies
The modelling of this project is dependent on the modelling constraints required by the UNIFI (ISO 20022) guidelines. It must also take into account the fact that several elements used by FpML are re-utilised in the schemas of other products. When potential discrepancies are noted, change requests will be submitted for approval to the Reverse Engineering Validation Group.
6.End of document
IRDRE_PP_v.1.0.doc – June 20041