## 3 BUSINESS PROCESS ARCHITECTURE

### 3.1 Introduction

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

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

#### 3.1.1 Why Business Messaging?

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

- Representation

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

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

- Semantics

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

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

- Business Process

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

  To support business process the messaging working group has extended the core FpML grammar to add a framework for defining messages and their content. This section describes some business processes and shows how they are implemented as message exchanges.

- Transport

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

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

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

#### 3.1.2 Design Assumptions

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

- 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.

- 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.

- 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.

- All business process definitions must have an observable completion. The set of messages defining a business process needs to be complete. In addition, timeouts must be defined if necessary.

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.1.2.1 Transport Characteristics

##### 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.1.3 Styles of Messaging

In general computer systems commonly use two styles of messaging to exchange information between each other, namely:

- Request/Response

  A style of exchange in which one system sends a message to the other to asking it to perform some function, the result of which is encapsulated in an appropriate response and returned.

- Notification

  A style of exchange in which a system sends a message describing a business event that has occurred and may be of interest to others.

The receipt of either kind of message may cause additional messages to be generated and sent as part of the processing to obtain information from other systems or to inform them of the business event underway.

#### 3.1.4 Transport Independence

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

From the top down, the four layers are:

##### 3.1.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.1.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.1.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.1.4.4 Transport

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

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

#### 3.1.5 Control Over Content

The design of a grammar must strike a balance between the degree of flexibility it allows and the complexity of its validation. An overly lax grammar allows the construction of documents that, whilst syntactically correct, may have no valid business interpretation. On the other hand a very rigid grammar may require many more grammatical productions in order to enumerate only the valid combinations.

In general it makes sense for a grammar to be strict when it can be achieved easily and without too much additional definition, and lax where flexibility is required (e.g. for proprietary extensions, etc.). In the case of the message framework the grammar provides a mechanism for ensuring that messages have the correct content that applies to them.

#### 3.1.6 Identification of Purpose

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

The FpML message framework is based on type substitution (option 3 - By Element Type) as it gives the greatest control over validation whilst allowing easy extension of the message elements. Below is a short explanation of the three techniques:

##### 3.1.6.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.1.6.2 By Element Name (not used by FpML)

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

    <?xml version="1.0"?>

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

To ensure that the content of the FpML element is always a valid message element the grammar would have to use either a choice group (which would limit extensibility) or a substitution group (which is extensible) to define the acceptable elements.

Whilst the root element could be used to indicate the function it is more likely that a child would be used so that all FpML documents would still have the FpML element as the root.

In this model the message header must be generic, that is suitable for any kind of message. There is no way in XML to validate that the content is suitable for the type of message content that follows.

##### 3.1.6.3 By Element Type

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

    <?xml version="1.0"?>

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

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

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

#### 3.1.7 Representing Internal Trades

The focus of FpML to date has been on the focus description of trades for B2B purposes. At the same time many of the existing implementations have been for internal trade exchanges between systems.

Extending FpML to handle internal trade information entails adding additional elements to the current schema to hold the values needed to categorize a trade for internal purposes. There are several ways this information could be added to the schema (e.g. optional elements, alternative inheritance structures, inheritance by restriction) each with its own properties in terms of ease of validation or affects on document style. The FpML Architecture specification contains examples of how bespoke extensions can be made to the schema.

#### 3.1.8 Sequence Diagram

A UML diagram that defines information flows. It focuses on the temporal order of the messages. Business Analysts can find sequence diagrams useful to communicate how the business currently works by showing how various business objects interact.

At the top of each diagram we see the names of actors or business objects involved in the process we want to describe. In the diagram above, Confirmation Requester and Confirmation Provider are examples of actors involved in the confirmation process.

The rectangles represent the systems involved in the process, e.g. Trading System, Confirmation System, and Matching System. However, in some other versions of sequence diagrams, the rectangles represent the actors or business objects.

Usually the actor or business object on the left side starts the interaction. Descending from each object is a line known as the “lifeline”. These lines define the time axis of the diagram. By convention, time proceeds in a downward direction. This practice is used in the FpML documentation.

The arrows between the lifelines represent messages being sent between the actors. For example, in the diagram above, RequestTradeConfirmation and TradeAlreadySubmitted are examples of messages being sent between the Confirmation Requester and the Confirmation Provider.

The white narrow rectangles that the arrows terminate on are called “activations”. For example, the rectangles between the RequestTradeConfirmation and TradeAlreadySubmitted messages in the diagram above are activations. They show the duration of the execution of a method or action in response to a message.

If you need more information regarding sequence or other UML diagrams, you can easily find UML diagram tools and tutorials by searching on the Internet.

### 3.2 The Message Framework

Versions of FpML prior to 4.0 have allowed the construction of documents which contain only product definitions. The original proposal for FpML 4.0 was to force a transition directly to messages by making some message elements mandatory in every document. However after further consideration it was decided to restructure the framework to allow both styles of definition giving FpML backwards compatibility with existing solutions and the scope to expand into new B2B (or A2A) messaging applications.

The following document give a general overview of what FpML Messages are available to support business processes: FpML Messaging Object Model (PDF)

#### 3.2.1 The Base Document

The XML schema for FpML defines the type of the root FpML element to be 'Document', an abstract type with an empty content model save only for the standard FpML version.

The Document type serves as the base type in an inheritance scheme that provides the content model definitions for actual message types.

##### 3.2.1.1 Data Documents

The DataDocument type provides the same content model as the pre XML schema version of FpML allowing the construction of documents that contain only product definitions.

To make an FpML 3.0 DTD based document compatible with the FpML 4.0 schema as a DataDocument a number of changes are required to the instance document, namely:

- The <!DOCTYPE> reference must be removed from the document.
- Where the <FpML> element defines a non-standard or institution specific default scheme attribute value it must be propagated the scheme attribute on all the appropriate elements.
- A reference to the FpML schema as the default namespace must be added.
- A reference to the W3C XML schema instance schema must be added and assigned to a namespace (e.g. 'xs' or 'xsi').
- A reference to the W3C XML Digital Signature schema must be added and assigned to a namespace (e.g. 'dsig').
- The type of the <FpML> element must be set to 'DataDocument'.
- A schemaLocation attribute may be added to the <FpML> element to hint at the location of the schema for XML tools that do not perform full 'entity resolving'.

