Scribd
Upload
58 views2 pages

FPML Views Faq

b2b

Uploaded by

suljo atlagic
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
58 views2 pages

FPML Views Faq

b2b

Uploaded by

suljo atlagic
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 2

Views – FAQ

Architecture Working Group


Editor: Andrew Jacobs
Updated: 2012-08-29

Introduction
Since release 5.0 the FpML schema has supported the generation of multiple ‘view’ schemas from a
common ‘master’ schema. The ‘views’ mechanism was created to address the problem of varying
the information content of schema to reflect the requirements of the business processing being
applied to it.

The first business process that FpML addressed was trade confirmation and as a result the models
for the trade structure and derivative products are strictly defined to ensure that all the data values
that would be mandatory on a paper confirmation document are defined as mandatory within the
XML schema.

When the working groups turned their attention to other business processes, such as pre-trade
negotiation and reporting they discovered that confirmation style designs where too strict and
needed to be adjusted to allow an alternative definition in which some normally mandatory
information could be omitted (e.g. business day adjustments, etc.) or replaced entirely.

Why view generation?


Supporting multiple views in a single schema can only be done either by modifying the grammar so
much of the content is either optional or selected from a choice group. However such a grammar is
so loose that it is unable to validate the data content from any view.

To have a strict content model for each business process ‘view’ of the data we need multiple
schemas, each with its own specific grammar, but maintaining multiple schemas to ensure that an
important change to one is reflected in the others would be time consuming and error prone if done
manually.

The solution is to derive all the views from a single ‘master’ schema using information that describes
how to adjust schema components to match the requirements of the view.

How many views will there be?


In FpML 5.4 there are four views namely, confirmation, reporting, transparency and record keeping.
Each view has been developed to address a particular business process and its data requirements.

Every time FpML is extended to cover a new business task the Business Process working group
considers whether the task can be accommodated within an existing view or whether a new view is
required.

Copyright © 2012.  International Swaps and Derivatives Association, Inc.


The (relatively) recent addition of messages for option exercise for example fitted within the existing
confirmation (post-trade) view but if we were to develop messages for pre-trade processes this
would require a new view to be defined.

Can a message appear in multiple views?


FpML 5.x uses a more generic message pattern than was present in earlier versions. Some of the
business messages structures (e.g. requestConfirmation, etc.) could appear in more than one view.
There is also a set of system message structures that are present in every view (e.g.
messageRejected).

Applications that process messages from more that one FpML view MUST examine both the name of
the FpML root element and its namespace URI to determine what the message was intended to
communicate.

What is the best view for internal communication?


FpML was designed to be a standard for ‘Business-to-Business’ (B2B) communication. Its messages
are designed to contain enough information to execute some business process and no more.

In particular FpML does not contain any management information needed to correct book or process
trades within a bank (e.g. no books or accounting information, no system names, no processing
instructions, etc.).

For most front office to middle/back office STP data transfers an extended version of the FpML
confirmation view is probably the best match as it contains complete and detailed trade economics.
Some risk and finance data feeds may be better served by the reporting view.

Extensions to FpML (to add additional MIS type information) should be done using the techniques
described in the Architecture specification rather than by directly editing the schema.

The AWG is considering the possibility of developing a tool to allow custom views to be generated
from master schema to help make this task easier.

What is the ideal master schema?


The original intention was that specific views should be derived from the master schema through a
process similar to XML schema restriction. This would mean that the master schema would have the
loosest grammar and each of the generated views would be a restricted subject of its model. Such a
master schema would be useful as the model to generate an XML binding library from.

At present the FpML master schema does not match this vision. The initial FpML 5 master schema
was created from the confirmation model in the 4.x version and annotations have been added to
allow the generation of less restrictive views, like reporting, from it.

The AWG would like to correct the master schema but it has to be done without accidentally
introducing any unintended changes. Manual editing would be too error prone so we need to
develop some automated tools to algorithmically correct schema and compare the results with the
current views to ensure accuracy.

Copyright © 2012.  International Swaps and Derivatives Association, Inc.

You might also like