Why are there no messages defined?

The focus of FpML is on the basic data objects that particular kinds of processing require. FpML does not specify how the processing is done, nor does it talk about how the data gets to the processing services.

In some areas message protocols for describing transport and transactions between systems/users exist already and it is the hope that FpML descriptions will eventually be embedded in those. In other areas, especially for Internet based applications and XML based application services, such standards are much less developed. By not insisting on a particular protocol the standard enables and encourages more experimentation and a larger potential usage of FpML.

Future versions of FpML might standardize aspects of processing once a shared view in the user community develops on which ones those are.

Why Client View?

It is easier to define a standard for areas that many users agree on already. The Client View is something that is not proprietary to a particular financial institution, it is exchanged in confirms and codified through the ISDA agreement. Thus one hopes that there is less reason for conflict and a faster agreement on a standard, than on other areas, e.g. the financial event structure, pricing results.

Is there a difference between Business Transactions and Protocol?

In the context of this document, protocol means how bits are moved from one system to another (HTTP, CORBA, TCP/IP), and business transaction means the semantics and procedure related to the business related interchange between parties (sell, unwind, buy). FpML does not standardize on a protocol. Currently FpML does not include any standardization for business transactions, but it might in the future.

What is the relationship to other standards?

FpML is a standard driven by the financial industries with support from vendors. Although it does compete conceptually with some vendor driven standards there is a strong desire to come to consensus on a standard that is most beneficial to the financial industry. Some other standards, finance industry and vendor driven ones, are more complementary, in that they focus on other kind of financial instruments, or in that they focus on the business transactions between parties.

Why are some element names in lower case and some in upper case?

An object oriented perspective benefits from a clear differentiation between classes and the state captured by a class. XML, coming originally from the world of document markup, does not facilitate such a view natively. FpML therefore uses naming conventions to make those distinctions clear. An upper case element name always represents the name of a class. Lower case names always represent an instance variable/fields.

Why CamelCase?

The camel case is a naming convention that originated with Smalltalk and was later used within Java, JavaScript and VisualBasic. It has therefore quite some market share in the realm of naming conventions.

Why are collection elements wrapped in their own element?

The aim is to be as clear as possible about repeating elements, and the easiest way to accomplish this is to wrap them in their own structure and not mix them up with elements that only have a single occurrence. The same mechanism is used in many programming languages that allow the definition of data records/types. Most will use an extra instance variable to point to a collection of objects (one of the exceptions to this is LISP where the basic underlying structure is a list)

How are ID and IDREF used?

FpML currently does not use ID and IDREF. The main reason is that this would require names that are unique for one document, and since there might be multiple trades in one document, those unique names are not easy to come by. FpML favors a trade relative naming approach and is aiming to use Xpath once it becomes stable. There is also a proposal on the table on how to redo naming and references, which is a little more restrictive but more structured and would also eliminate the redundant data in documents right now.

How are attributes used?

Currently attributes are only used for two purposes: (1) to represent typing meta-information, and (2) to express naming. Even though initial versions of FpML made use of attributes for enumerated values that was dropped in favor of a consistent element approach.

Why are there so many files for defining the DTD's?

One of the goals is to provide a clear structure that allows definitions to be mostly independent of each other. This is important for development, evolution, and maintenance reasons. DTDs' might be sorted into subdirectories later.

Where are the allowed combinations and values of elements documented?

This still needs to be done; it should be part of the element description for the first public release.

Why are the trade related data components so coarse?

One goal in the structuring of FpML has been to be able to factor the data components in suitable ways for processing. In particular, it is a goal that a particular processing service can pick and choose the minimal set of trade data components it requires for a task.

Why not have flat data structures?

Within FpML data is grouped together in a fashion that can be thought of as a class / instantiation of a class. It also makes the relationship between data explicit where appropriate. Arbitrary nesting allows capturing different levels of granularity regarding grouping entities together.

This approach generally results from an object background. XML is typically not used to serialize object structures, but the benefits of doing that surpass the disadvantages of an unusual XML style.

