Google+
Журнал Плас Плас Журнал http://www.plusworld.ru/
ул. Кржижановского, д. 29, корп. 5 Москва, 117218 Россия
+7 495 961 1065 http://www.plusworld.ru/upload/templates/logo_plus_ru.png
RSS RSS RSS RSS

Быть ли «облаку» в банке?

(Нет голосов)

01.09.2011 Количество просмотров 1711 просмотров

Plus2011#08-22.jpg

Аспекты принятия банковским сообществом «облачных» подходов.

Борис Поддубный, директор по развитию бизнеса IBM


Как появились «облака»

Сегодня тема «облачных» вычислений и сервисов, без сомнения, находится в фокусе внимания всего информационного сообщества и справедливо является одним из факторов, способных революционным образом изменить нашу жизнь в информационном пространстве. Несмотря на голоса скептиков, справедливо замечающих, что с точки зрения применяемых технологий в «облачных» инфраструктурах ничего принципиально нового не придумано и основные технологии применялись и ранее, революционной является новая парадигма, в которой появляются новые участники информационного взаимодействия: поставщики и потребители информационных услуг, а основным полем взаимодействия классического «облачного» сервиса становится Интернет. Именно Интернет стал основным катализатором синергетического эффекта и смыслом интеграции всех тех технологических направлений, развитие которых мы наблюдали на протяжении последних 15 лет, включая системы управления серверами и сетями передачи данных, автоматизацию процессов обслуживания инфраструктур, появление и развитие подходов управления услугами ITSM (IT Service Management) на базе лучших практик ITIL (IT Infrastructure Library), развитие систем технического учета ресурсов и конфигурационные базы данных, системы самообслуживания клиентов и динамичное развитие порталов.

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

Такой подход широко распространен и наше время, когда компании, эксплуатирующие крупные дата-центры, считают, что предоставляют именно «облачные» услуги, имея только клиентский контактный центр, Help Desk с системой управления потоками работ и назначениями (нарядами), а также группу администраторов, которые «автоматизируют» все операции по управлению ресурсами дата-центра и выполняют клиентские заявки. При всех недостатках такого подхода, важный шаг, который эти компании уже сделали, – выравнивание парка серверов с точки зрения моделей в соответствии с предоставляемыми услугами, а также использование средств виртуализации, таких как Hyper-V или WMware. Что само по себе дает положительный экономический эффект, улучшая коэффициент использования и загрузки ресурсов, но возможно только в условиях слабой конкуренции. При высоком же уровне предложений «облачных» сервисов и снижении прейскуранта на них такая стратегия может обернуться убытками для компании, чьим профильным бизнесом являются «облачные» сервисы.

Над всей РФ безоблачное небо?

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

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

В свою очередь, зарубежный опыт показывает нам, что на Западе компании изначально учитывают непростые конкурентные условия и закладывают в свои сервисные платформы самые современные технологии управления и автоматизации, заботясь о рентабельности и устойчивости своего бизнеса. В результате они получают возможность с самого начала своей деятельности в этом направлении предоставлять через Интернет широкий набор «облачных» сервисов. При этом их бизнес-модель предполагает как предоставление готовых SaaS-сервисов на базе мировых ISV, так и загрузку любых образов приложений, которые собраны по технологическому процессу и на базе инструментария, предлагаемого такими компаниями. При этом такие компании сами мотивируют ISV «вкладываться» в разработку для них образов приложений. Яркий пример тому – Amazon Elastic Cloud, где провайдерами приложений являются как такие уважаемые мировые софтверные дома, как Oracle, IBM так и небольшие стартапы. Последним очень выгодно использовать подобные «облака» для разработки и тестирования собственных идей, а также с целью продвижения своих продуктов на рынке среди клиентов, которые теперь могут самостоятельно или с минимальной сторонней помощью построить для себя прототип и провести апробацию решения.

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

«Облако» в банке

В то же время подобная бизнес-модель неприменима к банковскому сообществу, где основным профилем является предоставление финансовых услуг. Для них была характерна та ветвь развития, которая привела к иной модели предоставления «облачных» сервисов – к «частным облакам», где основным потребителем «облачных» сервисов является сам банк, который делает это ради повышения гибкости и обеспечения динамики основного бизнеса, улучшения показателей использования ресурсов. Триггером инноваций и моментом зарождения основ «облачных» вычислений можно считать момент бума «доткомов» (англ. dotcom или .com) и интернет-бизнеса, что на временной шкале соответствует отметке 15-летней давности. Банки отреагировали на этот факт появлением интернет-банкинга, что резко изменило весь IT-ландшафт банковского бизнеса, и сегодня мы наблюдали переход от монолитных централизованных приложений, работающих в терминальном и пакетных режимах, к двухуровневым и трехуровневым приложениям, где появились уровни абстракции данных, бизнес-логики и пользовательских представлений.

