Роли участников трансграничного токенизированного платежа

Здравствуйте. Это первый урок модуля о контурах доверия и допуска операции. В ускоренном blueprint важно начать не с выбора блокчейна или формата SWIFT-сообщения, а с точного ответа на вопрос: кто именно выполняет какую роль и в какой части операции.

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

---

Одна операция — несколько независимых «слоёв ролей»

Рассмотрим нейтральный вариант вашей модели:

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

Интуитивная, но опасная ошибка — назвать всех этих участников «получателем» или, наоборот, считать банк-корреспондент владельцем денег. Чтобы избежать этого, разделяйте роли по трём вопросам:

1. Кому принадлежат экономические права?
   Например, кто платит фиатные деньги и кто должен получить токен.

2. Кто технически и юридически исполняет перевод?
   Здесь появляются обслуживающие банки, корреспондентские счета и платёжные агенты.

3. Кто создаёт, хранит и передаёт цифровой актив?
   Здесь появляются эмитент, смарт-контракт, кастодиан, VASP и адрес кошелька.

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

---

Банковская сторона: кто участвует в платеже

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

1. Компания-отправитель: originator / debtor

Компания A — это экономический инициатор операции. В классической терминологии она является originator, то есть владельцем счёта, который разрешил перевод. В ISO 20022-контексте её часто называют debtor: стороной, чей счёт дебетуется.

Её роль не означает, что она сама отправляет SWIFT-сообщение. Компания обычно:

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

Компания A может финансировать выпуск токенов, покупать уже выпущенные токены, оплачивать погашение, приобретать объект недвижимости или перечислять средства VASP. Эти разные бизнес-цели не меняют её банковскую роль originator/debtor.

2. Банк отправителя: ordering financial institution / debtor agent

Bank A — обслуживающий банк компании A. После получения поручения он становится:

• ordering financial institution — финансовой организацией, которая инициирует банковский перевод от имени originator;
• debtor agent в ISO 20022 — агентом, обслуживающим счёт дебитора;
• потенциально instructing agent или отправителем конкретного межбанковского сообщения.

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

Важно: выражение «глобальный SWIFT-банк» не описывает самостоятельную юридическую роль. SWIFT — это сеть и набор стандартов обмена финансовыми сообщениями; участие в ней не делает банк автоматически корреспондентом, эмитентом цифрового актива или гарантом окончательного расчёта. Роль Bank A определяется его договором с компанией A и его отношениями с другими банками.

3. Банк-корреспондент: correspondent bank

Предположим, Bank A не имеет прямого доступа к EUR-расчётам с банком получателя и держит EUR-счёт у Bank B. Тогда:

• Bank A — respondent bank по отношению к Bank B;
• Bank B — correspondent bank по отношению к Bank A;
• счёт Bank A у Bank B используется для межбанковского расчёта.

В платёжной цепочке Bank B нередко также является intermediary financial institution, то есть промежуточной финансовой организацией, которая принимает и передаёт платёж дальше. Но эти два названия описывают разные аспекты:

Термин	Что он описывает
Correspondent bank	Долгосрочное договорное и счётное отношение: банк хранит средства другого банка и предоставляет ему услуги.
Intermediary financial institution	Функцию в конкретной платёжной цепочке: банк принимает и передаёт платёж между банком отправителя и банком получателя.

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

Банк-корреспондент не становится ни экономическим отправителем, ни экономическим получателем. Он исполняет расчёт и передачу инструкций на основании межбанковских договоров и записей по корреспондентским счетам.

4. Банк получателя: beneficiary financial institution / creditor agent

Bank D, который обслуживает счёт получателя фиатных средств, — это обычно:

• beneficiary financial institution: финансовая организация, получившая перевод прямо или через промежуточные банки и сделавшая средства доступными бенефициару;
• creditor agent в ISO 20022: агент, обслуживающий счёт кредитора;
• в отдельных сообщениях — получатель инструкции от предыдущего банка.

Его ключевая функция — не «получить сообщение», а обработать платёж в своём банковском контуре и, при успешном исполнении, кредитовать счёт клиента. Этот клиент и является beneficiary / creditor в банковской части операции.

---

Роли в ISO 20022: сторона и её агент — не одно и то же

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

Практическое соответствие для базового банковского перевода выглядит так:

Экономическая или операционная роль	Типовой ISO 20022-ярлык	В нашем примере
Компания, чьи средства списываются	Debtor	Компания A
Банк компании A	Debtor Agent	Bank A
Банк, передающий платёж между банками	Intermediary Agent	Bank B или иной промежуточный банк
Компания или организация, чей счёт зачисляется	Creditor	Организация S либо VASP V — зависит от назначения платежа
Банк, обслуживающий счёт кредитора	Creditor Agent	Bank D
Конечный экономический получатель, если он отличается от владельца зачисляемого счёта	Ultimate Creditor	Например, R при определённых агентских структурах

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

---

Токенизационный контур: эмитент, VASP/кастодиан и получатель токена

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

Токен-эмитент

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

В точном проекте необходимо письменно определить:

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

Последний пункт требует дисциплины терминов. Адрес администратора смарт-контракта, multisig или серверный сервис с правом mint — это технический исполнитель полномочия. Он не становится юридическим эмитентом, если не несёт обязательство перед держателями токена.

Кастодиан и VASP

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

VASP — поставщик услуг с виртуальными активами. В зависимости от применимой юрисдикции и модели он может осуществлять обмен, перевод, хранение, размещение или иные операции с виртуальными активами. Один VASP способен одновременно быть:

• кастодианом;
• площадкой обмена;
• получателем банковского перевода за услуги;
• оператором клиентской учётной системы;
• техническим каналом доставки токена.

Но VASP не обязательно:

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

Кастодиальная роль отвечает на вопрос: кто способен переместить актив с кошелька?
Роль конечного получателя отвечает на другой вопрос: кому принадлежат экономические права на актив?

Конечный получатель

Конечный получатель R — физическое лицо, компания или иной допустимый держатель, которому по договорной модели предназначен цифровой актив или права по нему.

R может:

• контролировать собственный self-custody-кошелёк;
• быть клиентом кастодиана V;
• получить запись о владении во внутреннем реестре VASP, а не отдельный ончейн-адрес;
• быть экономическим получателем, в то время как токены временно находятся у агента доставки или в escrow.

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

---

Единая карта ролей для вашей схемы

Ниже — рабочая классификация для операции «компания A переводит EUR; после подтверждённого поступления средств организация S организует выпуск/доставку цифрового актива получателю R».

Участник	Роль в банковском контуре	Роль в токенизационном контуре	Чего он не должен автоматически считаться
Компания A	Originator / Debtor	Плательщик, инвестор или заказчик выпуска	Банком, эмитентом или получателем токена
Bank A	Ordering Financial Institution / Debtor Agent	Обычно отсутствует	Эмитентом токена только потому, что он отправил платёж
Bank B	Correspondent Bank; часто Intermediary Financial Institution	Обычно отсутствует	Владельцем средств компании A или владельцем токена
Bank D	Beneficiary Financial Institution / Creditor Agent	Обычно отсутствует	Конечным получателем цифрового актива
Организация S	Beneficiary / Creditor, если на её счёт пришли EUR	Token Issuer либо уполномоченный оператор выпуска	Кастодианом, если она не контролирует клиентские ключи
VASP V	Может быть банковским бенефициаром, если его счёт указан в платеже	VASP, кастодиан, канал доставки или обмена	Эмитентом без принятия эмиссионного обязательства
Получатель R	Может не быть банковским бенефициаром	Конечный держатель / экономический получатель токена	Владельцем конкретного кошелька только по одному адресу

---

Три варианта, которые нельзя смешивать

Самое полезное проектное правило: сначала выясните, на чей банковский счёт зачисляется фиат, и отдельно — кому выдаётся токен.

Вариант 1. Деньги приходят эмитенту, токен получает R

Компания A переводит EUR на счёт организации S. S — банковский beneficiary/creditor и одновременно токен-эмитент. После предусмотренной проверки S выпускает или распоряжается выпуском токена для R.

• Банковский получатель: S.
• Получатель токена: R.
• VASP: может быть лишь кастодиальным каналом.
• Это не означает, что R получил фиатные средства на свой банковский счёт.

Вариант 2. Деньги приходят VASP, а токен выпускает другая организация

Компания A перечисляет EUR на счёт VASP V, например для покупки или конвертации. VASP получает фиат и оказывает услугу. Организация S остаётся эмитентом токена.

• Банковский получатель: V.
• Эмитент: S.
• Конечный держатель токена: R.
• Здесь V может доставить токен, но не обязан принимать на себя обязательство эмитента.

Вариант 3. Получатель хранит токен самостоятельно

Организация S получает банковское финансирование и доставляет токен прямо на адрес, контролируемый R.

• Банковский получатель: S.
• Эмитент: S.
• Кастодиан/VASP: может отсутствовать.
• Конечный получатель: R, который контролирует собственный ключ.

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

---

На правой части схемы видно множество ledger-узлов. Это не означает, что распределённый реестр заменяет все банковские роли. Даже если расчёт или доставка актива частично происходят через блокчейн:

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

---

Как зафиксировать классификацию до проектирования серверов

До построения API, оркестратора и смарт-контракта заведите для каждого участника карточку роли. Это не бюрократическое приложение: позже именно она позволит настроить разрешения, проверки, бухгалтерские проводки и обработку исключений.

Минимальная запись должна содержать:

Участник:
Юридическое лицо / физическое лицо:
Юрисдикция:
Роль в банковском переводе:
Роль в токенизационном контуре:
На каком основании действует:
Банковский счёт и обслуживающий банк:
BIC банка (если применимо):
Идентификатор юридического лица, например LEI (если применимо):
Кошелёк / тип хранения:
Кто контролирует ключи:
Кому принадлежат экономические права:
Какие договоры и реестры подтверждают роль:

Полезно также закрепить три разных идентификатора, не подменяя один другим:

• BIC помогает адресовать и маршрутизировать банковские сообщения;
• LEI, когда он применим, однозначно идентифицирует юридическое лицо;
• адрес кошелька идентифицирует позицию в блокчейн-сети, но не заменяет идентификацию лица или компании.

---

Итоги

Теперь у вас есть базовое разделение участников операции:

• компания A — originator/debtor, то есть экономический отправитель;
• её банк — ordering financial institution/debtor agent;
• банк-корреспондент предоставляет расчётные услуги банку-респонденту и может быть intermediary financial institution в конкретной цепочке;
• банк получателя — beneficiary financial institution/creditor agent;
• токен-эмитент несёт или организует обязательство, выраженное токеном;
• кастодиан/VASP хранит, переводит или обслуживает цифровой актив, но не становится автоматически его эмитентом или владельцем;
• конечный получатель — лицо, которому принадлежат экономические права на токен, даже если актив технически хранится у VASP.

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