The FpML 4.0 Schema was the first release of the specification to place a messaging framework around the product descriptions to describe the context and use to which the information is expected to be put. This section describes a small set of complex types and elements that comprise a simple message framework that is used as the basis for defining business messages and processes suitable for use in a communications process.
These definitions introduce a new set of ideas that previously could not be used in FpML because of its reliance on DTDs as the formal specification of the grammar. The following sections describe the reasoning behind the features used in the framework as well as a description of several business processes.
Increased efficiency in financial markets can only be achieved through greater automation of transaction processing and use of electronic messaging (e.g. the exchange of information directly between computer systems with as little human interaction as possible). In order to achieve this all the parties involved in such communications must agree on four things, namely:
Representation
There must be a common representation of a transaction, product or other reference data item that is accepted by all the parties.
The core FpML grammar defines a standard vocabulary for derivative based transactions and products that can form the basis of a messaging standard. As new messaging applications are considered the scope of the core grammar will need to expand to encompass the additional types of data referenced in these messages.
Semantics
All the parties must have the same interpretation of the information expressed by the representation.
The work of the validation working group provides a set of rules to ensure that a product definition conforms to the market definition for that product. The FpML rule set will expand and evolve over time as new financial products and message types are added to the grammar.
Business Process
All the parties must follow the same business processes and respond appropriately to any communication they receive.
To support the consistency across different business processes and views, the Messaging Task Force defined a new messaging framework that extended the core grammar. This section describes some business processes and shows how they could be implemented as message exchanges. This section describes some business processes and shows how they could be implemented as message exchanges.
Transport
The parties must agree on the communications transport used to interconnect their businesses.
FpML does not endorse any particular messaging transport for communication. The choice of transport is left to the implementer although in practice we expect only a few to be found suitable.
Disagreement over the first three of these features will mean that FpML users will potentially have to implement, maintain and support different software systems for each FpML aware service or application that they use. Supporting multiple communications transports is typically not that difficult although it does incur additional operations costs.
FpML 5 introduces a new messaging framework to address limitations in the version 4 framework.
This new framework does the following:
it consistently implements a set of general principles to make it easier to use the messages to implement real business processes
it adjusts the representation of parties, accounts, and roles to clarify the purpose of messages and the roles of the parties within a message.
The following section describes the new messaging framework.
Following are some of the issues in the FpML messaging framework that the version 5 framework seeks to correct:
Incomplete message set – in many cases not all messages required to implement a business process are defined in the FpML 4 message set. In particular, many requests lack acknowledgements, exception responses, correction capabilities, and in some cases normal responses. Many generic business processes (such as confirmation) have different levels of completeness depending on the specific event that is being covered.
Inconsistent message correlation – different implementations use different features of the FpML 4 framework to link successive messages together, making them incompatible.
Unclear processes – it is not always clear how the version 4 messages are to be combined together to fully implement a business process. For example, which message should be used to acknowledge or respond to a request isn’t always defined. While this could in theory be addressed through documentation, because the message set is incomplete, this is difficult to do.
In order to create the messages and business processes described in this document some design assumptions had to be made, principally:
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.
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?]
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.
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.
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".
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.
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.
The protocol that is used for exchanging FpML messages is defined in being in three main layers:
Specifically, the transport characteristics that FpML assumes in order to implement most of its business process definition are defined by:
In some processes such as Portfolio Reconciliation or Position Report, FpML assumes the following transport characteristics:
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:
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.
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”).
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.
The Transport Layer provides a point to point connection so that one server can send messages to another server and they will arrive uncorrupted and in the correct order.
The FpML Message Architecture defines a message structure that is independent of the underlying transport protocol, such as SMTP, File Transfer Protocol (FTP), Standardized Messaging Middleware, HTTP, etc.
The receiver of a message needs to be able to determine the function that the message is invoking. In XML there are three different techniques that can be used for indicating the purpose of a message.
The FpML 5.0 message framework is based on element naming (option 2 - By Element Name). Below is a short explanation of the three techniques:
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.
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.
The receiver can look at the type associated with an element within the message (e.g. the root or a child).
<?xml version="1.0"?> <FpML version="4-0" xmlns="http://www.fpml.org/2002/FpML-4-0" xsi:type="TradeConfirmationRequest"> <header> ... Message header </header> ... Business data </FpML>
An XML schema based instance may use type substitution to replace the content model of any element with another providing that the replacement is derived from the original. Given a framework that provides the appropriate extension points any number of new types can be derived within the name or different namespaces as necessary.
In addition through inheritance the message types can be associated with an appropriate message header content model.
Messages are divided into a series of business processes. For example, consent negotiation (getting permission to do something) is a business process. For each business process, in general the following messages will be available:
process request or notification message – to initiate the process. (In some cases the process may be initiated by a notification message rather than a request message).
process acknowledgment message – to acknowledge that the request or notification was received.
process exception message – to report that a request or notification cannot be processed.
process request/notification retracted message – to withdraw the original request or notification.
possibly, process-specific response messages
In some cases, some of these messages may be intentionally omitted, but in these cases the rationale for omitting the messages will be provided. For example, acknowledgement messages may be omitted where it is expected that all responses will be immediate, and retraction messages may be omitted if there is no need to allow requests to be withdrawn, because the original request would be fulfilled before the retraction could be sent.
For the consent negotiation process, for example, the messages include:
requestConsent – initiating request
consentAcknowledgement - acknowledgement
consentException - exception
requestConsentRetracted – retraction of the request
consentGranted - response
consentRefused – response
Messages follow this naming convention:
requestXxx
xxxAcknowledgement
xxxException
requestXxxRetracted
xxx[Status] or xxx[Response]
Providing each request with a more immediate and guaranteed response allows a more synchronous style of design, such as this:
Here the requester waits for the response before terminating its execution. This would allows easier specification of timeouts related to request processing although as we shall see later has implications for gathering the results of long running processes, such as matching.
The initiator of a business process should allocate a unique correlation identifier for each process instance it begins and any subsequent message related to the same process should contain the same identifier. A qualified scheme based value ensures that participants cannot accidentally re-use an identifier previous generated by another firm.
|
For example, when used within a trade execution advice it might appear as follows:
... <tradeExecutionAdvice> <messageHeader> </messageHeader> <isCorrection>false</isCorrection> <correlationId correlationIdScheme="http…">BQ/1234 </correlationnId> <sequenceNumber>657</sequenceNumber> <onBehalfOf> <partReference href="PARTYA"/> </onBehalfOf> <execution> <trade> … Lots more here </trade> </execution> <party id="PARTYA">…</party> <party id="PARTYB">…</party> </tradeExecutionAdvice> ...
Any response or follow up to this message should contain the same 'correlationId' definition. This regime allows us to make some other messaging clarifications, namely:
Every message will have a unique message identifier.
The ‘inReplyTo’ element of a response message (or exception) correlates with the ‘messageId’ of the associated request.
The conversationId has been removed.
Retransmission of a message for technical reasons (e.g. the last transmission of the request was not acknowledged or rejected) does not change the message identifier.
Replication of a message for business reasons (e.g. sending data that has been previously acknowledged) generates a new message identifier.
The response to a retransmitted request message should be identical to the original request. (1)
At the start of a long running process the initiating participant must create a unique one-time identifier for each process instance and distribute it to the other messaging party.
Every subsequent message sent by the requester must contain the process identifier.
Messages may contain reference to other business process instances providing their role is clear and unambiguous (e.g. an order MAY reference a previous quotation).
(1) This allows the transport to respond to retransmissions by sending a copy of the earlier cached response, no business process is necessary. This is a standard technique in ONC RPC and WebServices.
In a long running operation it is important to process all of the messages in the correct order. Each message’s ‘messageId’ is element is guaranteed to contain a unique value but the order of messages cannot be inferred by comparing two such identifiers.
The characteristics required by FpML’s transport characteristics states that two messages sent simultaneously, or within a short time of each other, may arrive in any order. Since message order cannot be determined from the message identifiers some other information needs to be added to them message to provide this.
In the SWIFT CUG implementation of the contract notification messages the trade version is used to derive the ordering. Whilst this is a workable solution for the CUG it does not solve the problem generally and some messages must artificially increase the contract version number to maintain order even though no change has actually occurred to the underlying contract.
The simplest solution is to define a type for sequence numbers and use it within messages to provide an orderable value.
|
It is important to note that although sequence numbers should be consistently increasing in value they do not have to form a gapless sequence. (2)
When combined with the unordered delivery transport characteristics a message processing application can be presented with a series of messages in a jumbled order.
An optimistic message processor should attempt to process the messages in the order they are delivered and unwind actions (or raise exceptions) when conflict is detected.
A pessimistic message processor should record the messages but delay their processing for a short period. This provides a time window during which any earlier messages received out of order can be re-sequenced before processing begins.
It is also important to note that sequence numbers must be qualified with respect to the message sender and the responding part may need to produce messages containing them. For example in the matching processes the messages containing the result should reference the same ‘correlationId’ used in the original request but should use a ‘sequenceNumber’ provided by the matcher rather than the requester.
For example the series of messages for a trade confirmation (including a correction) followed by the resulting match might be identified as follows:
|
(2) There may be messages within the same business process sent to other participants or internal changes to the business object that affect the sequence number.
Starting from FpML 5.2, the correlation ID is optional in requests. This is intended to more flexibly support a variety of processing models. The original request may omit the correlation ID if the recipient will quickly respond to requests with its own correlation ID. Subsequently requester will need to use the recipient's correlation IDs if it needs to correct or retract a request. The FpML messaging architecture recommends that services support the correlation ID in the original requests, because otherwise requesters cannot correct or retract requests until they receive a reply from the service.
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>
|
|
|
The 4.x tradeSide structure has been replaced by a simpler implementation adding a new relatedParty element. The role element within the relatedParty defines the list of roles as code list. This allows to customize the roles easier than using the tradeSide structure.
|
|
<someRequest> ... <partyTradeInformation> <partyReference href="party3"/> <relatedParty> <partyReference href="party4"/> <role>orderer</role> </relatedParty> <relatedParty> <partyReference href="party4"/> <role>introducer</role> </relatedParty> <relatedParty> <partyReference href="party3"/> <role>executor</role> </relatedParty> <relatedParty> <partyReference href="party4"/> <role>confirmer</role> </relatedParty> <relatedParty> <partyReference href="party6"/> <role>creditor</role> </relatedParty> <relatedParty> <partyReference href="party5"/> <role>settler</role> </relatedParty> <relatedParty> <partyReference href="party6"/> <role>accountant</role> </relatedParty> </partyTradeInformation> ... </someRequest>
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).
|
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.
Before looking at the current message processes and their associated messages it is worth looking at the overall sequence of business processes for trades.
The first thing to note is that there are two sets of processes; the first set manages the transaction itself during its ‘cradle to grave’ life cycle while the second are repeatable management tasks that may occur several times over the life time of the transaction.
Looking at the states in the life cycle part of the process model there the first thing to note is that there are multiple routes to the creation of trade.
The original model for FpML (and not actually supported in the specification) is the traditional model of direct inter-dealer negotiation (e.g. by phone, over SwapsWire, etc.) followed by an affirmation of the resulting transaction.
Alternatively trades could be created using a more market based approach in which quotes and orders are communicated through an exchange in which more than one market maker may be offering prices for the same quote or order. The terminology of quote, indications of interest, orders and execution is more closely coupled with this market approach.
In the direct negotiation approach the identities of the participants of fully disclosed and this allows pre-agreed exploitation of other party’s credit rating to obtain better prices (within agreed limits). In the market approach pre-order interactions may be anonymous to guarantee best prices are obtained for all market participants.
Messages related to trade negotiation and affirmation need to be capable of recording that these additional parties are being used but in later trade processing stages such ‘give-up’ trades are decomposed in a set of related back-to-back trades.
All the processes described in this section are applied to the following events:
In addition, the "clearing" event can be used in the clearing business processes.
|
All events use the same messages to support the processes. The additionalEvent element is an extension point to customize FpML and add additional events.
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.
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.
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.
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.
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.
The position report is intended to allow a firm to report the current status of a portfolio of positions.
|
|
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).
|
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.
|
The existing PaymentMatching type was restructured to use the new PaymentDetails model group.
|
|
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.
|
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.
|
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.
|
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.
The FpML standard for cashflow matching is aimed at providing a messaging standard to support the ISDA guideline developed by the ISDA Operations Committee.
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 standard for cashflow matching supports both cashflow netting for a single and across multiple trades.
This section is organized as follows:
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.
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:
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.
As stated above, the payment is exposed to the matching process using the tradeCashflowsAsserted message:
The tradeCashflowsAsserted message contains the following structures:
|
|
|
|
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:
The set of net payments can be cancelled using CancelTradeCashflows message:
|
Sequence of messages:
The standard suggests that the following workflow sequence will be applied for reconciling cashflows related to multiple OTC derivatives contracts:
|
|
|
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:
|
<nettedTradeCashflowsAsserted> ... <tradeIdentifyingItems> <partyTradeIdentifier id="trade2"> ... </tradeIdentifyingItems> ... <grossCashflow> ... <partyTradeIdentifierReference href="trade2"/> ... </grossCashflow> ... </nettedTradeCashflowsAsserted>
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:
The scheme mechanism provides implementers the ability to define their own schemes in a more generic or more aggregated level.
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 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:
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> ...
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> ...
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.
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.
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.
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.
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.
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).
Reconciliation MUST compare the parametric descriptions of each portfolio constituent but MAY also compare additional information such as any provided valuations.
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:
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.
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.
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 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:
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 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.
This section describes the new types need within the FpML schema to support the outlined design.
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:
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:
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.
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.
|
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.
|
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:
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.
In the implementation of this set of messages using a central matching service (trilateral), there are a set of guidelines to consider:
In the bilateral case:
There are a set of guidelines to consider depending on the scenario that is going to be implemented:
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:
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:
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.
More information about valuation can be found in the "Pricing and Risk Architecture" section.
There are service notification messages that allow a service to report information on status and other alerts to users. Supported variations include:
Previous | Top of Section | Next |
---|