FpML 5-5 pretrade View - BUSINESS PROCESS ARCHITECTURE

3 BUSINESS PROCESS ARCHITECTURE

3.1 Introduction

The FpML 4.0 Schema was the first release of the specification to place a messaging framework around the product descriptions to describe the context and use to which the information is expected to be put. This section describes a small set of complex types and elements that comprise a simple message framework that is used as the basis for defining business messages and processes suitable for use in a communications process.

These definitions introduce a new set of ideas that previously could not be used in FpML because of its reliance on DTDs as the formal specification of the grammar. The following sections describe the reasoning behind the features used in the framework as well as a description of several business processes.

3.1.1 Why Business Messaging?

Increased efficiency in financial markets can only be achieved through greater automation of transaction processing and use of electronic messaging (e.g. the exchange of information directly between computer systems with as little human interaction as possible). In order to achieve this all the parties involved in such communications must agree on four things, namely:

Representation

There must be a common representation of a transaction, product or other reference data item that is accepted by all the parties.

The core FpML grammar defines a standard vocabulary for derivative based transactions and products that can form the basis of a messaging standard. As new messaging applications are considered the scope of the core grammar will need to expand to encompass the additional types of data referenced in these messages.
Semantics

All the parties must have the same interpretation of the information expressed by the representation.

The work of the validation working group provides a set of rules to ensure that a product definition conforms to the market definition for that product. The FpML rule set will expand and evolve over time as new financial products and message types are added to the grammar.
Business Process

All the parties must follow the same business processes and respond appropriately to any communication they receive.

To support the consistency across different business processes and views, the Messaging Task Force defined a new messaging framework that extended the core grammar. This section describes some business processes and shows how they could be implemented as message exchanges. This section describes some business processes and shows how they could be implemented as message exchanges.
Transport

The parties must agree on the communications transport used to interconnect their businesses.

FpML does not endorse any particular messaging transport for communication. The choice of transport is left to the implementer although in practice we expect only a few to be found suitable.

Disagreement over the first three of these features will mean that FpML users will potentially have to implement, maintain and support different software systems for each FpML aware service or application that they use. Supporting multiple communications transports is typically not that difficult although it does incur additional operations costs.

3.2 The Messaging Framework

3.2.1 Introduction

FpML 5 introduces a new messaging framework to address limitations in the version 4 framework.

This new framework does the following:

it consistently implements a set of general principles to make it easier to use the messages to implement real business processes
it adjusts the representation of parties, accounts, and roles to clarify the purpose of messages and the roles of the parties within a message.

The following section describes the new messaging framework.

3.2.2 Issues in FpML 4 Messaging Framework

Following are some of the issues in the FpML messaging framework that the version 5 framework seeks to correct:

Incomplete message set – in many cases not all messages required to implement a business process are defined in the FpML 4 message set. In particular, many requests lack acknowledgements, exception responses, correction capabilities, and in some cases normal responses. Many generic business processes (such as confirmation) have different levels of completeness depending on the specific event that is being covered.
Inconsistent message correlation – different implementations use different features of the FpML 4 framework to link successive messages together, making them incompatible.
Unclear processes – it is not always clear how the version 4 messages are to be combined together to fully implement a business process. For example, which message should be used to acknowledge or respond to a request isn’t always defined. While this could in theory be addressed through documentation, because the message set is incomplete, this is difficult to do.

3.2.3 Design Assumptions

In order to create the messages and business processes described in this document some design assumptions had to be made, principally:

3.2.3.1 Highly Assured Transport

Throughout this document we have assumed that message exchanges will be carried by a passing of messages over a highly assured transport, such is provided by a messaging queuing system. This form of transport is commonly used today in the finance industry (e.g. AMQP, Apache QPid, FIX engines, MQSeries, MSMQ, RabbitMQ, SwiftNet Interact 'Store and Forward', etc.).

One important consequence of this decision is that error cases related to non-delivery do not have to be considered (e.g. once accepted a guaranteed messaging queuing system WILL ALWAYS deliver a message) although the 'freshness' of the message may need to be considered (e.g. has the message been stuck in a queue waiting to be delivered for a long period of time). Similarly message queuing system can normally eliminate duplicate messages so these are not considered either.

