9 марта, вторник 04:37
Bankir.Ru

Объявление

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

Фрод и автоматическая борьба с ним

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

  • Фрод и автоматическая борьба с ним

    Товарищи :-) имеется возможность улучшить срвис банка и сделать следующее.
    Как многие тут наверное уже столкнулись с дубликатами которые приходят в клиринге от acquirer ов. Клиент обычно в таких ситуациях винит свой банк а не тот который предоставляет услуги для точек/банкоматов и тд. Так вот идея такая. Есть возможность не лазия в код при загрузке клиринга проверять такие дубликаты и к примеру класть их на разбор в отдел претензионной работы (не постируя на карту и не кидая 2-ую смску клиенту о списании). Вопрос - как обычнотакие ситуации разруливаются? Скорее всего придет отмена в том же клиринге - вопрос когда. Опять же с точки зрения бухгалтерии деньги списаны по тому же VSS/MC.
    Это первый вариант которым я займусь но вот почитав ветки о претензионке хочется понять какие еще фроды распространены? И отсеять их таким же образом скинув ответственность на отдел претензионки. Короче - можно примеры наиболее распространенных случаев в студию? Мне пока видится следующее:
    1) операции с 38 полем = 000000 или пустым.
    2) опреации по карте с сервискодом х2х без авторизации.
    3) ...
    спасибо :-)

  • #2
    TSprinter,
    Что-то перечисленное Вами вовсе и не фрод

    Возвращаясь к Вашему вопросу:
    Вопрос - как обычно такие ситуации разруливаются?
    Какие "такие"? вопросы очевидного единичного повторного списания? cbk RC82, но в отдельных случаях принимаются отдельные меры.

    Вы хотите автоматизировать претензионную работу?

    Комментарий


    • #3
      >> Вы хотите автоматизировать претензионную работу?
      Не всю а ее "очевидную" часть.

      >> cbk RC82
      А по мастеру? И через какое время выставляется CB?

      >> Что-то перечисленное Вами вовсе и не фрод
      Почему же? Оффлайн операции на карту на которую они запрещены - не фрод?

      >> операции с 38 полем = 000000 или пустым.
      Некие эджастменты которые высылает сторонний банк и они ложатся как лишние на карту после чего держатель карты винит свой банк... Может это и не фрод но хотябы оповещать претензионку можно перед тем как сообщать об этом клиенту.

      Вы бы лучше мне подсказали куда смотреть если есть опыт претензионки.

      Комментарий


      • #4
        TSprinter, А по мастеру?
        4834

        И через какое время выставляется CB?
        Зависит от "прочих благоприятных".

        Оффлайн операции на карту на которую они запрещены - не фрод?
        а, вот вы про что... смотрите в VIOR ID#: 010410-010410-0024659 и ID#: 010410-010410-0024658

        а что, если клиент въехал на арендованном автомобиле в г. Осло через платный терминал, оплаив картой с svc = x2x, абсолютно не зная технологии безавторизационных списаний. Вы, по собственному домыслу эту операцию опротестовали, эквайер сообщил в полицию о том, что оплата въезда не правомочна, полиция наложила штрафные санкции на прокатную конотору, которая по договору списана сумму штрафа с клиента, уведомив его должным образом о том, ввиду чего был наложен штраф. И вот клиент Вам пишет, дескать, оплачивал 7 евро, а полиция говорит, что не оплатил, поэтому налагает штраф 10 000 евро. Что здесь фрод, ну, кроме Ваших действий?

        Вы бы лучше мне подсказали куда смотреть
        Давайте для начала сформулируем задачу. В правильно заданном вопросе половина ответа. Вы чего хотите: нотификации по определённому роду операций, формирования проводок по определённым полученным транзакциям или формирования определённых транзакций в результате обработки клиринга?
        Если первое и второе настраивается (если я правильно догадался о какой платформе идёт речь) за 15 минут, то третье противоречит VIOR ID#: 171009-171009-0003287.

        Комментарий


        • #5
          Речь о обработке файлов клиринга перед тем как постировать их на карты (провести по счетам) а не о автогенерации претензионки. Навеяло недавним спамом от сбербанка.
          Нет вы не догадались о какой платформе идет речь поверьте мне. Это не Вей4 и не ТР2 и их аналоги.
          Надо начать с оповещений - я это уже сделал. А дальше видно будет. Опять же СБ можно слать автоматом но думаю не стоит. Нужно отслеживать кейсы в течении сроков (30/45 дней) Хотя и это реализуемо.
          Задача достаточно проста. Хочется снять ответственность отдела процессинга с операций по претензионной работе по максимуму. Это проще всего делается в схеме которую я описал... Т.е. скидывать операции в банк (статус) и давать разбирать их отделу претензионной работы. Это сейчас у нас так происходит на ежедневной основе.

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

          Вопрос как Вы понимаете я не могу сформулировать точно и в цель потому как во первых мало опыта а во вторых считаю что я очень точно его задал. Вы же зацепились за реализацию а не за ее схему...
          Последний раз редактировалось TSprinter; 14.12.2010, 00:05.

          Комментарий


          • #6
            TSprinter, Речь о обработке файлов клиринга перед тем как постировать их на карты
            Вооот, это уже понятнее. Да, можно и операции без активной авторизации в системе, и OC, и прочие приятности отражать по диспутному счёту с целью разбора каждой операции отдельно, однако у всего есть подводные камни:
            Вы деавтоматизируете массу ненужной механической работы живым сотрудникам, что сделает человеческий фактор более значимым, потребует увеличение штата и ФОТ.
            Почему бы не подойти к вопросу с обратной стороны: разделить операцию загрузки файла с операцией отражения по счетам и мониторить входящие транзакции после загрузки перед отражением, а уж по-Вашему спорные операции помечать к разбору и не отражать по счетам клиентов. С недавними массовыми повторными списаниями процедура показала себя нетрудозатратной и эффективной.

            Считаю не кошерным всё под одну гребёнку сваливать на диспутный счёт для дальнейшего разбора.

            Комментарий


            • #7
              Что есть ОС? Не понял :-)

              Что есть прочие приятности? :-)))

              Я собственно об этом спрашиваю а не о том как это реализовать. Все подряд никто валить на диспутный счет не собирается :-)

              Комментарий


              • #8
                TSprinter, Что есть ОС?
                Original Credit. Встречаются кредитовые транзакции, на которые следом приходят ревёрсалы, а держатель эти денежки уже успевает потратить.

                Что есть прочие приятности?
                Рассказать, что Вам проверять я не смогу, всё же политика рисков индивидуальная. Думаю, для проверки Вас заинтересуют все операции без авторизации (в случае если система не находит активную авторизацию), туда же попадут случаи списания с иными реквизитами, которые не разблокируют сумму. Операции по несуществующим/заблокированным картам. Можете сделать подборку регионов, МСС, сумм, по которым будете проверять, допустимое количество операций по одной карте, по одной точке, по одному эквайеру, по одному городу, по одной стране, смоделируйте поведение, выберите нетипичные операции, постройте систему скоринга. Если выпускаете чиповые карты, проверяйте фолбэки. Если вовремя не решить для себя, что важно, а что нет, можно придумать работы на 26 часов в сутки
                Однако не проще ли действительно пойти от обратного и получит ТЗ от безопасников и претензионщиков о том, что они хотят?

                Комментарий


                • #9
                  Спасибо большое. Теперь начинаю понимать...

                  Сообщение от Иван Федотов Посмотреть сообщение
                  Что есть ОС?
                  Original Credit. Встречаются кредитовые транзакции, на которые следом приходят ревёрсалы, а держатель эти денежки уже успевает потратить.
                  Это в случае реверсала по банкомату когда внесли наличные - и откатывают их дебетом? Клиент уйдет в овер... Либо откатывают возврат товара... В других случаях это начисление:
                  И если он их потратил то мы должны ему начислить денег... И?

                  Сообщение от Иван Федотов Посмотреть сообщение
                  Что есть прочие приятности?
                  Думаю, для проверки Вас заинтересуют все операции без авторизации (в случае если система не находит активную авторизацию), туда же попадут случаи списания с иными реквизитами, которые не разблокируют сумму. Операции по несуществующим/заблокированным картам. Можете сделать подборку регионов, МСС, сумм, по которым будете проверять, допустимое количество операций по одной карте, по одной точке, по одному эквайеру, по одному городу, по одной стране, смоделируйте поведение, выберите нетипичные операции, постройте систему скоринга. Если выпускаете чиповые карты, проверяйте фолбэки.
                  Подумаю... :-) Спасибо.

                  Сообщение от Иван Федотов Посмотреть сообщение
                  Однако не проще ли действительно пойти от обратного и получит ТЗ от безопасников и претензионщиков о том, что они хотят?
                  [/QUOTE]

                  Ну это в процессе ессно.

                  Комментарий


                  • #10
                    TSprinter, Это в случае реверсала по банкомату
                    неа, это когда первоначально приходит, скажем, ТС06 а на завтра приходит ТС26.

                    Комментарий

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