kramer

Slide1: 

Axel Kramer—axel@2far.com Fragment Art & Research, Inc. FpML Initial Design Tradeoffs

What is FpML?: 

What is FpML? “Financial Products Markup Language” XML-based language Representation of interest rate and foreign exchange derivatives and related information Initially: represent client view represent data, not messages

Simple Interest Rate Swap: 

Simple Interest Rate Swap Company B Company A Fixed interest 5% in USD 6m USD LIBOR + 0.04% spread On a 20,000,000 USD notional. For 10 years semi-annual payments.

Client View: 

Client View Company B Company A trade sign confirm Data in confirm

Why is this interesting?: 

Why is this interesting? Currently labor-intensive manual process High transactional friction Leverage electronic processing: C2B, B2B inside B, inside C new kind of services

Who is working on FpML?: 

Who is working on FpML? Driven by financial industry. Initially collaboration between J.P.Morgan and PriceWaterhouseCoopers. Shift to open process, broad support by market participants, vendors, and software companies.

What is the current status?: 

What is the current status? Initial working draft published: www.FpML.org Next steps: get organizational structure and process in place Initiate working groups Initiate prototypical implementations

Why am I here?: 

Why am I here? Talk about the “XML-How”… Present some of the issues Communicate tradeoffs that were made Solicit feedback Spark YOUR interest!

Main Issues: 

Main Issues Objects Composition Validation References

Objects—Goals: 

Objects—Goals Organize data with an object oriented point of view. Follow instance of a class/instance variables paradigm. “Interface-based” types of instance variables.

Objects—Our choices: 

Objects—Our choices Strict naming conventions to tell object and its state apart. Use of namespaces to keep classes apart (mostly). No reliance on positional information, except in named and anonymous collections.

Objects —FpMLExamples: 

Objects — FpML Examples …fragment out of fixed stream <isfi:initialPrincipalPayment> <p:Payment xmlns:p="urn:fpml-Payment"> <p:paymentDate> <d:AdjustableDate> <d:date>1999-06-06</d:date> <d:businessDayConvention>ModifiedFollowing</d:businessDayConvention> <d:adjustmentsReference>primaryBusinessCenters</d:adjustmentsReference> </d:AdjustableDate> </p:paymentDate> <p:paymentAmount> <m:Money> <m:ccy>USD</m:ccy> <m:amount>1000000</m:amount> </m:Money> </p:paymentAmount> </p:Payment> </isfi:initialPrincipalPayment> …

Objects—Alternatives: 

Objects—Alternatives Don’t use namespaces, instead prefix or change name on case by case basis. Merge instance variables up into their owner, and have meta-information that denotes the current class.

Composition—Goals: 

Composition—Goals Maximize reuse of components. Processing service based flexibility. Utilize structure and be explicit as possible. Allow for proprietary and public extensions.

Composition—Our Choices: 

Composition—Our Choices Fine grained components, used everywhere (e.g. Money, Rate, AdjustableDate). Coarse grained components inside Trade, to express “bigger” concepts (e.g. TradeID, Party, Product). Trade as data envelope.

Composition —Envelope: 

Data Envelope (Some Trade) Data A Service X Service Y Data B Data C Data D Composition — Envelope

Composition—Alternatives: 

Composition—Alternatives One big component per product or trade. Coarse components that are enriched over time. Flat structure for representing parameters of product.

Validation—Goals: 

Validation—Goals Validate as much as possible with standard mechanisms. Facilitate non-standard validation when necessary. Don’t let current technology totally determine how FpML is structured.

Validation—Our Choices: 

Validation—Our Choices Use DTD’s for now. Move to XML-Schema when stable. Represent addl. meta information as attributes. For now require application level validation for data types, referential integrity, and semantic validation.

Validation—Alternatives: 

Validation—Alternatives Skip DTD, pick one of the schema proposals. Skip DTD, use proprietary validation tool. Validate once and sign.

References—Goals: 

References—Goals Enable use of external reference data Currencies, Holiday Calendars, Business Centers Minimize redundancies Between coarse elements Inside one component Facilitate “thin” processing

References—Our Choices: 

References—Our Choices Name of element defined in attribute. Reference is simple name, owning element defines context. Naming convention for referencing element.

References —FpMLExamples: 

References — FpML Examples <fpml:Trade> <fpml:tradeIDs> <tid:TradeIDs xmlns:tid="urn:fpml-TradeID"> <tid:TradeID> <tid:partyReference>ABC Trust</tid:partyReference> <tid:transactionReferenceNumber>237732</tid:transactionReferenceNumber> </tid:TradeID> ... </tid:TradeIDs> </fpml:tradeIDs> <fpml:partyInformation> <pty:PartyInformation xmlns:pty="urn:fpml-party"> ... <pty:tradeParties> <pty:Party name="ABC Trust"> ...

References—Alternatives: 

References—Alternatives ID, IDRef XPointer Binding Declarations XPath

Summary: 

Summary Briefly described FpML (what, why, who) Elaborated on XML-issues (Objects, Composition, Validation, References) Transition from document centric use of XML to data centric use is part of XML-evolution, and it’s not easy…

For more info:: 

For more info: Check out www.FpML.org Contact: