Уис эд уфэбс что это

Унифицированные форматы электронных банковских сообщений Банка России. Обмен с клиентами Банка России

1. Общая характеристика УФЭБС

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

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

1.3 УФЭБС разработаны на языке разметки XML.

2. Официальное описание УФЭБС

Полное описание взаимодействия клиентов с Банком России приведено в следующих документах:

2.1 Версия 2019.4.1, действующая с 30.09.2019 г.

2.2 Версия 2020.1.1, действующая с 01.01.2020 г.

2.3 Версия 2020.2.1, действующая с 30.03.2020 г.

Архивы содержат описание принципов построения интерфейсов обмена, перечень и форматы электронных сообщений, используемых в обмене, типовые схемы взаимодействия, соответствующие термины и определения, требования по защите электронных сообщений, а также формализованное описание структуры УФЭБС, разработанное в виде набора которые являются неотъемлемой частью описания УФЭБС. Кроме того, в архивы включены описания изменений, сделанных в данной версии документов.

Источник

Унифицированные форматы электронных банковских сообщений

Унифицированные форматы электронных банковских сообщений (УФЭБС) представляют собой единый стандарт финансовых сообщений для обмена внутри Российский Федерации. Пользователями данного формата является ЦБ РФ и клиенты ЦБ РФ, расположенные на территории России, валюта списания или валюта зачисления – российский рубль. Формат сообщений основан на стандарте ISO20022.

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

Альбом УФЭБС разработаны на языке разметки XML. В таблице приведены основные форматы документов.

Перевод сообщений между участниками может быть в двух видах: полноформатный или сокращённого формата.

Обмен сообщениями сокращённого формата допускается между воинскими частями, предприятиями и организациями Министерства обороны Российской Федерации

Каждое финансовое сообщение в обязательном порядке проходит регламентные контрольные процедуры: проходит контроль подлинности, структурный контроль, контроль на уникальность и логический контроль При переводе средств между участником-плательщиком и участником-получателем на основании платёжного поручения, платёжного ордера, платёжного поручения на общую сумму с реестром участник-плательщик составляет и направляет ED101, ED105, ED108. Статусная схема процесса обмена приведена ниже.

Если формируется распоряжение на бумажные носители, но платёжная система Банка России составляет электронное сообщение ED101, ED103, ED104, ED105, ED109, ED110, ED111 и направляет участнику на сформированное распоряжение в бумажном виде. Если из-за недостатка денежных средств распоряжение не может быть исполнено, но оно помещается во внутридневную очередь, где хранится до исполнения в течение операционного дня. Если пользователь захочет данное сообщение вывести из очереди, то он отправляет сообщение ED205 или ED805. Не исполненное сообщение в течение операционного дня возвращается пользователю со статусом не исполнено. При достаточном количестве средств платёжное сообщение исполняется в соответствии с регламентом, после чего Банк Росси отправляет участнику подтверждающий документ. В нижеприведённом примере сформировано платёжное поручение (формат Ed101).

Источник

Анатомия банка: кому нужен ED 108

Использование банками электронных платежных поручений “на общую сумму с реестром” регламентируется Положением БР N 384-П «О платежной системе Банка России» от 29 июня 2012 г. Подразумевается, что принятый к исполнению пакет распоряжений плательщиков детализируется в реестре (согласно Приложению 5 к 384-П). Общая сумма реестра должна совпадать с суммой, указанной в поручении “одной цифрой”, без детализации. Оформить платежное поручение на общую сумму с реестром имеет право как кредитная организация, так и ее филиал.

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

Платежное поручение на общую сумму с реестром соответствует формату ED 108 Альбома УФЭБС (унифицированных форматов электронных банковских сообщений для безналичных расчетов). Данный вид электронных сообщений разгружает систему БЭСП БР, поскольку идет через сервис несрочного перевода. Применяется ED 108, в первую очередь, в целях минимизации расходов на работу с физлицами, подразумевающую обработку небольших по деньгам, но многочисленных платежей. Формату уже несколько лет, но во многих кредитных организациях он все еще числится по разряду инноваций. И может быть субъективно воспринят каким-нибудь небольшим банком как своего рода технологический прорыв в деле автоматизации.

