Карл Сумманен, независимый эксперт

1. Введение

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

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

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

Особенно остро проблема отсутствия такого референса стоит в связи с тем, что в настоящее время в России существует множество операторов счета[2], модели идентификации счетов у которых широко варьируются. Даже в одной отрасли может быть несколько операторов счета различающихся масштабами, организационной структурой, архитектурой информационных систем и моделями идентификации счетов. "Хаос идентификации счетов" усугубляется процессами развития платежных систем и законодательства, изменяющими существующие типы операторов счетов и порождающими новые.

Отсутствие унифицированного способа идентификации счетов является одной (но не единственной) причиной отсутствия в РФ интегрированного трансфертного пространства, в рамках которого возможен трансферт с любого счета у любого оператора счета на любой счет у любого другого оператора счета.

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

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

Ожидается, что внедрение НРР обеспечит повышение качества облуживания для пользователей за счет большего удобства, скорости и простоты проведения операций; повышение операционной эффективности для участников обработки запросов за счет автоматической обработки; снижение числа ошибок; упрощение интеграции платежных систем; возможность полностью автоматизировать STP процессы "от ERP до ERP". В целом появление НРР может явится тригером и катализатором, которые запустят и ускорят процесс формирования интегрированного трансфертного пространства.

2. Требования к НРР

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

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

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

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

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

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

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

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

Корневым является ОР, не имеющий родительских ОР. В нашем случае это ОР национального (первого) уровня (т.е. государство), управляющий всеми ресурсами в национальной экономике[3].

Концевым является ОР, не имеющий дочерних ОР. Как правило в этой роли выступает ОР, непосредственно владеющий информационной системой, управляющей учетными записями ресурсов[4]. Концевой ОР, управляющий ресурсом, будем называть менеджером такого ресурса (МР).

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

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

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

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

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

Основное требование к НРР состоит в том, что информации, содержащейся в НРР, должно быть достаточно для идентификации ресурса. Для этого необходимо и достаточно, чтобы НРР для данного ресурса позволял: (1) идентифицировать МР и (2) определить локальный референс ресурса.

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

Чтобы выбрать оптимальную схему формирования НРР необходимо учесть и другие требования, для чего процессы адресации ресурсов должны быть рассмотрены более подробно. Сделаем это на примере трансферта.

Процесс обработки трансферта в общем случае включает несколько подпроцессов[5], в том числе: (1) процессинг - проверка возможности выполнения трансферта и подтверждение трансферта Бенефициару с созданием цепочки обязательств от Спонсора до Бенефициара; (2) клиринг - определение сторон, участвующих в расчетах и вычисление обязательств; и (3) расчеты в соответствии с обязательствами, рассчитанными в процессе клиринга. Каждый участник обработки трансферта может быть участником любого из перечисленных подпроцессов.

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

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

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

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

Вышесказанное проиллюстрировано ниже на примере фрагмента национального домена ОР (Рисунок 1), содержащего три ОР второго уровня: (1) оператора сотовой связи (ОСС 1); (2) многофилиальный банк (Банк 2) с двумя филиалами (ФБ 2.1 и ФБ 2.2); и (3) банковскую группу (БГ 3), включающую два многофилиальных банка (Банк 3.1 и Банк 3.2), каждый из которых имеет по два филиала. Банк 3.2 и филиалы Банка 2 и Банка 3.1 являются МР.

В рассматриваемом примере Банк 3.1 и Банк 3.2 функцию обработки сообщений в ходе процессинга делегировали группе банков БГ 3, Банк 3.1 делегировал функцию расчетов своим филиалам.

Таким образом, участниками процессинга являются все ОР уровней 2 и ниже кроме филиалов Банка 3.2; участниками клиринга являются ОСС 1, Банк 2, Банк 3.1 и Банк 3.2; участниками расчетов являются ОСС 1, Банк 2 и его филиалы, филиалы Банка 3.1, Банк 3.2 и его филиалы[6].

Для примера показаны три трансферта изображенных стрелками серого, красного и зеленого цветов. Пунктирные стрелки показывают общее направление трансферта. Стрелки отмеченные символами "P", "L" и "S" показывают: P ­ траекторию прохождения запросов при процессинге; L - цепочки обязательств, возникающих в результате процессинга, учитываемые при клиринге; и S - траекторию движения средств при расчетах по обязательствам.

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

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