#### 3.2.2 The Base Message

The core definitions within the schema establish a set of abstract base classes, 'Message' , 'MessageHeader' and a model group called 'MessageHeader.model' from which all the other definitions are composed by.

The message header used xsd:restriction in previous versions in order to restrict the content model for requests, responses, and notifications. But tools issues with xsd:restriction made the Architecture Working Group to change the architecture of the message header using model groups and xsd:extension instead of xsd:restriction.

The following XML schema fragment shows how these types and group are defined.

     <xsd:complexType name="Message" abstract="true">
    	<xsd:complexContent>
    		<xsd:extension base="Document"/>
    	</xsd:complexContent>
    </xsd:complexType>

      <xsd:complexType name="MessageHeader" abstract="true">
    	<xsd:sequence>
    		<xsd:element name="conversationId" type="ConversationId" minOccurs="0"/>
    		<xsd:element name="messageId" type="MessageId"/>
    	</xsd:sequence>
    </xsd:complexType>
    <xsd:group name="MessageHeader.model">
    	<xsd:sequence>
    		<xsd:element name="sentBy" type="MessageAddress"/>
    		<xsd:element name="sendTo" type="MessageAddress" minOccurs="0"
    maxOccurs="unbounded"/>
    		<xsd:element name="copyTo" type="MessageAddress" minOccurs="0"
    maxOccurs="unbounded"/>
    		<xsd:element name="creationTimestamp" type="xsd:dateTime"/>
    		<xsd:element name="expiryTimestamp" type="xsd:dateTime" minOccurs="0"/>
    		<xsd:element name="partyMessageInformation" type="PartyMessageInformation"
    minOccurs="0" maxOccurs="unbounded"/>
    		<xsd:element ref="dsig:Signature" minOccurs="0" maxOccurs="unbounded"/>
    	</xsd:sequence>
    </xsd:group>

The content of Requests, Responses, and Notifications Message Headers differ in the inReplyTo element so it is not included in the model group. Each specific type would control the existance and cardinality of the inReplyTo element. The role of each element is given below.

- conversationId allows a message sender to create a common context for a number of separate message exchanges.
- messageId contains the senders unique identifier for a message.
- inReplyTo contains the unique identifier for the request message that is being responded to.
- sentBy identifies the system or party sending a message.
- sendTo identifies the systems or parties who will receive a message and should act upon it.
- copyTo identities other systems or parties who will receive a message but who do not have to act upon it.
- creationTimestamp describes the time when the sender created the message.
- expiryTimestamp defines a time after which the sender will consider the message expired.
- dsig:Signature allows the inclusion of W3C digital signatures within the message.

The validation element in the Message type contains the URI for a set of additional validation rules to be applied to the document during processing.

#### 3.2.3 Requests, Responses and Notifications

The following image shows the construction of just one message style type, as with in the exception of the type of the header element, they are all the same.

    <xsd:complexType name="RequestMessage" abstract="true">
    	<xsd:complexContent>
    		<xsd:extension base="Message">
    			<xsd:sequence>
    				<xsd:element name="header" type="RequestMessageHeader"/>
    				<xsd:group ref="Validation.model"/>
    			</xsd:sequence>
    		</xsd:extension>
    	</xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="RequestMessageHeader">
    	<xsd:complexContent>
    		<xsd:extension base="MessageHeader">
    			<xsd:sequence>
    				<xsd:group ref="MessageHeader.model"/>
    			</xsd:sequence>
    		</xsd:extension>
    	</xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="ResponseMessage" abstract="true">
    	<xsd:complexContent>
    		<xsd:extension base="Message">
    			<xsd:sequence>
    				<xsd:element name="header" type="ResponseMessageHeader"/>
    				<xsd:group ref="Validation.model"/>
    			</xsd:sequence>
    		</xsd:extension>
    	</xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="ResponseMessageHeader">
    	<xsd:complexContent>
    		<xsd:extension base="MessageHeader">
    			<xsd:sequence>
    				<xsd:element name="inReplyTo" type="MessageId"/>
    				<xsd:group ref="MessageHeader.model"/>
    			</xsd:sequence>
    		</xsd:extension>
    	</xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="NotificationMessage" abstract="true">
    	<xsd:complexContent>
    		<xsd:extension base="Message">
    			<xsd:sequence>
    				<xsd:element name="header" type="NotificationMessageHeader"/>
    				<xsd:group ref="Validation.model"/>
    			</xsd:sequence>
    		</xsd:extension>
    	</xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="NotificationMessageHeader">
    	<xsd:complexContent>
    		<xsd:extension base="MessageHeader">
    			<xsd:sequence>
    				<xsd:element name="inReplyTo" type="MessageId" minOccurs="0"/>
    				<xsd:group ref="MessageHeader.model"/>
    			</xsd:sequence>
    		</xsd:extension>
    	</xsd:complexContent>
    </xsd:complexType>

#### 3.2.4 Error Handling

If a message cannot be processed for some technical reason such as: it has become corrupted, is not XML or is not a valid FpML message, then the receiver returns a 'MessageRejected' message to the sender. Usually the message will require manual intervention to diagnose and solve any problems. Such rejections will not be show on any of the diagrams in this paper.

If the message cannot be processed because the request is invalid, given the state of the data to which it applies, then an appropriate business level notification is returned to the sender (e.g. 'TradeNotFound', 'TradeAlreadyMatched', etc.) which in turn could be used to invoke either an automatic recovery or a manual intervention.

The design of the rejection message allows for the inclusion of multiple computer readable error descriptions. Each error is described by a collection of elements with the following interpretation:

- The reasonCode element contains a numeric code (taken from a standard list) which outlines the kind of error detected.

- The location element contains either a line and column number (separated by a comma) or an XPath expression. The value of the locationType attribute defines which type of location has been given. It may take the values 'lexical' or 'xpath'.

- The description element contains human readable text detailing the error.

- If the error is the result of a violation of a validation rule then the element validationRuleId contains the rule's identifier (e.g. 'ird-1').

- The additionalData element may contain extra information useful in diagnosing the reason for failure.

Another additionalData element is associated with the MessageRejected message after the error list to allow the source for the failed XML document to be returned. A CDATA section must be placed around the source message to prevent its interpretation as XML content. The following diagram shows the design for the complete message.