3.2.3.2 No Preservation of Message Sequence

There is no requirement for message sequence to be preserved over the message transport. Message sequence must not be expected to be repeatable nor predictable.

In practise enterprise message buses cannot be expected to halt the enterprise to preserve sequence. Hence this is not a requirement of FpML.

3.2.3.3 Long-Running Processes

Some of the business processes are 'long-running' in that once initiated they may remain active for a considerable time before completing (e.g. a request to confirm a trade may take many hours as it is dependent on the time of arrival of the matching trade). During this time the process may generate periodic notifications to the originator of the request and/or other parties. Such notifications will appear in the message stream set to a participant intermixed between other response messages.

An implication of such 'long-running' transactions is that the 'service provider' will contain a complex 'state'. The service should make suitable provisions to persistently record its state so that in the event of a software or hardware failure it can recover transparently without its clients having to resend any information.

3.2.3.4 Observable Completion

Principle: All requests should result in an "observable completion", that is a clear (observable by the requester) response.
Implementation: For each request or notification message there should be at least one defined acknowledgement message. In the case where the response to the request might be delayed pending additional information, the recipient of the request should acknowledge the request. [Should we set a guideline here? E.g. acknowledge if resulting action is likely not to occur within 10 seconds?]

3.2.3.5 Consistent Message Correlation

Principle: There should be a single, well-defined way to link successive messages (such as corrections or retractions of requests or notifications). This should not rely on message or transport level information, but rather use business-level information.
Implementation: Add an explicit correlation identifier, defined as business object identifier, and a sequence number to link successive messages.

3.2.3.6 Consistent Error Reporting

Principle: There should be a standard way of reporting error or exception status for each type of request.
Implementation: Ensure that there is an exception message for each message workflow.

3.2.3.7 Consistent correction and retraction mechanism

Principle: There should be a consistent way to correct messages containing an error, and to retract (withdraw, cancel) messages when the information is no longer valid or the action is no longer required.
Implementation: Correctable messages will contain an "isCorrection" indicator to indicate whether the message corrects a previous message. Retractable messages should have a corresponding message ending with "Retracted".

3.2.3.8 Consistent Processes Across Trades and Post-trade Events

Principle: Business processes should work consistently across trading events and post-trade events where possible, so the same messages should be available for each type of event.
Implementation: Most messages will be designed to be able to handle multiple types of events, such as new trades and post-trade events. This allows consistent coverage of a number of post-trade events with a number of business processes.

Implementers attempting to construct software based on these protocols using a non queuing transport (e.g. WebServices, DCOM, CORBA) will need to implement a reliable message layer to encapsulate the current message sequences (e.g. a get/put message interface using sequence numbers to detect lost or duplicated messages and positive/negative acknowledgments). The W3C site contains links to proposals for such extensions for use with WebServices.

3.2.3.9 Transport Characteristics

3.2.3.9.1 Purpose

The definition of the FpML business processes assumes the use of reliable messaging, meaning high predictability. Generally, increasing reliability increases latency. The assumption of reliable messaging is provided to make it easier to design standard business processes and messages. If the transport characteristics were not defined, the business process definition would be ambiguous.

3.2.3.9.2 Layers

The protocol that is used for exchanging FpML messages is defined in being in three main layers:

The Business Layer is the higher layer and deals with FpML documents. The exchange of FpML documents is fully described in the message choreography and the structure of the FpML documents is fully described by the schemata and the related validation rules. The Business Layer is equivalent to adding a Layer 9 to the OSI model.
The Message Transport Layer is the lower layer and deals with transport messages. The implementation of this layer is outside the scope of FpML since it varies. The Transport Characteristics apply to the Message Transport Layer. This layer is equivalent to adding a Layer 8 to the OSI model.
The layer immediately beneath the FpML Protocol is the Messaging Application Layer. FpML allows any Messaging Application that supports the requirements of the Transport Characteristics defined below. The Messaging Application Layer is Layer 7 of the OSI model.

3.2.3.9.3 Reliable Mode

