3 BUSINESS PROCESS ARCHITECTURE

3.1 Introduction

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

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

3.1.1 Why Business Messaging?

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

  • Representation

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

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

  • Semantics

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

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

  • Business Process

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

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

  • Transport

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

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

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

3.2 The Messaging Framework

3.2.1 Introduction

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

This new framework does the following:

  • it consistently implements a set of general principles to make it easier to use the messages to implement real business processes

  • it adjusts the representation of parties, accounts, and roles to clarify the purpose of messages and the roles of the parties within a message.

The following section describes the new messaging framework.

3.2.2 Issues in FpML 4 Messaging Framework

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

  • Incomplete message set – in many cases not all messages required to implement a business process are defined in the FpML 4 message set. In particular, many requests lack acknowledgements, exception responses, correction capabilities, and in some cases normal responses. Many generic business processes (such as confirmation) have different levels of completeness depending on the specific event that is being covered.

  • Inconsistent message correlation – different implementations use different features of the FpML 4 framework to link successive messages together, making them incompatible.

  • Unclear processes – it is not always clear how the version 4 messages are to be combined together to fully implement a business process. For example, which message should be used to acknowledge or respond to a request isn’t always defined. While this could in theory be addressed through documentation, because the message set is incomplete, this is difficult to do.

3.2.3 Design Assumptions

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

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

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

3.2.3.2 No Preservation of Message Sequence
  • There is no requirement for message sequence to be preserved over the message transport. Message sequence must not be expected to be repeatable nor predictable.

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

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

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

3.2.3.4 Observable Completion
  • Principle: All requests should result in an "observable completion", that is a clear (observable by the requester) response.

  • Implementation: For each request or notification message there should be at least one defined acknowledgement message. In the case where the response to the request might be delayed pending additional information, the recipient of the request should acknowledge the request. [Should we set a guideline here? E.g. acknowledge if resulting action is likely not to occur within 10 seconds?]

3.2.3.5 Consistent Message Correlation
  • Principle: There should be a single, well-defined way to link successive messages (such as corrections or retractions of requests or notifications). This should not rely on message or transport level information, but rather use business-level information.

  • Implementation: Add an explicit correlation identifier, defined as business object identifier, and a sequence number to link successive messages.

3.2.3.6 Consistent Error Reporting
  • Principle: There should be a standard way of reporting error or exception status for each type of request.

  • Implementation: Ensure that there is an exception message for each message workflow.

3.2.3.7 Consistent correction and retraction mechanism
  • Principle: There should be a consistent way to correct messages containing an error, and to retract (withdraw, cancel) messages when the information is no longer valid or the action is no longer required.

  • Implementation: Correctable messages will contain an "isCorrection" indicator to indicate whether the message corrects a previous message. Retractable messages should have a corresponding message ending with "Retracted".

3.2.3.8 Consistent Processes Across Trades and Post-trade Events
  • Principle: Business processes should work consistently across trading events and post-trade events where possible, so the same messages should be available for each type of event.

  • Implementation: Most messages will be designed to be able to handle multiple types of events, such as new trades and post-trade events. This allows consistent coverage of a number of post-trade events with a number of business processes.

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

3.2.3.9 Transport Characteristics
3.2.3.9.1 Purpose

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

3.2.3.9.2 Layers

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

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

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

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

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

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

3.2.4 Transport Independence

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

From the top down, the four layers are:

images/messaging/FpMLStack.jpg
3.2.4.1 Business Process

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

The FpML Specification models business processes in UML sequence diagrams.

3.2.4.2 Document

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

3.2.4.3 Messaging

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

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

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

3.2.4.4 Transport

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

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

3.2.5 Identification of Purpose

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

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

3.2.5.1 By Namespace (not used by FpML)

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

<?xml version="1.0"?>

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

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

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

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

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

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

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

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

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

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

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

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

3.2.6 General Pattern of Messages

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

  • process request or notification message – to initiate the process. (In some cases the process may be initiated by a notification message rather than a request message).

  • process acknowledgment message – to acknowledge that the request or notification was received.

  • process exception message – to report that a request or notification cannot be processed.

  • process request/notification retracted message – to withdraw the original request or notification.

  • possibly, process-specific response messages

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

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

  • requestConsent – initiating request

  • consentAcknowledgement - acknowledgement

  • consentException - exception

  • requestConsentRetracted – retraction of the request

  • consentGranted - response

  • consentRefused – response

3.2.7 Naming Conventions

