183
Карл Сумманен. Принципы и архитектура универсальной системы розничных трансфертов
1. Введение
Национальная платежная система (НПС) России включает платежные системы (ПС) нескольких различных классов, занимающие непересекающиеся области на пространстве трансфертных [1] сервисов: межбанковские переводы; платежные карты; моментальные переводы без открытия счета; электронные деньги; цифровые наличные; сервисы оплаты со счетов операторов сотовой связи и других небанковских операторов счета.
Все перечисленные классы ПС специализированы и работают по принципу «один режим - одна платежная система», например, системы платежных карт основаны на режиме дебетового трансферта, моментальных переводов - кредитового и т. п.
В некоторых случаях специализированные ПС могут реализовывать отдельные дополнительные режимы, отличные от основного, но такие реализации как правило ограничены и не отличаются качеством сервисов. Например, вряд ли получится оплатить покупку в магазине через ПС Банка России посредством платежного требования или перевести в реальном времени деньги с карты одного банка на карту другого.
Специализированные ПС, составляющие НПС, как правило операционно несовместимы, так как в отсутствие единых стандартов на процессы обработки трансфертов ПС развиваются независимо и требование совместимости на этапе проектирования не ставится. Как следствие, специализированные ПС образуют слабосвязанную НПС, не удовлетворяющую требованиям Интегрированного трансфертного пространства.
Например, если нет специально созданного шлюза, нельзя в реальном времени переводом со счета в одном банке пополнить карту в другом банке, сделать со счета в банке моментальный перевод со снятием получателем наличных, пополнить счет в банке через систему моментальных переводов, перевести деньги между счетами у различных операторов счета и т. д.
Рынок частично компенсирует слабую связанность НПС за счет попарной интеграции отдельных ПС. Это позволяет решать частные задачи, но не снимает проблему отсутствия ИТП, так как для этого потребовалось бы интегрировать каждую ПС с каждой, что по понятным причинам практически невозможно.
Для системного решения проблемы слабой связанности НПС необходимы национальные стандарты на процессы обработки трансфертов и протоколы межсистемных взаимодействий, требования которых заставили бы предусматривать механизмы операционной совместимости уже на этапе проектирования, что позволило бы операционно связывать ПС путем заключения соглашений без выполнения каких-либо специальных работ по интеграции.
В числе недостатков НПС, связанных с узкой специализацией ПС, следует отметить такие, как:
· функциональная неполнота, выражающаяся в существование потребностей широкого круга пользователей, для удовлетворения которых НПС не предлагает оптимальных сервисов;
· неудобство для пользователей, связанное с тем, что для получения набора сервисов, эквивалентного одной универсальной ПС, пользователь должен использовать несколько специализированных ПС;
· операционная неэффективность, связанная с тем, что стоимость владения одной универсальной ПС в среднем ниже чем несколькими специализированными, в совокупности обеспечивающими такую же функциональность;
Можно ли изменить сложившуюся ситуацию? По мнению автора она закономерна, но не неизбежна. Представляется, что преобладание специализированных ПС и слабая связанность НПС объясняются не столько экономической и технологической целесообразностью, сколько особенностями процесса формирования НПС в условиях свободного рынка под доминирующим влиянием частных интересов в отсутствие целеполагания и направляющих воздействий со стороны государства и приоритета общенациональных интересов.
Учитывая, что логика обработки транзакций, клиринга, расчетов примерно одинакова для всех режимов, создание универсальной системы трансфертов, объединяющей функциональность всех существующих специализированных ПС, и обеспечивающей все необходимые для функциональной полноты возможности, представляется вполне реальным. Ниже рассматривается возможный вариант архитектуры такой системы.
2. Требования к системе розничных трансфертов
Основная идея в основе предлагаемой универсальной системы розничных трансфертов (СРТ) - объединить в рамках одной ПС функциональность множества ПС различных классов в соответствии с принципом «одна платежная система - много режимов». Для этого СРТ должна обеспечить на базе одной технологической платформы и единой системы стандартов возможность выполнения трансфертов во всех необходимых контекстах [2] и для всех необходимых пользователям условий (параметров) трансферта, включая режимы его выполнения. Кроме того, СРТ должна создать основу для построения Интегрированного трансфертного пространства. Декомпозиция перечисленных общих требований в более детальные представлена ниже:
2.1. Нейтральность к контексту трансферта
СРТ должна быть максимально нейтральна [3] по отношению к контексту трансферта и тем самым к отдельным факторам, составляющих контекст, в том числе:
2.1.1. Нейтральность к категории пользователя
Функциональность СРТ не должна зависеть от категории пользователя и равно обеспечивать потребности всех существующих категорий, предусмотренных действующим законодательством, в том числе физических лиц, юридических лиц всех организационных форм и форм собственности, индивидуальных предпринимателей.
2.1.2. Нейтральность к резидентности и стране пользователя
Функциональность СРТ не должна зависеть от резидентности и страны происхождения пользователя и равно обеспечивать потребности резидентов РФ и любых других стран.
2.1.3. Нейтральность к типу оператора счета
Функциональность СРТ не должна зависеть от типа оператора счета [4] пользователя трансферта и равно обеспечивать потребности пользователей, счета которых обслуживаются операторами счетов любых типов.
2.1.4. Нейтральность к валюте трансферта
СРТ должна обеспечивать техническую возможность выполнения трансфертов номинированных в любых валютах.
2.1.5. Нейтральность к форме денег при фондировании и выплате
СРТ должна обеспечивать техническую возможность выполнения трансфертов для любых форм денег, используемых при фондировании и выплате трансферта, в том числе безналичных, материальных и цифровых наличных.
2.1.6. Нейтральность к типу родительской сделки
В случаях, когда трансферт является дочерним подпроцессом другой "родительской сделки" [5] , функциональность СРТ не должна зависеть от типа такой сделки.
2.2. Многообразие временных режимов выполнения
СРТ должна обеспечивать поддержку всех необходимых пользователям временных режимов выполнения трансфертов. Условная классификация временных режимов, потребность в которых возникает на практике и поддержка которых должна быть обеспечена, приводится ниже:
- синхронный режим (реальное время):
- онлайн-трансферт. Трансферт выполняется в синхронном режиме как одна транзакция, в которой непрерывно участвуют и человек и информационные системы. С точки зрения человека трансферт выполняется немедленно, характерное время в диапазоне от долей секунды до десятков секунд. Примеры: оплата товара в торгово-сервисном предприятии или в интернете платежной картой, оплата парковки, снятие наличных в банкомате;
- моментальный трансферт. Трансферт выполняется в синхронном режиме с точки зрения человека, но асинхронном с точки зрения информационных систем Трансферт выполняется достаточно быстро, чтобы непрерывное ожидание завершения было приемлемым для человека. Характерное время в диапазоне от десятков секунд до одной минуты. Пример - пополнение платежной карты держателем, стоящим в очереди, для оплаты покупки или снятия наличных;
- экспресс-трансферт. С точки зрения человека трансферт выполняется с небольшой задержкой в асинхронном режиме - человек выходит из транзакции и переключается на другое занятие не ожидая непрерывно результата, предполагая, что трансферт будет завершен в ближайшее время. Характерное время несколько десятков минут. Пример - пополнение платежной карты перед поездкой к банкомату или в магазин;
- срочный трансферт. С точки зрения человека трансферт выполняется с задержкой в асинхронном режиме - человек выходит из транзакции и переключается на другое занятие не ожидая непрерывно результата, предполагая, что трансферт будет завершен в течение текущего дня. Характерное время несколько часов.
- обычный трансферт. С точки зрения человека трансферт выполняется со значительной задержкой в асинхронном режиме - человек выходит из транзакции и переключается на другое занятие не ожидая, непрерывно результата и не предполагая, что трансферт будет завершен в течение текущего дня. Характерное время несколько дней;
2.3. Многообразие режимов инициации трансферта
СРТ должна обеспечивать поддержку всех необходимых пользователям режимов инициации трансферта, в том числе:
· возможность инициации различными участниками, в том числе Спонсором, Бенефициаром или третьей стороной;
· возможность инициации в различное время, в том числе инициации при совершении трансферта или предварительная инициация с последующим автоматическим исполнением;
2.4. Многообразие режимов акцепта
СРТ должна обеспечивать поддержку всех необходимых пользователям режимов акцепта трансферта, в том числе возможность:
- безакцептного выполнения;
· акцепта различными участниками, в том числе Спонсором, Бенефициаром, Бенефициаром и Спонсором, третьей стороной;
· акцепта в различное время, в том числе при совершении трансферта или предварительно;
· запроса одним участником акцепта другого участника;
· итерационного согласования участниками условий трансферта;
2.5. Многообразие режимов расчетов
В необходимых случаях СРТ должна обеспечивать возможность как синхронных, так и асинхронных расчетов [6] .
2.6. Многообразие режимов фондирования трансферта
СРТ должна обеспечивать поддержку всех необходимых пользователям режимов фондирования трансферта, в том числе возможность фондирования:
· в любой валюте независимо от валюты трансферта. Должна быть возможность фондировать трансферт в валюте отличной от основной валюты трансферта (например, перевод без открытия счета номинирован в рублях, но пункте приема перевода Спонсор передает доллары США);
· в деньгах любой формы. Должна быть возможность фондировать трансферт посредством денег различной формы, в частности такими, как безналичные деньги на счетах, обслуживаемых различными типами операторов счета, наличные цифровые и наличные материальные деньги);
· деньгами различного происхождения. Должна быть возможность фондировать трансферт деньгами Спонсора, заемными средствами и т.п.;
· деньгами из одного или нескольких источников различных типов, например групп счетов;
· в различное время. Должна быть возможность фондировать трансферт в любое время, в том числе до инициации, в ходе процессинга, до подтверждения трансферта Бенефициару, после подтверждения трансферта Бенефициару, до выплаты трансферта, после выплаты трансферта.
2.7. Многообразие режимов выплаты трансферта
СРТ должна обеспечивать поддержку всех необходимых пользователям режимов выплаты трансферта, в том числе возможность выплаты:
· в любой валюте независимо от валюты трансферта. Должна быть возможность выплачивать трансферт в валюте отличной от основной валюты трансферта (например, перевод без открытия счета номинирован в рублях, в пункте выплаты Бенефициар получает доллары США);
· в деньгах любой формы. Должна быть возможность выплачивать трансферт посредством денег различной формы, в частности безналично на счета, обслуживаемые различными типами операторов счета, наличными цифровыми и наличными материальными деньгами);
· различными способами. Должна быть возможность выплачивать трансферт передачей выплачиваемой суммы в собственность Бенефициара или третьего лица, например для погашения кредита и т.п.;
2.8. Приостановка и продолжение обработки трансферта
В некоторых режимах обработка трансферта приостанавливается до получения запроса на продолжение со стороны одного из участников [7] .
В случае завершения трансферта по инициативе Бенефициара последний помимо времени завершения также определяет другие существенные параметры процесса завершения, в том числе валюту и форму денег, в которых производится выплата, место выплаты, оператора счета и реквизиты счета.
В некоторых контекстах может быть востребован режим обработки трансферта, когда Спонсор после инициации трансферта Бенефициаром или третей стороной определяет условия продолжения обработки, в частности, время, место и режим фондирования.
СРТ должна поддерживать все необходимые пользователям режимы продолжения, в том числе по запросу Бенефициара, Спонсора или Бенефициара и Спонсора.
2.9. Передача сопроводительной информации
При выполнении трансферта может возникать необходимость передачи сопроводительной информации, наличие которой не влияет на выполнение трансферта, обработка которой производится только участниками трансферта. Например, если трансферт выполняется в целях выплаты зарплаты сотрудникам организации дополнительно к переводу общей суммы выплат Бенефициару должна быть передана сопроводительная информация о распределении этой суммы между конечными получателями, их счета и детали расчета зарплаты.
Структура, состав и объем сопроводительной информации заранее не определены и не регулируются правилами и стандартами СРТ.
Учитывая, что между участниками родительской операции часто отсутствуют какие-либо ранее установленные отношения, в частности, нет общего канала для защищенного информационного обмена, представляется разумным использовать для передачи сопроводительной информации сообщения, передаваемые в процессе выполнения трансферта.
Поскольку сопроводительная информация может изменяться в широких пределах в зависимости от потребностей участников и особенностей родительской операции, система передачи сопроводительной информации должна быть максимально гибкой и обеспечивать выполнение практически любых требований в части объема, состава и структуры передаваемых данных.
2.10. Унифицированный идентификатор счета
Трансферты могут производится с использованием для фондирования или выплаты счетов различного вида, в том числе групп счетов, ведущихся операторами различных типов.
СРТ должна поддерживать возможность использования унифицированной схемы идентификации счетов по единому унифицированному идентификатору учетной записи счета, в частности обеспечивать маршрутизацию сообщений на основании информации об операторах счета, представленной в указанном идентификаторе.
2.11. Внешнее управление трансфертом
В некоторых случаях, когда трансферт является частью другого (родительского) процесса, для которого необходимо обеспечить транзакционность, может возникать необходимость координированного исполнения трансферта и родительского процесса.
СРТ должна обеспечивать возможность встраивания процесса обработки трансферта в родительский процесс, в том числе возможность управления трансфертом со стороны родительского процесса, в частности, должна быть возможность запрашивать подтверждение возможности завершения трансферта.
2.12. Непрерывная доступность
СРТ должна обеспечить непрерывную техническую доступность, в частности независимость от режима работы участников платежей и переводов, дней и часов работы, календарей праздничных дней, часовых зон, регламента операционного дня, технологических особенностей банковских и иных автоматизированных систем, порядка ведения счетов и обработки входящих и исходящих расчетных документов.
2.13. Интегрируемость
СРТ должна обеспечить функциональность, сервисы и инструментарий, необходимые для создания на основе СРТ интегрированного платежного пространства в национальном или международном масштабе, в том числе, обеспечить:
· операционную совместимость СРТ и возможность прямой (без создания шлюзов) попарной операционной интеграции СРТ с использованием существующих в СРТ функций и сервисов (без дополнительных работ по развитию функциональности СРТ);
· возможность прямой (без создания шлюзов) операционной интеграции с СРТ частных платежных систем [8] , поддерживающих стандарты межсистемного взаимодействия СРТ (без дополнительных работ по развитию функциональности СРТ или ЧПС);
3. Архитектура и основные компоненты СРТ
Логическая архитектура [9] универсальной системы розничных трансфертов (СРТ), удовлетворяющей вышеописанным требованиям, показана ниже (см. Рисунок 1 [10] ).
Рисунок 1. Логическая архитектура системы розничных трансфертов |
Центральным технологическим компонентом СРТ является Центр обработки трансфертов (ЦОТ) - программно-аппаратный комплекс, обеспечивающий исполнение процессов обработки трансферта.
Компоненты ЦОТ:
Подсистема процессинга ЦОТ выполняет функции координатора транзакции и обеспечивает управление процессом обработки трансферта (в классическом понимании Business process management), установленного технологическими стандартами СРТ, включая поддержку обмена сообщениями между участниками СРТ.
Подсистема управления рисками ЦОТ отвечает за контроль рисков, связанных с трансфертами, в том числе рисков невыполнения обязательств при обработке трансфертов в режиме асинхронных расчетов. При определенных условиях, например при превышении для какого-либо участника трансферта лимита накопленных обязательств, эта подсистема может запрещать выполнение трансфертов.
Подсистема клиринга ЦОТ производит расчет, включая неттинг, накопленных взаимных обязательств между участниками трансферта по совокупности трансфертов, выполненных в режиме асинхронных расчетов в течение периода времени, для которого производится клиринг.
Подсистема управления расчетами ЦОТ обеспечивает другим компонентам ЦОТ интерфейсы для доступа к счетам участников трансферта в расчетных банках для переводов денег и/или получения информации об остатках на счетах. Интерфейсы подсистемы управления расчетами могут использоваться как в режиме асинхронных, так и синхронных расчетов.
Участники обработки трансферта:
Инициатор трансферта запрашивает трансферт у обслуживающего его Провайдера трансферт-услуг, на основании чего последний направляет стандартный запрос на инициацию трансферта ЦОТ СРТ.
В случае кредитового трансферта Инициатор совпадает со Спонсором, в случае дебетового - с Бенефициаром. В случаях, когда расчеты между Спонсором и Бенефициаром управляются третьей стороной, Инициатором трансферта может являться такая третья сторона.
Спонсором обеспечивает фондирование трансферта [11] .
Выплата трансферта [12] производится в пользу Бенефициара.
Координатором внешней транзакции осуществляет внешнее управление процессом обработки трансферта в случаях, когда трансферт является "дочерним" подпроцессом внешней "родительской" транзакции [13] .
Провайдеры трансферт-услуг (ПТУ) предоставляют своим клиентам коммерческие бизнес-услуги по переводу денег, созданные на основе сервисов СРТ. В качестве ПТУ могут выступать любые юридические лица, в соответствии с законодательством имеющие право оказывать услуги по переводу денег - кредитные организации, системы электронных денег и моментальных переводов и другие и компании, действующие на основе агентских соглашений.
Юридическая организация СРТ:
Общее управление СРТ осуществляется Оператором СРТ, отвечающим в том числе за управление развитием и функционированием СРТ, разработку стандартов, определение правил работы СРТ, развитие и сопровождение программно-аппаратного комплекса ЦОТ, заключение соглашений с участниками СРТ.
Между Оператором СРТ и Провайдерами трансферт-услуг заключаются соглашения, устанавливающие порядок использования ПТУ сервисов СРТ, в целях предоставления клиентам ПТУ трансферт-услуг.
Соглашение между Оператором СРТ и ПТУ Спонсора должно предусматривать, что положительный ответ ПТУ Спонсора на запрос ЦОТ на авторизацию трансферта создает у ПТУ Спонсора обязательство перед Оператором СРТ в размере суммы трансферта.
Соглашение между Оператором СРТ и ПТУ Бенефициара должно предусматривать, что передача ЦОТ в адрес ПТУ Бенефициара сообщения о подтверждении трансферта создает у Оператора СРТ перед ПТУ Бенефициара обязательство в размере суммы трансферта.
Между участниками трансферта и их расчетными банками заключаются соглашения, устанавливающие взаимные права и обязанности в части управления расчетными счетами и расчетов по обязательствам, связанными с трансфертами.
Организация расчетов:
Расчеты между участниками СРТ по обязательствам, возникающим в результате трансфертов, производятся в безналичной форме путем переводов между счетами участников в соответствующих Расчетных банках, в качестве которых могут выступать любые кредитные организации РФ, обеспечивающих ведение расчетных счетов участников и расчеты между ними по обязательствам, возникающим при обработке трансфертов.
СРТ должна поддерживать два режима расчетов между участниками: (1) синхронные расчеты [14] производятся в ходе процессинга (см. далее) в реальном времени и используются в случаях, когда по каким-либо причинам не допускается накопление обязательств; (2) асинхронные расчеты [15] производятся в отложенном режиме по результатам клиринга и не связаны жестко по времени с процессингом.
Возможность асинхронных расчетов, не связанных жестко по времени с процессингом, позволяет сделать подтверждение трансферта независимым от расчетов, что облегчает решение задачи выполнения трансферта в реальном времени, так как во многих случаях именно передача Бенефициару подтверждения трансферта рассматривается как выполнение платежа [16] .
В случае, если выполнение трансферта требовало бы в обязательном порядке завершения расчетов между всеми участниками, обеспечить требование проведения трансферта в реальном времени было бы значительно труднее, так как для этого потребовалось бы совершать расчеты между всеми участниками также в реальном времени, что теоретически возможно, но практически крайне трудно реализуемо.
4. Процесс обработки трансферта
Обработка трансферта производится путем обмена между участниками обработки трансферта юридически значимыми электронными сообщениями, заверенными в необходимых случаях электронной подписью.
Процесс обработки трансферта, включая протоколы передачи сообщений и их форматы устанавливаются национальным стандартом.
В общем случае процесс обработки трансферта включает в себя шесть подпроцессов, - процессинг, синхронные расчеты, клиринг, асинхронные расчеты, фондирование и выплата, каждый из которых может включать несколько этапов.
Некоторые из перечисленных подпроцессов, а именно синхронные расчеты, клиринг, асинхронные расчеты, является необязательным.
Кроме того, подпроцессы, составляющие процессинг, как правило независимы с точки зрения времени их выполнения. Как следствие, строгая последовательность исполнения подпроцессов процессинга отсутствует. Например, фондирование может производиться в любом порядке в зависимости от условий трансферт-услуги, режима трансферта и соглашений его участников.
Отсутствие жесткой связи между подпроцессами обеспечивает гибкость необходимую для возможности реализации множества различных режимов обработки трансферта.
4.1. Процессинг
В ходе процессинга производится обмен запросами между участниками трансферта для проверки технической, правовой, организационной и финансовой возможности выполнения трансферта, в том числе получения согласия всех участников на его выполнение, проверки наличия счетов и достаточности денег, координации с внешними процессами и т. п. [17]
В случае успешного результата всех проверок процессинг завершается передачей от ПТИУ Бенефициара в адрес Бенефициару юридически значимого подтверждения выполнения трансферта и соответствующей выплаты.
Результатом процессинга является непрерывная «цепочка обязательств», от Спонсора до Бенефициара, каждое звено которой является обязательством предыдущего участника перевести следующему сумму трансферта [18] .
Процессинг включает следующие логические этапы (Рисунок 1): инициация, контроль рисков, продолжение, акцепт, верификация, авторизация, координация, подтверждение.
Обработка этапов процессинга производится как правило в той последовательности, в которой они рассматриваются ниже, хотя данное правило не является строгим и возможны исключения. Состав и последовательность выполнения фактических этапов зависят от контекста, условий и режима обработки трансферта.
4.1.1. Инициация
Начальной точкой процессинга является обращение Инициатора к обслуживающему его ПТУ с запросом (1.1 [19] ) на предоставление трансферт-услуги.
Порядок запроса и условия трансферт-услуги, включая режим обработки трансферта, порядок фондирования и выплаты, способы идентификации и аутентификации Инициатора, документального оформления запроса, состав запрашиваемых данных и т.п. определяются условиями трансферт-услуги, установленными ПТУ и/или соглашением между Инициатором и ПТУ.
Сумма и валюта трансферта в общем случае могут быть любыми, на техническом уровне ЦОТ не должен ограничивать эти параметры трансферта. Ограничения, если они необходимы, например в целях управления рисками либо соблюдения требований законодательства, должны устанавливаться ПТУ.
На основании запроса, полученного от Инициатора, ПТУ формирует запрос к ЦОТ (1.2) на инициацию трансферта в формате, установленном стандартами СРТ.
4.1.2. Контроль рисков
При обработке запроса ПТУ Инициатора на инициацию трансферта Подсистема процессинга проверяет возможность выполнения трансферта с точки зрения ограничений, предусмотренных политикой СРТ управления рисками, возникающими при выполнении трансфертов. С этой целью Подсистема процессинга запрашивает (2.1) у Подсистемы управления рисками разрешение на выполнение трансферта.
В ходе обработки запроса на разрешение трансферта Подсистема управления рисками может в том числе проверять финансовую возможность выполнения расчетов между участниками и запрашивать (2.2, 2.3) с этой целью остатки на счетах участников в расчетных банках.
В общем случае Подсистема управления рисками возвращает разрешение или запрет на выполнение трансферта. В случаях, когда это предусмотрено условиями и/или режимом обработки трансферта, Подсистема управления рисками может возвращать предложение об изменении режима обработки.
4.1.3. Продолжение
В случаях, когда это предусмотрено условиями и/или режимом обработки трансферта, его исполнение может приостанавливаться до получения подтверждения необходимости продолжения от Бенефициара и/или Спонсора [20] .
Подтверждение предоставляется в форме запроса (3.1, 3.2), направляемого пользователем через обсуживающего его ПТУ. Порядок направления запроса определяется соглашением между пользователем и ПТУ.
Запрос может как требовать возобновления обработки трансферта, так и её прекращения и, кроме того, включать информацию, уточняющую или изменяющую параметры трансферта, например, Бенефициар может определить или изменить время, место и порядок выплаты, Спонсор может изменить время, место, порядок фондирования и сумму трансферта.
В случае необходимости запрос на продолжение может также включать требование получения согласия либо запроса на продолжение второй стороны, что открывает возможность для итерационного согласования условий трансферта между Бенефициаром и Спонсором.
4.1.4. Акцепт трансферта
Акцепт трансферта производится с целью получения согласия участников трансферта на его выполнение.
Для получения акцепта трансферта ЦОТ через соответствующего ПТУ направляет акцептующему участнику запрос акцепта (4.1, 4.2).
Акцепт трансферта необязателен и производится только для режимов, предусматривающих получение согласия Бенефициара и/или Спонсора на трансферт, например, согласие Спонсора как правило необходимо для трансфертов, инициируемых Бенефициаром [21] .
4.1.5. Верификация
Верификация трансферта (5.1) производится с целью проверки технической возможности выполнения трансферта на стороне Бенефициара, в том числе наличие и работоспособность счета для выплаты, указанного в условиях трансферта.
Верификация в общем случае необязательна и производится только для трансфертов, условия и/или режим обработки которых предусматривают такую проверку.
4.1.6. Авторизация
Авторизация трансферта (6.1, 6.2) производится с целью проверки технической и финансовой возможности выполнения трансферта на стороне Спонсора, в частности для проверки наличия у Спонсора достаточных средств на счете, а также обеспечения возможности выполнения расчетов по обязательствам, возникающим при выполнении трансферта, например, путем блокирования суммы трансферта на счете.
Возвращая ПТУ положительный ответ на запрос авторизации Спонсор берет на себя обязательство перед ПТУ в случае успешного выполнения трансферта произвести фондирование и возместить ПТУ сумму трансферта.
Возвращая ЦТО положительный ответ на запрос авторизации ПТУ также берет на себя обязательство перед СРТ в случае успешного выполнения трансферта возместить Оператору СРТ сумму трансферта.
Таким образом, в результате и после положительного результата обработки запроса авторизации формируется цепочка обязательств по переводу суммы трансферта Спонсор à ПТУ Спонсора à Оператор СРТ.
4.1.7. Координация с внешней транзакцией
В случае, если трансферт является подпроцессом внешней "родительской" транзакции и выполнение/невыполнение трансферта зависит от хода обработки этой транзакции, Подсистема процессинга направляет Координатору внешней транзакции запрос (7.1) на разрешение продолжения обработки трансферта.
4.1.8. Подтверждение
После получения положительного ответа на запрос авторизации на стороне Спонсора и (при наличии запроса) разрешения на завершение трансферта от Координатора внешней транзакции ЦОТ запросом (8.1) направляет ПТУ Бенефициара подтверждение трансферта. В результате передачи подтверждения Оператор СРТ берет на себя обязательство перед ПТУ Бенефициара в случае успешного выполнения трансферта выплатить ему сумму трансферта.
Получив от ЦОТ подтверждение трансферта, ПТУ Бенефициара запросом (8.2) передает это подтверждение Бенефициару. Тем самым ПТУ Бенефициара берет на себя обязательство перед Бенефициаром в случае успешного выполнения трансферта произвести выплату в его пользу в порядке, предусмотренным условиями трансферта и/или соглашением между ПТУ Бенефициара и Бенефициаром.
Результатом подтверждения трансферта является цепочка обязательств от Оператора СРТ до Бенефициара.
Таким образом, в случае успешного выполнения процессинга формируется непрерывная цепочка обязательств по переводу суммы трансферта от Спонсора до Бенефициара: Спонсор à ПТУ Спонсора à Оператор СРТ à ПТУ Бенефициара à Бенефициар.
4.2. Синхронные расчеты
В случаях, когда режим обработки и/или условия трансферта и/или соглашения между участниками трансферта предполагают режим синхронных расчетов между некоторыми участниками трансферта, расчеты по обязательствам между такими участниками, возникающим в ходе процессинга, выполняются непосредственно в ходе процессинга.
Запросы на перевод денег между счетами участников, необходимые для выполнения синхронных расчетов, направляются Подсистемой процессинга в Расчетный банк СРТ через Подсистему управления расчетами (9.1, 9.2).
4.3. Клиринг
В случае использования режима асинхронных расчетов по мере накопления обязательств между всеми или некоторыми участниками трансферта производится клиринг.
Для клиринга используется информация о выполненных трансфертах и сформированных обязательствах, не погашенных в режиме синхронных расчетов, передаваемая Подсистемой процессинга в Подсистему клиринга соответствующими запросами (10.1).
Периодичность проведения клиринга определяется правилами СРТ, включая политику управления рисками, и соглашениями между Оператором СРТ и участниками обработки трансферта, например установленными лимитами на суммы накопленных обязательств отдельных участников.
4.4. Асинхронные расчеты
Асинхронные расчеты производятся для погашения накопленных обязательств между участниками трансферта, рассчитанных в результате клиринга.
Для выполнения асинхронных расчетов Подсистема клиринга направляет через Подсистему управления расчетами в Расчетный банк СРТ запросы (11.1, 11.2) на перевод денег между счетами участников.
4.5. Фондирование
Для фондирования трансферта Спонсор передает (12.1) обслуживающему его ПТУ некоторую ценность.
Фондирование может производится в различных формах, в том числе списанием суммы трансферта со счета Спонсора, внесения наличных в кассу (валюта может не совпадать с валютой трансферта), передачи средств, полученных Спонсором в виде ссуды, и т. д. Порядок фондирования определяются условиями трансферт-услуги и/или соглашениями между Спонсором и ПТУ Спонсора.
По времени фондирование может производится в любой точке процесса обработки трансферта. Время фондирования определяется условиями трансферт-услуги, режимом обработки трансферта и/или соглашениями между Спонсором и ПТУ Спонсора.
4.6. Выплата
Для выплаты ПТУ Бенефициара передает (13.1) Бенефициару некоторую ценность (как правило, деньги).
Выплата может производится в различной форме, в том числе списанием суммы трансферта со счета ПТУ Бенефициара, выдачи наличных из кассы (валюта может не совпадать с валютой трансферта), погашения задолженности Бенефициара перед ПТУ) и т.д. Форма выплаты определяется условиями трансферт-услуги и соглашением между Бенефициаром и ПТУ Бенефициара.
Момент выплаты может совпадать либо быть после момента завершения процессинга (подтверждения трансферта). Время выплаты определяется условиями трансферт-услуги, режимом обработки трансферта и соглашением между Бенефициаром и ПТУ Бенефициара.
5. Примеры режимов выполнения трансферта
Ниже приводятся примеры нескольких типичных режимов выполнения трансферта (для краткости подпроцессы координации, клиринга и расчетов не показаны). Как видно из приведенных примеров, состав и последовательность выполнения подпроцессов и этапов процессинга зависят от условий и трансферт услуги и режима обработки трансферта.
Рисунок 2. Перевод по инициативе Спонсора. |
Рисунок 3. Перевод по инициативе Бенефициара. |
 Рисунок 4. Перевод по инициативе Спонсора с запросом продолжения Бенефициаром. |
