Платёжные инструкции и банковские подтверждения: ключевые различия

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

Это критично для серверного моста «банк → токен»: факт, что компания отправила поручение, банк передал межбанковское сообщение или сеть приняла пакет, ещё не означает, что S получила деньги. В этой схеме выпуск либо доставка токена должны зависеть от заранее определённого и проверяемого факта зачисления, а не от скриншота, QR-кода, хеша или статуса «в обработке».

---

Одна коммерческая операция — несколько разных событий

Возьмём базовую ситуацию:

• компания A даёт своему банку Bank A поручение перевести EUR;
• Bank A и, возможно, банк-корреспондент передают инструкцию по банковской цепочке;
• банк получателя Bank D зачисляет средства на счёт организации S;
• только после этого по правилам продукта может начаться выпуск или доставка цифрового актива для R.

Это не одна «транзакция» в техническом смысле. Это цепочка утверждений с разной силой:

Событие	Кто сообщает	Что это действительно означает	Чего это не доказывает
Клиент создал и подписал поручение	Компания A	A запросила платёж у своего банка	Что Bank A принял, исполнил или доставил платёж
Банк принял поручение	Bank A	Банк согласился обработать инструкцию в рамках своего процесса	Что средства зачислены S
Банк отправил межбанковскую инструкцию	Bank A / промежуточный банк	Следующему банку передано распоряжение обработать перевод	Что межбанковский расчёт завершён
Сеть подтвердила техническое принятие сообщения	SWIFT-сервис или банковский шлюз	Сообщение прошло транспортную/синтаксическую стадию	Что банк получателя зачислил деньги
Трекер показывает статус	GPI/Tracker	В цепочке опубликован статус определённого этапа	Само по себе — юридическую и учётную окончательность
На счёте S отражён кредит	Bank D	Банк получателя учёл поступление на счёте S	Что средства безусловно доступны для конкретной токенизационной модели; это зависит от условий, блокировок и правил
Банк подтвердил кредитование конечного бенефициара	Bank D / подтверждающий канал	Конечный счёт бенефициара был кредитован	Что токен уже можно выпускать без дополнительных комплаенс- и резервных проверок

Главное правило:

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

---

Клиентская инструкция: pain.001 или банковский API

pain.001 — это ISO 20022-сообщение типа Customer Credit Transfer Initiation. В обычной логике оно идёт от клиента к обслуживающему банку: компания A просит Bank A выполнить перевод.

Содержательно такая инструкция обычно включает:

• плательщика (Debtor);
• счёт, с которого должны списаться средства;
• получателя (Creditor);
• счёт получателя;
• сумму и валюту;
• назначение платежа;
• клиентские идентификаторы операции, в том числе Instruction Identification и End-to-End Identification;
• данные, необходимые банку для маршрутизации и проверок.

Банковский API, host-to-host файл или интерфейс интернет-банка могут не передавать буквальный XML-документ pain.001. Но логически они выражают то же действие: клиент инструктирует свой банк.

После получения pain.001 Bank A может вернуть клиенту pain.002 — Customer Payment Status Report. Однако здесь нужна дисциплина интерпретации: статус в pain.002 показывает, как Bank A обработал именно клиентскую инструкцию в рамках согласованного интерфейса. Он может сообщать о принятии, отклонении, ожидающей обработке или другом этапе, но не заменяет подтверждение кредитования счёта S банком Bank D.

Практически это означает, что в токенизационном сервере нельзя делать правило вида:

если pain.001 принят → разрешить mint

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

---

Межбанковское сообщение: pacs.008 или MT103

После того как Bank A принял инструкцию A, он создаёт распоряжение для следующего финансового института в маршруте. В современном ISO 20022-контексте для клиентского кредитового перевода между финансовыми институтами типичным сообщением является pacs.008 — FI to FI Customer Credit Transfer.

В legacy FIN-потоке ему функционально соответствует MT103. Важно не подменять эти понятия:

• pain.001: «клиент A просит Bank A перевести деньги»;
• pacs.008 / MT103: «один финансовый институт инструктирует другой финансовый институт обработать клиентский перевод»;
• pacs.002: статус, отправленный между финансовыми институтами; его точная семантика зависит от применимого rulebook и этапа обработки;
• camt.053 / camt.054: отчёт банка клиенту о движениях либо уведомление о конкретном дебете/кредите.

На практике между pain.001 и pacs.008 нет гарантированной связи «один файл — одно одинаковое сообщение». Банк может:

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

Поэтому серверу эмитента недостаточно получить от компании A копию pain.001. Она доказывает только намерение клиента и набор заявленных реквизитов. Она не доказывает, что банк получил платёж, тем более что S кредитована.

Схема полезна именно как напоминание о границе контуров, но её не следует читать как универсальную обязательную топологию. Реальный маршрут зависит от валюты, корреспондентских счетов, платёжной системы, банковских договоров и применимого стандарта. В частности, наличие линии pacs.008 между двумя банками означает передачу межбанковской инструкции, а не автоматическое появление доступного остатка на счёте S.

---

