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

 

Что же нового появилось в модуле «Бэк-офис операций с ценными бумагами»? Во-первых, был выполнен переход от системного механизма платежей к использованию нового объекта – «Требование/обязательство». Во-вторых, упростились правила работы с платежными реквизитами. В-третьих, изменилась технология обработки комиссий.
И наконец, был существенно доработан интерфейс ввода и редактирования сделок и операций. Обо всех этих новшествах и пойдет речь.

 

В своей новой версии «Бэк-офис операций с ценными бумагами» подвергся глубокой переработке, однако для пользователя, знакомого с предыдущей реализацией, прежде всего будут заметны не изменения «под капотом», а обновленный интерфейс.

 

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

 

•          Платежные реквизиты.

 

•          Требования/обязательства.

 

•          Комиссии.

 

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

 

 

 

 

Платежные реквизиты по любой сделке или операции в предыдущей версии системы хранятся в объекте «Платеж». По одной сделке может быть несколько денежных платежей и несколько платежей по ценным бумагам. В каждом из них хранится свой набор реквизитов плательщика и получателя. Например, в сделке РЕПО три денежных платежа (по первой части, по второй части и по процентам) и два платежа по ценным бумагам (по каждой части сделки – свой платеж). В случае необходимости может появиться и дополнительный платеж – компенсационный или по выплате купона. В платежах указаны стороны по сделке (покупатель и продавец ценных бумаг), их платежные реквизиты по деньгам и по ценным бумагам. В рамках одной сделки эти реквизиты, скорее всего, будут одинаковыми.

 

В новой версии модуля «Бэк-офис операций с ценными бумагами» предусмотрен справочник платежных реквизитов по сделке, в котором можно сразу увидеть все используемые в конкретной сделке счета для расчетов по денежным средствам или по ценным бумагам. Здесь отражается информация о счетах всех участников сделки: покупателя и продавца (клиента и контрагента), регистратора и посредника (если эти субъекты в сделке указаны). Оперативно просмотреть (и, если понадобится, изменить) этот справочник можно на новой вкладке – «Платежные реквизиты» (рис. 2), где хранятся сведения о расчетах по конкретной сделке.

 

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

 

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

 

В справочнике платежных реквизитов (см. рис. 2) есть ссылка на новый объект системы – «Требование/обязательство».

 

 

«Требование/обязательство» – объект довольно простой, название которого объясняет его назначение: отражать требования и обязательства по сделке или операции.

 

Все требования и обязательства делятся на две большие группы: требования/обязательства по денежным средствам (в которых указана валюта) (рис. 3) и требования/обязательства по ценным бумагам (где указывается выпуск ценных бумаг) (рис. 4).

 

Направление предстоящих расчетов определяет форму требования/обязательства – собственно требование (когда мы ждем денежные средства или поставку ценных бумаг от контрагента) или обязательство (если мы должны перевести денежные средства или поставить бумаги контрагенту).

 

Различают следующие виды требований и обязательств: аванс, оплата, поставка, комиссия, проценты в РЕПО и т. п.

 

Для отслеживания порядка исполнения сделки в новом объекте «Требование/обязательство» предусмотрены статусы обработки («Запланировано», «Исполнено», «Просрочено») и плановая/фактическая дата исполнения. Также здесь указаны контрагент, номер части сделки РЕПО (или займа), объем требования или обязательства (сумма в валюте или количество ценных бумаг), место учета денежных средств или ценных бумаг (для внутреннего учета), ссылка на справочник платежных реквизитов по сделке.

 

По необходимости пользователь может указать один и тот же счет контрагента и в требовании/обязательстве по авансу, и в требовании/обязательстве по оплате. Также возможно в каждом требовании/обязательстве использовать уникальные реквизиты (например, чтобы отразить поставку ценных бумаг частями из разных депозитариев).

 

Для требования/обязательства, как и для многих других объектов системы, можно добавить любой набор дополнительных атрибутов, используя дистрибутивные механизмы примечаний и категорий RS-Bank.

 

Чтобы пользователь имел возможность отслеживать требования и обязательства по конкретной сделке (или операции), в экранные формы добавлена отдельная закладка (рис. 5). Дополнительно реализован общий список всех требований и обязательств (рис. 6). В этом списке предусмотрен настраиваемый фильтр (рис. 7), который можно использовать, например, для оценки плановой позиции по указанному финансовому инструменту и контрагенту на заданную дату.

 

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

 

Зачем же понадобился новый объект, если в прежней версии системы есть платеж со схожими функциями? Пока речь идет исключительно об обработке внебиржевых сделок, и нет возможности выполнять неттинг по этим сделкам, фактические расчеты производятся по каждой сделке индивидуально. То есть любое требование или обязательство вырастает до расчетного документа – платежа.

 

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

 

