мци что это такое
Информация для клиентов Банка России при подключении к электронному обмену
Общая информация для клиентов Банка России при подключении к электронному обмену
(материал для клиентов Банка России, заключающих комплексный договор)
(материал для клиентов Банка России, заключающих комплексный договор или договор обмена)
(материал для клиентов Банка России, заключающих комплексный договор или договор обмена)
(материал для клиентов Банка России, заключающих комплексный договор или договор обмена)
(материал для клиентов Банка России, заключающих комплексный договор или договор обмена)
(материал для клиентов Банка России, заключающих комплексный договор или договор обмена)
Дополнительная информация для клиентов Банка России Московского региона при подключении к электронному обмену
(материал для клиентов Банка России, заключающих договор обмена)
(материал для клиентов Банка России, заключающих договор обмена)
(материал для клиентов Банка России, заключающих договор обмена)
(материал для клиентов Банка России, заключающих договор обмена)
(материал для клиентов Банка России, заключающих договор обмена)
(для отдельных категорий клиентов Банка России)
(материал для клиентов Банка России, заключающих договор обмена)
(материал для клиентов Банка России, заключающих договор обмена)
(материал для клиентов Банка России, заключающих договор обмена)
(материал для клиентов Банка России, заключающих договор обмена)
(материал для клиентов Банка России, заключающих договор обмена)
Сертификаты ключей Банка
(материал для клиентов Банка России, заключающих комплексный договор или договор обмена)
(материал для клиентов Банка России, заключающих комплексный договор или договор обмена)
(материал для клиентов Банка России, заключающих комплексный договор или договор обмена)
Сертификаты тестовых ключей Банка
(материал для клиентов Банка России, заключающих комплексный договор или договор обмена)
(материал для клиентов Банка России, заключающих комплексный договор или договор обмена)
Мци что это такое
Московский центр искусств
Межбанковский центр информации
Словарь: С. Фадеев. Словарь сокращений современного русского языка. — С.-Пб.: Политехника, 1997. — 527 с.
Межрегиональный центр информатизации
Смотреть что такое «МЦИ» в других словарях:
Нѣмци — Немцы нѣмци (1) 1. Народ, населяющий немецкую землю; германцы: Ту Нѣмци и Венедици, ту Греци и Морава поютъ славу Святъславлю, кають князя Игоря. 22. Афетово бо и то колѣно: варязи, свеи, урмане, готе, русь, агняне, галичане, волъхва, римляне,… … Словарь-справочник «Слово о полку Игореве»
нѣмьци — НѢМЬЦ|И (138), Ь с. мн. 1. Наименование людей, говорящих на непонятном языке. Зд. О чужестранцах, о врагах: Агисилаосъ ре(ч) Нѣкто перескокъ прииде къ немѹ из нѣмець а властителемъ велѧщемъ емѹ порѹчити вои своѥ. и ре(ч) не по(д)баеть порѹчити… … Словарь древнерусского языка (XI-XIV вв.)
Гориславличь — отчество от Горислав; здесь как прозвище (1): Тогда при Олзѣ Гориславличи сѣяшется и растяшеть усобицами; погыбашеть жизнь Даждь Божа внука; въ княжихъ крамолахъ вѣци человѣкомь скратишась. 16 17. Ср. Гориславичь. 1229: Томь же лѣтѣ поиде князь… … Словарь-справочник «Слово о полку Игореве»
перевѣтьникъ — ПЕРЕВѢТЬНИК|Ъ (3*), А с. Изменник: То(г) же лѣ(т). поiде кн҃зь олександръ на нѣмци на городъ копорью… i взѧ городъ. а нѣмци приведе в новъгородъ. а инѣхъ пѹсти по своеи воли. а вожанъ. и чюдцю перевѣтникы извѣша. ЛН ок. 1330, 128 об. (1241); i… … Словарь древнерусского языка (XI-XIV вв.)
подъвести — ПОДЪВЕ|СТИ (6*), ДОУ, ДЕТЬ гл. 1.Предоставить в чьел. распоряжение: азъ хотѣхъ тѧ жерца ѹстроити. и всего мир(а) жертвы подъ тѧ подъвести. ПрЮр XIV2, 57в. 2. Подстрекнуть, побудить выступить: пльсковiци же тъгда бѧхѹ подъвегли нѣмьци и чю(д).… … Словарь древнерусского языка (XI-XIV вв.)
Лошак, Марина Девовна — Марина Лошак Род деятельности: куратор, галерист, арт менеджер, искусствовед, коллекционер, музейный работник Дата рождения: 22 ноября 1955(1955 11 22) (57 лет) … Википедия
Московский дом национальностей — Тип Государственное бюджетное … Википедия
Мурман — название части побережья Сев. Ледовитого океана, а также его жителей, др. русск. урмане норвежцы (Лаврентьевск. летоп.), Мурманские нѣмци сев. народы, которые в союзе со свеянами воевали против русских (Жит. Александра Невского 35), нурмане… … Этимологический словарь русского языка Макса Фасмера
Межрегиональный центр информатизации при ЦБ не справился с объемами платежей
24 декабря Межрегиональный центр информатизации (МЦИ) при Банке России, в сферу ответственности которого входит организация системы электронных расчетов между банками, сообщил о смене своего руководства. В соответствии с приказом ЦБ новым директором центра назначен Сергей Гришкин, а экс-руководитель Владимир Петровский ушел в отставку. Об этом сообщила газета «Коммерсант».
В МЦИ и Банке России комментировать эту информацию отказались. Однако «Коммерсант» располагает данными о том, что в МЦИ все же знают о существовании проблемы с проведением платежей в Московском регионе. 17 декабря замдиректора МЦИ Александр Елагин направил телеграмму в адрес «руководителя кредитной организации, ответственного за передачу информации». В телеграмме, в частности, говорится о «невозможности соединения с узлом передачи данных и, как следствие, несвоевременности получения абонентами справок на переданные в МЦИ реестры направленных платежей». Правда, по мнению Елагина, виноваты в этом сами банки, которые «неравномерно направляют платежи на обработку в МЦИ».
ЦБ пытается распределить потоки платежей при помощи тарифов. Так, если банк отправляет деньги первым рейсом, то за обработку одного платежного поручения он заплатит ЦБ всего 2,40 руб., за второй рейс — уже 3,60 руб., третий и четвертый рейсы обойдутся в 4,80 и 7,20 руб. соответственно.
Но специфики работы компаний основной поток платежей приходится на третий и четвертый рейсы.
Начальник управления корсчетов и расчетов Промсвязьбанка Марина Конюхова говорит, что поток платежей увеличивается в декабре каждый год, что связано в первую очередь с переводами бюджетных средств.
Представитель крупного российского банка объясняет, что операционная система МЦИ рассчитана на обработку 1 млн платежей в день. Сейчас же, по его данным, в день приходится обрабатывать 1,2—1,3 млн платежей.
Финансовая сфера
В конце марта в Ассоциации российских банков прошел семинар «Новый уровень операционного взаимодействия с Банком России», организаторами которого выступили Московский банковский союз Банка России и компания «Комкор». Среди московских банкиров создание коллективного центра обработки информации (КЦОИ) обсуждалось давно, и страсти, что называется, накалились, а потому желающих принять участие в семинаре оказалось в два раза больше, чем мог вместить зал: из 160 организаций, подавших заявки, только 80 удалось туда попасть. На семинаре представителям банковских организаций рассказали об особенностях обработки платежной информации в КЦОИ в Москве с использованием ТПК «РАБИС НП».
В централизации сила и экономия
Консолидацию вычислительных ресурсов Банк России начал несколько лет назад. Ранее платежная система РФ насчитывала 78 центров обработки данных, построенных на абсолютно разных программах-платформах с использованием различных прикладных программных продуктов. Поэтому было решено хаотичную систему привести к единому образцу. В прошлом году были созданы два коллективных центра обработки информации — в Нижнем Новгороде (КЦОИ-1) и в Санкт-Петербурге (КЦОИ-2), за каждым из которых закреплена группа регионов. Намечалось, что Московская область присоединится к нижегородскому КЦОИ-1. Однако по реализации проекта возникло множество сомнений. Дело в том, что Москва обрабатывает порядка миллиона платежей ежедневно, что составляет треть от общего количества платежей, обрабатываемых системой Банка России, а по общему объему расчетов в этих платежах содержится больше 70% всех средств. В конце прошлого года было решено заменить АСБР «Москва» на КЦОИ Московского региона.
Директор Межрегионального центра информатизации Банка России (МЦИ Банка России) Сергей Гришкин отметил достоинства новой системы: «КЦОИ позволит существенно сократить затраты на сопровождение путем оптимизации технической инфраструктуры. Вполне очевидно, что когда ресурсы сосредоточены в одном месте, требуется меньше специалистов и легче осуществлять сопровождение и управление. Кроме того, проще решать вопросы, связанные с безопасностью и надежностью функционирования системы».
Именно для обеспечения надежности и катастрофоустойчивости в Московском регионе будет построено сразу два центра — основной и резервный. Основной центр обработки будет находиться в Тушино, а второй — в 130 километрах от Москвы. При возникновении чрезвычайных ситуаций обработка может быть переведена из одного центра в другой.
В Москве не как у всех
За основу специалисты МЦИ взяли РАБИС-НП и внесли в него изменения, учитывая особенности платежной системы Московского региона.
Основное отличие столичной платежной системы закреплено в положении 18-П «Технология многорейсовой обработки платежей». Согласно этому документу московские банки в течение дня могут пять раз отправлять платежи в МЦИ в строго определенное время. МЦИ, в свою очередь, обрабатывает полученную от банков информацию о списании и зачислении платежей и отправляет ее обратно. В регионах практикуется режим on-line, то есть платежи не накапливаются, а обрабатываются по мере поступления. В Московском регионе было решено сохранить существующий принцип как наиболее приемлемый для столичного объема работы.
Вторая особенность заключается в том, что столичные транспорт и АРМы не являются типовыми. Поддержка этих решений требует специальных ресурсов и серьезных затрат, поэтому для оптимизации процесса дальнейшая стратегия развития банковской системы будет выстроена на сведении к единому образцу программных средств. Отсюда вытекает одна из основных задач — перевод существующих абонентов «Астра», «Фаст-инфо-2» и «Фаст-инфо-3» на СВК (типовая транспортная система взаимодействия с клиентом).
По словам Сергея Гришкина, переход будет осуществляться поэтапно.
Сейчас четыре крупнейших добровольца — Сбербанк, Межбанковская валютная биржа, банки «Петрокоммерц» и «Авангард» — подключены к стенду для прохождения тестирования и ознакомления. После завершения апробации начнется двухступенчатый переход остальных банков. Первыми на СВК перейдут 42 банка, которые сегодня работают с транспортом «Фаст-инфо-3». Намечен этот этап ориентировочно на июль 2008 года. А в следующем году их примеру последуют банки, работающие с «Фаст-инфо-2» и «Астра».
На данном этапе, по замечанию заместителя директора МЦИ Алексея Данилова, кредитные организации могут действовать по своему усмотрению. Если банк все устраивает в работе, то до тех пор, пока не подошло по графику время перехода на СВК, он может ничего не изменять. Для осуществления деятельности будет предоставлена модифицированная программа «Конва». Однако старые программы, как известно, не всегда справляются с поставленными задачами. Банки, которые участвуют в БЭСПе (сегодня их порядка десяти), первыми столкнулись с тем, что действующий региональный транспорт не ориентирован на технологию работы с каждым сообщением в отдельности. Поэтому существующие версии пришлось немного доработать. Но в дальнейшем для работы в БЭСПе от файлового обмена придется отказаться. СВК как раз обеспечит решение этой задачи. При желании банк может проявить инициативу и досрочно перейти на СВК.
Система реального времени
В РАБИС-НП так же, как и в АСБР «Москва», будет реализована проверка на возможность оплаты документа с учетом встречных поступлений. Результаты этих обработок будут поступать к абонентам в виде реестра проведенных платежей пять раз в день по итогам рейсов.
РАБИС в Москве не ведет очередей документов непрерывной обработки. Если поступил платеж и на него не хватает средств, он не ставится в очередь, а будет сразу отвергнут с формированием сообщения об ошибке. В тот момент, когда на стороне московской платежной системы прошла транзакция, кредитной организации-получателю приходит ответный электронный документ, в котором указаны его кредитовые поступления. Раньше уведомление надо было либо запрашивать принудительно, либо дожидаться реестра проведенных платежей по итогам рейса.
Обработка в режиме МОП имеет также некоторые особенности. Вначале проводится логический контроль пакета, если в пакете обнаружены какие-то ошибки, отправляется извещение, и на этом операции заканчиваются. Если с пакетом все в порядке, то отправитель получает сообщение о состоянии пакета. Это извещение, в отличие от квитанции, которую получают сейчас, формируется не на транспорте, а уже внутри платежной системы.
Следующий этап обработки внутри РАБИС-НП — это логический контроль документов, входящих в пакет, который будет происходить сразу при поступлении. Разработчики обещают, что для реестров длиной 5000 документов время отклика не должно составить больше двух минут.
В итоге кредитная организация получает пакет ЭСИД, содержащий либо положительное, либо отрицательное подтверждение о результатах контроля документов.
Главное преимущество этой системы заключается в том, что весь логический контроль документов будет происходить в режиме реального времени, и головная боль о том, прошел или нет пакет, отправленный за минуту до закрытия последнего рейса, частично «излечится».
Заместитель начальника отдела МЦИ Дмитрий Клионский также предупредил, что реестр проведенных платежей будет иметь несколько иной вид. Теперь каждая логическая группа документов будет доставляться в отдельном файле. То есть по итогам рейса поступает пакет зачисленных и списанных ЭПД в режиме МОП, в режиме НОП, отдельно прошедших по системе БЭСП, и пакет ЭСИД, в котором будут подтверждения дебета, кредита, промежуточная выписка, извещение о состоянии отложенных и отозванных ЭПД и извещение о группе аннулированных платежей. Эти сведения будут поступать по итогам каждого рейса. Кроме того, в отличие от действующей сейчас технологии пакеты ЭПД и ЭСИД будут содержать документы по всем счетам кредитной организации. Сейчас пакеты составляются по каждому счету отдельно. Пятый рейс будет включать еще дополнительный ЭСИД — окончательную выписку по итогам дня, содержащую входящий остаток на день, исходящий остаток на день и информацию о прошедших ЭПД. ЭСИД формируются по каждому счету организации.
Еще один нюанс связан с использованием IBM WebSphere MQ. Дело в том, что по каналам IBM WebSphere MQ, больше 100 мегабайт в одном сообщении передано быть не может. Поэтому те электронные сообщения, которые превышают указанный объем, могут быть разбиты на части. И эти части должны быть собраны воедино уже на клиентской стороне самостоятельно. Для ясности фрагменты будут пронумерованы и на каждом из них проставлены реквизиты, по которым легко можно установить их принадлежность.
От технологии к реалиям
Банкиров также интересовал вопрос, позволит ли РАБИС-НП повысить скорость обработки реестра платежей. Ни для кого не секрет, что в часы пик банки нередко сталкиваются с проблемой проведения электронных платежей.
Директор МЦИ Сергей Гришкин прокомментировал эту ситуацию так: «Время подготовки реестров не зависит от транспортной системы – это время, которое расчетная система занимает на клиринг и изготовление отчетных форм. Действительно, в начале и в середине декабря были трудности, вызванные ростом нагрузки, но мы сумели оптимизироваться, и уверяю вас, что в мае такого не ожидается. Что касается РАБИС-НП, тут нам сложно составить прогноз, потому что эта технология адаптированная, она еще нигде не эксплуатировалась. У нас нет опыта, на основании которого мы могли бы сделать выводы, и нагрузочного тестирования пока не проводилось. Но мы уверены, что все будет происходить в регламентное время».
Также Сергей Гришкин обратил внимание на тот факт, что сбои могут возникать по разным причинам. Если аварийная ситуация произошла по вине МЦИ, то обычно рейсы продлеваются и автоинформатор об этом сообщает. Если это индивидуальная ситуация, которая происходит в конкретном банке, МЦИ не может действовать вопреки нормативному документу и изменять рейс. Поэтому кредитной организации придется самостоятельно искать выход из сложившейся ситуации.
Банки, в свою очередь, предпринимают меры для повышения надежности прохождения платежей. Так, в МЦИ поступила заявка от Сбербанка об использовании каналов доступа для соединения с МЦИ при помощи двух провайдеров. Еще несколько банков также заявили, что рассматривают подобный вариант.
Сегодня у кредитных организаций появилась возможность технически реализовать эту идею. Долгое время монопольное положение в этой сфере занимала компания «Инкома». Для предоставления услуг подключения к МЦИ компаниям-провайдерам предъявляются очень высокие технические требования и не все их в состоянии выполнить. Например, каналы связи абонентов и телекоммуникационных серверов МЦИ должны быть изолированы от других публичных сетей. Кроме того, провайдер должен обеспечить независимое подключение к двум территориально удаленным технологическим площадкам МЦИ, а это требует серьезных финансовых вложений в инфраструктуру. К тому же это направление развития бизнеса не для всех компаний представляет интерес, так, МЦИ исходящий трафик предоставляется бесплатно. Теперь на рынке появился второй провайдер — компания «Комкор». МЦИ высказывает свое одобрение и готово рассмотреть возможность обслуживания банка двумя провайдерами.
Олег Кравченко, руководитель направления систем связи компании КРОК
Задача привлечения и удержания розничных клиентов определяет интерес банков к системам, повышающим качество обслуживания и обработки поступающих запросов. Поскольку телефонная связь является одним из основных каналов общения с частными лицами, банки создают центры обработки вызовов, колл-центры. Это позволяет не только увеличить долю обслуженных обращений и расширить спектр предлагаемых услуг, но и уменьшить нагрузку на операторов. К примеру, в результате запуска территориально распределительного центра телефонных продаж и консультаций Русского банка развития операторы банка стали принимать и отслеживать в несколько раз больше запросов от клиентов. Также расширился список услуг, которые ежедневно могут получать клиенты банка по телефону. Это решение наши специалисты реализовали на базе технологий Avaya.
Стремясь оказаться ближе к своему потребителю, банки не только наращивают функционал услуг, но и активно идут в регионы, открывают новые представительства. Эффективным инструментом в случае роста филиальной сети является IP-телефония. Эта технология имеет ряд неоспоримых функциональных преимуществ по сравнению с традиционной связью. Главное среди них — существенное сокращение затрат на обслуживание и поддержку трафика. Как следствие — значительная часть IТ-проектов банков связана с модернизацией телекоммуникационной инфраструктуры.
Другое инфраструктурное решение, эффективно решающее коммуникационные и управленческие задачи при наличии широкой филиальной сети, – системы видеоконференцсвязи. В последние годы банки все активнее начинают использовать его в своей работе и не только для общения с партнерами. Например, созданная специалистами КРОК в Альфа-Банке система ВКС, изначально предназначенная для задач топ-менеджмента, сегодня успешно используется внутри компании для проведения семинаров и стажировок коллег из регионов. Решение позволяет не только общаться с партнерами в режиме реального времени, участвовать в совещаниях, но и совместно просматривать документы и видеоматериалы, прослушивать аудиозаписи.
МЕЖРЕГИОНАЛЬНЫЙ ЦЕНТР ИНФОРМАТИЗАЦИИ ПРИ БАНКЕ РОССИИ
Унифицированная транспортная среда электронного
взаимодействия межрегионального центра информатизации
при Банке России с клиентами Банка России Московского
Выписка из Пояснительной записки к техническому проекту
1.1 Полное наименование системы и ее условное обозначение
1.2 Назначение системы
1.3 Цели создания системы
1.4 Область использования системы
2 ОПИСАНИЕ ПРОЦЕССА ДЕЯТЕЛЬНОСТИ
2.1 Условия электронного взаимодействия с клиентами Банка России
2.1.1 Описание используемой среды передачи данных
2.2 Характеристики объекта автоматизации
3 ОСНОВНЫЕ ТЕХНИЧЕСКИЕ РЕШЕНИЯ ПО СИСТЕМЕ
3.1 Основные принципы построения системы
3.1.1 Изменение зоны ответственности Банка России для электронного взаимодействия с КБР
3.1.2 Необходимость платформы с гарантированной доставкой информации как основного интерфейса транспортного шлюза
3.1.3 Поддержка открытых стандартов взаимодействия
3.2 Основные функции системы
3.3 Архитектура и системно-технические решения
3.3.1 Перечень и описание интерфейсов, поддерживаемых системой СВК МЦИ для клиентов Банка России
3.3.2 Виды передаваемой информации
3.3.3 Порядок передачи данных с использованием транспортного протокола. 12 3.3.4 Способы представления информации для передачи с использованием транспортного протокола
3.3.5 Классификация передаваемых данных по их структуре
3.3.6 Порядок маршрутизации сообщений транспортным шлюзом
3.3.7 Порядок приема и отправки сообщений
3.3.8 Реализация принципа FIFO для платежных сообщений для транспортных протоколов 18 3.3.9 Решения по протоколированию
3.3.10 Решения по оперативному хранению сообщений
3.4 Содержание и порядок применения технических условий электронного взаимодействия между клиентами Банка России и МЦИ
3.5 Решения для клиентов Банка России
3.5.1 Классификация и способы прикладного взаимодействия клиентов Банка России с МЦИ (в том числе по структуре информации)
3.5.2 Режимы взаимодействия клиента с МЦИ
3.5.3 Подключение по протоколу HTTP в режиме «пользователь»
3.5.4 Подключение по протоколам SMTP/POP3/IMAP4 в режиме «пользователь»24 3.5.5 Подключение в режиме «программа»
3.5.6 Дополнительные сервисы для клиентов
3.6 Решения по организации подсистемы телекоммуникационного доступа. 24 3.6.1 Описание ПТД
3.7 Компонент групповой отправки сообщений
3.8 Компонент «Уведомление клиента Банка России об истечении срока действия паролей в СВК»
4 МЕРОПРИЯТИЯ ПО ПОДГОТОВКЕ ОБЪЕКТОВ АВТОМАТИЗАЦИИ. 26 4.1 Мероприятия по клиентам Банка России
4.1.1 Описание процесса подключения клиентов к МЦИ в части обмена платежной информацией 26 ПЕРЕЧЕНЬ ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ
ПЕРЕЧЕНЬ ПРИНЯТЫХ СОКРАЩЕНИЙ И ОБОЗНАЧЕНИЙ
ПРИМЕРЫ ВИДОВ СТРУКТУРЫ ТРАНСПОРТНЫХ СООБЩЕНИЙ,
ПЕРЕДАВАЕМЫХ ОТ КЛИЕНТА В МЦИ
A.1 Структура транспортного сообщения в формате УФЭБС КО – при передаче от клиента в МЦИ по HTTP при формировании сообщения с использованием Интернет браузера 31 A.2 Структура транспортного сообщения в формате УФЭБС КО – при передаче по HTTP при формировании сообщения прикладной системой
A.3 Структура транспортного сообщения в формате УФЭБС КО – при передаче по HTTP при формировании сообщения прикладной системой с использованием сегментации
A.4 Структура транспортного сообщения в унаследованном формате – при передаче по HTTP при формировании сообщения прикладной системой с использованием сегментации
1.1 Полное наименование системы и ее условное обозначение Полное наименование автоматизированной системы: Вторая очередь унифицированной транспортной среды электронного взаимодействия межрегионального центра информатизации при Банке России с клиентами Банка России Московского региона.
Условное обозначение системы: СВК МЦИ.
СВК МЦИ предназначена для обеспечения электронного взаимодействия Межрегионального центра информатизации при Банке России с клиентами Банка России Московского региона.
СВК МЦИ должна предоставлять клиентам Московского региона Банка России возможность осуществлять электронный обмен информацией в условиях перевода обработки платежной информации в Московском регионе на Коллективный центр обработки информации в г. Москва (КЦОИ МР).
Основные принципы построения СВК МЦИ:
– использование открытых стандартов и транспортных протоколов для подключения клиентов Банка России;
– возможность последующего расширения количества транспортных протоколов;
– предоставление (публикация) нескольких протоколов и интерфейсов для подключения клиентов Банка России, обеспечивающих различные варианты и классы обслуживания;
– обеспечение единой системы адресации и правил именования получателей и отправителей электронных сообщений (ЭС);
– четкое разделение сфер ответственности МЦИ и клиентов Банка России;
– возможность использования клиентами Банка России как коммерческих, так и открытых (в том числе бесплатных) программных продуктов;
– обеспечение обмена платежной и неплатежной информацией между МЦИ и клиентами Банка России;
– возможность расширения функций, выполняемых СВК МЦИ;
– обеспечение защиты обрабатываемой и передаваемой системой информации в соответствии с требованиями российского законодательства и нормативными документами Банка России.
1.3 Цели создания системы
– обеспечение электронного взаимодействия МЦИ с КБР при переводе обработки платежной информации в Московском регионе на КЦОИ МР;
– унификация средств электронной доставки информации, криптозащиты, программного обеспечения организации обмена электронными сообщениями с КБР.
1.4 Область использования системы Предметной областью автоматизации для СВК МЦИ является взаимодействие клиентов Банка России Московского региона (кредитных организаций и особых клиентов) и МЦИ в рамках обмена платежной информацией, статистической отчетностью и другими видами информации.
2.1 Условия электронного взаимодействия с клиентами Банка России 2.1.1 Описание используемой среды передачи данных В настоящее время для взаимодействия между КБР и МЦИ используются различные типы каналов передачи данных, такие как:
2.2 Характеристики объекта автоматизации Предметной областью автоматизации для СВК МЦИ является взаимодействие клиентов Московского региона Банка России и МЦИ в рамках обмена платежной информацией, статистической отчетностью и другими видами информации.
Схема существующего обмена платежной информации между КБР и Банком России представлена на Рис. 1.
Рис. 1. Схема существующего обмена платежной информации Транспортная система Московского региона состоит из 3-х подсистем: Астра, FastInfo-2 и СВК МЦИ 1-ой очереди. Абонентами указанных подсистем являются УЭО МР – кредитные организации, особые клиенты и учреждения расчетной сети Банка России Московского региона.
Доступ клиентов к транспортной системе осуществляется по протоколу TCP/IP через провайдеров связи или непосредственно через телефонную сеть общего пользования. Предусмотрен также аварийный способ доставки информации на магнитном носителе.
3 Основные технические решения по системе
3.1 Основные принципы построения системы 3.1.1 Изменение зоны ответственности Банка России для электронного взаимодействия с КБР МЦИ публикует интерфейс подключения к транспортной системе Банка России. Публикация интерфейсов со стороны Банка России будет осуществлена с помощью аппаратно-программных средств автоматизированной системы СВК МЦИ.
Техническое средство, находящееся у клиента Банка России, через которое осуществляется взаимодействие с СВК МЦИ, называется точкой доступа клиента Банка России. Ответственность за реализацию точки доступа (приобретение программных и технических средств, средств криптозащиты данных), а также ее эксплуатацию и обслуживание несет клиент Банка России.
Банк России предоставляет клиентам специальное программное обеспечение – АРМ Клиента Банка России (АРМ КБР) и Универсальный транспортный адаптер (УТА), обеспечивающее минимально необходимую для взаимодействия с СВК МЦИ функциональность. Использование клиентом специального программного обеспечения не является обязательным: клиент может использовать программное обеспечение третьих фирм, либо разработать его самостоятельно.
3.1.2 Необходимость платформы с гарантированной доставкой информации как основного интерфейса транспортного шлюза Автоматизированная система должна обеспечивать гарантированную доставку сообщений, поддерживать передачу больших объемов информации, надежно работать на имеющихся линиях связи.
3.1.3 Поддержка открытых стандартов взаимодействия При рассмотрении современных платежных систем можно наблюдать мировую тенденцию к постепенному переходу таких систем на открытые стандарты информационных технологий. Так, международная платежная система S.W.I.F.T.
создала новые форматы обмена на базе XML (SWIFT-ML).
Таким образом, переход к открытым стандартам позволяет строить транспортную систему для электронного обмена с КБР на основе промышленных решений, поставляемых крупными компаниями, обеспечивающих развитую поддержку для программно-технической платформы, своевременное обновление и расширение версий продуктов.
Также следование открытым стандартам всегда позволяет иметь возможность выбора между различными производителями.
В системе СВК МЦИ полностью удовлетворяют данному подходу интерфейсы на основе HTTP протокола, а также наличие поддержки таких спецификаций как XML, SOAP, MIME, URI и др.
В качестве транспорта с гарантированной доставкой сообщений используется закрытое решение на основе WebSphere MQ, разработанное – компанией IBM. На текущий момент времени не существует удовлетворительной реализации для систем с гарантированной доставкой сообщений, реализующих открытые спецификации.
Однако сегодня уже идет процесс внедрения тестирования и отладки таких спецификаций, например:
– WS-ReliableMessaging, разработанная IBM и Microsoft;
– ebXML Messaging – спецификация организации OASIS.
В перспективе, с появлением промышленных реализаций для этих или подобных спецификаций, решение по транспортной системе для клиентов Банка России может быть доработано до поддержки открытых стандартов и в части протокола гарантированной доставки. Возможность такой доработки обеспечивается использованием в качестве транспортного заголовка SOAP, допускающего расширение состава используемых реквизитов.
3.2 Основные функции системы
Основными функциями системы являются:
– электронный обмен платежной информации и банковской отчетности путем предоставления клиентам Банка России транспортного интерфейса HTTP;
– обеспечение поддержки обмена с использованием форматов УФЭБС КО;
– маршрутизация потоков информации внутри сети Банка России в платежную сетиь;
– работа по протоколам tcp/ip с поддержкой фактически существующих линий связи;
– обеспечение требований информационной безопасности при подключении клиентов к СВК МЦИ и прохождении сообщений через СВК МЦИ;
– предоставление клиенту информации о результатах маршрутизации сообщений с помощью квитанций;
– учет приоритетности трафика при помещении сообщений в транспортную систему.
3.3 Архитектура и системно-технические решения 3.3.1 Перечень и описание интерфейсов, поддерживаемых системой СВК МЦИ для клиентов Банка России Для КБР поддерживается способ подключения к СВК МЦИ по протоколу HTTP. Данный способ подключения предоставляет собой наименее дорогой вариант, но при этом имеет соответствующие ограничения: в общедоступной реализации HTTP-клиента не поддерживаются повторы при разрыве линии связи, кроме того, клиент всегда должен инициировать соединение с транспортным шлюзом. Для повышения класса обслуживания подключений по протоколу HTTP клиентам Банка России предлагается дополнительный сервис, облегчающий передачу больших объемов данных – сегментация, а также сервис проверки целостности и уникальности передаваемых сообщений.
Основным сервером в составе СВК МЦИ является сервер Транспортного шлюза. Транспортный шлюз построен на базе продукта MS BizTalk Server и выполняет функции маршрутизации и преобразования транспортных сообщений, а также реализует все сопутствующие технологические операции (квитирование, протоколирование и т.д.).
В СВК МЦИ поддерживается протокол взаимодействия с клиентами Банка России HTTP. Для протокола HTTP в СВК используется соответствующий провайдер транспортного протокола. Для организации взаимодействия с УОС по протоколу WMQ в ДМЗ функционируют менеджер очередей WMQ на выделенном сервере. При переходе на обработку в КЦОИ, происходит дальнейшее взаимодействие совмещенной транспортной станции с КЦОИ по протоколу WMQ.
На стороне клиентов Банка России функционирует специальное ПО, предоставляющее интерфейс взаимодействия с МЦИ. Клиент может разработать собственное ПО, использовать предоставляемое специальное программное обеспечение или штатное ПО для взаимодействия по протоколу HTTP (Интернет обозреватель).
3.3.2 Виды передаваемой информации СВК МЦИ обеспечивает обработку и маршрутизацию сообщений в формате УФЭБС (XML), в соответствии с альбомом форматов [УФЭБС], содержащих служебный заголовок в формате SOAP, который используется транспортным шлюзом для маршрутизации этих сообщений.
При этом выделяются сообщения с платежами (электронные платежные сообщения, ЭПС) и сообщения с запросами клиента к МЦИ и ответами МЦИ на запросы клиентов (электронные служебно-информационные сообщения, ЭСИС).
При передаче сообщений или файлов с помощью того или иного транспортного протокола, поддерживаемого системой СВК МЦИ, формируется транспортное сообщение, которое состоит из исходных данных клиента и транспортного заголовка, соответствующего спецификациям официального стандарта для данного протокола.
Спецификации официальных стандартов, как правило, предполагают множество вариантов по формированию транспортных заголовков, поэтому технические условия («Технические условия информационного взаимодействия клиентов Банка России и МЦИ при Банке России для обмена платежной информацией и статистической отчетностью» [25], «Технические условия информационного взаимодействия внутренних сегментов МЦИ при Банке России с СВК МЦИ» [26]), определяющие интерфейсы электронного обмена, накладывают собственные правила (ограничения) на формирование транспортного заголовка в рамках официального стандарта.
3.3.4 Способы представления информации для передачи с использованием транспортного протокола При передаче по протоколу HTTP для кодирования прикладной части транспортного сообщения используется «MIME-подобный» формат (в соответствии с RFC2045 [6], RFC2046 [7], RFC2047 [8] с учетом ограничений, накладываемых стандартом для протокола HTTP RFC2616 [9] ).
Сообщения в формате УФЭБС могут передаваться в сжатом виде с использованием алгоритма GZip в соответствии с RFC1952 [12]. Сжатие поддерживается только на плече клиент – СВК МЦИ. В случае, если сообщения в формате УФЭБС передаются в зашифрованном виде, то сжатие таких сообщений в СВК МЦИ является неэффективным, и в этом случае не рекомендуется.
Примеры структур транспортных сообщений приведены в приложениях A.1A.4 настоящего документа.
3.3.5 Классификация передаваемых данных по их структуре Принимается следующая классификация данных, передаваемых клиентом, по их структуре:
– сообщения в формате УФЭБС (XML), отправляемые с помощью запроса POST по протоколу HTTP;
– сообщения в формате УФЭБС (XML), отправляемые с помощью запроса POST по протоколу HTTP в сжатом виде.
Транспортный шлюз, в свою очередь, передает клиенту данные в соответствии со следующей классификацией (также по структуре этих данных):
3.3.6 Порядок маршрутизации сообщений транспортным шлюзом В качестве базового программного обеспечения при реализации транспортного шлюза используется Microsoft BizTalk Server.
Маршрутизация сообщений основана на механизме логической адресации.
Логический адрес представляет собой строку, уникально идентифицирующую участника обмена.
Клиент Банка России (далее внешний абонент) имеет логический и физический адреса для обмена различными видами трафика (платежным и информационным). Для внешнего абонента могут быть заданы несколько собственных логических адресов (множественная адресация). Логический адрес определяет автоматизированное рабочее место (АРМ). Для каждого логического адреса задается собственный физический адрес.
Каждое принимаемое шлюзом сообщение содержит логические адреса получателя и отправителя. Метод передачи логических адресов зависит от формата сообщения и протокола, по которому оно передаётся. Для сообщений в формате УФЭБС адреса передаются в заголовке SOAP-конверта.
При взаимодействии в режиме «пользователь-система» принимаемое сообщение может иметь более одного адреса получателя. В таком случае на уровне адаптера транспортного протокола из одного транспортного сообщения, содержащего список адресов получателей, формируется несколько, каждое из которых содержит только один адрес. Каждое такое сообщение маршрутизируется независимо от других.
На транспортном шлюзе администратором СВК МЦИ ведутся справочники внешних и внутренних абонентов. Справочники внешних и внутренних абонентов являются едиными для распределенного кластера транспортного шлюза.
На базе логического адреса получателя по соответствующему справочнику определяется физический адрес, и сообщение маршрутизируется по данному адресу.
Логическая адресация позволяет клиенту Банка России адресовать более одного получателя во внутреннем сегменте УОС.
При подключении клиенту Банка России сообщаются логические адреса, предназначенных для данного клиента, а также адреса абонентов в сегменте УОС. В сегменте УОС ведется справочник логических адресов клиентов. Таким образом, участники обмена указывают в сообщении только логические адреса, на основании которых транспортный шлюз выполняет маршрутизацию.
Для каждого логического адреса внешнего абонента фиксируется один протокол, по которому абонент может взаимодействовать со шлюзом, используя данный логический адрес.
Для анализа типа структуры (формата) сообщения используется поле Contenttype. На основании формата сообщения производится структурный контроль, определяется допустимое время приема и требуемые этапы технологической обработки.
При получении сообщения, несоответствующего правилам заполнения, описанных в технических условиях обмена, с нарушенной структурой или с некорректно заполненными технологическими данными (адресная информация, тип ЭС и т.д.) сообщение не маршрутизируется, помещается в очередь ошибочных сообщений, а отправителю формируется соответствующая квитанция с описанием причин отказа в маршрутизации.
При получении некорректно сформированного сообщения из внутреннего сегмента УОС необходимость формирования квитанции с описанием причин отказа в маршрутизации задаётся в настройках транспортного шлюза.
В случае успешной маршрутизации клиенту отправляется квитанция с указанием положительного результата. Квитанции об успешной маршрутизации доставляются клиенту, если он их заказал при отправке исходного сообщения, выставив определенный флаг в служебном заголовке. Квитанции об успешной маршрутизации в сторону сегмента УОС формируются в зависимости от настроек внутренних абонентов и наличия флага запроса квитанции.
Транспортные сообщения квитанций отправляются по тому же протоколу, что и исходное сообщение, при этом в качестве адреса, на который отправляется квитанция, используется адресная информация об отправителе исходного сообщения, полученная из транспортных заголовков.
Для асинхронного протокола WMQ, применяемого для взаимодействия с УОС, транспортный шлюз отправляет сообщение адресату непосредственно через адаптеры транспортных протоколов.
Для синхронного протокола HTTP поток сообщений, предназначенный для клиента, сохраняется в базе данных (MS SQL Server). Когда клиент устанавливает соединение, он может запросить сообщения для него: либо с помощью HTTPзапроса GET (в режиме «программа»), либо через веб-интерфейс, выбрав соответствующую ссылку (в режиме «пользователь»).
При помещении в транспортную систему сообщений, для которых определен приоритет и при этом провайдер транспортного протокола поддерживает приоритезацию трафика, маршрутизатор сообщений указывает приоритет 3.3.7 Порядок приема и отправки сообщений При поступлении сообщений по протоколу WMQ на один из менеджеров очередей СВК МЦИ, адаптер транспортного протокола в процессе автоматического сканирования очереди считывает сообщение и после технологического преобразования транспортного формата сообщения (DIME/MIME) публикует сообщение в единое хранилище (BizTalk Message Box). Экземпляр оркестровки (потока BizTalk, выполняющего маршрутизацию) является подписчиком для сообщений. После обработки сообщения в оркестровке и принятия решения по маршрутизации (включая все технологические этапы: протоколирование, структурный контроль, антивирусный контроль, отправка квитанций), сообщение публикуется для отправки через другой менеджер очередей. Адаптер транспортного протокола осуществляет отправку по указанному адресу.
Прием сообщений от КБР по протоколу HTTP осуществляется с помощью соответствующего адаптера транспортного протокола. Адаптер HTTP регистрируется как «слушатель» (listener) в компоненте операционной системы (драйвере) HTTP.sys.
В случае работы клиента в режиме «программа» клиентское ПО отправляет непосредственно HTTP-запросы. Для клиента, работающего в режиме «пользователь», разработано веб-приложение, через которое можно отправить и принять сообщение. HTTP-запрос впоследствии также обрабатывается транспортным адаптером.
Опционально осуществляется контроль целостности сообщений, передаваемых по протоколу HTTP. Для этого отправитель сообщения добавляет в заголовок транспортного протокола хэш-сумму MD5. Получатель вычисляет хэш на полученное сообщение и сравнивает с переданной в заголовках суммой. В случае несовпадения отправителю возвращается ошибка. Если заголовок запроса не содержит хэш-суммы, контроль не производится.
Для передачи сообщений большого размера по протоколу HTTP в качестве дополнительного сервиса предлагается сегментация. При передаче сообщения на шлюз клиент Банка России разделяет передаваемое сообщение на ряд фрагментов меньшего размера (т.н. «сегменты») и последовательно передаёт их по каналу связи. При приеме клиент запрашивает сообщение посегментно. В случае обрыва канала требуется повторно послать или получить только тот сегмент, при передаче которого произошел обрыв.
На стороне клиентов Банка России сегментация реализована в специальном программном обеспечении файлового взаимодействия. Также механизм реализации сегментации описан в Технических условиях обмена, что позволяет клиентам реализовать сегментацию в программных комплексах собственной разработки.
Сегментация поддерживается только в режиме взаимодействия «системасистема».
Сегментация является опциональной; необходимость сегментирования ЭС при приеме и передаче определяется КБР.
Осуществляется контроль соответствия авторизованного пользователя и адреса отправителя в заголовке служебного конверта ЭС либо в дополнительном заголовке HTTP-запроса при взаимодействии с клиентом Банка России по протоколу HTTP. Адаптер транспортного протокола передаёт на «Транспортный шлюз» имя авторизованного пользователя. Осуществляется проверка соответствия имени пользователя, переданного адаптером транспортного протокола, и имени пользователя, заданного в справочнике внешних абонентов для данного логического адреса. При обнаружении несоответствия, клиенту возвращается квитанция об ошибке адресации и сообщение не обрабатывается. При соответствии, сообщение обрабатывается дальше.
В SOAP-конверте сообщений, передаваемых в УОС, не добавляются дополнительные (к уже существующим) поля с адресной информацией. При работе КО за свой филиал, головная организация отправляет сообщение филиала от своего пользователя и указывает в SOAP конверте в поле from свой обратный адрес, который соответствует головной организации.
Для сообщений, поступающих от клиентов Банка России по протоколу HTTP, осуществляется антивирусный контроль. Перед маршрутизацией сообщения и выполнением технологических этапов обработки выполняется вызов антивирусного ПО Symantec Scan Engine по протоколу ICAP согласно [ICAP]. В случае обнаружения сигнатуры вируса в сообщении, Транспортный шлюз прерывает обработку данного сообщения и посылает отправителю ЭС соответствующую квитанцию.
Если сообщение, по которому принято решение в отказе маршрутизации вследствие подозрения на вирус, имело порядковый номер, то следующие сообщения не будут обрабатываться, пока не поступит корректное сообщение с пропущенным порядковым номером или не истечет время его ожидания.
Порядок и правила работы по перечисленным протоколам подробно описаны в Технических условиях обмена (в составе документации ТРП на СВК МЦИ).
В соответствии с требованиями ТЗ СВК МЦИ для электронных платежных сообщений (ЭПС) транспортная система должна обеспечивать заданный отправителем порядок доставки сообщений получателю (принцип FIFO).
Учитывая потенциальную возможность нарушения последовательности при многопоточном чтении / маршрутизации / отправке на транспортном шлюзе, вне зависимости от используемого клиентом протокола взаимодействия, разработано решение, в соответствии с которым отправитель электронного платежного сообщения обязан указывать несколько сопроводительных реквизитов, которые позволяют транспортному шлюзу контролировать последовательность доставки данных ЭПС в порядке, заданном отправителем.
Последовательность сообщений отслеживается с помощью логического адреса отправителя, а также ряда дополнительных реквизитов, передаваемых в заголовке props:SequenceInfo служебного конверта:
– дата составления ЭПС;
– порядковый номер ЭПС от данного клиента в течение дня без пропусков.
Для ЭПС в формате УФЭБС КО дополнительные реквизиты, обеспечивающие контроль доставки в режиме FIFO, указываются в заголовке служебного конверта УФЭБС КО.
Алгоритм работы транспортного шлюза при реализации принципа FIFO следующий:
– Транспортный шлюз проверяет наличие и корректность заполнения порядкового номера (в реквизитах служебного конверта, теле письма или полях транспортного сообщения);
– Если необходимые реквизиты отсутствуют либо некорректно заполнены, сообщение отвергается и клиенту направляется соответствующее уведомление;
– Если порядковый номер совпадает с порядковым номером одного из уже полученных сообщений, сообщение отвергается и Транспортный шлюз отправляет соответствующее уведомление клиенту;
– Транспортный шлюз проверяет, что очередное полученное ЭПС имеет порядковый номер строго на 1 выше, чем номер предыдущего ЭПС от данного клиента. Только при выполнении данного условия транспортный шлюз выполняет маршрутизацию данного ЭПС.
– В случае получения ЭПС с порядковым номером выше более чем на 1, транспортный шлюз считает, что пропущенные ЭПС могут еще находиться в очереди почтового сервера, и помещает полученное ЭПС в очередь на маршрутизацию.
– Одновременно запускается таймаут на ожидание приема пропущенных ЭПС. При истечении таймаута клиенту возвращается уведомление о неполучении пропущенных сообщений.
– При получении всех пропущенных сообщений транспортный шлюз запускает маршрутизацию ЭПС, находящихся в очереди.
Принцип FIFO обеспечивается только в направлении от клиента в МЦИ и только для электронных платежных сообщений как в формате УФЭБС КО, так и в унаследованном формате. Транспортный шлюз соблюдает принцип FIFO (отправляются в той же последовательности, в которой были получены) при последующей передаче сообщений в сегмент УОС после их приема и принятия решения по маршрутизации.
Необходимость обеспечения принципа FIFO задаётся отдельно для каждого клиента в справочнике внешних абонентов.
В случае если клиент Банка России утратил контекст передачи (номер текущего сообщения), администратор СВК по запросу может с помощью специального средства обнулить счетчик (номер последнего обработанного сообщения) для клиента. Действия администратора СВК по обнулению счетчика отражаются в журнале, доступном администратору информационной безопасности СВК.
3.3.9 Решения по протоколированию
В процессе работы компоненты, отвечающие за прием, маршрутизацию и отправку сообщений осуществляют протоколирование событий своей работы.
Протокол ведется с помощью стандартного для windows-платформы журнала ОС – Event Log через специализированный программный интерфейс (Event Log Win API).
События идентифицируются кодом, а также содержат следующую информацию:
– дата и время наступления события;
– тип события (на основе типов, используемых в Windows Event Log’e);
– описание события, содержащее читаемый текст на русском языке и дополнительную информацию (например, идентификационные атрибуты и адресную информацию, если событие связано с приемом, маршрутизацией или отправкой сообщения).
Кроме событий штатной обработки в журнале фиксируются ошибочные ситуации при маршрутизации (несоответствие формата, некорректная структура конверта, неверные значения технологических полей и т.д.).
Средства защиты для обеспечения информационной безопасности, в части аудита, аутентификации, авторизации и защиты от НСД, фиксируют в журнале события, связанные с входом (выходом) пользователя в систему, попытки несанкционированного доступа и т.д.
По установленному регламенту МЦИ с помощью специализированной утилиты осуществляется экспорт протоколов в файл за указанный период. Впоследствии эти файлы архивируются штатными средствами персоналом, обслуживающим СВК МЦИ, и могут быть записаны на внешние носители информации (CD-R/CD-RW и др.).
Взаимодействие с внешней архивной системой предлагается осуществлять:
– либо на уровне файловой системы и передачи файлов с протоколами работы;
– либо передачей файлов с протоколами работы по протоколу WMQ с помощью специализированной утилиты (LogExpt).
Настройка параметров Event Log осуществляется таким образом, чтобы гарантированное время хранения записей в текущем файле журнала многократно превышало период, за который выполняется экспорт записей протокола в файл для последующего архивирования.
Для просмотра событий используется штатный компонент ОС Windows – Event Log Viewer.
Каждые сутки в протокол работы транспортный шлюз помещает сообщение со статистической информацией за сутки с указанием количества обработанных сообщений (суммарное и отдельно по разным типам сообщений в СВК МЦИ) и количеством отказов в маршрутизации.
3.3.10 Решения по оперативному хранению сообщений Все принимаемые и отправляемые транспортным шлюзом сообщения сохраняются для оперативного хранения в файловой системе.
В целях определения исчерпывающей спецификации электронного взаимодействия между КБР и МЦИ в рамках данного технического проекта разработан документ «Технические условия информационного взаимодействия клиентов Банка России и территориальных учреждений Банка России для обмена платежной информацией и статистической отчетностью» (сокращенно, «технические условия»), определяющие все параметры взаимодействия, в том числе:
3.5.1 Классификация и способы прикладного взаимодействия клиентов Банка России с МЦИ (в том числе по структуре информации) При выработке решений для клиентов Банка России принята их следующая условная классификация:
Программное обеспечение, взаимодействующее с поддерживаемыми транспортными протоколами в соответствии с «техническими условиями», может быть разработано клиентом самостоятельно. Альтернативно, имеется свободно распространяемое специальное программное обеспечение взаимодействия (СПО).
СПО обеспечивает передачу и прием файлов в соответствии спецификацией, изложенной в «технических условиях».
СПО осуществляет передачу файлов с платежной информацией в формате УФЭБС КО. Данная программа сканирует каталоги с файлами и по имени каталога вычисляет адрес получателя в соответствии с настройками своей конфигурации.
Возможно задание адреса получателя определенному шаблону (маске) имени файла. С помощью логической адресации и указания адреса получателя по шаблону имени файла может быть организовано взаимодействие клиента Банка России более чем с одним абонентом в сегменте УОС: для каждого шаблона имени файла указывается логический адрес получателя.
При отправке файлов, Специальное программное обеспечение файлового взаимодействия формирует HTTP-запрос. В конфигурации есть возможность указать параметры транспортного заголовка, идентифицирующие тип передаваемого сообщения.
Прием сообщений осуществляется автоматическим сканированием указанных ресурсов адресовURL, при этом сканируемому URL (или маске принимаемых файлов) задается каталог, в который будут помещены принятые сообщения.
3.5.2 Режимы взаимодействия клиента с МЦИ Для клиента Банка России возможны следующие режимы взаимодействия с
3.5.3 Подключение по протоколу HTTP в режиме «пользователь»
Для подключения по протоколу HTTP в режиме «пользователь» для отправки и приема сообщений допускается использовать программное обеспечение «Интернет браузер», например Microsoft Internet Explorer версии 6.0 и выше.
Для реализации данного режима подключения разработано веб-приложение, выбрав в котором соответствующие ссылки пользователь может выполнить действия при отправке и приему сообщений.
Для подключения по протоколам SMTP/POP3/IMAP4 клиент может использовать любой почтовый клиент, например почтовый клиент Microsoft Outlook Express версии 6.0 и выше.
3.5.5 Подключение в режиме «программа»
Подключение в режиме «программа» доступно для протокола HTTP. Клиент должен разработать (или приобрести у сторонних производителей) специализированное программное обеспечение, которое будет осуществлять прием и передачу сообщений по протоколу HTTP в соответствии с «техническими условиями».
3.5.6 Дополнительные сервисы для клиентов Клиентам Банка России предоставляется ряд дополнительных сервисов, доступных по протоколу HTTP. В число данных сервисов входят:
– ПО удаленной смены паролей, позволяющее клиентам сменить пароль;
– перечень внутренних абонентов (адресный справочник МЦИ), которым клиент может отправить сообщение.
Данные сервисы реализованы в качестве веб-страниц.
3.6 Решения по организации подсистемы телекоммуникационного доступа
Подсистема телекоммуникационного доступа СВК (ПТД) обеспечивает взаимодействие между: КБР и СВК МЦИ а также техническими средств СВК МЦИ между собой.
3.7 Компонент групповой отправки сообщений
Компонент групповой отправки сообщений предназначен для ввода сообщений в СВК МЦИ с отчуждаемых носителей информации, предоставляемых клиентами Банка России. Данная функциональность может быть востребована, в частности, в случае неработоспособности каналов связи либо каналообразующего оборудования.
Компонент имеет следующие функциональные возможности:
– отправка сообщений в СВК МЦИ по протоколу HTTP;
– считывание квитанций о результатах обработки сообщения в СВК МЦИ;
– протоколирование процесса приема/передачи сообщений;
– сохранения переданных и принятых сообщений в архиве.
Компонент реализован в виде автоматизированного рабочего места с графическим пользовательским интерфейсом. Компонент осуществляет отправку сообщений с пользовательских носителей (например, флеш-накопителей) и отображает в графическом виде статус процесса. После отправки компонент считывает квитанции от Транспортного шлюза СВК МЦИ и ответные сообщения от УОС. Корреляция ответных сообщений от УОС осуществляется по полю CorrelationMessageID заголовка служебного конверта. Считанные квитанции и ответы сохраняются в каталог на носителе клиента.
3.8 Компонент «Уведомление клиента Банка России об истечении срока действия паролей в СВК»
Компонент «Уведомление клиента Банка России об истечении срока действия паролей в СВК» предназначен для автоматического проведения процесса уведомления КБР об истечении срока действия пароля прикладного уровня в СВК МЦИ. Уведомление производится путем посылки в адрес КБР информационного сообщения с текстом, содержащим информацию об оставшемся времени действия пароля и необходимости его смены. В случае устаревания пароля и блокировки учетной записи КБР в СВК уведомление посылается администратору СВК МЦИ.
4 Мероприятия по подготовке объектов автоматизации
4.1 Мероприятия по клиентам Банка России 4.1.1 Описание процесса подключения клиентов к МЦИ в части обмена платежной информацией При необходимости клиент должен установить необходимое программное обеспечение (для поддержки выбранного протокола взаимодействия).
Порядок распространения и использования специального ПО СВК осуществляется в соответствии с регламентом, утверждаемым Банком России.
Перечень используемых источников [1] 20-П. Положение о правилах обмена электронными документами между Банком России, кредитными организациями (филиалами) и другими клиентами Банка России при осуществлении расчетов через расчетную сеть Банка России 20-П (в ред. Указания ЦБ РФ 11.04.2000 № 774-У).
[2] РД 50–34.698-90. Методические указания. Информационная технология.
Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.
[3] 198-П. Положение о порядке расчета и взимания платы за расчетные услуги Банка России 198-П, 7 октября 2002.
[4] УФЭБС. «Унифицированные форматы электронных банковских сообщений для безналичных расчетов. Обмен с кредитными организациями и другими клиентами Банка России».
[5] RFC2822. “Internet Message Format, RFC 2822”, April 2001.
[6] RFC2045. “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC 2046”, November 1996.
[7] RFC2046. “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, RFC 2046”, November 1996.
[8] RFC2047. “MIME (Multipurpose Internet Mail Extensions) Part Three:
Message Header Extensions for Non-ASCII Text, RFC 2047”, November 1996.
[10] RFC2854. “The ’text/html’ Media Type, RFC 2854”, June 2000 [11] RFC2388. Masinter, L., «Returning Values from Forms: multipart/form-data», RFC 2388, August 1998.
[12] RFC1952. GZIP file format specification version 4.3, May 1996.
[15] WMQ Ref. WebSphere MQ Information Center V1.2. WebSphere MQ Application Programming Reference, © Copyright International Business Machines Corporation 1994, 2002. All rights reserved.
[16] WMQ Guide. WebSphere MQ Information Center V1.2. WebSphere MQ Application Programming Guide, © Copyright International Business Machines Corporation 1994, 2002. All rights reserved.
[17] WMQ IntComm. WebSphere MQ Information Center V1.2. WebSphere MQ Intercommunication, © Copyright International Business Machines Corporation 1994, 2002. All rights reserved.
[18] ICAP. Internet Content Adaptation Protocol (ICAP), April 2003 [19] Вторая очередь унифицированной транспортной среды электронного взаимодействия межрегионального центра информатизации при Банке России с клиентами Банка России Московского региона. Техническое задание.
[20] Вторая очередь унифицированной транспортной среды электронного взаимодействия межрегионального центра информатизации при Банке России с клиентами Банка России Московского региона. Описание комплекса технических средств. Номер документа КМНБ.425500.008.П9.
[21] Вторая очередь унифицированной транспортной среды электронного взаимодействия межрегионального центра информатизации при Банке России с клиентами Банка России Московского региона. Описание программного обеспечения. Номер документа КМНБ.425500.008.ПА.
[22] Вторая очередь унифицированной транспортной среды электронного взаимодействия межрегионального центра информатизации при Банке России с клиентами Банка России Московского региона. Описание подсистемы информационной безопасности. Номер документа КМНБ.425500.008.ПЕ.
[23] Вторая очередь унифицированной транспортной среды электронного взаимодействия межрегионального центра информатизации при Банке России с клиентами Банка России Московского региона. Руководство по установке и настройке. Номер документа КМНБ.425500.008.92.
[24] Вторая очередь унифицированной транспортной среды электронного взаимодействия межрегионального центра информатизации при Банке России с клиентами Банка России Московского региона. Руководство администратора.
Номер документа КМНБ.425500.008.90.
[25] Вторая очередь унифицированной транспортной среды электронного взаимодействия межрегионального центра информатизации при Банке России с клиентами Банка России Московского региона. Технические условия информационного взаимодействия клиентов Банка России и МЦИ при Банке России для обмена платежной информацией и статистической отчетностью.
Номер документа КМНБ.425500.008.ТУ.01.
[26] Вторая очередь унифицированной транспортной среды электронного взаимодействия межрегионального центра информатизации при Банке России с клиентами Банка России Московского региона. Технические условия информационного взаимодействия внутренних сегментов МЦИ при Банке России с СВК МЦИ. Номер документа КМНБ.425500.008.ТУ.02.
Перечень принятых сокращений и обозначений
A.1 Структура транспортного сообщения в формате УФЭБС КО – при передаче от клиента в МЦИ по HTTP при формировании сообщения с использованием Интернет браузера Комментарии по специфике формирования тела сообщения и заполнения параметров транспортного заголовка:
– клиент передает XML-файл, подготовленный в соответствии с альбомом форматов [УФЭБС];
– сообщение передается в MIME-подобном формате, содержащем две части;
– в первой части передаются параметры html-формы, где указан тип передаваемого файла (УФЭБС ЭПС либо УФЭБС ЭСИС) – выбранный пользователем с помощью Интернет браузера;
A.2 Структура транспортного сообщения в формате УФЭБС КО – при передаче по HTTP при формировании сообщения прикладной системой Комментарии по специфике формирования тела сообщения и заполнения параметров транспортного заголовка:
– клиент передает XML-сообщение, подготовленное в соответствии с альбомом форматов [УФЭБС];
– поле Content-type устанавливается в “application/xmlepd” либо “application/xmlesid” (“application/zxmlepd” либо “application/zxmlesid” – для сжатых сообщений по алгоритму GZip) – для анализа транспортным шлюзом типа передаваемого файла.
A.3 Структура транспортного сообщения в формате УФЭБС КО – при передаче по HTTP при формировании сообщения прикладной системой с использованием сегментации Комментарии по специфике формирования тела сообщения и заполнения параметров транспортного заголовка:
A.4 Структура транспортного сообщения в унаследованном формате – при передаче по HTTP при формировании сообщения прикладной системой с использованием сегментации Комментарии по специфике формирования тела сообщения и заполнения параметров транспортного заголовка:
МЕЖРЕГИОНАЛЬНЫЙ ЦЕНТР ИНФОРМАТИЗАЦИИ ПРИ БАНКЕ РОССИИ
(МЦИ) Унифицированная транспортная среда электронного взаимодействия межрегионального центра информатизации при Банке России с клиентами Банка России Московского региона (СВК МЦИ)
1.1 Наименование документа
1.3 Сфера применения
1.4 Общие положения
1.6 Структура документа
2.2 Особенности заполнения заголовков служебного конверта
3.1 Участники обмена
3.2 Транспортные протоколы обмена
3.3 Взаимодействие по протоколу HTTP
3.3.1 Порядок обмена HTTP-сообщениями
3.3.2 Общие правила оформления сообщений, передаваемых по протоколу HTTP 1.1
3.3.3 Правила оформления клиентами Банка России HTTP-сообщений при передаче платежной информации
3.3.4 Правила оформления HTTP-сообщений, передаваемых в направлении клиента Банка России
3.5 Действия при обнаружении вируса в сообщении
3.6 Самостоятельная смена паролей
3.6.2 Режим Система – Система
3.7 Адресный справочник
3.7.2 Режим Система – Система
3.8 Версия Транспортного Шлюза СВК
5.1 Параметры транспортных протоколов
5.2 Параметры подсистемы информационной безопасности
5.2.1 Канальный уровень
5.2.2 Прикладной уровень
5.2.3 Процедура изменения пользовательских паролей
5.2.4 Рекомендации по обеспечению информационной безопасности43
Полное наименование настоящих Технических условий – «Технические условия информационного взаимодействия клиентов Банка России и МЦИ при Банке России для обмена платежной информацией и статистической отчетностью» (Далее
Настоящие Технические условия разработаны в целях описания технических аспектов информационного взаимодействия между Территориальными учреждениями Банка России и клиентами Банка России (кредитными организациями и коммерческими банками), далее – «участниками обмена» в рамках проекта СВК МЦИ.
Настоящие Технические условия применяются для реализации информационного обмена между клиентами Банка России и Межрегиональным центром информатизации при Банке России.
В настоящем документе под терминами «обмен», «информационный обмен»
понимается обмен платежной и информационно-аналитической информацией между участниками.
В совокупности с прилагаемыми документами и используемыми стандартами (см. раздел 0) Технические условия образуют необходимый набор документов, на основе использования которых возможна реализация информационного обмена между участниками.
Данные Технические условия используют те же самые слова для определения требований к реализации протокола, что и [RFC2119] Эти слова следующие:
НЕОБХОДИМО, ДОЛЖЕН (MUST).
Применяется для указания, что данное требование спецификации необходимо обеспечить в любом случае.
РЕКОМЕНДУЕТСЯ, СЛЕДУЕТ (SHOULD).
«Волков Юрий Викторович yuriivolkov[at]yandex.ru ОБРАЗОВАНИЕ ОСНОВНОЕ И ДОПОЛНИТЕЛЬНОЕ Свердловский юридический институт юрист (правоведение) (Свердловск, 1982). Московский технический университет связи и информатики повышение квалификации специалистов отрасли связи (Москва, 1996, 1997, 1998,) Уральский политехнический институт УГТУ-УПИ повышение квалификации руководителей предприятий (Екатеринбург, 2002). Уральская государственная юридическая академия повышение квалификации преподавателей. »
«МАТЕМАТИКА И ИНФОРМАТИКА Название курса Старший преподаватель каф. лингвистики и информационных технологий Алексеева Лектор – степень, Наталия Ивановна звание, фамилия, имя, отчество НАПРАВЛЕНИЕ ПОДГОТОВКИ: Лингвистика, Бакалавриат, 1-ый курс Целевая аудитория ПРОФИЛЬ ПОДГОТОВКИ: преподавание, межкультурная коммуникация, перевод, (отделение, курс): культурология (отделение Л и МКК) Целью освоения дисциплины является формирование основных ИКТ компетенций Цели и задачи курса (уровень продвинутого. »
«Обоснование необходимости лицензирования подготовки магистров специальности 8.080204 Социальная информатика в Харьковском национальном университете радиоэлектроники Национальная доктрина развития образования (Указ Президента Украины от 17 апреля 2002 г. № 347/2002) ставит перед ВУЗами страны задачу обеспечения приближения к уровню и способу организации жизнедеятельности развитых стран на основании перехода к новому типу гуманистично-инновационного образования. Одним из ключевых направлений. »
«Утверждаю Проректор по учебной работе и информатизации ФГБОУ ВПО «РЭУ им. Г.В. Плеханова» О.А. Гришина «»_2015 г. ФГБОУ ВПО «РЭУ им. Г.В. Плеханова» _ «» 2015г. ПОЛОЖЕНИЕ об образовательно-научном центре «Статистика и математика» Федерального государственного бюджетного образовательного учреждения высшего профессионального образования «Российский экономический университет имени Г.В Плеханова» ОБЩИЕ ПОЛОЖЕНИЯ 1. 1.1. Настоящее положение определяет основные цели и задачи, структуру, функции. »
«. : Москва БИНОМ. Лаборатория знаний УДК 004.8 ББК 32.813+32.97 Б90 Мнение автора может не совпадать с мнением редакции Бубнов В. А. Б90 Информатика и информация: знаково-символьный аспект : монография / В. А. Бубнов. — М. : БИНОМ. Лаборатория знаний, 2014. — 320 с. : ил. ISBN 978-5-9963-0508-7 В основу данной работы положено представление о том, что информация — это содержание символа, представленного различными графическими конструкциями. В монографии обсуждаются все аспекты измерения и. »
«Примена статистике у кинематографији Горан Мићовић Факултет техничких наука Чачак Мастер професор технике и информатике, 526/2011 goranmico@gmail.com Ментор рада: др Вера Лазаревић,ванр. проф. Сажетак. У овом раду је представљена статистичка анализа над конкретим узорком. Рад се сатоји од неколико теоријских и практичних целина. Теоријске се баве статистичким посматрањем, дескриптивном статистиком, регресионом анализим. Пректичне се баве анализом у пакету Statistica, где је приказана. »
«СВЕДЕНИЯ О РЕЗУЛЬТАТАХ ПУБЛИЧНОЙ ЗАЩИТЫ ДИССЕРТАЦИИ ВЫПИСКА ИЗ ПРОТОКОЛА № 10 заседания диссертационного совета Д 219.003.02 по защите докторских и кандидатских диссертаций при Поволжском государственном университете телекоммуникаций и информатики от 19 июня 2015 года СЛУШАЛИ: защиту кандидатской диссертации Чилихина Николая Юрьевича «Разработка и моделирование алгоритмов декодирования полярных кодов в системе информационно-управляющих комплексов» по специальности 05.12.13 – «Системы, сети и. »
«ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ НАУЧНОЕ УЧРЕЖДЕНИЕ ИНСТИТУТ ПЕДАГОГИКИ И ПСИХОЛОГИИ ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ РОССИЙСКОЙ АКАДЕМИИ ОБРАЗОВАНИЯ Лаборатория информатизации профессионального образования ТЕОРИЯ И ТЕХНОЛОГИЯ ИНФОРМАЦИОННОСРЕДОВОГО ПОДХОДА К МОДЕРНИЗАЦИИ ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ Монография Казань Издательство «Данис» ИПП ПО РАО, 2011 УДК 377 Рекомендовано в печать Т 33 Ученым советом ИПП ПО РАО Т 33 Теория и технология информационно-средового подхода к модернизации. »
«ГБОУ ВО Московской области «Академия социального управления» Кафедра информационно-коммуникационных технологий Проблемы, возникающие в ходе подготовки учащихся 10-11-ых классов к итоговой аттестации в форме ЕГЭ по информатике и ИКТ Круглый стол в форме вебинара 16 октября 2015 г. Вопросы для обсуждения • «Тестовые задания из КИМ ЕГЭ по информатике и ИКТ, по которым в 2015 году произошло существенное снижение успешности выполнения», (Филиппов В.И., старший преподаватель кафедры. »
«РОССИЙСКИЙ ГОСУДАРСТВЕННЫЙ СОЦИАЛЬНЫЙ УНИВЕРСИТЕТ А.Ю. ФЕДОСОВ ТЕОРЕТИКО–МЕТОДОЛОГИЧЕСКИЕ И МЕТОДИЧЕСКИЕ ПОДХОДЫ К РЕШЕНИЮ ЗАДАЧ ВОСПИТАНИЯ В ШКОЛЬНОМ КУРСЕ ИНФОРМАТИКИ И ИКТ Издательство Российского государственного социального университета Москва УДК 002:372.8 ББК 74.263.2 Ф-32 Рецензенты: Доктор педагогических наук, профессор Ю.А.Первин (Российский государственный социальный университет) Доктор педагогических наук, профессор А.В. Могилёв (Воронежский государственный педагогический. »
«107078, Москва, ул. Новая Басманная, д. 14, стр. 4 тел.: +7 903 590 86 34, e-mail: info@irt.su www.irt.su Калашникова Ирина Александровна, аспирант ННГАСУ преподаватель кафедры геоинформатики и кадастра ННГАСУ Обеспечение качества работ по определению кадастровой стоимости недвижимости в целях налогообложения Введение Правительством Российской Федерации 25 августа 1999 г. было принято Постановление № 945 «О государственной кадастровой оценке земель» [1], положившее начало проведению работ по. »
«К ВОПРОСУ ОБ ИСПОЛЬЗОВАНИИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ В ВУЗОВСКОЙ СИСТЕМЕ ОЦЕНКИ КАЧЕСТВА Шестакова Мария Викторовна магистрант 1 курса Института математики, информационных и космических технологий Северный (Арктический) федеральный университет имени М.В. Ломоносова, РФ, г. Архангельск E-mail: shes-mariya@yandex.ru Чиркова Лидия Николаевна кан. пед. наук, доцент кафедры экспериментальной математики и информатизации образования Северный (Арктический) федеральный университет имени М.В. Ломоносова. »
«Информатика, вычислительная техника и инженерное образование. – 2013. № 1 (12) Раздел V. Моделирование сложных систем УДК 658.512 Д.С. Юрко, Е.В. Нужнов ВОЗМОЖНОСТИ И СРЕДСТВА ПОДДЕРЖКИ ФУНКЦИОНИРОВАНИЯ ТРАНЗИТНОГО ПОРТОВОГО АВТОМАТИЗИРОВАННОГО КОНТЕЙНЕРНОГО ТЕРМИНАЛА Современные контейнерные перевозки производятся с использованием единиц различных видов транспорта (водного, железнодорожного, автомобильного). В работе рассматриваются вопросы автоматизации функционирования транзитного. »
«1Муниципальное бюджетное общеобразовательное учреждение Средняя общеобразовательная школа №7 г. Павлово Нижегородской области Учебно-исследовательская работа Исследование кока-колы Работу выполнил: ученик 5 А класса Парфенов Кирилл Возраст 11 лет Научный руководитель: учитель информатики школы №7 Воронина В.В. Павлово Оглавление Введение Теоретическая часть Из истории кока-колы Несколько интересных фактов о коле Практическая часть Опыт 1. Получение электрической энергии Опыт 2. Растворение. »
«Отчёт о проведении мероприятий за период с 07.11.2015 г. по 13.11.2015 г. В отчетный период МУ ДПО «Воскресенский научно-методический центр» были проведены следующие мероприятия: 07 ноября 2015 года на базе МОУ «СОШ № 9» в соответствии с Планом работы ГБОУ ВО МО «Академия социального управления» в рамках национальной образовательной инициативы «Наша новая школа» Воскресенским научнометодическим центром был организован зональный мастер-класс для учителей информатики и ИКТ по теме «Методика. »
Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.