Как бизнесу взаимодействовать с банком наиболее эффективно и безопасно? На рубеже веков возникло такое понятие, как дистанционное банковское обслуживание (ДБО) — совокупность услуг, которые банк предоставляет клиентам для удаленного выполнения банковских операций. Данное явление начало развиваться в США, где в конце 20 века Security First Network Bank первым стал предоставлять услуги удаленно посредством интернета, причем у банка вовсе не было физического офиса, куда могли бы обращаться клиенты. Впоследствии, когда явление получило более широкое распространение, появился термин branchless bank (банк без филиала), т. е. банк, существующий только в сети. Экономия, связанная с обслуживаем физических отделений, позволила банкам предлагать более выгодные процентные ставки и условия обслуживания.

Сегодня понятие ДБО ассоциируется с термином клиент-банк. Принято выделять два вида клиент-банков:

• классический, или же толстый клиент, представляющий собой отдельно устанавливаемое на компьютер приложение,
• тонкий, или интернет-клиент, предоставляющий возможность работать через браузер.

Именно клиент-банк стал ключевым звеном при обмене документами между бизнесом и банком. Интерфейс клиент-банка позволил унифицировать формат работы учетных систем с банками через загрузку и выгрузку специальных файлов, содержащих информацию о платеже. Однако и есть и проблема: клиент-банк живет независимо от учетной системы компании-пользователя. Отсюда — потребность в средствах интеграции и криптозащиты, применение которых привело к следующему эволюционному скачку взаимодействия бизнеса с банком — а именно, Host-to-Host (H2H) технологиям. Технология особенно востребована в тех случаях, когда бизнесу необходимо иметь дело с несколькими банковскими система, валютами, платежными документами. Обмен через файл становится слишком трудозатратным и сложным с ростом бизнеса и числа обслуживающих банков.

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

При этом утверждать, что технология H2H представляет собой единый стандартизированный интеграционный механизм или конкретное решение, нельзя. Это скорее класс решений, который позволяет настроить взаимодействие с банком и определяет формат такого взаимодействия.

Технология H2H помогает установить связь между системой банка и учетной системой организации (ERP, Treasury Management System и др.). Эта связь является частным защищенным каналом обмена сообщениями с банком, который включает шифрование, цифровые подписи.

Такой обмен может выполнять следующие функции:

• получение выписки по счету,
• получение отчетов по балансу,
• проведение оплат,
• отправка платежных поручений на подписание в клиент-банк,
• оплата по зарплатным проектам.

Процесс проведения платежей через клиент-банк характеризуется следующими аспектами.

• Длительность обработки платежей

Процесс выгрузки платежных документов из учетной системы в клиент-банк организован таким образом, что, как правило, невозможно сформировать единый файл одновременно по всем банкам. Платежи нужно предварительно сгруппировать по банкам, расчетным счетам и форматам обмена, после чего сформировать отдельные файлы, например txt, xml. При работе с одним банком трудоемкость процесса остается относительно невысокой. Однако с увеличением количества банков возрастает количество операций, что приводит к кратному увеличению времени обработки платежей.

• Зависимость от человеческого фактора

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

• Лаг обратной связи о результатах оплаты

При файловом обмене информация о статусе платежа не поступает в учетную систему автоматически, «по кнопке», в режиме реального времени. Сотруднику необходимо отдельно отслеживать исполнение платежей в клиент-банке, а затем выгружать и загружать банковскую выписку в учетную систему также через отдельный файл. Это создает временной разрыв (лаг) между фактическим исполнением платежа банком и его отражением в ERP-системе: в клиент-банке платеж уже может быть исполнен, а в учетной системе он еще не отражен и не учтен при расчете фактических остатков денежных средств. Вследствие, снижается точность оперативного планирования ликвидности. Дополнительная задержка возникает, если файл сформирован, но своевременно не загружен в клиент-банк / ERP-систему.

• Риски потери, искажения и дублирования данных

При работе с обменными файлами возникают риски использования неактуальной версии файла, его ошибочного выбора, повторной загрузки, частичной обработки или изменения данных до импорта в клиент-банк. Даже если файл защищен от редактирования средствами информационных систем, что сегодня можно встретить в решениях фирмы 1C, риск расхождения между данными платежного документа в ERP-системе, содержимым сформированного файла и документом, фактически созданным в клиент-банке, остается на высоком уровне. Следствием могут стать неполная выгрузка платежей, повторная отправка, проведение платежа по устаревшим или некорректным реквизитам.