Практическое использование давно не нового, но все еще “новаторского” формата, а также дальнейшие перспективы ED 108 стали в ноябре предметом обсуждения на дискуссионной сессии III Национального Платежного Форума.

Формат быстро внедряется в тех случаях, когда у контрагентов есть опыт его использования. “Два года назад мы внедрили формат для работы с подразделениями Федерального казначейства. Кроме того, у нас есть 6 договоров с другими кредитными организациями, на основании которых мы обмениваемся с ними ED 108, причем довольно активно. Две из них уже использовали ED 108 до нас, предварительного двустороннего тестирования с ними проводить не потребовалось,” – поделился практикой Юрий Кощуг.

Через само Федеральное казначейство поручения в формате ED 108 проходят без проблем. Но бывает так, что от клиентов Казначейства суммы возвращаются обратно к отправителю. “Мы стали разбираться в одном таком конкретном случае. И выяснили, что причиной возврата была устаревшая версия ПО, которое, как я понимаю, Казначейство поставляет своим клиентам, – предположил г-н Кощуг. – Видимо, не все клиенты добросовестно к этому относятся. В результате чего, реестра, как такового, такой клиент “не видит”, не знает, что с этой суммой делать. И выбирает самый легкий способ – вернуть ее обратно”.

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

Публикации развернутых спецсправочников в разрезе ED 108 препятствует и то очевидное обстоятельство, что использование реестров при обмене между банками должно быть сегодня прописано в отдельно заключаемом договоре: по схеме каждый договаривается с каждым. Следовательно, отследить содержание таких договоров, обобщить извлеченные оттуда сведения в рамках единого справочника, а также вносить туда оперативные изменения (по мере их появления) – это задача, с чисто практической точки зрения, трудноразрешимая.

По поводу ED 108 в БР обращалось, например, партнерство НП «Национальный платежный совет». В частности, с предложением добавить формату полей. До сих пор, Банк России занимал по поводу таких обращений достаточно консервативную позицию.

Итак, сложностей на пути освоения ED 108 немало. Так сколько же банков им пользуется? “По нашим данным с 2013 года, 103 кредитные организации применяли этот документ хотя бы раз,” – привела цифру Светлана Ромашкина.

Источник

Информационная безопасность банковских безналичных платежей. Часть 2 — Типовая IT-инфраструктура банка

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

Disclaimer
Статья не содержит конфиденциальной информации. Все использованные материалы публично доступны в Интернете, в том числе на сайте Банка России.

Глава 1. Общее описание ИТ-инфраструктуры

Основные термины

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

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

В рамках данного исследования оба термина будут использоваться как синонимы.

Справедливость подобного подхода можно доказать тем, что в Приказе ФСТЭК России от 11.02.2013 N 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» для защиты информационных систем госрегулятор предписывает руководствоваться ГОСТами по автоматизированным системам.

Помимо информационных систем в IT-инфраструктуре банка можно выделить еще один тип элементов — информационные сервисы, или, как их часто называют, роботы.

Дать определение понятию информационный сервис довольно сложно, поэтому просто перечислим его основные отличия от информационной системы:

Автоматизированная банковская система

Ядром информационной инфраструктуры любого банка является автоматизированная банковская система или сокращенно АБС.

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

Данное определение позволяет подвести под него практически любую IT-систему в банке. В то же время обычные банковские служащие называют АБС ту систему, которая занимается учетом банковских счетов, проводок между ними (движением денежных средств) и остатков. Второе определение не противоречит первому и более четко его детализирует, им и будем пользоваться дальше.

В современных Российских банках наиболее распространенными являются следующие АБС :

Иногда в банках параллельно используют несколько АБС различных производителей. Зачастую это происходит, когда банк пытается перейти с одной АБС на другую, но возможны и менее тривиальные причины.

Прикладные информационные системы

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

Примерами прикладных информационных систем могут быть:

Инфраструктурные информационные системы

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

Информационные сервисы

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

Клиентские части сторонних информационных систем

Отдельного упоминания стоят клиентские части внешних по отношению к банку информационных систем. В качестве примеров приведу:

Типовые способы интеграции информационных систем

Для интеграции информационных систем обычно применяются следующие механизмы:

Модули интеграции

Под модулем интеграции будем понимать виртуальный элемент IT-инфраструктуры, реализующий интеграцию других элементов IT-инфраструктуры.