Specifically, the transport characteristics that FpML assumes in order to implement most of its business process definition are defined by:

The delivery of a message is highly assured so the receiving messaging endpoint receives the message at least once.
A sending messaging endpoint must not block the sending or receipt of other messages while waiting for a response to the sent message.
The same applies to the receiving messaging endpoint. It must not block the receipt or processing of other messages while processing the current message.
Messages may arrive in any order at the receiving messaging endpoints. However the message must be delivered before the maximum duration of time permitted.
For each FpML document sent, sixty seconds is the maximum duration of time in within which all its preceding FpML documents must be sent.
Messages are addressed to nought to many receiving messaging endpoints.
The maximum duration of time within which a message must be delivered is sixty seconds.
Only valid FpML documents are delivered; invalid FpML documents are rejected to the sending messaging endpoint.
The messaging transport system must ensure that the FpML document is well-formed, W3C Schema valid, validated against the constraints defined in the validation rules, and validated against the message choreography. It is important to note that the messaging transport system is a role that can be played by either endpoint in a peer to peer setup, or by one or more third party systems. In addition, multiple messaging transport systems can be chained together into a single messaging transport system.
The messaging transport system must ensure that the message is kept available until it is received by the messaging endpoint or until it is expired because it was delivered later than the maximum duration of delivery time. So, it can be queued on the messaging transport system within the maximum delivery time duration, but it can be queued at the destination indefinitely.
The maximum size of a message is 100,000kb (100Mb). Any message exceeding this size must be treated as an invalid message.
Clocks must maintain a maximum (inclusive) variance from UTC less than the Maximum Clock Variation for the supported Message Transport Mode. The maximum clock variation for this mode is ten seconds.

3.2.3.9.4 Bulk Transfer Mode

In some processes such as Portfolio Reconciliation or Position Report, FpML assumes the following transport characteristics:

The delivery of a message is highly assured so the receiving messaging endpoint receives the message at least once.
A sending messaging endpoint must not block the sending or receipt of other messages while waiting for a response to the sent message.
The same applies to the receiving messaging endpoint. It must not block the receipt or processing of other messages while processing the current message.
Messages may arrive in any order at the receiving messaging endpoints. However the message must be delivered before the maximum duration of time permitted.
Messages are addressed to nought to many receiving messaging endpoints.
The maximum duration of time within which a message must be delivered is ten minutes (600 seconds).
Only valid FpML documents are delivered; invalid FpML documents are rejected to the sending messaging endpoint.
The messaging transport system must ensure that the FpML document is well-formed, W3C Schema valid, validated against the constraints defined in the validation rules, and validated against the message choreography. It is important to note that the messaging transport system is a role that can be played by either endpoint in a peer to peer setup, or by one or more third party systems. In addition, multiple messaging transport systems can be chained together into a single messaging transport system.
The messaging transport system must ensure that the message is kept available until it is received by the messaging endpoint or until it is expired because it was delivered later than the maximum duration of delivery time. So, it can be queued on the messaging transport system within the maximum delivery time duration, but it can be queued at the destination indefinitely.
The maximum size of a message is 100,000kb (100Mb). Any message exceeding this size must be treated as an invalid message
Clocks must maintain a maximum (inclusive) variance from UTC less than the Maximum Clock Variation for the supported Message Transport Mode. The maximum clock variation for this mode is five minutes.

3.2.4 Transport Independence

In general, four layers of specification are contained in a XML Standard. A multi-layer approach allows implementers to choose the most appropriate technology for a given situation. It allows development and modifications within one layer without affecting or requiring changes to the others..

From the top down, the four layers are:

3.2.4.1 Business Process

This layer specifies the way in which any business process is defined, such that is understood and executable by people and applications. A business process can be defined as a set of interrelated tasks linked to an activity that spans functional boundaries. Business processes have starting points and ending points, and they are repeatable. Examples of business processes in the derivatives domain are the affirmation process, the confirmation process, and the matching process.

The FpML Specification models business processes in UML sequence diagrams.

3.2.4.2 Document

