Результат интеллектуальной деятельности: Автоматизированная система независимого подтверждения транзакций

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

Предложенная автоматизированная система независимого подтверждения транзакций (далее «СНПТ») используется как отдельный сервис и предназначен для подтверждения того, что документ был (1) отправлен в банк и/или (2) был принят банком именно в том виде, в каком был сформирован в автоматизированной информационной системе планирования ресурсов предприятия, которая обеспечивает управление казначейскими операциями, платежным процессом и обменом с банками (далее «ERP-система»), и отправлен клиентом в банк или сформирован в автоматизированной банковской системе (далее «АБС») банка и отправлен клиенту. СНПТ способна подтверждать любые электронные документы - выписки, платежные поручения, документы валютного контроля, письма из банка и т.п.

Известны способ и устройство для подтверждения транзакций [RU 2417444, C1, G06Q 20/00, 27.04.2011], согласно которым устройство управления отсылает сообщения запроса, содержащее данные транзакции мобильному устройству, которое может отправлять устройству управления сообщение подтверждения, содержащее код подтверждения, причем, устройство управления и/или мобильное устройство содержат одно или более цифровых запоминающих устройств, в котором хранят приложение безопасности для шифрования и создания цифровой подписи в сообщении запроса и/или в сообщении подтверждения, соответственно, перед их отправкой.

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

Известен также способ для выполнения защищенной электронной транзакции [RU 2397540, C1, G06F 21/20, 20.08.2010], при осуществлении которого пользователь аутентифицирует себя перед портативным носителем данных, причем, портативный носитель данных передает в терминал подтверждение аутентификации, а затем в ходе электронной транзакции формирует и передает в терминал гарантирующее аутентичность пользователя сообщение, причем, портативный носитель данных формирует информацию о качестве аутентификации, указывающую метод аутентификации, использованный для аутентификации пользователя, когда один тип информации о качестве аутентификации указывает на биометрический метод аутентификации, а другой тип информации о качестве аутентификации указывает на метод аутентификации, основанный на знании определенной информации, указанную информацию о качестве аутентификации добавляют в гарантирующее аутентичность пользователя сообщение и учитывают при совершении электронной транзакции.

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

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

Наиболее близкой по технической сущности и выполняемым функциям к предложенной является автоматическая система для проверки согласия стороны, имеющей полномочия на совершение транзакции, на совершение транзакции стороной, инициирующей транзакцию [RU 2388053, C1, G06Q 20/00, 27.04.2010], включающая первую базу данных, имеющую возможность накопления сведений о транзакции, включающих в себя идентификатор стороны, инициирующей транзакцию, хранилище данных, включающее в себя первую базу данных и, по меньшей мере, одну вторую базу данных и размещенные в ней предварительно заданные связанные между собой идентификатор стороны, инициирующей транзакцию, и абонентский адрес абонентского устройства стороны, имеющей полномочия на совершение транзакции, по меньшей мере, одно абонентское устройство автоматически коммутируемой телефонной сети, имеющее возможность установки соединения с абонентским устройством стороны, имеющей полномочия на совершение транзакции, передачи абонентского номера вызывающего абонента и приема сигнала отбоя и ответа, причем, упомянутый абонентский номер соответствует абонентскому устройству стороны, проверяющей транзакцию, и абонентское устройство стороны, имеющей полномочия на совершение транзакции, имеет средство сообщения сведений о вызывающем абоненте и отправки сигнала отбоя и сигнала ответа, по меньшей мере, одно устройство считывания идентификатора стороны, инициирующей транзакцию, и средство цифровой обработки транзакций, соединенное с устройством считывания идентификатора стороны, инициирующей транзакцию, и включающее в себя упомянутое хранилище данных и упомянутое абонентское устройство автоматически коммутируемой телефонной сети, причем, упомянутое средство цифровой обработки транзакций имеет возможность с помощью упомянутого хранилища данных накапливать сведения о транзакции в упомянутой первой базе данных и определять абонентский адрес стороны, имеющей полномочия на совершение транзакции, по идентификатору стороны, инициирующей транзакцию, и возможность с помощью упомянутого абонентского устройства сети автоматически коммутируемой телефонной сети инициировать соединение с абонентским устройством стороны, имеющей полномочия на совершение транзакции, передавать абонентский адрес вызывающего абонента и принимать сигнал отбоя и сигнал ответа, а абонентское устройство стороны, имеющей полномочия на совершение транзакции, включает в себя средство сообщения сведений о вызывающем абоненте и имеет возможность отправки сигнала отбоя и сигнала ответа.

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

