Axel Krameraxel2far.com

1
FpML Initial Design Tradeoffs

• Axel Krameraxel_at_2far.com
• Fragment Art Research, Inc.

2
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

3
Simple Interest Rate Swap
Fixed interest5 in USD
Company B
Company A
6m USD LIBOR 0.04 spread
On a 20,000,000 USD notional. For 10 years
semi-annual payments.
4
Client View
trade
Company B
Company A
sign confirm
Data in confirm
5
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

6
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.

7
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

8
Why am I here?

• Talk about the XML-How
• Present some of the issues
• Communicate tradeoffs that were made
• Solicit feedback
• Spark YOUR interest!

9
Main Issues

• Objects
• Composition
• Validation
• References

10
ObjectsGoals

• Organize data with an object oriented point of
  view.
• Follow instance of a class/instance variables
  paradigm.
• Interface-based types of instance variables.

11
ObjectsOur 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.

12
Objects FpMLExamples

• fragment out of fixed stream
• ltisfiinitialPrincipalPaymentgt
• ltpPayment xmlnsp"urnfpml-Payment"gt
• ltppaymentDategt
• ltdAdjustableDategt
• ltddategt1999-06-06lt/ddategt
• ltdbusinessDayConventiongtModifiedFollowinglt/d
  businessDayConventiongt
• ltdadjustmentsReferencegtprimaryBusinessCenters
  lt/dadjustmentsReferencegt
• lt/dAdjustableDategt
• lt/ppaymentDategt
• ltppaymentAmountgt
• ltmMoneygt
• ltmccygtUSDlt/mccygt
• ltmamountgt1000000lt/mamountgt
• lt/mMoneygt
• lt/ppaymentAmountgt
• lt/pPaymentgt
• lt/isfiinitialPrincipalPaymentgt

13
ObjectsAlternatives

• Dont 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.

14
CompositionGoals

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

15
CompositionOur 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.

16
Composition Envelope
Data Envelope (Some Trade)
Data A
Data B
Data C
Data D
Service X
Service Y
17
CompositionAlternatives

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

18
ValidationGoals

• Validate as much as possible with standard
  mechanisms.
• Facilitate non-standard validation when
  necessary.
• Dont let current technology totally determine
  how FpML is structured.

19
ValidationOur Choices

• Use DTDs 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.

20
ValidationAlternatives

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

21
ReferencesGoals

• Enable use of external reference data
• Currencies, Holiday Calendars, Business Centers
• Minimize redundancies
• Between coarse elements
• Inside one component
• Facilitate thin processing

22
ReferencesOur Choices

• Name of element defined in attribute.
• Reference is simple name, owning element defines
  context.
• Naming convention for referencing element.

23
References FpMLExamples

• ltfpmlTradegt
• ltfpmltradeIDsgt
• lttidTradeIDs xmlnstid"urnfpml-TradeID"gt
• lttidTradeIDgt
• lttidpartyReferencegtABC Trustlt/tidpartyRefere
  ncegt
• lttidtransactionReferenceNumbergt237732lt/tidtr
  ansactionReferenceNumbergt
• lt/tidTradeIDgt
• ...
• lt/tidTradeIDsgt
• lt/fpmltradeIDsgt
• ltfpmlpartyInformationgt
• ltptyPartyInformation xmlnspty"urnfpml-party"
  gt
• ...
• ltptytradePartiesgt
• ltptyParty name"ABC Trust"gt
• ...

24
ReferencesAlternatives

• ID, IDRef
• XPointer
• Binding Declarations
• XPath

25
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
  its not easy

26
For more info

• Check out www.FpML.org
• Contact