Рекомендации по переходу на новый формат

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

НКО АО НРД

Рекомендации участникам

Для участников, ранее реализовавших текущий ("старый") формат, ниже даются комментарии по поводу основных отличий форматов. Ознакомление с данными комментариями позволит облегчить процесс перевода разработанных ранее систем на новый формат сообщений.

Отличия форматов

Справочники

В старом формате все ограничения на значения тех или иных элементов указывались непосредственно в файле схемы формата. Это делалось путём явного указания ограничений на формат или набор значений. Такой подход облегчает валидацию сообщений стандартными средствами.

В новом формате большинство информации об ограничениях вынесено во внешние справочники и описания форматов. Все скалярные типы, для которых необходимо указать ограничение на формат или набор значений, являются наследниками типа Scheme. Для каждого такого типа указывается атрибут (название атрибута разное для разных типов), в значении которого указывается гиперссылка на страницу, где описывается формат/справочник.

Так, например, тип PartyRole расширяет тип Scheme следующим образом:

<xsd:extension base="Scheme">
    <xsd:attribute name="partyRoleScheme" 
                    type="xsd:anyURI"
                    default="http://repository.nsd.ru/taxonomy/cs/party-role">               
    </xsd:attribute>
</xsd:extension>

Атрибут partyRoleScheme задаёт ссылку на описание формата/справочника, при этом его указание в явном виде в конкретном xml-сообщении необязательно, так как у него указано значение по умолчанию default="http://repository.nsd.ru/taxonomy/cs/party-role".

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

Переиспользование элементов

Сообщения старого формата несколько удобнее "читать глазами" ввиду того, что необходимые блоки всегда описываются в том месте сообщения, где они понадобились. Так, например, если в каком-либо блоке сообщение требуется привести информацию об участнике, то воспроизводится весь блок, описывающий такую информацию:

<PARTY>
    <id_2>
        <id>RZ0002500004</id>
        <id_type>RPZR</id_type>
    </id_2>
    <name>ЮЛ клиент 4</name>
</PARTY>

В новом формате применяется подход, при котором информация, которую можно переиспользовать описывается в документе(сообщении) один раз. У корневого элемента соответствующего блока указывается атрибут @id. После чего в любом месте сообщения, где необходимо привести такую информацию, вместо воспроизведения всего блока приводится лишь ссылка на уже описанный блок.

Пример описания информации об участнике с указанием атрибута id, на который в дальнейшем будет даваться ссылка:

<party id="Party1">
    <partyId>RZ0002500003</partyId>
    <partyName>ЮЛ клиент 3</partyName>
    <relatedParty>
        <partyReference href="Party1"/>
        <role>BaseReportingAgent</role>
        <type>AllPositions</type>
    </relatedParty>
</party>

Пример ссылки на блок с описанием участника:

<partyReference href='Party1'>

Такой подход потенциально снижает размер сообщений за счёт переиспользования информации.

Типизация сообщений

В старом формате построение сообщений шло от финансового инструмента, информация связанная с которым передавалась. Так, например, сообщения, связанные с валютным свопом, имели корневой элемент, начинающийся с подстроки SWAPCURRENCY_. Далее, в зависимости от назначения сообщения к имени корневого элемента добавлялось окончание. Кроме того, элемент <msgAction> сообщения уточнял назначение сообщения.

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

Пример

На примере сообщения, направляемого участником в репозитарий для регистрации генерального соглашения, сравним два формата. Ниже оба сообщения приводятся не в виде xml-файлов, а в виде графической интерпретации таковых. Каждый блок схемы соответствует элементу xml-файла. В любой из блоков (элементов) могут быть вложены другие блоки (элементы).

В угловых скобках приводится название элемента в сообщении, например - <messageId>. Если элемент содержит конкретное скалярное значение, то под названием приводится данное значение. Например, TEST-BAV-MA1-001. Курсивом даётся комментарий.

Сообщение в старом формате

<MA_REG_REQUEST>

Корневой тэг сообщения.

<header>

Заголовок сообщения, содержащий общую техническую информацию о сообщении.

<msgId>

TEST-BAV-MA1-001

Идентификатор сообщения, присвоенный ему отправителем

<msgDate>

2012-09-17

Время создания сообщения

<msgAction>

REGI

Назначение сообщения

<msgSender>

Отправитель сообщения

<id_2>

<id>

RZ0002500003

Значение идентификатора

<id_type>

RPZR

Тип идентификатора

<name>

ЮЛ клиент 3

Наименование отправителя

<msgReceiver>

Получатель сообщения

<id_2>

<id>

NSD00000000

Значение идентификатора

<id_type>

RPZR

Тип идентификатора

<name>

НКО АО НРД

Наименование отправителя

<ma_general>

Информация о генеральном соглашении

<maId>

NONREF

Репозитарный идентификатор сделки/генерального соглашения

<ma_info>

Параметры генерального соглашения

<maDate>

2012-09-14

Дата заключения генерального соглашения

<maRealDate>

2012-09-14

Эффективная дата генерального соглашения

<templateDetails>

ISDA

Тип генерального соглашения

<match_type>

MATH

