СТАНДАРТ БАНКА РОССИИ

СТО БР НПС-1.4-2019

Финансовые сообщения в НПС

Правила обмена данными в национальной платежной системе



Дата введения: 2019-09-30



Предисловие


ПРИНЯТ И ВВЕДЕН в действие приказом Банка России от 20 сентября 2019 года N ОД-2191 "О введении в действие стандарта Банка России СТО БР НПС-1.4-2019 "Финансовые сообщения в НПС. Правила обмена данными в национальной платежной системе".

Настоящий Стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Банка России.

Введение


Настоящий Стандарт содержит рекомендации по реализации обмена данными в соответствии со стандартом ISO 20022 при переводе денежных средств в национальной платежной системе (далее - НПС).

________________

Международный стандарт ISO 20022 "Финансовые услуги - Универсальная схема сообщений для финансовой отрасли" (Financial services - Universal financial industry message scheme).

     1. Область применения


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

Положения настоящего Стандарта применяются на добровольной основе, если только в отношении конкретных положений обязательность их применения не установлена нормативными актами Банка России или условиями договоров.

     2. Термины и определения


В настоящем Стандарте применяются термины в соответствии со Стандартом Банка России СТО БР НПС-1.0-2017 "Финансовые сообщения в НПС. Общие положения" и Федеральным законом от 06.04.2011 N 63-ФЗ "Об электронной подписи", а также следующие термины с соответствующими определениями.

Сетевая модель
ВОС

-

базовая эталонная модель взаимодействия открытых систем в соответствии с ГОСТ Р ИСО/МЭК 7498-1-99 "Государственный стандарт Российской Федерации. Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель";

Сообщение

-

набор структурированной информации (в электронном виде), которой осуществляется обмен между двумя участниками информационного взаимодействия с использованием средств телекоммуникации;

Бизнес-сообщение

-

электронное сообщение стандарта ISO 20022, предназначенное для передачи прикладных данных между участниками информационного взаимодействия;

Транспортное сообщение

-

конверт, соответствующий спецификации SOAP 1.2, в заголовках которого находятся структуры, связанные с подписанием и шифрованием сообщения, а в теле передается бизнес-сообщение;

Способ доставки сообщения

-

группа параметров настройки для величин, определяющих характеристики доставки сообщений;

Система доставки сообщений

-

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

Участник
информационного
взаимодействия

-

субъект, который создает, обрабатывает, принимает или отправляет электронные сообщения;

Хеш

-

строка ограниченной длины, полученная путем выполнения специальных преобразований над исходными данными в соответствии с ГОСТ Р 34.11-2012;

Deflate

-

алгоритм сжатия данных без потерь;

Base64

-

стандарт кодирования последовательности байт в строку и из строки в последовательность байт;

Валидация

-

проверка входных данных по заданным правилам.



     3. Общие положения


В соответствии с положениями части 6 "Характеристики транспортировки сообщений" (ISO 20022-6 "Message transport characteristics") стандарта ISO 20022 обмен данными в рамках НПС выполняется в следующих слоях:

- бизнес-слой - самый верхний слой, в котором определены правила и сценарии обмена бизнес-сообщениями, а также структуры бизнес-сообщений, используемых в процессах обмена в рамках конкретных моделей связей НПС. Бизнес-слой эквивалентен добавлению уровня 9 к Сетевой модели ВОС;

- слой транспортировки сообщений - слой, в котором определены правила обмена электронными сообщениями, независимо от бизнес-слоя. Слой транспортировки сообщений эквивалентен добавлению уровня 8 к Сетевой модели ВОС;

- прикладной слой - самый нижний слой обмена, соответствующий уровню 7 Сетевой модели ВОС.

Настоящий Стандарт определяет рекомендации по обмену данными в рамках НПС в каждом из указанных выше слоев. Соблюдение настоящих рекомендаций позволит обеспечить функциональную совместимость (интероперабельность) взаимодействующих в рамках НПС информационных систем, поддерживающих ISO 20022.

     4. Бизнес-слой


