Переводы IP/IP и IPZip

IP-to-IP (IPIP)

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

Вместе с тем следует отметить, что переводы с IP-адреса на IP-адрес не являются распространённой практикой в банковской отрасли и не рекомендуются по ряду причин, включая вопросы безопасности, надёжности и соблюдения требований. Приведённые ниже пункты поясняют эти соображения:

1. Безопасность: переводы между IP-адресами (IP to IP) могут быть менее защищёнными по сравнению с устоявшимися банковскими сетями, такими как SWIFT или ACH, в которых применяется несколько уровней защиты, шифрования и аутентификации. Прямое взаимодействие между двумя IP-адресами может подвергнуть конфиденциальную информацию потенциальным угрозам безопасности, включая взлом, фишинг и атаки типа «человек посередине».
2. Надёжность: использование переводов по схеме «IP–IP» не гарантирует надёжности транзакции, поскольку в банковской отрасли отсутствуют общепризнанные стандарты и протоколы для переводов на основе IP-адресов. Это может приводить к проблемам при обработке, отслеживании и сверке транзакций.
3. Комплаенс: банки и финансовые учреждения подчиняются многочисленным нормам и требованиям, включая политики противодействия отмыванию денег (AML) и идентификации клиентов (KYC). Переводы с IP на IP могут не соответствовать этим регуляторным требованиям, что потенциально подвергает участвующие стороны юридическим и финансовым рискам.

Вместо переводов между IP-адресами банки и финансовые учреждения предпочитают использовать устоявшиеся сети, такие как SWIFT, RTGS или ACH/системы мгновенных платежей, а также стандарты обмена сообщениями, например ISO 20022, для обеспечения безопасных, надёжных и соответствующих требованиям переводов средств между различными учреждениями.

Основные различия между серверами связи и серверами учёта счетов в банках

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

Серверы связи

Коммуникационные серверы являются основой защищённого обмена данными между банками и финансовыми институтами. Ниже перечислены ключевые функции и характеристики коммуникационных серверов:

1. Защищённый обмен данными: эти серверы обеспечивают защищённый обмен данными, позволяя передавать конфиденциальную финансовую информацию между учреждениями без риска её компрометации.
2. Протоколы и стандарты: используются стандартизированные протоколы, такие как SWIFT, SEPA или ACH и другие, для межбанковского обмена сообщениями, что обеспечивает единообразие и надёжность на различных платформах.
3. Шифрование и аутентификация: для обеспечения безопасности коммуникационные серверы используют современные методы шифрования и строгие протоколы аутентификации, защищая данные при передаче.
4. Обработка транзакций: в первую очередь они обрабатывают запросы на проведение транзакций, сообщения и инструкции, выступая посредниками, которые передают информацию, необходимую для выполнения транзакций.
5. Отсутствие движения средств: важно, что эти серверы не осуществляют перемещение средств и не обновляют остатки на счетах напрямую; они лишь обеспечивают обмен информацией, необходимый для таких операций.

Серверы учётных записей и реестров

Серверы главной книги и счетов, в свою очередь, являются хранителями финансовых записей банка. Их основные характеристики:

1. Ведение финансовых записей: на этих серверах хранятся и ведутся основные финансовые записи банка, что обеспечивает точный учёт каждой операции.
2. Учёт операций: они фиксируют все операции, включая дебетовые и кредитовые проводки, а также отвечают за обновление и хранение актуальных остатков на счетах.
3. Управление главной книгой: серверы главной книги ведут главную книгу банка наряду с отдельными клиентскими счетами, обеспечивая полное представление о финансовом состоянии.
4. Целостность данных: обеспечение согласованности и целостности данных имеет принципиальное значение, поскольку эти записи необходимы для точной финансовой отчётности и соблюдения нормативных требований.
5. Строгие меры безопасности: с учётом чувствительности данных серверы реестров, как правило, оснащаются более жёсткими средствами защиты, включая дополнительные уровни шифрования и строгий контроль доступа.