Рисунок 5. Перевод по инициативе Бенефициара с запросом продолжения Спонсором. |
6. Создание трансфертной сети
Стандартизация процесса обработки трансферта и разделение процессинга и расчетов обеспечивают операционную совместимость СРТ и делают возможной прямую (без доработки и/или создания дополнительных шлюзов) интеграции друг с другом двух или более СРТ.
На представленной ниже (Рисунок 6) в качестве примера схеме интеграции двух СРТ для случая, когда инициация трансферта производится Спонсором, ЦОТ СРТ 1 (СРТ Спонсора), через который производится инициация трансферта, играет роль «ведущего», обеспечивая управление процессом обработки трансферта. ЦОТ СРТ 2 (СРТ Бенефициара) является «ведомым» и обеспечивает маршрутизацию и передачу запросов на Бенефициара и Оператора счета Бенефициара.
Рисунок 6. Интеграция СРТ |
Если инициация трансферта производится Бенефициаром роль "ведущего" будет выполнять СРТ Бенефициара, СРТ Спонсора будет ведомым.
В более сложном случае, когда инициация трансферта производится третьей стороной, схема расширяется за счет появления в ней третьей СРТ - СРТ Инициатора, которая выполняет функцию ведущей СРТ, обеспечивающей управление процессом обработки трансферта. СРТ Спонсора и СРТ Бенефициара и обеспечивают передачу запросов Спонсору и Бенефициару, соответственно.
Рассмотренная выше «прямая интегрируемость» СРТ позволяет операционно связать частные СРТ (ЧСРТ), входящие в НПС, в одноранговую трансфертную сеть (Рисунок 7), в которой любой пользователь любой СРТ может сделать трансферт любому другому пользователю. Принципы такой сети кратко описываются ниже.
 Рисунок 7. Архитектура одноранговой трансфертной сети |