Why isn't there a notion of a deal?

In contrast to a portfolio, a deal expresses a number of trades that are entered into in one business transaction. For now FpML avoids this issue, because it is close to the subject of business events. It should be revisited for the first public release.

Why isn't there a notion that products can be stand-alone?

It is clear that such a feature is desirable, but it raises the problem that one does want to have particular values of such a product filled in. E.g. if one has an auction like service or an electronic offering of products one probably wants to express that one can offer 5 year USD LIBOR swaps but leave particular other values up to the buyer to define. FpML is currently missing a mechanism to express incomplete products. A new reference proposal might help here. The issue needs to be revisited before the first public release.

What is a view, and can one define an arbitrary one?

A view is a particular, required, collection of the information components contained in a trade. Typically a view is processing service specific in that it is the subset of elements that must be in the Trade element for a service to function properly. For example, one might have a matching service that needs the trade ids, product, parties and fee elements in order to do a match, whereas a pricing service where clients can store their portfolios might only need the trade ids. Currently there is no mechanism to express a view. This issue should be revisited in the context of business events and processing before the first public release.

How are multiple products in one trade modeled?

Such a facility does not exist right now, but a simple mechanism would be to create a CompositeProduct that can include a list of products. This issue should be revisited before the first public release.

What is the difference between portfolio and generic transaction grouping?

The grouping and nesting of trades in portfolios, and the grouping and nesting of portfolios themselves is done to structure one's world of trades in appropriate ways for the purpose of communication and processing. A trade might actually be in multiple such portfolios. When trades are grouped within a business transaction it typically means the business transaction will fail if it fails for one of contained trades. FpML currently does not model business events and a transactional grouping of trades should be considered when business events are revisited.

Is there one and only one document for a trade?

No. There can be many documents that contain a particular trade. Furthermore, there might be documents that do not contain all the available information for a trade. (Note, in FpML a trade is seen as all available information associated with the ownership of a product). Sometimes the information that makes up a trade is generated on the fly and sometimes the different information components might come from multiple databases. This question relates to the view question above.

How can I add my proprietary data?

If the data you want to add is related to the ownership of a product, invent a new information component and make it a sub-element of the Trade element. If it is independent of a product, invent a new information component and make it a sub-element of the FpML element. Use namespaces to avoid name clashes. Do not add new elements or attributes to other standard components.

How can I use my proprietary data?

For the particular processing service, define which data components are required (standard ones and proprietary ones). As mentioned above, this subset of components is called a view (and currently FpML does not have a formal mechanism to express this concept). When receiving FpML in the processing service, validate that it conforms to that view. However, in order to converse with others in standard FpML, you must construct views only from components that are defined in the standard.

Why are namespaces used?

Without namespaces all sub-elements end up in one global namespace. Coming from the object oriented world the analogy is that all instance variable names are in one global namespace instead of being local to the class hierarchy of the class they are defined in. Any time somebody in a development team makes a local change, there is a potential with conflict with existing elements or concurrent local changes in another area by another user. That is a current flaw with XML and DTDs and namespaces are used to avoid this problem.

Aren't elements declared many times?

Shared components are declared in their own namespaces, and the object-oriented approach allows defining them only once, but making use of them in different contexts. For instance variables that have the same name and are defined in multiple objects it might feel like a redefinition. Some of that is due to the fact that they really are different, some of that is due to the fact that current DTDs' cannot express inheritance, and thus require the redefinition of elements, which would have been factored into common super classes in an object-oriented data model.

Why Prefixing?

Prefixing achieves the advantage of namespaces with DTDs even though the existing DTD validation mechanisms do not support namespaces. Once FpML moves to schemata the need for prefixing every element goes away and one can use scoped namespace declarations instead. Documents that have been created under the first, DTD based version continue to be valid documents when FpML moves to schemata.

How are references from one data element to another done?