Не менее важным был момент появления в архитектуре банков распределенных Web-серверов и таких важных элементов инфраструктуры, как выделенные системы аутентификации и авторизации, Single Sign On (SSO).

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

Именно здесь такие модули могут быть найдены чаще всего на уровнях пользовательского представления или бизнес-логики. Например, в конце отчетного периода, когда в несколько раз возрастает нагрузка на серверы отчетности банка, было бы логично развернуть дополнительные мощности именно на этот период и по его окончании освобождать их, поскольку в остальные периоды загрузка может не превышать 20%. Есть примеры российских банков, где при полностью статично установленных на серверах приложениях средняя загрузка серверов колеблется в пределах около 5%. Или, например, происходит развертывание новых приложений по региональным структурам банка. Используя технологии «частного облака» и подготовив образ и сценарий развертывания единственный раз, можно предоставлять новые прикладные функции пользователям, что называется, «по требованию».

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

Продолжая рассматривать факторы, мешающие российским банкам получить выигрыш от использования «облачных» технологий, можно упомянуть два, которые имеют между собой некоторую связь: это наш всеми уважаемый ГОСТ 34 на проектирование и внедрение информационных систем и текущие практики бухучета постановки на баланс этих самых автоматизированных систем и «законченных строительством» объектов автоматизации.

Авторы стандарта не имели представления о динамически выделяемых ресурсах, перемещении программных пакетов между узлами и системах виртуализации, поэтому вычислительный комплекс описывали как статическую структуру, состоящую из аппаратного, системного и прикладного уровней, а также периферийного оборудования. При сдаче в эксплуатацию объекта должно быть четко указано, где и какие модули работают на физическом уровне. Как будет выглядеть документация на объект, где есть понятия физических серверов, виртуальных машин, приложений, которые в любой момент времени могут быть запущены на подходящем свободном ресурсе? Логически выход напрашивается сам! Давайте проявим гибкость и определим группу серверов как единый аппаратный комплекс, а также будем воспринимать ГОСТ 34 как рекомендательный документ, а не догму! Однако далеко не все согласны с такой точкой зрения, и озвучиваются мнения об даптации ГОСТ 34 или о выпуске разъясняющих пользование этим стандартом в случае «облачных» технологий. Так что самым сложным оказалось изменить восприятие новой реальности.

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

Летим в грозу

Краеугольным же камнем в банковском сообществе является отдел безопасности, встающий на защиту интересов банка от проникновения туда «облачных технологий» и делающий это небезосновательно, поскольку даже самые активные «евангелисты клауда» признают, что в «облачных» средах возникает большое количество новых вопросов к обеспечению безопасности, а сама инфраструктура существенно усложняется. Что ж, пугаться этого не надо. Недаром все эксперты отмечают экспоненциальный рост сложности IT-систем. Для того чтобы успешно справляться с растущей сложностью, необходимо лишь использовать правильный набор инструментов. Если выстраивать инфраструктуру правильно, интегрируя средства мониторинга и управления информационными системами и сетями, системы управления аунтификацией и идентификацией, а также снижать долю ручных операций путем автоматизации процессов управления заказами, конфигурирования, активации и эксплуатации, то можно добиться гораздо большей защищенности систем, чем в обычном случае. И это не парадокс, а эффект комплексного решения вопросов!

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

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

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

Существенно помочь контролировать актуальное состояние инфраструктуры и оперативно информировать о несоответствиях с плановыми изменениями призваны агенты сбора данных о запущенных приложениях, а также системы оперативного мониторинга параметров серверов, открытых портов приложений и работы сетевых устройств. Они должны быть интегрированы с единой базой конфигураций и изменений CCMDB (Configuration and Change Management Data Base). Не имея таких средств, инфраструктура работает вслепую, и решать возникающие эксплуатационные вопросы крайне сложно. Например, как можно определить, на каком именно виртуальном сервере работает «зависшее» приложение, и где тот физический сервер, на котором происходит аномальный всплеск нагрузки на процессор, а также соотнести эти события без подобных систем?

Внутри «облачка»

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