НТС создается в форме ассоциации участников НТС (кооператив, некоммерческое партнерство и т.п.), которая осуществляется управление развитием и функционированием НТС, в том числе разрабатывает правила НТС, осуществляет прием новых и/или исключение действующих членов, обеспечивает заключение и ведение договоров, осуществляет контроль исполнения участниками правил, применяет штрафные санкции за нарушение правил, распределяет доходы, полученные ассоциацией в виде комиссионных и иных платежей, осуществляет управление операционными информационными ресурсами НТС.
Вступление новых участников в НТС в обязательном порядке предполагает присоединение к правилам НТС, одно из положений которых должно устанавливать, что при передаче сообщений определенного типа между ЧСРТ, между которыми передается сообщение, возникают финансовые обязательства.
Технически все СРТ, являющиеся узлами трансфертной сети, эквивалентны и равноправны. Каждая ЧСРТ в сети выступает в двух ролях - обслуживает подключенных к нему ПТУ и действует как транспортный узел, обеспечивая передачу сообщений в процессе обработки трансферта.
Для передачи сообщений используются стандартные сетевые протоколы. Сообщения могут передаваться между двумя любыми узлами.
Каждая ЧСРТ независимо производит клиринг, включая расчет обязательств и требований по отношению к другим ЧСРТ, с которыми производился обмен сообщениями, и передает в расчетные банки платежные инструкции.
Провайдеры трансферт-услуг заключают с СРТ соглашения об обслуживании. Один ПТУ может заключить соглашения с одной или более СРТ. На примере, приведенном выше (Рисунок 7) соглашения между ПТУ и СРТ обозначены "толстыми стрелками" - ПТУ Спонсора подключен к НТС через ЧСРТ 5 и ЧСРТ 6, ПТУ Бенефициара подключен к НТС через ЧСРТ 4 и ЧСРТ 5.
Оптимальный маршрут прохождения сообщений выбирается ПТУ Спонсора при инициации процесса обработки трансферта исходя из критериев максимальной надежности и минимального времени доставки сообщений. При выборе могут учитываться такие факторы, как доступность и загруженность ЦОТ ЧСРТ, число промежуточных ЦОТ, размер накопленных обязательств между ЧСРТ, остатки на счетах ЧСРТ в расчетном банке и т. п. Выбранный маршрут далее используется для обмена сообщениями в течение всего процесса обработки трансферта.
В приведенном выше примере (Рисунок 7) возможно несколько маршрутов: 1-3-7, 1-4-5-7, 1-4-6, 2-6, 2-5-7. Как правило, исходя из критерия минимального числа промежуточных узлов, будет выбираться маршрут 2-6, однако, в определенных случаях, например, при неработоспособности или высокой загруженности ЧСРТ 5 могут выбираться и другие маршруты, "обходящие" ЧСРТ 5, например 1-3-7 или 1-4-6.
Расчеты между расчетными банками ЧСРТ производятся через расчетный банк трансфертной сети, в роли которого может выступать, например, Центральный Банк. На примере, приведенном выше (Рисунок 7), маршруты расчетов (зеленые стрелки в нижней части рисунка) соответствуют маршрутам обмена сообщениями.
Предложенная в настоящей статье модель допускает расширение путем подключения к трансфертной сети частных платежных систем (ЧПС), отличных от СРТ (Рисунок 8 [22] ). ЧПС может быть подключена к одной или нескольким ЧСРТ, входящих в трансфертную сеть, в качестве Провайдера трансферт-услуг [23] при условии поддержки ЧПС соответствующих стандартов.
 Рисунок 8. Подключение к НТС частных ПС |