- взлом ERP-системы клиента может привести к подмене банковских реквизитов (влияние фактора ограничивается возможностями конкретного вида используемой ERP-системы);

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

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

- ответственность за всю информацию, которая загружается в клиент-банк, несет клиент;

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

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

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

- не сохраняется лог выгрузки и загрузки данных между ERP-системой в клиент-банком;

- не обеспечивается шифрование канала передачи данных между ERP-системой в клиент-банком.

- передача документов в систему на стороне клиента иногда производится в неподписанном виде, что создает риск подмены данных после их выгрузки из ERP-системы клиента из-за внутреннего человеческого фактора;

- иногда, требуется конвертация документов в формат системы электронного документооборота, в процессе которого может быть осуществлена конвертация, которая искажает содержание документа;

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

- как правило, система не отвечает за возможную потерю или искажение информации, которая передается по каналу обмена;

- не обеспечивается шифрование канала передачи данных между ERP-системой в систему электронного документооборота.

- взлом ERP-системы клиента может привести к подмене банковских реквизитов (влияние фактора ограничивается возможностями конкретного вида используемой ERP-системы);

- банк не несет ответственности за возможные риски модификации или подмены файла с документов поле его выгрузки из ERP-системы клиента и до поступления в банк;

- процесс передачи (выгрузки и загрузки) платежей из ERP-системы в индивидуальный шлюз host-to-host производится через файл, размещенный на сервере или сетевом диске клиента, что создает возможность его подмены или модификации;

- как правило, система не отвечает за возможную потерю или искажение информации, которая передается по каналу обмена;

- как правило, не обеспечивается шифрование канала передачи данных из ERP-системы в индивидуальный шлюз host-to-host.

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

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

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

На чертеже представлены:

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

на фиг. 2 - функциональная схема блока конвертации и верификации;

на фиг. 3 - функциональная схема блока управления казначейскими операциями клиента;

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

на фиг. 5 - функциональная схема блока управления банковскими операциями корпорации;

на фиг. 6 - функциональная схема блока управления операциями банка;

на фиг. 7 - функциональная схема блока формирования и отправки платежей клиента;

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

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

Автоматизированная система независимого подтверждения транзакций (фиг. 1) содержит также блок 5 обновления данных между базами, первый и второй входы-выходы которого соединены с седьмым и восьмым входами-выходами первого блока 3 подтверждения транзакций, соответственно, блок 6 управления операциями банка, первый и второй входы-выходы которого соединены с пятым и шестым входами-выходами блока 4 управления банковскими операциями корпорации, соответственно, блок 7 формирования и отправки платежей клиента, первый вход-выход которого соединен с девятым входом-выходом блока 2 управления казначейскими операциями клиента, а второй вход-выход соединен с третьим входом-выходом блока 6 управления операциями банка, а также второй блок 8 подтверждения транзакций, первый и второй входы-выходы которого соединены с третьим и четвертым входами-выходами блока 5 обновления данных между базами, а третий, четвертый, пятый, шестой и седьмой входы-выходы которого соединены с четвертым, пятым, шестым, седьмым и восьмым входами-выходами блока 6 управления операциями банка, соответственно.

Блок 1 конвертации и верификации (фиг. 2) содержит блок 9 запросов на конвертацию данных из ERP в стороннее приложение, блок 10 конвертации платежных документов в формат банка в стороннее приложение, блок 11 хранения файлов с платежным документом в формате банка, блок загрузки в ERP платежных документов в формате банка в сконвертированном формате, блок верификации заполнения полей документа.

Блок 2 управления казначейскими операциями клиента (фиг. 3) содержит блок 14 передачи платежных документов для оплаты, блок 15 передачи платежных документов для конвертации в формат банка, блок 16 конвертации платежных документов в формат банка в самой ERP системе, блок 17 выгрузки платежей для поверки соответствия, блок 18 подтверждения готовности документа к оплате, блок 19 подписания платежного документа, блок 20 хранения файлов с платежными документами в формате банка, блок 21 загрузки в ERP-систему проведенной выписки банка, блок 22 выгрузки платежей в клиент-банк.