• Трудности измерения процесса

При отсутствии сквозной интеграции сложнее получать достоверные показатели процесса оплаты. Например, затруднительно определить время между согласованием заявки, формированием платежного поручения, выгрузкой файла, загрузкой в клиент-банк, подписанием и фактическим исполнением платежа. Это ограничивает возможность расчета KPI и других показателей процесса.

• Отсутствие сквозной и ссылочной целостности

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

• Легкость настройки и скорость подключения

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

• Особенности, специфичные для холдингов

Отдельно необходимо подсветить проблему стандартизации и прозрачности процесса оплаты, которая характерна для холдингов. Крупные компании и корпорации, имеющие большое количество дочерних предприятий и филиалов, испытывают определенные трудности в сфере управления финансами, поскольку они постоянно развиваются и расширяют масштабы своей деятельности и зависят от объемов внешних займов. Стоит также учитывать территориальную распределенность дочерних зависимых организаций (ДЗО), которые работают в различных часовых поясах. Кроме того, дочерние предприятия пользуются услугами большого количества банков (или филиалов банков), которые предоставляют им краткосрочные кредиты и депозиты, имеют различные технические форматы и каналы доставки сообщений. Результат — снижение эффективности использования денежных средств, увеличение кассовых разрывов, невозможность стандартизировать процесс, потеря информационной связанности между ДЗО и головной организацией, трудности прогнозирования ликвидности. Подобная ситуация только способствует выбору в пользу H2H обмена.

Влияние H2H обмена можно отследить в трех направлениях: управленческом, процессном и техническом.

1. Управленческие последствия внедрения H2H обмена

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

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

2. Изменение бизнес-процессов в результате применения H2H

Бизнес‑процессы меняются не только с точки зрения управляемости — меняется и их структура.

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

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

3. Изменения технического взаимодействия

H2H обмен предлагает качественно новый подход к передаче данных. При классическом клиент-банке точкой взаимодействия банка и клиента становился файл формата txt, xml, формируемый вручную пользователем. H2H делает взаимодействие более комплексным и защищенным.

На схеме показано общее взаимодействие с двумя возможными протоколами обмена: криптографическим протоколом SSL/TLS (Secure Sockets Layer / Transport Layer Security) и протоколом безопасной передачи файлов SFTP (SSH File Transfer Protocol), работающим поверх SSH. SSL/TLS обеспечивает конфиденциальность, целостность и аутентификацию канала связи. Протокол использует комбинацию асимметричного и симметричного шифрования: на этапе рукопожатия (взаимодействия) стороны аутентифицируются и согласуют сеансовый ключ, после чего весь трафик шифруется симметричным алгоритмом.

Данный протокол позволяет выстроить процесс следующим образом:

1. Сервер пытается подключиться к веб-сайту (веб-серверу), защищенному с помощью SSL, и запрашивает идентификацию у веб-сервера.
2. В ответ веб-сервер отправляет серверу копию своего SSL-сертификата.
3. Сервер проверяет достоверность сертификата. О результате успешной проверки отправляет сигнал обратно к веб-серверу.
4. Веб-сервер возвращает подтверждение с цифровой подписью и начинает сеанс, зашифрованный с использованием SSL.
5. Зашифрованные данные используются совместно сервером и веб-сервером.

Протокол SFTP отвечает за передачу файлов, работающий поверх SSH, и включает в себя аутентификацию, команды и передачу данных в одном зашифрованном потоке.

В целом можно выделить два варианта обмена на уровне API (Application Programming Interface):

• взаимодействие с веб-сервисами банка из системы напрямую (технология H2H встроена в решение и доступна для применения после настройки),
• взаимодействие с банком через внешнюю компоненту (внешняя компонента может поставляться банком или сторонним интегратором).

Если H2H решение встроено в учетную систему то, как правило, доступно два способа подключения:

• подключение с применением электронной подписи (ЭЦП),
• подключение по логину, паролю и одноразовому паролю.

В случае внешнего модуля все зависит от банка.

