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.
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.
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.
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.
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.
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.
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.
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
Messages follow this naming convention:
-
requestXxx
-
xxxAcknowledgement
-
xxxException
-
requestXxxRetracted
-
xxx[Status] or xxx[Response]
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.
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.
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.
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.
In FpML 5 most workflows are designed to work consistently for a number of events, including new trades and post-trade events such as novations, amendments, and terminations. In addition, the process model is designed to be extensible by allowing implementations to substitute in their own events into the FpML messaging framework.
|
|
|
3.2.13.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.13.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.13.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).
|
|
|
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.
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.
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.
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.
|
|
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 Execution Notification Flow
3.3.4.1.1 Execution Notification
An execution should correlate with the order from which it is derived.
|
|
3.3.4.1.2 Execution Notification Correction
The execution notification may contain mistakes. The ExecutionNotification type allows corrections (provided it is still possible to do so), by sending a corrected execution notification correlated to a prior notification with "isCorrection" element set to "true".
|
|
3.3.4.1.3 Execution Retraction
The execution can be retracted (provided it is still possible to do so) by correlating execution retracted message to the execution notification.
|
|
3.3.4.2 Execution Advice Flow
The successful execution of a trade or post-trade event (novation, termination, etc.) may need to be distributed to other parties involved in the trade processing and settlement such as custodians. The execution notification messages should be used for communication between investment managers and custodians. They replace the 4.x Contract Notification messages.
3.3.4.2.1 Execution Advice
Sending the execution advice message should create a unique notification identifier for future correlation.
3.3.4.2.2 Execution Advice Correction
The trade execution advice may contain mistakes which can be corrected (provided it is still possible to do so) by sending the correct trade execution advice message correlated to a prior execution advice message with "isCorrection" element set to "true".
3.3.4.2.3 Execution Advice Retraction
The execution may have been sent in error so it can be retracted by sending execution advice retracted message.
3.3.4.3 Trade Change Advice Flow
The trade change advice message describes an external event that is NOT negotiated between the contract parties but affects the economic terms of the contract (e.g. a credit event on a CDS Index constituent entity) and needs to be distributed to other parties involved.
3.3.4.3.1 Trade Change Advice
A trade change advice message provides the recipient with the terms for economic changes in the indicated contract resulting from a market event (e.g. index factor information when credit events occur on index constituents).
3.3.4.3.2 Trade Change Advice Correction
The trade change advice may contain mistakes which can be corrected by sending the correct trade change advice message correlated to a prior trade change advice message with "isCorrection" element set to "true".
The trade change advice message should not be used to correct a prior trade execution advice message.
3.3.4.3.3 Trade Change Advice Retraction
Trade change advice retracted message defines the structure for a message retracting a prior change advice.
3.3.4.4 Trade Reference Information Update Flow
The trade reference information update process allows a party to provide updated identification information (such as trade IDs) for a trade that is maintained by another party.
3.3.4.4.1 Trade Reference Information Update
The trade reference information update request allows a party to provide updated identification information (such as trade IDs).
|
|
|
3.3.4.4.2 Trade Reference Information Update Correction
The trade reference information update request may contain mistakes which can be corrected by sending the correct trade information update request message correlated to a prior trade information update request message with "isCorrection" element set to "true".
The trade reference information update request message should not be used to correct a prior trade execution advice message.
3.3.4.4.3 Trade Reference Information Update Retraction
Trade reference information update retracted message defines the structure for a message retracting a prior information update request.
|
|
|
3.3.4.5 Consent Negotiation Flow
3.3.4.5.1 Purpose
The "Consent" process is used when one party needs to obtain consent from another party before peforming some action, such as novating or clearing a trade. The Consent process can be used for any such process, although most of the documentation will discuss consent required for specific processes such as novating a trade.
3.3.4.5.2 Trade Novation
The 4.x model for trade novation was based on having all the participants communicate directly with each other. This is overly complex and should be changed in favor of a centralized service provider model.
The first stage in a novation is consent gathering. The idea is to get all the participants to agree that a novation can be performed prior to actually attempting it. This was to address an issue raised by an ISDA Ops committee.
From the point of view of the transferor the consent process executes as follows:
The transferor sends the request to the novation coordinator who sends it on to the other participants.
When responses have been received from the other participants the collective decision can be reported to the transferor.
The process for the transferee and remaining parties is similar. First they must decide whether to accept the novation or not.
As the decision process may take time the initial request should be followed by a subsequent round of response messaging.
There are no cancellation messages associated with the consent gathering process, but the process is benign and creates no financial commitments.
To keep all participants synchronized, request consent messages can be corrected by requester, sending a corrected request consent message with "isCorrection" indicator set to "true", and a unique correlation identifier and a sequence number to link a prior message.
If the consent is no longer required, the requester can retract a request consent message.
3.3.4.5.3 Clearing
When a trade is submitted for clearing, it may be that the clearing service must obtain consent from a clearing firm prior to clearing the trade. In this case, the consent messages may be used to request this consent.
For clearing consent, the overall flow is typically as follows:
- SEF (or other source of trades) submits trade to clearing platform using the "requestClearing" message.
- Clearing platform checks policies for clearing the trade to determine if the trade can be cleared without seeking consent from the clearing member firm. (This may depend, for example, on the size or type of the trade, and/or limits and utilization.)
- If necessary, clearing platform requests consent of one or both clearing firms involved in the trade using the "requestConsent" message. The requestConsent message can include information about the trade, include calculated "quote" values, such as the NPV or DV01, to assist the recipient decide whether to consent to the trade.
- Clearing member firm grants consent using the "consentGranted" message, or refuses consent using the "consentRefused" message. The "consentRefused" message may include a reason that the consent was refused.
- If consent was granted, the clearing platform clears the trade and returns the result with the "clearingConfirmed" message.
- If consent was refused, the clearing platform returns the result to the submitter with the "clearingRefused" message.
The case where consent is refused is similar except that the responses are "consentRefused" followed by "clearingRefused", as shown below.
If there is a technical problem with the consent request (e.g. not implemented, system down, badly formatted request), the "consentException" message is used. This messages indicate to the recipient that there is a technical issue that may require investigation. Normally it would be the responsibility of the technical staff to investigate and resolve this before any further processing would occur.
3.3.4.6 Confirmation
The standard confirmation process is supported by FpML. The following messages are used to support it:
- requestConfirmation
- requestConfirmationRetracted
- confirmationAcknowledgement
- confirmationException
- confirmationStatus
- confirmationAgreed
- confirmationDisputed
3.3.4.6.1 Message Diagrams
3.3.4.6.1.1 requestConfirmation
The confirmation process starts with the requestConfirmation message. The message may be used to request the confirmation of a new trade or any other event supported by FpML such as novation, terminations, amendments, etc.
|
|
|
3.3.4.6.1.2 requestConfirmationRetracted
A requestConfirmation message may be cancelled using the requestConfirmationRetracted message.
|
|
|
3.3.4.6.1.3 confirmationAcknowledgement
A business acknowledgement message to indicate that the previously sent message was sucessfully processed.
|
|
|
3.3.4.6.1.4 confirmationException
A message sent to inform another system that some exception has been detected.
|
|
|
3.3.4.6.1.5 confirmationStatus
The confirmationStatus message provides the status of the matching process: matched, mismatched, unmatched, or alleged. It may also provide the best fit trade(s) or event(s) as result of the matching process.
|
|
|
3.3.4.6.1.6 confirmationAgreed
The confirmationAgreed message is sent when the matching process returns a proposed match (trade or event) and the Confirmation Requester agrees with it.
|
|
|
3.3.4.6.1.7 confirmationDisputed
The confirmationDisputed message is sent when the matching process returns a proposed match (trade or event) and the Confirmation Requester disputes it.
|
|
|
3.3.4.6.2 Scenarios
The following scenarios are used to describe the message exchanges:
3.3.4.6.2.1 Normal Operation
The successful confirmation process involves requesting the confirmation from the Confirmation Requester. The Confirmation Provider sends an acknowledgement message immediately.
The Confirmation Provider is then in charge of performing the matching process and sends back a confirmationStatus message with the status of the matching process: matched, mismatched, unmatched, or alleged. The Confirmation Provider sends then an acknowledgement message immediately.
If the Confirmation Requester is ok with the status, it sends a confirmationAgreed message and the Confirmation Provider sends back and acknowledgment to finish the process.
3.3.4.6.2.2 Exception
If there is a problem with the the confirmationRequest, the Confirmation Provider sends back a confirmationException message. The message includes the reason of the problem.
3.3.4.6.2.3 Correction Possible
The requestConfirmation may contain mistakes which can be corrected by sending the correct requestConfirmation message correlated to a prior requestConfirmation message with "isCorrection" element set to "true".
3.3.4.6.2.4 Correction Not Possible
In some situations the message cannot be corrected and the Confirmation Provider sends back an exception message.
3.3.4.6.2.5 Retraction Possible
The requestConfirmationRetracted message defines the structure for a message retracting a prior requestConfirmation.
3.3.4.6.2.6 Retraction Not Possible
In some situations the message cannot be retracted and the Confirmation Provider sends back an exception message.
3.3.4.7 Clearing
The standard clearing process is supported by FpML. The following messages are used to support it:
- requestClearing
- requestClearingRetracted
- clearingAcknowledgement
- clearingException
- clearingConfirmed
- clearingRefused
- clearingStatus
- requestClearing (deClear)
3.3.4.7.1 Scenarios
The following scenarios are used to describe the message exchanges:
3.3.4.7.1.1 Normal Operation
The successful clearing process involves requesting the clearing from the Clearing Requester. The Clearing Provider sends an acknowledgement message immediately.
The Clearing Provider is then in charge of deciding whether the clearing is confirmed or refused.
If the clearing is confirmed, the Clearing Provider sends a clearingConfirmed message. This may include either a "trade" payload describing the trade that was cleared, or a "clearing" event which includes details of the submitted trade and the resulting two cleared trades. (The first type may be more appropriate to send to a clearing member firm; the second to an execution facility). Currently, the "clearing" structure is suitable for representing trades that have been allocated in advance by the requester, e.g. SEF, and divided into separate requests for each allocation. In these cases, each clearing request will result in a pair of trades, one for each side. In cases where the trade is allocated by the clearing service, one trade may result in multiple trades after allocation. The current "clearing" event representation cannot represent this, so currently a separate message must be sent to confirm the clearing of each allocation trade. A future version of FpML may extend this structure to support this scenario in a single message, however some clearing services use a sequence of several existing FpML messages to support this scenario.
On the other hand, if the clearing is refused, the Clearing Provider sends a clearingRefused message.
3.3.4.7.1.2 Exception
If there is a problem with the the clearingRequest, the Clearing Provider sends back a clearingException message. The message includes the reason of the problem.
3.3.4.7.1.3 Correction Possible
The requestClearing may contain mistakes which can be corrected by sending the correct requestClearing message correlated to a prior requestClearing message with "isCorrection" element set to "true".
3.3.4.7.1.4 Correction Not Possible
In some situations the message cannot be corrected and the Clearing Provider sends back an exception message.
3.3.4.7.1.5 Retraction Possible
The requestClearingRetracted message defines the structure for a message retracting a prior requestClearing.
3.3.4.7.1.6 Retraction Not Possible
In some situations the message cannot be retracted and the Clearing Provider sends back an exception message.
3.3.4.7.1.7 Clearing Status Notification (clearingStatus)
The clearingStatus message is to allow the flexibility to support a variety of clearing operational models with the existing FpML clearing business process. The message allows events from the clearing lifecycle to be notified to parties relevant in the process (such as clearing members or intermediary parties).
The process flow shows an example of how the clearingStatus message could be used in a request for clearing process. In this example a status of Pending is returned to the clearing requester after the request is received, which notifies them that the request is pending a particular process or validation in the CCP. In this example it is assumed that the operational model requires such a notification to be made to manage the expectation of the requester.
The example also shows a later clearingStatus message being sent to the original clearing requester (we could rename this clearing member) that shows that the cleared trade is now settled. This for example could be required in an operating model where the CCP is responsible for initiating the settlement process.
The content of the status message and usage is by convention of the operating model of the clearing service. A standard set of statuses can be provided to promote consistency. It is key however to allow flexibility for the CCP to have a status of their choosing to accommodate their specific conventions. Some standard statuses have been defined in a clearing-status-code coding scheme:
- Received: The request for a trade to be cleared has been received by the CCP.
- Accepted: The trade has passed CCP eligibility checks and is accepted as a request for clearing.
- Rejected: The trade has failed CCP eligibility checks and is rejected as a request for clearing.
- Pending: The trade is pending an internal CCP process before registration can be confirmed.
- Registered: The trade is registered with the CCP and novation has taken place.
- Cancelled: The trade has been cancelled.
- Decleared: The trade has been rescinded from clearing with the CCP.
- Settled: The trade has been settled (applicable where the CCP initiates settlement).
- Expired: The option trade has been expired (applicable where the CCP is the option executor).
- Exercised: The option trade has been expired (applicable where the CCP is the option executor).
Note that the states which explicitly name a status which FpML implicitly communicates with a message type have been included for completeness but are probably not required, for example, 'received' status is implicit in the clearingAcknowledgement message.
3.3.4.7.1.8 Request to de-clear
the requestClearing message used with a deClear event allows for a trade to be removed from clearing - or ‘de-cleared’
the requestClearing message extends a CorrectableRequestMessageMediated type that allows the inclusion of up to two onBehalfOf elements. This allows the requestClearing message to be sent on behalf of the two original trade counterparties.
There are a large number of variants for the usage of such a de-clear operation, depending on who is sending the request; whether this request is direct or via an intermediary such as a matcher and also on the granularity of the request (both novated trade sides or just one trade side).
The actual process used and trade identification employed would be dependent on the operating model. A couple of example usage scenarios are described below.
|
|
The above process flow shows an example of an individual de-clear request (only the happy path is shown). The requester issues a requestClearing message to the CCP containing a de-clear event model. The identity of the trade could be a particular novated trade side since this is a unilateral view from one party. The resulting clearingAcknowledgement and clearingConfirmed messages are as per the existing FpML clearing process. This scenario may be used were the requester sends a de-clear request directly to the CCP independent of a corresponding request from the other trading party. The model is allowing but not advocating that a de-clear can be carried out just on one particular novated trade side.
The following process flow shows a second example (and generally the most likely) where the de-clear requests are matched before being delivered to the CCP. In this example the identification of the trade to be de-cleared would probably be that original trade IDs from the de-clear requesters to the matcher and a clearingID between the matcher and the CCP which encompasses both novated trades.
|
|
3.3.4.7.1.9 Request Clearing Eligibility Messages
the requestClearingEligibility message is used to request the mandatory clearing status of a trade with respect to regulatory bodies.
|
|
|
The clearingEligibility message shows the mandatory clearing status of a trade with respect to different regulatory bodies.
|
|
|
- supervisoryBody - The regulator or other supervisory body to which the clearing requirements apply.
- mandatorilyClearable - Whether the particular trade type in question is required by this regulator to be cleared.
Standard Exception and Acknowledgement messages are available to complete the set of messages.
3.3.4.7.1.10 Compression Activity
The compressionActivity structure is available in select messages (e.g., clearingConfirmed and requestConsent) to provide context information about compressions affecting the trade/event. It relates trades together such as trades combined as a result of netting or portfolio compression.
|
|
|
The structure was developed as an alternative to the linkId mechanism available as part of the PartyTradeIdentifier. Some clearing organizations have requirements to provide references to the other trades that were part of the same netting. The linkId is a link identifier allowing the trade to be associated with other related trades, however, it does not allow any qualification on the related trades (e.g., whether a replacement trade or a set of originating trades).
The structure includes the following optional elements:
- the compressionType identifies the type of trade amalgamation such as netting or portfolio compression
- one or more occurences of the originatingTradeId can be used to specify references to the trades terminated as a result of compression
- replacementTradeId specifies reference to the replacement trade
From a business perspective, there are two scenarios:
- Full Netting - The net position is zero. The clearing service would send a message for each terminated trade. Each termination confirmation message, unique to each trade, (e.g., clearingConfirmed message with a termination event) will have references to all the trades that were terminated as a result of netting.
- Partial Netting - occurs when the swaps eligible for netting do not fully offset each other and there is “remaining” notional. The clearing service would send a message for each terminated trade – with each termination containing references to the trades that are part of the same netting and a reference to the replacement trade that is created with the remaining notional.
The new trade would have references to all the trades that were terminated (i.e., a set of originatingTradeId) and a special reference to the replacement trade (replacementTradeId)
For a netting activity, the following structure might be specified:
<compressionActivity>
<compressionType>Netting</compressionType>
<replacementTradeId tradeIdScheme="http://www.abc.com/clearing-id">CL000003</replacementTradeId>
<originatingTradeId tradeIdScheme="http://www.abc.com/clearing-id">CL000001</originatingTradeId>
<originatingTradeId tradeIdScheme="http://www.abc.com/clearing-id">CL000002</originatingTradeId>
</compressionActivity>
3.3.4.8 Allocation
The standard allocation process is supported by FpML. The following messages are used to support it:
- requestAllocation
- requestAllocationRetracted
- allocationAcknowledgement
- allocationException
- allocationApproved
- allocationRefused
3.3.4.8.1 Scenarios
The following scenarios are used to describe the message exchanges:
3.3.4.8.1.1 Normal Operation
The successful allocation process involves requesting the allocation from the Allocation Requester. The Allocation Provider sends an acknowledgement message immediately.
The Allocation Provider is then in charge of deciding whether the allocation is approved or refused.
If the allocation is approved, the Allocation Provider sends an allocationApproved message. On the other hand, if the allocation is refused, it sends and allocationRefused message.
3.3.4.8.1.2 Exception
If there is a problem with the the allocationRequest, the Allocation Provider sends back an allocationException message. The message includes the reason of the problem.
3.3.4.8.1.3 Correction Possible
The requestAllocation may contain mistakes which can be corrected by sending the correct requestAllocation message correlated to a prior requestAllocation message with "isCorrection" element set to "true".
3.3.4.8.1.4 Correction Not Possible
In some situations the message cannot be corrected and the Allocation Provider sends back an exception message.
3.3.4.8.1.5 Retraction Possible
The requestAllocationRetracted message defines the structure for a message retracting a prior requestAllocation.
3.3.4.8.1.6 Retraction Not Possible
In some situations the message cannot be retracted and the Allocation Provider sends back an exception message.
3.3.5.1 Novation
A novation is a transaction in which a ‘transferor’ transfers to a ‘transferee’, with the consent of the ‘remaining party’, all of its rights and obligations under the contract in respect to the novated amount. The effect of the agreement is that for the ‘novated amount’ (i.e. all or part of the outstanding notional amount), the old transaction between the transferor and the remaining party is terminated, and a new transaction is executed between the remaining party and the transferee with economic terms identical to those of the old transaction.
A three-way novation is between a transferee, a transferor and a remaining party. The typical four-way novation is between a transferee, a transferor, a remaining party and a related second remaining party (where remaining party had the deal with the transferor, and the second remaining party is a related company to the remaining party who assumes the deal with the transferee).
|
|
|
The required ‘transferor’, ‘transferee’, and ‘remainingParty’ elements, with the optional ‘otherRemainingParty’ element, indicate the roles in the transaction by providing references to the ‘party’ elements.
The optional ‘otherRemainingParty’ element is not applicable in a three-way novation and should be omitted. In a four-way novation the party referenced is Transferee 2. Transferee 2 means a party which accepts by way of novation the rights, liabilities, duties and obligations of Transferor 2. ISDA 2004 Novation Term: Transferee 2 (four-way novation).
The ‘oldTransaction’ indicates the original trade between the transferor and the remaining party. This can alternately be represented by the ‘oldTransactionReference’. The ‘newTransaction’ indicates the new trade between the transferor and the remaining party (for a 3-way novation) or other remaining party (for a 4-way novation). This can alternately be represented by 'newTransactionReference'.
The ‘novationDate' is the date on which the rights, obligations etc. transfer between the parties. The 'novationTradeDate' is the date on which the parties agree that they will novate. If a 'novationTradeDate' is not specified, the 'novationTradeDate' will be deemed to be the 'novationDate'. The ‘novatedAmount’ (or ‘novatedNumberOfOptions’) by validation rule must be of the same currency and equal to or less than the appropriate notional amount in the product element within the ‘oldTransaction’ between the transferor and the remaining party.
The 'fullFirstCalculationPeriod’ is of type boolean. If its value is 'true', ‘fullFirstCalculationPeriod’ has the implicit value of “applicable” as detailed in the ISDA novation agreement. On the other hand, if its value is 'false', it has the implicit value of "inapplicable".
The 'firstPeriodStartDate' with respect to the Transferee and Remaining Party is included in the Novations message to be able to make sense of the “new transaction” without requiring reference back to the “old transaction”. The 'href' attribute references the relevant party that is making the payments
The 'nonReliance' element corresponds to the non-Reliance section in the 2004 ISDA Novation Definitions, section 2.1 (c) (i). The element appears in the instance document when non-Reliance is applicable
The 'creditDerivativesNotices' element should be specified if one or more of either a Credit Event Notice, Notice of Publicly Available Information, Notice of Physical Settlement or Notice of Intended Physical Settlement, as applicable, has been delivered by or to the Transferor or the Remaining Party. The type of notice or notices that have been delivered should be indicated by setting the relevant boolean element value(s) to true.
The absence of the 'creditDerivativesNotices' element means that no Credit Event Notice, Notice of Publicly Available Information, Notice of Physical Settlement or Notice of Intended Physical Settlement, as applicable, has been delivered by or to the Transferor or the Remaining Party.
If the receiving party agrees with the novation then they should respond with a ‘NovationConsentGranted’ message. The Transferor or the Transferee may include the details of a payment representing the market value of the transaction.
Since the Novation transaction itself is governed by one or more ISDA contractual definitions and supplements these are specified within the Novation structure with the following two elements: 'contractualDefinitions' and 'contractualSupplements'.
For example, for an IRS novation this will typically reference the 2004 ISDA Novation Definitions and the 2000 ISDA Definitions. For Credit Derivatives it references the 2004 ISDA Novation Definitions, the 2003 ISDA Credit Derivatives Definitions and the May Supplement. So for interest rate products, the following values might be specified:
<novation>
...
<contractualDefinitions>ISDA2004Novation</contractualDefinitions>
<contractualDefinitions>ISDA2000</contractualDefinitions>
...
</novation>
And for credit derivatives, the following values might be specified:
<novation>
...
<contractualDefinitions>ISDA2004Novation</contractualDefinitions>
<contractualDefinitions>ISDA2003Credit</contractualDefinitions>
<contractualSupplement>ISDA2003CreditMay2003</contractualSupplement>
...
</novation>
3.3.5.2 increase
The Increase representation in FpML is used for increasing the notional amount of a trade.
|
|
|
The tradeIdentifier is used to reference the previously confirmed trade. The agreementDate is the date on which the parties enter into the increase transaction. The effectiveDate is the date on which the increase becomes effective.
A payment for the right of increase may occur.
Depending on the type of product, the amount of the increase is specified in the changeInNotionalAmount or changeInNumberOfOptions elements. Similarly, the outstanding amount of the trade after the increase is specified in the outstandingNotionalAmount or outstandingNumberOfOptions elements.
3.3.5.3 Termination
The Termination representation in FpML is used for terminating partially or fully a trade. The same business content is used for both full and partial terminations.
|
|
|
The tradeIdentifier is used to reference the previously confirmed trade. The agreementDate is the date on which the parties enter into the termination transaction. The effectiveDate is the date on which the termination becomes effective.
A payment for the right of termination may occur.
Depending on the type of product, the amount of the termination is specified in the changeInNotionalAmount or changeInNumberOfOptions elements. Similarly, the outstanding amount of the trade after the termination is specified in the outstandingNotionalAmount or outstandingNumberOfOptions elements. For a full termination, the outstanding amount will be set to 0.
3.3.5.4 amendment
The Amendment representation in FpML is used for amending the terms of a trade.
|
|
|
The trade element is used to represent the details of the amended trade. (Note that the use of tradeIdentifier is insufficient for providing the amended trade details and is not allowed.) The agreementDate is the date on which the parties enter into the amendment transaction. The effectiveDate is the date on which the amendment becomes effective.
A payment for the right of amendment may occur.
3.3.5.5 Allocation
Allocations are the division of a single market trade across two or more investors/funds.
3.3.5.5.1 Linking Mechanism
This section describes the way of representing allocations in FpML. This is done using the existing FpML trade structure in order to represent both, the block and the allocated trades.
3.3.5.5.1.1 Design Assumptions
- To identify block and allocated trades inside the current FpML trade structure.
- The allocated trades may be not known upfront so the solution covers two situations:
- The system knows upfront the block and the allocated trades.
- The system knows the block trade but not the allocated trades.
- To allow for 2-way linkage, this means to:
- Indicate the block trade and the id for the subsequent allocated trades.
- Indicate in an allocated trade the id for the original block trade.
- The tradeId element for any kind of trades (normal, block, allocated) should be kept at the same location as currently stands in the FpML trade structure.
3.3.5.5.1.2 Implementation
The implementation uses the PartyTradeIdentifier type. Depending whether the trade is a block or an allocated trade, the allocationTradeId and the blockTradeId elements would be filled out.
|
|
|
3.3.5.5.1.3 Examples
This is an analysis of the different situations:
3.3.5.5.1.3.1 Normal Trade
...
<tradeHeader>
<partyTradeIdentifier>
<partyReference href=”BGI”/>
<tradeId tradeIdScheme=”http://abc.com”>ABC100</tradeId>
</partyTradeIdentifier>
</tradeHeader>
...
3.3.5.5.1.3.2 Normal trade that is subsequently split/allocated into two trades
It is allocated into two trades ABC101 and ABC102. The block trade includes links (allocationTradeId) to the allocated trades.
...
<tradeHeader>
<partyTradeIdentifier>
<partyReference href=”BGI”/>
<tradeId tradeIdScheme=”http://abc.com”>ABC100</tradeId>
<allocationTradeId>
<partyReference href=”Fund1”/>
<tradeId tradeIdScheme=”http://abc.com”>ABC101</tradeId>
</allocationTradeId>
<allocationTradeId>
<partyReference href=”Fund2”/>
<tradeId tradeIdScheme=”http://abc.com”>ABC102</tradeId>
</allocationTradeId>
</partyTradeIdentifier>
</tradeHeader>
...
3.3.5.5.1.3.3 Each of the resulting allocated trades
Each of the resulting allocated trades is a separate FpML trade element. Each one of the trades is identified as allocated trade with the xsi:type="AllocationTradeIdentifier".
Allocated trade ABC101:
...
<tradeHeader>
<partyTradeIdentifier>
<partyReference href=”Fund1”/>
<tradeId tradeIdScheme=”http://abc.com”>ABC101</tradeId>
<blockTradeId>
<partyReference href=”BGI”/>
<tradeId tradeIdScheme=”http://abc.com”>ABC100</tradeId>
</blockTradeId>
</partyTradeIdentifier>
</tradeHeader>
...
Allocated trade ABC102:
...
<tradeHeader>
<partyTradeIdentifier>
<partyReference href=”Fund2”/>
<tradeId tradeIdScheme=”http://abc.com”>ABC102</tradeId>
<blockTradeId>
<partyReference href=”BGI”/>
<tradeId tradeIdScheme=”http://abc.com”>ABC100</tradeId>
</blockTradeId>
</partyTradeIdentifier>
</tradeHeader>
...
3.3.5.5.1.4 N-Level Allocations
The PartyTradeIdentifier type supports the representation of N-level allocations in FpML. This basically means the ability to allocate a block trade to multiple allocation trades, and then allocate these in turn to other allocation trades (and so on if desired).
The support of N-Level Allocations is done including the allocationTradeId element and the blockTradeId element at the same time.
3.3.5.5.2 Short Form Representation of Allocations
This section describes a representation of allocation trades with the following features:
- Supports a "short-form" allocation representation, in which the key block economics are stated once, and the allocation data is contained in a terse matrix.
- Supports credit and collateral requirements, and approval management (per subaccount).
- Supports fees that must be allocated ("block" fees) and fees that should not be allocated ("third party" fees).
There are two basic design principles:
- The first principle is that models should always provide the option to correlate by identifier or by the entire trade but never a partial trade that requires matching.
- The second principle is that the "short-form" representation of allocations should be possible in post-trade messages.
The agreement of the Messaging Working Group was to place this "short-form" representation within the trade structure in order to use this form of representation across the different post-trade messages.
|
|
|
3.3.5.6 Option Exercise / Expiry
Option exercise and expiry process is supported by FpML. The following messages are used to support the process:
- optionExpirationNotification
- placeOrder
- executionNotification
- requestConfirmation
- executionAdvice
- executionException
- maturityNotification
3.3.5.6.1 Scenarios
The following scenarios are used to describe the message exchanges:
Generic option exercise/expiry process
Basic option exercise/expiry process
Cleared option exercise/expiry process
3.3.5.6.2 Modeling
OptionExercise
|
|
|
The optionExercise model supports partial exercise (specify the number of options or amount to exercise), full exercise (use fullExercise flag), as well as the option to request options not to be exercised (use expiry flag)
- expiry - boolean used to request options not to be exercised
- fullExercise - boolean used to request exercise of all the options
- partial exercise
- exerciseInNotionalAmount - Specifies the fixed amount by which the option should be exercised expressed as notional amount.
- outstandingNotionalAmount - Specifies the Notional amount after the Change
- exerciseInNumberOfOptions - Specifies the fixed amount by which the option should be exercised expressed as number of options.
- outstandingNumberOfOptions - Specifies the Number of Options after the Change.
- exerciseInNumberOfUnits - Specifies the fixed amount by which the option should be exercised express as number of units.
- outstandingNumberOfUnits - Specifies the Number of Units
additional elements are needed:
- optionBuyer
- optionSeller
- tradeIdentifier
- exerciseDate
- exerciseProcedure - specifies whether it is manual exercise or automatic exercise
- settlementType - specifies cash of physical setttlement
- payment
OptionExpiry
The OptionExpiry event is used to notify a party that options are expiring.
|
|
|
- tradeIdentifier or originalTrade (full trade details)
- date
- time
- exerciseProcedure
3.3.5.6.3 Application - Affirmation Platforms
The set of Option expiration notification messages can be sent to affirmation platforms that may not have all the trade details. This will enable affirmation platforms to provide the exercise and assignment service to clearing firms. The following diagram illustrates the workflow for interating with affirmation platforms.
Sample Message Flow
- DCO sends an optionExpirationNotification to the platform of the Counterparty with the Long position
- The counterparty using the affirmation platform submits an exercise notice (requestExecution with an optionExercise event) to DCO
- DCO runs the assignment process
- An executionNotification is sent back to the platform with an event of optionExercise.
- DCO sends to the Clearing Member of the long position
- clearingConfirmed (Terminated) for the Swaption
- clearingConfirmed (New Trade) for the Swap
- DCO sends to the Clearing Member of the short position
- clearingConfirmed (Terminated) for the Swaption
- clearingConfirmed (New Trade) for the Swap
3.3.5.6.4 Order Placement
placeOrder message is used by the party that has the exercise decision role to request options to be exercised (or not). "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.5.7 Clearing / deClear
The "clearing" and "deClear" events are provided to support clearing processes.
3.3.5.7.1 Clearing
The "clearing" event allows full trade/event details or summary information to be reported about both the original submission (the submitted trade) and the two resulting cleared trades.
Currently, the "clearing" structure is suitable for representing trades that have been allocated in advance by the requester, e.g. SEF, and divided into separate requests for each allocation. In these cases, each clearing request will result in a pair of trades, one for each side. In cases where the trade is allocated by the clearing service, one trade may result in multiple trades after allocation. The current "clearing" event representation cannot represent this, so currently a separate message must be sent to confirm the clearing of each allocation trade. A future version of FpML may extend this structure to support this scenario in a single message, however some clearing services use a sequence of several existing FpML messages to support this scenario.
3.3.5.7.2 DeClear
The "deClear" event allows a firm to request that a trade be removed from clearing, or a clearing service to request consent for this, or to report that is has been done.
The trade model has been enhanced with an approval structure (approvals) to support electronic execution in which the trades are pre-authorized (“pre-screened”) to be cleared by the credit granting firm.
There have been industry discussions between several FCMs and clearing firms on how FCM acceptance of pre-trade screened orders could be automated. Screened orders would be given a credit approval token.
Background - CFTC Rule 1.73 requires FCM to establish risk-based limits in each Client account, and screen orders for compliance with these limits. In the current trade clearing workflow CCPs present trades to FCM for acceptance. This, in essence, is yet another screening operation. Since the orders were screened before the resulting trades were sent for clearing there is no reason to reject the trades. FCMs seek to prevent rejecting a trade which was the outcome of an approved order. In other words, FCMs would like the ability to have auto-acceptance of trades that result from properly screened orders, while being able to possibly reject trades that weren’t screened.”
In FpML, the credit approval token is modeled using a generic approval structure that could be used for (but not limited to) credit limit checking. Other uses include compliance approvals or for market risk limit approvals, (most likely internal to a firm).
The trade has been enhanced with an apprvoal structure (approvals) which is a container for approval states in the workflow.
The approval element represents a specific approval state in the workflow. and contains the following elements:
- type - The type of approval (e.g. "Credit").
- status - The current state of approval (.e.g preapproved, pending approval, etc.)
- approver - The full name or identifiying ID of the relevant approver.
- approvingPartyReference - A pointer style reference to a party defined elsewhere in the document. The party referenced has approved the specified item (e.g. trade or allocation).
- approvalId - An identifer for a specific appoval, to allow the approval to be identified and tracked.
The following examples illustrate the use of the approval structure.
- confirmation/business-processes/clearing/msg-ex07.xml (requestClearing) - This example shows a request for clearing from a SEF to a clearing house
- confirmation/business-processes/clearing/msg-ex10.xml (clearingConfirmed) - This example shows a clearing confirmation to a SEF showing the original trade and information about the cleared trades that were created.
Additional related enhancements are deferred to a later version. This may include, for instance, the ability to update approvals independent of trade information, or allocation-specific approval processes.
The clearing eligibility messages are used to check the clearing eligibility of a trade at a clearing house.
- A single trade can be submitted for analysis
- Returns the clearing service eligibility and the mandatory clearing status of the trade or of each trade within the portfolio – multiple regulatory bodies may be referenced.
The messages are available in the pretrade and confirmation views and include:
- requestClearingEligibility - request message
- clearingEligibility - response message
- clearingEligibilityException - exception message
- clearingEligibilityAcknowledgement - acknowledgement message
Several DCOs have identified very similar requirements to support the processing of portfolios.
3.3.8.1 Business Requirements
Some DCOs wish to have the ability to support clearing of a portfolio and the ability to claim/reject and apply other actions to the whole portfolio instead of one trade at a time. FpML does have the ability to represent simple portfolios (defined as lists of trade IDs), but at the moment that cannot be used together with the request clearing messages. There is no specific portfolio type that includes multiple complete trades.
Some of the cases where portfolios of trades might need to be handled include:
-
moving a clearing account containing multiple trades from one clearing firm (broker) to another (this is sometimes called “porting”)
-
transferring (assigning/novating) a portfolio of trades from one market participant to another, for example as a result of an acquisition or a exit from part of a market.
-
backloading of an existing portfolio of trades.
Some DCOs wish to manage the processing of a portfolio in multiple messages. A portfolio may contain thousands of trades and it is not practical to process one huge message. A solution is needed from a processing perspective.
The messaging solution (but not any given implementation) must be able to handle either of the following two models:
-
The request is acted on for the portfolio as a whole. For example, in consent negotiation, consent is given or refused to the portfolio as a whole.
-
The request is acted on for the individual constituent of the portfolio. For example, in consent negotiation, consent may be given for some constituents of the portfolio but not for others.
This portfolio request capability must be provided for the following business processes:
-
consent negotiation
-
clearing
|
|
|
|
|
|
3.3.8.2 Portfolio Reference
Starting with FpML 5.2, a new, optional portfolioReference structure has been added to select messages (i.e., requestConsent, consentGranted, requestClearing, and clearingConfirmed) to group together individual messages that can be acted on at a group level.
The portfolioReference provides:
-
a way of linking together multiple messages that are part of the same portfolio
-
a way for the recipient of ensuring all the messages are received
-
a way to apply actions e.g. grant consent to the bulk container (e.g., on some group identifier rather than at the individual level)
Requests and responses message have a different content model. For the requestConsent, requestClearing, clearingConfirmed messages, the portfolioReference (of type PortfolioReferenceFull) includes:
-
portfolioName – An identifier that uniquely identifies the portfolio.
-
sequenceNumber – A sequential (gapless numerical) identifier giving the message sequence within the portfolio. A recipient must ensure that all sequence numbers from 1 to the number of the final request are received to ensure that it has all constituents of the portfolio.
-
submissionComplete – An optional boolean indicator that specifies whether the last message in the portfolio has been sent. The indicator should be provided for request messages. It should be optional when used in the clearingConfirmed message.
|
|
|
The first constituent of portfolio Port1 may be coded as:
<portfolioReference> <portfolioName portfolioNameScheme=”http://www.clearingsvc.com/portfolioId”>Port1</portfolioId> <sequenceNumber>1</sequenceNumber> <submissionsComplete>false</submissionsComplete> </portfolioReference>
For response messages (e.g. consentGranted), the portfolioReference structure (of type PortfolioReference) just includes the portfolioName and allows the response to reference the portfolioName where the response is at the portfolio level.
|
|
|
If the response is at the individual message level, the portfolioReference does not need to be included; only a reference to the original correlationId.
The consent on an entire portfolio may be coded as:
<consentGranted> … <correlationId correlationIdScheme="http://www.clearingsvc.com/correlationId">123456</correlationId> <sequenceNumber>1</sequenceNumber> <portfolioReference> <portfolioName portfolioNameScheme=”http://www.clearingsvc.com/portfolioId”>Port1</portfolioId> </portfolioReference>
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.