Данный элемент мы назвали виртуальным, потому что его функционал может быть реализован, как в виде отдельного специализированного элемента ИТ-инфраструктуры (например, информационного сервиса), так и в виде компонентов интегрируемых информационных систем. Более того, в качестве модуля интеграции может выступать даже человек, «вручную» переносящий информацию между интегрируемыми информационными системами.

Пример ИТ-инфраструктуры банка

На Рис.1 можно увидеть фрагмент типовой информационной инфраструктуры банка, содержащий рассмотренные выше типы элементов.

Глава 2. Инфраструктура безналичных расчетов

Если посмотреть на эту схему (Рис.1) с точки зрения осуществления безналичных расчетов, то можно увидеть, что банк реализует их при помощи:

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

Инфраструктура обеспечения платежного взаимодействия с Банком России

Рис. 2.
IT-инфраструктуру платежного взаимодействия банка с Банком России будем рассматривать на примере исполнения платежа, отправляемого в адрес клиента другого банка.

Как мы помним из первой части, вначале клиент должен передать в банк платежное поручение. Сделать это он может двумя способами:

Если клиент передал платежное поручение на бумажном носителе, то работник банка на его основании делает электронное платежное поручение в АБС. Если распоряжение было подано через ДБО ИКБ, то через модуль интеграции оно попадает в АБС автоматически.

Доказательством того, что именно клиент сделал распоряжение о переводе денежных средств, в первом случае является лично подписанный им бумажный документ, а во втором, электронный документ в ДБО ИКБ, заверенный в соответствии с договором.

Обычно для заверения электронных документов клиентов — юридических лиц в ДБО ИКБ применяют криптографическую электронную подпись, а для документов клиентов — физических лиц коды SMS-подтверждений. С юридической точки зрения для заверения электронных документов в обоих случаях банки обычно применяют правовой режим аналога собственноручной подписи (АСП).

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

Технические средства взаимодействия с платежной системой Банка России

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

Для банков, обслуживаемых в Московском регионе, применяется следующее ПО:

АРМ КБР

АРМ КБР – это ПО, с помощью которого уполномоченные работники банка осуществляют шифрование и электронную подпись исходящих платежных документов, а также расшифровку и проверку электронной подписи платежных документов, поступающих из Банка России. Но, если быть более точным, то АРМ КБР в своей работе оперирует не платежными документами, а электронными сообщениями (ЭС), которые бывают двух типов:

Для того чтобы АРМ КБР мог обработать платеж, он должен быть преобразован в файл, содержащий электронное платежное сообщение формата УФЭБС. За подобное преобразование отвечает модуль интеграции АБС с платежной системой Банка России. С технической точки зрения подобные преобразования довольно просты, поскольку формат УФЭБС основан на XML.

Файлы электронных сообщений покидают модуль интеграции АБС в открытом виде и помещаются в специальную папку файловой системы (обычно это сетевая папка), которая настроена в АРМ КБР для электронных сообщений, имеющих статус «Введенные». На ранее представленной схеме (Рис. 2.) эта папка обозначена как «Папка 1».

Затем в процессе обработки электронные сообщения меняют свои статусы на «Контролируемые», «Отправленные» и т. д., что технически реализуется путем перемещения файла с электронным сообщением в соответствующие папки, которые настроены в АРМ КБР. На схеме (Рис. 2.) эти папки обозначены как «Папка 2».

В определенный момент технологической обработки (установленный внутренними регламентами банка) исходящих электронных сообщений они шифруются и подписываются электронной подписью с помощью СКАД Сигнатура и закрытых криптографических ключей ответственных работников.

СКАД Сигнатура

СКАД Сигнатура, это СКЗИ, разработанное компанией ООО «Валидата» по заказу Банка России и предназначенное для защиты информации в платежной системе Банка России. Данного СКЗИ нет в открытом доступе (кроме документации, размещенной на сайте ЦБ РФ), и оно распространяется Банком России только среди участников его платежной системы. К отличительным особенностям данного СКЗИ можно отнести:

Зашифрованные и подписанные электронные сообщения помещаются в специальную папку, на схеме (Рис. 2.) это «Папка 3». УТА непрерывно мониторит эту папку и, если он видит там новые файлы, передает их в ЦБ РФ одним из следующих способов:

Следует отметить, что все электронные сообщения, с которыми работает УТА, зашифрованы и подписаны электронной подписью.

Получив зашифрованное электронное сообщение, УТА перекладывает его в папку с входящими зашифрованными сообщениями. Уполномоченный работник с помощью своих криптоключей и АРМ КБР проверяет электронную подпись и расшифровывает сообщение.

Далее обработка производится в зависимости от типа электронного сообщения. Если это платежное сообщение, то оно через модуль интеграции передается в АБС, где на его основании формируются бухгалтерские проводки, изменяющие остатки на счетах. Важно отметить, что при взаимодействии АБС (модуля интеграции) и АРМ КБР используются файлы стандартного формата в открытом виде.

В процессе функционирования АРМ КБР ведет журнал своей работы, который может быть реализован в виде текстовых файлов или с помощью БД, работающих под управлением СУБД.

Альтернативные схемы обработки

Мы рассмотрели «классическую» схему работы системы. В реальности существует множество ее разновидностей. Рассмотрим некоторые из них.

Разновидность 1. Разделение контуров отправки и приема сообщений
Реализуется схема с двумя АРМ КБР. Первый работает с участием человека и выполняет только отправку сообщений, второй работает в автоматическом режиме и выполняет только прием сообщений.

Разновидность 2. Полный автомат
АРМ КБР настраивается на работу полностью в автоматическом режиме без участия человека

Разновидность 3. Изолированный АРМ КБР
АРМ КБР функционирует как выделенный компьютер, не подключенный к сети банка. Электронные сообщения передаются на него человеком-оператором с помощью ОМНИ.

Перенос электронной подписи из АРМ КБР в АБС

Банк России планирует перейти на новую технологическую схему обработки платежей, при которой электронные сообщения будут подписываться не в АРМ КБР, как было ранее, а в АБС (точнее в модуле интеграции АБС — АРМ КБР).

Для реализации данного подхода выпущена новая версия АРМ КБР, которая стала называться АРМ КБР-Н (новая). Все основные изменения можно увидеть, если сравнить схемы информационных потоков, проходящих через АРМ КБР старой и новой версии.

Рассмотрим схему информационных потоков в классическом АРМ КБР. Источник схемы – официальная документация на АРМ КБР «АВТОМАТИЗИРОВАННОЕ РАБОЧЕЕ МЕСТО КЛИЕНТА БАНКА РОССИИ. Руководство программиста. ЦБРФ.61209-04 33 01».

Рис. 3.
Примечания.

Рис. 4.

С точки зрения криптографии АРМ КБР-Н отвечает за шифрование / расшифрование электронных сообщений, а также за проверку электронных подписей на них. Формирование электронных подписей перенесено в модуль интеграции АБС.

Логично предположить, что данный модуль также должен будет проверять подписи под сообщениями, полученными из АРМ КБР-Н. С технической точки зрения это не является обязательным, но с точки зрения обеспечения безопасности имеет критическое значение, поскольку обеспечивает целостность сообщений, передаваемых между АБС и АРМ КБР-Н.

Помимо файлового интерфейса взаимодействия между АБС, АРМ КБР-Н и УТА добавлен интерфейс IBM WebSphere MQ, что позволяет строить сервис-ориентированную ИТ-инфраструктуру банка и решить проблему старой схемы с организацией одновременной работы нескольких операторов, ответственных за отправку платежей.

Источник

Уис эд уфэбс что это

Об актуальных изменениях в КС узнаете, став участником программы, разработанной совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу выдаются удостоверения установленного образца.

Программа разработана совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.

Обзор документа

Описание форматов сообщений, используемых при передаче органу Федерального казначейства информации, поступившей от кредитной организации (филиала) в электронном виде, из платежных документов физических лиц (Описание форматов «Казначейство»)

1. Термины, определения и сокращения

КО: Кредитная организация (филиал кредитной организации).

ПО: Программное обеспечение

XML (eXtensible Markup Language): Расширяемый (открытый) язык разметки.

Документ XML: файл в формате XML определенной структуры (квитанция, извещение, запрос, подтверждение).

XML-схема (XML schema): Язык описания структуры документа. Предусматривает описание допустимой структуры документа и типов данных в значениях атрибутов и содержимом элементов.