Таким образом, единый стандарт H2H взаимодействия, применимый для всех банков и систем, отсутствует. Банки самостоятельно определяют формат и регламент обмена, перечень доступных операций, требования к аутентификации и подписанию документов, а также механизмы расширения функциональности. Со стороны клиента это обычно предполагает заключение дополнительных соглашений, настройку технического подключения и адаптацию системы к требованиям банка.

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

Согласно результатам исследований в области рисков внедрения информационных систем, к таковым можно отнести:

• частые технические трудности (сбои, ошибки, задержки платежей) из-за недостаточной компетенции сотрудников в области информационной защиты, API и криптографии,
• отсутствие аналитической поддержки пользователей по тем же причинам, ведущее к негативному отношению к H2H, проблемам с адаптацией и обучением, разрывам кроссфункциональных коммуникаций,
• сопротивление организационным и техническим нововведениям со стороны пользователей, что может стать следствием плохой технической подготовки, информированности, скорости и качества решения инцидентов, повышением ответственности без материального или иного стимулирования,
• отсутствие четкой цели, показателей их выполнения и запланированного объема работ,
• менее вероятными, но также значимыми являются юридические риски, связанные с нарушением условий договоров и лицензионных соглашений, а также с изменениями законодательства РФ.

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

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

Для комплексной оценки целесообразности внедрения H2H обмена необходимо оценить возможные риски, проанализировать эффект, который будет зависеть от размеров предприятия и оборота, и сопоставить его с классическим файловым обменом.

Фирма «1C» предоставляет широкий спектр программных продуктов как для учета, так и для планирования. При этом компания пытается выстроить целую экосистему вокруг своей продукции, не только внедряя ПО, но и предоставляя пакет сервисов для бизнеса. Обмен с банком через H2H как раз и является таким сервисом.

Среди H2H решений на рынке российского программного обеспечения «1C» остается лидером по узнаваемости, т. к. встроенный в конфигурации механизм обмена «1C:DirectBank» упоминается в сфере банковского обслуживания чаще других. Например, если взять десять крупнейших банков в России по мнению издательства «Коммерсантъ» по состоянию на 2024 год, на сайте практически каждого из них присутствует упоминание о взаимодействии с системой 1C посредством сервиса «1C:DirectBank».

В рамках взаимодействия 1C и банка сервис «1C:DirectBank» может оказывать до 14 услуг (совокупность доступной функциональности определяется банком):

• подписание платежек в 1C,
• отправка платежек на подпись в банк,
• отзыв ошибочно отправленного документа по специальному запросу,
• платежки в валюте,
• получение выписок в 1C,
• автозагрузка выписки по расписанию,
• зарплатные реестры,
• информация из банка в 1C,
• реестры выплат самозанятым,
• цифровой рубль,
• «1C:ФинОтчетность» (отправка финансовой отчетности в банки и другие организации),
• «1C:Кредит» (поиск кредитных предложений от банков и финансовых организаций),
• «1C:Открытие счета» (открытие расчетных счетов прямо из программы),
• «1C:Депозит» (поиск выгодных предложений, отправка заявки в банк).

Техническая подготовка к подключению сервиса определяется банком. Но, как правило, необходимо использовать для работы инструменты криптографии. Для электронной подписи применяются аппаратные криптопровайдеры со встроенным СКЗИ (средствами криптографической защиты информации), сертифицированным ФСБ РФ, следующих вариантов:

• Рутокен. Относится к аппаратным и программным решениям в области аутентификации, защиты информации и электронной подписи. Устройства Рутокен являются основными ключевыми носителями в массовых российских проектах, базирующихся на технологиях электронной цифровой подписи (ЭЦП) и инфраструктуре открытых ключей (PKI).
• КриптоПро CSP. Этот провайдер позволяет создавать юридически значимую ЭЦП и проверять ее подлинность в соответствии с Федеральным законом № 63-ФЗ «Об электронной подписи». Он обеспечивает безопасность и конфиденциальность при передаче электронных документов с электронной подписью.
• JaCarta. Персональное средство электронной подписи с российской криптографией «на борту» для формирования усиленной квалифицированной электронной подписи с неизвлекаемым ключом и строгой аутентификацией пользователей.

Применение СКЗИ обеспечивает:

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