In order to encapsulate one XML message within another the addition data section would have to use an XML CDATA encoding to prevent the parser from attempting to process the contents.

Message rejections may use any of the following list of error codes to indicate the reason for failure. Institutions may define their own additional error codes in the numeric range provided for user errors.

Level 100: Message transport and delivery problems

- 100: Default transport error code
- 101: Transport unavailable
- 102: Unknown recipient/destination
- 103: Delivered to wrong recipient
- 104: Timeout - message delivered past expiration
- 105: This type of message not accepted on this transport
- 106: Message generation problem (e.g. data conversion)
- 110: Message corrupted (e.g. CRC failure)
- 111: Message text doesn't match digital signature hash

Level 200: Message Integrity and Processing problems

- 200: Default message processing error code
- 201: Lexical problem - not well-formed XML
- 202: Unsupported character set
- 203: Empty or missing content
- 204: Content too large
- 210: System unavailable
- 211: Message component text doesn't match digital signature hash

Level 300: Message Validation Problems

- 300: Default validation error code
- 301: Unknown or unsupported DTD/Schema
- 302: Unsupported FpML version
- 303: Invalid FpML message - message doesn't validate w.r.t. specified DTD/schema
- 304: Validation failure - unsupported message type
- 305: Validation failure - mandatory FpML rule (a rule we say must always be followed)
- 306: Validation failure - master agreement rule (a rule 2 parties agree to follow)
- 307: Validation failure - business policy (a rule that only the recipient has)
- 308: Validation failure - unsupported product/asset
- 310: Signature required - message content must be signed
- 311: Signature not accepted - problem with message signer (cert revoked, unacceptable principal, etc.)

Level 400: Business Process/Workflow Problems

- 400: Default business process error code
- 401: Don't know - unrecognized trade
- 402: Suitability - trade can't be done for client or dealer suitability reasons
- 403: Credit - trade can't be done for credit reasons
- 404: Not interested - recipient chooses not to respond
- 410: Message arrived too late - e.g. trade no longer exists
- 411: Message expired - message arrived on time, but a response was not generated in time

Level 500: User Defined

### 3.3 The Business Processes

FpML releases to date have concentrated on defining only product structure. These products are the key part of many messages but in order to have a meaningful 'conversation' additional information is required to express the action that the message sender believes the message receiver should perform upon receipt of the message. Usually a key data structure like a product and/or party is the main component of the data that accompanies the request but for some actions additional parameters may need to be included.

#### 3.3.1 B2B Request for Quote

This section outlines a process for requesting and obtaining a quote for a trade prior to entering into a full contractual trade. The processes shown are based on those in use today in markets that already have an established electronic market.

Within this section well shall refer to two types of market participant, namely:

- Market Makers

  Dealers who will typically provide either a one or two way price on a given financial instrument.

- Market Takers

  Traders who will typically request and subsequently trade on prices provided by market makers.

