Счёт выглядит привычно: тот же поставщик, тот же логотип, похожая сумма. Изменился только расчётный счёт. Именно такое изменение я бы считал отдельным событием, а не обычным распознанным полем.
Подмена банковских реквизитов в счёте опасна тем, что OCR может извлечь значение совершенно правильно. Ошибка возникает позже: система принимает новое значение как доверенное только потому, что оно напечатано в документе.
Для меня достаточного основания здесь нет. Перед оплатой нужно понять, совпадают ли реквизиты с master-data контрагента, кто сообщил об изменении и каким независимым способом оно подтверждено.
OCR подтверждает символы, но не принадлежность счёта
Распознавание может уверенно вернуть банк, БИК, расчётный счёт и получателя. Это доказывает только то, что такие данные присутствуют в файле.
Я бы сохранял extracted value вместе с координатами или фрагментом исходника, а затем сравнивал его с текущими доверенными реквизитами карточки контрагента. Совпадение получает обычный статус. Расхождение — отдельный exception.
BEC-сценарии часто строятся вокруг подмены платёжных инструкций или переписки. CISA и FBI отдельно предупреждают о мошенничестве через business email compromise.
Проверяемые источники: CISA — Business Email Compromise Continues to Swindle and Defraud U.S. Businesses · FBI IC3 — Business Email Compromise (BEC)
Смена реквизитов должна иметь собственный статус
Я бы не ограничивался красной подсветкой поля. Документ получает состояние `bank_details_changed`, а проведение или платёж блокируется до отдельного решения.
В статусе сохраняются прежние реквизиты, новые распознанные значения, источник файла и найденные различия. Тогда сотрудник проверяет конкретное изменение, а не перечитывает весь счёт.
После подтверждения новые реквизиты нельзя молча записывать в master-data, если у компании для этого существует отдельный процесс изменения карточки контрагента.
Проверяемые источники: FBI IC3 — Business Email Compromise: The $50 Billion Scam
Подтверждать изменение через то же письмо бессмысленно
Если подозрительный счёт пришёл по email, ответить на этот же email вопросом «вы точно сменили счёт?» недостаточно. При компрометации переписки злоумышленник контролирует тот же канал.
Я бы использовал независимый контакт: известный телефон, карточку поставщика, отдельный корпоративный процесс или подтверждение уполномоченного сотрудника. В журнале фиксируется способ проверки.
FBI рекомендует независимо проверять запросы на изменение банковских данных и платёжных инструкций. Для автоматизации это должен быть явный control point.
Проверяемые источники: FBI IC3 — Business Email Compromise (BEC) · FBI IC3 — Business Email Compromise: The $50 Billion Scam
Сравнивать нужно больше одного поля
Совпавшее название получателя само по себе слабое доказательство. Я бы сравнивал набор: контрагент, банк, БИК, счёт, корреспондентский счёт и другие реквизиты, которые использует ваш платёжный процесс.
Изменение только одного элемента всё равно требует объяснения. Если одновременно изменились несколько полей, это не делает документ автоматически подозрительным сильнее или слабее; важно, существует ли подтверждённая запись об изменении.
Нормализация формата полезна для сравнения, но исходную строку документа нужно сохранять рядом.
Проверяемые источники: CISA — Business Email Compromise Continues to Swindle and Defraud U.S. Businesses
История реквизитов помогает проверке, но не заменяет её
У поставщика действительно может измениться банк. Поэтому простое правило «новый счёт запрещён» создаст много ручных исключений.
Я бы хранил версии доверенных реквизитов с датой действия и основанием изменения. Тогда система видит, что новый счёт уже был официально подтверждён вчера, либо впервые появился только в текущем PDF.
Такая история полезна и для расследования: можно восстановить, какая версия master-data использовалась при конкретной оплате.
Проверяемые источники: CISA — Secure Your Business
Оплата разрешается только после подтверждённого основания
Definition of Done здесь простой: документ распознан, контрагент найден, банковские реквизиты совпали с доверенными либо изменение подтверждено независимым каналом, решение записано в audit trail.
Если подтверждения нет, счёт остаётся в исключении. Уверенность OCR, похожий шаблон и привычная сумма не должны заменять этот статус.
Я бы считал такой контроль готовым, когда по каждой оплате можно ответить: какие реквизиты использованы, с какой доверенной версией они сверялись и кто подтвердил изменение.
Проверяемые источники: FBI IC3 — Business Email Compromise (BEC) · FBI IC3 — Business Email Compromise: The $50 Billion Scam
Новый поставщик и смена реквизитов — разные события
При первом счёте у компании ещё нет доверенной истории. Это не значит, что реквизиты можно принять автоматически. Просто проверка строится иначе: onboarding контрагента, договор, официальный справочник и внутреннее одобрение.
Я бы явно различал `new_counterparty_details` и `changed_existing_details`. Для второго есть историческое значение, для первого — процесс первичного подтверждения.
Так контроль не превращается в правило, которое работает только со старыми поставщиками и молча доверяет новым.
Проверяемые источники: FBI IC3 — Business Email Compromise (BEC) · CISA — Secure Your Business
Контрольные вопросы перед внедрением
Как автоматически заметить подмену реквизитов в счёте?
Извлечь банковские поля из документа и сравнить их с доверенными master-data контрагента. Любое значимое расхождение должно создавать отдельный статус и блокировать оплату до проверки.
Можно ли подтвердить новые реквизиты ответом на письмо поставщика?
Если изменение пришло по email, лучше использовать независимый известный канал. При компрометации почты ответ может получить тот же злоумышленник.
Нужно ли автоматически обновлять карточку поставщика после подтверждения?
Только если это соответствует вашему процессу управления master-data. Я бы сохранял отдельное основание изменения и версию реквизитов, а не связывал обновление карточки с одним счётом автоматически.
Я не считаю новый расчётный счёт ошибкой сам по себе. Но до оплаты он должен иметь доказанное основание. Если система умеет показать исходник, прежнее значение, новое значение и независимое подтверждение, следующий шаг проверяем. Без этой цепочки красивое распознавание ничего не гарантирует.
Для соседних проверок пригодятся для «подмена реквизитов в счёте»: Как автоматически извлекать данные из счетов, актов и договоров · Как в 1С найти дубли документов до повторного проведения счёта · Как настроить роли и права доступа в автоматизации документов.