Требования дбо

Оглавление:

Дистанционное банковское обслуживание

Интернет Клиент

Мобильный Клиент

Электронный документооборот B2B

Интеграционный Банк Клиент

Система «Клиент-ТелеБанк» (StepUP)

Личный кабинет

Банк ВТБ — ваш расчетный Банк

Используя систему дистанционного банковского обслуживания (ДБО), клиенты могут проводить банковские операции в электронном виде непосредственно как из офиса, так и со своего мобильного компьютера (ноутбука), смартфона, находясь вне офиса.

Система ДБО позволяет:

  • формировать документы по расчетным операциям: платежные поручения, заявления на перевод, покупку, продажу валюты, заявления на конверсию, поручения на списание средств с транзитного счета;
  • формировать документы валютного контроля: по постановке на учет контрактов или кредитных договоров, сведения о валютных операциях, справки о подтверждающих документах, заявления о постановке на учет и снятии с учета контрактов или кредитных договоров;
  • формировать документы по депозитным сделкам: заявление на размещение депозита, заявление о продлении срока депозитной сделки, уведомление о согласии на размещение депозита, уведомление о согласии на продление срока депозитной сделки;
  • формировать документы по аккредитивам в иностранной валюте и валюте РФ: заявления на открытие аккредитивов, заявления на изменение условий аккредитивов, заявления об акцепте/отказе от акцепта документов по аккредитивам;
  • проводить операции с использованием документов свободного формата в рамках договоров и соглашений, заключенных между клиентами и Банком.

В системе ДБО предусмотрена возможность отслеживать состояние отправленных документов, проводить поиск документов за отчетный период, получать выписки по счетам и обмениваться с Банком сообщениями в свободном формате. Клиенты также получают доступ к различным справочникам.

Вы можете подключить один или сразу два сервиса дистанционного банковского обслуживания: Интернет-Клиент и Банк-Клиент.

Требования к разработчикам ДБО

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

Но Россия тут не пионер. Одним из первых к этой теме обратился PCI SSC, который выработал определенные требования к разработке платежных приложений — стандарт PA DSS . Правда, подпадают под него далеко не все приложения , которые обрабатывают финансовые потоки. В т.ч. под него спокойно могут не попасть многие системы ДБО, особенно для юридических лиц, т.к. они не обрабатывают данные платежных карт. Но как основа для формирования собственных требований данный стандарт подходит достаочно неплохо.

Еще один интересный документ был опубликован совсем недавно — в январе этого года. Речь идет о Software Assurance Framework от BITS — подразделения по разработке технологических политик Financial Services Roundtable. Этот 53-хстраничный документ, который описывает целую программу защищенной разработки ПО для финансовых институтов. 8 частей этого документа охватывают все необходимые темы при разработке защищенных приложений:

  • Обучение и тренинги разработчиков
  • SDLC. Тема SDLC становится достаточно популярной в последнее время. И я про нее писал в блоге и в отдельной статье в «ИТ Менеджере». Эта же тема освещается и на специализированной конференции в России — SECR .
  • Моделирование угроз. BITS упоминает Microsoft STRIDE, хотя таких стандартов и рекомендаций существует десятки (я их рассматриваю в курсе по моделированию угроз). И писал про это недавно.
  • Лучшие практики программирования. Интересно, что BITS не выдумывает ничего своего, а отсылает к уже существующим практикам — OWASP Secure Coding Practices Guide, Department of Homeland Security Build Security In Portal, CERT Secure Coding, MSDN Security Developer Center и т.д.
  • Тестирование безопасности. Этот кусок очень неплохо расписан — упомянуты различные программные продукты, виды анализа кода и т.д.
  • Практика предварительного внедрения
  • Документирование. Раздел подробно описывает, какие документы должны сопровождать разработку и тестирование программного обеспечения.
  • Контроль пост-внедрения.

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

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

Как создать и развить эффективную ДБО-систему в банке

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

Без хорошего ДБО — никуда

В настоящее время дистанционные каналы обслуживания стали неотъемлемым атрибутом для банковской отрасли (своего рода «must have»). Сложно представить себе банк, у которого отсутствует и в ближайшее время не появится интернет-банк, мобильный банк и другие удаленные каналы по обслуживанию клиентов. В этой области идет серьезная конкуренция между финансовыми организациями за функциональность своих решений и за удобство их использования. ДБО стало инструментом борьбы за клиента и за долю на рынке.

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

Хотим все и сразу

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

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

Много и быстро — сложно и неэффективно

Внедрение полнофункциональной ДБО-системы и ее успешное функционирование сопряжено с целым рядом серьезных ограничений.

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