В бизнес-слое обмен данными реализуется путем передачи бизнес-сообщений. Бизнес-сообщение представляет собой совокупность бизнес-заголовка и содержимого сообщения, описанного в Стандартах ISO 20022 НПС.

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

Бизнес-сообщения должны содержать всю информацию, необходимую для их корректной интерпретации Участниками информационного взаимодействия, должны быть понятны вне контекста транспортного конверта (раздел 5 настоящего Стандарта).

Бизнес-сообщения должны быть представлены в виде XML-документов и должны соответствовать XML-схемам и правилам заполнения документов, описанным в Стандартах ISO 20022 НПС.

     4.1. Правила обмена данными в бизнес-слое


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

При описании обмена в бизнес-слое задаются Способы доставки сообщений (MessageTransportMode), которые определяют группы характеристик доставки сообщений, описанные в части 1 "Метамодель" (ISO 20022-1 "Metamodel") стандарта ISO 20022. Характеристики доставки сообщений справочно приведены в Таблице 4.1 настоящего Стандарта.

________________

www.iso20022.org.

Определенные в бизнес-слое Способы доставки сообщений должны быть реализованы в слое транспортировки сообщений и (или) прикладном слое.

     Таблица 4.1. Характеристики доставки сообщений

Характеристика

Описание

Обеспечение доставки (DeliveryAssurance)

Принимает одно из следующих значений:

не менее одного раза (AT_LEAST_ONCE),

в точности один раз (EXACTLY_ONСЕ),

не более одного раза (AT_MOST_ONCE)

Асинхронность отправителя (SenderAsynchronicity)

Принимает одно из следующих значений:

конечная точка синхронна (ENDPOINT_SYNCHRONOUS),

обмен синхронен (CONVERSATION_SYNCHRONOUS),

асинхронен (ASYNCHRONOUS)

Асинхронность получателя (ReceiverAsynchronicity)

Принимает одно из следующих значений:

конечная точка синхронна (ENDPOINT_SYNCHRONOUS),

обмен синхронен (CONVERSATION_SYNCHRONOUS),

асинхронен (ASYNCHRONOUS)

Порядок доставки сообщения (MessageDeliveryOrder)

Принимает одно из следующих значений:

порядок сохраняется для всех получателей и отправителей сообщений (EXPECTED_CAUSAL_ORDER),

порядок сохраняется только для каждой пары получателя и отправителя сообщений (FIFO_ORDERED),

порядок не сохраняется (UNORDERED)

Окно доставки сообщения (MessageDeliveryWindow)

Максимальная продолжительность времени, в пределах которого транспортное сообщение может быть доставлено без учета очередности. Значения должны быть большими или равными нулю.

Окно отправки сообщения (MessageSendingWindow)

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

Метод рассылки сообщения (MessageCasting)

Принимает одно из следующих значений:

односторонняя рассылка (UNICAST),

групповая рассылка (MULTICAST),

рассылка по списку (BROADCAST),

любая рассылка (ANYCAST)

Ограниченная задержка связи (BoundedCommunicationDelay)

Максимальная продолжительность времени, в пределах которого сообщение должно быть доставлено. В качестве значения должна быть задана продолжительность времени в соответствии с ISO 8601

Валидация сообщений
включена/отключена
(MessageValidationOnOff)

Принимает одно из следующих значений:

валидация включена (VALIDATION_ON) - сообщения валидируются Системой доставки сообщений,

валидация отключена (VALIDATION_OFF) - сообщения не валидируются Системой доставки сообщений

Результаты валидации
сообщения
(MessageValidationResults)

Принимает одно из следующих значений:

отклонение (REJECT),

отклонение и доставка (REJECT_AND_DELIVER),

доставка (DELIVER)

Уровень валидации сообщения (MessageValidationLevel)

Уровень валидации сообщения, требуемый Системой доставки сообщений.

Принимает одно из следующих значений:

сообщение не валидировалось (NO_VALIDATION),

провалидирован синтаксис сообщения (SYNTAX_VALID),

сообщение соответствует XML-схеме (SCHEMA_VALID),

сообщение соответствует ... правилам (MESSAGE_VALID),

сообщение соответствует бизнес-правилам (RULE_VALID),