Зашифрованный пакет: совокупность документов XML, сгруппированных в один файл.

В качестве основных типов данных XML-файлов в документе используются следующие:

В описании некоторых атрибутов используется псевдотип «перечисление», для каждого такого атрибута явно описываются конкретные значения, которые он может принимать.

Все шаблоны XML файлов приведены в кодировке windows-1251. Для описания структуры используются следующие сокращения:

А атрибут XML документа

К корневой элемент XML документа

Э элемент XML документа

[0] Элемент/атрибут должны отсутствовать в указанном контексте

[0..1] Элемент/атрибут является необязательным

[1] Элемент/атрибут является обязательным

[0..n] Элемент является необязательным, количество элементов не ограничено

[1..n] Количество указанных элементов не менее одного

элемент (атрибут) может отсутствовать

— Заполнение поля Абонент

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

— Идентификатор внутри категории, в соответствии с локальным справочником, ведущимся в Банке России для идентификации ТУ, КО и других участников расчетов.

Для идентификации ТУ, КО и органа Федерального казначейства и обеспечения маршрутизации используется мнемонический код «УИС» и уникальный идентификатор составителя электронного документа, сформированный в соответствии с требованиями документа Банка России «О правилах обмена электронными документами между Банком России, кредитными организациями (филиалами) и другими клиентами Банка России при осуществлении расчетов через расчетную сеть Банка России» (Положение Банка России от 12.03.1998 № 20-П (В редакции Указания от 11.04.2000 № 774-У)).

3. Общие сведения

3.1. Зашифрованный пакет

3.1.1. Логическая структура зашифрованного пакета

3.1.2. Шаблон зашифрованного пакета

3.1.3. Описание реквизитов зашифрованного пакета

Идентификатор зашифрованного пакета представляет собой составное выражение (не присутствующее в явном виде) и включает в себя следующие реквизиты зашифрованного пакета и извещения из платежных документов:

3.2. Извещение

3.2.1. Логическая структура извещения с информацией из платежных документов физических лиц

— Структура элемента ED101 см. «Унифицированные форматы электронных банковских сообщений для безналичных расчетов. ОБМЕН С КРЕДИТНЫМИ ОРГАНИЗАЦИЯМИ И ДРУГИМИ КЛИЕНТАМИ БАНКА РОССИИ»

3.2.2. Шаблон извещения

3.2.3. Описание реквизитов извещения

3.3. Квитанция

3.3.1. Логическая структура квитанции

3.3.2. Шаблон квитанции

3.3.3. Описание реквизитов квитанции

3.3.4. Описание результатов проверки

3.4. Подтверждение

3.4.1. Логическая структура подтверждения

3.4.2. Шаблон подтверждения

3.4.3. Описание реквизитов подтверждения

3.5. Запрос

3.5.1. Логическая структура запроса

3.5.2. Шаблон запроса

3.5.3. Описание реквизитов запроса

3.5.4. Описание результатов проверки

3.6. Порядок формирования и проверки КА XML-документа

Настоящий раздел описывает порядок необходимых преобразований XML документа для формирования и проверки значения КА.

3.6.1. Правила формирования КА

Процесс формирования конверта ЭЦП (КА) состоит из следующих этапов:

2. Сериализация сформированного XML-документа в массив байтов, для которого будет рассчитываться КА, и канонизация проводятся по стандарту xml-c14n. Значения элементов документа не должно состоять только из пробельных символов (WhiteSpace в терминах XML).

3. Формирование (вычисление значения) КА: вызов функции СКЗИ по формированию КА с передачей ей массива байтов, полученного на предыдущем этапе.

4. Кодирование полученного на предыдущем этапе значения КА по алгоритму base64.

5. Помещение закодированного на предыдущем этапе значения КА в элемент KA, а также определения набора атрибутов в соответсвии с форматом

3.6.2. Правила проверки КА

Процесс проверки КА на XML-документе состоит из следующих этапов:

1. Получение защищенного КА из XML-документа.

2. Выделение значения КА из элемента KA.

3. Раскодирование значения КА, выделенного на предыдущем этапе, по алгоритму base64.

4. Исключение элемента KA из XML-документа.