Messages follow this naming convention:

  • requestXxx

  • xxxAcknowledgement

  • xxxException

  • requestXxxRetracted

  • xxx[Status] or xxx[Response]

3.2.8 Acknowledgements

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

images/messaging/acknowledgements.png

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

3.2.9 Message correlation

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

schemaDocumentation/schemas/fpml-msg-5-4_xsd/complexTypes/CorrelationId.png

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

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

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

  • Every message will have a unique message identifier.

  • The ‘inReplyTo’ element of a response message (or exception) correlates with the ‘messageId’ of the associated request.

  • The conversationId has been removed.

  • Retransmission of a message for technical reasons (e.g. the last transmission of the request was not acknowledged or rejected) does not change the message identifier.

  • Replication of a message for business reasons (e.g. sending data that has been previously acknowledged) generates a new message identifier.

  • The response to a retransmitted request message should be identical to the original request. (1)

  • At the start of a long running process the initiating participant must create a unique one-time identifier for each process instance and distribute it to the other messaging party.

  • Every subsequent message sent by the requester must contain the process identifier.

  • Messages may contain reference to other business process instances providing their role is clear and unambiguous (e.g. an order MAY reference a previous quotation).

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

3.2.10 Message sequencing

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

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

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

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

schemaDocumentation/schemas/fpml-msg-5-4_xsd/groups/Sequence.model.png

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

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

  • An optimistic message processor should attempt to process the messages in the order they are delivered and unwind actions (or raise exceptions) when conflict is detected.

  • A pessimistic message processor should record the messages but delay their processing for a short period. This provides a time window during which any earlier messages received out of order can be re-sequenced before processing begins.

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

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

schemaDocumentation/schemas/fpml-msg-5-4_xsd/complexTypes/CorrectableRequestMessage.png

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

3.2.11 Correlation ID optionality

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

3.2.12 Other topics
3.2.12.1 onBehalfOf

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

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

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

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

schemaDocumentation/schemas/fpml-shared-5-4_xsd/complexTypes/OnBehalfOf.png

schemaDocumentation/schemas/fpml-shared-5-4_xsd/complexTypes/OnBehalfOf/partyReference.png

schemaDocumentation/schemas/fpml-shared-5-4_xsd/complexTypes/OnBehalfOf/accountReference.png

3.2.12.2 party roles

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

schemaDocumentation/schemas/fpml-doc-5-4_xsd/complexTypes/PartyTradeInformation.png

schemaDocumentation/schemas/fpml-doc-5-4_xsd/complexTypes/PartyTradeInformation/relatedParty.png

 
<someRequest>
...
	<partyTradeInformation>
            <partyReference href="party3"/>
            <relatedParty>
               <partyReference href="party4"/>
               <role>orderer</role>
            </relatedParty>
            <relatedParty>
               <partyReference href="party4"/>
               <role>introducer</role>
            </relatedParty>
            <relatedParty>
               <partyReference href="party3"/>
               <role>executor</role>
            </relatedParty>
            <relatedParty>
               <partyReference href="party4"/>
               <role>confirmer</role>
            </relatedParty>
            <relatedParty>
               <partyReference href="party6"/>
               <role>creditor</role>
            </relatedParty>
            <relatedParty>
               <partyReference href="party5"/>
               <role>settler</role>
            </relatedParty>
            <relatedParty>
               <partyReference href="party6"/>
               <role>accountant</role>
            </relatedParty>
	</partyTradeInformation>
...
</someRequest>
3.2.12.3 separation of party and account

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

schemaDocumentation/schemas/fpml-shared-5-4_xsd/groups/PartiesAndAccounts.model.png

FpML 5.2 and 5.3 introduce new features to better support regulatory reporting requirements. The following table shows which FpML business processes support which types of regulatory reporting requirements.

FpML Views
Message Type Confirmation Reporting Transparency Record Keeping
Real Time X
PET X
Confirmation X
Life Cycle Price Formation X X X
Intrinsic Non Price Formation X X
Daily State X
Valuation X TBD

The different message types have no dependencies except for valuation messages to SDRs that require prior reports to be submitted.

3.4.1 FpML 5 Business Processes

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

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

3.4.2 Transaction life cycle

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

images/messaging/TransactionLifeCycle.png

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

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

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

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

images/messaging/TransactionLifeCycle2.png

3.4.3 Generic (Multi-Event) Flows

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

  • trade
  • novation
  • increase
  • termination
  • amendment
  • optionExercise / optionExpiry
  • deClear

In addition, the "clearing" event can be used in the clearing business processes.

