О дырявых и не дырявых интернет-банках я уже писал. Сейчас речь пойдёт об удобных и неудобных.
Современный человек живёт интересами семьи, работой, развлечениями. И его не заставишь читать инструкции. Ему вынь да положь всё интуитивно понятное, простое и удобное. Но, конечно же, не в ущерб содержательной стороне дела.
Наверное в этой теме вы ждёте от меня привычных текстов о числе кликов, раскраске интерфейса или количестве шаблонов. Но эти вопросы уже на приличном уровне решены в любом серьёзном интернет-банке. Мне же хотелось бы копнуть намного глубже.
ЯДРО
Разговор на эту тему начну с архитектуры систем удалённого доступа. Так исторически сложилось, что раньше делали интернет-банки для юрлиц, затем - физлиц, потом - мобильные приложения. Это были локальные разработки, нередко написанные разными программистами. Ни о каких единых программных ядрах и интерфейсах в то время даже не помышляли. Вот поэтому сегодня клиенты и стреляются от такого зоопарка. Но, к сожалению, эта архаика заполонила весь рынок России.
Современные же системы удалённого доступа имеют другую архитектуру. Клиент работает в одной и той же программной среде. Одним кликом переходит от физлица к юрлицу. В одном сеансе может работать со всеми своими фирмами.
Каждое приложение связано с ядром через компьютер, телефон или IPad. Если программная среда едина, то в интернет-банке можно делать настройки для мобильных и карточных приложений. Это наращивает их функциональность, удобство работы и уровень защиты.
ИНТЕРФЕЙС
Интерфейс - достаточно специфическая тема. Требует специальных навыков. Поэтому будет лучше если его сделают не прикладные программисты, а ведущие специализированные фирмы. Но конечно же, в диалоге с разработчиками систем удалённого доступа.
Для создания любимого миллионами интернет-банка полезно посоветоваться с самим народом. Узнать что ему нравится, а что не очень. По своему опыту могу сказать, что люди у нас в России активные и закидывают программистов сотнями, а то и тысячами предложений. Задача разработчиков лишь успевать реагировать на энтузиазм масс, отделяя зёрна от плевел.
Для неопытного пользователя система удалённого доступа должна быть не только оснащена подсказками, но предугадывать его возможные действия и вести эффективный диалог.
Требования к простому интернет-банку очевидны - человек с первого раза без посторонней помощи может провести все платежи. Причём речь идёт не о куцем функционале, а максимально широком. И такие решения на рынке уже есть.
Общение с клиентами позволяет не только отполировать интерфейс, но и весь остальной функционал тоже. Скажем, без их советов практически невозможно довести до совершенства интеграцию с бухгалтерскими программами.
API-БАНК
Есть ещё одно интересное решение - бухгалтерская система предприятия напрямую связана с ядром банковской системы удалённого доступа, что позволяет работать без традиционного пользовательского интерфейса, снижая в сотни раз время на обработку платежей. Речь идёт об API-банке - автоматизации онлайн обмена между банком и бухгалтерскими программами.
Это критически важно для крупных сетевых клиентов, имеющих сотни, тысячи ежедневных платежей. А мне известны фирмы и с десятками или даже сотнями тысяч платежей (например, крупные торговые или терминальные сети). В этом случае им на архаике ехать ой как тяжело.
API-банк это также мощное оружие в конкурентной борьбе для интернет-магазинов, позволяющее им полностью автоматизировать работу с банком.
КОММУНИКАЦИИ
Обязательный элемент дружественного интернет-банка это эффективный диалог с клиентами. Активно работающий форум, быстро и грамотно отвечающий на звонки колл-центр, видеоролики, социальные сети...
Об уровне удобства работы могут судить не только специалисты по юзабилити, но и эксперты из бухгалтерских фирм. Так полнее и глубже можно оценить все плюсы и минусы работы с системами удалённого доступа.
В следующих статьях рассмотрю другие критерии оценки интернет-банков.
Комментарии 32
"Клиент работает в одной и той же программной среде. Одним кликом переходит от физлица к юрлицу. В одном сеансе может работать со всеми своими фирмами.
Каждое приложение связано с ядром через компьютер, телефон или IPad. Если программная среда едина, то в интернет-банке можно делать настройки для мобильных и карточных приложений. Это наращивает их функциональность, удобство работы и уровень защиты."
Что касается API - то это важным решением, но и оаньше существовал механизм обмена между банковскими системами и ДБО, возможно несколько проще, но с другой стороны универсальнее - файловый обмен.
Ну почему же не истиной? Я загружаю свой интернетбанк, работаю как ЮЛ, потом выбираю пользователя -ФЛ- и все в одном сеансе, в едином интерфейсе, не перелогиниваясь.
API-банк себе не настраивал, т.к. платежей немного, файловая закачка вполне устраивает раз в сутки. Но у кого сотни платежей- те это хотят подключить, где-то недавно читал, что такая потребность есть.
Я же не говорю, что это нельзя сделать:)
Риск какой именно ошибочной операции возрастает ? Какой вообще риск появляется при автоматизированной системе разнесения платежей, использующей API банка ? Если уж банк пустил платеж через свою систему, то как минимум все поля заполнены верно и однозначно трактуются. А коли так, то используя API мы получаем мега удобный инструментарий для автоматизации рутинных процессов оператора, ежедневно вносящего в бухгалтерскую систему поступающие платежи...
Посмотрим на это с другой стороны - отправка платежа без необходимости экспорта-импорта из бухгалтерской программы в клиент-банк и далее по маршруту... Вы сами задаете правила, при которых будет уходить/не уходить (нужное выбрать) платеж. Не доверяете (пока еще) API - платеж будет ждать вас на подписи в интернет-банке, доверяете - улетит сразу же, как только вы сформировали платежное поручение ВНУТРИ бухгалтерской программы.
А если платежки для вас готовит бухгалтер и вы желаете контролировать весь процесс расставания с деньгами - она, не выходя из привычной ей рабочей области, накидает нужное количество платежей за считанные секунды. Вам останется лишь зайти и подписать их все разом (одним кликом).
Резюмируя, скажу, API-банка предоставляет вам:
Что касается API - то это важным решением, но и оаньше существовал механизм обмена между банковскими системами и ДБО, возможно несколько проще, но с другой стороны универсальнее - файловый обмен.
Но согласитесь, когда API банка представлено целой открытой спецификацией, например, web-сервисов, то для различных интеграторов, мечтающих сделать взаимодействие с банком максимально бесшовным, жизнь сильно упрощается.
К тому же API, в отличие от файлообмена, подразумевает, что для доступа к сервисам банка потребуется пройти стандартную аутентификацию/авторизацию, например, по ключу/сертификату и передача данных будет шифроваться нужным образом
Вообще это верно для любой информации передаваемой клиентам в любых сервисах использующих в своей работе как транспорт - интернет (т.е. не только в банках).
Хотя явно все идет к тому что и на стороне клиента все это упростится и удешевится (нужны стандартные решения), и тогда даже совсем небольшие компании начнут массово использовать не ручную работу с приемом и отправкой платежей, и даже не через экспорт-импорт файлов, а работать - именно через API
Например, когда в Трока Диалог (а это даже не средняя организация) интегрировались с Kondor+, то интеграция была выполнена через файловую систему. И всё работало практически в режиме реального времени.
Как показала практика предлагаемое в то время API работало значительно медленнее.
Что касается авторизации и шифрования, то это зависит от конкретной реализации. Файловая система - это не только samba или ftp, но и sftp и другие протоколы связи.
А в Москве я так понимаю все еще накапливаются информация по межбанку и идет рейсами с какой-то периодичностью.
И если при съеме технической информации (там где нет необходимости иметь ее в непрерывном режиме) такое положение может оставаться еще довольно долго, то межбанковский обмен в Москве, все-таки неизбежно перейдет в онлайн. Это веление времени, технические задержки при расчетах субъектов в 21 веке слишком многих из клиентов не устраивают и их (не клиентов, а задержки!
Уже не раз ловил момент, когда платеж в 1С поступает и разносится быстрее, чем успевает прийти смс от банка - оно и понятно, смски стоят в очереди у оператора на отправку, а платежи разносятся сразу же по поступлении. Не буду лукавить, не онлайн (хотя такая возможность имеется, но необходимости нет), а раз в n секунд...
У нас реализована тесная интеграция бухгалтерии и менеджеров с банком с помощью API. Готов ответить на любые вопросы из теоретической (а лучше из практической) плоскости...
PS:
А где наши дорогие оппоненты ? где эта могучая четверка ?
Вас просто игнорируют. Вам все первые части пытались объяснить, что вести обсуждение в таком "ключе" мало кому интересно. За попытку это донести были забанены некоторые пользователи. Что Вы теперь хотите?
P.S Владимир Николаевич, можете считать, что это мой ответ на письмо в личку.
Для обсуждения были уже предложены процедура проведения рейтинга, выбор экспертов, оценка защищённости денежных средств клиентов, удобство работы с интернет-банками.
И неужели по всем этим поводам вам представителям рейтинговых агентств нечего сказать кроме хамских выпадов?
Если вы не согласны с моими подходами - оппонируйте. Расскажите о своих методиках оценки.
А то у меня складывается впечатление, что при переходе от общей части к конкретике представители рейтинговых агентств стушевались.
1) У кого кроме ИнБанка существует такой сервис (из федералов в особенности)
2) Как осуществить запрос и получить ответ от банка? Также как и Яндекс-АПИ?
3) Выдается ли информация об исполнении или отказе в исполнении исходящих платежек?
4) и на сайте ИнБанка выложена красивая картинка, что платежи разнесутся автоматически в том числе и по договорам. Но простите если в платежке единственный идентификтор контрагента это ИНН, то как можно в пределах контрагента правильно все по договорам разнести. Можно конечно максимально сократить ручной труд, но совсем избавиться от него вред ли получится?
5) Как организована защита в АПИ? Что сделано чтобы любой пользователь не увидел состояние счета и не наотправлял платежек
P.S. На всякий случай ремарочка. Прошу не думать, что опять увязываю автора блога с его должностью в ИнБанке. Вопрос "У кого кроме ИнБанка" возник после того как в Яндексе набрал API-банк. И яндекс только на ИнБанк указал.
Правда поиск рекомендую делать в Гугле (как я сейчас), а не в Яндексе. Гугль лучше ищет по моему мнению и куда меньше вставляет рекламных подставок на самые верхние строки поиска (в Яндексе это уже давно в ущерб собственно инструменту поиска).
Наверное, не корректно было бы нам, сотрудникам Инбанка, отвечать на такой вопрос. Обсуждать публично достоинства и недостатки других банков у нас не принято.
3) Выдается ли информация об исполнении или отказе в исполнении исходящих платежек?
Если нужны какие-то технические подробности, то дам несколько ссылок из нашей Wiki :
Т.е. есть некий набор web-сервисов.
Если в назначении платежа не будет больше никакой информации ни о договоре, счете или заказе, то понятно, что максимум, что можно - это привязать к контрагенту, ну там конечно же вручную привязать к нужному объекту. Всегда при любой автоматизации будет какой-то процент тех платежей, которые не удалось разнести автоматически. Здесь ведь важно, что вся рутина по заходу в интернет-банк, выгрузке в файл, загрузке в 1С (или куда), обработке в 1С целью привязке будет уже сделана и останется лишь необходимость разобрать ошибочные платежи, которые по каким-то причинам не разнеслись.
В Инбанке API представлен web-сервисами, которые работают через ту же криптографию, что и сам интернет-банк. Поэтому шифрование, электронные подписи - всё это есть стандартное.
2Шарухин Антон, с удовольствием дополню Алексея. По пунктам:
Есть много банков, заявивших о наличии API у себя, но, как в том анекдоте про дедушку, доктора и соседа - "и вы говорите...." Мне не знаком ни один другой банк, действительно реализовавший API на сколько-нибудь должном уровне, кроме разговоров...
Все делается с помощью web сервисов посредством крипто-канала (Inter-Pro)
Конечно! А иначе это был бы кот в мешке
В 99% платежей в поле комментария (назначения) платежа присутствует информация о счете, акте, счет-фактуре и т.д. на основании которых осуществляется платеж. Робот ищет по этим данным документ-основание и если находит, берет оттуда всю нужную инфу (в том числе и договор). Если не находит, то платеж разносится по контрагенту без указания договора, а в лог заносится инфа о возникшей проблемке и ответственному человеку (оператору, менеджеру, бухгалтеру и т.д.) улетает письмо или смс с указанием проблемки.
Не буду раскрывать секретов, но скажу, что технология защиты не отличается от обычной работы пользователя в интернет банке. Даже более консервативная в каком-то плане я бы сказал. К тому же робот, работающий на стороне 1С, не знает сколько денег у клиента на счету. У него другие задачи и для их выполнения ему не нужны вышеуказанные знания. Он лишь разносит поступающие платежи или отправляет их. Для это не нужно знать остаток. Если денег на счету не хватило - сработает обычный механизм, предусмотренный для таких случаев, в том числе и информирование клиента...
Тем не менее, соглашусь с вами - робот не может полностью заменить оператора (буха, менеджера и т.д.) Пока не может...
Алексею Романчуку, хочу сказать, что я ведь не прошу обсуждать достоинства и недостатки API сервиса у разных банков. Просто попросил дать информацию у кого это реализовано и не просил вдаваться в плюсы и минусы.
Пока как я понял что реализовано только у ИнБанка, а у всех остальных на уровне "программных заявлений". Задал вопрос своему банку, жду ответа.
Кстати наблюдаю примерно аналогичную картину в области эквайринга. Ручные терминалы предлагают установить все кому не лень. Но почему-то только Сбер и Альфа (причем по поводу Альфы уверен не до конца) предлагает не ручные терминалы, а пин-пады и впридачу к ним библиотеку sbrfcom.dll, как раз таки реализующую набор API функций по проведению эквайринговых операций, что исключает человеческий фактор при проведении операций с картами.
Кто что слышал, про аналогичные решения??? Или предоставление API и в и-банке и в эквайринге это пока нечто из ряда вон?
Но я думаю за ними не заржавеет, с учетом того сколько всего нового у них появилось в и-банке за два последних года. Да и владелец банка системотехник по образованию.
P.S. Дак а что насчет API в эквайринге? Неужели только Сбер у нас пионер?
Увы, это не аргумент. Не всегда хороший системотехник становится хорошим владельцем. Хотя хороший владелец вряд ли станет хороший системотехником)))
После ознакомления с возможностями API-банка мне показалось, что сам интерфейс можно совсем списывать с критерием, т.к. интерфейсом можно написать море, на любой вкус и цвет, лишь бы сопрячь их с банком - и все.
Есть, конечно, вопрос безопасности, как доверить доступ к своим счетам стороннему производителю программ, но в Инбанке это может решаться отдельными (самостоятельно выпущенными пользователями специально для "домашней бухгалтерии") ограниченными ключами с соответственно настроенными разрешениями.
Да. Этим обычно и пользуются программисты при реализации интеграции с Инбанком, прежде чем переносить наработки на юридические лица.
Программисты пишут API банка. API это интерфейс. Поэтому по нормам русского языка интерфейс банка.
Я же пишу API-банк как имя собственное.
Посмотрим какое написание приживётся.
Лет десять назад мне позвонил гражданин и сказал, что написал про меня мерзости. И если я не хочу продолжения публикаций, то должен ему заплатить.
Ответил ему, что он ас чёрного пиара, то есть пиарас, и я не возражаю против его дальнейших писаний. Пишет до сих пор. А я горжусь тем, что придумал новое русское слово.
Что касается интерфейса, то практика внедрения ерп систем говорит о том, что человек привыкает ко всему (даже плохому), и перевести его на что-то новое и более совершенное в части удобства интерфейса очень даже не просто. Но когда с большим трудом переведешь - говорят: "Как стало удобно... "
По себе скажу, что очень грустил по интерфейсу нортон-командер... и долго никак не привык пользоваться виндовсовскими окошечками. Но через какое то время освоился...
Леонид Шейкман один из них.
Добавлю. Леонид уже связался с одним из наших партнёров в разработке прикладных сервисов и они объединяют свои услия, уже совместно занимаясь автоматизацией бухгалтерского обслуживания.
С каждым днем ко мне поступает все больше и больше запросов на установку автоматизированной системы разнесения платежей в 1С с помощью предоставляемого Инбанком API.
Демонстрация возможностей занимает 10-15 минут. И все. Клиент хочет себе эту обработку
К тому же, привыкать к чему-то новому не надо - наоборот, перестаешь заниматься рутиной...