Currently this is done by name. Specifically, the element that is being referenced will have a name as an attribute (e.g. name="name"). This will then be the value the referencing element uses. In general, if the value of an element foo can be expressed by a reference, there is an alternative element called fooReference, which contains the reference name. This issue needs to be revisited for the first public release. XPath, a shared proposal by the XSL and XPointer group of W3C is getting more stable and could be used instead.

Why is Money an object in itself?

It is an object because it is an interesting semantic unit in the financial domain. In that sense it is similar to Floating Rate and Fixed Rate. FpML opts for the structured approach and reifies those kind of objects instead of folding them flattened into the object that contains them.

Where is validation done and how much is necessary?

There is a scale of choices with respect to the validation of XML documents. On the rigid spectrum one uses all possible features of a DTD to do validation, on the other side, one gives up on DTDs because they are so weak anyway, and does all validation in the application. FpML takes a middle ground. As much validation with DTD's is done as possible without having that force unnecessary burden on the expressibility or consistency. Schemata languages will pick up some of the remaining validation issues, (e.g. to check types and enumerations, which FpML does not represent as attributes), but there is a requirement for doing validation in the application or a validation services (which could then sign the information component, so no repeat validation would be necessary). The main areas of validation that fall in that category are referential integrity of named and referred elements and the instrument specific appropriate values of elements. The latter needs to be described with the element description before the first public release.

How are signatures done?

This topic is a candidate for a working group in the technical committee. Currently FpML assumes signing and the storage of signatures in an information component is independent of the components that need to be signed.

Where are the business events?

This release does not define any business events. It does make some suggestions in the business scenario section as to what business events might be interesting ones for a particular domain, but the standard itself does not define them. It is assumed that their definition would make use of elements currently defined in this standard as part of their data and that processing related working groups in the technical committee will pick up this topic.

Should there be versions of a trade?

This issue is interesting and important for certain kind of processing but has been deferred to working groups in the technical committee.

How does FpML provide access to the history of the data?

This issue is interesting and important for certain kind of processing but has been deferred to working groups in the technical committee.

How does matching work if there are different ways of expressing the same concept?

This question is applicable for the high level matching (e.g. vanilla fixed float vs. general swap) as well as the lower level (e.g. different date structures). One possibility is to explicitly state which choice is being used and if there is not agreement at that level, then there is no match. Another possibility is to have a transformation from one to another. When translating from the simpler version to the more complex (e.g. vanilla to more general), the transformation should be able to be completely specified. If the transformation goes the other way, obviously it might not work (that is a non-vanilla swap might be the input which would not in fact be able to be transformed). Matching also presents a problem when some kind of algorithm is involved (e.g. dates and frequency). All parties must agree on the algorithm. If there are discrepancies, this would be problematic. The standard must define the rules to generate a normalized form that can be compared.

Can an FpML document serve as the prime record?

There are different opinions about this right now. In the end, this issue will be driven by business needs/opportunities and the consensus of the technical committee.

Why isn't the document expressed from one party's point of view?

FpML uses a symmetrical document because that implies that the same document can be signed from either party's point of view. This means there is no 'owner' concept for the document, although there may be from a trade perspective.

How does FpML handle reference data?

There is a difference to how internal and external reference data should be handled: for external data it is reasonable to provide some kind of reference. For internal data that not all parties will see, it is not, except in proprietary data components. Reference data that can be expressed with an international standard will be expressed in a notation, e.g. currencies, ISDA-rate option names, business centers. Dates are expressed in the ISO standard.

How are defaults handled?

"Defaults are usually wrong". FpML does not have any defaults in the standard. Applications can provide user interface defaults when constructing FpML.

Why are there rigid instruments and flexible ones?

The Vanilla fixed float will cover a significant number of trades while still providing a simpler structure. People will be able to understand the simpler structure more easily (e.g. only 10 things to look at instead of 100). Systems will be able to be simpler if some clients only want to deal with the vanilla case.

Why aren't there low-level components that can be plugged together for arbitrarily complex products?

This is a complex enough topic that it probably warrants a white paper. From a business point of view it scales better and makes processing for simple products easier, while still allowing the definition of more complex products.

