3.1.2.1.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.1.2.1.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.1.2.1.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.1.2.1.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.3.3.3.1 Normal Operation

Under normal operation we would expect a match to be found as soon as both the internally and externally generated copies of the trade are submitted to the confirmation engine.

Following a trade negotiation each side generates a 'RequestTradeConfirmation' message which is sent to the confirmation provider's system. These requests are used to initiate a trade matching operation. The structure of the request message is shown below.

If the request is valid then the trade is passed to the matching engine for processing. The 'RequestTradeMatch' message needs the same basic data content as the confirmation request message.

When a match is found the associated notification message needs to identify the two trades (via their identifiers) to the participants.

To finish the process the confirmation requestor confirms his acceptance of the match by issuing a 'ConfirmTrade' message that contains a reference to the matched trade.

The final notification of the confirmation provider reiterates the legally binding definition of the trade.

If the request contains the details for a transaction which has already been processed by the confirmation service then a number of possible errors can result in response to the request:

• If a request to confirm the same trade was made previously and the trade is currently unmatched or mismatched, then the service should reply with a 'TradeAlreadySubmitted' message.

• The 'TradeAlreadySubmitted' message has the following content model:

• If a request to confirm the same trade was made previously and the trade was successfully matched, then the service should reply with a 'TradeAlreadyMatched' message.

• The 'TradeAlreadyMatched' message has the following content model:

3.3.3.3.2 Mismatch

If a mistake has occurred in the generation of one trade confirmation request it is possible that the system can detect that two trades should have matched (e.g. they contain a common unique trade identifier) but that they cannot due to significant differences.

The confirmation system keeps trades in its pool following the mismatch notification to allow a subsequent correction or cancellation to be applied to the trade.

The 'TradeMismatched' notification must contain the participants trade identifier as well as the identifier for the counter-trade that it should have matched, together with any other potential matches.

3.3.3.3.3 Confirmation Correction

Whilst a trade is unconfirmed the requesting party may send new copies of the transaction data to replace the original trade details. The data content of the replacing transaction should match the same requirements as those for initiation. Transactions must be fully re-specified (rather than just the incremental differences). The content model for the 'ModifyTradeConfirmation' message which requests this is as follows:

There are a number of scenarios that can result in the processing of such messages:

• The confirmation system may not be able to locate the original trade description to be modified.

• The generated 'TradeNotFound' message contains the identifier for the trade the system was unable to find.

• The modification may be accepted and propagated to the matching engine but the trade remains unmatched.

• As with the initial matching request the 'ModifyTradeMatch' message contains a full copy of the trade.

• The modification may be accepted and propagated to the matching engine resulting in a mismatched trade.

• The modification may be accepted and propagated to the matching engine resulting in a matched trade.

3.3.3.3.4 Confirmation Cancellation

Whilst a trade is unconfirmed the requesting party may ask the entire confirmation action to be cancelled. The cancellation message needs only to contain the information necessary to identify the transaction it affects and must match a currently unconfirmed transaction.

As in earlier cases there are a number of possible processing scenarios depending on the state of the trade within the confirmation system, namely:

• If the cancellation applies to a trade that can not be located, then the sequence of messages is as follows:

• If the cancellation applies to an existing unmatched trade then, it generates the following messages:

• Once the confirmation system has identified the trade as unmatched it must request that the matching system remove the trade from its storage. This is done through a 'CancelTradeMatch' message.

• The response to the confirmation requester completes the process by acknowledging that the confirmation request is cancelled.

• If the cancellation applies to a trade which has already been matched, then the message flow is as follows:

3.3.3.3.5 Alleged

When the confirmation provider detects an unmatched trade that has been outstanding for a period of time, it sends a copy of the transaction to the indicated counterparty. The trade is not removed from the unmatched trade set so that a subsequent new trade confirmation or modification request may match against the trade.

The 'TradeAlleged' message must provide the identification information for the transaction that is alleged against the counterparty. A confirmation service might provide additional information to suggest current unmatched trades that might be a counter transaction.

3.3.3.3.6 Unmatched

A request for trade confirmation that remains unmatched, even after alleged trade processing, for a length of time, should be returned to the requester within a message indicating a failure to match.

The 'TradeUnmatched' notification contains identification information for the unmatched trade and may contain suggestions for possible counter trades.

3.3.3.4.1 Normal Operation

As before the confirmation process is begun when the trading parties send a description of the trade to the confirmation system, now external to both parties.

The presence of the third party allows the match to be taken as legally binding and it is automatically considered confirmed without the need for any further messages.

If the request contains the details of a transaction that has already been processed by the conformation service then a number of possible errors can result from the request, namely:

• If the trade has already been submitted and is currently unmatched or mismatched the service should reply with a 'TradeAlreadySubmitted' message.

• If the trade has already been processed and has been matched, then the service should reply with a 'TradeAlreadyMatched' message.

3.3.3.4.2 Mismatch

The message pattern for the detection of a mismatch is the same as in the bilateral processing case.

3.3.3.4.3 Confirmation Correction

As in the bilateral case either party can request that the details of an unmatched trade be replaced with a new definition. The series of scenarios are identical to the bilateral cases.

• If no corresponding trade can be found in the confirmation system then a 'TradeNotFound' messages is generated.

• The modification may be accepted and propagated to the matching engine but the trade remains unmatched.

• The modification may be accepted and propagated to the matching engine resulting in a mismatched trade.

• The modification may be accepted and propagated to the matching engine resulting in a matched trade.

3.3.3.4.4 Confirmation Cancellation

As in the bilateral case either party can request that the confirmation processing for an unmatched trade be suspended and the trade definition removed from the set of unmatched trades.

• If the cancellation applies to a trade that can not be located, then the sequence of messages is as follows:

• If the cancellation applies to an existing unmatched trade, then it generates the following messages:

• If the cancellation applies to a trade which has already been matched, then the message flow is as follows:

3.3.3.4.5 Alleged

The process of notifying a counterparty of an alleged trade is exactly the same as in the bilateral case.

3.3.3.4.6 Unmatched

As in the bilateral case any trades that remain unmatched, even after alleged trade processing has been attempted, are eventually removed from the unmatched trade set.

3.3.7.2.1 Phase 1: Consent and Negotiation

Before a novation can take place all the parties must give consent to the transfer of rights and liabilities. As the transferor is the initiator of the novation they should be the party that sends the initial messages.

The key problem is one of ensuring that all parties are aware of the acceptance or non-acceptance of their counterparts. The transferor could contact each in turn to request their consent but a more elegant solution to use multiple ‘sendTo’ and ‘copyTo’ facilities of the message header to pass requests and responses between all parties simultaneously.

A ‘NovationConsentRequest’ message passes details of the previously negotiated transaction that the transferor wishes to novate as well as describing the identity and roles of each party. As the same message is sent to both the transferee and remaining party it must contain the complete description of the underlying transaction (rather than just a reference) as the transferee will have no record of it.

Figure 1 (above) Successful Novation Consent

The XML model of the ‘NovationConsentRequest’ would look as follows.

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>
                                        

If the transferee or remaining party choose not to perform the requested novation then they can respond with a ‘NovationConsentRefused’ message.

The use of this message results in three possible message flows in the case of refusal (e.g. transferee refuses, remaining party refuses or both refuse). In all cases all of the parties are aware of the outcome and can continue processing appropriately.

Figure 2 (above) Unsuccessful Novation Consent (Remaining Party Refuses)

Figure 3 (above) Unsuccessful Novation Consent (Transferee Refuses)

Figure 4 (above) Unsuccessful Novation Consent (Both Parties Refuse)

At end of the process each party should be aware of consent status of the others. Once the transferor has received two; NovationConsentGranted’ messages and has assessed the payment terms specified by the transferee they may either begin the actual novation or request an alternative novation consent with another transferee.

All of the messages exchanged during the negotiation may have passed through an intermediary (such as a confirmation provider) who may monitor message flow, but who plays no part in the initial discovery stage.

3.3.7.2.2 Transfer of Rights and Obligations

Once all parties have consented to novate a transaction a message from any of the parties may start the transfer process.

The novation process closely resembles that for trade matching and confirmation however there are two underlying transactions that must both be matched for the novation as a whole to be confirmed.

• The transferor and remaining party must agree on the details of the old transaction
• The transferee and remaining party must agree on the details of the new transaction
• Transferor and transferee need to agree on the payment

A novation is considered confirmed when all three parties have submitted a valid ‘RequestNovationConfirmation’ message containing matching transaction descriptions. Any of the parties may initiate the matching process by sending their message first.

The data content of this message varies according to the sender, specifically:

• The transferor will provide only the old transaction details (or old transaction identifier) and possible payment details if to the transferee
• The transferee will provide only the new transaction details and possible payment details if to the transferor
• The remaining party will provide both the old and new transaction details.

The XML grammar for this message does not enforce this content model, rather it is intended to be asserted by a validation rule.

The sequence of processing and messages generated by a confirmation system in response to a request for confirmation will vary according to the order of their arrival from the parties. The diagram ‘Novation model 1’ shows an example of the flows assuming that remaining party sends first followed by the transferor and finally the transferee.

