Изнанка интерфейса

Месяц назад мы опубликовали на этом самом месте статью Александра Евтюшкина "Электронные расчеты и технологический фетишизм" (#39 [267], сс. 36-37) и попросили откликнуться тех, кому есть что сказать по поводу существующих расчетных и платежных систем в Internet. Отклики пришли, но не так чтобы много: то ли не пользуется никто этими системами, то ли те, кто пользуется, не читают "Компьютерру", то ли сказать нечего...

Напомню, что Евтюшкин в статье критиковал разработчиков системы "КиберПлат" (www.cyberplat.ru), первой российской онлайновой системы для оплаты покупок через Internet, за "технологический фетишизм", переусложненность и аргументировал в пользу переноса в Internet клиент-банковской архитектуры.

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

Предварительное замечание: с моей точки зрения, ситуация внедрения "расчетных и платежных систем в Internet" (что бы под ними ни понимать) в России принципиально отличается от ситуации с их внедрением, допустим, в Америке. Чем? Тем, что в России нормальной и сколько-нибудь удовлетворительно выполняющей свои функции инфраструктуры расчетов и платежей нет и во внесетевом мире. Этот тезис еще полгода назад вызывал массу возражений; сегодня, я думаю, их уже не последует.

И³

Интерфейс интересен, прежде всего, тем, что он интерфейс к чему-то. Финансовый интерфейс - это интерфейс к финансовым инструментам и институтам. Вот "магическая" мнемоническая формула: Инструменты, Институты, Интерфейсы (И³). Поставьте что-то в каждую вершину этого треугольника, и вы получите "расчетную систему", которую можно серьезно обсуждать.

Создал ли банк "Платина" расчетную систему, запустив "КиберПлат"? Да, в определенном смысле - создал, добавив свой интерфейс к банку (как институту) и средствам на счете клиента (как инструменту). Поскольку и институт, и инструмент вполне "консервативны", вся сумма упреков Евтюшкина в основном пролетает мимо, или, точнее, сосредотачивается лишь на интерфейсной части.

Евтюшкин хочет систему "клиент-банк", работающую через Internet? "КиберПлат" и есть в своей инструментальной основе система "клиент-банк", позволяющая клиенту распоряжаться средствами на счете. В известном смысле, 29 октября (уже после публикации статьи Евтюшкина) банк "Платина" подтвердил это, предоставив пользователям системы оформлять платежные поручения, позволяющие выполнить банковский перевод на любой счет в любом российском банке (см. www.cyberplat.ru/i_plat3.htm). Почему эта функция не была заявлена до кризиса и почему она заявлена в октябре, надеюсь, понятно?

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

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

Нужны ли нам деньги?

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

Дальше. Насколько я помню общую методологию проектирования, "идеальным", с точки зрения проектировщика, является компонент системы, которого нет. То есть, функция выполняется, а соответствующей ей организованности материала (со всеми ограничениями, материалом накладываемыми) нет.

Как можно реализовать функцию смазки в системе "каток", где нужно обеспечить скольжение конька по поверхности? Я очень живо представляю себе решение, которое предложили бы "консервативные" банковские технологи типа архитекторов S.W.I.F.T. или процессинговых систем. Большая гладкая поверхность, залитая солидолом. Ватерпасы и сервоприводы, обеспечивающие ее горизонтальность. Форсунки, подающие солидол, чтобы компенсировать утечку из-за того, что идеальную горизонтальность обеспечить все же не удается. И так далее.

На самом деле катки строят проще: заливают поверхность водой и ждут, пока она замерзнет. Ледяная площадка ровная и сухая; под коньком лед тает, и вода выполняет роль смазки, позволяя ему скользить по мокрой поверхности. Конек прошел - вода опять замерзла и никуда не денется, не утечет.

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

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

Экономически такая модель означает, что исчезают пресловутые "финансовые потоки", к которым присасываются разнообразные паразиты.

Задание технологу: инструменты должны быть реализованы так, чтобы указанные "раз-два-три" совершались "в одно касание", а сама система - быть достаточно большой (иметь достаточное количество участников), чтобы любой актив был ликвидным в каждый момент времени.

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

Это - повестка дня в том, что касается инструментов. Что с институтами?

Нужны ли нам банки?

Как обеспечить отработку протоколов финансовой криптографии?

Есть в этой области такой культурный герой, Роберт Хеттинга (Robert Hettinga), нашим постоянным читателям он знаком по статье "Геодезическая экономика и финансовая криптография" ("Компьютерра" #235, сс. 3-11 Приложения). Последние полгода Боб без остатка посвятил себя "евангелической" деятельности по реализации идеи цифровых сертификатных инструментов, он провел несколько интересных мероприятий и развернул новый онлайновый ресурс Financial Technology Evangelism (www.philodox.com), содержащий, в частности, его очередную (следующую после статьи, написанной для нас в феврале) большую статью.

Она называется "Рыночная модель для подписки на предъявительские цифровые инструменты"
(A Market Model for Digital Bearer Instrument Underwriting), и я не уверен, что ее стоит сейчас публиковать по-русски в "Компьютерре", но несколько тезисов перескажу. Достаточно вольно, на свой страх и риск.

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

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

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

Есть ли в данной схеме место для такого "универсального финансового института", как банк? Думаю, что нет, хотя на рынке место для традиционных банковских услуг (например, кредита - но банк в этом отношении является обычным торговцем) останется. Может ли бизнес по "подписке" на цифровые инструменты вырасти из банковского бизнеса? Конечно, да. Более того, у нас банковское сообщество - наиболее вероятная среда появления моделей такого бизнеса... если банки не будут слишком консервативными.

Судьба финансовых интерфейсов

if x
then
writeln ("X - ложно");
(из какой-то программы)

И вот только теперь можно (и нужно) вернуться к вопросу об интерфейсах. По отношению к интерфейсам обычно обсуждается их 1) функциональность и 2) удобство/привлекательность.