This layer corresponds to the FpML document definitions. It provides a set of abstractions specific to financial derivatives but also a set of elements which are not context specific (such as “Party” and “Price”).

3.2.4.3 Messaging

The Messaging layer addresses the need to record session and communication settings for message transport in order to enable coordination between parties in a business transaction.

The FpML Schema explicitly models ‘delivery’ related information as part of the message itself. Some transports (i.e. SOAP, ebXML, etc.) allow such information to be placed in the ‘envelope’ that surrounds the message during delivery.

Including a standard header within FpML messages increases consistency by providing a single format for delivering information regardless of the physical transport, ensures that it will be persisted if the message is archived, and allows more flexible use of features such as digital signatures.

3.2.4.4 Transport

The Transport Layer provides a point to point connection so that one server can send messages to another server and they will arrive uncorrupted and in the correct order.

The FpML Message Architecture defines a message structure that is independent of the underlying transport protocol, such as SMTP, File Transfer Protocol (FTP), Standardized Messaging Middleware, HTTP, etc.

3.2.5 Identification of Purpose

The receiver of a message needs to be able to determine the function that the message is invoking. In XML there are three different techniques that can be used for indicating the purpose of a message.

The FpML 5.0 message framework is based on element naming (option 2 - By Element Name). Below is a short explanation of the three techniques:

3.2.5.1 By Namespace (not used by FpML)

The receiver can look at the namespace from which the element definitions have been drawn and determine from it the function requested.

<?xml version="1.0"?>

<FpML version="4-0"
 xmlns="http://www.fpml.org/2002/FpML-4-0-TradeConfirmationRequest">
  <header>
    ... Message header
  </header>
  ... Business data
</FpML>

Using namespaces it would be possible to create a highly extensible framework for FpML but it could lead to documents having to have every FpML element prefixed with a suitable namespace abbreviation although it may be possible to mitigate this by having the 'core' sub-schemas use no namespaces in their definition and take on the namespace of the one they are including into.

There may be further issues with related XML standards such as XPath as the namespace of the same included elements may not be consistent between documents.

3.2.5.2 By Element Name (used by FpML 5.x)

The receiver can look at the name associated with an element within the message (the root and one of the first level children) to determine the function requested.

<?xml version="1.0"?>
<requestConfirmation fpmlVersion="5-0" xmlns="http://www.fpml.org/FpML-5/confirmation">
  <header>
    ... Message header
  </header>
  <trade>
    ... Business data
  </trade>
  ...
</requestConfirmation>

In this model the root element is a global element of a type derived from the base FpML Document type, typically a message type.

3.2.5.3 By Element Type (used by FpML 4.x)

The receiver can look at the type associated with an element within the message (e.g. the root or a child).

<?xml version="1.0"?>
<FpML version="4-0" xmlns="http://www.fpml.org/2002/FpML-4-0" xsi:type="TradeConfirmationRequest">
  <header>
    ... Message header
  </header>
  ... Business data
</FpML>

An XML schema based instance may use type substitution to replace the content model of any element with another providing that the replacement is derived from the original. Given a framework that provides the appropriate extension points any number of new types can be derived within the name or different namespaces as necessary.

In addition through inheritance the message types can be associated with an appropriate message header content model.

3.2.6 General Pattern of Messages

Messages are divided into a series of business processes. For example, consent negotiation (getting permission to do something) is a business process. For each business process, in general the following messages will be available:

process request or notification message – to initiate the process. (In some cases the process may be initiated by a notification message rather than a request message).
process acknowledgment message – to acknowledge that the request or notification was received.
process exception message – to report that a request or notification cannot be processed.
process request/notification retracted message – to withdraw the original request or notification.
possibly, process-specific response messages

In some cases, some of these messages may be intentionally omitted, but in these cases the rationale for omitting the messages will be provided. For example, acknowledgement messages may be omitted where it is expected that all responses will be immediate, and retraction messages may be omitted if there is no need to allow requests to be withdrawn, because the original request would be fulfilled before the retraction could be sent.

For the consent negotiation process, for example, the messages include:

requestConsent – initiating request
consentAcknowledgement - acknowledgement
consentException - exception
requestConsentRetracted – retraction of the request
consentGranted - response
consentRefused – response