Резюмируя вышесказанное перечислим требования к НРР:

· возможность идентифицировать любой ресурс в национальной экономике:

· возможность на основании НРР построить путь от национального ОР до МР;

· возможность на основании локального референса ресурса идентифицировать ресурс внутри менеджера ресурсов;

· возможность независимого установления политики маршрутизации ОР;

· возможность полностью автоматизированной маршрутизации;

· расширяемость - устойчивость к изменениям национального домена ОР;

· нейтральность к контексту:

· отрасли - применимость к любой отрасли экономики;

· типу ресурса - применимость к ресурсам любых типов;

· типу ОР - применимость к ОР любых типов;

· особенностям ОР;

· языку - применимость в любых языковых средах;

· кодировке - применимость для любых кодировок;

· каналу - применимость для любых используемых каналов;

· возможность обработки человеком, в том числе:

· человекочитаемость;

· простота запоминания и прочтения;

· удобство передачи от человека человеку;

· простота и скорость ввода;

· низкий уровень ошибок ввода;

· возможность выявления ошибок ввода только на основании данных НРР;

3. Формат и структура НРР

Прежде чем переходить к обсуждению формата НРР рассмотрим кратко подходы применяемые для решения аналогичных задач:

Номер платежной карты

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

Формат и структура номеров платежных карт регулируются международным стандартом ISO/IEC 7812, поддерживаемым платежной индустрией. Номер карты имеет вид последовательности цифр, включающей два сегмента: (1) код эмитента (Issuer Identification Number (IIN) или Bank Identification Number (BIN)) длиной шесть символов банка; и (2) внутренний номер счета (Primary Account Number (PAN))), определяемый эмитентом. Первый символ кода эмитента определяет отрасль (Major Industry Identifier), остальные пять символов являются адресом конкретного эмитента внутри отрасли. Последний символ внутреннего номера счета является контрольным разрядом, рассчитываемым с помощью алгоритма Luhn. Регистр IIN управляется американской банковской ассоциацией.

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

International Bank Account Number

Для решения задачи идентификации банковских счетов в мировом масштабе был разработан стандарт представления унифицированного международного референса банковского счета (International Bank Account Number или IBAN) в виде символьно-цифровой строки. Структура и синтаксис IBAN регулируются стандартом ISO 13616.

IBAN представляется в виде сегментированной последовательности буквенно-цифровых символов, включающей код страны, контрольные разряды, рассчитываемые с использование алгоритма MOD-97-10 (ISO/IEC 7064:2003) и внутренний (национальный) номер банковского счета (Basic Bank Account Number или BBAN).

Uniform Resource Identifier

Для решения задачи адресации ресурсов в нерегулярной многоуровневой иерархии, которую представляет из себя интернет, был разработан стандарт представления адреса (Uniform Resource Identifier или URI) произвольного ресурса (файла, сервиса, ящика электронной почты и т.д.) в сети Интернет. Текущая структура и синтаксис URI регулируются стандартом RFC 3986:2005.

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

Все рассмотренные выше решения являются "нишевыми", так как каждое из них ограничено определенной предметной областью (определенный тип ресурса и/или оператора ресурса) и/или не учитывают требования, предъявляемые к НРР (языковая нейтральность, нейтральность к каналу, возможность использования человеком и другие).

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

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

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

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

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

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

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

Оптимальным представляется использование 2-х контрольных разрядов, рассчитываемых при помощи алгоритма MOD-97-10 (ISO/IEC 7064:2003), обеспечивающего вероятность обнаружения ошибки около 99% (100% для некоторых типов ошибок, например, замены одной цифры).

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

Пример структуры НРР, соответствующей сформулированным выше предложениям, показана ниже (Рисунок 2):

Рисунок 2. Структура НРР

На верхнем "национальном" уровне (уровень 1) находится собственно национальный референс ресурса. НРР декомпозируется на три составляющих: (1) сегмент, содержащий относительный адрес дочернего ОР (Адрес ОР-2[8]), управляющего ресурсом; (2) референс ресурса уровня 2, где последний можно рассматривать как относительный адрес ресурса с точки зрения ОР-2; и (3) контрольный код из двух цифр, рассчитанный на основании данных НРР с использованием алгоритма MOD-97-10 (ISO/IEC 7064:2003).

