13 декабря, пятница 10:34
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

SWIFT: стандарты, форматы полей - практика применения.

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • #31
    В Вашем случае в МТ100, которое Вы отправляете в BKTRUS33, в поле 56- IRVTUS3N, в поле 57-INGBATWW.
    Если INGBATWW тоже держит счет в BKTRUS33, то в МТ100, кот. Вы отправляете в BKTRUS33, поле 56 указывать не надо, в 57- INGBATWW.

    Поле 54 заполняется в МТ100 при отправке "платежа с покрытием".

    Удачи!

    Комментарий


    • #32
      Поле 54 "банк корреспондент банка-получателя". Под банком-получателем подразумевается банк, получающий ваше МТ100, а не банк получателя денег. И используется только в платежах с покрытием. В вашем случае, если вы шлете МТ100 в INGBATWW, то поле 54 для IRVTUSN. В противном случае смотрите
      Irena I

      Комментарий


      • #33
        UA Project

        Уважаемые коллеги очень полно уже осветили вопрос.
        Подитожу.
        Поле 54 используется в MT100/103 ТОЛЬКО при платежах с покрытием и указывает банку получателю сообщения его банк-корреспондент, куда придут деньги. Поле 56 указвает банк через который должен идти платеж.

        То есть если Вы шлете платеж с покрытием в "Банк получателя", то MT100 выглядит вот так:
        :50:Ordering customer
        :53A:BKTRUS33
        :54A:INGBATWW
        :59:Beneficiary

        MT202 вот так:
        :56A:IRVTUS3N
        :57A:INGBATWW
        :58D:"Банк получателя"

        Если же в шлете прямой платеж через своего корреспондента, то то MT100 выглядит так:

        :50:Ordering customer
        :56A:INGBATWW
        :57D:"Банк получателя"
        :59:Beneficiary

        Irena_I

        У него есть еще один банк в цепочке.
        I don't get mad. I get even.

        Комментарий


        • #34
          Коллеги!
          Помогите , пожалуйста, разобраться!
          Получили от одного из наших московских банков-корреспондентов сообщение следующего характера:
          ".........Bank and branches are fully ISO 15022 compliant and therefore opted out of ISO 7775 mug since the 16 th of November 2002 . ........Bank will not send or receive messages in ISO 7775 standard since that date."
          Это связано с переходом 100 на 103? Означает ли это, что данный банк больше не будет принимать сообщения в 100 формате? Какие ещё изменения влечёт за собой этот переход? Разъясните, пожалуйста, а то я что-то растерялась.
          Премного благодарна.
          Если идти, не меняя направления, придёшь туда, откуда ушёл.

          Комментарий


          • #35
            GELLA_KZN

            Если вы не работаете с 5 категорией (цен. бум.), то расслабьтесь. В данном случае изменения касаются только этого. Пока это траблы только вашего СВИФТовского админа.

            Комментарий


            • #36
              Malik, я что-то не пойму - так это проблема отдела ценных бумаг или СФИФТовского админа. А если мы к СФИФТУ не подключены?
              Если идти, не меняя направления, придёшь туда, откуда ушёл.

              Комментарий


              • #37
                GELLA_KZN

                Ну цен. бум. уже должны были давно подготовиться, а админ будет нажимать последние кнопки в понедельник (кто-то с замиранием)
                Если вы к СВИФТ не подключены, то не знаю как это вас коснется, может вам стоит применять новые форматы при оформлении сообщений 5 категории.
                Вам эту мессагу случаем не ВТБ прислал?
                Но это точно не связано с убийством сотки, это нас настигнет через год.

                Комментарий


                • #38
                  Боюсь показаться неграмотной, но что представляют из себя сообщения 5 категории? Или мне не грузиться этим, если это связано с "ценными" заморочками? Ценники уже повесили замок на свой "ценный" отдел, так что поинтересоваться не у кого. А жуть как хочется. Правильно ли я поняла Вас, Malik, что этот вопрос целиком на "совести" ценников и у них свои стандарты, нас не касающиеся?
                  А месага точно оттуда. Какие-нибудь доп. комментарии по этому поводу (ВТБ) будут?
                  Если идти, не меняя направления, придёшь туда, откуда ушёл.

                  Комментарий


                  • #39
                    GELLA_KZN

                    Да, 5 категория - это ценные бумаги. Если вы ими не занимаетесь - забудьте об этом как дурной сон! В ноябре следующего года будете 103 встречать.
                    Все остальные комментарии ВТБ на их сайте, но это ваши "ценники" наверняка знают.
                    Успехов!

                    Комментарий


                    • #40
                      Ребята, помогите, пожалуйста!!!

                      К нам в банк обратился клент с просьбой подтвердить по телексу или свифту наличие документов, составляющих PROOF OF PRODUCT.

                      Вопрос: в каком формате мы должны послать это сообщение? В МТ199?

                      И какие обязательства в этом случае берет на себя банк?
                      RND

                      Комментарий


                      • #41
                        Sorry, я, м.б., просто не знаком со спец.терминологией, а что такое proof of product? К чему это физически относится?
                        В общем же случае можно руководствоваться следующим: если не знаешь, какой тип сообщения выбрать, то выбираешь n99 (n - в зависимости от темы; если и тема не идентифицируется, то МТ199). Даже если на самом деле для этого случае где-то предусмотрен спец.тип сообщения - ничего страшного, прочитают, поймут. В качестве ободряющего примера: среди наших контрагентов по ценным бумагам (крупные московские банки) в лучшем случае половина умеет присылать сообщения 5-ой категории, отличающиеся от 599.
                        Об ответственности: аналогично ответственности, которую Вы налагаете на себя, подписывая от имени банка некое письмо.
                        Это общие соображения. Может, не стоило и встревать, но уж больно хочется узнать, что такое proof of product...

                        Комментарий


                        • #42
                          Хамстеру, насчет 5-го формата: на самом деле в Москве банки не очень в этом сильны?!?!??
                          До сего момента думал, что они на уровне...

                          Комментарий


                          • #43
                            Они, м.б., на уровне; я могу судить только по тем подтверждениям, к-рые получаю сам. Так вот личная статистика говорит о том, что в виде спец.форматов (МТ518 и т.д.) приходит примерно 30-40 процентов подтверждений сделок. Подготовка МТ518 занимает в среднем сутки даже у тех, кто умеет.
                            Но, на мой взгляд, ничего страшного в этом нет. Уж больно наворочено в этих МТ5nn всего... Не сочтите за нескромность, но идиотом я себя не считаю. Тем не менее, однажды, когда было время, решил честно сделать МТ518 самостоятельно, имея перед глазами не только сделку, но и МТ518 от контрагента. Потратил около двух часов. Сообщение так и не удалось отправить. В итоге пришлось сделать как обычно: в сообщении контрагента сменил REF, поменял где нужно buy на sell...
                            В общем, относитесь к этому как хотите, но, по-моему, это не тот случай когда нужно чересчур расстраиваться из-за своей безграмотности.
                            Конечно, если у Вас сделки ежедневно, Вы работаете с Euroclear и т.д., тогда конечно, noblesse oblige.

                            Комментарий


                            • #44
                              Коллеги, у меня к вам срочный вопрос, который желательно бы разрешить сегодня.
                              В МТ 202 в 72 поле нужно указать дополнительную информацию сразу для двух банков: для BNF и для REC. Возможно ли оформить это следующим образом:
                              :72:/BNF/............................................ .
                              /REC/.................................................. ?
                              Заранее спасибо.
                              Если идти, не меняя направления, придёшь туда, откуда ушёл.

                              Комментарий


                              • #45
                                Возможно. Если информация для кого-либо не входит в одну строку, то, естественно, должно быть примерно так:
                                :72:/BNF/....
                                //....
                                /REC/....
                                //...

                                Перевод, разумеется, попадет на repair из-за наличия указателя /REC/

                                Комментарий


                                • #46
                                  Перевод, разумеется, попадет на repair из-за наличия указателя /REC/
                                  Уважаемый Hamster,
                                  спасибо за скорейшую реакцию, но позвольте уточнить что значит "попадёт на repair". В каком контексте здесь понимается repair?
                                  Спасибо.
                                  Если идти, не меняя направления, придёшь туда, откуда ушёл.

                                  Комментарий


                                  • #47
                                    Небольшая поправка.

                                    Должно быть так:

                                    :72:/REC/....
                                    //...
                                    /BNF/....
                                    //....

                                    То есть по мере пути прохождения платежа.
                                    I don't get mad. I get even.

                                    Комментарий


                                    • #48
                                      GELLA_KZN
                                      "попадёт на repair" - значит перевод будет отправлен на "ручную
                                      обработку", соотвественно возрастет комиссия за платеж.
                                      Цифры в линии не главное

                                      Комментарий


                                      • #49
                                        Николай, спасибо!
                                        Встречный вопрос Serzh - это что же получается каждый раз когда указываешь код получателя доп. информации, в данном случае REC придётся переплачивать? Так в таком случае логично обходиться без указания кодов, а что называется сразу преподносить инфу.
                                        Хотя по правилам вроде бы положено их использовать.
                                        Коллеги, я что-то не допонимаю, кажется. Разъясните, pls.
                                        Если идти, не меняя направления, придёшь туда, откуда ушёл.

                                        Комментарий


                                        • #50
                                          /rec/ - информация для получателя сообщения, т.е. для Вашего корреспондента. Таким образом, отправляя перевод с указателем /rec/, Вы, фактически, просите Вашего корреспондента прочитать его визуально и, возможно, предпринять какие-то действия (в зависимости от того, что Вы написали). Естественно, /rec/ любая автоматизированная система обработки воспринимает как сигнал остановки и передает сообщение оператору.
                                          Если в банке-корреспонденте предусмотрена комиссия за ручную обработку, то ее в этом случае снимут. Правда, не все банки ее берут. Тут уж смотрите тарифы своего корреспондента...
                                          Естественно, /rec/ указывается в крайнем случае, когда без дополнительных действий корреспондента не обойтись.
                                          Так что все правила 72-го поля составлены с учетом обеспечениея автоматизированной обработки, а уж как их использовать - на Ваше усмотрение в каждом отдельном случае...

                                          Комментарий


                                          • #51
                                            Так в таком случае логично обходиться без указания кодов, а что называется сразу преподносить инфу.
                                            Смотря как оформить эту инфу...
                                            Если просто вбить в поле 72 без кодов и слэшей, то попадет на ту же ручную доработку за те же деньги, да еще, бывает, и напутают что-нибудь, и не попадет инфа куда хотелось бы...
                                            Вообще же все это сильно зависит от софта Вашего корреспондента. Встречаются и дополнительные ограничения, которые многие указывают в отдельных брошюрках.

                                            Комментарий


                                            • #52
                                              Hamster, большое спасибо. Теперь всё ясно. Значит, окончательный варинт получается таким:
                                              :72:..............доп. инфа для rcv............ .
                                              /BNF/..................................................... .
                                              Если идти, не меняя направления, придёшь туда, откуда ушёл.

                                              Комментарий


                                              • #53
                                                hamster

                                                По поводу ручной обработки полностью согласен. На ручную обработку попадает только /REC/. Если есть другие коды, а /REC/ нет - будет автомат.

                                                Если просто вбить в поле 72 без кодов и слэшей,

                                                Так ить - вроде ж структуированное поле, без кодов и слэшей нельзя.

                                                GELLA_KZN

                                                Встречный вопрос Serzh - это что же получается каждый раз когда указываешь код получателя доп. информации, в данном случае REC придётся переплачивать?

                                                Только когда /REC/.
                                                I don't get mad. I get even.

                                                Комментарий


                                                • #54
                                                  GELLA_KZN
                                                  Значит, окончательный варинт получается таким:
                                                  :72:..............доп. инфа для rcv............ .
                                                  /BNF/.....................................................
                                                  Нет, правильный вариант, на мой взгляд написал Николай.

                                                  Должно быть так:

                                                  :72:/REC/....
                                                  //...
                                                  /BNF/....
                                                  //....
                                                  Цифры в линии не главное

                                                  Комментарий


                                                  • #55
                                                    Насчет порядка кодовых слов.
                                                    Только что рылся в стандартах, ничего не нашел.
                                                    Sorry, откуда рекомендация, что кодовые слова должны идти в соответсвии с последовательностью персылки денег, т.е. сначала REC, потом INT if any etc?
                                                    Насколько я понимаю, с точки зрения автоматизированнолй обработки, только REC имеет значение, т.е. система после ручной доработки должна его просто вырезать. Остальные же коды остаются в большинстве случаев без изменений и меняются в зависимости от отношения Вашего корреспондента и credit party в Вашем сообщении. Т.е. с точки зрения обработки в текстовой константе, заключенной в поле 72, нужно иногда менять одно ключевое слово на другое, например, /acc/ на /rec/ и т.д. Возможно, придется срезать часть 72 поля, если общая длина сообщения окажется слишком большой. Но если предположить учет этих особенностей, целесообразно завести бы обратный порядок кодовых слов: /bnf/, /acc/ и т.д. Так откуда же рекомендация о порядке?

                                                    Комментарий


                                                    • #56
                                                      Если просто вбить в поле 72 без кодов и слэшей,

                                                      Так ить - вроде ж структуированное поле, без кодов и слэшей нельзя.


                                                      Да, действительно, теперь так... Давно я не заглядывал в стандарты...

                                                      Комментарий


                                                      • #57
                                                        hamster

                                                        Sorry, откуда рекомендация, что кодовые слова должны идти в соответсвии с последовательностью персылки денег, т.е. сначала REC, потом INT if any etc?

                                                        1. Логика.
                                                        2. Здравый смысл.

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

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

                                                        Насчет смены - Вы когда нибудь встречали соответствующую замену кодов участниками трансфера?
                                                        I don't get mad. I get even.

                                                        Комментарий


                                                        • #58
                                                          /REC/ в любом случае должен стоят первым - для того, кто первый получит сообщение, иначе это абсолютно нелогично.
                                                          Насколько я понимаю, разницы никакой. Если в 72 поле указана информация для разных участников обработки с разными квалификаторами, то назначение информации определяется именно квалификатором, а не расположением текста внутри поля 72. Иначе - с точки зрения логики - зачем же нужны квалификаторы?
                                                          Насколько я понимаю, весь смысл стандартов SWIFT и состоит в том, что значение текста определяется полем, в котором он находится, а не относительным положением его в сообщении. Другое дело, что последовательность полей также фиксирована, но это, с точки зрения автоматизированной обработки, уже необязательно.
                                                          Далее. Обработка 72 поля может организовываться по-разному, но наиболее естественными способами являются два:
                                                          1. Поле делится на части, предназначенные разным участникам платежа; затем, в зависимости от контекста, формируется новое 72 поле, при этом квалификаторы могут измениться.
                                                          2. Происходит - при необходимости - контекстная замена квалификатора.

                                                          Пример:
                                                          Исходное МТ202:
                                                          :57A:XXXXXXXX
                                                          :58A:YYYYYYYYY
                                                          :72:/ACC/TEXT

                                                          Если Ваш корр., получивший такое МТ202, держит счет XXXXXXXX у себя, то он ему должен отправить следующее МТ202:
                                                          :58A:YYYYYYYY
                                                          :72:/REC/TEXT

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

                                                          Мой собственный опыт показывает, что последовательность квалификаторов в поле 72 никакого значения не имеет. Система подготовки сообщений у меня реализована таким образом, что, как правило, она обеспечивает именно обратный порядок квалификаторов, т.е bnf-acc-int-rec, хотя специально под это дело я ее не настраивал. С 95 года работает, и только сегодня Вы меня заставили задуматься.

                                                          С точки зрения ручной обработки - разницы тоже никакой. Юридический смысл текста по стандарту определяется именно квалификатором.

                                                          Может, попробуете опровергнуть?

                                                          Комментарий


                                                          • #59
                                                            Когда я написал, что правильно писать :72:/REC/....//.../BNF/....//...., то имел ввиду
                                                            скорее даже не последовательность кодовых слов, а то, что GELLA_KZN написал
                                                            окончательный вариант: :72:..............доп. инфа для rcv............/BNF/...... .
                                                            Т.е. убрав /REC/ вообще. Но тогда, как получатель сообщения поймет, что
                                                            данная информация предназначена для него. При этом, в 72 поле первым всегда
                                                            должно стоять кодовое слово - получается, что выглядеть все будет так:
                                                            :72:/BNF/...... //..............доп. инфа для rcv............ . Но тогда вся информация
                                                            уйдет к /BNF/ и получатель не выполнит предназначавщихся для него
                                                            инструкций. Да и наличие /REC/ по моему мнению не гарантирует того, что эти инструкции бдут приняты во внимание. По своей практике, всегда старался
                                                            избегать использование /REC/ в 72.

                                                            hamster
                                                            Насчет порядка кодовых слов. Так откуда же рекомендация о порядке?
                                                            Действительно, указаний какое кодовое слово должно быть первым, вторым и
                                                            т.д. нет. Я бы написал /REC/->/BNF/. Почему? Видимо в силу привычки .
                                                            (Сейчас точно утверждать не берусь кто, но кто-то из наших корреспондентов в
                                                            Германии просил, что если есть в 72 /REC/ писать его в первую очередь.
                                                            Это им видимо из-за настроек софта нужно было.)
                                                            Цифры в линии не главное

                                                            Комментарий


                                                            • #60
                                                              hamster

                                                              А зачем что-то опровергать? Я лишь говорил о логике, не более. И не говорил, что это обязательно. Причем не про замену, а про первоначальное положение.
                                                              Такой порядок есть только в примерах.

                                                              Я прекрасно понимаю, что Вы имеете ввиду.

                                                              Допустим, в схеме три банка.

                                                              Первоначальное 72-е поле:

                                                              72:/REC/TEXT
                                                              //INT/TEXT1
                                                              //ACC/TEXT2

                                                              А далее:

                                                              72:/REC/TEXT1
                                                              //ACC/TEXT2

                                                              И уж в конце:

                                                              72:/REC/TEXT2

                                                              Но это в идеале. На самом деле очень редко меняется BNF, INT на REC. Это я и хотел сказать. Может быть у Вас другая практика?

                                                              С 95 года работает, и только сегодня Вы меня заставили задуматься.

                                                              Обратный порядок также имеет право на жизнь. Весьма здраво.
                                                              Порядок-то есть, а не хаотично расставленные коды. Не думаю, что нужно что-то менять.
                                                              I don't get mad. I get even.

                                                              Комментарий

                                                              Обработка...
                                                              X