A request for quote process could be conducted directly between a market maker and a market taker (e.g. Citigroup's 'CitiFx FX Benchmark' service) or more commonly through an electronic exchange or trading portal where several market makers may quote on the same request.

##### 3.3.1.1 Product Specification for RFQ

The specification of products in request for quote messages is different than for those in post trade messages. The product may be more ambiguous (e.g. it may not specify whether it is a buy or sell) and irrelevant settlement specific data can be omitted.

The 'symmetric' nature of FpML product specifications creates some additional problems when considering their generalization into pre-trade messages. FpML avoids the use of simple 'buy' and 'sell' indicators by associating parties with components of a product and indicating their obligation (i.e. payer or receiver). However this approach has three problems in the pre-trade space.

- Anonymity

  In some negotiations the identity of the market taker may not be known until an agreement has been reached. FpML requires party information within a product specification to identify obligations. An identity could only be hidden if a standard 'dummy' party was allowed in negotiation messages.

- Multicasting

  A market taker may request quotes on the same product from many market makers. Given the current definitions the product definition would need to be customized for each potential recipient. Alternatively another 'dummy' party could be used to represent any maker.

- Two Way Quotes

  In many negotiations the intent of the market taker is unclear and market maker provides both a buy and a sell price. The use of party to identify obligation in an FpML product means that can only have one interpretation (i.e. it is either a buy or a sale, it can never be both).

It is clear that if the current style of product definition is to be used for pre-trade then some additional conventions will need to be adopted.

Whilst it would be possible to generalize the current post trade definitions by making some of the current elements optional (so they could be excluded in RFQs) and the addition of extra optional elements of quote specific data this would lead to possibility that RFQ products could appear in post trade messages (and vice versa). Syntactically such messages would be valid and extra validation rules could need to defined to detect this semantic error.

A simpler solution would be to define a new set of product definitions specifically for pre-trade messages based on a similar framework as is used for the existing post-trade products. To implement this a new global element and base type are needed to serve as the attachment point for substituting definitions.

Given these definitions quotable versions of the existing products can be created, for example for FX:

Using this definition it is possible to express the intention of the transaction (e.g. the currencies, delivery date(s) and notional amount) whilst leaving other values (i.e. the exchange rate) out.

    <quotableFxSingleLeg>
      <exchangedCurrency>
        <paymentAmount>
          <currency>GBP</currency>
          <amount>1000000</amount>
        </paymentAmount>
        <paymentDate>
          <unadjustedDate>2003-07-25</unadjustedDate>
          <dateAdjustments>
            <businessDayConvention>FOLLOWING</businessDayConvention>
            <businessCentersReference href="CENTERS"/>
          </dateAdjustments>
        </paymentDate>
     </exchangedCurrency1>
      <exchangeRate>
        <quotedCurrencyPair>
          <currency1>USD</currency1>
          <currency2>GBP</currency2>
          <quoteBasis>CCY1PERCCY2</quoteBasis>
        </quotedCurrencyPair
      </exchangRate>
    </quotableFxSingleLeg>

By keeping the quotation product definition close to that of the post-trade product (e.g. using the same element names and ordering) a responding message can be constructed by copying sections of the input message (e.g. parts of the parsed DOM tree representation) and enriching it with any required data to form the full product definition.

In order to create the example definition for FX two other definitions had to be generalized, namely QuotablePayment (from Payment) and QuotableMoney (from Money). These definitions have no direct relationship with their fully formed partners, they are simply modified copies of the original XML schema definitions, although it would be possible to define them using 'inheritance by restriction' (e.g. Money could be inherited from QuotableMoney making the amount element mandatory, Payment and QuotablePayment could be derived from some generic common base class).

##### 3.3.1.2 Bilateral Request for Quote

This section describes the follow of messages required in a bilateral exchange directly between a market maker and a market maker. It is assumed that market maker operates two systems to support his trading business: one to manage his communication with market takers (the quotation system) and one to record transactions (the trading system). The features of these two logical systems could reside in a single physical implementation.

The following diagram shows the sequence of message exchanges (including an additional flow for a quote update) under normal operation.

The role of each of the messages is as follows:

- The market taker sends the quotation system a RequestQuote message describing the properties of the transaction in which he is interested in. The quotation system forwards the message on to the market maker for attention. The RequestQuote message uses the QuotableProduct definition to allow the product to be loosely defined.

Note that the message allows more than one product be to included to allow a number of quotes to be request simultaneously.

- The market determines either a one-way or two-way price for the product and the left of time for which that quote will be honored and returns it to the market taker via the quotation system. The market marker can quote for a subset of the requested products (or none of them by not responding at all).

- The market taker accepts the quote and informs the quotation system of which quote (if the price was two-way) was taken by returning a fully formed trade (possibly containing the market takers settlement information). The quotation system forwards the acceptance to the trading system.

- The quotation system should ensure that details of the trade within the AcceptQuote match the quotation provided earlier and that the quote is still valid.

- When the trading system confirms its acceptance of the transaction by returning it in a TradeExecution message, informing each party that the trade is complete.

The role of the quotation system in the above processing is to ensure that both market makers and market takers are treated fairly during the quotation process, by maintaining an audit record of message from both parties in order of arrival.

In practice the negotiation of a rate or price for a transaction may require more message exchanges than shown in the last example and there are a number of different outcomes that can occur, namely:

- The market taker may choose not to act on the quote, leaving it instead to expire at the time designated by the market maker.

- There are no messages to inform parties of the expiration of a quote, rather it is discovered by exception when a stale quote is acted upon (shown later).

- The market maker may choose to refine a previously made quote to reflect a change in market conditions. A marker taker may be tempted to trade on the new quote (as shown in the following diagram) or may leave it to expire or be cancelled.

- The market taker may re-request a quote for the same product for which he requested an earlier quotation. If the earlier quotation is still active then the request could be ignored or an update sent to original request. If the quote has expired then the normal quotation process is repeated.

- A market taker may attempt to take up a quotation after it has become expired. This could be accidental or caused through synchronization issues between the systems (e.g. differences between system clocks, message delays or processing order).

#### 3.3.2 Trade Execution

This section contains the set of messages to report a new block trade and to modify or cancel the report.

##### 3.3.2.1 TradeExecution

This message is used to report the execution of a block-level trade. Its content model is similar to the previous TradeCreated message, which was deprecated in FpML 4.2. It is also similar to an NOE (Notice of Execution) in FIX.

It contains a trade and 2 or more parties.

##### 3.3.2.2 TradeExecutionModified

This message is used to report a modification to a previously-reported trade execution.

Content model includes:

- optionally, the original version of the trade, or just an identifier
- the revised version of the trade
- 2+ parties

##### 3.3.2.3 TradeExecutionCancelled

This message is used to cancel a previously reported trade execution, e.g. if the trade was raised in error.

Content model includes either a trade identification section or a complete trade, plus one or more parties.

##### 3.3.2.4 Workflows

##### 3.3.2.4.1 TradeExecution within the Trade Lifecycle

The TradeExecution message could be the first message in a flow, or could happen as the result of a previous RFQ process.

In the case of an RFQ, the 'QuoteAcceptanceConfirmed' message of FpML 4.x has been deprecated in 4.4, and removed in version 5.0, and the TradeExecution message must be used in its place.

The TradeExecution message would typically be followed by an allocation process, initiated by the RequestAllocation message.

The following diagram illustrates the overall flow of an RFQ, Trade Execution, and Allocation process:

##### 3.3.2.4.2 Correction and cancellation flow

In the case of an error in the original TradeExecution message, the TradeExecutionModified message is provided to correct the details.

The following diagram illustrates the scenario where a trading platform reports an execution, then corrects it twice (presumably due to an interaction out of scope of this diagram, such as GUI interactions), then finally decides that the trade was raised in error and cancels it.

#### 3.3.3 B2B Trade Affirmation

Within the context of FpML, trade affirmation is considered to be a notification of trade execution. An affirmation message may be sent internally or externally after the trade negotiation has completed. At this point the trade may not have been legally confirmed between the two principal parties. Trade affirmations may also be sent by a third party, e.g. a broker, to the principal parties involved.

##### 3.3.3.1 The Affirmation Process

There are a few basic patterns that are used in the industry today for delivery of trade affirmation messages. In all cases the workflow is basically the same. That is, a notification message is sent from a trading system (either an internal/external system or broker) followed by an acknowledgement of receipt (response message) from the message receiver. Acknowledgement of receipt is used to complement the asynchronous nature of the affirmation message and to assure that the message is not deleted from the originating system prior to being persisted in the destination system.

The following sequence diagram illustrates the process for one side of a bilateral affirmation. Both parties to the trade may be executing this process to obtain an affirmation from each other.

The affirmation message typically contains the same information that is contained in a trade confirmation message. Some details, such as settlement information, could be omitted if it is unknown to the affirmation sender. The following diagram shows the content model for a 'TradeAffirmation' message.

The response to the affirmation message indicates its acceptance and indicates the transaction to which it applies. The content model for it is as follows:

If the trade affirmation is being generated by a third party, such as a broker, then affirmation could be sought from one side and then the other, or from both simultaneously as shown in the following diagram.

The data content of the messages is the same as in the bilateral case.

#### 3.3.4 B2B Trade Confirmation

Today the procedure for achieving trade confirmation is manual for most OTC derivative transactions. Principally this is because the information describing the economic and legal liabilities of the transaction are embedded within a native text document and set amongst legal wording. A skilled human reader is needed to extract and compare the relevant information to determine if it matches the bank's own definition of the same deal.

This section describes how the process of trade confirmation for OTC derivatives might be achieved electronically through the exchange of a sequence of 'messages' between the two parties' computer systems. This can only take place if the parties involved have identified and 'marked-up' the salient details of the transaction using a common vocabulary of terms and data structure, such as those provided by the FpML product definitions.

##### 3.3.4.1 The Confirmation Process

There are two common styles for trade confirmation used by the finance industry today:

- Bilateral confirmation models the current manual process where one party (the confirmation requester) creates a legal definition of the trade, signs it and sends it to the other party (the confirmation provider) who checks and then countersigns the document and returns it.

- This countersigned document becomes the legally binding definition from the transaction once it has been acknowledged back to the requester.

  Both parties might be attempting to obtain a confirmation from the other with this method at the same time.

- Trilateral confirmation involves both parties to a trade each generating and sending a copy of the agreed upon trade to an independent third party. When the third party determines that two trades match it sends an identical trade representation to both parties to confirm the match.

- The trade description generated by the confirming service becomes the legally binding trade representation.

##### 3.3.4.2 The Matching Process

Matching and comparison are central to confirmation process. In basic terms the matching operation is carried out as follows.

Each new request to confirm a trade results in a search of the system's set of currently unmatched trades to determine if a viable match exists. A trade is comprised of a set of data items that describe its properties and each one of these in turn falls into one of following three categories:

- Identifying financial items that, if present, must exactly (or within tolerance) match (e.g. common trade identifier, trade date, maturity, product type, currencies, notional amounts, parties, etc.).
- Non-identifying items that should exactly (or within tolerance) match (e.g. business centers, date roll conventions, etc.).
- Items irrelevant to the matching process (e.g. comments).

As a result of the matching process a trade is said to be:

- Matched - If all identifying and non-identifying items agree.
- Mismatched - If all identifying items agree but the non-identifying items differ.
- Unmatched - No match on identifying items could be found.

If a trade is matched then both descriptions of a trade are fully reconciled and the parties can agree that it is confirmed. If the trades contain identification information that shows that they should have matched but other significant details differ then the trade is mismatched.

If no match was found then the system must assume that it is yet to receive a copy of the trade from the other party and should add it to the set of unmatched trades and wait for the next request.

Some additional actions are required to prevent trades remaining unmatched indefinitely. There are two cases that can give rise to this situation:

- The counterparty failed to enter and send his definition of the transaction (so no counter-trade exists in the system).
- The counterparty incorrectly identified the true party (in which case a counter-trade exists but will never match).

To attempt to recover from both cases after a trade has remained unmatched for a period of time, the system should send a message to the alleged counterparty in order to provoke them into investigating whether they need to send a new trade or correct an existing unmatched trade.

If after an additional time period the trade still remains unmatched, it should be returned as failed.

##### 3.3.4.3 Bilateral Confirmation

The following sections illustrate the end-to-end sequence of message exchanges required to confirm a transaction directly between two parties and the various outcomes that are possible.

##### 3.3.4.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.4.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.4.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.4.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.4.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.4.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.4.4 Trilateral Confirmation

This section illustrates some processes in action with a third party performing the matching process. In general the sequence of requests and responses is the same as in the bilateral case and there are no additional trilateral specific message types.

##### 3.3.4.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.4.4.2 Mismatch

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

##### 3.3.4.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.4.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.4.4.5 Alleged

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

##### 3.3.4.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.5 B2B General Processes

##### 3.3.5.1 Trade Status Enquiry

At a number of points in the confirmation process it is possible that one or the other or both parties to a transaction received an unexpected error message from the other or the central service.

In order to determine the correct course of action to recover from such an error the participants need to determine the perceived state of their transaction within the other party's systems. This indicates that a simple status enquiry operation would be required to recover the necessary information.

For efficiency the trade status enquiry message should allow more than one transaction to be checked at a time (e.g. all outstanding unmatched trades, etc.). Its content model is as follows:

The response message returns each identifier with a suitable status code value (i.e. unmatched, matched, confirmed, not known, etc.).

#### 3.3.6 A2A Trade Updates

Most financial institutions use a collection of systems to manage their trade portfolios, usually with each system providing functionality specific to either a financial product (e.g. foreign exchange, equity, money markets, etc.) or part of the trade processing lifecycle (e.g. trading, risk management, settlement, etc.).

As consequence of this distribution of function, information must be transferred between systems in order to facilitate the administration and execution of the transactions over time. In order to maintain consistency between the master copy of a transaction and any replicas of it that may have been created in other systems any change that is applied to the master copy must be notified to the downstream systems so that they too may (if appropriate) update to reflect the change.

Changes to transactions occur for two primary reasons, namely:

- Human error may have caused a discrepancy in the values which parametrically describe the transaction and may be subsequently discovered and corrected.
- Manual or automated processing related to behavior of the financial product may cause the transaction to change (e.g. option exercise, maturity, etc.)

There are two common ways in which notifications for transaction changes are constructed. One approach is to consider having only two message types, one to indicate the creation of a transaction and another to cause its deletion. In this style an update would be considered to be a deletion of the old transaction image immediately followed by a re-creation of the transaction its new state. Such a protocol will allow the accurate transfer of information between two systems but it fails to relate the two events making it hard to see what the actual cause of the change was.

A better approach is to have a family of messages, each customized to a specific event so that the receiver can adjust its representations of the affected information and at the same time record a connection between the affected items. Such messages can be processed 'atomically' taking the data from one consistent state to another, and at no time leaving the changes incomplete.

The following diagram shows the processing sequence shared by all such notifications. Note that in a real environment the notification message is more likely to be 'multicast' to a number of receivers rather than just one as in the example and/or may pass through some intermediate routing service.

#### 3.3.7 A2A Generic Trade Notifications (Deprecated)

The A2A Trade Notifications messages have been deprecated. See Contract Notifications section for new meessages replacing them.

##### 3.3.7.1 Trade Creation (Deprecated)

When a system that acts as source of trade information detects that a new trade has been created it should create and send a TradeCreated notification to inform downstream systems.

##### 3.3.7.2 Trade Amendment (Deprecated)

When a system that acts as source of trade information detects that an existing trade has been modified it should create and send a TradeAmended notification to inform downstream systems.

##### 3.3.7.3 Trade Cancellation (Deprecated)

When a system that acts as source of trade information detects that a previously existing trade has been cancelled it should create and send a TradeCancelled notification to inform downstream systems.

#### 3.3.8 Novations

##### 3.3.8.1 Introduction

This section looks at how the entire trade novation process can be represented as an exchange of FpML based messages between parties.

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 process model for novation has been split into two sections.

- During the discovery stage the parties negotiate the details of the novation (e.g. the amount to be novated and any payment required in return) and consent for the novation is obtained from each party.
- Assuming consent has been obtained then in the second stage the negotiated details are acted upon and the actual transfer of rights and obligations is performed.

As the negotiation today is largely conducted by telephone the first stage of the process is optional and processing can begin directly with the second stage.

##### 3.3.8.2 The Novation Process

Scenario:

Institutions ABC (the ‘transferor’) and DEF (the ‘remaining party’) have previously negotiated and confirmed a transaction of some kind. ABC now decides that it would like to novate all or part of the transaction to a third party XYZ (the ‘transferee’).

The following diagrams assume direct and reliable communication between all of the parties (possibly through some central hub).

##### 3.3.8.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.8.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.9 Terminations

The Termination representation in FpML is used for decreasing the notional value of a trade or fully terminating the trade.

The trade element allows the details of the underlying trade to be specified. Alternately, the tradeReference can be used to reference the previously confirmed trade. The terminationTradeDate is the date on which the the parties enter into the termination transaction. The terminationEffectiveDate is the date on which the termination becomes effective.

To indicate a full termination the “full” element is used. Alternately, for partial terminations the “partial” element is used. Depending on the type of product, the amount of the decrease is specified in the decreaseInNotionalAmount or decreaseInNumberOfOptions elements. Similarly, the outstanding amount of the trade after the partial termination is specified in the outstandingNotionalAmount or outstandingNumberOfOptions elements.

A payment for the right of termination may occur.

##### 3.3.9.1 Negotiation Messages

FpML defines simple request/response messages for negotiating Terminations:

TradeTerminationRequest is a request message for requesting a Termination. TradeTerminationResponse is a response to the request for Termination.

##### 3.3.9.2 Confirmation Messages

FpML defines a request and a notification message for confirming Terminations:

RequestTerminationConfirmation is used for requesting that the contained termination be put forward for matching and confirmation.The TerminationConfirmed (notification) message is generated when a Termination is determined to be confirmed.

#### 3.3.10 Increases

The Increase representation in FpML is used for increasing the notional amount of a trade.

The trade element allows the details of the underlying trade to be specified. Alternately, the tradeReference can be used to reference the previously confirmed trade. The increaseTradeDate is the date on which the parties enter into the increase transaction. The increaseEffectiveDate is the date on which the increase becomes effective.

Depending on the type of product, the amount of the increase is specified in the increaseInNotionalAmount or increaseInNumberOfOptions elements. Similarly, the outstanding amount of the trade after the increase is specified in the outstandingNotionalAmount or outstandingNumberOfOptions elements.

A payment for the right of increase may occur.

##### 3.3.10.1 Negotiation Messages

FpML defines simple request/response messages for negotiating Increases:

TradeIncreaseRequest is a request message for requesting an Increase. TradeIncreaseResponse is a response to the request for an Increase.

##### 3.3.10.2 Confirmation Messages

FpML defines a request and a notification message for confirming Increases:

RequestIncreaseConfirmation is used for requesting that the contained increase be put forward for matching and confirmation.The IncreaseConfirmed (notification) message is generated when an Increase is determined to be confirmed.

#### 3.3.11 Amendments

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 tradeReference is insufficient for providing the amended trade details and is not allowed.) The amendmentTradeDate is the date on which the parties enter into the amendment transaction. The amendmentEffectiveDate is the date on which the amendment becomes effective.