Референс ресурса уровня 2 декомпозируется на относительный адрес дочернего ОР (относительный адрес ОР-3) и референс ресурса уровня 3. Комбинация адреса ОР-2 и относительного адреса ресурса уровня 3 может рассматриваться как адрес ОР-3.

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

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

При определении формата адреса ОР-2 будем исходить из двух основных требований: (1) поскольку число ОР-2 в общем случае неизвестно и может изменяться, адрес ОР-2 должен быть расширяемым; и (2) длина адреса ОР-2 должна быть минимальной при условии выполнения требования 1.

Одна из возможных схем формирования адреса ОР-2, удовлетворяющая рассмотренным выше требованиям, рассматривается ниже:

Представим адрес ОР-2 в виде последовательности из двух сегментов, первый из которых имеет длину 0 или 1 (минимальное значение длины равное 0 означает, что первый сегмент является необязательным) и определяет длину адреса ОР-2, второй является собственно адресом ОР-2.

Таблица 1. Структура адреса ОР-2

Для администрирования процессов управления адресами ОР-2 (выделение, аннулирование, замена) должен быть определен уполномоченный федеральный орган (по аналогии с Американской банковской ассоциацией (American Bankers Association, ABA), администрирующей процесс управления IIN), который должен будет определить правила распределения ресурсов, в частности механизмы принятия решений в случае конкуренции участников процесса за адреса.

В общем случае по желанию ОР-2 ему могут быть выделены адреса из любого диапазона[9]. Учитывая вероятное желание ОР-2 сократить длину НРР, можно ожидать, что выделение адресов будет производится, как правило, начиная с самых коротких с постепенным увеличением длины по мере роста числа ОР-2.

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

В случае прекращения использования отдельных адресов (например, при ликвидации ОР-2) такие адреса могут использоваться повторно, что позволит снизить скорость исчерпания адресного пространства.

Предлагаемая схема формирования адреса ОР-2 позволяет в общей сложности адресовать не более 1 111 105 ОР-2. С учетом размеров экономики РФ и возможности повторного использования такая емкость адресного пространства представляется вполне достаточной.

Для иллюстрации ниже приведен пример НРР для счета физического лица, находящегося под управлением филиала ФБ 3.1.1. Предполагается, что банковская группа БГ 3 включает не более 9 банков, банк Банк 3.1 имеет не более 99 филиалов, филиал ФБ 3.1.1 обслуживает не более 100 000 000 счетов, информационная система ФБ 3.1.1 включает не более 9 систем ведения счетов.

Таблица 2. Пример НРР для счета физического лица

4. Совместимость с IBAN

Учитывая важность банковских счетов как идентифицируемых ресурсов и глобальный характер расчетов, которые часто требуют глобальной (в мировом масштабе) идентификации, целесообразно обеспечить совместимость НРР и IBAN путем двусторонней конвертации рассматриваемых референсов друг в друга. Схема конвертации показана ниже (Рисунок 3)

Рисунок 3. Соответствие между НРР и IBAN

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

Описанный алгоритм взаимного преобразования НРР и IBAN применим только в случаях, когда длина НРР такова, что длина получающегося IBAN не превышает 34 символа (ограничение, установленное ISO 13616).

---

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

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

[3] В настоящей статье мы ограничиваемся решением задачи унифицированной идентификации в масштабах национальной экономики, что позволяет считать национального оператора ресурсов корневым узлом.

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

[5] Сумманен К.Т., Универсальная система розничных трансфертов: Основа НПС нового поколения, ПЛАС № 9 [220], сентябрь 2015.

[6] Участниками расчетов являются участники, имеющие соответствующие соглашения и открывшие корсчета (показаны сиреневыми кружками) в системе расчетных банков.

[7] Ресурсом в данном случае является не счет, а запись с авторизационным лимитом.

[8] Для краткости далее будем обозначать ОР уровня N как ОР-N.

[9] Теоретически каждому ОР-2 может быть выделено несколько "логических" адресов, которые должны указывать на один и тот же "физический" (например, сетевой) адрес. Использование более одного "логического" адреса может оказаться полезным в случаях, когда на НРР помимо задачи идентификации ресурса возлагается задача его классификации (например, указание на тип продукта, задание логики обработки и т.п.).

[10] Используются произвольные значения.

[11] Ведущие нули во внутреннем идентификаторе счета исключены для сокращения длины НРР.

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

Читайте также:

Центральный банк Республики Узбекистан: «Акцент на реформы и модернизацию»