3.2.7 Naming Conventions

Messages follow this naming convention:

requestXxx
xxxAcknowledgement
xxxException
requestXxxRetracted
xxx[Status] or xxx[Response]

3.2.8 Acknowledgements

Providing each request with a more immediate and guaranteed response allows a more synchronous style of design, such as this:

Here the requester waits for the response before terminating its execution. This would allows easier specification of timeouts related to request processing although as we shall see later has implications for gathering the results of long running processes, such as matching.

3.2.9 Message correlation

The initiator of a business process should allocate a unique correlation identifier for each process instance it begins and any subsequent message related to the same process should contain the same identifier. A qualified scheme based value ensures that participants cannot accidentally re-use an identifier previous generated by another firm.

For example, when used within a trade execution advice it might appear as follows:

 
                                                ...
<tradeExecutionAdvice>
  <messageHeader>
    
  </messageHeader>
  <isCorrection>false</isCorrection>
  <correlationId correlationIdScheme="http…">BQ/1234 </correlationnId>
  <sequenceNumber>657</sequenceNumber>
  <onBehalfOf>
    <partReference href="PARTYA"/>
  </onBehalfOf>
  <execution>
    <trade>
      … Lots more here
    </trade>
  </execution>
  <party id="PARTYA">…</party>
  <party id="PARTYB">…</party>
</tradeExecutionAdvice>
                                      
                                                ...

Any response or follow up to this message should contain the same 'correlationId' definition. This regime allows us to make some other messaging clarifications, namely:

Every message will have a unique message identifier.
The ‘inReplyTo’ element of a response message (or exception) correlates with the ‘messageId’ of the associated request.
The conversationId has been removed.
Retransmission of a message for technical reasons (e.g. the last transmission of the request was not acknowledged or rejected) does not change the message identifier.
Replication of a message for business reasons (e.g. sending data that has been previously acknowledged) generates a new message identifier.
The response to a retransmitted request message should be identical to the original request. (1)
At the start of a long running process the initiating participant must create a unique one-time identifier for each process instance and distribute it to the other messaging party.
Every subsequent message sent by the requester must contain the process identifier.
Messages may contain reference to other business process instances providing their role is clear and unambiguous (e.g. an order MAY reference a previous quotation).

(1) This allows the transport to respond to retransmissions by sending a copy of the earlier cached response, no business process is necessary. This is a standard technique in ONC RPC and WebServices.

3.2.10 Message sequencing

In a long running operation it is important to process all of the messages in the correct order. Each message’s ‘messageId’ is element is guaranteed to contain a unique value but the order of messages cannot be inferred by comparing two such identifiers.

The characteristics required by FpML’s transport characteristics states that two messages sent simultaneously, or within a short time of each other, may arrive in any order. Since message order cannot be determined from the message identifiers some other information needs to be added to them message to provide this.

In the SWIFT CUG implementation of the contract notification messages the trade version is used to derive the ordering. Whilst this is a workable solution for the CUG it does not solve the problem generally and some messages must artificially increase the contract version number to maintain order even though no change has actually occurred to the underlying contract.

The simplest solution is to define a type for sequence numbers and use it within messages to provide an orderable value.

It is important to note that although sequence numbers should be consistently increasing in value they do not have to form a gapless sequence. (2)

When combined with the unordered delivery transport characteristics a message processing application can be presented with a series of messages in a jumbled order.

An optimistic message processor should attempt to process the messages in the order they are delivered and unwind actions (or raise exceptions) when conflict is detected.
A pessimistic message processor should record the messages but delay their processing for a short period. This provides a time window during which any earlier messages received out of order can be re-sequenced before processing begins.

It is also important to note that sequence numbers must be qualified with respect to the message sender and the responding part may need to produce messages containing them. For example in the matching processes the messages containing the result should reference the same ‘correlationId’ used in the original request but should use a ‘sequenceNumber’ provided by the matcher rather than the requester.

For example the series of messages for a trade confirmation (including a correction) followed by the resulting match might be identified as follows:

(2) There may be messages within the same business process sent to other participants or internal changes to the business object that affect the sequence number.

3.2.11 Correlation ID optionality

Starting from FpML 5.2, the correlation ID is optional in requests. This is intended to more flexibly support a variety of processing models. The original request may omit the correlation ID if the recipient will quickly respond to requests with its own correlation ID. Subsequently requester will need to use the recipient's correlation IDs if it needs to correct or retract a request. The FpML messaging architecture recommends that services support the correlation ID in the original requests, because otherwise requesters cannot correct or retract requests until they receive a reply from the service.

3.2.12 Other topics

3.2.12.1 onBehalfOf

The FpML neutral view principle when combined with some of the notifications for post-trade processes and a common third party such as a custodian results in situations where the third party can not easily tell which side of the trade he is supposed to be processing.

For example, parties A and B negotiate a trade and then send a contract execution notification to their common custodian C. The custodian may be able to figure out which side of the trade to process by means of the message sender’s identity but as a single sender identity might be used by several legally separate trading divisions within the same company group determining the correct party might require extensive organisational reference data. This approach would also fail for internal book-to-book deals where both sides would originate from the same sender.

What is needed is an explicit indication of the party for whom the trade should be processed included in every message. In the case of book-to-book trades this information should use account references to further qualify the party. For example:

 
				<someRequest>
				  <header>
				    … Basic message details
				  </header>
				  …
				  <onBehalfOf>
				    <partyReference href="JPM"/>
				    <accountReference href="PORTFOLIO1"/>
				  </onBehalfOf>
				  … Request specification here
				</someRequest>

3.2.12.2 party roles

The 4.x tradeSide structure has been replaced by a simpler implementation adding a new relatedParty element. The role element within the relatedParty defines the list of roles as code list. This allows to customize the roles easier than using the tradeSide structure.

 
<someRequest>
...
	<partyTradeInformation>
            <partyReference href="party3"/>
            <relatedParty>
               <partyReference href="party4"/>
               <role>orderer</role>
            </relatedParty>
            <relatedParty>
               <partyReference href="party4"/>
               <role>introducer</role>
            </relatedParty>
            <relatedParty>
               <partyReference href="party3"/>
               <role>executor</role>
            </relatedParty>
            <relatedParty>
               <partyReference href="party4"/>
               <role>confirmer</role>
            </relatedParty>
            <relatedParty>
               <partyReference href="party6"/>
               <role>creditor</role>
            </relatedParty>
            <relatedParty>
               <partyReference href="party5"/>
               <role>settler</role>
            </relatedParty>
            <relatedParty>
               <partyReference href="party6"/>
               <role>accountant</role>
            </relatedParty>
	</partyTradeInformation>
...
</someRequest>

3.2.12.3 separation of party and account

Currently accounts are specified within a party definition and the relationship between the two objects depends on the elements present. To simplify the structure and make the relationships clearer the account structure should be moved outside of Party and given a mandatory reference to its beneficiary and an optional reference to its servicer (this is the reverse of the 4.x accounts model).

3.3 Business Processes

3.3.1 FpML 5 Business Processes

Before looking at the current message processes and their associated messages it is worth looking at the overall sequence of business processes for trades.

The first thing to note is that there are two sets of processes; the first set manages the transaction itself during its ‘cradle to grave’ life cycle while the second are repeatable management tasks that may occur several times over the life time of the transaction.

3.3.2 Transaction life cycle

Looking at the states in the life cycle part of the process model there the first thing to note is that there are multiple routes to the creation of trade.

images/messaging/TransactionLifeCycle.png

The original model for FpML (and not actually supported in the specification) is the traditional model of direct inter-dealer negotiation (e.g. by phone, over SwapsWire, etc.) followed by an affirmation of the resulting transaction.

Alternatively trades could be created using a more market based approach in which quotes and orders are communicated through an exchange in which more than one market maker may be offering prices for the same quote or order. The terminology of quote, indications of interest, orders and execution is more closely coupled with this market approach.