Similar to the trade confirmation process, first request generates ‘NovationAlleged’ messages to inform the other parties that a novation process has been started. Once a party has sent in its confirmation request it receives status notifications until either confirmation is achieved or the process is aborted.

The main difference being that for trade confirmation the alleged messages are only sent after a timeout period.

Novation model 1(above)

Novation model 2 (above): Order as per original Trade Confirmation

The following diagrams show the model for each status message:

NovationAlleged Message:

NovationMatched Message:

NovationConfirmed Message

The following items are not specifically addressed in the examples above:

• The matching of the payment details
• The error conditions

3.3.11.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.11.1.2 Implementation

The implementation uses type substitution in PartyTradeIdentifier type so in the case that a trade is a block trade, the element has the following structure:

 
...
<partyTradeIdentifier xsi:type="BlockTradeIdentifier" >
...      
                                                

In case the trade is an allocated trade, the element has the following structure:

 
...
<partyTradeIdentifier xsi:type=”AllocationTradeIdentifier" >
...    
                                                

BlockTradeIdentifier and AllocationTradeIdentifier are derived types (extension) of PartyTradeIdentifier.

This is the schema structure for the new types:

3.3.11.1.3 Examples

This is an analysis of the different situations:

Example:

• "Long-Form" Allocation of a Credit Default Swap (xml file)

 
                                                        ...
<tradeHeader>
        <partyTradeIdentifier>
                <partyReference href=”BGI”/>
                <tradeId tradeIdScheme=”http://abc.com”>ABC100</tradeId>
        </partyTradeIdentifier>
</tradeHeader>                                                        
                                                        ...    
                                                        

 
                                                        ...
<tradeHeader>
        <partyTradeIdentifier xsi:type=”BlockTradeIdentifier”>
                <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>                                                        
                                                        ...    
                                                        

 
                                                        ...
<tradeHeader>
        <partyTradeIdentifier xsi:type=”BlockTradeIdentifier”>
                <partyReference href=”BGI”/>
                <tradeId tradeIdScheme=”http://abc.com”>ABC100</tradeId>
        </partyTradeIdentifier>
</tradeHeader>                                                
                                                        ...    
                                                        

 
                                                        ...
<tradeHeader>
        <partyTradeIdentifier xsi:type=”AllocationTradeIdentifier”>
                <partyReference href=”Fund1”/>
                <tradeId tradeIdScheme=”http://abc.com”>ABC101</tradeId>
                <blockTradeId>  
                        <partyReference href=”BGI”/>
                        <tradeId tradeIdScheme=”http://abc.com”>ABC100</tradeId>
                </blockTradeId>
        </partyTradeIdentifier>
</tradeHeader>
                                                        ...    
                                                        

 
                                                        ...
<tradeHeader>
        <partyTradeIdentifier xsi:type=”AllocationTradeIdentifier”>
                <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.11.1.4 Validation Rule

With this implementation, there are potential situation where the use of type substitution in partyTradeIdentifier may be confusing. Let’s see the situation where there are multiple partyTradeIdentifier elements:

 
                                                ...
 <tradeHeader>
...
        <partyTradeIdentifier xsi:type=”BlockTradeIdentifier”>
                <partyReference href=”BGI”/>
                <tradeId tradeIdScheme=”http://abc.com”>ABC100</tradeId>
        </partyTradeIdentifier>
        <partyTradeIdentifier xsi:type=”BlockTradeIdentifier”>
                <partyReference href=”RBS”/>
                <tradeId tradeIdScheme=”http://rbs.com”>RBS100</tradeId>
        </partyTradeIdentifier>
…
</tradeHeader>                                        
                                                ...    
                                                

The two partyTradeIdentifier are making reference to the same trade (block trade in this case). A validation rule should enforce that the xsi:type value should be the same for both partyTradeIdentifier elements in order to be consistent. Otherwise, you may have a potential situation where one of the partyTradeIdentifier element contains a value in the xsi:type attribute but the other doesn't’t: This situation potential case may be confusing for implementers. This potential issue applies also when the xsi:type values equals to AllocationTradeIdentifier.

3.3.11.1.5 N-Level Allocations

The BlockTradeIdentifier 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 with partyTradeIdentifier derived type named BlockTradeIdentifier that includes the allocationTradeId element and the blockTradeId element.

3.3.11.3.1 RequestAllocation

FpML message supporting the allocation "short-form" representation with a reference to the trade instead of sending the whole trade details.

The response to this message would be an AllocationCreated notification message incorporating full FpML trade representation for the block and the allocated trades.

3.3.12.3.1 TradeCashflowsAsserted