Коммуникационный сервер инициирует и обеспечивает проведение операций, однако именно сервер учётной книги в конечном счёте фиксирует и отражает эти операции после проверки в книгах банка.

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

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

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

Перевод IP ZIP

Защищённая файловая передача институциональных платёжных поручений

Перевод IP ZIP лучше всего понимать как защищённый файловый способ передачи структурированных платёжных инструкций и сопутствующих данных о транзакциях непосредственно между аутентифицированными институциональными системами по сети на основе протокола IP.

Терминология требует особой точности.

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

Соответственно:

IP ZIP передаёт платёжную информацию и инструкции. Сам по себе он не осуществляет расчёт денежными средствами.

Концептуально это сопоставимо с различием, применимым к сообщению ISO 20022 pacs.008 (кредитовый перевод клиента между финансовыми институтами). Сообщение pacs.008 может содержать высокоструктурированную межбанковскую инструкцию на кредитовый перевод, однако само сообщение не следует смешивать с фактическим движением и расчётами в деньгах центрального банка, деньгах коммерческих банков или остатками на корреспондентских счетах.

Тот же принцип применим к передаче по IP в формате ZIP.

2. ZIP-файл как защищённый контейнер для сделки

Компонент ZIP служит прежде всего механизмом контейнеризации и упаковки.

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

В зависимости от согласованной двусторонней спецификации такой пакет может содержать:

• структурированные платёжные инструкции;
• платёжные сообщения в формате XML;
• наборы данных, совместимые с ISO 20022;
• транзакционные объекты в формате JSON;
• записи о транзакциях в формате CSV или в формате с фиксированной структурой;
• файлы межбанковских платежей в проприетарных форматах;
• информация о должнике и кредиторе;
• сведения о счёте отправителя и счёте бенефициара;
• идентификаторы транзакций;
• сведения о валюте и сумме;
• запрошенные даты исполнения и валютирования;
• инструкции банка-корреспондента;
• сведения о банке-посреднике;
• информация о платеже;
• информация о маршрутизации расчётов;
• комплаенс-документации;
• документы, подтверждающие прохождение KYC или KYB;
• информация об источнике средств;
• манифесты транзакций;
• цифровые подписи;
• криптографические хеши;
• сертификаты;
• метки времени;
• файлы сверки; и
• контрольные суммы.

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

Сжатие носит технически вторичный характер. Основная цель — контролируемое формирование пакета и его передача.

Следовательно, ZIP-архив ни в коем случае не следует рассматривать как доказательство того, что представленные в архиве средства существуют, доступны, не обременены или расчёты по ним произведены.

3. Структурированное платёжное поручение

При надлежащем построении платёжное поручение, содержащееся в пакете IP ZIP, может выполнять функцию, аналогичную традиционным структурированным финансовым сообщениям.

Например, институт может передать XML-инструкцию, содержащую поля, соответствующие сведениям, которые обычно содержатся в сообщении ISO 20022 pacs.008, в том числе:

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

Принципиально важно, что структура данных не определяет механизм расчётов.

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

Таким образом:

Получение распоряжения ≠ получение средств

Аутентификация инструкции ≠ завершение расчёта по средствам

Успешный импорт файла ≠ зачисление окончательных средств бенефициару

Подтверждение получения сервером ≠ подтверждение расчёта

Это различие является основополагающим для подхода IFB к альтернативным методикам перевода средств.

4. Протоколы передачи

Передача институциональных IP ZIP-файлов должна осуществляться исключительно в контролируемой и аутентифицированной среде связи.

В зависимости от двусторонней технической договорённости передача может осуществляться с использованием таких технологий, как:

SFTP

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

Для институционального подключения, как правило, следует отдавать предпочтение аутентификации с открытым ключом перед аутентификацией только по паролю.

FTPS