schemaDocumentation/schemas/fpml-business-events-5-4_xsd/groups/Events.model.png

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

3.4.4 Reporting Business Processes
3.4.4.1 Overview
3.4.4.1.1 Purpose

The FpML reporting capability is designed to allow institutions to report details about derivative portfolios with a variety of levels of granularity, in a format consistent with the normal messaging and confirmation specification.

The reporting capability is intended to support a number of use cases, including but not limited to:

  • Regulatory reporting

  • Reporting between counterparties for reconciliation purposes

  • Reporting from service providers to clients on portfolios maintained by the service.

3.4.4.1.2 Reporting View

The FpML reporting messages are provided in the FpML reporting view, which is indicated with the namespace "http://www.fpml.org/FpML-5/reporting".

The reporting view contains essentially the same element definitions as the FpML confirmation view. However, in almost all cases the elements are optional (minOccurs = "0") in reporting view. This allows the creator of the report to decide which elements to include. There are some other slight differences in the product schema between reporting view and confirmation view; these are mostly to prevent ambiguity in the reporting view cause by too many optional elements within choices.

3.4.4.1.3 Field Lists

For a specific report layout, implementations are encouraged to list the required/expected fields using a field list that is validated by the recipient using a validation processor. The field list should be expressed in the form of a table that lists the expected fields and the XPath within the FpML document that contains the expected value. The validation processor can iterate through these XPaths and verify that they are present, and report errors if they are not.

In future drafts of this specification we anticipate publishing field lists for select business reporting requirements.

3.4.4.1.4 Generic Product

To support reporting on derivative products for which no full FpML representation is available, there is a special product called the "genericProduct" (this was formerly known as the "nonSchemaProduct"; that product is still available as a deprecated product name.). This product allows a small number of identifying characteristics to be represented. These identifying characteristics cover key risk attributes of the product, such as:

  • key dates (like effective, termination, and expirations dates)

  • underlying assets

  • strikes or fixed rates

  • notionals

Characteristics that do not have significant impact on the overall market or credit risk of a product are not included and will not be added in the future. These characteristics include:

  • date adjustment rules, conventions, business calendar locations, and lags or offsets

  • fields related to detailed calculation procedures, such as precision, negative rate treatment, etc...

  • fields related to option exercise procedures, such as business calendar location time.

  • fields related to handing of unusual situations, such as extraordinary events.

  • in general, any fields that do not contribute to describing the risk characteristics of the trade

Following are guidelines for use of the non-schema product:

  • nonSchemaProduct should be used only when the product is not adequately covered by the existing FpML product structures.

  • If a non-schema product is used, the asset class and product type should be filled in with descriptions of the product, either using FpML-supplied or implementation-specific codes.

  • When a full FpML product description becomes available for a non-schema product, new implementations should use that in preference to the non-schema product, and existing implementations should attempt to phase out uses of the non-schema product over time as they are maintained.

3.4.4.2 Description of the Processes
3.4.4.2.1 Position and Activity Reporting

The position report was introduced in FpML 4.x in the Pricing and Risk area. It allows a firm to report on the open positions contained in a portfolio. For version 5.x the position report has been expanded, and two new activity reports have been added. In addition, the position report (positionReport) was enhanced to report payments at the position level in order to support the clearing and settlement of OTC derivatives.

3.4.4.2.1.1 Position Report

The position report is intended to allow a firm to report the current status of a portfolio of positions.

schemaDocumentation/schemas/fpml-reporting-5-4_xsd/complexTypes/PositionReport.png

schemaDocumentation/schemas/fpml-reporting-5-4_xsd/complexTypes/PositionReport/position.png

The position report includes:

  • header information to describe the contents of the report (asOfDate, dataSetName, reportContents, quotationCharacteristics, submissionsComplete)

  • a series of position elements. Each position element includes:

    - identifying information

    - optional status information, allowing the reporting firm to explain how the position was created and modified

    - details of the trade underlying the position

    - servicing events, both planned and historical, together with related values

    - valuation elements reporting calculated or observed values such as NPVs, rates, or spreads. (More information about the valuation elements can be found in "Pricing and Risk Architecture" section.)

    - optional payments (repeatable payment element), allow cash flows to be reported for the majority of asset types as well as allow payments to be reported at the position level in the same way that valuations are reported.

The FpML standard for cashflow matching offers the ability to provide optional calculation details (calculationDetails) within the payment structure that explain how the payment has been computed. A typical approach would be to reconcile the payment(s) and grossCashflow(s) elements.

