Удобное подписание группы платёжных поручений

Почему этот сценарий особенно важен

Часто пользователи систем ДБО создают в течение дня группу платёжных поручений (от нескольких десятков до нескольких сотен) и в конце дня запускают процесс подписания и отправки на исполнение всех платёжных поручений одновременно. При использовании Trust Screen-устройства по умолчанию возникает необходимость подтверждать каждое платёжное поручение на этом устройстве. Если платёжных поручений будет много, то такая операция будет создавать дискомфорт в работе для пользователей.

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

1. Сводное платёжное поручение в адрес всех контрагентов, попавших в “белый список”.
2. Каждое платёжное поручение в адрес контрагентов, не попавших в “белый список”.

Сводное платёжное поручение может содержать:

• общую сумму платежа в адрес получателей из “белого списка”;
• число таких получателей или их список.

Подтверждение такого сводного платёжного поручения позволяет защититься от атак, направленных на опустошение счёта компании в пользу доверенных контрагентов (например, в налоговую).

Защищенный сценарий в этом случае предусматривает следующий порядок действий

Исходные данные

• Пользователь ввёл PIN-код для используемого средства ЭП и авторизовался в личном кабинете.
• На сервере хранится подготовленный заранее “белый список” доверенных контрагентов для данного пользователя.

Пользователь

• Создает группу платёжных поручений и сохраняет их на сервере ДБО.
• Инициирует операцию подписания группы платёжных поручений.

Прикладное ПО на стороне сервера

“Пробегает” по всем платёжных поручениям из группы и разделяет их на 2 подгруппы:

• получатели которых попали в “белый список”;
• получатели которых не попали в “белый список”.

Далее для тех платёжных поручений, получатели которых не попали в “белый список”, прикладное ПО последовательно для каждого из них выполняет действия согласно сценарию Подписание платёжного поручения в системе ДБО.

Далее для тех платёжных поручений, получатели которых попали в “белый список”, прикладное ПО:

• подписывает каждое из этих платёжных поручений на средстве ЭП пользователя;

• запрашивает на Антифрод-терминале подтвердить сводную информацию обо всех платежных поручениях, попавших в “белый список”, например:

  1. общую сумму платежа в адрес получателей из “белого списка”;
  2. число таких получателей или их список.
  

Примечание

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

1. Пользователь сначала подтверждает последовательно ключевые реквизиты платёжных поручений на Антифрод-терминале.
2. После подтверждения / отклонения пользователем ключевых реквизитов всех платежных поручений, которые выводились на Антифрод-терминал, прикладное ПО конкатенирует сами поручения в один документ (массив данных) и подписывает их на средстве ЭП одной подписью как единый документ.

Результат этого сценария:

1. На сервере сохранены подписи всех подтвержденных платежных поручений.
2. Для тех платёжных поручений, получатели которых не попали в “белый список” и которые пользователь подтвердил на Антифрод-терминале, на сервере должны быть сохранены:
   • подписанные журналы операций терминала для каждого такого платёжного поручения.
3. Для тех платёжных поручений, получатели которых попали в “белый список”, на сервере должны быть сохранены:
   • подписанный журнал операций терминала для сводной информации обо всех платежных поручениях, попавших в “белый список”.
4. Если пользователь отклонил какое-то платёжное поручение, Антифрод-терминал не будет формировать для этого поручения журнал операций. Прикладное ПО также не должно формировать для него подпись. На сервере следует указать статус – отклонено пользователем при подтверждении.