«Подтверждение сети» бывает трёх разных типов

Фраза «SWIFT подтвердил платёж» слишком неопределённа для проектной документации. Под ней могут иметь в виду по меньшей мере три несводимых друг к другу вещи.

1. Техническое подтверждение транспорта

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

Такое подтверждение полезно для эксплуатации: оно позволяет понять, нужно ли повторно отправлять сообщение и дошло ли оно до контрагента. Но оно не говорит, что адресат:

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

Технический ACK — это доказательство доставки сообщения, а не доставки денег.

2. Статус обработки от банка

Следующий банк может вернуть межбанковый статус, например через pacs.002 в ISO 20022-потоке. Такой статус сильнее простого сетевого ACK: он отражает обработку инструкции банком или платёжной системой.

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

1. схемой конкретного платежа;
2. профилем ISO 20022 и правилами сообщества;
3. ролью отправившего статус банка;
4. статусным текстом и причиной;
5. тем, относится ли событие к межбанковскому расчёту или к кредитованию клиентского счёта.

То есть правило «увидели pacs.002 — выпускаем токен» является архитектурной ошибкой.

3. GPI/Tracker-подтверждение и UETR

В GPI-цепочке участники передают статусы в общий Tracker. Для сквозной корреляции используется UETR — Unique End-to-end Transaction Reference. Он должен сопровождать платёж по маршруту и связывать статусы разных участников с одной платёжной историей.

UETR особенно ценен в архитектуре, потому что позволяет сопоставить:

• исходную инструкцию Bank A;
• сообщения и статусы промежуточных банков;
• GPI-обновления;
• подтверждение от Bank D;
• внутреннюю запись сверки эмитента.

Однако уникальность ссылки не превращает её в доказательство. Самостоятельно сформированный hash, QR-код с UETR или письмо «payment sent» лишь указывают, что искать. Они не заменяют банковский источник, который подтверждает, что произошло.

---

Выписка и уведомление: что именно сообщает банк клиенту

Когда Bank D обслуживает счёт S, наиболее значимыми для S артефактами становятся банковские отчёты, а не исходная инструкция A.

Артефакт	Типовое ISO 20022-сообщение	Назначение	Доказательная сила для условия выпуска
Внутридневной отчёт	camt.052	Показывает доступные банку внутридневные движения и остатки	Полезен для раннего мониторинга, но не всегда достаточен как окончательная запись
Банковская выписка	camt.053	Отражает движения и остатки за отчётный период	Сильный учётный артефакт, если получен из доверенного банковского канала и содержит нужную кредитовую запись
Уведомление о дебете/кредите	camt.054	Сообщает о конкретном движении по счёту	Быстрое операционное подтверждение; нужно сверять с выпиской и правилами банка
Подтверждение кредитования конечного бенефициара	GPI/подтверждающий статус/банковский ответ	Указывает, что конечный счёт бенефициара был кредитован	Сильный индикатор доставки платежа, но его следует связать с банковским учётом и условиями продукта

camt.054 часто наиболее удобен для событийной архитектуры: банк оперативно сообщает S о конкретном кредите. Но сервер не должен верить любому входящему JSON, XML, PDF или email. Он должен проверить источник: например, взаимно аутентифицированный банковский API, подписанный канал, защищённый SFTP-обмен, банковский портал с контролируемым извлечением либо иной согласованный механизм.

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

Есть важная граница: даже достоверная выписка не всегда даёт стороннему эмитенту право считать деньги обеспечением. Если S — эмитент, это может быть её собственный банковский артефакт. Если фиат пришёл на счёт VASP или платёжного агента, эмитенту нужны договорная модель, полномочия на использование средств и проверяемое подтверждение от соответствующей стороны. В противном случае «кредит на чужом счёте» ошибочно принимается за резерв эмитента.

---

Что считать доказательством окончательного зачисления

В проекте не стоит искать один магический документ. Нужен набор взаимосвязанных доказательств. Для операции «A переводит EUR, S затем организует выпуск токена» минимальный пакет проверки должен отвечать на следующие вопросы.

1. Кто является источником подтверждения?

Источник должен быть известным, аутентифицированным и уполномоченным:

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

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

2. Что именно было кредитовано?

Нужно проверить как минимум:

• сумму и валюту;
• валовую и чистую сумму, если возможны удержания комиссий;
• счёт кредитора и юридическое лицо-владельца счёта;
• дату валютирования, дату проводки и доступность средств, если они различаются;
• назначение платежа;
• платёжные ссылки банка;
• отсутствие статуса rejection, return, recall, hold или compliance review.

Особенно опасна ошибка «совпала сумма — значит, это наш платёж». В EUR на один и тот же счёт могут прийти несколько одинаковых сумм, а комиссия посредника может привести к несовпадению исходной и фактически кредитованной сумм.

3. Как связать кредит с исходной инструкцией?

Для этого создают реестр корреляции, а не опираются на один идентификатор:

Идентификатор	Кто обычно создаёт	Для чего нужен
Instruction ID	Компания A	Идентифицирует клиентское поручение
End-to-End ID	Клиентская цепочка платежа	Связывает коммерческую операцию по всей цепочке, если сохранён
UETR	SWIFT/GPI-контекст	Связывает межбанковое прохождение и статусы
Банковский transaction reference	Конкретный банк	Позволяет найти запись в учёте или отчёте банка
Statement entry reference	Bank D	Привязывает операцию к записи в camt.053/camt.054
Internal funding case ID	Система S	Связывает банковское событие с заявкой на выпуск токена

Связь должна быть явно записана в системе S. Например: заявка на токенизацию CASE-417 сопоставлена с UETR, затем с банковским reference Bank D и с конкретной строкой выписки. Это защищает от двойного использования одного поступления в двух заявках.

---

Операционная и юридическая окончательность — не одно и то же

Слово «окончательный» следует определить в политике операции, а не использовать как интуитивное.

Операционная окончательность может означать: Bank D подтвердил, что счёт S кредитован, запись отражена в банковской отчётности, а внутренние системы S успешно сверили атрибуты операции.

Расчётная или юридическая окончательность зависит от платёжной системы, применимого права, времени cut-off, договоров, процедур возврата, ошибок, санкционных остановок и иных обстоятельств. Даже после кредитования в реальном мире могут существовать расследования, исправления или предусмотренные законом возвраты.

Поэтому корректная логика не звучит как «кредит подтверждён, значит всё необратимо». Она звучит так:

Условия допуска к выпуску выполнены, если доверенный источник подтвердил кредитование счёта S, все атрибуты сверены, отсутствуют открытые блокировки, а уровень расчётной уверенности соответствует утверждённой политике продукта.

Для консервативной модели политика может требовать одновременно:

1. подтверждение кредитования конечного бенефициара;
2. camt.054 из аутентифицированного банковского канала;
3. последующую сверку с camt.053;
4. отсутствие возврата, отзыва или compliance hold;
5. одобрение уполномоченного оператора для исключений.

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

---

Правило допуска: какие статусы блокируют выпуск

В документации будущего оркестратора полезно заранее разделить состояния на три категории.

Категория	Примеры событий	Действие токенизационного контура
Не является основанием для выпуска	pain.001 создан; банк принял поручение; pacs.008 отправлен; транспортный ACK; промежуточный GPI-статус	Сохранить для трассировки; mint и доставка заблокированы
Требует ожидания или ручной проверки	Несовпадение суммы; частичный кредит; pending; AML/sanctions hold; неизвестный reference; платёж через агента	Поставить кейс в очередь исключений; не выпускать токен
Может стать основанием для выпуска	Подтверждённый кредит на счёте S; все ссылки и реквизиты сверены; соблюдены условия политики	Создать разрешение на выпуск, не смешивая его с самим банковским доказательством

Полезно сохранить раздельно два объекта:

Payment evidence:
  утверждение банка о конкретном кредитовом событии

Issuance authorisation:
  внутреннее решение S, что данное событие удовлетворяет
  правилам обеспечения, комплаенса и продукта

Первый объект говорит: «что произошло в банковском контуре». Второй: «какое действие разрешено в токенизационном контуре». Это разделение позволит позднее безопасно добавлять комплаенс-проверки, двойную бухгалтерскую книгу, повторные сверки и правила погашения.

---

Краткая проверка для вашей схемы A → S → R

Перед тем как считать фиатное поступление обеспечением цифрового актива, команда S должна быть способна документально ответить:

1. Какая именно инструкция A лежит в основе операции?
   Нужны её клиентский ID, сумма, валюта, цель и разрешённый плательщик.

2. Какой межбанковский путь и идентификаторы с ней связаны?
   В частности, UETR, если он доступен, и банковские references.

3. Какой банк кредитовал какой счёт?
   Недостаточно формулировки «деньги пришли в Европу» или «платёж в SWIFT завершён».

4. На каком основании S вправе использовать именно этот кредит для выпуска?
   Счёт должен принадлежать S либо существовать документально оформленная агентская/кастодиальная модель.

5. Какие независимые артефакты подтверждают факт?
   Например, подтверждение кредитования и camt.054, затем сверка с camt.053.

6. Что произойдёт, если позднее появится return, recall или расхождение?
   Этот вопрос пока не решаем технически, но его нельзя оставлять вне модели допуска.

---

Итоги

В этой операции пять типов артефактов выполняют разные функции:

• pain.001 или банковский API фиксирует клиентское распоряжение A;
• pacs.008 или MT103 передаёт межбанковскую инструкцию;
• транспортный ACK подтверждает обработку сообщения сетью, а не движение денег;
• GPI-статус и UETR дают наблюдаемость и корреляцию маршрута;
• camt.054, camt.053 и подтверждение кредитования дают банковские доказательства движения по счёту и доставки платежа.

Ни один ранний этап — созданное поручение, отправленный pacs.008, сетевое подтверждение или UETR — не должен сам по себе запускать выпуск токена. Основанием может быть только заранее определённый, аутентифицируемый и сверенный пакет доказательств кредитования.

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