3.1 Introduction
The FpML 4.0 Schema was the first release of the specification to place a messaging framework around the product descriptions to describe the context and use to which the information is expected to be put. This section describes a small set of complex types and elements that comprise a simple message framework that is used as the basis for defining business messages and processes suitable for use in a communications process.
These definitions introduce a new set of ideas that previously could not be used in FpML because of its reliance on DTDs as the formal specification of the grammar. The following sections describe the reasoning behind the features used in the framework as well as a description of several business processes.
Increased efficiency in financial markets can only be achieved through greater automation of transaction processing and use of electronic messaging (e.g. the exchange of information directly between computer systems with as little human interaction as possible). In order to achieve this all the parties involved in such communications must agree on four things, namely:
-
Representation
There must be a common representation of a transaction, product or other reference data item that is accepted by all the parties.
The core FpML grammar defines a standard vocabulary for derivative based transactions and products that can form the basis of a messaging standard. As new messaging applications are considered the scope of the core grammar will need to expand to encompass the additional types of data referenced in these messages.
-
Semantics
All the parties must have the same interpretation of the information expressed by the representation.
The work of the validation working group provides a set of rules to ensure that a product definition conforms to the market definition for that product. The FpML rule set will expand and evolve over time as new financial products and message types are added to the grammar.
-
Business Process
All the parties must follow the same business processes and respond appropriately to any communication they receive.
To support the consistency across different business processes and views, the Messaging Task Force defined a new messaging framework that extended the core grammar. This section describes some business processes and shows how they could be implemented as message exchanges. This section describes some business processes and shows how they could be implemented as message exchanges.
-
Transport
The parties must agree on the communications transport used to interconnect their businesses.
FpML does not endorse any particular messaging transport for communication. The choice of transport is left to the implementer although in practice we expect only a few to be found suitable.
Disagreement over the first three of these features will mean that FpML users will potentially have to implement, maintain and support different software systems for each FpML aware service or application that they use. Supporting multiple communications transports is typically not that difficult although it does incur additional operations costs.
FpML 5 introduces a new messaging framework to address limitations in the version 4 framework.
This new framework does the following:
-
it consistently implements a set of general principles to make it easier to use the messages to implement real business processes
-
it adjusts the representation of parties, accounts, and roles to clarify the purpose of messages and the roles of the parties within a message.
The following section describes the new messaging framework.
Following are some of the issues in the FpML messaging framework that the version 5 framework seeks to correct:
-
Incomplete message set – in many cases not all messages required to implement a business process are defined in the FpML 4 message set. In particular, many requests lack acknowledgements, exception responses, correction capabilities, and in some cases normal responses. Many generic business processes (such as confirmation) have different levels of completeness depending on the specific event that is being covered.
-
Inconsistent message correlation – different implementations use different features of the FpML 4 framework to link successive messages together, making them incompatible.
-
Unclear processes – it is not always clear how the version 4 messages are to be combined together to fully implement a business process. For example, which message should be used to acknowledge or respond to a request isn’t always defined. While this could in theory be addressed through documentation, because the message set is incomplete, this is difficult to do.
In order to create the messages and business processes described in this document some design assumptions had to be made, principally:
3.2.3.1 Highly Assured Transport
-
Throughout this document we have assumed that message exchanges will be carried by a passing of messages over a highly assured transport, such is provided by a messaging queuing system. This form of transport is commonly used today in the finance industry (e.g. AMQP, Apache QPid, FIX engines, MQSeries, MSMQ, RabbitMQ, SwiftNet Interact 'Store and Forward', etc.).
One important consequence of this decision is that error cases related to non-delivery do not have to be considered (e.g. once accepted a guaranteed messaging queuing system WILL ALWAYS deliver a message) although the 'freshness' of the message may need to be considered (e.g. has the message been stuck in a queue waiting to be delivered for a long period of time). Similarly message queuing system can normally eliminate duplicate messages so these are not considered either.
3.2.3.2 No Preservation of Message Sequence
-
There is no requirement for message sequence to be preserved over the message transport. Message sequence must not be expected to be repeatable nor predictable.
In practise enterprise message buses cannot be expected to halt the enterprise to preserve sequence. Hence this is not a requirement of FpML.
3.2.3.3 Long-Running Processes
-
Some of the business processes are 'long-running' in that once initiated they may remain active for a considerable time before completing (e.g. a request to confirm a trade may take many hours as it is dependent on the time of arrival of the matching trade). During this time the process may generate periodic notifications to the originator of the request and/or other parties. Such notifications will appear in the message stream set to a participant intermixed between other response messages.
An implication of such 'long-running' transactions is that the 'service provider' will contain a complex 'state'. The service should make suitable provisions to persistently record its state so that in the event of a software or hardware failure it can recover transparently without its clients having to resend any information.
3.2.3.4 Observable Completion
-
Principle: All requests should result in an "observable completion", that is a clear (observable by the requester) response.
-
Implementation: For each request or notification message there should be at least one defined acknowledgement message. In the case where the response to the request might be delayed pending additional information, the recipient of the request should acknowledge the request. [Should we set a guideline here? E.g. acknowledge if resulting action is likely not to occur within 10 seconds?]
3.2.3.5 Consistent Message Correlation
-
Principle: There should be a single, well-defined way to link successive messages (such as corrections or retractions of requests or notifications). This should not rely on message or transport level information, but rather use business-level information.
-
Implementation: Add an explicit correlation identifier, defined as business object identifier, and a sequence number to link successive messages.
3.2.3.6 Consistent Error Reporting
-
Principle: There should be a standard way of reporting error or exception status for each type of request.
-
Implementation: Ensure that there is an exception message for each message workflow.
3.2.3.7 Consistent correction and retraction mechanism
-
Principle: There should be a consistent way to correct messages containing an error, and to retract (withdraw, cancel) messages when the information is no longer valid or the action is no longer required.
-
Implementation: Correctable messages will contain an "isCorrection" indicator to indicate whether the message corrects a previous message. Retractable messages should have a corresponding message ending with "Retracted".
3.2.3.8 Consistent Processes Across Trades and Post-trade Events
-
Principle: Business processes should work consistently across trading events and post-trade events where possible, so the same messages should be available for each type of event.
-
Implementation: Most messages will be designed to be able to handle multiple types of events, such as new trades and post-trade events. This allows consistent coverage of a number of post-trade events with a number of business processes.
Implementers attempting to construct software based on these protocols using a non queuing transport (e.g. WebServices, DCOM, CORBA) will need to implement a reliable message layer to encapsulate the current message sequences (e.g. a get/put message interface using sequence numbers to detect lost or duplicated messages and positive/negative acknowledgments). The W3C site contains links to proposals for such extensions for use with WebServices.
3.2.3.9 Transport Characteristics
3.2.3.9.1 Purpose
The definition of the FpML business processes assumes the use of reliable messaging, meaning high predictability. Generally, increasing reliability increases latency. The assumption of reliable messaging is provided to make it easier to design standard business processes and messages. If the transport characteristics were not defined, the business process definition would be ambiguous.
3.2.3.9.2 Layers
The protocol that is used for exchanging FpML messages is defined in being in three main layers:
- The Business Layer is the higher layer and deals with FpML documents. The exchange of FpML documents is fully described in the message choreography and the structure of the FpML documents is fully described by the schemata and the related validation rules. The Business Layer is equivalent to adding a Layer 9 to the OSI model.
- The Message Transport Layer is the lower layer and deals with transport messages. The implementation of this layer is outside the scope of FpML since it varies. The Transport Characteristics apply to the Message Transport Layer. This layer is equivalent to adding a Layer 8 to the OSI model.
- The layer immediately beneath the FpML Protocol is the Messaging Application Layer. FpML allows any Messaging Application that supports the requirements of the Transport Characteristics defined below. The Messaging Application Layer is Layer 7 of the OSI model.
-
3.2.3.9.3 Reliable Mode
Specifically, the transport characteristics that FpML assumes in order to implement most of its business process definition are defined by:
- The delivery of a message is highly assured so the receiving messaging endpoint receives the message at least once.
- A sending messaging endpoint must not block the sending or receipt of other messages while waiting for a response to the sent message.
- The same applies to the receiving messaging endpoint. It must not block the receipt or processing of other messages while processing the current message.
- Messages may arrive in any order at the receiving messaging endpoints. However the message must be delivered before the maximum duration of time permitted.
- For each FpML document sent, sixty seconds is the maximum duration of time in within which all its preceding FpML documents must be sent.
- Messages are addressed to nought to many receiving messaging endpoints.
- The maximum duration of time within which a message must be delivered is sixty seconds.
- Only valid FpML documents are delivered; invalid FpML documents are rejected to the sending messaging endpoint.
- The messaging transport system must ensure that the FpML document is well-formed, W3C Schema valid, validated against the constraints defined in the validation rules, and validated against the message choreography. It is important to note that the messaging transport system is a role that can be played by either endpoint in a peer to peer setup, or by one or more third party systems. In addition, multiple messaging transport systems can be chained together into a single messaging transport system.
- The messaging transport system must ensure that the message is kept available until it is received by the messaging endpoint or until it is expired because it was delivered later than the maximum duration of delivery time. So, it can be queued on the messaging transport system within the maximum delivery time duration, but it can be queued at the destination indefinitely.
- The maximum size of a message is 100,000kb (100Mb). Any message exceeding this size must be treated as an invalid message.
- Clocks must maintain a maximum (inclusive) variance from UTC less than the Maximum Clock Variation for the supported Message Transport Mode. The maximum clock variation for this mode is ten seconds.
3.2.3.9.4 Bulk Transfer Mode
In some processes such as Portfolio Reconciliation or Position Report, FpML assumes the following transport characteristics:
- The delivery of a message is highly assured so the receiving messaging endpoint receives the message at least once.
- A sending messaging endpoint must not block the sending or receipt of other messages while waiting for a response to the sent message.
- The same applies to the receiving messaging endpoint. It must not block the receipt or processing of other messages while processing the current message.
- Messages may arrive in any order at the receiving messaging endpoints. However the message must be delivered before the maximum duration of time permitted.
- Messages are addressed to nought to many receiving messaging endpoints.
- The maximum duration of time within which a message must be delivered is ten minutes (600 seconds).
- Only valid FpML documents are delivered; invalid FpML documents are rejected to the sending messaging endpoint.
- The messaging transport system must ensure that the FpML document is well-formed, W3C Schema valid, validated against the constraints defined in the validation rules, and validated against the message choreography. It is important to note that the messaging transport system is a role that can be played by either endpoint in a peer to peer setup, or by one or more third party systems. In addition, multiple messaging transport systems can be chained together into a single messaging transport system.
- The messaging transport system must ensure that the message is kept available until it is received by the messaging endpoint or until it is expired because it was delivered later than the maximum duration of delivery time. So, it can be queued on the messaging transport system within the maximum delivery time duration, but it can be queued at the destination indefinitely.
- The maximum size of a message is 100,000kb (100Mb). Any message exceeding this size must be treated as an invalid message
- Clocks must maintain a maximum (inclusive) variance from UTC less than the Maximum Clock Variation for the supported Message Transport Mode. The maximum clock variation for this mode is five minutes.
In general, four layers of specification are contained in a XML Standard. A multi-layer approach allows implementers to choose the most appropriate technology for a given situation. It allows development and modifications within one layer without affecting or requiring changes to the others..
From the top down, the four layers are:
3.2.4.1 Business Process
This layer specifies the way in which any business process is defined, such that is understood and executable by people and applications. A business process can be defined as a set of interrelated tasks linked to an activity that spans functional boundaries. Business processes have starting points and ending points, and they are repeatable. Examples of business processes in the derivatives domain are the affirmation process, the confirmation process, and the matching process.
The FpML Specification models business processes in UML sequence diagrams.
3.2.4.2 Document
This layer corresponds to the FpML document definitions. It provides a set of abstractions specific to financial derivatives but also a set of elements which are not context specific (such as “Party” and “Price”).
3.2.4.3 Messaging
The Messaging layer addresses the need to record session and communication settings for message transport in order to enable coordination between parties in a business transaction.
The FpML Schema explicitly models ‘delivery’ related information as part of the message itself. Some transports (i.e. SOAP, ebXML, etc.) allow such information to be placed in the ‘envelope’ that surrounds the message during delivery.
Including a standard header within FpML messages increases consistency by providing a single format for delivering information regardless of the physical transport, ensures that it will be persisted if the message is archived, and allows more flexible use of features such as digital signatures.
3.2.4.4 Transport
The Transport Layer provides a point to point connection so that one server can send messages to another server and they will arrive uncorrupted and in the correct order.
The FpML Message Architecture defines a message structure that is independent of the underlying transport protocol, such as SMTP, File Transfer Protocol (FTP), Standardized Messaging Middleware, HTTP, etc.
The receiver of a message needs to be able to determine the function that the message is invoking. In XML there are three different techniques that can be used for indicating the purpose of a message.
The FpML 5.0 message framework is based on element naming (option 2 - By Element Name). Below is a short explanation of the three techniques:
3.2.5.1 By Namespace (not used by FpML)
The receiver can look at the namespace from which the element definitions have been drawn and determine from it the function requested.
<?xml version="1.0"?>
<FpML version="4-0"
xmlns="http://www.fpml.org/2002/FpML-4-0-TradeConfirmationRequest">
<header>
... Message header
</header>
... Business data
</FpML>
Using namespaces it would be possible to create a highly extensible framework for FpML but it could lead to documents having to have every FpML element prefixed with a suitable namespace abbreviation although it may be possible to mitigate this by having the 'core' sub-schemas use no namespaces in their definition and take on the namespace of the one they are including into.
There may be further issues with related XML standards such as XPath as the namespace of the same included elements may not be consistent between documents.
3.2.5.2 By Element Name (used by FpML 5.x)
The receiver can look at the name associated with an element within the message (the root and one of the first level children) to determine the function requested.
<?xml version="1.0"?>
<requestConfirmation fpmlVersion="5-0" xmlns="http://www.fpml.org/FpML-5/confirmation">
<header>
... Message header
</header>
<trade>
... Business data
</trade>
...
</requestConfirmation>
In this model the root element is a global element of a type derived from the base FpML Document type, typically a message type.
3.2.5.3 By Element Type (used by FpML 4.x)
The receiver can look at the type associated with an element within the message (e.g. the root or a child).
<?xml version="1.0"?>
<FpML version="4-0" xmlns="http://www.fpml.org/2002/FpML-4-0" xsi:type="TradeConfirmationRequest">
<header>
... Message header
</header>
... Business data
</FpML>
An XML schema based instance may use type substitution to replace the content model of any element with another providing that the replacement is derived from the original. Given a framework that provides the appropriate extension points any number of new types can be derived within the name or different namespaces as necessary.
In addition through inheritance the message types can be associated with an appropriate message header content model.
Messages are divided into a series of business processes. For example, consent negotiation (getting permission to do something) is a business process. For each business process, in general the following messages will be available:
-
process request or notification message – to initiate the process. (In some cases the process may be initiated by a notification message rather than a request message).
-
process acknowledgment message – to acknowledge that the request or notification was received.
-
process exception message – to report that a request or notification cannot be processed.
-
process request/notification retracted message – to withdraw the original request or notification.
-
possibly, process-specific response messages
In some cases, some of these messages may be intentionally omitted, but in these cases the rationale for omitting the messages will be provided. For example, acknowledgement messages may be omitted where it is expected that all responses will be immediate, and retraction messages may be omitted if there is no need to allow requests to be withdrawn, because the original request would be fulfilled before the retraction could be sent.
For the consent negotiation process, for example, the messages include:
-
requestConsent – initiating request
-
consentAcknowledgement - acknowledgement
-
consentException - exception
-
requestConsentRetracted – retraction of the request
-
consentGranted - response
-
consentRefused – response
Messages follow this naming convention:
-
requestXxx
-
xxxAcknowledgement
-
xxxException
-
requestXxxRetracted
-
xxx[Status] or xxx[Response]
Providing each request with a more immediate and guaranteed response allows a more synchronous style of design, such as this:
Here the requester waits for the response before terminating its execution. This would allows easier specification of timeouts related to request processing although as we shall see later has implications for gathering the results of long running processes, such as matching.
The initiator of a business process should allocate a unique correlation identifier for each process instance it begins and any subsequent message related to the same process should contain the same identifier. A qualified scheme based value ensures that participants cannot accidentally re-use an identifier previous generated by another firm.
|
|
For example, when used within a trade execution advice it might appear as follows:
...
<tradeExecutionAdvice>
<messageHeader>
</messageHeader>
<isCorrection>false</isCorrection>
<correlationId correlationIdScheme="http…">BQ/1234 </correlationnId>
<sequenceNumber>657</sequenceNumber>
<onBehalfOf>
<partReference href="PARTYA"/>
</onBehalfOf>
<execution>
<trade>
… Lots more here
</trade>
</execution>
<party id="PARTYA">…</party>
<party id="PARTYB">…</party>
</tradeExecutionAdvice>
...
Any response or follow up to this message should contain the same 'correlationId' definition. This regime allows us to make some other messaging clarifications, namely:
-
Every message will have a unique message identifier.
-
The ‘inReplyTo’ element of a response message (or exception) correlates with the ‘messageId’ of the associated request.
-
The conversationId has been removed.
-
Retransmission of a message for technical reasons (e.g. the last transmission of the request was not acknowledged or rejected) does not change the message identifier.
-
Replication of a message for business reasons (e.g. sending data that has been previously acknowledged) generates a new message identifier.
-
The response to a retransmitted request message should be identical to the original request. (1)
-
At the start of a long running process the initiating participant must create a unique one-time identifier for each process instance and distribute it to the other messaging party.
-
Every subsequent message sent by the requester must contain the process identifier.
-
Messages may contain reference to other business process instances providing their role is clear and unambiguous (e.g. an order MAY reference a previous quotation).
(1) This allows the transport to respond to retransmissions by sending a copy of the earlier cached response, no business process is necessary. This is a standard technique in ONC RPC and WebServices.
In a long running operation it is important to process all of the messages in the correct order. Each message’s ‘messageId’ is element is guaranteed to contain a unique value but the order of messages cannot be inferred by comparing two such identifiers.
The characteristics required by FpML’s transport characteristics states that two messages sent simultaneously, or within a short time of each other, may arrive in any order. Since message order cannot be determined from the message identifiers some other information needs to be added to them message to provide this.
In the SWIFT CUG implementation of the contract notification messages the trade version is used to derive the ordering. Whilst this is a workable solution for the CUG it does not solve the problem generally and some messages must artificially increase the contract version number to maintain order even though no change has actually occurred to the underlying contract.
The simplest solution is to define a type for sequence numbers and use it within messages to provide an orderable value.
|
|
It is important to note that although sequence numbers should be consistently increasing in value they do not have to form a gapless sequence. (2)
When combined with the unordered delivery transport characteristics a message processing application can be presented with a series of messages in a jumbled order.
-
An optimistic message processor should attempt to process the messages in the order they are delivered and unwind actions (or raise exceptions) when conflict is detected.
-
A pessimistic message processor should record the messages but delay their processing for a short period. This provides a time window during which any earlier messages received out of order can be re-sequenced before processing begins.
It is also important to note that sequence numbers must be qualified with respect to the message sender and the responding part may need to produce messages containing them. For example in the matching processes the messages containing the result should reference the same ‘correlationId’ used in the original request but should use a ‘sequenceNumber’ provided by the matcher rather than the requester.
For example the series of messages for a trade confirmation (including a correction) followed by the resulting match might be identified as follows:
|
|
(2) There may be messages within the same business process sent to other participants or internal changes to the business object that affect the sequence number.
Starting from FpML 5.2, the correlation ID is optional in requests. This is intended to more flexibly support a variety of processing models. The original request may omit the correlation ID if the recipient will quickly respond to requests with its own correlation ID. Subsequently requester will need to use the recipient's correlation IDs if it needs to correct or retract a request. The FpML messaging architecture recommends that services support the correlation ID in the original requests, because otherwise requesters cannot correct or retract requests until they receive a reply from the service.
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>
|
|
|
|
|
|
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.
|
|
|
|
<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).
|
|
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:
- trade
- novation
- increase
- termination
- amendment
- optionExercise / optionExpiry
- deClear
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.
3.4.3.1 Non-Public Execution Reporting Flow
FpML has developed messages to support reporting by reporting parties and execution facilities into swaps data repositories, to support the regulatory reporting requirements mandated by the Dodd-Frank Act. The following diagram shows how the different entities in the reporting process may use the FpML public reporting messages (in blue, labeled "PET" for "Primary Economic Terms") to report on trade execution to SDRs.
3.4.3.1.1 Non-Public Execution Report
The non-public execution report message is provided for reporting parties and agents (such as execution platforms) to report on the execution of trades to Swaps Data Repositories for regulatory reporting purposes. The non-public execution report contains a complete representation of the economic terms of each product.
|
|
3.4.3.1.2 Non-Public Execution Report Correction
The non-public execution report may contain mistakes. The NonpublicExecutionReport type allows corrections (provided it is still possible to do so), by sending a corrected execution report correlated to a prior report with "isCorrection" element set to "true".
3.4.3.1.3 Non-Public Execution Retraction
The execution report can be retracted (provided it is still possible to do so) by correlating execution retracted message to the execution report.
|
|
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.