20 октября, пятница 17:26
Bankir.Ru

Объявление

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

Форматы обмена данными

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

  • Форматы обмена данными

    Уважаемые автоматизаторы!
    Хочу поднять следующую тему.
    Ходят слухи, что наш дорогой ЦБ наконец решил унифицировать форматы обмена данными в своих системах и в том числе обмен данными с комбанками. Речь пока идет только об унификации форматов электронных платежных документов. Но в будущем видимо у них дойдут руки и до отчетности.
    Причем менять хотят кардинально: полный отказ от SWIFT форматов.

    Хотелось бы обсудить следующее: чем нам это грозит?
    и какие технологии можно было-бы применить при разработке новых форматов.

  • #2
    А что же со SWIFTом. Чем он им не понравился?
    И это что же всю Россию зацепит?
    А каким образом с зарубежьем работать? видмо по старому. им же ЦБ не указ.
    когда интересно внедрять будут.
    Придется же софт для работы с ЦБ переписывать.

    Комментарий


    • #3
      Последняя переделка форматов у нас была летом 2000 года. Форматы я бы сказщал SWIFT ориентированные. Сообщения от комбанка до целевой машины в цои идет через 8 машин. С машины на машину в цои перегоняются вручную и в часы пик в цои может застрять на одной из этих машин. Все что нужно комбанкам это шлюз прикладного уровня между оперднем банка и оперднем цои. Это может ыбть реализовано значительно проще.

      Комментарий


      • #4
        Вот как раз с целью создания такого шлюза и будут унифицироваться форматы.
        В ЦБ сейчас вообще идет работа по стандартизации и единообразию всего на свете. Хотят оставить 3-4 типовых программных комплекса по обработке расчетных документов, в дальнейшем полная централизация расчетов (проект ФРЦ).
        С комбанками сейчас обмен эл платежками идет где как: где файлами в SWIFT-похожем формате, где в виде dbf, где в виде документострок. В разных областях опять-же разные требования к оборудованию и способу физического связи с цб, протоколам работы.
        Внутри цб счас тоже идет внедрение транспортной системы на базе MQSeries. Вот к этой транспортной системе они и хотят в конечном счете банки присоединить. И чтоб обрабатывалось все автоматически, никаких операций "вручную".

        Комментарий


        • #5
          Есть ли конкретная техническая информация о подключении к транспортной системе на основе MQSeries?

          Комментарий


          • #6
            Господа!
            А у кого-нибудь есть описание SWIFT-форматов на русском языке?
            Можно на английском, но только не руководство пользователя.
            Спасибо.

            Комментарий


            • #7
              2 Milon
              Конкретной технической информации нет. Известно лишь что это продукт IBM. А транспортную систему разработали наши российские фирмы.
              Транспортная станция работает на NT. Файловый обмен отсутсвует, все операции преобразования сообщений производятся в памяти через вызовы функций MQI.

              2 coba
              SWIFT бывает разный: международный, российский, SWIFT-подобный (у каждого разработчика свой). Какой нужен? может что-то и есть.

              Комментарий


              • #8
                По MSeries информации в сети достаточно. У меня сложилось впечатление, что она для финансовых проектов среднего уровня.А вот о том, что Госбанк планирует на нее переходить и об условиях подключения к ней комбанков ничего не нашел. Важен также протокол прикладного уровня. В существующей у нас SWIFT подобной системе он отсутствует. Поэтому она заведомо не может рабоать в режиме On Line.

                Комментарий


                • #9
                  Относительно того средних или не средних. ЦБ уже выбрал этот софт и внедряет в разных регионах, в этом году наверное внедрит везеде. К тому же что значит для средних. это видимо определяется путем расчета максимальной пропускной способности транспортной системы. скажем (кол-во платежных документов/час) видимо показанная производительность ЦБ устроила.
                  Протокол прикладного уровня определяется не транспортной системой а прикладным софтом. Этот протокол соответственно зависит от той системы что используется в конкретном регионе.
                  Транспортная система должна быть интегрирована с прикладными программами. В комбанке это (АБС-ТС) в ЦОИ это (региональная расчетная система-ТС).
                  ЦБ сейчас разрабытывает и протоколы прикладного уровня. т.е какие электронные документы будут ездить между КБ и ЦОИ, какой документ будет ответным скажем на запрос об отзыве платежки из внутридневной очереди отложенных платежей и т.д. Это естественно тесно связано с форматами.

                  А как сейчас в разных комбанках организован электронный обмен с ЦБ.
                  Надо бы определиться чего мы хотим от этого обмена. Какой сервис получить. какой способ обмена оптимален. и долбать цебешников. Пока идет разаработка всего этого добра на них еще можно как-то повлиять.

                  Комментарий


                  • #10
                    Увы протокол прикладного уровня не сводится к номенклатуре и форматам передаваемых сообщений. Не представляю как можно боротся с элементарным незнанием принципов организации многопроцессорных и многозадачных параллельных процессов. Исходя из форматов файлов можно было представить такую благостную картину.
                    1. Я запрашиваю состояние счета.
                    2. Провожу свои платежи.
                    3. Получаю данные о поступлениях.
                    4. Получаю выписку по совершенным операциям.
                    5. Если что то непонятно запрашиваю.
                    Реально операционист несколько раз в день одномоментно отправляет в ЦОИ до 2 тысяч документов. В часы пик ответ на сообщение приходит через 2-3 часа. Приходящий ответ о состоянии счета никак не привязан к платежкам и какому либо моменту времни. Выписка связана с теми же платежками случайным образом. То есть если документ у них где то застрял, то надо обязательно вручную выяснять его судьбу потому что любые запросы тоже застрянут. Строю системное время считывая момент, когда они создали файл и записывая момент когда сам создаю файл с сообщениями. Но так как сообщения проходят через восемь машин это не слишком точно.В случае ошибочного возврата документов часто невозможно добится причин ошибки . Недавно меня с самым серьезным видом уверяли в том, что краснодарски РКЦ расположен в Сочи, хотя это противоречит их же справочнику.

                    Комментарий


                    • #11
                      Milon, Совершенно правильно нарисовал "благостную картинку". Так и должно все работать. И главное кое-где работает. Скажем у нас отклик системы составляет от нескольких минут до 15-20 минут.
                      И все-таки еще раз повторю:
                      При эл. обмене данными между КБ и ЦОИ можено выделить два вида протоколов: протокол низкого уровня, т.е. и транспортный протокол,
                      и протокол высокого уровня, т.е. протокол обмена прикладного уровня.
                      Транспортный уровень сейчас опустим, а прикладной уровень зависит от конкретной прикладной системы используемой в ТУ ЦБР: это могут быть АБС "УРАЛ", РАБИС-НП, РАБИС-2, АБС "Поволжье" и пр.

                      Типичный пример протокола высокого уровня (выдернул из положения 50-П, это только один кусочек)

                      ---------╛ 100 ------╛ 100 ---------╛
                      ╕Участник+------------------>╕ ФРЦ +------------------> ╕Участник╕
                      ╕СВР - ╕ ╕ ╕ ╕СВР - ╕
                      ╕платель-╕996 при отказе в ╕ ╕097 при неуспешной ╕получа- ╕
                      ╕щик ╕исполнении ЭПД ╕ ╕проверке ЭПД ╕тель ╕
                      ╕ ╕<------------------+ ╕<-------------------+ ╕
                      ╕ ╕ ╕ ╕ ╕ ╕
                      ╕ ╕900 при успешном ╕ ╕900 при успешном ╕ ╕
                      ╕ ╕исполнении ЭПД ╕ ╕исполнении ЭПД ╕ ╕
                      ╕ ╕<------------------+ ╕<-------------------+ ╕
                      ╕ ╕ ╕ ╕ ╕ ╕
                      ╕ ╕910 при завершении ╕ ╕196 при отрицатель- ╕ ╕
                      ╕ ╕операций по ЭПД ╕ ╕ных результатах ╕ ╕
                      ╕ +------------------>╕ ╕сверки ╕ ╕
                      ╕ ╕ ╕ +------------------->╕ ╕
                      ╕ ╕196 при отрицатель-╕ ╕ ╕ ╕
                      ╕ ╕ных результатах ╕ ╕910 по завершении ╕ ╕
                      ╕ ╕сверки ╕ ╕операций по ЭПД ╕ ╕
                      ╕ ╕<------------------+ +------------------> ╕ ╕
                      L--------- L------ L---------
                      Рис. 1. Схема документооборота при проведении расчетов
                      между участниками СВР на основании платежного поручения

                      Вот о такого рода протоколах я и говорил.
                      И естественно протокол и форматы обмена (сообщения МТ100, МТ910, МТ196 и т.д.) связаны друг с другом.
                      И непременными реквизитами в каждом сообщении должно быть: адрес отправителя/получателя, время формирования, ссылка на исходное сообщение.

                      А почему у вас отклик такой медленный? Каналы узкие или софт не справляется?
                      У вас видимо реализована пакетная посеансовая обработка платежных документов, т.е. есть время сеансов связи по полчаса два- три раза в день, и все что накопилось к этому времени вываливается (вот и пиковая нагрузка), а потом ждете следующего сеанса когда ответ придет если вообще придет (

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

                      Мне бы казалась идеальной такая ситуация: это нарисованная тобой благостная картина и вся информация поступает с минимальной задержкой (не более 2-3 минут), чтоб имелась возможность отозвать ЭПД, чтоб имелась возможность получать информацию об ответных платежах, да еще чтобы можно было овердрафт оформить электронным документом под будущие поступления, и опять же не через два часа, а минут за десять. (можешь дополнить список желаний)
                      Для этого естественно надо иметь постоянное соединение с центром обработки, соответствующий софт на своем конце и на стороне ЦОИ, и протоколы обмена, и форматы обмена.
                      И чтобы пропускная возможность транспорной системы позволяла.

                      Комментарий


                      • #12
                        Мне кажется задача много проще чем ее представляют. У меня есть каталог, где лежат платежки моего опердня связанные с моим корсчетом, в ЦОИ есть каталог в котором лежат платежки опердня, связанные с эти корсчетом. Реч идет просто о синхронизации содержимого двух каталогов. Такая команда есть в любом файловом менеджере. В локальных сетях подобную задачу решает устройство называемое повторителем. Пересылает пакеты между двумя сегментами сети. Технология SWIFT подобных файлов усложняет задачу . На хороших каналах связи работаем так будто от банка до цои сообщение идет через телекс и факс и курьером через джунгли.Тогда действительно нужны форматы которые можно распечатать, положить в рюкзак и перенести.
                        Замедление в 2-3 часа возникает когда они начинают решать какие то сови задачи подводя итоги дня.

                        Комментарий


                        • #13
                          Прошу прощения на схеме все пробелы поехали, поэтому ничего непонятно.

                          Комментарий


                          • #14
                            > Технология SWIFT подобных файлов усложняет задачу
                            Во-первых, файлы должны иметь определенный формат, для того чтобы системы понимали друг друга. Какой это формат SWIFT или еще какой уже не так важно.
                            Во вторых, у вас все-таки проблема видимо не в файлах и их синхронизации, а в технологии обработки в ЦОИ. Не справляется ЦБ-шный софт в вашими платежами и платежами других банков. Тут уж ничего не поделаешь надо ждать когда они софт поменяют. А они его поменят, это однозначно.

                            Комментарий


                            • #15
                              Я считаю, что ЦОИ это механизм для достуа к обьекту счет в опердне другого банка. С моей точки зрения система дожна дать мне прозрачный доступ к очередям входящих и исходящих сообщений другого банка. То есть защита соединения, а не файла.
                              Форматы важны. Зачем предусмативать подпись кажлого сообщения если реально подписывается файл из 1-2 тысяч документов. Представте себе президента банка, который 2000 раз нажимает на кнопку наложения электронной подписи. Для пересылки большого количества финансовых сообщений есть EDI. Все вопросы с протоколами там отработаны. Естественно связывается с системами электронной торговли.
                              Отсутствие единого системного времени при обмене финансовыми файлами чрезвычайно важно. Оно приводит к тому что их система не может без меня определить застрявшее на промежуточном этапе сообщение.Получив ответ на запрос о состоянии счета я не знаю какие документы из отосланных мною прошли, а какие нет. Я не могу провести сверку не останавливая процесс передачи сообщений. Я не могу свои отосланные сообщения гарантированно включить в выписку.

                              Комментарий


                              • #16
                                > Представте себе президента банка, который 2000 раз нажимает на
                                > кнопку наложения электронной подписи.

                                Ему и незачем нажимать на кнопку, процесс должен быть построен так, чтобы конкретный операционист или скажем контролер нажимал эту самую кнопку. И нес персональную ответсвенность за искажение данных.
                                я думаю ни в одном банке электронные документы не подписываются презинтом банка или ГБ.
                                И еще я считаю должна обеспечиваться неразрывность хранения и передачи ЭПД и подписи, это будет гарантировать получателю неискаженность данных. Это высказывание спорное приглашаю всех обсудить проблемы безопасности передачи платежноцй информации.
                                Конечно не все системы в ЦБ да и в комбанках готовы сейчас обеспечить это но к этому надо стремиться.

                                В вашем конкретном случае, когда ты не можешь гарантированно провести сверку документов виновата все-таки система обработки данных в ЦБ, и видимо протоколы (форматы) обмена. Какой у вас там софт стоит, железо?

                                > Я считаю, что ЦОИ это механизм для достуа к обьекту счет в опердне
                                > другого банка. С моей точки зрения система дожна дать мне
                                > прозрачный доступ к очередям входящих и исходящих сообщений
                                > другого банка.

                                ЦОИ это такой же опердень, только опредень Банка России. В нормальном полноценном ЦОИ выполняются все те же операции что в комбанке. Соответсвенно у них те же проблемы с масштабированием при увеличении нагрузки.

                                > Для пересылки большого количества финансовых сообщений есть EDI.
                                > Все вопросы с протоколами там отработаны. Естественно связывается с
                                > системами электронной торговли.

                                Стстемы EDI ориентрованы на предметную область в которой они применяются. SWIFT это частный случай системы EDI ориентированный на банковскую деятельность. Но насколько я понимаю SWIFT не закрывает всех потребностей электронного документооборота Банка России. Вот поэтому они изобретают а-ля SWIFT-форматы и протоколы обмена.
                                Но как мне кажется системы EDI на базе SWIFT, UN/EDIFACT, ANSI X-12 и им подобных уже морально устарели. Все они придуманы в 70-годах прошлого века Все они довольно сложны. Нет стандртных средств парсинга, редактирования / создания сообщений. (кроме довольно дорогих которые предоставляют организации поддерживающие эти стандарты).
                                Я бы хотел видеть форматы обмена платежной информацие с ЦБ созданные на язке XML. Расхваливать сейчас его прелести я не буду, думаю это и так всем ясно.
                                Хотя естественно применение того или иного формата не решит проблем описанных Milon. Здесь нужен комплекс мер: и четко продуманные форматы и протоколы обмена, и софт способный справиться с большими объемами информации, и железо соответсвующее.

                                Комментарий


                                • #17
                                  Касательно XML-based протоколов финансовых сообщений,
                                  имеет смысл посмотреть -

                                  FIXML - Financial Exchange Protocol (www.fixprotocol.org),
                                  FpML - Financial Products Markup Language (www.fpml.org).
                                  Там есть DTD на формат финансовых сообщений.
                                  Правда, это касается инвестиционного банкинга и
                                  финансовых инструментов (трейдинг, расчеты, поставка) -
                                  с платежными системами можно сравнивать только в
                                  качестве примера.

                                  FIX имеет спек на сессионный уровень (онлайновый
                                  обмен, не пакетный) - с протокольными процедурами
                                  поддержки целостности (встречная нумерация сообщений,
                                  resend_request, gap_fill и т.п.). Если кто-то ведет
                                  изыскания на эту тему, м.б. имеет смысл позаимствовать
                                  стандартные подходы. Поскольку ожидается переход на
                                  ISO 15022 (глобальный классификатор бизнес-элементов
                                  для финансовой индустрии, курируется свифтом), все эти
                                  протоколы будут меняться (новый FIX 4.3 должен стать
                                  совместимым). 15022 содержит протокольный уровень -
                                  возможно, проблема поддержки 'квитовки' между ордерами
                                  и подтверждениями/выпиcками там решена.

                                  Где-то были сообщения и о рабочей группе по SWIFTML.
                                  Может быть, можно попасть отсюда - www.fisd.net (Financial Software Development Association).
                                  Там есть краткие описания многих протоколов и ссылки.

                                  Успехов,
                                  PSrg, psrg@futures.msk.ru -- www.transaq.ru

                                  Комментарий

                                  Пользователи, просматривающие эту тему

                                  Свернуть

                                  Присутствует 1. Участников: 0, гостей: 1.

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