Протокол FTP может быть защищён с помощью TLS там, где этого требует унаследованная инфраструктура, при условии применения надлежащей проверки сертификатов, стандартов шифрования и механизмов контроля доступа.

HTTPS / REST API

Пакет документов может передаваться через аутентифицированную конечную точку HTTPS или архитектуру API с использованием TLS и соответствующей аутентификации на уровне приложений.

Mutual TLS

Для институциональных подключений с повышенными требованиями к надёжности взаимная аутентификация TLS (mTLS) позволяет обеим сторонам удостоверять друг друга с помощью цифровых сертификатов.

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

VPN

До начала передачи на уровне приложений между участвующими учреждениями может быть установлен зашифрованный частный туннель с помощью VPN типа «сеть—сеть» на базе IPSec или аналогичного протокола.

Выделенное частное подключение

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

Точный протокол должен быть согласован на двусторонней основе до начала операционной активации.

5. Аутентификация конечных устройств

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

К соответствующим мерам контроля могут относиться:

• институциональные цифровые сертификаты;
• пары открытых и закрытых ключей SSH;
• взаимная аутентификация по сертификатам TLS (mutual TLS);
• учётные данные API;
• ограничение доступа списком разрешённых IP-адресов;
• аутентификация через VPN;
• аппаратные модули безопасности;
• закрепление сертификатов (certificate pinning) там, где это уместно;
• многофакторная аутентификация администраторов;
• контролируемые служебные счета;
• ролевое разграничение прав доступа; и
• разделение производственной и тестовой сред.

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

Аналогично, обладание конечной точкой доступа, учётными данными для входа на сервер, API-ключом или паролем к ZIP-архиву не подтверждает права собственности на соответствующие средства.

6. Шифрование

Конфиденциальность, как правило, следует обеспечивать более чем на одном уровне.

Шифрование при передаче данных

Канал связи должен быть защищён шифрованием с использованием надлежащим образом настроенного современного протокола, например TLS или SSH.

Это защищает информацию при передаче.

Шифрование полезной нагрузки

При необходимости транзакционный пакет может быть дополнительно зашифрован.

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

Шифрование хранимых данных

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

Однако шифрование обеспечивает лишь конфиденциальность. Оно не подтверждает финансовую состоятельность операции.

7. Криптографическая целостность

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

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

Например:

Исходный пакет транзакции
→ формируется криптографический хеш
→ пакет передаётся
→ принимающая система самостоятельно вычисляет хеш
→ вычисленный хеш сравнивается с переданным или подписанным хешем

Несоответствие означает, что полученный пакет не идентичен в криптографическом отношении пакету, первоначально прошедшему аутентификацию.

Для проверки целостности данных могут применяться современные криптографические хеш-алгоритмы, например семейства SHA-2 или SHA-3, в зависимости от особенностей реализации.

8. Цифровые подписи

Цифровая подпись выполняет принципиально иную функцию, чем шифрование.

Шифрование обеспечивает конфиденциальность.

Хеширование способствует обеспечению целостности.

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

1. подлинность — пакет подписан с использованием соответствующего закрытого ключа;
2. целостность — подписанные данные не были впоследствии изменены; и
3. подотчётность — подпись может быть соотнесена с соответствующими институциональными учётными данными с учётом применимой инфраструктуры открытых ключей (PKI) и системы управления.

Принимающее учреждение должно проверить подпись по соответствующему доверенному сертификату или открытому ключу до того, как платёжное поручение поступит в обработку.

Закрытые ключи подписи должны быть надлежащим образом защищены, предпочтительно с использованием институциональной инфраструктуры управления ключами и, при необходимости, аппаратных модулей безопасности (Hardware Security Modules).

9. Защита от повторной отправки и дублирования

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

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

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

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

10. Валидация файла

Успешное получение файла должно инициировать проверку, а не автоматический расчёт.

В защищённой среде обработки пакет документов может проходить несколько последовательных проверок:

Этап 1 – Проверка на транспортном уровне

