Skip to main content

Как работает банк со своими корреспондентами по SWIFT

Итак, наш банк имеет открытые корреспондентские счета в США (CITIBANK N.A. NEW YORK), в Европе (VTB BANK DEUTSCHLAND AG), в России (Промсвязьбанк Москва и Собинбанк Москва).

как работает оператор платежей SWIFT


Соответственно, все расследования по платежам происходят через эти банки согласно  установленным корреспондентским отношениям с использованием соответствующих форматов SWIFT MT-195/295, MT-196/296, MT-199/299 и MT-192/292

Кроме прямых корреспондентских отношений с банками, нашим банком установлены отношения и с другими финансовыми организациями через процедуру обмена ключами, что даёт возможность использовать SWIFT-форматы МТ-195, МТ-196 и МТ-199 для проведения процедуры расследования по стандартным платежам и платежам с покрытием:

- DEUTSCHE BANK TRUST COMPANY AMERICAS USA
- COMMERZBANK AG Germany
- CITIBANK N.A. London
- CITIBANK N.A. Brussels
- BANQUE DE COMMERCE ET DE PLACEMENTS S.A. Geneva
- NORVIK BANKA JSC  LV
- ABLV BANK AS  LV

В среднем процедура расследования занимает от 3 до 14 дней (если необходимо уточнить детали платежа: счёт получателя или наименование).

Многое зависит от колличества банков, которые задействованы в трафике платежа. Для
решения проблем используется переписка с банками-корреспондентами, контакт с кураторами счёта в соответствующих банках.Можно использовать Free Format MT-995/999, направляя их напрямую в банк-отправителя (при входящих платежах).

При необходимости можно контактировать с клиентами банка, а по возможности вступить в переписку с отправителями средств.

Что касается наиболее сложных ситуаций, то они связаны с процессом возврата ошибочно отправленных средств, а также со средствами, которые были отправлены банком, но не получены бенефициаром.

В некоторых случаях, это занимало достаточно времени, так как приходилось использовать все доступные инструменты:
- вести длительные переписки и общение как с банками, так и с клиентами, таким образом достигая позитивный результат.

По срокам, наиболее быстро решаются проблемы с банками Еврозоны и США.

Более сложно решать вопросы с Азиатскими банками (например, китайские банки не всегда идут на контакт) или Россией (связано с особенностями документооборота и не
всегда использованием SWIFT для быстрой передачи информации).

Popular posts from this blog

Сбербанк и дропы с площадки Dark Money, и кто кого?

Крупных открытых площадок в даркнете, специализирующихся именно на покупке-продаже российских банковских данных, обнале и скаме около десятка, самая большая из них – это Dark Money . Здесь есть нальщики, дропы, заливщики, связанный с ними бизнес, здесь льют и налят миллионы, здесь очень много денег, но тебе не стоит пока во все это суваться. Кинуть тут может любой, тут кидали и на десятки миллионов и на десятки рублей. Кидали новички и кидали проверенные люди, закономерности нету. Горячие темы – продажи данных, банковских карт, поиск сотрудников в скам и вербовка сотрудников банков и сотовых операторов, взлом аккаунтов, обнал и советы – какими платежными системы пользоваться, как не попасться милиции при обнале, сколько платить Правому Сектору или патрулю, если попались. Одна из тем – онлайн-интервью с неким сотрудником Сбербанка, который время от времени отвечает на вопросы пользователей площадки об уязвимостях системы банка и дает советы, как улучшить обнальные схемы. Чтобы пользова

Перехват BGP-сессии опустошил кошельки легальных пользователей MyEtherWallet.com

Нарушитель ( реальный заливщик btc и eth ) используя протокол BGP успешно перенаправил трафик DNS-сервиса Amazon Route 53 на свой сервер в России и на несколько часов подменял настоящий сайт MyEtherWallet.com с реализацией web-кошелька криптовалюты Ethereum . На подготовленном нарушителем клоне сайта MyEtherWallet была организована фишинг-атака, которая позволила за два часа угнать 215 ETH (около 137 тысяч долларов) на кошельки дропов. Подстановка фиктивного маршрута была осуществлена от имени крупного американского интернет-провайдера eNet AS10297 в Колумбусе штат Огайо. После перехвата BGP-сессии и BGP-анонса все пиры eNet, среди которых такие крупнейшие операторы, как Level3 , Hurricane Electric , Cogent и NTT , стали заворачивать трафик к Amazon Route 53 по заданному атакующими маршруту. Из-за фиктивного анонса BGP запросы к 5 подсетям /24 Amazon (около 1300 IP-адресов) в течение двух часов перенаправлялись на подконтрольный нарушителю сервер, размещённый в датацентре п