5. Сериализация сформированного XML-документа в массив байтов, для которого будет рассчитываться КА, канонизация проводятся по стандарту xml-c14n

6. Проверка КА: вызов функции СКЗИ по проверке КА с передачей ей массивов байтов, полученных на этапах 5 и 3

4. Контроль целостности и содержания документов

4.1. Выполняемые проверки

4.1.1. Извещение

При приеме в обработку извещения на уровне КО производится следующий контроль:

— контроль документа по XSD схеме;

— проверка правильности указания кредитной организацией в извещении номера банковского счета (элемент KAZNIZV/PPOS/ED101/Payee/PersonalAcc) органа Федерального казначейства из допустимого перечня согласно пункту 2.1 Указания № 2467-У и пунктом 1.3 приложения 1 к данному Указанию;

— контроль общего количества платежных документов физических лиц (элемент KAZNIZV/PPOS/Count) количеству записей в повторяющейся последовательности (элементы KAZNIZV/PPOS/DETAIL/FIZDOC);

— контроль суммы платежного поручения (элемент KAZNIZV/PPOS/ED101/Sum) сумме значений в повторяющейся последовательности (элементы KAZNIZV/PPOS/DETAIL/FIZDOC/Sum);

— контроль сочетаний значений (при заполнении элементов KAZNIZV/PPOS/DETAIL/FIZDOC/DocIndex и/или KAZNIZV/PPOS/DETAIL/FIZDOC/Id не заполняются элементы KAZNIZV/PPOS/DETAIL/FIZDOC/Name, KAZNIZV/PPOS/DETAIL/FIZDOC/ Adress);

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

При положительном результате контроля извещение будет дополнено уникальным идентификатором (элемент KAZNIZV/UID, если он не будет сформирован средствами информационной системы КО), на извещение будет установлен КА КО (элемент KAZNIZV/КА, если он не будет сформирован средствами информационной системы КО).

При отсутствии ошибок обработки будет сформирован зашифрованный пакет, на который будет установлен КА.

4.1.2. Зашифрованный пакет

При приеме на уровне ТУ зашифрованного пакета, производится следующий контроль:

контроль зашифрованного пакета по XSD схеме;

контроль КА зашифрованного пакета;

проверка правильности указания кредитной организацией идентификатора зашифрованного пакета, предусмотренная пунктом 2.2 Указания № 2467-У (в том числе, отсутствует проверка идентификатора кредитной организации на возможность передачи извещений, а также идентификатора органа Федерального казначейства на возможность получения извещений);

При отрицательном результате любого контроля в адрес КО формируется квитанция с указанием кода ошибки (элемент Квитанция/КодРезКонтроля=”2”) и причины отказа в приеме (элемент Квитанция/Пояснение);

При положительном результате контроля в адрес КО формируется квитанция с указанием кода положительного решения о приеме (элемент Квитанция/КодРезКонтроля=”0”), зашифрованный пакет направляется в адрес органа Федерального Казначейства.

При приеме на уровне органа Федерального Казначейства зашифрованного пакета, производится следующий контроль:

контроль уникальности идентификатора зашифрованного пакета;

контроль зашифрованного пакета по XSD схеме;

контроль КА зашифрованного пакета;

контроль расшифрования зашифрованного пакета;

По результатам контроля формируется квитанция с указанием результата контроля. При отрицательном результате контроля квитанция формируется с указанием кода ошибки (элемент Квитанция/КодРезКонтроля=”2”) и причины отказа в приеме (элемент Квитанция/Пояснение), при положительном результате контроля формируется квитанция с указанием кода положительного решения о приеме (элемент Квитанция/КодРезКонтроля=”0”).

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

При положительном результате контроля производится прием в дальнейшую обработку расшифрованного извещения и выполняется следующий контроль:

контроль извещения по XSD схеме;

контроль КА извещения;

контроль уникальности в течении дня идентификатора извещения;

проверка правильности указания кредитной организацией в извещении номера банковского счета (элемент KAZNIZV/PPOS/ED101/Payee/PersonalAcc) органа Федерального казначейства из допустимого перечня согласно пункту 2.1 Указания № 2467-У и пунктом 1.3 приложения 1 к данному Указанию;