Читайте так же:  Налог на тягачи

Во-вторых, самые трудоемкие и сложные этапы при внедрении систем ДБО — это интеграция со смежными системами: АБС, процессинговыми центрами, системами приема платежей, антифрод-системами и многими другими. Как следствие, если банк хочет получить решение с широкой функциональностью в короткие сроки, то указанные системы также должны дорабатываться в соответствии с его амбициозными планами. Реализовать это также непросто, поскольку обычно такие системы имеют свои планы развития.

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

И, наконец, в-четвертых, при внедрении ДБО-систем должны соблюдаться требования безопасности и нормы законодательства, при этом нужно часто проходить аудит на соответствие этим требованиям. Чем шире функциональность, тем сложнее становится этот процесс, и тем больше времени он отнимает.

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

Альтернативный вариант: в первую очередь — все самое необходимое

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

С одной стороны, система ДБО должна предоставлять определенные сервисы, пользуясь которыми клиенты банка получат удовлетворение от применения системы.

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

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

Чем для начала клиентов порадуем?

Первым делом следует внедрять минимально необходимый набор возможностей, который должен быть реализован в интернет-банке и мобильном банке, причем функциональность мобильной версии не должна быть ниже, чем у «десктопной», поскольку клиенты банков все больше операций совершают со смартфонов. Итак, обычно в первую очередь мы рекомендуем внедрять:

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

— информационные сервисы: остатки на счетах, задолженности по кредитам, сроки очередных платежей, история всех операций. Клиент должен ориентироваться в структуре своих финансов, должен знать, когда, где и сколько он заплатил, когда и сколько он должен заплатить, сколько средств на его счетах и т.п.;

— денежные переводы: внутрибанковские, межбанковские, с карты на карту своего и чужого банка (P2P-переводы), возможность оформить наиболее частые операции в виде шаблонов регулярных платежей;

— оплата услуг. Чем шире набор поставщиков, чьи услуги пользователь может оплатить через интернет-банк, тем лучше. Если есть региональные филиалы, то не следует забывать и о региональных провайдерах;

— интеграция с сервисами госуслуг: получение информации и мгновенная оплата штрафов ГИБДД, налогов и других бюджетных начислений.

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

Что и как делать дальше?

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

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

— пожелания банка по скорости обновления системы;

— возможности банка по обновлению системы;

— готовность процессов и внешних систем;

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

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

Основные преимущества развивающейся системы

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

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

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

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

Секрет успешного развития ДБО-решения

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

Читайте так же:  Размер пособия при учете на ранних сроках

Обо всем этом следует подумать заранее, чтобы потом без особых дополнительных усилий новые возможности и сервисы подключались к новым системам.

ДБО для юридических лиц: четыре тренда изменений

Сегмент ДБО для корпоративных клиентов традиционно более консервативен и инертен к инновациям. Многочисленные отраслевые конференции сегментируют информационные потоки, жестко разделяя информационный контент; подразделения банков, курирующие корпоративный и розничный сегменты, как правило, изолированы от задач друг друга и почти никогда не смотрят на потребителя под одним углом. Но настолько ли кардинальны различия в целевой аудитории, инструментарии и подходах к взаимодействию?

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

Долгие годы основным потребителем интернет-банка для юридического лица был сотрудник финансовой службы или бухгалтер. Не самый требовательный потребитель, не так ли? «В довесок» к неприхотливости этой части потребителей можно добавить и неизбежность использования сколь угодно неудобного ДБО по причине использования бизнесом, например, кредитного продукта в конкретном банке.

Вплоть до 2014 г. рынок этих программных продуктов как будто замер на месте: и без того небольшой по размеру, он был поделен между 4–5 всем известными вендорами, которые не предлагали ничего существенно отличающегося друг от друга с точки зрения пользовательского опыта. Данный сегмент отраслевых программных решений как будто пропустил случившуюся вокруг рынка интернет-технологий цифровую революцию, или, как ее еще называют, диджитализацию, со всеми вытекающими best practice из рынка цифровой коммерции и digital-маркетинга.

Какой пользовательский опыт в части корпоративных ДБО предлагают нам многие банки даже сегодня?

1. Установка и настройка рабочего места часто похожи на увлекательный IT-квест, для прохождения которого требуется или невероятное терпение, или помощь айтишника.
2. Мы все еще сталкиваемся с ограничениями на работу с интернет-банком в популярных браузерах и различных операционных системах.
3. Прорвавшись сквозь всевозможные неудобства и ограничения, мы попадаем в достаточно изолированную узкофункциональную среду, в которой часто ничего кроме базовой транзакционной функциональности сделать нельзя.