Сервис от 1С обеспечивает следующие изменения:

• перенос всей работы финансовой службы в единое окно ERP-системы,
• высокую скорость обмена,
• подпись документов в программе 1C без дополнительной подписи в клиент-банке.

Стандарт, на котором построен «1C:DirectBank», является открытым и может применяться любыми разработчиками систем управления и учета. Он строится на базе международного стандарта ISO 20022 для передачи данных. При этом для использования прямого обмена с банком необходимо ввести всего одну общую настройку для всех банковских счетов организации с каждым из банков, которые поддержали эту технологию на своей стороне.

Процесс подключения, как правило, включает четыре этапа.

1. Заключения договора / дополнительного соглашения с банком.
2. Выпуск/перевыпуск ЭЦП.
3. Получение и загрузка в 1C банковских настроек.
4. Настройка маршрута подписания.

Реализация сервиса прямого обмена с банками «1C:DirectBank» способствует формированию экосистемы вокруг платформы 1C. Бизнес получает возможность управлять финансовыми операциями в единой информационной среде и отслеживать актуальное состояние счетов и платежей в режиме, близком к реальному времени.

Подводя итоги рассмотрения технологии H2H, можно с уверенностью говорить о следующих особенностях.

• H2H не имеет единого обязательного формата сообщений.
• Конкретный формат и сценарии зависят от банка, канала связи и реализованного интеграционного решения.
• Для международного и корпоративного банковского обмена значим ISO 20 022, но его реализация определяется национальными регуляторными профилями.
• В экосистеме 1C используется сервис «1C:DirectBank» — прямой обмен с банком по стандарту 1C, поддерживаемый многими крупными банками России.
• Доступная функциональность (платежи, выписки, зарплаты, валютные операции, акты сверок и т. п.) определяется банком и условиями договора.
• Успех внедрения определяется качеством организационной и технической подготовки: регламентами по ЭЦП/токенам, правами на подписание, процессами сверки и обработки отказов.
• Видимый эффект H2H возникает при увеличении объемов платежей и обслуживающих банков.

H2H обмен является качественно новым подходом к проведению оплат и обеспечению непрерывности процессов. Несмотря на появление в 2010‑х годах, его развитие продолжается за счет расширения функциональности и углубления интеграций. Ключом к эффективному использованию остаются организационные и технические изменения. В российском контексте решение «1C:DirectBank» за счет открытых правил обмена стало наиболее известной реализацией H2H технологии.

Подводя итоги одного из проектов, реализованного компанией 1С-ПЕРСПЕКТИВА для группы компаний — крупного российского холдинга, поставщика и производителя продуктов из рыбы и морепродуктов, мы подсчитали экономический эффект от внедрения сервиса «1С:DirectBank».

Проект был завершен в 2026 году, длился один год и включал в себя внедрение в 15 юридических лицах холдинга системы централизованного казначейства на базе решения «1С:ERP Управление холдингом», механизма внутригруппового кэш-пулинга, реализацию унифицированного механизма интеграции с системами юридических лиц, а также подключение сервиса «1С:DirectBank».

• Получение состояния платежей стало в 3–12 раз быстрее. Раньше ожидание статуса занимало до 6–24 часов (клиент‑банк), теперь варьируется в промежутке от 0,5 до 4 часов («1С:DirectBank»).
• Скорость выгрузки платежек (без подписи) увеличилась в 3–5 раз. Раньше на выгрузку пакета в банк тратилось до 10 минут, теперь — до 2 минут.
• Оперативность мониторинга состояния исполнения сократилась в 2–6 раз. Если прежде проверка исполнения платежей по одному банку занимала до 2 минут, то сейчас то же самое время требуется для проверки исполнения по всем отправленным поручения одновременно.
• Ускорилось подписание платежей в связи с переходом от разных банковских приложений к единому окну 1С.

Важнейшим результатом внедрения сервиса «1С:DirectBank» стало ускорение денежного оборота примерно в 1,5–2 раза. Быстрее подтвержденные платежи ведут к улучшенному планированию ликвидности. Источники такого роста: переход в единый интерфейс, исключение промежуточного шага по выгрузке, согласование и отслеживание платежей в едином интерфейсе, получение оперативной банковской выписки день в день.