Объект «Платеж» довольно сложно устроен. Он пытается подобрать схему расчетов (то есть нужный корреспондентский счет), конвертировать суммы из одной валюты в другую, если валюта цены и валюта расчетов не совпадают. Даже если обрабатываются тысячи биржевых сделок, не нужно по каждой из них определять корсчет: он всегда один и тот же. Для использования в качестве хранилища данных при проведении расчетов и формирования поручений в «Депозитарий» нужен был объект «полегче». С этой точки зрения новый объект «Требование/обязательство» можно представить себе как «облегченный платеж». Точнее, как его половинку со стороны контрагента (в части хранения платежных реквизитов). Этот объект не перегружен лишними данными и алгоритмами, поэтому и обрабатывается он значительно быстрее1.

 

 

 

С появлением объекта «Требование/обязательство» платеж в «Бэк-офисе операций с ценными бумагами» используется в качестве расчетно-денежного документа, который формируется только при необходимости отражать реальные расчеты по сделкам. Платежи генерируются специальной процедурой по исполненным требованиям и обязательствам (по результатам обработки биржевых торгов, по результатам работы операции неттинга, по исполненным внебиржевым сделкам и оплаченным внешним комиссиям) и отправляются в АБС. Данная процедура спроектирована таким образом, что позволяет работать не только с учетным ядром RS-Bank, но и с любой другой АБС. При использовании учетного ядра АБС RS-Bank V.6 сформированные в «Бэк-офисе операций с ценными бумагами» платежи обрабатываются стандартным образом в модулях «АРМ-Позиционера» и «Межбанковские расчеты». В случае применения сторонней АБС обработка платежа полностью ложится на нее.

 

Поскольку расчеты должны выполняться не только по деньгам, а еще и по ценным бумагам, аналогичным образом была переработана процедура генерации поручений депо. Поручения формируются по исполненным требованиям и обязательствам по ценным бумагам (по исполненным внебиржевым сделкам, по результатам неттинга по ценным бумагам, по результатам обработки биржевых торгов). Разумеется, банк может использовать депозитарный модуль любого производителя. Но по умолчанию (без дополнительных настроек и доработок) осуществляется передача поручений в модуль «Депозитарий» программного комплекса RS-Securities V.6 (рис. 8).

 

 

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

 

Все сведения о комиссиях по конкретной сделке теперь можно увидеть на отдельной вкладке (рис. 9). Здесь отражаются сумма комиссии, сумма НДС, текущий статус комиссии (рассчитана, начислена, оплачена), ее получатель, а также сведения о договоре обслуживания. Пользователь может не только просмотреть эти данные, но и при необходимости внести свои корректировки или даже добавить новую комиссию (рис. 10).

 

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

 

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

 

•          Взимаемые с клиента комиссии в пользу банка (периодические комиссии) обрабатываются отдельной сервисной операцией – «Обработка периодических комиссий».

 

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

 

В новой версии системы обработка биржевых комиссий, импортированных из клиринговых отчетов биржи, полностью выполняется в операции «Расчеты на ОРЦБ». Проводки по учету комиссий формируются в зависимости от настроек модуля – либо сводные, либо в разрезе сделок.

 

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

 

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

 

При этом способ обработки редко используемых (разовых) комиссий не изменился.

 

 

 

Повышение производительности системы – важная задача. Но при переходе на новый объект «Требование/обязательство» разработчики преследовали и другие цели. Ждет своей очереди реализация возможности учитывать сделки, в которых оплата выполняется частями в разные даты (на сегодняшний день система позволяет обрабатывать сделки с оплатой в двух частях – аванс или задаток и основная часть). Также появится функционал для учета сделок, в которых поставка производится частями из разных депозитариев (поставка разными фактическими выпусками успешно обрабатывается и в текущей версии системы).

 

В настоящий момент разработчики трудятся над тем, чтобы любой вид учета операций с ценными бумагами – бухгалтерский, внутренний и налоговый – можно было вести отдельно от других. Пока совсем обособленным можно считать только налоговый учет: при необходимости его можно включить или выключить, да и налоги система умеет считать по данным не только нашего модуля «Бэк-офис операций с ценными бумагами», но и систем сторонних производителей. Когда же соответствующие доработки будут выполнены, все три вида учета будут существовать независимо друг от друга, используя в качестве источников информации требования/обязательства и сделки. А данные для депозитарного учета будут формироваться отдельной процедурой, не привязанной к бухгалтерскому учету.

 

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

 

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

 

Объект «Требование/обязательство» с его статусами и датами фактического исполнения представляет собой как раз источник информации бэк-офисного учета, на основе которого может быть проведено отражение операций в остальных видах учета.

 

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

 

Стоит заметить, что разделение видов учета в «Бэк-офисе операций с ценными бумагами» позволит сотрудникам бэк-офиса, бухгалтерии и депозитария работать практически независимо. Остановившаяся по какой-то причине обработка данных депозитарного учета совершенно не помешает сформировать данные бухгалтерского учета или выпустить отчетность ФСФР по данным внутреннего учета. И это справедливо для всех видов учета, кроме, естественно, бэк-офисного, на основе которого они строятся.