Только задумайтесь: информационная система, которой является в банке ДБО, достоверно идентифицирующая клиента, знающая его финансовое состояние, в 99% случаев абсолютно не приспособлена ни для комплексного обслуживания этого самого клиента, ни для роли удаленного офиса продаж банка.

Большая часть всех этих проблем давно уже решаема, и банки, сделавшие ставку на digital-канал, ушли в отрыв от менее прогрессивных коллег: рост базы «Точки», Модульбанка, «Тинькофф Бизнеса» тому яркое подтверждение.

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

Для того чтобы на качественно ином уровне решить данную задачу, нужен совершенно другой тип компетенций в разработке цифровых систем, который исторически сформировался в среде разработки SaaS-сервисов и e-commerce-решений.

Успешные SaaS-сервисы и e-commerce-решения в своей ДНК бережно хранят миссию по улучшению оцифрованных пользовательских метрик. Digital-аналитика – основной источник принятия решений о развитии продуктовой среды взаимодействия с клиентом. Это сервисы для конечных потребителей, а не их представителей, которые никуда не денутся, как бы ни был неудобен интерфейс.

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

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

Тренд № 1 – разделение классического ДБО на независимый фронт и бэк
При формировании фронтальных платформ ДБО на первый план выходят не только UX-/UI-экспертиза в финансовых сервисах, но и e-commerce-экспертиза и неразрывно связанная с ней экспертиза в digital-маркетинге.

Как часто вы замеряли конверсии в своем интернет-банке? В современных фронтальных средах ДБО это неотъемлемая метрика для продуктового аналитика. Конечная реализация фронтального слоя дистрибуции в каждом конкретном банке – это воплощение принятой в банке digital-стратегии, наложенной на профиль абонентской базы: этот профиль определяет прежде всего набор востребованных нетранзакционных сервисов.

Возможность «разорвать оковы» стандартного дистрибутива ДБО на данный момент достигается двумя способами:
1) заменой старого поставщика ДБО на нового вендора, предоставляющего хорошо документированный и функциональный API для создания внешних фронтальных сред;
2) самостоятельной реализацией middle-слоя к старому решению ДБО, если лицензионная политика взаимодействия с вендором это позволяет.

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

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

Рисунок 1
Разделение ДБО на бэкэнд и фронтальную среду

Фронтальный слой дистрибуции может быть сколь угодно глубоко и часто изменяем в отрыве от поставщика лицензий ДБО. Банку становятся доступны любые возможности по брендированию и проектированию удобных UI/UX-сценариев в интерфейсе и расширению их функциональности.

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

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

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

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

Рисунок 2
Единая коммуникационная среда банка

А API-интегрированные сервисы в этой среде дают возможность клиенту получать любую услугу в несколько кликов: он не озадачен договорными отношениями с новыми поставщиками, контролем оплат, регистрациями – он просто подключает услугу, а банк списывает за нее деньги.

Читайте так же:  Федеральный закон от 30 ноября 2010 г n 327-фз

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

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

И тут стоит отметить успехи команды «Точки», чье мобильное решение уже нашло международное признание в премии SME AppsBank Awards, заняв третье место.

Мобильная среда не является заменой традиционному браузерному интернет-банку: при правильном подходе она должна позволять совершать все типы наиболее востребованных операций.

Если ваш банк только стоит перед задачей внедрения корпоративного мобильного интернет-банка, мы бы рекомендовали итеративный подход.

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

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

Рисунок 3
Этапы внедрения мобильных приложений

Если говорить о рекомендуемой последовательности внедрения, то мы бы ее описали так:
1) реализация удобного адаптивного интерфейса для браузерного интернет-банка (это можно делать даже в гайдлайнах iOS и Android отдельно);
2) внедрение гибридного приложения — оболочка с наиболее востребованными функциями классического приложения и коммуникационными механиками (touch ID, push-нотификации и т.д.) и встроенная в оболочку браузерная часть адаптивного интернет-банка;
3) полноценное мобильное приложение на кроссплатформенных или нативных технологиях.

Второй этап рекомендуется для быстрой проверки гипотез и снятия пользовательского фидбэка о функциональной достаточности.

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

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

Тренд № 4 – экосистемный подход, открытая архитектура, API для корпоративных и внешних информационных систем
Решив проблему удобства взаимодействия на пользовательском уровне, современное корпоративное ДБО становится всего лишь частью большого экосистемного подхода и в вопросах автоматизации бизнеса.

