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

Объявление

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

Как определить по Мастеру доместик ?

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

  • Как определить по Мастеру доместик ?

    Тут вот с 1 октября релиз ECCSS 2004-2 требует от эквайеров в обязательном порядке проставлять в формируемые презентменты IRD (Interchange Rate Designator, по старому IRI). И всплывает старая и больная проблема.
    Ну, определили мы, что вычисленный из таблицы БИНов эмитент российский (код страны 643). А дальше-то? Ведь до сих пор не все российские банки вошли в соглашение по доместику…
    Сейчас мы ставим в таких случах в SH6 (Transaction Fee Rule) Processing Domain (алиас Transaction Domain) = 'D' и в ус не дуем. Если это не доместик, то в Ватерлоо сами поправят и пришлют Warning (на который мы наплюем - их не так много). А с 1 октября пойдут реджекты, чего совсем не хочется.
    Как вообще определять - такой-то российский эмитент участник российского доместика или не участник?

  • #2
    AlexYe Как вообще определять - такой-то российский эмитент участник российского доместика или не участник?

    Вариант А. Забейте табличку конфигурационную в программе, которую будете использовать при заполнении SH6
    И когда пойдут реджекты - просто вносите туда IIDы из отреджектированных транзакций.

    Вариант Б. Попробуйте позвонить в московский офис Мастеркарда [сорри, этот вариант Вам похоже не подойдет ]
    --* Never say never again...

    Комментарий


    • #3
      Сообщение от Rzhevsky
      AlexYe
      Гм, я честно говоря, надеялся, что есть некий (может быть, не вполне официальный ;-) документ, где сформулировано ПРАВИЛО.
      А сводится все к банальной необходимости держать таблицу банков и проверять их штучно.
      То есть, оно опять же по принципу "хотели как лучше" (чтоб доместик был нормальный, как у всех (в Interchange and Service Fees, April 2004, раздел 4 Clearing Guidelines, Determining the Fee Program написано гениально простое правило: (Если) European issuer (country A)+ European merchant (country A)+ European acquirer (country A)+No bilateral agreement, то =Domestic) ,
      а получилось "как всегда" (при выполнении всех этих условий еще надо лезть в некий список и судорожно проверять по нему банк-эмитент)

      Тогда нам проще будет не опираться на доместик, а ставить в SH6 код 'E'. Пусть все будет по внутриевропейским ставкам, зато без ошибки

      Комментарий


      • #4
        Гм, я честно говоря, надеялся, что есть некий (может быть, не вполне официальный ;-) документ, где сформулировано ПРАВИЛО.

        Жизнь сложнее правил Опять же - откуда мы узнаем про bilateral и кто нам будет давать регулярные обновления таблиц?

        ИМХО, есть ряд таблиц, которые регулярно обновляются и присылаются Мастеркардом. Их мы обрабатываем и живём спокойной жизнью. Всё остальное - неформализовано и служит потенциальным источником ошибок и геморроя. Поэтому делаем так, как проще нам [разработчикам] или выгоднее нашему бизнесу [если он сумеет нас убедить, что доходы от реализации превысят расходы на разгребание геморроя]
        --* Never say never again...

        Комментарий


        • #5
          Про двусторонние договоренности мы должны знать сами (это же договоренности между нашим банком и конкретным эмитентом, зарегистрированные в Европее. Я правда, не знаю ни одного российского банка, который зарегистировал в Европее bilateral-договор ;-)
          А вот про таблицы...
          Я-то имел в виду конкретную вещь: когда делался российский доместик, то делом представительства и ассоциации было обеспечить распространение его на все российские банки (как это делалось по всей Европе), тогда и действовало бы простое правило, процитированное мною и присутствующее в Interchange Fee мануале. А доместик российский вводился ... мы сами знаем как... и до сих пор полностью, насколько мне известно, не введен - не все банки договорились со сбером и проч.
          Вот в итоге и получается, что, была ли конкретная транзакция рассчитана по доместику, мы узнаем только получив Detailed Position и посмотрев в нем Settlement Group Identification. Заранее это точно знать не есть возможно.

          Комментарий


          • #6
            AlexYe Заранее это точно знать не есть возможно.
            Абсолютно согласен.
            Правда, можно на основе анализа DP (пары сообщений с Format Code P1-P3) составить табличку институтов, расчитывающихся через рубли) и добавлять в неё записи при обработке очередного DP. И удалять неправильные записи при обработке отчета Rejected/Corrected Items. Получается вполне устойчивый алгоритм. Но всё равно это кривое решение. By design.
            --* Never say never again...

            Комментарий


            • #7
              Ну да...

              Кстати- это уже из свежего опыта, - мы попытались на приеме сообщений (эмитентом) определять региональность на основе ныне преобразованного поля SH6, заполняемого эквайером. Там второй байт должен указывать на региональность операции (собственно, необходимостью его заполнения на стороне эквайера и был вызван мой вопрос в сабже).
              Европей честно указал в релизе, что он будет проверять в SH6 только последние байты (третий-четвертый) - это Interchange Rate Designator. То есть корректность второго байта (региональность) - сугубо на совести эквайера.
              Так вот, когда мы его поанализировали в сообщениях, принятых после 1 октября, там поперло такое... что идею определять региональность во входящих сообщених по SH6 мы сразу в ужасе похерили. Нельзя так нельзя - то есть, надо ждать до Detailed Position.

              Комментарий

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

              Свернуть

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

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