In the direct negotiation approach the identities of the participants of fully disclosed and this allows pre-agreed exploitation of other party’s credit rating to obtain better prices (within agreed limits). In the market approach pre-order interactions may be anonymous to guarantee best prices are obtained for all market participants.

Messages related to trade negotiation and affirmation need to be capable of recording that these additional parties are being used but in later trade processing stages such ‘give-up’ trades are decomposed in a set of related back-to-back trades.

images/messaging/TransactionLifeCycle2.png

3.3.3 Overall Messaging Flows

With the advent of new business processes created based on regulatory reform in the OTC derivative trading space, the FpML Business Process Working Group (BPWG) created a set of diagrams to describe how FpML can be used to support the new business lifecycles around OTC derivative trading. Following is an initial version of those diagrams.

images/messaging/BPWG overall OTC flow diagrams.jpg

3.3.4 Generic (Multi-Event) Flows

All the processes described in this section are applied to the following events:

trade
novation
increase
termination
amendment
optionExercise / optionExpiry
deClear
withdrawal

Additional events have been added since version 5.5.

basketChange
corporateAction
indexChange

All events use the same messages to support the processes. The additionalEvent element is an extension point to customize FpML and add additional events.

3.3.4.1 FpML Payload in FIX RFQ Messages

The FpML-FIX Collaboration Working Group has developed a framework to use the FpML product definitions together with FIX. The products scope covers:

Interest Rate Swaps
Credit Default Swaps

The approach consists on using the FpML product representation together with the FIX Security Definition messages. Even though OTC derivatives are not securities, once the product representation has been exchanged between the parites, FIX messages are used to assign it an identifier. The identifier is then used through the entire RFQ and Execution processes withouth the need to exchange the product details anymore.

The FpML product representation used in pre-trade is consistent with the existing representation in other views such as confirmation. The pre-trade product representation is a subset of the legal confirmation representation. Since the FpML is encapsulated within the FIX Security Definitions messages, information regarding quantity/amount and price is defined within the FIX messages so this information is not included in the FpML representation.

Documentation and examples have been developed to illustrate the approach. They are available at:

FpML pre-trade examples are available in the Schema and Examples .zip available in this specification.

3.3.4.2 Quotation

3.3.4.2.1 Request Quote

The 4.x design of the RFQ processes was intended to cover both bilateral and exchange based quotation. The design splits the responsibility for providing quotes (the ‘Market Maker’) from that of distributing them (the ‘Quotation System’). This is an over complication as FpML cannot and should not define how the quotes derived. The new “RequestQuote” type only describes the communication between the requester and provider.

The process of creating a quotation may take time depending on the method (single calculator, exchange model, etc.) The quotation acknowledgement response should establish a unique quotation identifier.

3.3.4.2.2 Request Quote Correction

Request quote message can be corrected by requester, sending a corrected request for quote message with "isCorrection" element set to "true", and a unique quotation identifier and a sequence number to link a prior message.

3.3.4.2.3 Quotation Update

(Andrew’s paper suggests that an established unique quotation identifier is used to correlate a subsequent quotation notification with the request, but the quotation response message is not correctable. How then the corrections/updates work?)

The current model allows quote provider to update his quote, for example if there is a large market movement. The update should be correlated to the original quote by means original quotation reference

3.3.4.2.4 Request Quote Retraction

The request for quote can be retracted by the requester at anytime.

images/messaging/RequestQuoteRetraction.png

3.3.4.3 Ordering

3.3.4.3.1 Order Placement

In the 4.x models, order placement is called 'AcceptQuote' and assumes that order placement is always preceded by a quotation process. In 5.0 model, "PlaceOrder" makes it possible to initiate an order directly without a prior quote and an optional quote reference should be provided to correlate the processes if required.

3.3.4.3.2 Order Placement Update

The Place Order type allows an order requester to correct or update already placed order. The update should be correlated to the original quote by means original quotation reference (a unique quotation identifier and a sequence number to link a prior message) with "isCorrection" element set to "true".

images/messaging/OrderPlacementUpdate.png

3.3.4.3.3 Order Placement Retraction

The placed order can be retracted using Place Order Retracted type and correlated it to the order that is getting retracted.