Подтверждение того, что отправление поступило по авторизованному каналу.

Этап 2 — аутентификация конечных точек

Подтверждение подлинности передающей системы и учётных данных организации.

Этап 3 – Меры защиты от вредоносного программного обеспечения и обеспечения безопасности файлов

Проверка архива и входящих в него файлов перед загрузкой в платёжную инфраструктуру.

Этап 4 – криптографическая верификация

Проверка хэшей, подписей и сертификатов.

Этап 5 – Структурная валидация

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

Этап 6 — семантическая валидация

Подтверждение того, что обязательные поля платежа присутствуют и внутренне согласованы.

Этап 7 – Валидация операции

Проверка валюты, суммы, счетов, маршрутной информации, референсов операции и расчётных инструкций.

Этап 8 — Проверка соответствия требованиям комплаенс

Меры контроля в области AML, санкций, KYC/KYB, мониторинга операций и иные применимые меры контроля.

Этап 9 – Проверка расчётов

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

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

11. Подтверждение получения не означает расчёта

Среда IP ZIP может формировать несколько технических подтверждений.

Например:

ACK – файл получен

Это подтверждает лишь то, что принимающая конечная точка получила пакет.

ACK – файл аутентифицирован

Это подтверждает, что процедуры контроля аутентификации были успешно завершены.

ACK – файл проверен

Это подтверждает, что пакет соответствует применимым структурным или техническим требованиям проверки.

ACK – Инструкция принята

Это может подтверждать, что платёжная инструкция поступила в процесс обработки принимающего учреждения.

Ни одно из этих состояний не обязательно означает следующее:

РАСЧЁТЫ ЗАВЕРШЕНЫ

Для расчёта требуется отдельное финансовое событие.

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

12. Расчёты по базовой сделке

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

В зависимости от задействованных валют, учреждений и юрисдикций расчёты могут осуществляться через:

• корреспондентские банковские услуги;
• счета «Ностро»/«Востро»;
• счета в центральном банке;
• Инфраструктура RTGS;
• признанные клиринговые системы;
• национальные платёжные системы;
• инфраструктуры мгновенных платежей;
• банки-корреспонденты, осуществляющие расчёты; или
• иной юридически и операционно признанный механизм расчётов.

14. Принцип безопасности

IFB проводит принципиальное разграничение в отношении всех альтернативных методов перевода средств:

Защищённая передача данных доказывает, что данные могут быть безопасно переданы. Она не доказывает, что расчёт по денежным средствам может быть произведён.

• Шифрование не подтверждает наличие средств.
• Цифровая подпись не подтверждает наличие средств.
• Остаток на сервере не является подтверждением наличия средств.
• Файл транзакций не подтверждает наличие средств.
• Успешная загрузка файла не является подтверждением наличия средств.
• Техническое подтверждение не доказывает осуществление расчётов.

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

15. Рамочные условия принятия документов IFB

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

До запуска промышленного подключения IFB может потребовать проверки следующего:

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

Одной технической совместимости недостаточно.

IFB не рассматривает успешную передачу пакета IP ZIP как получение средств. Операция считается финансово завершённой только тогда, когда расчёт по соответствующей сумме успешно завершён через согласованную банковскую или расчётную инфраструктуру и может быть независимо выверен.

Основополагающий принцип

IP ZIP — это защищённая передача инструкции. Расчёт — это перемещение соответствующей финансовой стоимости.

Эти два процесса могут быть частями одного рабочего цикла сделки, однако они не являются одним и тем же событием.

В терминологии институционального банковского дела:

Передача сообщения → аутентификация → валидация → принятие → исполнение → расчёты → сверка

Лишь завершение соответствующей процедуры расчётов подтверждает, что денежная часть сделки исполнена.

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

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

Если Вы хотите узнать больше о порядке перевода средств или активов на Ваши счета в нашем банке, пожалуйста, свяжитесь с Marie Mayer.