Сообщения и логика их обработки

Спецификация сообщений торгового репозитария

НКО АО НРД

Используемые сообщения

Обмен информации между участниками финансовых рынков происходит в рамках каких-то бизнес-процессов. В FpML такие бизнес-процессы условно разделяются на четыре группы и для них в Master-схеме описываются свои наборы сообщений. Репозитарий НРД в своём протоколе использует сообщения процесса recordkeeping и набор собственных сообщений.

Полный набор сообщений из стандарта FpML избыточен для решения задач локального репозитария, поэтому используется лишь подмножество сообщений FpML. К ним также добавляются несколько собственных сообщений, для решения задач, связанных со спецификой требования регулятора; эти сообщения создаются в полном соответствии с требованиями стандарта, являясь расширениями базовых типов сообщений FpML.

Сообщения процесса Recordkeeping

Из fpml-recordkeeping-process.xsd (который помимо пространства recordkeeoing-view также содержится и в используемом репозитарием пространстве reporting-view) в новом формате заимствуются следующие сообщения.

Сообщение Описание
nonpublicExecutionReport Сообщение используется для первичной отправки анкет на регистрацию, а также для отправки запросов на внесение изменений в отправленные ранее анкеты.
nonpublicExecutionReportAcknowledgement Сообщение используется для оповещения участников репозитарием об успешной регистрации данных.
nonpublicExecutionReportRetracted Сообщение используется для отзыва ранее отправленных, но ещё не зарегистрированных анкет.
nonpublicExecutionReportException Сообщение используется для отправки репозитарием участникам информации о неудачной валидации анкет или неудачной сверке, в том числе сообщение содержит детальную информацию о том, где именно в сообщении найдены не согласующиеся данные.

Собственные сообщения репозитария НРД

Помимо указанных выше сообщений FpML репозитарий НРД в своём формате также использует несколько собственных сообщений.

Сообщение Описание
statementRequest Направляется участником репозитария для запроса выписки по зарегистрированным договорам.
statementReport Выписка по зарегистрированным договорам. Направляется репозитарием участнику.
reportDifference Уведомление о расхождениях, найденных в процессе сверки анкет контрагентов.
pendingMessagesReport Ежедневный отчёт репозитария, содержищий информацию об анкетах, находящихся в статусе "Ожидание".

Сопоставление старых и новых сообщений

Каждое сообщение содержит набор сущностной информации, которую непосредственно нужно обработать, а также набор признаков, из которых делается вывод о том, что именно нужно сделать с сущностной информацией.

Признаки, определяющие назначение сообщения

Три критерия, по которым обработчик понимает назначение сообщения.

Корневой тэг

Первое, из чего можно судить о назначении сообщения является его корневой тэг. Далее будем называть его именем сообщения. Так, например, корневой тэг <nonpublicExecutionReport> говорит о том, что в сообщении содержится информация одного из перечисленных ниже назначений:

  • анкета договора|генерального соглашения на первичную регистрацию;
  • часть договора|генерального соглашения для внесения изменений.

Тэг <nonpublicExecutionReportException> говорит о том, что в сообщении содержится информация об ошибке при первичной (до квитовки и сверки) обработке анкеты либо в процессе сверки.

Признак isCorrection

Если значение этого поля равно False, то сущностная информация сообщения направляется для первичной регистрации. Если же значение равно True, то сущностная информация сообщения направляется для внесения изменений в отправленные ранее данные. Признак используется только в сообщениях, унаследованных от <CorrectableRequestMessage>.

Events.model

Набор узлов (элементов, тэгов), описывающих экономические события - сделки и post-trade события. Например, внутри тэга <trade> описывается конкретная сделка. Внутри тэга <optionExpiry> описывается экспирация опциона.

Отдельным пунктом в <Events.model> стоит элемент <additionalEvent>. Он является наследником абстрактного типа <AdditionalEvent>, что позволяет определять собственные типы бизнес-событий, унаследованные от <AdditionalEvent>.

Trade

Тип <Trade> используется для передачи информации об отдельной сделке. Одним из его узлов является элемент <product>, абстрактного типа Product. От этого типа унаследованы все типы, описывающие конкретные финансовые инструменты, например <FxSwap> или <BondOption>. Таким образом, внутри <Trade> на месте элемента <product> могут быть несколько других тэгов:

        <trade>
            <tradeHeader>
                ...
            </tradeHeader>
            <fxSwap>
                ...
            </fxSwap>
        </trade>            
        <trade>
            <tradeHeader>
                ...
            </tradeHeader>
            <bondOption>
                ...
            </bondOption>
        </trade>            
        <trade>
            <tradeHeader>
                ...
            </tradeHeader>
            <swaption>
                ...
            </swaption>
        </trade>