Additional observation and calculation details can be provided to enable a fast research path to the cause of the break. calculationElements and/or observationElements structures can be used to capture partial calculations and observation details.

(More information about the calculation details can be found in section 3.4.2.3 "Calculation Details". Additionally, the “Design principles” subsection provides insights on supported cashflows in FpML)

Example of new payment structure at the position level, including adjustedPaymentDate and calculationDetails:

 
 <position>
               ...
                <payment>
                             <identifier>123</identifier>
                             <payerPartyReference href="party1"/>
                             <receiverPartyReference href="party2"/>
                             <paymentAmount>
                                         <currency>EUR</currency>
                                          <amount>123</amount>
                              </paymentAmount>
                              <adjustedPaymentDate>2004-06-04</adjustedPaymentDate>
                              <calculationDetails>
                                               <grossCashflow>
                                                              <cashflowId cashflowIdScheme="http://www.abc.com/cashflowId">_2005US2</cashflowId>
                                                               <payerPartyReference href="party2"/>
                                                               <receiverPartyReference href="party1"/>
                                                                <cashflowAmount>
                                                                                 <currency>USD</currency>
                                                                                  <amount>20444.44</amount>
                                                                 </cashflowAmount>
                                                                <cashflowType>Coupon</cashflowType>
                                               </grossCashflow>
                                                <calculationElements>
                                                                <calculationPeriod>
                                                                                  <adjustedStartDate>2004-03-20Z</adjustedStartDate>
                                                                                   <adjustedEndDate>2004-06-20Z</adjustedEndDate>
                                                                                    <numberOfDays>92</numberOfDays>
                                                                                    <dayCountFraction>ACT/360</dayCountFraction>
                                                                                    <dayCountYearFraction>0.2555</dayCountYearFraction>
                                                                 </calculationPeriod>
                                               </calculationElements>
                              </calculationDetails>
              </payment>
             ...    
      

The position element is based on ReportedPosition type which adds the optional payment(s).

schemaDocumentation/schemas/fpml-reporting-5-4_xsd/complexTypes/ReportedPosition.png

The payment structure in FpML was modified to accommodate for an optional adjusted payment date and calculation details used in the position report. The payment within the position report is based on a new type PositionPayment which uses a new model group PaymentDetails.model that covers payment details.

schemaDocumentation/schemas/fpml-reporting-5-4_xsd/complexTypes/PositionPayment.png

The existing PaymentMatching type was restructured to use the new PaymentDetails model group.

schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/complexTypes/TradeCashflowsAsserted.png

schemaDocumentation/schemas/fpml-reporting-5-4_xsd/complexTypes/ReportedPosition/payment.png

3.4.4.2.1.2 Position Activity Report

The position activity report is a variation of the Position Report that is specifically targeted to reporting changes in position, for example changes between two points in time.

Instead of directly containing positions, the PositionActivityReport includes a series of Position Updates. These elements include information about the type of update (new position, modified position, removed position), the reason for the update, and details of the resulting or removed position.

schemaDocumentation/schemas/fpml-reporting-5-4_xsd/complexTypes/PositionActivityReport.png

3.4.4.2.1.3 Event Activity Report

The Event Activity Report allows a firm to report on a series of related or unrelated business events, such as trades, amendments, novations, or terminations. These events will typically be applicable for a specific context (e.g. a single account or product) over a specific time period (e.g. a day or month). It does not allow valuation information or servicing events to be reported.

schemaDocumentation/schemas/fpml-reporting-5-4_xsd/complexTypes/EventActivityReport.png

3.4.4.2.2 Reset Reporting

The reset report, added in FpML 5.0, allows a firm to report on the fixing of a floating rate index, and to indicate the positions that are affected by the fixing.

It contains:

  • header information describing the applicability of the report

  • information about the index being set

  • information about the rate observation

  • a list of positions affect by the fixing.

schemaDocumentation/schemas/fpml-reporting-5-4_xsd/complexTypes/ResetReport.png

3.4.4.2.3 Exposure Reporting

FpML can now support reporting of aggregate exposures in a variety of ways. The ExposureReport allows a substantial number of idenfying characteristics to be used to categorize exposure. These characteristics include both party-related categories (such as the region, country, risk grade, or industry sector) to be used for grouping exposure records, or product-related fields such as product type, currency, underlying assets, etc. Exposures can be reported in a flat summary form, or nested within other exposures to provide a multi-level report. The values that are reported can be any FpML measureType, such as aggregate NPV or notional, or various risk measures.