Первый блок 3 подтверждения транзакций (фиг. 4) содержит блок 23 акцента или отклонения документа из банка, блок 24 сверки хеша в базе с рассчитанным из платежного документа, блок 25 расчета хеша для подтверждения и сверки с данными базы, блок 26 присвоения ID дайджеста документа (ДД), блок 27 расчета хеша на основании ДД и ID транзакции, блок 28 записи транзакции в СНТП, блок 29 СНТП (блокчейн), блок 30 возврата ID ДД в ERP для акцепта в банке, блок 31 проверки соответствия сконвертированных документов, загруженных ранее из ERP, блок 32 отправки статуса соответствия документов.

Блок 4 управления банковскими операциями корпорации (фиг. 5) содержит блок 33 СНТП (блокчейн), блок 34 дополнительной проверки документов перед отправкой, блок 35 отправки документа в банк, блок 36 передачи в СНТП дайджеста документа и ID ДД, блок 37 передачи платежного документа через шлюз (host-to-host), блок 38 загрузки выписки из банка с ID ДД.

Блока 6 управления операциями банка (фиг. 6) содержит блок 39 загрузки платежного документа в банк, блок 40 проверки корректности подписи на платежном документе, блок 41 проверки платежного документа на заполнение полей, блок 42 запроса акцепта платежа в СНТП, блок 43 передачи платежного документа через клиент-банк, блок 44 передачи в СНТП дайджеста платежа и ID ДД, блок 45 поучения ответа о возможности исполнения платежа акцепт-отказ, блок 46 отказа от исполнения документа, блок 47 акцепта платежного документа банка, блок 48 формирования и отправки клиенту статуса обработки платежного документа, блок 49 формирования выписки, блок 50 отправки выписки клиенты с ID ДД.

Блок 7 формирования и отправки платежей клиента (фиг. 7) содержит блок 51 загрузки платежных поручений в клиент-банк, блок 52 подписания и отправки платежей.

Второй блок 8 подтверждения транзакций (фиг. 8) содержит базу 53 данных СНТП, блок 54 расчета хеша для подтверждения и сверки данными базы, блок 55 акцепта или отклонения документа, блок 56 сверки хеша в базе с рассчитанным из платежного документа, блок 57 присвоения ID дайджеста документа, блок 58 расчета хеша на основании ДД документа и ID транзакции, блок 59 записи транзакции в СНТП, блок 60 возврата ID ДД в АБС банка для акцепта клиента.

Автоматизированная система независимого подтверждения транзакций используется следующим образом.

Все элементы блоков 1-8 выполняют функции, отраженные в их названиях.

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

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

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

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

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

Отправка документа из ERP-системы.

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

Получение документа банком.

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

Для этого после того, как документ будет зарегистрирован в АБС банка, на одном из этапов проверки АБС обращается к СНПТ, передавая ей идентификатор документа и ДД.

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

Дайджест документа и формирование хеша дайджеста документа.

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

ERP-система передает ДД:

<PmtRub>

<PmtInfNm>Клиент 1 </PmtInfNm>

<PmtInfOrgId>7724792919</PmtInfOrgId>

<PmtInfDbtrAcct>407028118222110700814</PmtInfDbtrAcct>

<PmtInfFinInstnId>044525593</PmtInfFinInstnId>

<PmtInfFinInstnIdNm>Банк</PmtInfFinInstnIdNm>

<PmtInfInstdAmt>88000.0000</PmtInflnstdAmt>

<PmtInfRltdDt>09.06.2018</PmtInfRltdDt>

</PmtRub>

СНПТ создает идентификатор транзакции (в примере используется произвольный идентификатор транзакции:

77da712a8a0c4f3d9211673931646d7d

Далее на основе данных из ДД и идентификатора транзакции СНПТ создает хеш (в примере используется алгоритм хеширования md5:

md5("Клиент17724792919407028118222110700814044525593Банк88000.0000

09.06.201877da712a8a0c4f3d9211673931646d7d")

Получаем хеш:

03939f856260535c2f9986bfc90fbeab

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

Основа для разработки дайджестов.

Для каждого вида документа использован специальный дайджест, который содержит все реквизиты документа, которые перечислены в "Положении о правилах осуществления перевода денежных средств" (утв. Банком России 19.06.2012 N 383-П) или других нормативных актах.

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