рне шахрайство.
Якщо клієнт не зміг передати платіжне доручення в електронній формі через неполадки власного комп'ютера, всі збитки, що виникають у зв'язку з цим, він повинен нести сам. Природно, в договорі з банком для цього випадку повинна бути передбачена можливість скасування на певний термін (наприклад, на термін ремонту комп'ютера) електронної передачі і заміни її звичайним паперовим документообігом або орендою комплектом техніки у банку. Якщо клієнт не зміг передати платіжне доручення в електронній формі через неполадки в комп'ютерній мережі банку (тобто банк не зміг прийняти платіжне доручення клієнта), збитки за це повинні покладатися на банк.
Аналогічний підхід застосовний і до випадку, коли розрахункова операція не могла бути своєчасно здійснена в результаті збою в комп'ютерній мережі кореспондента банку-платника. Останній повинен відшкодувати своєму клієнтові виникли в результаті цього збитки, а потім вправі стягнути сплачене у порядку регресу зі свого кореспондента. З метою уникнути в таких випадках збільшення розміру збитків, договори про електронні платежі повинні також передбачати можливість заміни електронного документа паперовим. А механізм стягнення збитків повинен бути за погодженням сторін максимально спрощений.
Ще однією причиною помилок у процесі електронного переказу коштів можуть стати недоліки використовуваного програмного забезпечення. Одним з можливих шляхів підвищення якості програмного забезпечення могло б стати введення обов'язкової державної сертифікації на весь програмний комплекс.
Недоліки програмного забезпечення можуть призвести до неможливості зашифрувати (Розшифрувати) інформацію про платежі; до того, що ЕЦП однієї зі сторін помилково буде сприйматися програмою перевірки як фальшива; до появи можливості підробки ЕЦП тощо
Логіка підказує, що всі виникаючі в результаті цього збитки треба покладати на організацію - розробника програмного забезпечення. Однак для цього необхідно, по перше, довести, що саме недоліки програмного забезпечення стали причиною появи збитків, а по друге, мати відповідні правові підстави для пред'явлення позову до розробника (наприклад, договір з ним).
На даної проблеми має сенс зупинитися докладніше. Претензії до розробника можна пред'явити в рамках норм Закону В«Про захист прав споживачівВ», який діє в даний час в редакції Федерального закону від 09.01.96 № 2-ФЗ. Однак для визнання у програмного забезпечення як у товару істотного недоліку необхідно проведення експертизи, що потребують суттєвих грошових коштів, наявності кваліфікованих експертів і певного часу, а також підготовленості суддів, які в змозі були б розглянути такий позов і прийняти по ньому об'єктивне рішення. Слід визнати, що вітчизняна правоохоронна система до проведення подібних заходів поки не підготовлена. Перш за все слід розпочати з формування експертної бази, причому вона повинна бути незалежною і від розробників і від банків.
Поки ж, якщо в процесі здійснення електронних розрахунків ЕЦП одою зі сторін буде сприйматися іншою стороною як фальшива, для розгляду виниклого конфлікту утворюється погоджувальна комісія з представників сторін спору і розробника програмного забезпечення (наприклад, в пакеті документації до СКЗИ В«Верба-ОВ» мається методика проведення таких перевірок за участю розробника). При перевірці документа з фальшивою цифровим підписом погоджувальна комісія повинна спочатку перевірити цілісність програмного забезпечення у кожної з сторін договору, а потім - справжність підписів під спірним документом.
Проблема залучення виготовлювача програмного забезпечення до відповідальності вирішується в укладаються на практиці договорах по різному. Може бути передбачено, наприклад, що при виникненні у банку або клієнта збитків через недоліки програмного забезпечення банк зобов'язаний пред'явити позов до розробника. Це юридично цілком обгрунтовано: для того, щоб організувати розрахунки в електронній формі банк повинен укласти з розробником відповідний договір, який дає банку право, по-перше, самому користуватися програмою, по-друге, поширювати її серед своїх клієнтів, включаються в електронний документообіг, а по-третє, пред'являти розробнику відповідні претензії. У цій ситуації у клієнта немає прямого договору з виробником програми, тому він не в змозі сам пред'явити до нього позов. Зате клієнт має право стягнути виникли у нього збитки з банку, який в порядку регресу повертає сплачені ним суми з організації - розробника програмного забезпечення.
Необхідно особливо розглянути принципи розподілу збитків, що виникли в результаті комп'ютерного шахрайства при нез'ясованих обставинах. Справа в тому, що будь-яке програмне забезпечення незалежно від виду та ступеня захисту, може бути змінено кваліфікованим фахівцями та використано у протиправних цілях. На сьогоднішній день не існує абсолютно надійних способів захисту від несанкціо...
