В долгах как в шелках. Рост рынка потребительского кредитования. Правила денег от Уоррена Баффета, инвестора №1 в мире.

Комплексный подход к обслуживанию пластиковых карточек в коммерческом банке

Андрей Маховой
Игорь Даниловский

Требования к технологии обслуживания пластиковых карточек

После августовского кризиса 1998 г. роль пластиковых карточек как платежного средства стала постепенно снижаться, и многие участники карточного рынка утратили интерес к работе с этим финансовым инструментом. Такая тенденция сохранялась до конца 2000 г., после чего интерес ко всем видам карточных продуктов стал резко возрастать. Это связано, по всей видимости, с наметившимся подъемом отдельных отраслей промышленности, в первую очередь нефте- и газодобывающих, а также с выходом банковской системы России из кризисного состояния. Тем не менее за два послекризисных года ряд банков утратил свои ведущие позиции на рынке карточных услуг и в тоже время появились новые активные его участники. На сегодняшний день крупнейшими операторами, предоставляющими услуги по процессингу международных карточек Europay и VISA являются:

  • Сбербанк РФ,
  • Кардцентр,
  • Компания объединенных кредитных карточек,
  • ГУТА Банк,
  • Автобанк,
  • Мастербанк,
  • ТрансКредитКард,
  • Газпромбанк,
  • NPS Card.

    • Регулярные потрясения в банковском секторе России и смена ведущих игроков рынка пластиковых карточек требуют минимизации затрат банков, которые эмитируют карточки в качестве аффилиированных членов платежных систем или агентов крупных банков, по смене банков-спонсоров и переходе с одного процессинга на другой.

    Усиливаются требования международных платежных систем в повышении статуса банков-агентов до аффилиированных (ассоциированных) членов с правом выпуска карточек с собственным логотипом. Аффилиированное членство делает банки менее зависимыми от банка-спонсора. Гибкий подход к выбору банка-спонсора позволяет сократить затраты на выпуск пластиковых карточек.

    Тенденции на рынке карточных продуктов таковы, что большинство банков стараются эмитировать как минимум карточки двух международных платежных систем — VISA и Europay. Кроме этого, ряд банков параллельно с международными карточками поддерживают и карточки национальных платежных систем Union Card, STB, ACCORD, «Золотая Корона» и некоторые другие. Возможен также выпуск банком своих локальных банковских карточек, зарплатных карточек, корпоративных и пр. Достаточно часто различные типы карточек процессируются различными процессинговыми центрами, и банк вынужден иметь несколько бэк-офисов.

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

    Трехуровневая схема обслуживания пластиковых карточек

    Процесс обслуживания пластиковых карточек можно разделить на четыре большие группы операций: процессинговые операции, бэк-офисные операции, операции по бухгалтерскому сопровождению и операции по обслуживанию взаиморасчетов между участниками платежной системы. Существуют разные точки зрения относительно того, каким образом операции из этих четырех групп должны сочетаться в рамках различных программных продуктов. На наш взгляд, наиболее универсальной является трехуровневая схема с выделенным бэк-офисом. По этой схеме все фронт-офисные функции по процессингу и эквайрингу выполняются в процессинговом центре (ПЦ), функции бэк-офиса пластиковых карточек и операции по бухгалтерскому сопровождению проводятся в рамках выделенного бэк-офиса пластиковых карточек, а обслуживание взаиморасчетов происходит в рамках стандартных возможностей ОДБ банка.

    Схема работы с выделенным бэк-офисом имеет следующие преимущества:

    При таком подходе обмен данными между ПЦ и бэк-офисом наиболее целесообразно осуществлять при помощи набора файлов стандартных форматов, а связь с ОДБ — напрямую (если это позволяют технические средства) или опять же через файлы экспорта-импорта. Для обмена данными на уровне ПЦ — бэк-офис наиболее предпочтительными являются файлы текстовых форматов, которые являются читаемыми не только для ПО, но и непосредственно для человека. Недостатком таких форматов является их сложность для обработки машинными методами, поскольку информация, хорошо структурированная с точки зрения человека, оказывается обычно очень плохо структурированной для ее обработки на компьютере. Преимущество такого подхода заключается в том, что всегда имеется возможность обратиться к первоисточнику и посмотреть на него вживую, если все другие способы разбора нестандартной ситуации неэффективны.

    Объединение функций бэк-офиса и процессинга в одном программном продукте при всей своей кажущейся технологичности имеет ряд существенных недостатков, таких, например, как сложное подключение ко второму процессинговому центру, невозможность смены процессингового центра, сложность при добавлении карточных продуктов других платежных систем. Кроме того, объединение процессинового центра и бэк-офиса в рамках одного программного продукта приводит обычно к тому, что картсчета и депозиты физических лиц приходится обрабатывать в разных базах данных, что лишает банк гибкости в управлении финансовыми средствами клиентов.

    Необходимость интеграции бэк-офиса и ритейл

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

    Головной банк и филиалы: преимущества работы с единой базой данных

    Еще несколько лет назад большинство банковских ритейл-систем строилось по принципу раздельной работы головного банка и филиалов. В каждом филиале велась собственная база данных по розничным операциям. За последние 2—3 года эта идеология стала претерпевать существенные изменения. Благодаря бурному развитию средств коммуникации и каналов связи стало возможным переключить всю филиальную сеть банка по розничным операциям на единую базу данных. Онлайновый режим работы филиалов банка с общей базой имеет ряд неоспоримых преимуществ для крупного банка:

    Для отделений, которые по техническим причинам не могут работать напрямую с центральной базой данных, должен быть предусмотрен специальный офлайновый режим работы. Центральная база данных содержит в себе копию базы данных офлайнового отделения. В самом отделении оператором выполняются только простейшие действия по кассовому обслуживанию клиента, открытию/закрытию счетов и т.п. Все данные по новым клиентам, открытым или закрытым счетам, проводкам, пролонгациям и пр. передаются ежедневно в виде файлов в центральную базу данных по обычным низкоскоростным телефонным линиям. Таким образом достигается синхронность базы данных отделения и ее копии внутри центральной БД. Все групповые операции (такие, как начисление процентов, пролонгации, групповые зачисления зарплаты, групповые удержания комиссий) производятся по данному отделению внутри центральной базы данных и реплицируются в базу данных отделения посредством файлов специальных форматов. Кроме этого, в центральной базе данных для каждого счета отделения ежедневно рассчитывается сумма процентов, которые должны быть выплачены вкладчику при досрочном расторжении договора вклада. Эти суммы также реплицируются в базу данных отделения посредством файлового обмена. В случае досрочного расторжения договора вклада в таком отделении указанная сумма предлагается оператору как результат расчета процентов при досрочном расторжении, хотя реально никакого расчета не проводится. Такой подход позволяет существенно упростить уровень администраторской поддержки системы в небольших офлайновых отделениях и удаленных пунктах обслуживания, где, как правило, отсутствует квалифицированный персонал.

    Рис. 1. Схема организации онлайновых и офлайновых филиалов и отделений многофилиального бэк-офиса

    Первые разработки в этой области были проведены компанией «АСофт». Ее система была построена по двухуровневой схеме. Сервер СУБД ORACLE обрабатывал запросы к базе данных, которые он получал от специально разработанного сервера приложений. Все клиентские АРМы, в свою очередь, взаимодействовали с сервером приложений, на котором выполнялись процедуры обработки данных.

    НПФ «Инверсия» пошла по несколько иному пути. Многофилиальное решение было ею реализовано в рамках классической технологии Клиент—Сервер. Вся обработка данных была сосредоточена в хранимых процедурах СУБД ORACLE и производилась непосредственно не сервере баз данных. Система была построена по одноуровневой схеме. Программное обеспечение клиентских рабочих мест фактически выполняло только функции вывода данных на экран и поддержания диалога с пользователем. Выбор одноуровневой схемы и перенос всех вычислений и обновлений БД на сервер позволил добиться высокой производительности системы и почти нулевого трафика. Кроме того, данный подход позволил использовать все штатные способы контроля доступа к данным, предусмотренные в самой СУБД ORACLE, что невозможно при использовании многоуровневых схем обработки.

    Головной банк, аффилиированные члены и агенты

    Ведение базы данных в Головном офисе по всем карточкам, эмитированным самим банком, всеми его филиалами, банками — аффилиированными членами и агентами, позволяет решить многие проблемы обеспечения качества предоставляемых услуг по пластиковым карточкам. Разбор нештатных ситуаций, контроль за мошенничеством и управление рисками, разрешение претензий клиентов и соблюдение правил платежных систем требует высококвалифицированного и дорогостоящего персонала. При малом количестве операций по карточкам прием на работу сотрудника соответствующей квалификации экономически невыгоден. В регионах также существует реальная проблема нахождения сотрудников необходимой квалификации.

    При ведении единой базы данных сотрудники Головного офиса имеют всю необходимую информацию об операциях, выполненных клиентами филиалов, аффилиантов и агентов, и могут взять на себя все сложные вопросы обслуживания клиентов и взаимодействия с платежной системой, обеспечивая единый с Головным офисом уровень сервиса.

    Работа Головного банка строится по двухуровневой схеме. Отделения/филиалы банка выполняют функцию взаимодействия с клиентами, прием заявлений и передачу документов, информирование клиентов и выполнение операций по их счетам. Рабочее место операциониста позволяет в режиме онлайн кроме состояния счета получить информацию о карточках и задолженности клиента.

    Выпуск карточек, обработка транзакций и выполнение операций в соответствии с транзакциями, расчеты по эквайринговым операциям выполняются в Головном офисе бэк-офисом по операциям с пластиковыми карточками. Комплекс выполняемых операций обслуживается на нескольких рабочих местах: выпуск карточек и ведение картсчетов, обслуживание мерчентов (торгово-сервисных предприятий) и ведение операций по эквайрингу, выполнение клиринговых расчетов.

    Особенности обслуживания клиринговых операций

    Особенностью выполнения клиринговых расчетов является получение информации из различных источников, ее консолидация, обработка и привязка к соответствующим транзакциям, сообщениям о возвратных платежах, откате и др. Достаточно распространенной является ситуация, когда банк взаимодействует сразу с несколькими клиринговыми центрами, например, с одним — по операциям на территории России, а с другим — по операциям за рубежом. В такой ситуации особо следует обратить внимание на тот факт, что валюты клиринговых расчетов могут быть разными для различных клиринговых центров. Возможна ситуация, когда один из филиалов банка эмитирует свои собственные карточки со своим собственным клирингом. Межфилиальные расчеты значительно упрощаются при ведении единой базы данных, так как вся информация об операциях из различных процессинговых центров консолидируется в Головном офисе.

    Интеграция с зарплатными проектами

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

    Необходимость тесного взаимодействия с фирмами — разработчиками ПО

    Наиболее оптимальным является подход, когда бэк-офисное решение разрабатывается в тесном сотрудничестве между IT-подразделением банка и независимой софтверной фирмой путем модификации уже имеющихся у последней разработок. Проблемы крупного банка в области автоматизации розничного бизнеса едва ли могут быть решены в полном объеме на основе уже существующих коробочных технологий. Ряд тендеров, проведенных крупными российскими банками за последние годы (НИКойл, БашКредитБанк, ТрансКредитБанк), демонстрирует их тяготение именно к индивидуальному подходу в решении этой проблемы. В тоже время не следует связывать технологический прорыв в сферу карточных технологий с небольшими софтверными фирмами или даже группами внутрибанковских программистов. Приняв такое (несомненно, более дешевое) предложение, банк поставит себя в зависимость от одного-двух человек, и тогда болезнь, увольнение или несчастный случай с одним из них могут привести к серьезному сбою в работе банка.

    При выборе партнера для автоматизации карточного блока операций следует учитывать и имеющийся у него опыт работы в этой сфере. С осторожностью следует относиться к предложениям провести разработку ПО с нуля и в очень короткие сроки даже при наличии у потенциального партнера каких-то уникальных и вероятно, оригинальных средств сверхскоростной разработки на основе какого-то объектного подхода с непонятной аббревиатурой на конце. Чаще всего это используется как красивая приманка для не очень сведущих в области автоматизации руководителей высокого ранга. Как сказал один умный человек, «если бы такое средство было, то о нем все давно бы знали». К тому же любое оригинальное средство разработки может оказаться несовместимым с новой версией операционной системы или СУБД. Обычно такие предложения заканчиваются срывом сроков поставки ПО, невозможностью оптимизации по быстродействию чересчур объектно-ориентированного программного кода и массой нестыковок между различными модулями, что вполне характерно для заведомо невыполнимого проекта.

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

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


    Статьи, интервью, публикации