Развитая архитектура «облачных» платформ содержит большой (но не исчерпывающий) набор компонент, изображенный на рис. 1. Минимальный набор компонент содержит портал самообслуживания запросов потенциальных пользователей «облачных» сервисов, менеджер управления «облачными» сервисами (состоящий из пяти модулей), инфраструктуру виртуализации и аппаратный комплекс, куда входят пользовательские устройства, серверы, системы хранения данных и сети. Такая архитектура соответствует обычно либо «частным облакам», где сервисами являются PaaS или IaaS-услуги для создания тестовых сред и сред разработки приложений. Эти «облака» являются логичным шагом банков на пути адаптации «облачных» платформ и позволяют им существенно уменьшить время на разработку новых IT- систем и повысить коэффициент использования ресурсов, если одни и те же ресурсы банка разделяются между различными проектами. Кроме того, такой подход позволяет банку в несколько раз уменьшить время на предоставление исполнителю среды разработки. В этой ситуации банк выигрывает еще и за счет того, что предоставляет разработчику прототип своего IT-окружения, полностью собранный с учетом IT-стандартов банка. При этом банк может быть уверен, что все новые разработки будут выполнены в соответствии с его внутренними стандартами. Если же банк планирует эксплуатировать платформу предоставления «облачных» сервисов в коммерческом режиме, то ему не обойтись как минимум без компонент безопасности, управления резервным копированием, а также углубленного мониторинга инфраструктуры с элементами корреляции событий и приоритезацией сбоев для эффективного решения задач эксплуатации и обслуживания пользователей.

Рисунок 1. Компоненты «облачной» архитектуры
Рисунок 1. Компоненты «облачной» архитектуры

Очень часто построению «облачных» систем сопутствует процесс консолидации приложений – как серверных, так и клиентских (desktop cloud). В банке этот процесс неизбежно связан с изменением инфраструктуры обеспечения безопасности (инфраструктуры управления ключами безопасности, сертификатов). Рассмотрим ситуацию, когда банк консолидирует на одном сервере пользовательские приложения, которые ранее выполнялись каждое на своем ПК (а ключ хранился, например, на USB-носителе в составе этого ПК). Попытка запуска таких приложений в терминальном режиме на одном физическом сервере столкнется с проблемой перенесения всех ключей безопасности на этот сервер. В результате потенциальный злоумышленник, получив доступ к серверу, может получить доступ ко всем ключам.

Если рассмотреть вопрос услуг типа SaaS, то здесь основной проблемой на данный момент является успешное решение вопросов интеграции приложений в инфраструктуру облака, их адаптации для последующего предоставления их функций в виде «облачных» сервисов. При этом возможно внесение существенных доработок в информационные системы для обеспечения соблюдения ими основных принципов обслуживания многих потребителей (multi tenancy) внутри единой физической инфраструктуры.

Давайте более подробно разберем сущность этого нового термина «multitenant», его смысл и влияние на архитектуру, почему он так важен в контексте «клауд архитектур», а также попытаемся его перевести.

В нашу профессиональную деятельность уже давно и прочно вошли словосочетания многозадачный (multi-tasking) и многопользовательский (multi-user). Эти понятия говорят о возможности информационных систем одновременно работать с несколькими задачами и одновременно обслуживать много пользователей. Все эти понятия появились, чтобы подчеркнуть революционный скачок в эффективности таких систем. Определение «multi tenant» является принципом программной архитектуры и характеризует новый скачок эффективности, поскольку такая архитектура определяет, что множество организаций (tenants), каждая из которых может состоять из набора пользователей, получает возможность обслуживаться на едином экземпляре программных компонент. Такая программная архитектура подразумевает, что все организации используют одни версии модулей, и с ростом нагрузки архитектура растет горизонтально – запускаются большее количество модулей исходных версий. Таким образом, выполняется еще один существенный принцип – сложность системы не растет пропорционально нагрузке и количеству пользователей. В этих архитектурах происходит виртуальное разделение данных и конфигураций различных организаций. Давайте назовем такую архитектуру «мультигостевой».

Прямой противоположностью является архитектура multi-instance, или «многоэкземплярная», когда под каждую организацию запускается своя отдельная операционная среда, то есть полный набор необходимых модулей. Они также могут отличаться по версиям для разных организаций. Здесь мы подошли к фундаментальному различию между «облачными» и виртуальными средами, потому что большинство приложений, которые были созданы до появления «облачных архитектур», могут обеспечить работу только в multi-instance архитектурах. То есть под каждого клиента вам нужно разворачивать заново весь набор модулей на отдельной виртуальной машине. Иными словами, растет количество клиентов – пропорционально увеличивается и количество виртуальных машин, конфигураций и, возможно, версий программного обеспечения. Экономия в этом случае работает только на уровне увеличения загрузки серверов путем запуска нескольких виртуальных машин. Multi tenant архитектура в этом случае позволила бы вам добавлять клиентов внутри одной операционной среды, только добавляя новые конфигурации клиентов, запуская новые модули исключительно по мере роста нагрузки. Поэтому для построения полноценных «облачных» сервисов сами приложения должны эволюционировать в направлении mutli tenant архитектур.

На пути этой эволюции соблюдение принципа multi tenant поднимает целый пласт вопросов по изолированию операционных сред потребителей и обеспечению защищенного разделяемого доступа к данным, мощным и интегрированным системам аутентификации и авторизации пользователей, единого управления политиками безопасности для всех предоставляемых ресурсов, включая сети передачи данных внутри «облачных» инфраструктур.