Подключение ЧПС делает возможными трансферты между пользователями, обслуживающимися в различных ЧПС, что фактически означает создание интегрированного трансфертного пространства в национальном масштабе. При этом трансфертная сеть СРТ выступает в качестве «интеграционного хаба» объединяющего ЧПС.
Требование нейтральности СРТ к валюте с технической точки зрения позволяет легко расширить функциональность СРТ и говорить о трансферте не только денег, но и любых абстрактных сущностей, подчиняющихся тем же законам управления (один владелец в данный момент времени, сущность характеризуется массой (суммой), учет на счете, возможность передачи, запрет на двойное списание и т.п.), что и деньги, например, ценных бумаг.
Заметим также, что в описанной модели трансфертной сети нет явной ссылки на страну ЧСРТ или ЧПС. Это позволяет включать в трансфертную сеть зарубежные ПС и создавать на базе описанной модели международные системы розничных трансфертов.
7. Передача дополнительной информации
При выполнении трансферта может возникать необходимость передавать нерегламентированную дополнительную информацию [24] , не содержащуюся в сообщениях стандартного формата, передаваемых в ходе процессинга (далее "сопроводительные сообщения").
Технически сопроводительные сообщения можно передавать "по отдельному контуру" вне информационной среды, в которой происходит обработка трансферта, однако в этом случае возникают дополнительные трудозатраты на создание и поддержку такого контура и увеличивается риск потери информации. Предпочтительно поэтому сопроводительные сообщения включать в состав сообщений, передаваемых при обработке трансферта.
Использование для передачи сопроводительных сообщений основных (установленных стандартами СРТ) полей сообщений, передаваемых в ходе процессинга, нецелесообразно, так как состав и свойства таких полей в силу стандартизации статичны, тогда как содержание и структура сопроводительных сообщений могут непредсказуемо изменяться.
Предлагается поэтому использовать для доставки сопроводительных сообщений выделенное "транспортное" поле в составе стандартного сообщения СРТ, которое передавалось бы от отправителя получателю без изменения и обработки подсистемой процессинга.
7.1. Стандартизация сопроводительных сообщений
При создании технологии передачи сопроводительных сообщений необходимо найти баланс между двумя противоречащими друг другу требованиями:
С одной стороны, поскольку процесс передачи сопроводительных сообщений, в частности ее состав, объем, формат, способы защиты и подтверждения, зависит от режима обработки трансферта и потребностей участников и может варьироваться очень широко, технология передачи должна быть гибкой и обеспечивать возможность кастомизации вплоть до требований отдельных субъектов.
С другой стороны, чтобы обеспечить возможность обмена сопроводительными сообщениями между несвязанными друг с другом участниками, технология обмена должна допускать стандартизацию.
Противоречие разрешается, если стандартизацию различных составляющих сопроводительного сообщения разделить между различными сторонами:
Транспортный пакет, в котором передаются сопроводительные сообщения (далее "пакет сопроводительной информации" или "ПСИ"), в том числе его структура, способы адресации, подписания электронной подписью, размещения сопроводительных сообщений и/или вложенных транспортных пакетов и т.п., не зависят от содержания сообщений и могут быть унифицированы в рамках стандарта верхнего уровня (национального стандарта) на формат ПСИ.
Стандартизацию собственно сопроводительных сообщений, зависящих от потребностей пользователей, логично передать в руки последних, предоставив им возможность разрабатывать частные стандарты сопроводительных сообщений. При этом может быть определено неограниченное число частных стандартов, в качестве владельцев которых могут выступать любые участники или пользователи СРТ, а также третьи стороны.
Управление стандартизацией ПСИ, включая организацию процессов разработки и утверждения стандартов ПСИ и ведения реестра частных стандартов, целесообразно осуществлять в рамках общей системы стандартизации в НПС.
7.2. Структура ПСИ
Поскольку на практике может возникать необходимость одновременной передачи более одного сопроводительного сообщения и вложенных сопроводительных сообщений, предлагается в рамках общего стандарта на формат ПСИ определить ПСИ как многоуровневую иерархию, включающую ПСИ верхнего уровня и неограниченное число уровней вложенных ПСИ.
Примерная структура ПСИ показана ниже (Рисунок 9):
Рисунок 9. Структура пакета сопроводительной информации |
ПСИ включает в себя ноль или более (число не ограничено) сопроводительных сообщений, содержащих информацию, которую необходимо передать между пользователями. Формат и структура сопроводительных сообщений регулируются частными стандартами, разрабатываемыми пользователями.
Кроме сопроводительных сообщений ПСИ содержит набор атрибутов, например, идентификатор ПСИ, ссылка на частный стандарт, применимый к ПСИ, электронная подпись и иные данный, связанные с подписанием и шифрованием содержания ПСИ, идентификатор основного сообщения, адресная информация отправителя и получателя ПСИ и т.д. Структура и содержание атрибутов как правило регулируются стандартом на общий формат ПСИ. Отдельные атрибуты ПСИ могут регулироваться частными стандартами.
В дополнение к вышеперечисленному ПСИ содержит 0 или более (число не ограничено) вложенных ПСИ. Число уровней в описанной иерархии не ограничено и определяется пользователями, разрабатывающими частные форматы ПСИ.
7.3. Передача ПСИ большого объема
Объем дополнительной информации, передаваемой в ПСИ, заранее неизвестен и потенциально может варьироваться от нескольких байт для передачи коротких сообщений до значительных размеров. Верхнюю границу определить сложно, однако можно ожидать, что объем передаваемых данных может быть достаточно большим. Например, нельзя исключить, что в каких-то случаях участникам трансферта будет необходимо передавать видео-файлы.
Несмотря на указанную неопределенность, система передачи дополнительной информации должна обеспечивать возможность передачи ПСИ для всего диапазона объемов данных.
Заметим, что это требование входит в очевидное противоречие с другим не менее существенным требованием обеспечить в необходимых случаях высокую скорость (вплоть до реального времени) обработки трансферта.
Для разрешения этого противоречия технология передачи сопроводительных сообщений в случае обмена сообщениями значительного размера должна быть модифицирована. Обмен объемными ПСИ целесообразно производить через выделенную подсистему передачи ПСИ (Рисунок 10), что позволит с одной стороны выполнить требование быстрой обработки в необходимых случаях трансфертов, в с другой, сохранить обработку объемных ПСИ внутри информационного пространства, в котором происходит обработка трансферта.
Рисунок 10. Система передачи сопроводительных сообщений большого объема |
При необходимости передачи ПСИ значительного объема отправитель сохраняет такую ПСИ в базе ПСИ при этом ПСИ присваивается уникальный идентификатор. В ПСИ, передаваемом в составе процессингового сообщения, в сопроводительном сообщении указывается идентификатор ПСИ, сохраненного в базе ПСИ, с помощью которого получатель ПСИ может запросить его из базы ПСИ.
8. Идентификация записей
При совершении трансфертов для адресации сообщений и/или совершения действий, предусмотренных процессом обработки трансферта (например, запроса остатка или блокирования суммы трансферта на счете) как правило возникает необходимость идентификации [25] учетных записей [26] различных сущностей, связанных с трансфертом [27] .
Для существования интегрированного платежного пространства необходима схема идентификации учетных записей, обеспечивающая возможность единообразной адресации записей при помощи унифицированного национального идентификатора записи (НИЗ), формируемого по стандартным правилам.
НИЗ должен удовлетворять следующим требованиям:
· однозначная идентификация учетной записи на всем множестве учетных записей в пределах страны;
- совместимость с IBAN, возможность преобразования НИЗ в IBAN и обратно;
· нейтральность к типу сущности, возможность идентификации учетных записей любых типов сущностей;
- нейтральность к оператору записей [28] , возможность идентификации учетных записей, ведущихся у любых операторов записей независимо от размера, организационной структуры, архитектуры информационной системы и т.п.;
· нейтральность к отрасли, возможность идентификации учетных записей для любых отраслей;
· языковая нейтральность, применимость в любых языковых средах и кодировках;
· возможность маршрутизации внутристрановых сообщений [29] внутри страны без обращения к зарубежным информационным ресурсам;
- возможность автоматизированной обработки;
- возможность обработки человеком, в том числе:
· человекочитаемость, простота запоминания, прочтения и ввода;
· возможность локальной проверки по формальным критериям при вводе;
· расширяемость, сохранение полной работоспособности в процессе развития НПС;
При проектировании схемы идентификации учетных записей необходимо учитывать, что в настоящее время отсутствует (и, маловероятно, что появится в будущем) единый порядок внутренней идентификации [30] учетных записей различными операторами записей.
Так, подходы к идентификации учетных записей в разных странах сильно различаются. Например, каждая страна устанавливает (или не устанавливает вообще) собственные правила формирования номера банковского счета.
Кроме того, в пределах одной страны способы идентификации зависят от отрасли. Например, способы нумерации лицевых счетов клиентов в банках, у операторов сотовой связи, интернет-провайдеров, страховых компаний, системах криптовалют различаются. В некоторых случаях формат устанавливается регулятором, в других самим оператором, в третьих международным стандартом, в четвертом протоколом системы цифровых наличных и т.д.
Даже в пределах одной отрасли одной страны может быть множество операторов записи различающихся размером бизнеса (т.е. числом учетных записей), организационной структурой, архитектурой информационных систем и т.п. и как следствие требованиями к внутренней идентификации учетных записей.
Вышеописанный "хаос идентификации" усугубляется непрерывно идущими процессами развития платежных систем, приводящим к появлению новых типов операторов записей и изменением существующих, изменению регулирования и т.п.
Вышесказанное показывает, что задача создания единого стандарта внутренней идентификации учетных записей практически неразрешима [31] и при проектировании схемы идентификации необходимо исходить из множественности стандартов внутренней идентификации, управляемых различными лицами и на различных уровнях.
В описанной ситуации "неуправляемости внутренних идентификаторов" УИЗ может быть создан путем комбинации внутреннего (уникального в пределах оператора записей) идентификатора с другими идентификаторами, например, такими как коды страны, отрасли, оператора, подразделения оператора, базы учетных записей и т.д., обеспечивающими необходимую уникальность УИЗ (национальную или международную).
Задача создания УИЗ таким образом сводится к стандартизации порядка формирования УИЗ из внутреннего идентификатора, обеспечиваемого оператором записей, и других данных.
Верхнеуровневую структуру УИЗ можно определить анализируя процесс адресации сообщения при обработке трансферта. Адресация выглядит как движение по дереву решений сверху вниз от международного уровня до уровня оператора:
· на международном уровне соответствующий узел платежной сети выделяет и анализирует сегмент УИЗ, содержащий международный адрес (страну или группу стран) учетной записи и передает сообщение на обработку соответствующему национальному (наднациональному) узлу;
· на национальном уровне соответствующий узел выделяет и анализирует сегмент УИЗ, содержащий адрес оператора учетной записи [32] и передает сообщение на обработку узлу, отвечающему за обработку сообщений, поступающих в адрес оператора;
· на уровне оператора соответствующий узел платежной сети выделяет и анализирует сегмент УИЗ, содержащий внутренний адрес учетной записи, определяет информационную систему, в которой находится учетная запись, и передает ей сообщение.
С учетом вышесказанного предлагается формировать УИЗ в виде иерархии сегментов, каждый из которых соответствует перечисленным уровням обработки УИЗ при адресации сообщений (Рисунок 11). При этом внутренняя структура сегментов должна определяться независимыми стандартами, устанавливаемыми различными органами стандартизации.
Рисунок 11. Структура унифицированного идентификатора записи |
Глобальный идентификатор записи (ГИЗ) имеет структуру соответствующую требованиям ISO 13616 для международного номера банковского счета (International Bank Account Number, IBAN) и включает сегмент [33] , в котором указывается международный адрес учетной записи (страна), сегмент с контрольными разрядами IBAN и сегмент, включающий национальный адрес (последний не анализируется при обработке на международном уровне).
Национальный адрес (в терминах ISO 13616 Basic Bank Account Number, BBAN) регулируется национальными стандартами (в случае банковских счетов - центральными банками). Длина национального адреса не должна превышать 30 символов.
Для внутристрановых трансфертов вместо национального адреса, предусмотренного ISO 13616, возможно использовать национальный идентификатор записи (Рисунок 11), не включающий ненужный для внутристрановых трансфертов код страны.
Вместо контрольных разрядов ГИЗ для НИЗ рассчитывается собственная контрольная сумма, добавляемая в конец НИЗ. При необходимости преобразования НИЗ в ГИЗ Национальный адрес может быть получен из НИЗ путем удаления контрольных разрядов НИЗ.
Обратим внимание, что при использовании НИЗ снимается ограничение ISO 13616 на длину НИЗ и последняя может превышать 32 символа [34] . Тем не менее следует иметь в виду, что "длинные" НИЗ не могут быть преобразованы в ГИЗ и использоваться для трансграничных трансфертов.
Структура НИЗ (Рисунок 11) включает три сегмента: (1) адрес оператора записи, под которым понимается идентификатор, однозначно определяющий оператора записи на полном множестве операторов записи в стране; (2) внутренний идентификатор записи, под которым понимается идентификатор, однозначно определяющий учетную запись на полном множестве учетных записей, находящихся под управлением оператора; и (3) контрольные разряды, обеспечивающие возможность обнаружения со значительной вероятностью ошибок ввода [35] .
Общую структуру адреса оператора (Рисунок 11) предлагается определить на уровне национального стандарта как последовательность из двух или более сегментов, где первый сегмент длиной 1 или 2 символа содержит код схемы, идентифицирующий схему адреса.
Схема адреса содержит полное описание формата адреса оператора и определяет помимо прочего число сегментов в адресе, их смысл, последовательность и длину. Каждая схема относится к какому-либо подмножеству операторов записи, обладающих определенными особенностями, и описывает формат адреса оператора оптимальный для этого подмножества. Например, для крупных банков и операторов сотовой связи, ведущих большое числе записей и имеющих сложную организационную структуру, целесообразно выделить отдельную (от средних и небольших банков) схему.
Предполагается, что схемы будут создаваться по мере необходимости при возникновении подмножеств операторов, обладающих новыми особенностями, для которых не подходят ранее разработанные схемы.
В рамках НПС должен вестись справочник схем. В целях повышения надежности платежной системы и избежания создания "узкого горла" целесообразно не создавать справочник схем адреса оператора в виде централизованной базы данных. Более правильно использовать технологию аналогичную интернет и создать распределенную централизованно управляемую базу аналогично DNS.
Процесс разработки и регистрации схем адреса оператора должен регулироваться на национальном уровне, возможно, национальным стандартом. Управление справочником схем должно осуществляться соответствующим образом уполномоченной федеральной организацией, например, оператором платежной системы.
С каждой схемой должен быть связан справочник операторов записей, содержащий информацию, необходимую для адресации сообщений, например IP-адреса серверов операторов и т.д.
Одному справочнику может соответствовать более одной схемы. Управление справочниками операторов может быть как централизованным, так и децентрализованным и осуществляться, например, отраслевыми органами стандартизации и/или ассоциациями, группами операторов и т.п.
Обратим внимание, что в рамках предложенного подхода длина первого сегмента непостоянна и может иметь два значения - 1 или 2. Например, интервал от 0 до 5 (6 схем) может быть выделен для схем длина кода которых равна 1, интервал от 60 до 99 (40 схем) выделен для схем с длиной кода равной 2. Число "коротких" кодов схемы должно быть установлено национальным стандартом.
Переменная длина кода схемы позволяет в необходимых случаях увеличить на один символ длину внутреннего идентификатор записи. Например, 6 коротких кодов схем могут быть использованы для кодирования схем адресов операторов, которым необходимо иметь в своем распоряжении максимальное количество символов для внутреннего идентификатора записи (операторы, управляющие большим числом записей и/или имеющие сложную организационную структуру и/или сложную архитектуру информационной системы).
Примеры справочника схем оператора и некоторых схем приведены в таблицах ниже:
Таблица 1. Пример перечня схем адреса оператора
Таблица 2. Примеры схем адреса оператора
Структура, порядок формирования и использования внутреннего идентификатора записи полностью определяются оператором записей и не подлежат стандартизации.
В приведенных выше примерах в качестве внутреннего номера счета в банке указан 20-значный номер банковского счета. Такой номер содержит значительный объем ненужной клиенту "бухгалтерской" информации. Для удобства пользователей целесообразно в качестве идентификаторов счета использовать более короткие номера, что позволит значительно сократить длину НИЗ.
В общем случае ВИЗ будет иметь сегментированную структуру (Рисунок 11) аналогичную структуре НИЗ за исключением сегмента с указанием кода схемы, который в случае ВИЗ не является обязательным и используется по решению оператора.
Структура сегментов ВИЗ определяются оператором и очевидно будет отражать организационную структуру, организацию информационной системы и другие особенности оператора. Обязательным элементом ВИЗ является локальный адрес, под которым понимается уникальный идентификатор записи в пределах определенной информационной системы.
Благодаря сегментированной структуре УИЗ становится возможным независимое определение требований к структуре сегментов (фактически - структуре адреса на определенном уровне) различными участниками. Это позволяет создать многоуровневую иерархию стандартов и обеспечивает максимальную гибкость и расширяемость, в частности возможность независимого определения на различных уровнях схем адресации и определения на одном уровне множества схем адресации.
На диаграмме, описывающей возможную структуру УИЗ (Рисунок 11), можно выделить следующие уровни стандартизации: международный (показан на диаграмме синим цветом), национальный (зеленый), отраслевой (желтый), корпоративный (красный).
В рамках описанного подхода при необходимости число уровней стандартизации может быть увеличено или их состав изменен по отношению к приведенному примеру путем простого добавления схем адреса оператора, предполагающих большее число уровней или иной их состав.
В завершение заметим, что в описанном выше подходе к формированию НИЗ допускается возможность использования в адресе как буквенных символов, так и цифровых. Однако, учитывая, что ввод адреса может производится с использованием устройств доступа, не позволяющих вводить буквы (например, клавиатура стационарного телефона), предпочтительно при формирования адреса ограничиться только цифровыми символами.
9. Термины и сокращения
9.1. Термины
Асинхронные расчеты - расчеты по обязательствам между участниками процессов обработки трансфертов, возникшими в результате выполнения одного или более трансфертов, выполняемые в отложенном режиме по результатам клиринга. В зависимости от режима выполнения трансферта и/или требований участников трансферта и/или соглашений между участниками трансферта асинхронные расчеты могут производится между всеми или только некоторыми (любыми) участниками процесса обработки трансферта.
Выплата трансферта - передача ПТУ Бенефициара в пользу Бенефициара некоторой ценности, в частном случае денег, для погашения обязательства ПТУ Бенефициара перед Бенефициаром в связи с выполнением трансферта.
Интегрированное трансфертное пространство (ИТП) - совокупность связанных платежных систем, в которой любой субъект имеет техническую возможность (законодательные ограничения не рассматриваются) перевести деньги в любое время, в любом требуемом режиме, в любой валюте, со счета у любого оператора счета на счет любого субъекта у любого другого или того же оператора счета. Термин «трансфертное пространство» (вместо «платежное пространство») использован для разделения понятий «трансферт» и «платеж».
Клиринг ─ расчет итоговых обязательств участников трансфертов по накопленным обязательствам, включая взаимозачет (неттинг) встречных обязательств. Клиринг является необязательным подпроцессом обработки трансферта. Необходимость в клиринге возникает при использовании режима асинхронных расчетов.
Оператор счета - лицо ведущее денежный счет субъекта. В случае безналичных денег оператором счета является юридическое лицо, например, Центральный Банк РФ, кредитные организации, провайдеры мобильной связи, интернет-провайдеры, операторы электронных денег. В случае безналичных денег оператор счета совпадает с владельцем денег.
Оператор учетной записи сущности - лицо или группа лиц, распоряжающееся базой (базами) данных, в которых хранятся данные, входящие в учетную запись. Например, операторами записей клиентов являются все организации в какой-либо форме управляющие базой клиентов, операторами записей счета являются все организации управляющие счетами, т.е банки, небанковские кредитные организации, МФО, операторы сотовой связи, провайдеры услуг, частные платежные системы (системы безналичных электронных денег, системы цифровых наличных). В случае децентрализованной системы криптовалюты такой, как биткоин и его производные, единый владелец распределенной базы данных с записями счетов (кошельков) отсутствует и оператором записей счетов является сообщество пользователей таких систем.
Платеж - передача одним субъектом (Покупателем), получающим услугу или товар у другого субъекта (Продавца), этому субъекту какой-либо ценности в обмен на получаемую услугу или товар. В качестве средства платежа, могут выступать любые материальные или нематериальные сущности, представляющие ценность для Продавца, в частности деньги. В последнем случае платеж выполняется с использованием трансферта. Понятие «платеж» имеет смысл только в сделке продажи, когда есть Продавец и Покупатель, но к другим типам сделок, например, к сделкам мены и односторонним сделкам дарения, неприменимо.
Родительская сделка - сделка, по отношению к которой трансферт является дочерним подпроцессом. Например, конверсионная сделка в режиме PvP может рассматриваться как два встречных трансферта в различных валютах, выполняемых в рамках одной транзакции. Аналогично, при оплате приобретаемого в магазине товара трансферт является частью сделки покупки-продажи. Как правило к сделкам применяется требование транзакционности, заключающееся в том, что либо успешно выполняются все действия сделки, либо не выполняется ни одно из них. Для обеспечения транзакционности процесс, управляющий родительской сделкой должен иметь возможность управлять трансфертом.
Синхронные расчеты - расчеты по обязательствам между участниками процесса обработки трансферта, возникающим в результате подпроцесса процессинга, выполняемые в реальном времени как часть этого подпроцесса. В зависимости от режима выполнения трансферта и/или требований участников трансферта и/или соглашений между участниками трансферта синхронные расчеты могут производится между всеми или только некоторыми (любыми) участниками процесса обработки трансферта.
Трансферт - передача по запросу Инициатора определенной суммы денег в определенной валюте от их исходного владельца (Спонсора) будущему владельцу (Бенефициару), где под передачей денег понимается переход собственности на деньги от Спонсора Бенефициару. Трансферт возникает не только при совершении платежа, но и в других типах сделок, когда деньги выступают в качестве обмениваемой или передаваемой ценности, например, при конверсионных операциях, и односторонней передаче денег (дарение, пополнение счета, получение наличных).
Трансферт-услуга - бизнес-услуга по переводу денег, созданная на основе технологических сервисов СРТ, предлагаемая Провайдером трансферт-услуг своим клиентам на платной основе.
Учетная запись сущности - выделенная совокупность взаимосвязанных данных в базе (базах) данных, описывающая эту сущность. Обратим внимание, что речь идет об идентификации учетной записи сущности, а не идентификации самой сущности. Одной сущности может отвечать несколько учетных записей, находящихся под управлением одного оператора записи, например, для одного и того же клиента банка может быть создано несколько учетных записей в одной или различных базах данных банка.
Фондирование трансферта - передача Спонсором в пользу ПТУ Спонсора некоторой ценности, в частном случае денег, для погашения обязательства Спонсора перед Провайдером трансферт-услуг в связи с выполнением трансферта.
9.2. Сокращения
ВИЗ - Внутренний идентификатор записи.
ГИЗ - Глобальный идентификатор записи.
ИТП - Интегрированное трансфертное пространство.
НИЗ - Национальный идентификатор записи.
НПС - Национальная платежная система.
ПС - Платежная система
ПСИ - Пакет сопроводительной информации.
ПТУ - Провайдер трансферт-услуг.
РБ - Расчетный банк.
СРТ - Система розничных трансфертов.
УИЗ - Унифицированный идентификатор записи.
ЧПС - Частная платежная система.
ЧСРТ - Частная система розничных трансфертов.
ЦОТ - Центр обработки трансфертов.
[1] Термины и сокращения, используемые в тексте статьи, понимаются в соответствии с определениями, данными по месту использования либо приведенными в разделе 9.
[2] Под контекстом понимается совокупность условий, в которых выполняется трансферт, например, характеристики пользователей трансферта, операторов счетов, время и место выполнения. В понятие контекста не включаются требования пользователей в отношении условий (параметров) трансферта и режима его выполнения.
[3] Под нейтральностью понимается независимость функциональности СРТ от контекста на техническом уровне без учета ограничений, накладываемых законодательством[3]
[4] См. термины.
[5] См. термины.
[6] См. термины.
[7] Например, в случае трансферта в рамках системы моментальных переводов запрос на продолжение трансферта направляется Бенефициаром, который этим одновременно определяет условия завершения трансферта, в частности время, место и режим выплаты. В этом случае временной режим трансферта технически может варьироваться в очень широком диапазоне от минут (если Бенефициар требует немедленного получения денег) до неограниченно длительного времени (месяцы и даже годы).
[8] Под частной платежной системой понимается платежная система на основе технологической платформы, отличной от СРТ.
[9] На диаграмме показаны логические роли. Состав фактических участников зависит от контекста - в определенных контекстах некоторые логические роли могут отсутствовать. Один субъект может выполнять несколько логических ролей.
[10] Красные стрелки обозначают запросы обрабатываемые в реальном времени, сиреневые - запросы, обрабатываемые в пакетном режиме, синие - выплату суммы трансферта в любой форме (наличные и безналичные), зеленые - перевод денег между счетами. Затемненные кружки в банках обозначают счета Лоро (корреспондентские или расчетные), незаполненные кружки обозначают счета Ностро. Незаполненная стрелка соответствует запрашивающей стороне, заполненная - запрашиваемой.
[11] См. термины.
[12] См. термины.
[13] См. термины.
[14] См. термины.
[15] См. термины.
[16] Если соглашение между Бенефициаром и его ПТУ рассматривает такое подтверждение как точку безотзывности трансферта, получение подтверждения является основанием для совершения Бенефициаром определенных действий. Например, получение положительного ответа на авторизационный запрос при оплате платежной картой является для торговой точки основанием для передачи товара.
[17] Процессинг можно рассматривать как переговоры между участниками путем обмена электронными сообщениями.
[18] В случаях, когда соглашения между участниками обработки трансферта предусматривают синхронные расчеты, обязательства в «цепочке обязательств» могут быть исполнены в реальном времени в ходе процессинга.
[19] Здесь и далее в скобках указан номер запроса на диаграмме процесса обработки трансферта (Рисунок 1).
[20] Например, подобный режим используется в системах моментальных переводов, в которых инициированный Спонсором перевод завершается по инициативе Бенефициара.
[21] Необходимость получения согласия Бенефициара встречается реже, но может быть необходимо, например, когда Спонсору до выполнения перевода необходимо юридически значимое согласие Бенефициара с условиями трансферта либо Бенефициар настаивает на определенной формулировке описания трансферта или определенном счете выплаты.
[22] Синие стрелки обозначают договорные отношения, зеленые - потоки обмена сообщениями и денежные потоки.
[23] Такая модель подключения предполагает, что ЧПС не выполняет функции СРТ в полном объеме, в том числе не управляет процессом обработки трансферта, как это делает подсистема процессинга ЦОТ СРТ. В случае, если ЧПС указанные функции может выполнять в полном объеме, она может выступать в качестве полноценного узла трансфертной сети.
[24] Например для сообщения Бенефициару порядка распределения суммы трансферта между несколькими конечными получателями и т.п.
[25] Под идентификацией (адресацией) понимается присвоение учетной записи идентификатора (адреса), позволяющего однозначно выделить учетную запись на определенном множестве других учетных записей. В некоторых контекстах термин "идентификация" может также обозначать ссылку на учетную запись путем указания идентификатора.
[26] Под учетной записью сущности понимается выделенная совокупность взаимосвязанных данных в базе (базах) данных, описывающая эту сущность. Обратим внимание, что речь идет об идентификации учетной записи сущности, а не идентификации самой сущности. Одной сущности может отвечать несколько учетных записей, находящихся под управлением одного оператора записи, например, для одного и того же клиента банка может быть создано несколько учетных записей в одной или различных базах данных банка.
[27] Например, счет, карта, группа счетов, цифровой кошелек, клиент, сделка и т.п.
[28] Под оператором учетной записи сущности понимается лицо или группа лиц, распоряжающееся базой (базами) данных, в которых хранятся данные, входящие в учетную запись. Например, операторами записей клиентов являются все организации в какой-либо форме управляющие базой клиентов, операторами записей счета являются все организации управляющие счетами, т.е банки, небанковские кредитные организации, МФО, операторы сотовой связи, провайдеры услуг, частные платежные системы (системы безналичных электронных денег, системы цифровых наличных). В случае децентрализованной системы криптовалюты такой, как биткоин и его производные, единый владелец распределенной базы данных с записями счетов (кошельков) отсутствует и оператором записей счетов является сообщество пользователей таких систем.
[29] Сообщения, отправитель и получатель которых находятся в РФ.
[30] Под внутренней идентификацией здесь понимается идентификация (нумерация, наименование) учетных- записей оператором записей.
[31] Единственное требование в отношении внутренних идентификаторов, которое с разумной степенью достоверности можно считать выполняющимся, является их уникальность в пределах одного оператора.
[32] Отраслевой уровень не включаем в иерархию в связи с отсутствием формального определения отрасли и вытекающей из этого возможной неоднозначностью отнесения учетных записей к определенной отрасли.
[33] Длина сегмента указана в фигурных скобках.
[34] В случаях, когда для внутристрановых трансфертов ограничение на длину национального адреса, установленное ISO 13616, не является обязательным, альтернативное значение для максимальной длины сегмента указано через слеш.
[35] Для вычисления контрольных разрядов предлагается использовать стандарт ISO/IEC 7064:2003, применяемый при вычислении таких разрядов в IBAN.