DDOS атаки на маршрутизатор и методы защиты Juniper routing engine

По долгу службы мне часто приходится сталкиваться с DDOS на сервера, но некоторое время назад столкнулся с другой атакой, к которой был не готов. Атака производилась на маршрутизатор  Juniper MX80 поддерживающий BGP сессии и выполняющий анонс сетей дата-центра. Целью атакующих был веб-ресурс расположенный на одном из наших серверов, но в результате атаки, без связи с внешним миром остался весь дата-центр. Подробности атаки, а также тесты и методы борьбы с такими атаками под катом.  История атаки Исторически сложилось, что на маршрутизаторе блокируется весь UDP трафик летящий в нашу сеть. Первая волна атаки (в 17:22) была как раз UDP трафиком, график unicast пакетов с аплинка маршрутизатора: и график unicast пакетов с порта свича подключенного к роутеру: демонстрируют, что весь трафик осел на фильтре маршрутизатора. Поток unicast пакетов на аплинке маршрутизатора увеличился на 400 тысяч и атака только UDP пакетами продолжалась до 17:33. Далее атакующие изменили стратегию и добавили к

Сброс BGP-сессии при помощи TCP Connection Reset Remote Exploit

Уже ни раз рассказывал о протоколе ТСР , так что повторятся особо не буду, напомню лишь основные положения: Transmission Control Protocol описывается в RFC 793 и преимуществом его является надежность передачи данных от одной машины к другому устройству по сети интернет. Это означает, что ТСР гарантирует надежность передачи данных и автоматически определит пропущенные или поврежденные пакеты. Что для нас важно из его конструкции? В общем виде заголовок ТСР пакета выглядит так: Программа передает по сети некий буфер данных, ТСР разбивает данные на сегменты и дальше упаковывает сегменты в наборы данных. Из наборов данных формируются пакеты и уже они передаются по сети. У получателя происходит обратный процесс: из пакетов извлекаются набор данных, его сегменты, затем сегменты передаются в ТСР стек и там проверяются, потом собираются и передаются программе. Sequence numbers Данные разбиваются на сегменты, которые отдельными пакетами направляются по сети получателю. Возможна ситуация, к

Как найти реального заливщика

Своего первого реального заливщика, который показал мне как можно скачать деньги в интернет с банковских счетов, я нашел случайно, когда еще трудился в Укртелекоме сменным инженером немного подрабатывая продавая трафик налево , но потом этот человек отошел от дел в связи со слишком уж скользкой ситуацией в данной сфере, и я решил поискать партнера на форумах, разместив рекламу на трёх электронных досках объявлений. Честно говоря поначалу даже был готов сразу закинуть 500 000 гривен в Гарант, но потом призадумался, а стоит ли? Ко мне начал обращаться народ обращается разных категорий 1. Дебильная школота, которая что-то любит повтирать про свою серьезность и просит закинуть 10 000 USD им на Вебмани в качестве аванса  2. Реальные мэны, которые  льют сразу большую сумму по SWIFT  без разговоров про гарантии и прочую шнягу, но после того, как им отдаёшь нал, они сразу пропадают, суть данных действий я так и не понял. зачем пропадать, если всё прошло гладко? 3. Мутные личност

Обзор внутренней инфраструктуры безопасности Google

Обычно компании предпочитают хранить в тайне особенности своей инфраструктуры безопасности, которая стоит на защите дата-центров, полагая, что раскрытие подобной информации может дать атакующим преимущество. Однако представители Google смотрят на этот вопрос иначе. На то есть две причины. Во-первых, публикация таких отчетов позволяет потенциальным пользователям Google Cloud Platform (GCP) оценить безопасность служб компании. Во-вторых, специалисты Google уверены в своих системах безопасности. На днях компания обнародовала документ Infrastructure Security Design Overview («Обзор модели инфраструктуры безопасности»), в котором Google достаточно подробно описала свои защитные механизмы. Инфраструктура разделена на шесть слоев, начиная от аппаратных решений (в том числе физических средств защиты), и заканчивая развертыванием служб и идентификацией пользователей. Первый слой защиты – это физические системы безопасности, которые просто не позволяют посторонним попасть в дата-центры. Эта част