Про SWIFT, ISO20022 и жажду на­жи­вы

Мно­гие знают (чи­та­ли мои опусы), но я на вся­кий слу­чай на­пом­ню, я до­воль­но много лет ра­бо­тал со 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 есть ещё па­роч­ка таких же огол­те­лых ини­ци­а­тив, но про них я на­пи­шу как-​нибудь в дру­гой раз.