Мне кажется важным отметить 3) "честность" интерфейса. Существует масса случаев, достаточно точно покрываемых эпиграфом к этой главке (для тех, кто не читает на Паскале, переведу: "Если x истинно, напечатать: "X - ложно").

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

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

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

Я, в общем, согласен с Валерием, что в "карточной" половинке своей "КиберПлат" банку "Платина" не удалось реализовать этой функции: операция с карточкой, зарегистрированной в системе, остается, как говорят банкиры, "MOTO-операцией" (от "Mail Order/Telephone Order" - "заказ по почте/заказ по телефону"), то есть операцией, совершенной без физического присутствия карточки и "откатываемой" по первому требованию клиента. С торговца, таким образом, не снимаются риски неуплаты, и он должен каким-то образом управлять ими (заранее закладывать потери в бизнес-план, страховаться и т. п.)

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

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

А кроме доступа к собственно финансовым инструментам, совсем неплохо будет, если интерфейс будет интегрирован и собственно с "витриной" Internet-магазина. Что и попытались сделать разработчики системы "КиберПлат", и, по-моему, не самым худшим образом.

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

Мне кажется, было бы разумным предоставить клиенту целый набор различных интерфейсных метафор и позволить выбрать ту, которая ему наиболее понятна и привычна. Для кого-то такой метафорой окажется "чек", для кого-то - "карточка". Но самая убойная метафора - это, конечно же, монета или банкнота. Процитирую себя, цитирующего Хеттингу, рассказывающего свой сон:

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

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

Итак, основные требования к финансовым интерфейсам:

1. "честность" визуализации функций инструмента, доступ к которому предоставляет интерфейс;
2. возможность доступа посредством одного интерфейса к различным инструментам (например, к средствам на счете, к банковской гарантии и т. п.);
3. расширяемая функциональность и открытость интерфейса, позволяющая менять его посредством обновления или добавления модулей.

Мне кажется, из этого следуют по крайней мере два вывода:

1. перспективной является ориентация в качестве технологической основы для финансовых интерфейсов на единую гипертекстовую/гипермедийную среду (сегодня единственным претендентом на роль такой среды мне кажется набор протоколов http/html(xml), в просторечии - Web или WWW);
2. рано или поздно требования единого интерфейса ко многим инструментам поставят под вопрос целесообразность наличия отдельных инфраструктур для обращения этих инструментов, и издержки обращения будут срезаться за счет переноса самих инструментов из специализированных выделенных в универсальные и общедоступные компьютерные сети. И это будет смертью "безналичных расчетов" - технологий, переходных от систем оборота осязаемых, "физических" сертификатов к системам оборота сертификатов цифровых.