Тип сверки договоров

<PARTY1>

Описание первой стороны соглашения

<tradeRef>

MA1-001_RZ0002500003

Номер соглашения в системе участника

<MACOUNTERPARTY>

<id_2>

<id>

RZ0002500003

<id_type>

RPZR

<name>

ЮЛ клиент 3

Наименование участника

<base_reporter1>

<id_2>

<id>

RZ0002500003

<id_type>

RPZR

<name>

ЮЛ клиент 3

Наименование участника

<PARTY2>

Описание первой стороны соглашения

<tradeRef>

MA1-001_RZ0002500004

Номер соглашения в системе участника

<MACOUNTERPARTY>

<id_2>

<id>

RZ0002500004

Идентификатор

<id_type>

RPZR

Тип идентификатора

<name>

ЮЛ клиент 4

Наименование участника

<base_reporter1>

Базовое информирующее лицо участника

<id_2>

<id>

RZ0002500004

Репозитарный идентификатор участника

<id_type>

RPZR

Тип идентификатора

<name>

ЮЛ клиент 4

Наименование участника

<REPORTER>

<id_2>

<id>

RZ0002500003

Репозитарный идентификатор участника

<id_type>

RPZR

Тип идентификатора

<name>

ЮЛ клиент 3

Наименование участника

<rep_dfi_type>

ALLD

Рапортуемые сделки

<rep_party>

all

За какие стороны отчитывается данное ИЛ

Сообщение в новом формате

<nonpublicExecutionReport>

Корневой тэг сообщения.

<header>

Заголовок сообщения, содержащий общую техническую информацию о сообщении.

<messageId>

TEST-BAV-MA1-001

Идентификатор сообщения, присвоенный ему отправителем

<creationTimestamp>

2012-09-17

Время создания сообщения

<sentBy>

RZ0002500003

Отправитель сообщения

<sendTo>

NSD00000000

Получатель сообщения

isCorrection

false

Признак, указывающий является ли данное сообщение корректировкой к направленному ранее аналогичному сообщению.

<asOfDate>

2012-09-14

Дата заключения сделки/генерального соглашения

<originatingEvent>

Trade

Причина совершения рапортуемой сделки

<trade>

Описание сделки/генерального соглашения

<tradeHeader>

Заголовок сделки, общая информация

<partyTradeIdentifier>

Идентификатор ген. соглашения, присвоенный репозитарием. Заполняется обязательно.

<partyReference>

@href='Repository'

Ссылка на описание участника

<tradeId>

NONREF

Значение идентификатора. NONREF при первичном направлении на регистрацию.

<partyTradeIdentifier>

Идентификатор ген. соглашения, присвоенный стороной. Заполняется опционально.

<partyReference>

@href='Party1'

Ссылка на описание участника

<tradeId>

NONREF

Значение идентификатора. NONREF при первичном направлении на регистрацию.

<partyTradeIdentifier>

Идентификатор ген. соглашения, присвоенный стороной. Заполняется опционально.

<partyReference>

@href='Party2'

Ссылка на описание участника

<tradeId>

NONREF

Значение идентификатора. NONREF при первичном направлении на регистрацию.

<masterAgreementTerms>

Параметры генерального соглашения

<breakRepoAgreement>

false

Признак того, что сообщение направляется с целью разрыва репозитарного договора.

<masterAgreementInformation>

Информация о генеральном соглашении

<masterAgreementType>

ISDA

Тип генерального соглашения

<masterAgreementConfirmation>

MATH

Способ согласования договоров

<servicesPayer>

Both

Определяет, кто платит за услуги репозитария

<party>

@id='Party1'

Описание первой стороны ГС.

<partyId>

RZ0002500003

Репозитарный идентификатор участника

<partyName>

ЮЛ клиент 3

Наименование участника

<relatedParty>

Ссылка на участника, играющего по отношению к описываемому участнику определённую роль

<partyReference>

@href='Party1'

Ссылка на участника

<role>

BaseReportingAgent

Роль

<type>

AllPositions

Уточнение роли

<relatedParty>

Ссылка на участника, играющего по отношению к описываемому участнику определённую роль

<partyReference>

@href='Party1'

Ссылка на участника

<role>

ReportingAgent

Роль

<type>

AllPositions

Уточнение роли

<party>

@id='Party2'

Описание второе стороны ГС.

<partyId>

RZ0002500004

Репозитарный идентификатор участника

<partyName>

ЮЛ клиент 4

Наименование участника

<relatedParty>

Ссылка на участника, играющего по отношению к описываемому участнику определённую роль

<partyReference>

@href='Party2'

Ссылка на участника

<role>

BaseReportingAgent

Роль

<type>

AllPositions

Уточнение роли

<relatedParty>

Ссылка на участника, играющего по отношению к описываемому участнику определённую роль

<partyReference>

@href='Party1'

Ссылка на участника

<role>

ReportingAgent

Роль

<type>

AllPositions

Уточнение роли

<party>

@id='Repository'

Описание репозитария

<partyId>

NSD000000000

Репозитарный идентификатор

<partyName>

НКО АО НРД

Наименование участника/репозитария