Is there an alternative to parametric information for date schedules?

There are provisions in the standard for replacing some parametric information by explicit information. This has not been emphasized and used in the version of the document but it is facilitated by the object-oriented approach taken.

What market data is supported in this release of FpML?

This release of FpML supports the definition of exchange rates, and implied volatilities for FX Options.

• The exchange rate definition includes an optional direction specifying bid, ask, or mid.
• The implied volatility data is organized per currency pair with multiple tenors per currency pair.

The support for market data will be extended in the next release to include other data such as zero curves, correlations, interest rates etc.

What is an FXLeg?

The FXLeg component is common to FX Spot, FX Outright and FX Swap products. It represents the exchange of two currency amounts at a specified rate and date. Two FX Leg components are combined to form an FX Swap trade where the same currencies are exchanged on two different dates. Application logic will be used to determine whether the data contained within the two FX Leg components is consistent.

Can templates be arbitrarily combined to create new products?

The FpML definition is hierarchical in nature. Products are built from pluggable components called Templates. Various templates such as FXOptionTemplate, FXLegTemplate, FXBarrierTemplate, FXBinaryTemplate are combined as required to define products. These templates cannot be arbitrarily combined because products could be created which are not valid instruments.

How are the exchange rates expressed?

FX exchange rates can be expressed by specifying currency1, currency2, quote basis and the rate. The quote basis provides context to the rate and can either be number of currency1 per unit of currency2 or number of currency2 per unit of currency1.

What are FXCore and FXOptionCore and FRACore components?

Although these components are not meaningful in business terms, they represent a collection of fields that are common amongst a set of related products. The 'core' components were created to collect a set of common fields into one component that is reused as needed.

Why is 'base currency' omitted from the FXSpot, FXOutright and FXSwap and included in FXOptions?

The 'baseCurency' element is used in FX Option instruments to indicate which of the two currencies is regarded as the base currency for this FX trade. In conjunction with the FXRate and its term field, the baseCcy indicates the market convention being used: American ('base per term' or 'base per risk') or European ('term per base' or 'risk per base'). The 'baseCcy' must correspond to one of the two currencies involved in the trade.

Why are multiple settlement dates allowed?

It is possible for the currencies of a foreign exchange transaction to be exchanged on different days, however because this is a very rare occurrence normally one settlement date will be needed.

Why are fixings supplied together with fixing reference information?

The fixing reference information is recorded when the deal is executed before any fixings have occurred. During the life of the trade, fixings are applied to the trade and can be sent along with the reference information in order to determine risk or mark-to-market information, as the fixing rates must be supplied.

From whose perspective is FpML defined (buyer or seller)?

The FpML definition is party neutral in the sense that element tags define trade components generically. For instance, notional related information is defined using ccy1Amount or ccy2Amount and not buyAmount or sellAmount.

It is possible that a trade information could be transferred multiple times between two parties before it gets confirmed. The above concept eliminates any need to change the FpML to reflect a party's perspective.

Can multiple barriers be defined?

The FXBarrierCore component can be used to define single barrier products: Knock-in, Knock-out or multiple barrier products, such as a Double Knock-out.

Is this a complete set of Party information?

No. The approach has been to provide the information necessary to cover the current scope of FpML. Release 1.0 contains only the information necessary to exchange data for trade confirmation and settlement.

Does Party provide information for Risk and Exposure management?

Only to the extent that the information currently provided is used for this purpose. Supplemental information will be added in subsequent releases to the current Party framework to support detailed risk and exposure reporting, e.g. industry codes and country of assets.

Can payment instructions be provided by swap stream?

Not yet. While multiple payment instructions per currency can be provided into the Settlement Instructions, the links between streams and payment instructions have not yet been provided.

Why does the Contact element have the Phone Number as a required component?

In most contexts, the contact is an optional element. However, if it is defined, some information should be provided so the person can be reached. The phone number is considered mandatory since the address is an optional element and just providing the name was considered inadequate information to reach him/her.