NSD’s trade repository messages specifications

Current specification

Сообщения репозитария

nonpublicExecutionReport

The key message for the participant. This message is used by the participant to:

  • send a contract form / master agreement form to the repository for primary registration
  • submit changes to a form that is not yet registered
  • submit a form to register changes to terms and conditions of the registered trade
  • This message is also used by the Repository to send a confirmation request.

The form CM010 - Master agreement form is used in the following business processes:

  • "Master agreement registration" - one-way notification
  • "Master agreement registration" - bilateral consecutive confirmation

The form CM011 - Master agreement termination form is used in the following business processes:

  • Termination of the master agreement and cease of services with respect of the master agreement

The form CM021 - Contract form is used in the following business processes:

  • "Contract registration" - one-way notification
  • "Contract registration" - bilateral cross confirmation
  • "Contract registration" - bilateral combined confirmation

The form CM041 - Repo form is used in the following business process:

  • "Contract registration" - one-way notification
  • "Contract registration" - bilateral cross confirmation
  • "Contract registration" - bilateral combined confirmation

The form CM091 - Form for contracts based on master agreements with maturity less than 4 working days is used in the following business processes:

  • "Quarter report registration" - one-way notification
  • "Quarter report registration" - bilateral consecutive confirmation

The form CM092 - Contract collateral and execution transfers form is used in the following business processes:

  • "Obligation fulfilment registration" - one-way confirmation
  • "Obligation fulfilment registration" - bilateral consecutive confirmation

The form CM093 - Contract obligation status form is used in the following business processes:

  • "Contract obligation status registration" - one-way notification
  • "Contract obligation status registration" - bilateral consecutive confirmation

The form RM005 - Confirmation request is used in the following business processes:

  • "Contract registration" - bilateral combined confirmation
  • "Quarter report registration" - bilateral consecutive confirmation
  • "Obligation fulfilment registration" - bilateral consecutive confirmation
  • "Contract obligation status registration" - bilateral consecutive confirmation "Termination of the master agreement and cease of services with respect of the master agreement"

Message structure

FieldTypeDescriptionPrint form titleFFSM titlePropertiesConditions
headerRequestMessage​HeaderMessage header.0-1, mre
validationValidationA list of validation sets the sender asserts the document is valid with respect to. This field is never filled for NSD messages. 0-∞, ncf
isCorrectionxsd:booleanIndicates if this message corrects an earlier request.Correction message mark0-1, mre, nfr
parentCorrelat​ionIdCorrelationIdA reference to message which register a master agreement. Should be filled in messages for trade registration when they are being send together with master agreement registration message. Related document form identifier0-1, nfr
correlationIdCorrelationIdA qualified identifier used to correlate between messages. For NSD messages the format is [Sender identifier]-[Year]-[Message ID]. Messages chain identifier0-2, mre, nfrIn NSD repository messages only one correlationId element must be filled.
sequenceNumberxsd:positiveIn​tegerA numeric value that can be used to order messages with the same correlation identifier from the same sender. 0-1, ncfThis is not used in messages to the repository.
onBehalfOfOnBehalfOfIndicates which party (or parties) (and accounts) a trade or event is being processed for. Normally there will only be a maximum of 2 parties, but in the case of a novation there could be a transferor, transferee, remaining party, and other remaining party. Except for this case, there should be no more than two onABehalfOf references in a message. Message on behalf of.0-4, ncfThis model is used in messages sent for registration by the repository only.
asOfDateIdentifiedDateThe date for which this document reports positions and valuations.Event's actual date0-1, mre, mfr
asOfTimexsd:time0-1, ncfThis is not used in messages to the repository.
portfolioRefer​encePortfolioRefer​enceBase0-1
Choice begin
Branch1
originatingEve​ntOriginatingEve​nt0-1, ncfThis is not used in messages to the repository.
tradeTradeInformation about master agreement or trade which is being reported. Attribute xsi:type is not described for master agreement, but for trade xsi:type="TradeNsd". Form initial registration1-1, mre
Branch2
amendmentTradeAmendment​ContentNegotiated amendment to a trade. Used to communicate information on the amendments to the terms of a trade. Amendment is the bilaterally agreed revision of one or more terms of a contract that involves more than a change in notional and has an economic effect. This is not to be confused with a correction to a previous notification of the same contract event. Form values negotiated amendment1-1, mre
Branch3
increaseTradeNotionalC​hangeNotional amount increase event. This is used to transfer information about the change of the trade notional amount and the payment made between the parties of the trade which is related to such notional change. Notional amount increase.1-1, ncfThis is not used in messages to the repository.
Branch4
terminatingEve​ntTerminatingEve​ntThis may be used to describe why a trade was terminated. This field is only field for message which register a repository agreement break. In this case value must be 'BreakRepositoryAgreement'. Agreement break reason0-1, ncfThis is not used in messages to the repository.
terminationTradeNotionalC​hangeDescription of a trade termination event. It's used to transfer information about the change of the trade notional and the payment made between parties of the trade which is related to such notional change. Termination event includes the full or partial end of the contract. The partial termination is, in effect, a decrease of the notional and is also known as a “decrease”. A full termination is the cancellation of the notional of the contract and also known as “close” or “unwind” of a trade. Trade termination1-1This is not used in messages to the repository.
Branch5
novationTradeNovationC​ontent1-1, ncfThis is not used in messages to the repository.
Branch6
optionExerciseOptionExercise1-1, ncfThis is not used in messages to the repository.
Branch7
optionExpiryOptionExpiry1-∞, ncfThis is not used in messages to the repository.
Branch8
deClearDeClearDefine an de-clear event.1-1, ncfThis is not used in messages to the repository.
Branch9
withdrawalWithdrawal1-1, ncfThis is not used in messages to the repository.
Branch10
additionalEventField must be replaced by one of next elments: executionStatus, reportAmendment, masterAgreementTermination, designationRA, rejectionRA, report, 1-1, mre
Choice end
quoteBasicQuotation0-∞, ncf
partyPartyA legal entity or a subdivision of a legal entity. Parties can perform multiple roles in a trade lifecycle. For example, the principal parties obligated to make payments from time to time during the term of the trade, but may include other parties involved in, or incidental to, the trade, such as parties acting in the role of novation transferor/transferee, broker, calculation agent, etc. In FpML roles are defined in multiple places within a document. In repository messages this includes reporting role of a party. Party0-∞, mre
accountAccountOptional account information used to precisely define the origination and destination of financial instruments. In particular this may include client account reference when defined in this group. Party's clients.Party's client.0-∞, ncf
NonpublicExecutionReport