сообщение соответствует рыночной практике (MARKET_PRACTICE_VALID),

сообщение соответствует бизнес-процессу (BUSINESS_PROCESS_VALID),

полностью валидное сообщение (COMPLETELY_VALID)

Длительность хранения (Durability)

Принимает одно из следующих значений:

долговременно (DURABLE),

постоянно (PERSISTENT),

временно (TRANSIENT)

Максимальное отклонение времени (MaximumClockVariation)

Максимальное отклонение от Всемирного координированного времени (UTC) для обеспечиваемого Способа доставки сообщения

Максимальный размер сообщения (MaximumMessageSize)

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



     4.2. Структура бизнес-сообщений


Бизнес-сообщение имеет следующую структуру:

<BusinessMessage xmlns="urn:cbrf:iso:20022:business-message">

<AppHdr xmlns="urn:iso:std:iso:20022:tech:xsd:head.001.001.01">

<!-- Содержимое заголовка -->

</AppHdr>

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:xxxx.nnn.nnn.nn">

<!-- Содержимое документа -->

</Document>

</BusinessMessage>

В качестве заголовка бизнес-сообщения используется структура Business Application Header (ВАН). Структура задана в документе "ISO 20022 Business Application Header. Message Definition Report" (версия от 1 июня 2010 года). Рамочные правила ее использования заданы в документе "ISO 20022 Business Application Header Message Usage Guide Version 1.8" (версия от апреля 2016 года). Описание структуры заголовка бизнес-сообщения и правила ее заполнения для целей использования в НПС приведены в Таблице 4.2.

________________

www.iso20022.org.

     Таблица 4.2. Структура заголовка бизнес-сообщения

Прикладной атрибут

Правила формирования

Отправитель

Идентификатор отправителя записывается в реквизит AppHdr/Fr/*.
При этом обязательно указывается идентификационная схема в реквизите */SchmeNm/Cd (при использовании идентификационных кодов, зарегистрированных в ISO 20022) или */SchmeNm/Prtry (при использовании собственных идентификационных кодов).
В качестве основных типов идентификаторов могут выступать:
ОГРН, идентификационная схема - OGRN
ИНН, идентификационная схема -TXID
Российский БИК, идентификационная схема - RUCBC
УИС, идентификационная схема - RUCB
Может быть указан иной идентификатор, принятый Участниками информационного взаимодействия, позволяющий однозначно идентифицировать участника в цепочке обмена.
При формировании идентификатора отправителя и типа идентификатора недопустимо использование символов пробела, перевода строки, возврата каретки и табуляции

Получатель

Идентификатор получателя записывается в реквизит AppHdr/To/*.
Требования к идентификаторам атрибута Получатель аналогичны требованиям к идентификаторам атрибута Отправитель

Идентификатор сообщения

Идентификатор сообщения записывается в реквизит AppHdr/BizMsgldr.
Идентификатор сообщения должен быть уникальным по определенному Участнику информационного взаимодействия.
При формировании идентификаторов сообщения рекомендуется использовать алгоритмы создания универсальных уникальных идентификаторов (UUID) согласно спецификации RFC 4122 (см. таблицу 5.1). В целях соответствия требованиям ВАН к длине идентификатора, при записи UUID в реквизит AppHdr/BizMsgldr, в строковое представление UUID не должен включаться идентификатор пространства имен "urn:uuid:", а также должны быть исключены символы "-".
Пример идентификатора: "f81d4fae7dec11d0a76500a0c91e6bf6"

Тип сообщения

Тип бизнес-сообщения записывается в реквизит AppHdr/MsgDefldr.
Могут использоваться только типы сообщений, применяемые в НПС.
Пример: "pain.001.001.07"

Бизнес-сервис

Бизнес-сервис записывается в реквизит AppHdr/BizSvc.
Реквизит опциональный, правила заполнения определяются Участниками информационного взаимодействия

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

Дата и время формирования сообщения записываются в реквизит AppHdr/CreDt. Время указывается по Гринвичу

Этот документ входит в профессиональные
справочные системы «Кодекс» и  «Техэксперт»