The FpML exposure report is used to implement the CFTC Part 20 position report. Several examples are provided of these exposure reports. Subsequent versions of the specification will include more detail on these examples, which are based on the Part 20 regulation and the CFTC guidebook to Part 20 reporting.

3.4.4.2.4 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.4.4.2.4.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 supports both cashflow netting for a single and across multiple trades.

This section is organized as follows:

  • Design principles
  • Messaging and schema structure
  • Usage guidelines

3.4.4.2.4.2 Design Principles

The standard for cashflow matching within a single trade was 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. In 2010, support for cashlow matching across multiple trades was added by the FpML Business Process 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 or across trades. 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:

    For cashflows within a single trade, 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.

3.4.4.2.4.3 Cashflows within a trade
  • 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. 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.

    • images/messaging/CashflowBilateralMatch.jpg

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

schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/complexTypes/TradeIdentifyingItems.png

schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/complexTypes/TradeIdentifyingItems/tradeDetails.png

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

schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/complexTypes/PaymentMatching.png

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

schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/complexTypes/TradeCashflowsAsserted.png

3.4.4.2.4.3.2 tradeCashflowsMatchResult

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

schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/complexTypes/TradeCashflowsMatchResult.png

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

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

schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/elements/cancelTradeCashflows.png

3.4.4.2.4.4 Cashflows across multiple trades
  • Sequence of messages:

    The standard suggests that the following workflow sequence will be applied for reconciling cashflows related to multiple OTC derivatives contracts:

    • The Matching Requester sends a nettedTradeCashflowsAsserted including the set of net payments (each one uniquely identified) that need to be reconciled to the Matching Service as of a specific date. 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 nettedTradeCashflowsException message and the submitted set would go to an exception state.
    • Once the matching process is performed the matching service sends a nettedTradeCashflowsMatchResults 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 nettedTradeCashflowsRetracted message.

    schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/elements/nettedTradeCashflowsAsserted.png

    schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/elements/nettedTradeCashflowsMatchResult.png

    schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/elements/nettedTradeCashflowsRetracted.png

  • Referencing the trade within the gross cashflow:

    The ability to establish the relationship between the cashflow and the trade is implemented referencing the partyTradeIdentifier through the partyTradeIdentifierReference within the GrossCashflow component:

    schemaDocumentation/schemas/fpml-shared-5-4_xsd/complexTypes/GrossCashflow.png

    	 
    <nettedTradeCashflowsAsserted>
    ...
    	<tradeIdentifyingItems>
          		<partyTradeIdentifier id="trade2">
    			...
    	</tradeIdentifyingItems>
    	...
    	<grossCashflow>
                ...
                <partyTradeIdentifierReference href="trade2"/> 
                ...
        </grossCashflow>
    ...
    </nettedTradeCashflowsAsserted>
    
    
      
3.4.4.2.4.5 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
  • Cash flow type scheme
  • Updated asset measure scheme
  • Cash flow status scheme

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

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

3.4.4.2.4.6.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.4.4.2.4.6.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.4.4.2.4.6.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.4.4.2.5 Portfolio Reconciliation
3.4.4.2.5.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.4.4.2.5.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.4.4.2.5.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.4.4.2.5.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.4.4.2.5.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.4.4.2.5.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.4.4.2.5.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.4.4.2.5.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.4.4.2.5.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.4.4.2.5.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).

images/messaging/portfolio_abcd.jpg

To initiate reconciliation the requester 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’.

images/messaging/portfolio_sequence1.jpg

In a real-time environment this notification may be generated every time one of underlying portfolio sets is modified and requesters 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.4.4.2.5.4 Messaging and Schema Structure

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

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

schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/complexTypes/PositionsAsserted.png

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.

schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/complexTypes/DefinePosition.png

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

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

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

schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/complexTypes/PositionReference.png

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

When a reconciliation provider has processed a ‘PositionsAsserted’ it MAY return a ‘PositionsAcknowledged’ to the requester. 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.

schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/elements/positionsAcknowledged.png

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.

schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/complexTypes/UnprocessedPosition.png

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

schemaDocumentation/schemas/fpml-reconciliation-5-4_xsd/elements/positionsMatchResults.png

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.4.4.2.5.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.4.4.2.5.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.4.4.2.5.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.4.4.2.5.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.4.4.2.5.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.4.4.2.5.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.4.4.2.6 Valuation Reporting

More information about valuation can be found in the "Pricing and Risk Architecture" section.

3.4.5 Service Notification

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

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