На передовой «облачного фронта»

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

Как мы увидели, путь к принятию «облачных» подходов в профессиональном сообществе лежит через решение новых, сложных вопросов. Несмотря на звучащие оптимистические заявления в отношении перспектив и новых открывающихся возможностей «облачных» вычислений, сама технология еще находится на пике иллюзий и ожиданий, если мы возьмем классификацию зрелости технологий по Гартнеру (см. рис. 2).

Рисунок 2. зрелости технологий
Рисунок 2. Кривая зрелости технологий

C момента зарождения технологий, которые лежат в основе «облачных» технологий, прошло около 15 лет. За это время были решены многие технологические вопросы, образующие фундамент. Но это был важный период в том смысле, что компании, двигающиеся в верном направлении развития IT-систем, сегодня демонстрируют готовность к использованию «облачных» подходов. Остальным же участникам IT-сообщества предстоит догонять лидеров для того, чтобы выйти на плато продуктивного использования этих перспективных технологий.

КАЛЕЙДОСКОП

TSYS и U.S. Bank заключили соглашение о процессинге в Европе

TSYS и U.S.Bank подписали соглашение, по условиям которого TSYS будет предоставлять услуги процессинга Elavon Financial Services Limited, 100%-ной дочерней компании U.S.Bank. В течение лета 2011 г. компания приступит к эмиссии корпоративных карт на рынке Европы.

U.S.Bank, пятый по величине коммерческий банк в США, учрежден корпорацией U.S.Bancorp. Сегодня корпорация располагает сетью из 3082 банковских отделений и 5238 банкоматов в 25 штатах, предлагая клиентам широкую линейку банковских, брокерских, страховых, инвестиционных, ипотечных продуктов, а также трастовых и платежных услуг.

U.S.Bank объявил о планах по эмиссии корпоративных карт для сотрудников европейских офисов североамериканских мультинациональных корпораций, являющихся его клиентами, через Elavon Financial Services Limited в марте текущего 2011 г.

На первом этапе проекта U.S.Bank будет акцентироваться на выпуске карт для клиентов из Великобритании, Ирландии, Франции, Германии, Испании и Италии. Банк планирует предложить держателям различные варианты расчетов по картам (в евро и фунтах стерлингов), а также позволит выбрать язык обслуживания (английский, французский, немецкий, итальянский или испанский). Карты будут соответствовать всем европейским технологическим стандартам, включая полноценное использование технологии Chip&PIN.

Как заявил Алан Гибсон (Alan Gibson), директор направления коммерческих платежей в Европе компании Elavon Financial Services Limited, «сотрудничество с таким надежным партнером, как TSYS, дает нашим клиентам дополнительные гарантии, что они получат услуги мирового класса. Заключенное соглашение свидетельствует о расширении наших давних партнерских отношений, которым уже более 20 лет. С TSYS мы уверены в способности поддерживать клиентов по всему миру».

«TSYS – одна из ведущих компаний в сфере процессинга коммерческих платежей в Европе, предоставляющая данные услуги в 17 странах, – отметил Боб Эванс (Bob Evans), управляющий директор по Европе, TSYS Int. – Решение U.S.Bank развивать работу на рынке Европы на базе платформы TS2 Commercial Card от TSYS является свидетельством серьезности сложившихся между нами отношений, а также ценности опыта, полученного нашей компанией при расширении присутствия в данном регионе».

«Ашан» собирается получить банковскую лицензию в России

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

Сейчас в РФ работает только представительство банка – ООО «БА Финанс», которое не имеет банковской лицензии и занимается консультацией посетителей магазинов «Ашан», Leroy Merlin, Decathlon. Сами кредиты выдает Кредит Европа Банк. Всего банк работает в десяти странах, в том числе во Франции, Испании, Италии, Португалии, Польше, Румынии, Украине и Китае. В ряде стран, как и в России (например, в Китае и Венгрии), у Accord также нет банковской лицензии. В некоторых странах, например в Испании, Accord работает под торговой маркой Oney. В странах, где Auchan имеет банковскую лицензию, группа через подразделение Banque Accord занимается распространением банковских продуктов, в том числе кредитных займов, страховых услуг.

Всего по итогам 2010 г. количество клиентов Accord составляло 6,4 млн. Чистая банковская прибыль Accord – 372 млн евро (рост на 2,1% по сравнению с 2009 г.).


Комментарии (0):

Добавлять комментарии могут только зарегистрированные Пользователи


Читайте в этом номере:
обновить

а вы знаете, что...

… первую в мире действующую систему дистанционного банковского обслуживания для юрлиц запустил в Великобритании в 1983 г. Bank of Scotland (для компаний, входящих в National Building Society), причем в системе для приема и отправки дистанционных распоряжений по счетам использовались тогда… телефон и телевизор?