A payment for the right of amendment may occur.

##### 3.3.11.1 Negotiation Messages

FpML defines simple request/response messages for negotiating Amendments:

TradeAmendmentRequest is a request message for requesting an Amendment. TradeAmendmentResponse is a response to the request for an Amendment.

##### 3.3.11.2 Confirmation Messages

FpML defines a request and a notification message for confirming Amendments:

RequestAmendmentConfirmation is used for requesting that the contained amendment be put forward for matching and confirmation.The AmendmentConfirmed (notification) message is generated when an Amendment is determined to be confirmed.

#### 3.3.12 Allocations

Allocations are the division of a single market trade across two or more investors/funds.

##### 3.3.12.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.12.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.12.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.12.1.3 Examples

This is an analysis of the different situations:

Example:

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

##### 3.3.12.1.3.1 Normal Trade

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

##### 3.3.12.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 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>
                                                            ...

##### 3.3.12.1.3.3 Block Trade that is identified upfront without knowing the allocated trades

The trade is identified as block trade (xsi:type="BlockTradeIdentifier) but there aren't links to the allocated trades (no allocationTradeId elements appear).

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

##### 3.3.12.1.3.4 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 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>
                                                            ...

Allocated trade ABC102:

                                                            ...
    <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.12.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.12.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.12.2 AllocationCreated, AllocationAmended, AllocationCancelled

This section introduces three generic A2A allocation messages in FpML. Each one of these is a notification message sending an allocation (represented as collection of trades). This allocation is a group of trades identified as block or allocated trades. The identification of these trades is done using the linking mechanism described above in order to identify and to link block and allocated trades in FpML.

The implementation introduces three notification messages named AllocationCreated, AllocationAmended, and AllocationCancelled. The structure of these messages is very similar to the existing “generic A2A notification messages” called TradeCreated, TradeAmended, and TradeCancelled messages. However, instead of sending a single trade, the new allocation messages are sending a collection of trades.

This is the proposed schema structure:

AllocationCreated:

AllocationAmended:

AllocationCancelled:

##### 3.3.12.3 Allocations - Short Form Representation

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.

Example:

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

##### 3.3.12.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.13 Cashflow Matching

The FpML standard for cashflow matching is aimed at providing a messaging standard to support the ISDA guideline developed by the ISDA Operations Committee.

##### 3.3.13.1 Model Overview

Its purpose is to provide a general framework that the industry service providers as well as the various financial actors in the marketplace should use to support their cashflow reconciliations on OTC derivatives. Because of the wide range of expected usage scenarios as well as products involved, this standard has been developed as a flexible paradigm: the schema is largely made of optional nodes and elements, while this guideline document opens the possibility of using only part of the framework.

The scope of this standard is to support the following spectrum of use cases:

- The complete range of OTC products that are supported by the FpML standard;
- The matching of cashflows by industry service providers that provide a multilateral relationship with an implied level of sophistication in terms of underlying state transition structure, as well as, on the other end of the spectrum, simple bilateral reconciliation of cashflows among specific actors;
- Intra-day matching, where sets of cash flows are sent incrementally and resulting messages with the matching statuses are received immediately, as well as end-of-day (or, more generally, and-of-period) matching processes.

The standard for cashflow matching does not cover at this point the process of cashflow netting among counterparties. The underlying implication of the standard is each party will present to the matching process netted payment when applicable within a trade. Payment netting across trades is however outside of the scope of this standard at the present time.

This section is organized as follows:

- Design principles
- Messaging and schema structure
- Usage guidelines

##### 3.3.13.2 Design Principles

This standard for cashflow matching has been specified by the FpML Business Process Group in the course of 2005 and early 2006, as a follow-up from the earlier high-level guidelines developed by the ISDA Operations Working Group.

The following design principles have guided this standard:

- Synergies with the other components of the FpML standard:

  The cashflow matching standard is positioned as an additional component of the FpML standard. As such, it leverages the building blocks that are part of this standard and is compatible with those other components. As a result, it is expected that the actors of the marketplace will leverage their existing FpML product implementations to support their cashflow matching reconciliation.

- Product support:

  The FpML representation of cash flow matching is designed to support all OTC derivatives products. The representation is flexible and generic in order to accommodate the different product features. Also, the aim being to reconcile cashflows as opposed to trade characteristics, the trade features that are part of this standard have been strictly limited to (i) those that are deemed appropriate for identifying the supporting trade, and (ii) the calculation details that support the exposed cashflows.

- Supported cashflows:

  The current version of the standard is focused on reconciling known cashflows (as opposed to partial calculation and/or observation elements that will get refined over time until the cashflow is finally known) within the context of a trade. As a result, cashflows that would result from cross-trade netting are not supported by this standard. It is expected that if two parties would have a netting agreement across contracts for the purpose of decreasing their settlement exposure, they would use this standard for reconciling their individual cashflow components while agreeing through a different framework regarding the actual settlement amount.

- Matching window:

  The high-level guideline developed by the ISDA Operations Working Group recommends that “The window for inclusion into the matching process is to be based upon the next known cashflow date, subject to certain rules”. The recommended FpML standard is that, in addition to systematically reconciling the next known cashflow within a given trade (whether it is 1 week or 1 year out),the parties should also reconcile any known cashflow within a window of 20 business days. Such calendar month is indeed considered as the operational window where the parties should systematically match any known cashflow, including those that come is rapid upcoming succession.

- Cashflow granularity:

  The high-level guideline developed by the ISDA Operations Working Group recommends that “Each cashflow leg forming part of a trade should be matched independently.” The FpML Business Process Working Group expressed the concern that this might cause issues in the case of less vanilla OTC derivatives, as it would imply that the various parties have a similar modeling approach for the trade. As a result, the FpML standard recommends the matching, within each trade, of the cashflow that the counterparty intends to settle, with the gross cashflow component(s) being provided as an underlying calculation detail. Considering the industry practice of reducing settlement risk by netting cashflows whenever practically possible, this means that in most of the cases netted cashflows per payment date and currency should be reconciled (netted float vs. fix in the case of interest rate swaps, netted price, interest and dividend components in the case the reset or unwind of a total return swap, etc.). In the fewer cases where two counterparties would, for example, intend to settle separately their fixed and float legs, they would expose these two cashflows independently.

- Identification of trades:

  For addressing 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 FpML standard provides the ability to identify this trade through a meaningful set of standard economic details: dates, notional and underlying asset. This set of attributes has been limited in order to avoid the bias of focusing the reconciliation on trade attributes instead of cashflows elements.

- Sequence of messages:

  The standard suggests that the following workflow sequence will be applied for reconciling cashflows related to OTC derivatives contracts in the case where a central matching service will be involved:

  - Either Matching Requester sends a TradeCashflowsAsserted including the set of net payments (each one uniquely identified) that need to be reconciled to the Matching Service as of a specific date trade. Initially, non-previously submitted sets of payments are at the Pending state. The message can be rejected if it doesn’t correlate, which would imply sending a MessageRejected and the submitted set would go to a rejected state.

  - Once the matching process is performed the matching service sends a CashflowsMatchResults message. This message includes a list of all matched, mismatched (with proposed matches), and unmatched set of payments. Alleged and unmatched net payments are the same state but from different sides. So the status of the cashflow changes from Pending to Unmatched, Mismatched, or Matched depending on the matching results.

  - The set of payments can be cancelled (removed) from the process using a CancelTradeCashflows message.

  - A broken matched is a transition from matched but it’s not a state in the workflow. The broken matched status has been suggested as part of the ISDA high-level standard for Cash flow Matching, Netting, and Settlement. However, from a modeling perspective, this is considered a transition between two different states.

  - If a payment is unmatched or mismatched while it reaches the stated payment date, it moves to Expired state.

  See Annex B for state diagram of the process.

##### 3.3.13.3 Messaging and Schema Structure

##### 3.3.13.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.13.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.13.3.3 CancelTradeCashflows

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

##### 3.3.13.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.13.4 Usage Guidelines

The FpML schema that supports the cashflow matching standard has a quite loose grammar control: a large number of elements are made optional, while there a significant reliance on values that are specified through schemes that are external to the scheme (as opposed to stricter enumerations).

As stated in the introduction to this document, this is because this standard is aimed at supported a wide range of use cases.

As a result, a set of usage guidelines are being provided thereafter, which adoption is left to the discretion of the respective implementers. Also, a set of examples in the form of xml files have been developed, which illustrate those usage guidelines.

The examples can be found at http://www.fpml.org/spec/2006/wd-fpml-4-2-2006-02-15/html/fpml-4-2-examples-frame.html

##### 3.3.13.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.13.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.13.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.5 Annex A: Class Diagram

##### 3.3.13.6 Annex B: State Machine Diagram

#### 3.3.14 Portfolio Reconciliation

##### 3.3.14.1 Introduction

This section describes the specification to support trade reconciliation as described in the recent ISDA Operations Committee paper Recommended Practices for Portfolio Reconciliation. It details the reconciliation scenarios that it has been designed to support and required assumptions and goes on to define the ‘protocol’ that allows their execution through the exchange of electronic messages between participating parties.

The main drivers for these enhancements are the best practices stated by the ISDA Operations Committee and the work developed by the Data Standards Working Group (DSWG), a group of US hedge funds that developed a position reporting format based on FpML. The FpML portfolio reconciliation integrates this position representation into its framework.

##### 3.3.14.2 Model Overview

The objective of portfolio reconciliation is to ensure that two organisations have consistent record for a given portfolio by comparing descriptions of the portfolio content provided by each participant.

The result of the reconciliation process is a report describing where the two content descriptions are in agreement and just as importantly where they disagree (e.g. additional/missing transactions, different values, etc.).

The reconciliation process itself can be performed in several different ways. The following sections describe the key areas of variation.

##### 3.3.14.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.14.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.14.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.14.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.14.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.14.3 Design Principles

Although reconciliation occurs between pairs of parties, for the purposes of defining the communications protocol we need only consider the data exchanges that occur between a single requesting party and the provider of the reconciliation service.

In terms of design inputs, the position representation for portfolio reconciliation is based on the model developed by the Data Standards Working Group (DSWG), which defined a position report message to support daily reporting. The Business Process Working Group decided that it was important to integrate the DSWG representation (already part of FpML in the PositionReport message) into the Portfolio Reconciliation framework.

##### 3.3.14.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.14.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.14.4 Messaging and Schema Structure

This section describes the new types need within the FpML schema to support the outlined design.

##### 3.3.14.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 complete contract details, or an element identifying the version of the position that included the full trade definition, or trade reference (mainly used for reporting purposes), or contract reference .
- 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.14.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.14.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.14.5 Usage Guidelines

The FpML support for portfolio reconciliation aims to support a wide range of scenarios. As a result, a set of usage guidelines are being provided thereafter, which adoption is left to the discretion of the respective implementers. Also, a set of examples in the form of xml files have been developed, which illustrate those usage guidelines.

##### 3.3.14.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.14.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.14.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.14.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.6 Examples

A set of scenarios and examples have been developed. These scenarios and examples are available at the examples section (SCHEMAS and EXAMPLES) - Business Process Examples - Portfolio Reconciliation.

#### 3.3.15 Contract Notifications

With the introduction of the new messages described further in this section we want to make a clearer distinction between the notifications distributed between the active participants in a business process and those who do not play an active role but need to be informed of the outcome.

Participants within a business process typically establish a common context (such as a trade) for their messages and can often abbreviate their communications through the use of reference identifiers rather than having to pass complete data descriptions every time.

Downstream participants (i.e. not directly involved in the business process) typically do not see any of this communication and the final notification most likely is the first time downstream participants see the affected business data. To simplify their processing it is often better to send them a summary of the business process that contains both the initial and final states of the affected data.

Since FpML release 4.0 the schema has included some basic trade notification messages which where described as ‘Application to Application’ (A2A). The use of these messages (e.g. ‘TradeCreated’, ‘TradeAmended’ and ‘TradeCancelled’) is deprecated and that the notification message types described in this section are used instead.

##### 3.3.15.1 Contract vs. Trade

Historically in FpML, there was no distinction between “trade” and “contract”.

However, the term "trade" should only be used to refer to the trading event and the resulting trade specifications. From there on all changes to the contracts should not be called trades, nor should the contract itself.

Trade is the transaction between a buyer and seller. Contract is the legal agreement that governs the transaction. In the contract, we can reuse the same information that details the transaction, but the contract is the legal agreement between the parties. Trade has been overloaded in FpML to cover the meaning of a contract, but that’s a mistake. Parties amend contracts, novate contracts, terminate contracts, increase contracts, not trades.

In order to allow for this distinction, a new definition of Contract has been introduced. The contract content is similar to the existing FpML trade content model but some elements have been omitted since they are not relevant for the contract definition. The omitted elements include:

- brokerPartyReference: this is a single reference to a party. The model doesn’t support brokers acting on behalf of multiple parties.
- tradeSide: even though there is a need to support roles within the contract model, the current tradeSide model needs to be reviewed in order to make sure that it supports only the relevant information for contracts. This will be done in a later phase.

##### 3.3.15.2 Contract Identification

##### 3.3.15.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.15.3 ContractCreated

The notification message indicating that a contract has been created at the allocation level. The FpML trade representation has an allocation node, the assumption is that the contract definition is at the allocation level, so no allocation node appears.

##### 3.3.15.4 ContractCancelled

The ContractCancelled notification allows a contract created by mistake to be cancelled entirely.

##### 3.3.15.5 Business Event Notifications

The business events notifications are considered to be ‘facts’ to be acted upon immediately.

This section describes the messages to support notification of full and partial terminations, novations, and increases.

The contract notifications represent an instruction to in some way adjust a contract on an effective date. The act of negotiating the instruction is 'historic fact' but the actual execution of the instruction MAY BE a future action (e.g. to be performed sometime after the instruction has been sent). As a consequence it should be possible to issue corrections or cancellations to the original instruction without needing using compensating transactions.

A simple analogy is a hotel room booking. Having made room booking (e.g. ContractCreated) the client can change the date, type of room, cancel etc. right up until the date that he's supposed to stay (‘instruction execution’). After then his booking is ‘executed’ and he's financially liable regardless of whether he actually stayed or not. If he was to receive a refund for not staying it is likely that it would have to be negotiated and take into account some administration fees (like a termination).

Once the instruction is executed correction and/or cancellation should not be possible and a compensating transaction would have to be issued. When we expand the message set in a future phase it would be possible to include reverse flows for status information (e.g. notification of actual instruction execution) and error conditions (e.g. rejection of corrections to executed instructions).

The pattern of message is simple notification with business errors generated for ‘negative acknowledgement’ conditions.

##### 3.3.15.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.15.5.1.1 ContractFullTermination

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

##### 3.3.15.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.15.5.1.3 ContractPartialTermination

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

##### 3.3.15.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.15.5.2 Novation

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

##### 3.3.15.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.15.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.15.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.15.5.3.1 ContractIncreased

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

##### 3.3.15.5.3.2 ContractIncreasedCancelled

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

Previous | Top | Next
--- | --- | ---