Актуальность использования электронных платежей в банковской практике: анализ зарубежного опыта и возможности его использования в Рос

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

Итак, в современных криптографических  системах, в том числе финансовых, используется так называемая технология "криптографии с открытым ключом". Надежность этой технологии основана на доказуемой эквивалентности задачи "взлома" криптосистемы какой - либо вычислительно сложной задаче. Например, при использовании одного из самых распространенных алгоритмов RSA, каждый участник криптосистемы генерирует два случайных больших простых числа p и q, выбирает число e, меньшее pq и не имеющее общего делителя с (p-1)(q-1), и число d, такое, что (ed-1) делится на (p-1)(q-1). Затем он вычисляет n=pq, а p и q уничтожает.

Пара (n, e) называется "открытым ключом", а пара (n, d) - "закрытым ключом". Открытый ключ передается всем остальным участникам криптосистемы, а закрытый сохраняется в тайне. Стойкость RSA есть функция сложности разложения произведения pq на простые множители p и q (эту задачу придется решать тому, кто вознамерится "вычислить" закрытый ключ из открытого). При достаточной длине этих простых чисел (несколько тысяч двоичных разрядов) такое разложение вычислительно невозможно (т.е. требует ресурсов, недоступных в этом мире).

Для обеспечения конфиденциальности, участник А "шифрует" сообщение m участнику Б с помощью открытого  ключа Б: c := me mod n, а участник Б "расшифровывает его" с помощью своего закрытого ключа: m:= cd mod n. Для наложения "цифровой подписи" участник А "шифрует" сообщение m участнику Б с помощью своего закрытого ключа s := md mod n, и отправляет "подпись" s вместе с сообщением m. Участник Б может верифицировать подпись участника А с помощью открытого ключа А, проверив равенство.

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

Безопасность выполнения операций телефонного банковского  обслуживания обеспечивается с помощью  процедуры идентификации клиентов по имени и паролю (PIN-коду), который клиент может выбрать и сменить в любой момент с помощью тех же средств телефонного обслуживания. Кроме того, технология телефонного банковского обслуживания концептуально безопасна, поскольку позволяет клиентам инициировать операции, в которых участвуют только счета самого клиента. Даже при выполнении платежей всегда предполагается перечисление денежных сумм с одного из счетов клиента в банке на счет клиента у поставщика услуг (как правило идентифицируемого дополнительными реквизитами клиента). Реальные номера счетов системой не запрашиваются и клиентом не указываются. В системе Back Office, в которой собственно и выполняются операции платежей, всегда производится идентификация клиентских счетов и легальность инициированной клиентом операции платежа. Здесь же после всех проверок выполняется и реальная операция перечисления денежных средств со счета клиента на реальный банковский счет поставщика услуг. Более того, банк для оказания услуг такого рода, как правило, заключает специальные прямые договора с поставщиками услуг. Условиями таких договоров регулируются форматы и регламент передачи данных о платежах от банка к поставщику услуг, правила проверки легальности операций платежей и т.д. На основании таких отношений банка с провайдерами и формируется доступный клиенту список получателей платежей клиента.

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

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

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

Логика подсказывает, что все возникающие в результате этого убытки надо возлагать на организацию – разработчика программного обеспечения. Однако для этого необходимо, во - первых, доказать, что именно недостатки программного обеспечения стали причиной появления убытков, а во - вторых, иметь соответствующие правовые основания для предъявления иска к разработчику (например, договор с ним).

На данной проблеме имеет  смысл остановиться подробнее. Претензии  к разработчику можно предъявить в рамках норм Закона “О защите прав потребителей”, который действует в настоящее время в редакции Федерального закона от 09.01.96 № 2-ФЗ. Однако для признания у программного обеспечения как у товара существенного недостатка необходимо проведение экспертизы, что потребует существенных денежных средств, наличия квалифицированных экспертов и определенного времени, а также подготовленности судей, которые в состоянии были бы рассмотреть такой иск и принять по нему объективное решение. Следует признать, что отечественная правоохранительная система к проведению подобных мероприятий пока не подготовлена. Прежде всего, следует начать с формирования экспертной базы, причем она должна быть независимой и от разработчиков и от банков.

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

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

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

2.2. Достоинства  и недостатки электронных банковских услуг

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

Используя "Клиент-Банк", можно не только оплатить свои счета, но и узнать сальдо, движение по счету, перечень поступлений за день. Важным достоинством использования данной системы является то, что свежую

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

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

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

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

Таблица 1.

Достоинства и  недостатки внедрения системы "клиент-банк"  для банка

Таблица 2.

Достоинства и  недостатки внедрения системы "клиент-банк" для клиента