Правила заполнения полей

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

Пространства имён

Формат сообщений репозитария состоит из трёх пространств имён:

• FpML Recordkeeping - http://www.fpml.org/FpML-5/recordkeeping
• Официальные расширения FpML - http://www.fpml.org/FpML-5/ext
• Расширения НРД - http://www.fpml.org/FpML-5/recordkeeping/nsd-ext

Эти пространства разнесены по файлам fpml-recordkeeping-merged-schema.xsd, fpml-ext-merged-schema.xsd и nsd-ext-merged-schema.xsd соответственно.

Корневой тэг любого сообщения при этом должен содержать следующие атрибуты:

<root   xmlns='http://www.fpml.org/FpML-5/recordkeeping' 
                                        xmlns:fpmlext='http://www.fpml.org/FpML-5/ext'
                                        xmlns:nsdext='http://www.fpml.org/FpML-5/recordkeeping/nsd-ext'  
                                        xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' 
                                        fpmlVersion='5-4' 
                                        xsi:schemaLocation='http://www.fpml.org/FpML-5/recordkeeping fpml-recordkeeping-merged-schema.xsd http://www.fpml.org/FpML-5/recordkeeping/nsdext nsd-ext-merged-schema.xsd http://www.fpml.org/FpML-5/ext fpml-ext-merged-schema.xsd'>

Таким образом, при использовании в сообщении элементов, необходимо учитывать префикс пространства имён.

Для пространства http://www.fpml.org/FpML-5/recordkeeping, их имена следует использовать как есть, не предваряя их префиксом. Например:

<partyTradeInformation>
    ...
</partyTradeInformation>

Для пространства имён http://www.fpml.org/FpML-5/ext используется префикс fpmlext.
Например:

<fpmlext:repo>
    ...
</fpmlext:repo>

Для пространства имён http://www.fpml.org/FpML-5/recordkeeping/nsd-ext используется префикс nsdext.
Например:

<nsdext:masterAgreementTerms>
    ...
</nsdext:masterAgreementTerms>

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

В сообщениях в формате FpML лица, упоминающиеся в сообщении описываются в блоке PartiesAndAccounts.model, расположенном как правило в конце сообщения. Каждому участнику соответствует один блок party, содержищий идентификатор (в сообщениях репозитария НРД - репозитарный код) и краткое наименование лица. Для каждого блока задаётся атрибут @id, который в других частях сообщения используется для указания ссылки на данного участника, путём задания соответствующего атрибута @href. Для данных блоков существует набор правил.

Идентификатор (@id)

Атрибут @id может принимать одно из следующих значений:

TradeRepository

Задаётся для описания репозитария НРД.

Party1

Задаётся для блока, описывающего сторону 1 в терминах генерального соглашения. Это означает, что если участник А по генеральному соглашению является первой стороной, то в сообщениях (на регистрацию генерального соглашения или на регистрацию договора) он должен описываться в блоке party с атрибутом @id равным Party1.

Party2

Задаётся для блока, описывающего сторону 2 в терминах генерального соглашения. Это означает, что если участник А по генеральному соглашению является второй стороной, то в сообщениях (на регистрацию генерального соглашения или на регистрацию договора) он должен описываться в блоке party с атрибутом @id равным Party1.

Sender

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

Receiver

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

Набор блоков party

Каждое сообщение, направляемое ИЛом на регистрацию анкеты должно сдержать четыре блока party:

<party id='TradeRepository'>
    <!-- -->
    <partyId>NDC0000000000</partyId>
    <!-- -->
    <partyName>НКО АО НРД</partyName>
</party>
<party id='Party1'>
    <!-- Указываем репозитарный код первой стороны -->
    <partyId>P000000000111</partyId>
    <!-- Наименование (имя) участника. -->
    <partyName>Клиент репозитария 1</partyName>
</party>
<party id='Party2'>
    <!-- Указываем репозитарный код первой стороны -->
    <partyId>P00000000222</partyId>
    <!-- Наименование (имя) участника. -->
    <partyName>Клиент репозитария 2</partyName>
</party>
<!-- Отправитель сообщения. -->
<party id='Sender'>
    <partyId>P000000000111</partyId>
    <partyName>Клиент репозитария 1</partyName>
</party>

<party id='TradeRepository'>
    <!-- -->
    <partyId>NDC0000000000</partyId>
    <!-- -->
    <partyName>НКО АО НРД</partyName>
</party>
<party id='Party1'>
    <!-- Указываем репозитарный код первой стороны -->
    <partyId>P000000000111</partyId>
    <!-- Наименование (имя) участника. -->
    <partyName>Клиент репозитария 1</partyName>
</party>
<party id='Party2'>
    <!-- Указываем репозитарный код первой стороны -->
    <partyId>P00000000222</partyId>
    <!-- Наименование (имя) участника. -->
    <partyName>Клиент репозитария 2</partyName>
</party>
<!-- Получатель сообщения. -->
<party id='Receiver'>
    <partyId>P000000000111</partyId>
    <partyName>Клиент репозитария 1</partyName>