images/messaging/OrderPlacementRetraction.png

3.3.5 Credit Limit Check Messages

A joint ISDA - FIA working group developed business and technical requirements to support Pre-Execution Clearing Certainty workflows. An FpML subgroup translated the requirements into a new set of messages included in this draft for industry review. The messages are available in the new pretrade view and include:

Request Credit Limit Check - request message
Limit Check Approved - response/acknowledgement message (full approval, partial approval are supported)
Limit Check Refused - response/acknowledgement message
Credit Limit Report (Fuel gauge)
Set Credit Limit
Credit Limit Response
Suspend Credit (Kill Switch) - A kill is the cancelling of all open orders for a given party globally. It also entails cutting off the target party from placing any new orders from the time the kill is processed.
Credit Limit Response (Limit Suspended)
Restore Credit (Unkill) "Un-kill" or "Reinstate" message developed that would let SEFs know when a credit provider is happy for a killed party to begin trading again.
Credit Limit Exception
Order Status Notification
Service Notification (heartbeat: loggin-on/logging-off) - Existing FpML message that allows a service to send a notification message to a user of the service.
- The heartbeat represents to your message counterparty that your application is connected and able to process a kill switch if one is sent – it must be implemented in the application layer rather than the messaging layer. (Note: the application layer sits on top of the messaging layer, so any messaging outage will mean that the application layer is also out. This means that the heartbeat could fail due to a networking issue but that it must be implemented to take the application layer into account as well.)
- Must be a two-way round-trip message i.e. a two-way handshake
- Must be configurable between sender and recipient. e.g., Ability to agree that a system will be down for a planned outage. Number of heartbeats to be missed in order to constitute a failure (see next section below)

Some of the messages (i.e., request limit check, order status notification) may carry a product payload. Note that certain product fields are being considered for the next draft of version 5.5.

Glossary:

Credit Limit or "Limit" - A maximum value, which could be of various types (e.g. initial margin, dv01/cs01, notional, etc.), that an entity is willing to provide to another party with whom they have a contractual relationship for the purposes of clearing.
Credit Model or "Model" - The method jointly employed by the Credit Extender and Limit Checker for a given Credit User through which the credit value of a trade is verified to be within the credit limit prior to the placement of an order and the execution of a trade. The FIA/ISDA group has currently defined 3 Pre-Execution models (Push, Ping, Plus One)
Credit Extender - An entity that provides credit to another party with whom they have a contractual relationship for the purposes of facilitating clearing of that party’s trades. Examples include: FCMs who provide credit to end users, or CCPs who provide credit to FCMs.
Credit User - An entity that receives credit from a credit extender and leverages that credit to clear trades intraday.
- Asset Manager with a limit at an FCM
- FCMs with limits at a CCP
Limit Checker - An entity that employs a systematic method in order to determine whether the credit value of a swap executed by a credit user is within the acceptable maximum credit value provided by a credit extender.
- FCMs checking their client’s limit utilization
- CCPs checking their Clearing Member’s limit utilization
- CCPs checking an FCM’s client’s limit utilization on the FCM’s behalf
- Credit Hub check an FCM’s client’s limit utilization on the FCM’s behalf
- etc...
Velocity - Velocity is the time interval for which the limit applies. For instance one may set a limit which says $100M per 10 minutes. The velocity of the $100MM is 10 minutes.
Clip Size - The clip size is the amount (or clip) threshold under the velocity limit. So using the prior example the clip size is $100M the velocity of the clip is 10 Minutes.

3.3.6 Service Notification

There are service notification messages that allow a service to report information on status and other alerts to users. Supported variations include:

status - allows the service to indicate whether it is available or not as a whole (or other overall statuses).
processingStatus - allows the service to report information about the status of processing activities, for example end of day processing, netting processes, etc. There are fields that allow the processing cycle to be identified as well as the specific processing event.
advisory - allows the service to provide advance notice of changes to the service, for example related to availability, rules, product coverage, etc. Advisories may be qualified with a time range when they is applicable, and may be categorized (for example into advailability, rules, products, etc.) to assist recipients to know how to process them.

Previous	Top of Section	Next