При таком подходе ДБО становится не только транзакционным инструментом, но и незаменимым поставщиком и реципиентом данных для автоматизации бизнеса: такое ДБО должно иметь «на борту» автоматические инструменты интеграции с популярными CRM-платформами, учетными и складскими системами, биллингами, биометрическими платформами, ритейл-системами и иметь открытый API для корпоративных IT-систем.

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

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

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

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

Банки – это консервативные структуры, и многие до сих пор не умеют работать по Agile с внешними подрядчиками и поставщиками, а еще меньшее количество умеют применять подходы Agile в финансировании.

Однако только гибкое управление требованиями и гибкие методологии реализации (рис. 4) позволяют выводить на рынок успешные продуктовые кейсы, не уходя в проектные «долгострои».

Рисунок 4
Гибкая методология реализации

Пока банки, выделившие задачи по трансформации ДБО в отдельные структуры digital-банкинга и inhouse-лаборатории, демонстрируют более высокий рост. Возможны ли сейчас успешные кейсы в банках с традиционной оргструктурой и традиционными подходами к проектной деятельности – вопрос открытый.

Эта статья была разослана 387 людям, которые подписались на тему «Интернет-банкинг»

Чтобы подписаться на «Интернет-банкинг», просто введите Ваш
электронный адрес.

Требования законодательства к системе ДБО клиент-банк в организации

  • Регистрация: 18.04.2013
  • Сообщений: 35

  • Регистрация: 27.10.2013
  • Сообщений: 6

Хотел уточнить, в качестве кого выступает обычная, не банковская и не кредитная организация, в ФЗ-161?

Оператор по переводу денежных средств или кто?

И какие в обычном клиент-банке персональные данные? ФИО генерального директора и главного бухглатера?

  • Регистрация: 05.09.2008
  • Сообщений: 97

  • Регистрация: 27.10.2013
  • Сообщений: 6

  • Регистрация: 05.07.2012
  • Сообщений: 70

  • Регистрация: 26.05.2004
  • Сообщений: 1636

Это где вы нашли такое обязательное требование по сертифицированную криптозащиту? Не знаю такого требования.

А вообще-то, все законодательные требования изложены в 382-П.

  • Регистрация: 08.08.2011
  • Сообщений: 62
  • Регистрация: 31.08.2003
  • Сообщений: 1542
  • Регистрация: 06.03.2007
  • Сообщений: 3184
  • Регистрация: 06.03.2007
  • Сообщений: 3184
  • Регистрация: 31.08.2003
  • Сообщений: 1542

  • Регистрация: 27.10.2013
  • Сообщений: 6
  • Регистрация: 31.08.2003
  • Сообщений: 1542

  • Регистрация: 05.07.2012
  • Сообщений: 70

  • Регистрация: 27.10.2013
  • Сообщений: 6

В п.1 382-П отсутствует » клиент».

Есть:
1. операторы по переводу денежных средств
2.банковские платежные агенты (субагенты),
3.операторы платежных систем,
4. операторы услуг платежной инфраструктуры.

Т.е. 382-П для клиента не обязательный документ.

  • Регистрация: 31.08.2003
  • Сообщений: 1542

В п.1 382-П отсутствует » клиент».

Есть:
1. операторы по переводу денежных средств
2.банковские платежные агенты (субагенты),
3.операторы платежных систем,
4. операторы услуг платежной инфраструктуры.

Т.е. 382-П для клиента не обязательный документ.

  • Регистрация: 27.10.2013
  • Сообщений: 6
  • Регистрация: 06.03.2007
  • Сообщений: 3184
  • Регистрация: 17.06.2008
  • Сообщений: 1595
  • Регистрация: 31.08.2003
  • Сообщений: 1542

  • Регистрация: 08.08.2011
  • Сообщений: 62
  • Регистрация: 31.08.2003
  • Сообщений: 1542

  • Регистрация: 05.07.2012
  • Сообщений: 70

  • Регистрация: 05.07.2012
  • Сообщений: 70
  • Регистрация: 06.03.2007
  • Сообщений: 3184

  • Регистрация: 05.07.2012
  • Сообщений: 70

  • Регистрация: 26.05.2004
  • Сообщений: 1636

Эту сказку тут рассказывали много раз. Не верю! (с) Такое могло быть только в мелком региональныом банке или региональном филиале.

Вот скажите мне, «Доходчиво объяснили» это, как? Какое предписание прислали? На какой документ сослались? А что на это прокуратура сказала? Не верю, что бы в банке из топ-5 юристы это просто так оставили. Так к ним завтра зайдут братки из местных и «доходчиво объяснят» что им надо платить за крышу.