Закон 210-ФЗ «Об организации предоставления государственных и муниципальных услуг» подписан в июле. Он вводит универсальную электронную карту – единый носитель, который объединяет идентификацию гражданина, доступ к госуслугам и банковское платёжное приложение. Выдача по заявлениям стартует с 1 января 2012 года, массовая – с 2014-го. До первого срока чуть больше года, и работу по интеграции систем нужно начинать сейчас, а не когда регламенты дойдут до финальной редакции.

УЭК – это не просто пластик с чипом. Это точка, где сходятся реестры ведомств, банковский процессинг, удостоверяющий центр и федеральная инфраструктура межведомственного взаимодействия. Тот, кто запустит интеграцию заранее, к 2012 году получит работающий сервис, а не аврал на стенде приёмки.

Что меняется на стороне ведомства

Карта сама по себе ничего не решает. За ней стоят информационные системы ПФР, ФОМС, налоговой и региональных органов, которые должны отдавать данные по запросу в реальном времени. Ключевое требование 210-ФЗ – перевод услуг в электронный вид и обмен через единую систему межведомственного электронного взаимодействия (СМЭВ). Это значит, что ведомственные реестры нужно привести к согласованным форматам и выставить наружу веб-сервисы с гарантированными SLA.

На практике большинство учётных систем не готовы к такой нагрузке. Запросы к карте идут синхронно, отклик нужен за секунды, а не за часы пакетной выгрузки. Здесь помогает разделение контуров: оперативный слой обслуживает онлайн-обращения, аналитический работает отдельно. Подход к консолидации разнородных источников мы разбирали в материале про BI поверх больших данных – для УЭК актуальна та же дисциплина чистых справочников и единых ключей идентификации.

Отдельная задача – масштабирование. Пиковая нагрузка на региональный сегмент непредсказуема, а закупать железо под максимум невыгодно. Эластичную инфраструктуру под такие сценарии мы описывали в заметке про архитектуру частного облака: ведомственный контур остаётся в защищённом периметре, но ресурсы выделяются по требованию.

Что готовить банкам

Банк в схеме УЭК отвечает за платёжное приложение и одновременно становится оператором части персональных данных. Это два разных уровня ответственности. Платёжный модуль интегрируется с процессингом по правилам ПРО100 – национальной платёжной системы, под которую карта и проектируется. Здесь нужны доработка эмиссии, поддержка контактного чипа и стыковка с банкоматной сетью.

Сложнее с данными. Каждое обращение по карте – это идентификация владельца, проверка статуса приложения и фиксация операции. Объём событий растёт линейно с числом держателей и быстро уходит за рамки классической реляционной СУБД, особенно на журналировании и аналитике обращений. Для таких потоков мы рекомендуем колоночные и нереляционные хранилища – почему, разбирали в обзоре NoSQL и колоночных хранилищ.

Связующее звено – интеграция

Самостоятельно ни ведомство, ни банк всю цепочку не закрывают. Между реестрами, СМЭВ, удостоверяющим центром и процессингом нужен слой, который маршрутизирует запросы, гарантирует доставку, проверяет ЭЦП и ведёт неотказуемый журнал. Без сервисной шины и единых контрактов сервисов система рассыпается на ручные сверки.

Мы строим именно такие связки – от проектирования контрактов веб-сервисов до промышленной эксплуатации под СМЭВ. Стык ведомственных и банковских контуров закрывается через системную интеграцию реестров, шины обмена и инфраструктуры ЭЦП: согласование форматов, маршрутизация запросов и нагрузочные испытания до запуска.

Вывод

УЭК – это интеграционный проект, а не выпуск карт. Срок 2012 года выглядит далёким только на бумаге: реестры, СМЭВ и платёжное приложение готовятся месяцами. Начните с инвентаризации сервисов и согласования форматов уже в этом квартале – тогда к старту выдачи карта заработает, а не останется пилотом на бумаге.