контроль общего количества платежных документов физических лиц (элемент KAZNIZV/PPOS/Count) количеству записей в повторяющейся последовательности (элементы KAZNIZV/PPOS/DETAIL/FIZDOC);

контроль суммы платежного поручения (элемент KAZNIZV/PPOS/ED101/Sum) сумме значений в повторяющейся последовательности (элементы KAZNIZV/PPOS/DETAIL/FIZDOC/Sum);

При положительном результате контроля формируется подтверждение, извещение размещается в выходном каталоге.

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

На подтверждения и запросы устанавливается КА органа Федерального казначейства.

4.1.3. Запрос (подтверждение)

При приеме на уровне ТУ запроса (подтверждения), производится следующий контроль:

контроль запроса (подтверждения) по XSD схеме;

контроль КА запроса (подтверждения);

контроль реквизитов запроса (подтверждения) на предмет соответствия их значения требованиям Приложения 1 Указания № 2467-У.

По результатам контроля в адрес органа Федерального казначейства формируется квитанция с указанием результата контроля.

В случае положительного результата контроля запрос (подтверждение) направляется в адрес кредитной организации.

При приеме на уровне КО запроса (подтверждения), производится следующий контроль:

контроль запроса (подтверждения) по XSD схеме;

контроль КА запроса (подтверждения);

контроль реквизитов запроса (подтверждения) на предмет соответствия их значения требованиям Приложения 1 Указания № 2467-У.

По результатам контроля в адрес территориального учреждения формируется квитанция с указанием результата контроля.

В случае положительного результата контроля запрос (подтверждение) принимается в обработку.

4.2. Контроль документов по XSD схеме

XSD схемы входят в состав программного обеспечения.

Согласно правилам контроля по XSD схеме последовательность атрибутов для элемента может быть произвольной, дублирование атрибута в одном элементе не допустимо, последовательность дочерних элементов имеет значение, дублирование элементов допустимо. XML документ должен иметь только один корневой узел.

4.2.1. Базовые типы данных

— DataBase64 Блок данных в кодировке Base64

— Дата Дата в формате YYYY-MM-DD

— ДатаВремя Дата и время. [ГОСТ ИСО 8601-2001]. Формат CCYY-MM-DDThh:mm:ss.

— Строка Строка без ограничения длины

— Email Адрес электронной почты

— Абонент Идентификатор составителя (получателя) электронного сообщения.

— ИмяФайла Имя файла

— СКЗИ Наименование используемой СКЗИ. Допустимые значения: Сигнатура, Верба, САЭД

4.2.2. Извещение

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

— UID уникальный идентификатор извещения с типом данным [GUID]

— Nom номер извещения с информацией из платежных документов физических лиц, уникальный для рабочего дня, в течение которого составлено данное сообщение, тип данных [Строка]

— MakeDate дата составления извещения с информацией из платежных документов физических лиц, тип данных [Дата]

— Exec ФИО исполнителя разделенные пробелом, тип данных [Строка]

— Email Адрес электронной почты исполнителя, тип данных [Строка]

— Phone Телефон исполнителя, тип данных [Строка]

Содержимым корневого элемента является последовательность из элементов PPOS (только один элемент) и KA (элемент не является обязательным).

Элемент PPOS должен содержать следующие атрибуты:

— AccDocNo порядковый номер электронного сообщения, содержащего платежное поручение на общую сумму платежных документов физических лиц, направленного кредитной организацией в Банк России для исполнения, тип данных [xsd:positiveInteger]

— AccDocDate дата электронного сообщения, содержащего платежное поручение на общую сумму платежных документов физических лиц, направленного кредитной организацией в Банк России для исполнения, тип данных [Дата]

— Count общее количество платежных документов физических лиц, реквизиты которых включены в повторяющуюся последовательность, тип данных [xsd:positiveInteger]

Содержимым элемента PPOS является последовательность элементов ED101 (один элемент) и DETAIL (один элемент).

Атрибуты и содержимое элемента ED101 определяется схемой из «Унифицированные форматы электронных банковских сообщений для безналичных расчетов. ОБМЕН С КРЕДИТНЫМИ ОРГАНИЗАЦИЯМИ И ДРУГИМИ КЛИЕНТАМИ БАНКА РОССИИ»

