10 июля, пятница 12:22
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.

                                                              Комментарий

                                                              500 Портал временно недоступен

                                                              Портал временно недоступен

                                                              Возникла ошибка при открытии страницы. Обновите страницу или перейдите на главную
                                                              Обновите страницу спустя некоторое время.

                                                              Агенство Bankir.Ru приносит извинения пользователям
                                                              за доставленные неудобства
                                                              Обработка...
                                                              X