</party>

Отличие между двумя приведёнными выше примерами заключается в последнем блоке party - у них задаются разные атрибуты @id.

Исключениями из этого правила являются сообщения Подтверждение параметров Анкеты генерального соглашения/договора (CM001) и Уведомление о несогласии с параметрами (CM002). Для этих сообщений участник заполнят два блока party.

<party id='TradeRepository'>    
    <partyId>NDC0000000000</partyId>    
    <partyName>НКО АО НРД</partyName>
</party>
<!-- Отправитель сообщения. -->
<party id='Sender'>
    <partyId>P000000000111</partyId>
    <partyName>Клиент репозитария 1</partyName>
</party>

Заголовок сообщения

В заголовке сообщения указываются отправитель и получатель сообщения: sentBy и sendTo. В этих элементах указываются репозитарные коды отправителя (sentBy) и получателя (sendTo) сообщения. Детальное описание стороны даётся в блоках party внизу сообщения.

Для сообщения, направляемого участником в репозитарий полю sentBy соответствует блок party с атрибутом @id равным Sender, а полю sendTo соответствует party c @id='TradeRepository'.

Для сообщения, направляемого репозитарием участнику полю sentBy соответствует блок party с атрибутом @id равным TradeRepository, а полю sendTo соответствует party c @id='Receiver'.

<header>
    ...
    <sentBy>P000000000111</sentBy>
    <sendTo>NDC0000000000</sendTo>
    ...
</header>
...
<party id='TradeRepository'>
    <!-- -->
    <partyId>NDC0000000000</partyId>
    <!-- -->
    <partyName>НКО АО НРД</partyName>
</party>
...
<!-- Отправитель сообщения. -->
<party id='Sender'>
    <partyId>P000000000111</partyId>
    <partyName>Клиент репозитария 1</partyName>
</party>

<header>
    ...
    <sentBy>NDC0000000000</sentBy>
    <sendTo>P000000000111</sendTo>
    ...
</header>
...
<party id='TradeRepository'>
    <!-- -->
    <partyId>NDC0000000000</partyId>
    <!-- -->
    <partyName>НКО АО НРД</partyName>
</party>
...
<!-- Получатель сообщения. -->
<party id='Receiver'>
    <partyId>P000000000111</partyId>
    <partyName>Клиент репозитария 1</partyName>
</party>

Клиенты сторон

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

<account id='ClientParty1'>
    <!-- Код клиента, присвоенный ему стороной -->
    <accountId></accountId>
    <!-- Ссылка на описание стороны, чьим клиентом является данное лицо -->
    <servicingParty href='Party1'/>
</account>

Значение атрибута @id может принимать значение ClientParty1 или ClientParty2 в зависимости от того, клиентом какой из сторон генерального соглашения является данное лицо.

В сообщении может быть заполнено не более двух блоков account. Элемент accountId заполняется кодом, присвоенным стороной своему клиенту в соответствии с Приказом ФСФР. В блоке account заполняется не более одного элемента accountId.

Атрибут accountIdScheme и accountNameScheme, а также элементы accountName, accountType и accountBeneficiary не используются.

Элемент servicingParty должен содержать заполненный атрибут @href, в котором должно быть указано значение атрибута @id блока party, описывающего сторону, обслуживающую данного клиента.

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

Для прохождения процедуры сверки в Репозитарии, требуется соблюдать следующие правила присвоения идентификаторов инструментов в xml-сообщениях, направляемых в Репозитарий:

Номер сообщения

Номер сообщения, направляемого в репозитарий указывается в элементе messageId блока header и должен являться строкой, состоящей из не более чем 35-и цифр и/или букв английского алфавита.

correlationId

Данный элемент используется для связывания нескольких сообщений в одну цепочку. Инициатор процесса регистрации какой-либо сделки, формируя исходное сообщение в репозитарий, с которого начинается процесс обмена сообщениями между ним, репозитарием и ИЛ-ом второй стороны, указывает в сообщении этот узел, задавая ему значение по правилу:
[Репозитарный код отправителя]-[Год]-[Исх. номер сообщения].

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

parentCorrelationId

Ссылка на уникальный, в рамках инициатора, исходящий номер анкеты генерального соглашения (см. п. correlationId). Заполняется в анкете договора, при одновременной подаче на регистрацию анкет генерального соглашения и договора, заключенного в рамках этого генерального соглашения.

isCorrection

Значение этого элемента равно true только в сообщениях, направляемых в репозитарий для внесения изменений в ранее переданные анкеты (ещё не зарегистрированные). В остальных случаях значение false.

Расширенные типы

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

Использование специального типа указывается в сообщении в явном виде, путём указания у соответствующего элемента атрибута xsi:type со значением, равным имени расширенного типа. Так, например, во всех сообщениях репозитария используется расширенный тип элемента <trade>. В связи с этим соответствующий элемент в сообщении описывается в следующем виде:

<trade xsi:type='nsdext:TradeNsd'>
    ...
</trade>

Список таких расширенных типов приводится в справочнике.