Элемент DETAIL не должен содержать атрибутов. Содержимым элемента является последовательность элементов FIZDOC (как минимум один элемент). Помимо типа данных, в квадратных скобках указывается максимальная длина реквизита в символах.

Элемент FIZDOC не должен иметь содержимого и должен содержать следующие обязательные атрибуты:

— AccDocDate Дата платежа физического лица, тип данных [Дата]

— Sum Сумма платежа физического лица, тип данных [xsd:decimal, 18]

Элемент FIZDOC может содержать следующие необязательные атрибуты:

— Name Фамилия, имя и отчество (при наличии), тип данных [Строка, 70]

— DocNo Номер документа, тип данных [Строка, 15]

— DocDate Дата документа, тип данных [Дата]

— DocIndex Индекс документа, тип данных [Строка, 20]

— UniNo Уникальный присваиваемый номер операции, тип данных [Строка, 20]

— Id Идентификатор физического лица, тип данных [Строка, 25]

— Adress Адрес, тип данных [Строка, 70]

— Purpose Назначение платежа физического лица, тип данных [Строка, 140]

— INN ИНН плательщика, тип данных [Строка, 12]

— DrawerStatus Статус, тип данных [Строка, 2]

— PaytReason Основание платежа, тип данных [Строка, 2]

— TaxPaytKind Тип платежа, тип данных [Строка, 2]

— TaxPeriod Налоговый период, тип данных [Строка, 10]

— KaznPersonalAcc Номер лицевого счета, открытого бюджетополучателю в органе Федерального казначейства, тип данных [Строка, 11]

— PersonalAcc Номер лицевого счета, открытого бюджетополучателю в финансовом органе, тип данных [Строка, 16]

Элемент KA имеет обязательный атрибут KAType (Наименование системы криптографической авторизации электронных документов) с типом данных [СКЗИ]. Элемент содержит текст в формате base64

4.2.3. Подтверждение

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

— UID Уникальный идентификатор подтверждения, тип данных [GUID]

— DateTime Дата/время формирования подтверждения, тип данных [ДатаВремя]

— ResultMessage Результат приема в вербальной форме, тип данных [Строка]

— ОтправительЭС Определяет организацию, которая составила и подписала подтверждение [Строка]

— ПолучательЭС Определяет организацию, которой направлено данное подтверждение [Строка]

Содержимым корневого элемента является последовательность из элементов KAZNIZV (один обязательный элемент) и KA (один не обязательный элемент)

Элемент KAZNIZV должен содержать следующие обязательные атрибуты:

— UID Уникальный идентификатор извещения, тип данных [GUID]

— Nom номер извещения с информацией из платежных документов физических лиц, уникальный для рабочего дня, в течение которого составлено данное сообщение, тип данных [Строка]

— MakeDate дата составления извещения с информацией из платежных документов физических лиц, тип данных [Дата]

Содержимое элемента KAZNIZV отсутствует.

Структура элемента KA идентична структуре в извещении.

4.2.4. Запрос

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

— UID Уникальный идентификатор запроса, тип данных [GUID]

— DateTime Дата/время формирования запроса, тип данных [ДатаВремя]

— ОтправительЭС Определяет организацию, которая составила и подписала подтверждение [Строка]

— ПолучательЭС Определяет организацию, которой направлено данное подтверждение [Строка]

Содержимым корневого элемента является последовательность из элементов KAZNIZV (один элемент), SUBJECT (один элемент), DETAIL (ноль или несколько) KA (элемент не является обязательным).

Элемент KAZNIZV должен содержать следующие обязательные атрибуты:

— UID Уникальный идентификатор извещения, тип данных [GUID]

— Nom номер извещения с информацией из платежных документов физических лиц, уникальный для рабочего дня, в течение которого составлено данное сообщение, тип данных [Строка]

— MakeDate дата составления извещения с информацией из платежных документов физических лиц, тип данных [Дата]

Содержимое элемента KAZNIZV отсутствует.

Элемент SUBJECT не должен содержать атрибутов, содержимым элемента имеет тип данных [Строка]

Элемент DETAIL содержит следующие обязательные атрибуты:

— Code код результата проверки, принимает одно из значений: 02, 12, 13, 14, 15

— Text описание результата проверки [Строка]

Структура элемента KA идентична структуре в извещении.

Источник