Раннее я писал, что электронная подпись – это нечто отделённое от лица, которому она принадлежит, и поэтому к её любят передавать сотрудникам, бухгалтерии и т.д., что приводит к ситуации, когда у того же бухгалтера фактически оказываются полномочия, далеко выходящие за пределы должных. Добавьте сюда то обстоятельство, что документ, подписанный электронной подписью лица, является документом, подписанный этим лицом (и это очень сложно оспорить).
Особенно остро эта проблема стоит в сфере закупок.
Поэтому был предложен механизм машиночитаемых доверенностей (МЧД). Редкий случай, когда имеется в виду именно то, что подразумевается исходя из названия: доверенность, которую можно прочесть машине, XML. Изначально это практически исключительно штука для руководителей организаций, но со временем её функции решили расширить.
Новый закон предусматривает возможность подписания служебных документов той же подписью, что и личной, при условии выданной этому лицу МЧД, которая содержит информацию о доверенном ФЛ, ЮЛ-доверителе, и конкретном ФЛ, которое выдало доверенность, а также о типе операции, которую может выполнить такое лицо.
При этом в одной МЧД можно указать несколько полномочий, одну МЧД можно выдать на несколько сотрудников полномочия могут быть передоверены другому лицу в рамках передоверия. Задумка, в принципе, блестящая.
Но в информационных системах меняется сама процедура подписания электронных документов. Если раньше нужно было проверять только электронную подпись, теперь необходимо также проверять на валидность и МЧД, учитывая гибкость системы, это подразумевает проверку электронных подписей, которые включены в МЧД, срока действия доверенности, а также удостоверение полномочий на совершение определённого действия.
Для автоматизированных систем проблема стала несколько жёстче, потому что всё это нужно сделать, разумеется, автоматически. Благо есть коды полномочий.
Конечно же, законодателем было введено слишком большое число переменных, вся система оказалась дырявой, сырой и забагованной, в итоге переходный период был продлён до конца августа 2024 г., хотя запустить её в обязательном порядке пытались ещё в прошлом году. Не знаю, что получится позже, будем смотреть, конечно.
Реестр МЧД ведёт ФНС. Занятно, что это почему-то блокчейн хранилище. Я сам понятия не имею, зачем нужен распределённый реестр блокчейн, если есть вполне определённый центральный реестродержатель.
Но это реестр, а ещё есть хранилища МЧД разных ведомств, которые пока не централизованы и у каждого ведомства на данный момент своё. Конечно, разговоры о создании единого хранилища уже ведутся, но нам пока не сильно легче. В любом случае, создать МЧД могут в любом сервисе с нужным функционалом (да и руками это можно сделать), и направить её можно вместе с электронными документами.
Насколько досконально теперь нужно проверять доверенности:
1. De jure никакого нового правового регулирования понятия "доверенность" не создаётся. Законодатель просто ввёл и постарался отрегулировать новую систему, позволяющую уполномочивать сотрудников посредством стандартизированной электронной доверенности.
2. Проверка полномочий неких людей на совершение определённых действий, конечно, должна быть, но представительство при отсутствии на то должных полномочий – это не обязательно головная боль лица, к которому обращается мнимый представитель. Главное, что необходимо доказать для лица, к которому обратился представитель – это т.н. видимость правомочия или полномочия из обстановки (подробнее об этом в другой статье). А уже отсутствие полномочий на представительство (совершение сделки под чужим именем) подтверждается лицом, которое ложно представили.
3. Таким образом, с вас как владельца ИТ-системы могут спросить, озаботились ли вы налаживанием подключения к системам, хранящим доверенности, к реестру ФНС и т.д.
4. Теоретически, если сбой произошёл на стороне ФНС или хранилища, вина лежит не на АС. Мы по идее приходим к тем же нормам о добросовестности и разумности при создании сервиса (здесь об одно интересном немецком деле).
Такие дела.
