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

Нынче я работаю аналитиком в конторе, которая пишет программное обеспечение для центробанков, расчётных платёжных систем, систем мгновенных платежей, и, в числе прочих активностей мы разрабатываем стандарты и форматы для обеспечения работы всех этих систем и бизнес процедур для различных стран (наши продукты работают более чем в 50 странах мира). В том числе мы много и плотно общаемся со SWIFT по вопросам совместимости форматов и стандартов сообщений, выработки новых стандартов и прочим подобным вопросам.

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

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

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

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

Таким образом, для каждой такой центральной системы (далее я буду использовать термин Market Infrastructure -- MI), используются свои стандарты и форматы, свои обозначения и правила для номеров счетов и идентификации как участников, так и конечных бенефициаров расчётов. Всё это определяет регулятор MI, обычно это платёжная система страны (или объединения нескольких стран в регионе, тогда правила устанавливают центробанки этих стран совместно).

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

Очевидно, что задачи выработки форматов и стандартов, а также общих принципов бизнес-процедур  для трансграничных обменов сообщениями должны неким образом координироваться между всеми участниками во всём мире. И действительно, SWIFT, созданный в 1972 году, должен был решить эту задачу, выработав единые форматы и стандарты. Именно тогда и появились стандарты FIN MT.

С течением времени их стало не хватать (активности изменялись и расширялись) и была сделана попытка преобразовать FIN MT в стандарт ISO15022. К сожалению, этот стандарт разрабатывали совсем другие люди, которые уже не помнили (а то и вовсе не понимали) того, что было раньше, кроме того, хотели сохранить совместимость с предыдущими форматами, и в результате получилось, мягко говоря, не очень.

Простейший пример: именование платежа. Именований платежа есть два, между двумя ближайшими точками в рамках цепочки (point-to-point) и между началом и концом в цепочке (end-to-end).

Для point-to-point было предусмотрено поле 20 -- Transaction Reference Number из 16 символов в 4-ом блоке сообщения (это блок непосредственно финансовой информации), но потом оказалось, что транзакций в одном сообщении может быть несколько, а для end-to-end предложили использовать поле Message User Reference (MUR) в 3-м блоке (пользовательские служебные параметры сообщения). 

И дальше началось...

МТ103: клиентский одинарный платёж, поле 20 называется "Референс отправителя"

МТ102: клиентский множественный платеж, когда в одном сообщении может быть несколько транзакций, поле 20 называется "Референс файла", т.е. общий референс на всю пачку, но при этом на каждой транзакции в пачке есть поле 21, которое и называется "Референс транзакции". 

МТ200: банковский перевод, поле 20 так и осталось "Референс транзакции".

МТ202: банковский перевод для подкрепления счёта клиента, поле 20 опять называется "Референс транзакции", но при этом появляется поле 21, которое называется "Связанный референс", в нём пишется референс (поле 20) соответствующего МТ103. 

В ISO15022 была сделана попытка всю эту непотребщину хотя бы немного причесать, приведя к каким-то одинаковостям, но как мы видим, попытка кончилась ничем. А поле MUR в третьем блоке, которое должно использоваться для end-to-end референса, используют как попало, более того, поскольку третий блок не входит в финансовую информацию, его и вовсе игнорируют при дальнейшей пересылке.

Потом появились стандарты ISO20022, и в них стало ещё хуже. С одной стороны в каждом сообщении появился User Header Block с кучей полей, куда можно было бы затолкать референсы транзакций, с другой стороны в блоке финансовой информации тоже появились какие-то поля для референсов, и всё это непонятно как коррелирует с предыдущим FIN. Про ISO20022 и его приколы также можно написать отдельную юмористическую статью, но, боюсь, она будет сильно специфической и неинтересной большинству читателей.

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

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

Во всём мире, кроме SWIFT. Трансграничные платежи так и остались в форматах FIN. И тут начали возникать проблемы, связанные с конвертацией сообщений из XML в MT и обратно. XML стандарты ISO20022 гораздо шире, включают множество полей, которых нет в FIN MT, а те, которые есть, расширены, например тот же референс транзакции стал не 16 символов, а 35. 

SWIFT последние лет 25 рассказывает о том, что вот вот буквально завтра наступит светлое будущее с XML, но при этом все эти 25 лет всё это колыхалось ни шатко ни валко. Как я уже сказал, все MI перешли на ISO20022 со своими доработками и мучались с преобразованиями в трансграничные обмены SWIFT. 

Надо сказать, что стандарты ISO20022 настолько широки, что туда можно затолкать практически всё, что угодно, вплоть до собственных расширений. Чем все и пользовались.

Но SWIFT это SWIFT, у них всё вертится в головах не вокруг того, чего хотят банки, а вокруг того, чего хочет сам SWIFT (точнее вокруг того, чего хотят топ-50 мировых банков, которые и хотят определять развитие финансовых коммуникаций).

И вот SWIFT выкатил FINplus, который был призван заменить FIN, новая технология поддерживающая до некоторой степени обратную конвертацию в FIN, с тем, чтобы миграция по замене пошла гладко и безошибочно. Описывать FINplus я сейчас не буду (это тема отдельной статьи, если интересно, напишите в комментариях), но на одном моменте остановлюсь. Как и FIN, FINplus принципиально заточен под платёжные цепочки трансграничных сообщений и не работает с центральными клиринговыми системами, в нём принципиально нет соответствующих полей и кодовых слов. Да, путём разных извращений, можно одно в другое затолкать, но это, мягко говоря, требует очень значительных накладных расходов и не всегда получается корректно, в смысле дальней поддержки, расширения и масштабируемости.

Кроме того, SWIFT выкатил технологию, которую он назвал "My standards". На основе стандартов ISO20022 можно разрабатывать свои ограничения на типы сообщений, загружать их в центральный движок SWIFT и в рамках своей MI получать работающую локальную инфраструктуру обмена сообщениями, используя SWIFT как транспортную систему и третью независимую сторону с контролем синтаксиса и семантики сообщений, а также аудита, аутентификации , ограничения доступа и прочих кошерных вещей, которыми славен SWIFT. Нужно зарегистрировать свою закрытую группу, в ней отдельный сервис, раздать правда доступа, определить параметры, зарегистрировать участников... Разумеется, всё это стоит денег, и немаленьких денег. Ну и у этих "Моих стандартов" есть кучка неприятных ограничений, но в прицнипе с ними жить можно.

Затем SWIFT решил подмять под себя и локальные рынки. С этого момента начинается самое интересное. 

Итак, SWIFT разработал подмножество ISO20022, которое он обозвал ISO Acceleration Pack (в девичестве High Value Payments plus -- HVPS+). Этот набор сообщений с одной стороны был предназначен для работы в локальных MI, а с другом стороны был максимально совместим с FINplus. Чтобы можно было бесшовно стыковать трансграничные платежи с внутренними.

И теперь SWIFT пытается нагнуть все центробанки и MI с тем, чтобы они у себя заменили свои собственные уже готовые и работающие форматы/стандарты на SWIFT-овый IAP, и за это заплатили в SWIFT денег. Потому что SWIFT им готов всё это доработать и выдать указания рекомендации, как у них всё должно быть. Ну и заодно SWIFT даст небольшую скидку на использование "My standards", ведь без него это всё не зафурычит.

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

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

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