As stated above, the payment is exposed to the matching process using the TradeCashflowsAsserted message:

The TradeCashflowsAsserted message contains the following structures:

• asOfDate: The date and time at which the set of net cashflows was defined.
• tradeCashflowsId: Unique identifier assigned by either party or matching service, as agreed, to a set of net cashflows.
• tradeIdentifyingItems: Structure that holds reference to the trade through the tradeId and optionally some trade-specific elements for identifying the trade in the case of trades that have not been negotiated through electronic platforms and for which the counterparty's trade ID has not been captured. The underlyingAsset element is a head of a substitution group. This means that this element is replaced by one of the possible underlying components defined in the fpml-asset subschema. These components include: equity, index, bond, convertible bond, fx rate, and other underlyers.

• adjustedPaymentDate: The adjusted date in which the net payments are being paid/received.
• payment: Defines a net payment in a given currency and optionally contains the gross cash flow information and its related calculation details that sustains this payment.

• matchId: A unique identifier assigned by either party, or matching service, as agreed, to each set of matched cashflows.

3.3.12.3.2 TradeCashflowsMatchResult

The result of the reconciliation process is reported using the TradeCashflowsMatchResult message:

The message includes a status element. The values are defined using a coding scheme. The values include:

• Matched: both sides have the same cash flow (or set of cash flows) information within matching policies.
• Mismatched: both sides have the same cash flow (or set of cash flows), but there are differences greater than the acceptable tolerance in the matching policies.
• Unmatched: no corresponding cash flow (or set of cash flows) was found in "the other party’s" submitted sets.
• Alleged: no corresponding cash flow (or set of cash flows) was found in "your" submitted sets.

3.3.12.3.3 CancelTradeCashflows

The set of net payments can be cancelled using CancelTradeCashflows message:

3.3.12.3.4 Reference Data

In order to standardize the values of some of the elements defined by the cash flow matching subschema, a set of schemes is provided. The schemes provided include:

• Product type scheme (product-type-1-0.xml)
• Cash flow type scheme (cashflow-type-1-0.xml
• Updated asset measure scheme (asset-measure-4-0.xml)
• Cash flow status scheme (trade-cashflows-status-1-0.xml)

The scheme mechanism provides implementers the ability to define their own schemes in a more generic or more aggregated level.

3.3.12.4.1 Trade Identification

The FpML guideline recommendation for cashflow matching is to identify the trade using either the common trade identifier (in the case where it has been negotiated through an electronic platform), or the trade identifiers assigned by each of the respective parties (in the case where a post-trade matching process exists, either bilaterally or through an industry service provider).

Recognizing that a common trade identification is, most often, not available (at least in the early stages of the contract’s lifecycle), the FpML standard supports the identification of the trades through a set of trade attributes:

• Trade date, effective date and termination date. The recommended usage is to specify those two latter dates as unadjusted, without date adjustment. The objective is indeed to use those attributes as a trade identification mechanism, not to reconcile the date adjustment convention for the given contract. In the case where a trade would have several effective dates and/or termination dates, the recommended usage guideline is to identify it with the earliest effective date and the latest termination date.
• ProductType. A simple typology of OTC products has been developed to support the cashflow matching process, which is contained in the product-type-simple-1-0.xml scheme. This typology can be used by the implementers as a reference for product categorization. As a coding scheme it can be customized easily to meet the needs of the application.
• Underlyer. The substitution group that is part of the schema provides the ability to represent the whole array of underlying assets currently specified through FpML. The examples that have been developed illustrate the suggested usage. In the case of assets that have multiple industry references, such as listed securities (with ISIN, CUSIP, RIC, etc.) or reference entities (with the formal name or the RED identifier), the expectation is that while FpML provides an appropriate framework, each implementer will specify an appropriate convention.
• Notional. The FpML usage guideline is to specify the notional (or notionals, in the case of a cross-currency swap) in effect on the last day of the last calculation period.

Below is a snippet of one of a credit default swap example that highlights this approach for identifying the trade when no common identifier is available and the party do not have (yet) the trade identifier of its counterpart:

 
...
<tradeIdentifyingItems>
	<partyTradeIdentifier>
		<partyReference href="abc"/>
		<tradeId tradeIdScheme="http://www.abc.com/tradeId">SDB0494701620</tradeId>
	</partyTradeIdentifier>
	<tradeDetails>
		<tradeDate>2005-02-28</tradeDate>
		<effectiveDate>
			<unadjustedDate>2005-03-01</unadjustedDate>
		</effectiveDate>
		<terminationDate>
			<unadjustedDate>2009-12-20</unadjustedDate>
		</terminationDate>
		<productType productTypeSimpleScheme=
"http://www.fpml.org/coding-scheme/product-type-simple-1-0">CreditDefaultSwap</productType>
		<underlyer id="_018A99">
			<referenceEntity>
				<entityId entityIdScheme=
"http://www.fpml.org/spec/2003/entity-id-RED-1-0">018A99</entityId>
		</referenceEntity>
		</underlyer>
		<underlyer id="FIXED">
			<fixedRate>
				<initialValue>0.04</initialValue>
			</fixedRate>
		</underlyer>
		<notional>
			<currency>USD</currency>
			<amount>2000000.00</amount>
		</notional>
	</tradeDetails>
</tradeIdentifyingItems>

...      
                                                

In this other snippet, the respective trade identifiers are know, and the party that asserts the cashflow does not then see the need to express the trade details (this latter point being however not necessarily an optimal approach, considering that the statement of the economic identifiers of the trade could be a good way to ensure that the trade identification has not been mi-stated):

 
...
 <tradeIdentifyingItems>
	<partyTradeIdentifier>
		<partyReference href="abc"/>
		<tradeId tradeIdScheme="http://www.abc.com/tradeId">trade1abcxxx</tradeId>
	</partyTradeIdentifier>
	<partyTradeIdentifier>
		<partyReference href="def"/>
		<tradeId tradeIdScheme="http://www.def.com/tradeId">123cds</tradeId>
	</partyTradeIdentifier>
</tradeIdentifyingItems>

...
                                           
                                                

3.3.12.4.2 Payment

As presented in the Design Principles section of this document, the recommended usage of this messaging protocol is, within the perimeter of a trade, to match the cashflow that the counterparties intend to settle.

Practically speaking, this means that when several cashflows will have the same payment date and currency, those will be presented as netted to the matching process.

This snippet below presents the simple way of expressing a payment as part of the schema:

...
<payment>
	<identifier paymentIdScheme="http://www.abc.com/paymentId">8410363</identifier>
	<payerPartyReference href="def"/>
	<receiverPartyReference href="abc"/>
	<paymentAmount>
		<currency>USD</currency>
		<amount>20444.44</amount>
	</paymentAmount>
</payment>
...
                                                
                                                

3.3.12.4.3 Calculation Details

The FpML standard for cashflow matching offers the ability to provide underneath calculation details that explain how the payment has been computed. Those details are optional, in order to provide the ability for the implementers to have matching processes with a scope limited to the sole payment, with no underlying information.

Considering the underlying recommendation that cashflows should be matched as they will settle and, as a result, that most of those would be netted, the calculationDetails container is based upon the specification of each of the gross cashflow components that make up this exposed payment. In the case where no netting would have occurred (e.g. a credit default swap coupon), the amount stated in the paymentAmount node would be equal to the one stated in the grossCashflow node.

The various examples that have been developed propose a usage guideline in the case where the party would provide a complete set of underlying information to explain how the payment has been computed. From an implementation perspective, such approach would however not necessarily imply that each of those data elements should be reconciled: a conceivable approach could be to just reconcile the payment and gross cashflow(s) elements, with the observation and calculation details being provided to enable a fast research path to the cause of the break.

3.3.13.2.1 Bilateral vs. Trilateral

Reconciliation can be performed directly with the other participant or via an intermediary who performs the service on behalf of both parties. If it is performed bilaterally then either one or both the parties may take in responsibility for performing the necessary comparisons.

3.3.13.2.2 Batch (a.k.a Snapshot) vs. Incremental

Reconciliation MAY be performed when complete portfolio descriptions have been received from both parties or as an on going process whenever either party changes their portfolio description.

A portfolio description could be sent as a single message to the service (e.g. containing a complete snapshot of a small portfolio), or as a series of messages describing incremental changes to the position components (e.g. as additions, modifications, cancellations to a large portfolio).

It may also be useful to be able to construct portfolios by referencing components of previous submitted portfolios rather than having to re-upload them (especially if there are a large number of components which have not changed). The reference could be made specific through the use of version identifiers.

3.3.13.2.3 Fixed time vs. Real-time

Reconciliation may be performed as soon as information is provided or at a fixed time, for example relative to a specific geographic ‘end of day’ or ‘market close’ time.

Portfolio information is never provided simultaneously by both parties so any change to a portfolio in a real-time based service will generate an initial unmatched state with respect to one party and alleged with respect to the other until the matching component is received from the other party (when it can be resolved to matched or mismatched).

3.3.13.2.4 Level of detail

Reconciliation MUST compare the parametric descriptions of each portfolio constituent but MAY also compare additional information such as any provided valuations.

3.3.13.2.5 Product Scope

Trades describing positions created by negotiated OTC transactions. The unique nature of these contracts means that they cannot be aggregated. The products supported include complete range of OTC products that are supported by FpML. Currently the coverage is limited to OTC products. It doesn’t include multiply traded contracts.

The potential extended coverage could include:

• Positions in multiply traded contracts such as equity, bonds, futures, exchange traded options and warrants. Such positions are normally expressed and an opening and closing amount of some contract and MAY be supported by a list of the transactions that affected the position. A proposal for representing trades of securitised products is available on the FpML website on the proposals section www.fpml.org/proposals (Non derivative products) and this framework can be extended to support these products.
• Cash positions resulting from foreign exchange transactions, coupons and dividends. As with securitised positions theses should be expressed as an opening and closing amount for each currency and MAY be supported by a list of affecting transactions. Whilst currencies have been modelled in FpML since version 1.0 they are not treated the same ways as OTC and non-derivative products so they require separate handling.

3.3.13.3.1 Product Representation

The FpML portfolio reconciliation messages use the existing FpML OTC product representations. The rationale for this is that existing complex data models used for confirmations purposes should cover the data requirements for portfolio reconciliation. However, the FpML Business Process Working Group recognizes that there are some data elements that are required for confirmation and other post-trade processes that shouldn’t be required for reconciliation activities. Future schemas may have a more flexible product representation to be used exclusively for reconciliation purposes.

3.3.13.3.2 Design approach

When a group of parties are reconciling with each other through the same service they should all have the same view, although they may define a different number of portfolios to the service. For example if we had four parties A, B, C and D using the same service where A had traded with B, C and D, C had traded with A and D whilst B had only traded with A, then A would need to submit three portfolios (A-B, A-C, A-D), B would submit one (B-A), C would submit two (C-A, C-D) and D would submit two (D-A, D-C).

To initiate reconciliation the requestor should send one (“snapshot approach”) or more (“incremental approach”) ‘PositionsAsserted’ messages to the reconciliation service provider to construct the portfolio contents.

Each definition request WILL contain details of:

• The identity of the requesting party
• The identity of the matching party (optional).
• A portfolio identifier (possibly defined by the service provider). Having an identifier allows more that one portfolio to exist for each party pairing. For example you could define portfolios to maintain DAILY, WEEK-TO-DATE and MONTH-TO-DATE positions with a particular counterparty simultaneously.
• A portfolio as-of date (the date for which the portfolio definition applies).
• A flag indicating whether it is a new portfolio or an update to an existing one.
• A number of portfolio component definitions with optional version information.

In the “incremental approach” the reconciliation service WILL use the two identities, portfolio identifier and as-of date to group together components that arrive in multiple definition messages to create a complete portfolio definition. Request message contents SHOULD be processed sequentially and individually. It is possible for some component definitions to be rejected while others are accepted and applied to the portfolio.

Optionally, the service provider can send a response message called ‘PositionsAcknowledged” with immediate feedback how each of the provided component definitions was processed (e.g. accepted/rejected). It does not contain any reconciliation comparison results.

At some time following the submission of the portfolio of positions, the reconciliation server will process its set of the portfolio collections and produce a notification report of matches and differences. This notification report is called ‘PositionsMatchResults’.

In a real-time environment this notification may be generated every time one of underlying portfolio sets is modified and requestors MUST be capable of processing multiple notification messages relating to the same portfolio. They MUST also be capable of processing a reconciliation notification (containing alleged position components) for a portfolio they have not yet defined. This implies that the portfolio identifier can be determined in advance and is not a user definable data item.

3.3.13.4.1 PositionsAsserted

The ‘PositionsAsserted’ message type is used to either start the construction of a new portfolio or modify the contents of an existing one.

The message includes:

• A portfolio identification section, identifying the portfolio name, the defining and matching parties, the as-of date, and the new portfolio definition flag as described above.
• An indicator called ‘submissionsComplete’ that specifies whether this message completes the updating of the portfolio for the as-of date.
• A set of instructions for specifying the positions contained in the portfolio. There is a choice between completely restating the portfolio’s positions (by specifying “replaceAllPositions” and listing the up-to-date positions), and incrementally updating the portfolio by updating or removing positions.
• The parties referenced by the above.

To specify a position, whether it is a new or updated position, the ‘definePosition’ element is used. It has the structure shown in the following diagram and it is based on the Position representation developed by the FpML Pricing and Risk Working Group. This guarantees a consistent position model, which is used for both: position reporting as well as portfolio reconciliation. This structure allows for positions in unique OTC derivative contracts, and through extensions could potentially allow for listed securities (identified by an instrument code value and qualifying URL) and cash as well. It can be appear multiple times within a request.

This structure is an extension of the Pricing and Risk Position type and includes:

• Identification information (a position ID and version), which allows the position to be referenced across messages. The positionId may be based on one of the trade IDs in an included trade, or it may be something different. The version is a positive, increasing number. Higher version numbers imply “newer” positions, i.e. ones that replace previously supplied information. There is no requirement that the version number be small or that version numbers be sequential, so a timestamp-based integer could potentially be used as a version identifier. The positionId and version are assumed to have been created by the sender of the message (i.e. the definingParty), rather than by any of the parties to the trade.
• Complete trade details, or an element identifying the version of the position that included the full trade definition, or trade reference (mainly used for reporting purposes).
• An optional reference to a base party, from whose point of view valuations are computed. This allows the reconciliation service to determine the sign with which valuations should be compared.
• A “force match” element, which is an optional reference to a position specified by the matchingParty that is known to correspond to this position.

If a position is no longer needed (e.g. a change to a trade’s details means that it falls outside the scope of the reconciliation) it may be removed by sending a ‘removePosition’ element, which simply contains a “PositionReference” type. This is a reference to a previously identified position. Its structure is as follows:

The PositionReference contains a position ID, which is version-independent, and an optional version. If the version is specified, the reference is to a particular version of the position; if not, the reference is to any version (which typically means the latest version).

In the case of a “removePosition” element, the “version” is not needed to specify the position, and if supplied should be treated as informational.

Positions that net to a zero closing amount within the scope of the reconciliation SHOULD be expressed using ‘definePosition’ and NOT removed. Example: If I opened with 50 shares in IBM stock that were sold during the period being reconciled then I should have a position with zero closing units to represent this. If I do no further trading in IBM stock then there does not need to be a position for IBM stock in future reconciliation portfolios until some is reacquired.

If a reconciliation provider cannot process a PositionsAsserted, for example because the message cannot be parsed, is schema-invalid, or contains illegal header information (defining or matching parties, as-of date, or portfolio name), it should return an FpML “MessageRejected” message, specifying the reason the message was rejected.

3.3.13.4.2 PositionsAcknowledged

When a reconciliation provider has processed a ‘PositionsAsserted’ it MAY return a ‘PositionsAcknowledged’ to the requestor. The decision on whether use this message will depend on the implementation. As the request may have contained many position adjustments the response must be capable of providing status information of each adjustment.

For each ‘definePosition’ element in the request the response SHOULD contain either a ‘definedPosition’ or ‘unprocessedPosition’ element. Similarly a ‘removePosition’ element in the request SHOULD have either a corresponding ‘removedPosition’ or ‘unprocessedPosition’ element.

The ‘definedPosition’ element describes a position adjustment that succeeded. It contains a PositionReference to the position that was created. Similarly, a “removedPosition” element contains a PositionReference to the position that was removed.

If an entire position change cannot be processed then in addition to the position identification information, the reason that the position change could not be processed should be provided.

3.3.13.4.3 PositionsMatchResults

The result of a reconciliation operation is one (“snapshot approach”) or more (“incremental approach”) ‘PositionsMatchResults’ messages sent by the provider. A single notification message may contain the results of comparing multiple positions and hence must support the match, mismatched, unmatched and alleged position results. However, the data reported for each one of these status is quite similar, i.e. an implementation may choose to report differences between positions even thought they are matched objects.

The message includes a status element. The values are defined using a coding scheme. The values include:

• Matched: both sides have the same position information within matching policies.
• Mismatched: both sides have the same position, but there are differences greater than the acceptable tolerance in the matching policies.
• Unmatched: no corresponding position was found in "the other party’s" submitted set.
• Alleged: no corresponding position was found in "your" submitted set.

3.3.13.5.1 Trilateral vs. Bilateral

In the implementation of this set of messages using a central matching service (trilateral), there are a set of guidelines to consider:

• The matchingParty element contained inside portfolioDefinition should be omitted since it would provide irrelevant information.
• A matchId value should be provided by the central matching service once two positions are matched.

In the bilateral case:

• The matchingParty element should be provided.
• The parties should agree upfront whether to use the matchId element and who will provide the value.

3.3.13.5.2 Incremental vs. Snapshot

There are a set of guidelines to consider depending on the scenario that is going to be implemented:

• If the position submissions are sent incrementally, the matching results should be sent incrementally as well.
• If the position submissions are sent as snapshot (using a single message for the whole portfolio), the results should be sent as snapshot as well.

3.3.13.5.3 Reference Data

In order to standardize the values of some of the elements defined by the portfolio reconciliation subschema, a set of schemes is provided. The schemes provided include:

• Position match status scheme (position-match-status.xml)

3.3.13.5.4 Position Differences

In order to provide the ability to report position differences, the portfolio reconciliation PositionMatchResults message reuses the existing TradeDifference structure. Example:

<difference>
	<differenceType>Value</differenceType> 
	<differenceSeverity>Error</differenceSeverity> 
	<element>adjustedTerminationDate</element> 
	<basePath>constituent/trade/fra/ajustedTerminationDate</basePath> 
	<baseValue>1992-01-17</baseValue>
	<otherPath>constituent/trade/fra/ajustedTerminationDate</otherPath> 
	<otherValue>1993-01-17</otherValue> 
	<message>Value [1993-01-17] in HEDGUS33 is [1992-01-17] in ABCDUS33.</message> 
</difference>
						

There is flexibility for implementers to provide the basePath/otherPath information. FpML recommends having different “entry points” for reporting the XPath expression depending on where the difference is located. These entry points would begin with the following elements:

• constituent (as shown in the snippet above)
• valuation
• scheduledDate

3.3.14.2.1 Primary Contract Identifier

In FpML, there is no notion of primary trade or contract identifier. Contract identification is meaningful within the context of a party. That’s why the identifier structure contains a partyReference element referencing a party. Within the structure, multiple versionedContractId elements can be specified. This is useful for allowing organizations with multiple systems, each one of them generating one or multiple contract identifiers, to be able to record that in the FpML message. Each system is identified by a unique value in the contractIdScheme attribute.

<identifier>
	<partyReference=”INVM1”/>
    	<versionedContractId>
        		<contractId contractIdScheme="http://www.investmentmgm.com/coding-scheme/contract-id">CDI290204</contractId>
        		<version>1</version>
    	</versionedContractId>
    	<versionedContractId>
        		<contractId contractIdScheme=”valuation-system/contract-id”>VS3456332</contractId>
        		<version>1</version>
    	</versionedContractId>
</identifier>
                                        

In order to be able to process contract identification information, in absense of a central system, participants should decide on how to store the identification information of the contract:

• Recipients may choose to process all contract identifers and sources sent in a message and their relationship so in subsequent messages, the sender may send only one of the previous identifiers and the recipient may still be able to identify the contract.
• Recipients may choose to process a single contract identifier. In that case, participants must agree which system source is relevant, and ignore the others. Participants must exchange the contractIdScheme values that are going to be relevant for processing. In the example above, the recipient may keep the contract id of ‘http://www.investmentmgm.com/coding-scheme/contract-id’ and ignore the other contract id.

3.3.14.5.1 Termination

The termination messages allow details of a full or partial termination to be distributed to downstream participants. Please note that the notification messages split between full and partial terminations. This allows recipient to know the action at the message type level without having to inspect the content of the message.

3.3.14.5.1.1 ContractFullTermination

A ‘ContractFullTermination’ message provides the recipient with the latest terms for a full termination of the indicated contract.

3.3.14.5.1.2 ContractFullTerminationCancelled

A ‘ContractFullTerminationCancelled’ message provides the recipient with an instruction to cancel a specific full termination event of the indicated contract.

3.3.14.5.1.3 ContractPartialTermination

The ‘ContractPartialTermination’ message indicates that a contract has been terminated partially.

3.3.14.5.1.4 ContractPartialTerminationCancelled

A ‘ContractPartialTerminationCancelled’ message provides the recipient with an instruction to cancel a specific partial termination event of the indicated contract.

3.3.14.5.2 Novation

The novation messages allow details of a full or partial novation to be distributed to downstream participants.

3.3.14.5.2.1 ContractNovated

A ‘ContractNovated’ message provides the recipient with the latest terms for a full or partial novation of the indicated contract.

3.3.14.5.2.2 ContractNovatedCancelled

A ‘ContractNovatedCancelled’ message provides the recipient with an instruction to cancel a specific novation event of the indicated contract.

3.3.14.5.3 Increase

The increase message describes a negotiated increase in the economic value of a trade. An increase can also be used to correct an erroneous partial termination.

Please note that increase and partial termination use the same ChangeContractSize content model.

3.3.14.5.3.1 ContractIncreased

A ‘ContractIncreased’ message provides the recipient with the terms for an economic enlargement of the indicated contract.

3.3.14.5.3.2 ContractIncreasedCancelled

A ‘ContractIncreasedCancelled’ message provides the recipient with an instruction to cancel a specific increase event of the indicated contract.