На головну сторінку   Всі книги

Тема 7.3. Інформаційні технології в банках. Дистанційне обслуговування клієнтів

Автоматизована банківська система (АБС) - аппаратнопрограммний комплекс, який реалізовує інформаційні технології, що забезпечують діяльність банку. Основні функції банку, належні автоматизації, можна об'єднати в наступні групи:

Рутинні банківські операції - обробка документів, ведіння кредитних справ, міжбанківські розрахунки, валютно-обмінні операції і т.

д.

Накопичення даних, формування звітності, організація внутрішнього контролю

Аналітичне забезпечення функцій прийняття рішень керівництвом банку.

Початок розвитку АБС за рубежем було встановлено в 70-х роках ХХ віку. Багато які АБС, створені тоді (наприклад, MIDAS), працюють в російських і зарубіжних банках до цього дня. У Росії перші АБС з'явилися в 80-х роках. Спочатку російські АБС створювалися як облікові програми для банків, надалі їх розробники поставили перед собою задачу розвитку АБС як універсальних систем і успішно вирішили її.

На сьогоднішній день рівень розвитку АБС в Росії і на Заході приблизно однаковий, але різниця в термінах еволюції відбивається на якості опрацювання тих або інакших функцій АБС.

Програмно-технічна платформа, що Використовується АБС є основним визначальним чинником таких характеристик системи, як масштабованість, відвертість, можливість роботи в режимі реального часу (онлайн), підтримка механізмів транзакцій, захист даних і санкціонування доступу. Більш докладний опис цих характеристика АБС буде дано далі.

Основними складовими програмно-технічної платформи є:

Апаратна платформа.

Операційна система.

Система управління доступом до даних.

Враховуючи, що між апаратними платформами і операційними системами існує певна залежність, доцільно розділити їх поєднання на чотири групи:

AS/400 - операційна система OS/400 на комп'ютерах IBM AS/400;

MAINFRAME - операційні системи MVS, VSE і аналогічні на комп'ютерах IBM/370/390 і аналогічних;

UNIX - Unix-подібні операційні системи, здатні працювати на різній апаратурі;

операційні системи Windows NT, Novell NetWare і OS/2, працюючі на апаратурі Intel. Таке об'єднання пояснюється тим, що по доступних матеріалах не вдалося однозначно згрупувати представлені АБС по перерахованих в даному пункті операційних системах.

Системи управління, що Використовуються для побудови АБС доступом до даних діляться на дві категорії:

Промислова СУБД.

Файлові системи, засновані на методах доступу операційної системи, що використовується.

Саме від типу системи управління, що використовується доступом до даних багато в чому залежать такі якості АБС, як відвертість і переносимість. Крім того, тип системи управління, що використовується доступом істотним образом впливає на загальну вартість АБС.

З цієї точки зору АБС, побудовані на основі СУБД, володіють наступними перевагами:

Вони підтримують стандартну мову маніпулювання даними (SQL), забезпечуючи тим самим відвертість.

Легше переносяться з однієї апаратно-системної платформи на іншу.

Більш прості в розробці і розвитку.

У той же час АБС на основі файлових систем:

Загалом істотно дешевше, оскільки при придбанні таких АБС не потрібно оплачувати ліцензію на використання СУБД.

У ряді випадків можуть виявитися більш продуктивними в частині доступу до даних.

Не вимагають залучення фахівців з СУБД, що загалом також здешевлює проект.

Більш прості у впровадженні і супроводі.

У цей час серед розробників і користувачів АБС найбільш поширена запропонована А. Евтюшкиним (Банківські технології, №7-8, 1997) класифікація АБС по їх "технологічних поколіннях", при цьому за основу була прийнята технологічна платформа, на якої АБС будувалася.

Необхідно пояснити деякі поняття, встановлені в основу класифікації. Передусім, потрібно звернути увагу на структуру АБС.

Як правило, сучасні АБС мають модульну структуру, т. е. складаються з окремих блоків (модулів), кожний з яких дозволяє здійснювати ту або інакшу групу банківських операцій. Конфігурація (модульний склад) АБС, що використовується в конкретному банку, залежить від функціональних потреб банку, його організаційної структури,

ліцензій, що є у нього, фінансових можливостей і ряду інших чинників.

Обов'язковим елементом є базовий, основний модуль, який називається ядром АБС. Ядро АБС забезпечує виконання основних операцій над банківськими базами даних, контролює цілісність і коректність даних, відповідає за безпеку системи загалом. Робота всіх інших модулів АБС спирається на основні операції, які виготовляються в її ядрі.

Іноді, особливо в ранніх російських АБС, як ядро розглядається так званий «Операційний день банку» - модуль розрахункового обслуговування клієнтів, в рамках якого ведуться основні бази даних і формуються щоденні бухгалтерські звіти (баланс, особові рахунки, бухгалтерські журнали і пр.). Однак такий підхід, хоч і що має деякі практичні основи, не можна вважати суворо коректним.

Структура АБС тісно пов'язана з методами і технологіями програмування, вживаними при її розробці. Одним з основних питань технології АБС є організація многопользовательского доступу до даних. Як правило, в АБС здійснюється розподілений доступ до даних одночасно з декількох комп'ютерів, об'єднаних в мережу. У цьому випадку одна частина функцій виконується на комп'ютері - клієнтові, а інша - на комп'ютері - сервері, причому їх взаємодія здійснюється через деякий узгоджений протокол. Існує три основних типи технологій розподіленого доступу до даних:

Файл - сервер (FS- модель). У її рамках передбачається, що один з комп'ютерів мережі є файловим сервером і надає свої ресурси по обробці файлів іншим комп'ютерам, на ньому також розташовується сховище даних. На інших комп'ютерах є призначене для користувача програмне забезпечення, реалізуючий функції призначеного для користувача інтерфейса доступу до даних, і копія процесора бази даних (СУБД). Всякий раз, коли прикладна програма звертається до бази, процесора даних звертається до файлового сервера. У відповідь файловий сервер направляє по мережі необхідний блок даної, отримавши який, СУБД виконує над ними дії, задекларированние в прикладній програмі. Однак через технологічні нестачі FS-моделі вона може застосовуватися тільки у відносно невеликих системах. Серед недоліків потрібно назвати:

високий мережевий трафік, зумовлений необхідністю передавати велику кількість даних від сервера до додатків

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

- відсутність надійних коштів забезпечення безпеки даних, допускається захист тільки на рівні мережевої операційної системи

Клієнт - сервер. Основні відмінності цієї моделі показані на малюнку. У системі клієнт-сервер процесор бази даних розміщується на центральному сервері разом з сховищем даних. Він може обслуговувати одночасно декілька клієнтських додатків, управляючи сховищем і повертаючи запитану інформацію після обробки її локальному додатку, що запитав.

Хост - термінал. У системах цього типу комп'ютер - клієнт служить засобом введення і виведення алфавітно-цифрової і носить назву «термінал користувача». Центральний комп'ютер є місцем зберігання і обробки даних, а також здійснює перетворення запитів комп'ютерів-клієнтів і результатів їх виконання.

З точки зору функціонального наповнення можна згрупувати модулі, що є в сучасних АБС, таким чином:

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

Депозитні операції - включає в себе операції за договорами внесків фізичних осіб і депозитами юридичних осіб, в тому числі відкриття і повернення депозитів, нарахування і виплату відсотків по них.

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

Робота з цінними паперами - в цьому модулі виробляються брокерські, ділерські операції, операції по довірчому управлінню цінними паперами, ведеться депозитарний облік цінних паперів. Також проводиться переоцінка цінних паперів при зміні курсової вартості, формуються резерви під знецінення цінних паперів, проводяться аналітичні операції за оцінкою вартості портфелів цінних паперів і інш.

Міжбанківські операції - модуль забезпечує розрахунки, що проводяться банком через коррсчет в РКЦ, по прямих кореспондентських розрахунках і межфилиальние розрахунки, а також операції, пов'язані з видачею і отриманням міжбанківських кредитів, розміщенням і поверненням міжбанківських депозитів.

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

Дистанційне обслуговування клієнтів - електронне розрахункове обслуговування клієнтів - юридичних і фізичних осіб з використанням коштів зв'язку для передачі платіжних документів від клієнта в банк і різних документів і інформації - з банку клієнту (так званий КЛІЄНТ-БАНК), в тому числі з використанням пластикових карт, Інтернету-технологій, а також так званого «телефонного банкинг».

Частіше за все окремою групою виділяються модулі АНАЛІЗУ ФІНАНСОВОГО СТАНОВИЩА банку, його клієнтів і його контрагентів.

Важливе значення має те, яким чином пов'язані між собою окремі функціональні модулі (автоматизовані робочі місця або АРМи) АБС. Можна виділити наступні типи зв'язку:

Непов'язані модулі: зв'язок відсутній або здійснюється за рахунок обміну даними між модулями через файли проміжного формату.

Пов'язані за даними модулі: зв'язок здійснюється через загальні файли даних, що використовують єдиний формат і доступні різним модулям (АРМам). При цьому міра зв'язку може бути різною - від слабої, коли активна зміна даних проводиться різними АРМамі послідовно і кожний з них взаємодіє з даними в монопольному режимі, до сильної, коли обробка даних в загальній базі проводиться одночасно різними АРМамі.

Пов'язані по функціях модулі: різні АРМи використовують одні і ті ж функції, що зберігаються в загальнодоступному місці і необхідність, що викликається по мірі. Зв'язок також може бути слабим (якщо це функції низького рівня, наприклад, функції доступу до полів записів СУБД) або сильним (якщо це функції, реалізуючий бізнес-логіку, наприклад, функції нарахування відсотків, виконання проводок і т. п.).

Ще один важливий аспект АБС - це базовий елемент технології. У АБС ранніх розробок (не тільки російських і не тільки на основі персональної обчислювальної техніки) базовим елементом технології була бухгалтерська проводка. Будь-яка банківська операція представлялася як набір проводок, які співробітник банку проводив практично вручну (заповнюючи відповідні поля в екранній формі) або при мінімальній мірі автоматизації. Як правило, це було слідством розвитку АБС підходу, що домінував на перших етапах до них як переважно облікових систем, в яких договірні умови здійснення операцій з контрагентами грають підлеглу роль по відношенню до задач ведіння бухгалтерського обліку.

У нових АБС базовим елементом технології стають документ (під яким розуміється, як правило, сукупність проводок, що генеруються одним реальним паперовим або електронним документом) або операція, тобто сукупність документів, що формують закінчену банківську операцію (наприклад, видачу - супровід - повернення кредиту). У цьому відбилися зміни вимог до АБС з боку користувачів, які перестали розглядати АБС як «великий бухгалтерський калькулятор» і оцінили потенціал їх використання з метою фінансового менеджменту.

Як і в багатьох інших інформаційних технологіях, в цей час спостерігається тенденція укрупнення базового елемента технології АБС і підвищення рівня абстракції. Можливо, базовим елементом технології АБС завтрашнього дня стане клієнт - як сукупність всіх пов'язаних з ним банківських продуктів і операцій.

Повертаючись до теми класифікації АБС, потрібно сказати, що запропонований варіант класифікації не є єдино можливим і, крім того, швидкі темпи розвитку інформаційних технологій примушують постійно розширювати і цей перелік. У цей час можна виділити наступні покоління АБС:

Перше покоління: апаратна платформа - автономні персональні комп'ютери під управлінням MS-DOS; СУБД - Clipper, FoxPro, Clarion; базовий елемент технології - бухгалтерська проводка; структура АБС - автономні АРМи, не пов'язані або слабо пов'язані за даними через обмін файлами (в тому числі шляхом фізичного перенесення на гнучких дисках з комп'ютера на комп'ютер). Зараз практично не зустрічається.

Друге покоління: апаратна платформа - персональні комп'ютери під управлінням MS-DOS, працюючі в локальній мережі Novell NetWare; СУБД - Clipper, FoxPro, Clarion; базовий елемент технології - бухгалтерська проводка; структура АБС - автономні АРМи, пов'язані за даними через загальні файли, лежачі на сервері, і не пов'язані по функціях. Активно використовувалися в середині 90-х рр., особливо в невеликих регіональних банках.

Третє покоління: апаратна платформа - персональні комп'ютери під управлінням MS-DOS (MS Windows), працюючі в локальній мережі Novell NetWare (Windows NT); СУБД - власна розробка на базі менеджера записів Btrieve; базовий елемент технології - бухгалтерська проводка, рідше - документ; структура АБС - автономні АРМи, сильно пов'язані за даними через загальні структури бази даних і слабо пов'язані по функціях. Технологія,

перехідна від "файл-сервер" до "клієнт-сервер". АБС цього покоління були широко поширені в середині-кінці 90-х рр., в тому числі в ряді великих банків. Є виключно вдалі реалізації.

Четверте покоління: апаратна платформа - персональні комп'ютери під управлінням MS-DOS (MS Windows), працюючі в локальній мережі, або ж хост-комп'ютер з терміналами; СУБД - професійна реляційна (може бути постреляционная або мережева); базовий елемент технології - бухгалтерська проводка (рідше), документ, операція; структура АБС - автономні АРМи, сильно пов'язані за даними через загальні структури бази даних, в окремих випадках пов'язані по функціях через загальне ядро. Технологія "хост-термінал" або дворівнева "клієнт-сервер". Досить поширене.

П'яте покоління: апаратна платформа - персональні комп'ютери під управлінням MS Windows, MS-DOS, рідше за UNIX, в розподіленій мережі (WAN) з декількома фізичними серверами додатків (які працюють під багатозадачними многопользовательскими ОС); СУБД - професійна реляційна плюс менеджер транзакцій; базовий елемент технології - документ або операція; структура АБС - логічні АРМи, сильно пов'язані як за даними, так і по функціях в межах локальної мережі або хоста і слабо пов'язані за даними в межах розподіленої мережі. Технологія трехуровневая "клієнт-сервер" з використанням менеджерів транзакцій. Одиничні розробки.

Шосте покоління: апаратна платформа - гетерогенна мережева середа; СУБД - професійна реляційна з відкритим інтерфейсом (можливо одночасно декілька різної СУБД); базовий елемент технології - операція або документ; структура АБС - логічні АРМи, що динамічно формуються по компонентній технології, сильно пов'язані за даними і функціям в межах всієї мережі intranet. Перспективна технологія, що з'явилася недавно. Одиничні розробки.

Вимоги, що пред'являються до АБС.

Функціональна повнота і продуктивність. Вимоги до функціональності АБС, в суті, досить очевидні:

Підтримка коректного виконання всіх операцій банку відповідно до діючих інструкцій Банку Росії і правил бухгалтерського обліку.

Підтримка коректного складання всієї звітності, необхідної діючими інструкціями Банку Росії, стандартами МСФО (GAAP), іншими нормативними документами.

Підтримка правил, процедур, протоколів і форматів обміну інформацією в електронній формі, встановлених для взаємодії кредитно-фінансових установ з установами Банку Росії.

Наявність вбудованих коштів оперативного фінансового аналізу, прогнозування і планування позиції банку, а також механізмів управління фінансовими ресурсами (дилинг, фондовий ринок і т. п.) або інтерфейсів до відповідних продуктів третіх фірм.

Треба тільки мати на увазі, що банку потрібно встановлювати вимоги до функціональності АБС виходячи не з "сьогоднішнього" стану банку, а принаймні з розрахунку на той стан, який передбачається мати через два роки. Інакшими словами, необхідно спланувати або спрогнозувати набір операцій, кількість клієнтів, об'єм документообігу і інші основні характеристики банку не менш ніж на два роки уперед (а краще - на п'ять років).

Справа в тому, що процес впровадження і повного освоєння АБС займає приблизно рік. Бажано, щоб ще як мінімум рік можна було користуватися АБС, не вносячи в неї радикальних змін (за винятком звичайних модифікацій, пов'язаних із змінами нормативної бази). Якщо ж за цей період банк або різко збільшить об'єм операцій, або розширить їх номенклатуру, то систему доведеться серйозно модернізувати.

Зростання документообігу може примусити перейти на більш продуктивну апаратну платформу - а це часто виявляється не такою уже простою справою. Так, один з великих російських банків, що купив декілька років назад серйозну АБС західного походження на платформі AS/400, виявився в ситуації, коли йому не вистачає продуктивності самої старшої моделі цього сімейства, а вибрана ним АБС не переносима на інші платформи...

Зміна номенклатури операцій звичайно потрібна банку, щоб розширити клієнтську базу. Залучити нових клієнтів простіше усього пропозицією нових послуг, нових фінансових продуктів. Якщо в АБС не закладені можливості підтримки цих фінансових продуктів - банк може виявитися вимушений або докупляти нові модулі (і організовувати їх інтеграцію з АБС, що не завжди проходить безболісно), або перейти на нову АБС. У всіх цих випадках він буде нести непродуктивні фінансові втрати, яких можна уникнути, якщо більш ретельно планувати своє майбутнє.

Все більш важливою стає здатність АБС працювати в розподіленому мережевому середовищі. Тепер це все частіше не просто локальна мережа: зміни, що відбуваються в російській банківській системі об'єктивно ведуть до скорочення числа банків при одночасному зростанні їх філіальних мереж.

Більшість поширених нині АБС вирішують задачу консолідації балансу за рахунок обміну файлами в кінці операційного дня. Однак цього скоро буде недостатньо. Нинішній клієнт хоче, щоб звичні йому послуги були доступні для нього в будь-якому відділенні або філії його банку, навіть якщо ця філія знаходиться не в тому місті, в якому він відкривав собі рахунок. Щоб задовольнити потреби клієнта, АБС повинна забезпечувати розподілену обробку інформації в режимі он-лайн.

Для многофилиальних банків, що особливо мають трехуровневую структуру, дуже важливе дотримання єдності технології. Це також треба враховувати і прагнути до використання однакових АБС в філіали, відділеннях і головних конторах (що відносно легко при виборі технологій, що масштабуються ). Як мінімум, системи всіх рівнів повинні мати однакову структуру даних, однаковий інтерфейс користувача для однакових операцій і єдиний інтерфейс прикладного програмування. Деякі пропозиції, що є сьогодні на ринку, з цієї точки зору виглядає щонайменше дивно: для кожного рівня - головний офіс, філія, додатковий офіс - пропонується фактично окрема АБС, при цьому три типи АБС відносяться до різних поколінь, побудовані на різних платформах і не сумісні навіть по структурах даних! Досить очевидно, що впровадження такого "комплекту" спричинить нескінченний головний біль для управління автоматизації, а головне - серйозно утруднить розвиток банківської технології в потерпілому банку.

Швидкість роботи АБС повинна в ідеалі дещо випереджати потреби банку. У сучасному банку на одного операційного працівника доводиться в середньому до 400 операцій за 1 робочий день. Функціональна повнота має на увазі, що набір модулів АБС відповідає видам операцій, вироблюваних банком, і забезпечує повну автоматизацію діяльності банку.

Масштабованість - можливість роботи з апаратурою, що має широкий спектр продуктивності, в тому числі на різних платформах. Ця якість зумовлена наступними вимогами:

Забезпечення зростання продуктивності системи, пов'язаного з розширенням клієнтської бази банку і спектра послуг, що надаються.

Збереження раніше зроблених капітальних вкладень при переході на більш продуктивний варіант апаратної платформи.

Можливість установки АБС як в головному офісі банку, так і в самостійних філіали.

Відвертість - можливість інтеграції з іншими інформаційними системами. Ця якість зумовлена наступними вимогами:

Одночасна робота на одному і тому ж обладнанні модулів АБС і іншого програмного забезпечення, розробленого банком або третіми фірмами, в тому числі пакету Microsoft Office, прийнятого де-факто як корпоративний стандарт більшістю організацій.

Інформаційний обмін з іншими системами автоматизації, в тому числі з використанням механізмів DDE.

Настроюваність системи забезпечується в основному за рахунок внесення нової інформації в нормативно-довідкові бази даних, в яких закладені параметри, змінні в зв'язку з отриманням нових вказівок вищестоящих органів, з появою нововведень в практиці роботи самого банку. Ці параметри використовуються в роботі всіх інших модулів АБС.

Надійність і безвідмовність визначають здатність нормального функціонування АБС в умовах збоїв і відмов компонентів апаратного забезпечення системи. При будь-яких зовнішніх обставинах АБС повинна працювати, забезпечуючи цілісність і коректність інформації.

Перешкоди до нормального функціонування АБС можуть бути пов'язані з помилками персоналу, технічними проблемами (наприклад, перебої з електропостачанням, низька якість зв'язку), природним катаклізмом і т. д.

Для забезпечення безвідмовної і надійної роботи АБС застосовуються наступні методи:

Оснащення апаратурою, регулюючою стрибки напруження і що забезпечує безперебійне електропостачання,

Використання сучасних каналів зв'язку, в тому числі що дублюють.

Оснащення спеціально розробленими програмами, підтримуючими цілісність і коректність всіх взаємопов'язаних баз даних. Приклад - використання транзакцій в АБС. Періодичне створення копій всіх баз даних (backup версій), в тому числі на зовнішніх магнітних носіях.

Наявність резервного апаратного центра, що включає в себе не тільки запасний комплект техніки і лінії зв'язку, але і кошти відновлення даних.

Підтримка механізмів транзакцій забезпечує здатність системи підтримувати логічну цілісність бази даних при одночасній роботі багатьох користувачів, а також у разі збоїв і аварій.

Безпека має на увазі захищеність АБС від несанкціонованого доступу. Останнім часом безпеки інформаційних технологій банки приділяють особливу увагу. Проте кількість реально визискуваних АБС з серйозними проблемами в області безпеки в Росії досить велика. Це зумовлене в тому числі і слабою підготовкою служб безпеки більшості банків в області інформаційних технологій. Разом з тим відомо, що якщо несанкціонована операція коректно проведена в базі даних, то виявити її коштами звичайного бухгалтерського аудиту складно.

Способи забезпечення безпеки АБС можна згрупувати таким чином:

Фізичні методи оберігають від фізичного несанкціонованого доступу в приміщення, де проводиться обробка даних автоматизованої системи (наявність системи дозволу доступу і перевірки повноважень, застосування різних способів контролю доступу, сигналізації і т. п.).

Апаратні методи передбачають наявність пристроїв, що обмежують і контролюючих доступ до введення і виведення (електронні ключі, аналізатори і т. п.)

Програмні методи полягають в наявності в складі АБС запрограмованих технологій забезпечення безпеки, в тому числі використання методів криптографії і протоколювання операцій. Наприклад, на будь-якому етапі проводиться аналіз законності доступу до інформації, коректності оформлення документів, контроль за тимчасовими рамками (робочий час чи ні, проста фіксація моменту доступу в спеціальних базах даних), контроль за особливо небезпечними операціями (видалення даних, введення нових користувачів і т. д.).

Адміністративний метод має на увазі наявність спеціалізованих груп працівників, які виконують 3 функції: управління роботою локальної мережі, в тому числі введення нових користувачів ЛВС; управління роботою АБС - введення нових користувачів і визначення їх функцій, умов для виконання операцій; контроль за першими двома функціями, в тому числі шляхом аналізу протоколів (журналів), в яких фіксуються дії співробітників.

Архітектура АБС, що складається з описаних вище елементів і що задовольняє перерахованим вимогам, приведена на малюнку. Послідовність її побудови кожний банк вибирає самостійно. Розглянемо типові варіанти:

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

Інтеграція кращих спеціалізованих систем різних постачальників в єдиний комплекс, банка, що виконується силами фахівців або компанії - системного інтегратора. Цей варіант частіше за все пов'язаний з великими витратами.

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

Вибір того або інакшого варіанту залежить від фінансових можливостей банку, наявності у нього раніше придбаної АБС і цілого ряду інших чинників.

Підмурівком системи фінансового аналізу і інвестиційного портфельного аналізу повинна бути структура даних, що забезпечує крім надійного зберігання і швидкого доступу можливість отримання багатомірних зрізів і різних мір агрегирования. Багатомірність представлення інформації і побудова агрегированних показників у вигляді зрізів багатомірного куба є методологічна основа сучасного фінансового і інвестиційного портфельного аналізу. Об'єкт (портфель), що Вивчається представляється як багатомірна система, для аналізу якої необхідне формування агрегированних показників по різних зрізах цієї системи.

Автоматизовані системи, вирішальні задачі оперативної обробки транзакцій з одночасним зверненням до бази великої кількості користувачів, відносяться до типу OLTP-систем (On-Line Transaction Processing). Світова практика показує, що традиційний (реляційний) метод проектування баз даних, що використовується для систем обробки транзакцій, не відповідає задачам синтезу, аналізу, консолідації даних.

У аналітичній системі запити на зміну даних практично відсутні, але вибірка здійснюється по більшій кількості записів, ніж при використанні АБС з метою облікових функцій. Додатки, призначені для аналізу даних, звичайно означаються абревіатурою OLAP (On-Line Analytical Processing).

Існує два підходи до їх практичної реалізації.

Перший підхід передбачає побудову повністю автономних систем на базі спеціалізованих OLAP-платформ (наприклад, Oracle Express), призначених для обробки багатомірних баз даних. Це зв'язане з високою вартістю для замовника, оскільки буде необхідно в деякій області дублювання частини функцій облікової системи банку (облік операцій і ведіння складу портфеля), вирішеної на який-небудь АБС.

Альтернативний підхід полягає в побудові багатомірних структур даних на базі звичайній реляційній СУБД (акой підхід називають

ROLAP-структурою). Цей підхід не використовує всіх можливостей OLAP-технологій з точки зору аналізу. Багато які стандартні рішення в OLAP реалізовуються «вручну» в ROLAP-структурах. Але ROLAP- структури переважніше, оскільки можуть співіснувати з будь-якою реляційною СУБД, не вимагаючи від банку заміни старої АБС.

АБС російського і зарубіжного виробництва, а також практика їх використання в банках мають істотні відмінності, зумовлені історією розвитку АБС і банківської системи.

Більшість російських АБС працюють в двох- або трех-уровневой архітектурі «клієнт-сервер». Все АБС можуть працювати в різних середовищах, серед яких домінують Windows NT і різні варіанти UNIX як серверний операційні системи, але називаються і багато які інші, насамперед Novell Netware. Що стосується клієнтських робочих місць, то можна назвати такі операційні системи, як DOS, різні варіанти Windows, що досить рідко використовується Java і інш. Серед СУБД, що використовується представлений практично весь спектр систем, представлених на ринку. При цьому звертає на себе увагу той факт, що користувачі ряду АБС можуть використати на вибір декілька СУБД.

Серед російських розробників по продажу програмного забезпечення для банків (по числу інсталяцій) лідирують "R-Style Software Lab." (програма RS-Bank) і «Діасофт» (DiasoftBank 4x4, Diasoft 5NT). За ними слідують компанії «Форс» (Ва-Банк), «Кворум» (Кворум), «Про- грамбанк» (Гефест), «Інверсія» (Invobank) і ряд інших.

Зведені дані по найбільших розробниках приведені в таблиці. Приведена далі коротка характеристика АБС, створених російськими розробниками, спирається на модульний підхід до їх структури.

RS-Bank - програмний комплекс виробництва ТОВ «R-Style Software Lab.» Повна версія системи RS-Bank вийшла в світло в 1993 році.

RS-Bank позиціонується розробником як система комплексного інформаційного і функціонального забезпечення автоматизації всього спектра банківських послуг. АБС надає кошти для ведіння якісного зовнішнього (бухгалтерського) і внутрішнього (управлінського) обліку. За допомогою OLAP-технологій в програмному комплексі реалізоване аналітичне ядро, що являє собою основу функціонування і інструмент розробки аналітичних підсистем (включаючи власне підсистему аналізу консолідованої інформації).

У основу АБС RS-Bank v.5.0 встановлені наступні базові концепції: модульна організація системи (розділення на фронт-, бек-, мидл- офіси), розділення модулів на OLTP- і OLAP-додатку, принцип нарощування функціональності навколо облікового ядра і аналітичного ядра, реалізація додатків на різних програмних платформах.

DiasoftBANK (фірма-виробник ЗАТ «Компанія «Діасофт»). Компанія «Діасофт» пропонує в цей час декілька варіантів комплексної автоматизації банку на базі трьох ліній програмних продуктів, ориентирвоанних на різні технологічні платформи і що мають ряд характерні відмітних ознак.

DiasoftBank 4x4 є найбільш масовим рішенням, відрізняється відносною простотою при впровадженні і експлуатації. Базовий варіант системи працює на платформі Btrieve / Pervasive SQL. Інша версія системи - DiasoftBANK 4x4 Workflow - підтримує роботу на 5 платформах, додавши до вищезазначеним MS SQL Server, DB/2 for AS/400, Informix, Oracle.

Рішення на базі системи «Нова Афіна» здібно підтримати роботу великого многофилиального банку з кількістю операцій від 1000 в день. Потужність системи забезпечується можливостями промислової СУБД Oracle.

DiasoftBanking 5NT - рішення для дрібних і середніх банків на платформі MS SQL Server або Sybase Adaptive Server.

Будь-який з вищеперелічених програмних комплексів, взятий за основу системи автоматизації, вирішує основні задачі забезпечення діяльності комерційного банку: ведіння головної книги, розрахунково-касове обслуговування, автоматизація роботи бухгалтерії, міжбанківське і меж- філіальні розрахунки (зв'язок з РКЦ, SWIFT і т. д.), отримання фінансової і управлінської звітності, крединое і депозитне обслуговування. Загальні характеристики продуктів:

многовалютность - дозволяє працювати з довільною кількістю валют в банку (при цьому одна валюта виділяється як національна)

многофилиальность - дозволяє вести повні бази даних філіали на єдиному фізичному сервері.

багатоплановість - дозволяє банкам працювати з довільною кількістю планів рахунків.

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

«Центавр», «Гефест», «Афіна» (ТОВ «ПрограмБанк»). Компанія «ПрограмБанк» є одним з найстаріших розробників банківських систем в Росії, заснована в 1989 році групою випускників МФТИ, що розробили систему автоматизації для ряду найбільших на той момент комерційних банків. Цей програмний продукт став прародителем ИБС «Центавр», якій користуються зараз біля 400 банків. Таке рішення оптимальне для невеликих банків, тих, що мають до 20 робочих місць і до 1000 операцій втягни.

У 1993 році була почата розробка інтегрованої АБС «Афіна» (нині - ИСУБД «Нова Афіна», спільна розробка з Компанією «Діасофт»), що базується на промисловій СУБД класу Oracle і програмних платформах класу UNIX. Сьогодні «нова Афіна» використовується в підрозділах Ощадбанку РФ, Внешторгбанка РФ, МДМ - банка, а також в ряді представництв зарубіжних банків. «Нова Афіна» являє собою набір автоматизованих бізнесу-систем, працюючих на основі універсального фінансового ядра. Система реалізована в архітектурі «клієнт-сервер», основним об'єктом для роботи в системі є документ - електронна копія реального фінансового або облікового (адміністративного) документа банку, паспорт операції, свідчення про здійснення співробітником банку певної операції.

У 1996 році початки розроблятися АБС «Гефест», що займає нішу автоматизації середніх по величині капіталу кредитних установ з широкою регіональною мережею філіали і додаткових офісів, з щоденним документообігом в декілька тисяч документів. Вона направлена на рішення задач фінансового управління банком. У її основу встановлена система електронного управління документообігом з використанням СУБД Cache.

КВОРУМ (ЗАТ «АТ Кворум») почала створюватися в липні 1992 року одночасно з установою фірми-розробника. АБС є полнофункциональним рішенням, здатним забезпечити ефективну автоматизацію широкого діапазону бізнесу-процесів сучасного банку. Система КВОРУМ спирається на концепцію колективної обробки банківських операцій і засновується на принципі єдиної бази даних. Комплексний характер системи полягає в тому, що в ній не тільки реалізовані функції, пов'язані з основною діяльністю банку (операційне обслуговування, кредитування і т. д.), але і підсистеми, що забезпечують автоматизацію внутрішньогосподарської діяльності банку (облік кадрів, зарплати, основних коштів і інш.). Усього в склад КВОРУМ входять більше за 40 програмних модулів.

Починаючи з версії 6.0, в рамках АБС КВОРУМ підтримуються дві лінії програмних продуктів. Перша в якості СУБД використовує

Btrieve Record Manager, друга працює на платформі Oracle Server. Обидві лінії використовують одні і ті ж інтерфейси користувача. Бізнес- логіка також є єдиною з алгоритмічної точки зору, розрізнюючись способом реалізації (в додатках, орієнтованих на Oracle, бізнес- логіка реалізована у вигляді процедур, що зберігаються на мові PL/SQL).

З точки зору програмно-технічної платформи, зарубіжні банки орієнтовані на великі комп'ютерні системи. Незважаючи на те, що найбільше поширення в світі отримали автоматизовані банківські системи на платформі AS/400, в цей час більшість банків вважають за краще придбавати АБС на так званих відкритих платформах, насамперед на платформах UNIX.

Біля половини західних банків віддали перевагу АБС на основі промисловій СУБД. У той же час 75% всіх (по номенклатурі, а не по кількості) АБС на платформі UNIX побудовано на базі саме промисловій СУБД.

З точки зору західних банків система управління доступом до даних сама по собі не є визначальним чинником при виборі АБС. Тенденція використання для розробки АБС промислової СУБД зумовлена не стільки вимогами західних користувачів АБС, скільки перевагами розробників, оскільки це зменшує вартість і час розробки і подальшого супроводу і розвитку систем.

Функціональні характеристики західних АБС також мають істотні відмінності від російських аналогів. У західних АБС, як правило, відсутні функції автоматизації внутрішньогосподарської діяльності банку. Це пояснюється чим склався зарубіжною практикою, коли АБС автоматизує тільки бізнес-функції, а для автоматизації внутрішньогосподарської діяльності використовуються спеціалізовані системи типу R/3 фірми SAP або PRMS фірми Acacia Technologies. По тих же причинах в двох представлених АБС (Finance KIT і Trading Assistant) відсутня підсистема «Головна книга», яка може бути побудована на основі, наприклад, Oracle Financials.

Необхідно також звернути увагу, що оцінки функціональної повноти АБС погано коррелируют з маркетинговими оцінками. Наприклад, вищі оцінки, що отримали за функціональну повноту АБС Citadel і Musketeer за маркетинговими даними займають останні місця. Можна передбачити, що це викликане тим, що до того часу, коли ці АБС почали продаватися (1996 і 1995 р. відповідно), черговий етап формування і насичення ринку АБС вже завершився.

Далі розглянемо деякі характеристики найбільш відомих на зарубіжному ринку АБС.

Midas DBA, Equation DBA (Midas-Kapiti International, UK)

Ці АБС є світовими лідерами по кількості користувачів і кількості діючих установок. Вони добре відомі і на ринку країн СНД (більше за 20 впроваджень). Загалом системи себе зарекомендували як досить «жорсткі», що важко настроюються на особливості місцевого законодавства і нормативної бази. Пояснюється це тим, що з розглянутих це самі старі (в значенні що використовуються при розробці і програмуванні підходів, методів і інструментальних засобів) системи - їх комерційний продаж почався в 1975 (Equation) і 1977 (Midas) м. Системи працюють на платформі IBM AS/400.

Bankmaster (Kindle Banking Systems Ltd., Ireland)

Bankmaster займає третю позицію по числу користувачів серед всіх розглянутих систем і першу позицію серед систем на платформі UNIX. Система орієнтована на невеликі і середні банки. Основними ринками збуту системи є Великобританія (біля 25%), Африка (біля 15%), Південно-Східна Азія (20%), Ближній Схід (15%) і Північна Америка (до 7%).

Перша комерційна система була розроблена в 1980 р. для апаратно-системної платформи ICL. У 1987 р. було виконане перенесення системи на платформу UNIX, а в 1996 р.- на платформу Windows NT. Як інформаційна основа АБС використовуються методи доступу операційної системи, однак, в 1994 р. була випущена версія АБС (BANKMASTER/RS), в якій для управління даними застосовується промислова СУБД Informix.

Bankmaster - це універсальна банківська система, однак істотна частка функціональних підсистем підтримується за рахунок додаткових продуктів виробника або третіх фірм:

Контроль позицій підтримується системою City Dealer від MKI.

Документарні операції - системою IBSnet.

Офіційна звітність - системою Abacus.

Вивіряння підтверджень - системою CMS.

Вивіряння рахунків лоро і ностро - системою Soar.

Електронний банкинг - системою Fontis від Credo.

Роздрібні операції зосереджені в окремому продукті BRANCHPOWER, призначеному для установки в філіали і відділеннях банку. Інтеграція відділень (філіали) з центральним офісом здійснюється по мережах АТМ або Х.25. Допускається як автономна робота відділень (філіали), так і спільна робота в режимі клієнт-сервер з використанням інтерфейсного продукту Transaction Processing Gateway.

Microbanker (Citicorp IT Industries Ltd. (Citil), India)

Прообразом АБС Microbanker стала розроблена в Citibank система Cosmos, яка була перероблена і перенесена на платформу UNIX. Система орієнтована на невеликі і середні банки. Основними ринками збуту системи є континентальна Європа, Африка, Південно-Східна Азія і Ближній Схід. Найближчим конкурентом Microbanker є АБС Bankmaster, хоч є і виключення - в 1996 р. Rabobank, що є користувачем систем Midas і Atlas, ухвалив рішення встановлювати АБС Microbanker у всі свої нові підрозділи.

АБС працює на широкому спектрі UNIX-платформ, підтримує алфавітно-цифровий інтерфейс користувача і використовує методи доступу файлової системи для організації інформаційної бази. Анонсована робота АБС на платформах Novell Netware і Windows NT, однак реально працюючих в промисловому режимі установок такого роду немає.

Microbanker - це бек-офісна многовалютная многофилиальная система з обмеженою підтримкою роздрібних операцій. Microbanker підтримує:

Головну книгу.

Оновлення залишків в режимі реального часу.

Валютний дилинг.

Міжбанківський дилинг.

Кредити.

Документарні операції.

Торгівлю цінними паперами.

Крім того, доступний ряд додаткових продуктів того ж виробника, що розширюють функціональні можливості АБС:

Система MoneyMaker автоматизує фронт-офіс для міжбанківських операцій і покриває валютний і міжбанківський дилинг, опції прибутковості, аналіз прибутків і збитків, управління позицією, обробку лімітів і грошових потоків; планується підтримка деривативов. Є інтерфейси до систем моделювання і до Reuters 2000.

Система Customer Access Systems підтримує електронний банкинг.

Система Finware автоматизує бек-офіс роздрібних операцій і включає:

Головну книгу.

Кредити.

Іпотеку.

Депозити.

Поточні і ощадні рахунки.

Безготівкові розрахунки і взаємозаліки.

Система забезпечує онлайновие зв'язку між всіма підрозділами банку, підтримує автоматичні касові апарати (теллери) і стандарти ISO для доступу до інших периферійних пристроїв. У цей час CITIL пропонує комплекс з АБС Microbanker і Finware як інтегроване рішення під торгової мазкої Unified Banking Solution.

Незважаючи на відносно високі маркетингові показники систем IBS-90 і Abraxys, навряд чи варто розглядати їх як серйозних кандидатів на впровадження в російських банках. По-перше, вони володіють недостатньою функціональністю. По-друге, фірма-виробник не має задовільної стратегії по розвитку і підтримці продукту. Функціональний розвиток АБС Abraxys (розвиток IBS-90 припинений, хоч підтримка ведеться) здійснюється за принципом локальних доробок для окремих користувачів системи, які проводяться за додатковими контрактами. Потім найбільш вдалі рішення включаються в нову версію системи. Характерним прикладом незадовільності такої стратегії є факт, що у восьмій версії системи, яка планувалася до випуску в липні 1998 р., відсутня підтримка евро.

АБС IBIS була розроблена на початку 1980 р. в лондонському Італійському Міжнародному банку (Italian International Bank). Виробники затверджують, що система була розроблена «з нуля» для платформи IBM System/38, і в цьому укладається її перевага перед системами Midas і Equation, які були розроблені для цієї ж платформи, але ще в середині 1970 р. У той же час деякі конкуруючі виробники висловлюють думку, що IBIS - це усього лише результат перенесення з платформи IBM System/3 внутрикорпоративной розробки 1970 р.

Основними ринками збуту системи є регіони ЮгоВосточной Азії, Східної і континентальної Європи і, в меншій мірі, США. Звичайно користувачі розглядають IBIS як більш нову і менш ризиковану альтернативу системам Midas і Equation.

До 1992 р. система була перенесена на платформу IBM AS/400 і стала розповсюджуватися під мазкої IBIS/AS.

Функціональний розвиток системи здійснювався в формі проектів для окремих банків.

Для лондонського Svenska Handelsbanken була виконана робота по перенесенню всіх функцій обробки фінансових повідомлень в окремий модуль. У результаті з'явилася Система обробки повідомлень (MPS), що обробляє більшість платежів в підсистемах обслуговування приватних осіб і корпоративних клієнтів і дилинга, обробки повідомлень і підтверджень, включаючи он-лайновие зв'язку з корпоративними клієнтами і SWIFT.

Для Banco Espirito Santo (Лондон) був доданий інтерфейс до модулів комерційних і синдицированних кредитів; для Ceskoslovenska Obchodni Banka розроблений фронт-офіс підсистеми роздрібних операцій; з BNE Swedbank (Люксембург) був узгоджений проект «Управління фондами»; елементи ринку капіталів були розроблені для Bank of America. Був також виконаний великий проект по депозитах приватних осіб для Union Bank of Finland.

З точки зору функціональності, АБС IBIS/AS володіла тими ж достоїнствами, що і її конкуренти на платформі AS/400. Разом з тим вона має і аналогічні недоліки - при розробці АБС використовувалися застарілі інформаційні технології, система погано структурована, важка в підтримці і супроводі. За результатами обмеженого опиту, проведеного в 1992 р., були отримані наступні результати:

12 користувачів оцінили підсистеми «Головна книга», «Валютний дилинг», «Міжбанківський дилинг» і кредитні модулі як «задовільні» (хоч один користувач оцінив модуль «Валютний дилинг» як «незадовільний»);

половина користувачів, що використовують модуль «Фьючерси», оцінили його як «незадовільний»;

модуль «Угоди про форвардну операцію» 57% користувачів оцінили як «прийнятний»; 43% - як «незадовільний»;

модуль «Свопи» 20% користувачів оцінили як «прийнятний», 80% - як «незадовільний»;

модуль «Офіційна звітність» 75% користувачів оцінили як «прийнятний»; 25% - як «незадовільний»;

кошти генерації звітів 11% користувачів оцінили як «хороші»; 67% - як «прийнятні»; 22% - як «незадовільні»;

половина користувачів заявили, що вони володіють системою, яка найкращим образом відповідає їх потребам; три користувачі утруднилися дати таку оцінку; двоє користувачів заявили, що не вважають IBIS кращим вибором, і двоє - що проект по впровадженню АБС завершився незадовільно. Жоден з користувачів не оцінив систему як «відмінну»;

в той же час, з точки зору якості і оперативності обслуговування і підтримки, АБС IBIS виглядала краще за своїх конкурентів - 22% користувачів оцінили сервіс як «відмінний»; 56% - як «хороший» і 22% - як «адекватний».

Подальший розвиток АБС проходив як в частині поліпшення експлуатаційних характеристик, так і в частині вдосконалення функціональної частини. Система була повністю перепрограммирована із застосуванням самих сучасних інструментів і технологій. Для участі в цьому проекті були запрошені фахівці з IBM.

У технологічному напрямі були зроблені наступні удосконалення:

замінена система генерації звітів;

в систему роздрібних операцій додані: підтримка прямого дебетування; підтримка регулярних платежів на адресу трохи одержувачів; підтримка комісій; інтерактивний доступ до SWIFT термінала Alliance;

впроваджений новий дилинговий модуль, який повністю замінив стару систему введення операцій. Новий модуль є доповненням до існуючих модулів підтримки бек-офісу дилинга і розширює їх можливості в частині: введення повідомлень про операції; поліпшеної обробки кредитів з можливістю перегляду умов, інтерфейса з Reuters Dealing 2000, підтримки сенсорних екранів (touch-screens);

додані функції електронного банкинга, що дозволяють приватним і корпоративним клієнтам видалено, в тому числі і через Інтернет: відстежувати зміни балансів і рахунків; ініціювати регулярні платежі; перенести кошти з рахунку на рахунок; ініціювати транзакції; отримувати доступ до оперативної інформації;

додана система управління ризиками, підтримуюча стандартні моделі і методи, включаючи Value at Risk і JP Morgan's Riskmetrics. Крім того, систему можна використати для аналізу «Що, якщо».

Планується до впровадження новий модуль «Репо», який замінить модуль, що є, орієнтований в основному на облік.

Система Finance KIT задумувалася як фронтальна частина бек-офісу казначейства. Вона була розроблена на початку 1990 р. і набула поширення в основному в секторі корпоративного казначейства, хоч було і декілька користувачів-банків. Зокрема, одним з перших користувачів АБС був ABB Financial Services - банківський підрозділ міжнародної корпорації ABB Broun Group.

Спочатку як платформа АБС були вибрані персональні комп'ютери з операційною системою Windows і «настільною» СУБД Access фірми Microsoft. Однак ця платформа не змогла забезпечити необхідній продуктивності, і до 1994 р. АБС була переписана для платформи UNIX і СУБД Sybase. У цей час АБС доступна на платформах Sun Solaris і HP-UX. Перенесення на інші платформи або іншу СУБД не планується; версія для Windows більше не продається, але додана підтримка клієнтських робочих місць для Windows 95 і Windows NT.

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

Незважаючи на те що спочатку Finance KIT задумувався як інструмент корпоративного казначейства, поступово були додані функції підтримки банківського бізнесу. У цьому значенні система призначалася для підтримки повного циклу обробки банківської транзакції - від введення операції до остаточного розрахунку.

Як фронт-офіс АБС взаємодіє з продукцією третіх фірм, включаючи дилинговие системи, системи телефонних торгів і інструменти аналізу і ціноутворення - JP Morgan's Riskmetrics, електронні таблиці, пакети бухгалтерського обліку, ціноутворення валютних опціонів і форвардних операцій, моделювання «Що якщо» і ціноутворення в операціях з нульовим купоном.

АБС охоплює валютний дилинг, міжбанківський дилинг, бонди, довгострокові зобов'язання, операції репо, процентні свопи, фьючерси і опціони. За допомогою вбудованого Інструментального редактора, Редактора маршрутів транзакцій і Редактора правил можна створювати фінансові інструменти і настроювати пов'язані з ними потоки даних. Редактори працюють зі стандартними компонентами і правилами. За допомогою Редактора кредитних ризиків можна встановлювати ліміти, параметри неттинга і групові правила. Ліміти можуть встановлюватися для окремих транзакцій або для портфелів і визначатися інструментом, протилежною стороною або трейдером. Всі ліміти відстежуються в реальному часі. У версії 4.0 додана повна підтримка управління ризиками.

На рівні бек-офісу Finance KIT підтримує розрахунки, кліринг і платежі. Оновлення всіх позицій виготовляється в режимі реального часу. АБС має інтерфейси до систем офіційної звітності, узгодження і вивіряння, а також до терміналів SWIFT. АБС не має власної підсистеми «Головна книга», і повинна бути зв'язана з відповідним функционалом стороннього виробника.

Виробник позиціонує Finance KIT як систему комплексної автоматизації фронт- і бек-офісу для банків з числом ділерів до 50. Це визначається не стільки технічними можливостями системи (на тестових випробуваннях АБС змогла обробити 3000 операцій в зміну, що приблизно в три рази перевищує максимальний досягнутий рівень самого великого користувача), скільки думкою виробника, що повністю інтегроване рішення скрутно реалізувати у великих структурах, в яких процес прийняття рішень може бути тривалим і що погано формалізується.

Перша версія системи Bancs (Financial Network Services PTY Ltd., Australia) була розроблена в кінці 70-х рр. підрозділом обробки даних State Building Society для автоматизації бек-офісу роздрібного сектора. Система працювала на комп'ютерах NCR9800 під управлінням операційної системи VRX. У 1982 р. для здійснення підтримки продукту, його розвитку і поширення на комерційній основі, була організована дочірня фірма Financial Network Services, куди увійшли розробники системи. Зараз продукт відомий під двома торговими марками FNS і Bancs, в залежності від платформи, що використовується. Система працює на широкому колі апаратних і системних коштів, включаючи мейнфрейми IBM, DEC VAX і різні Unix-системи. Особливістю роботи в розподілених середовищах є як можливість взаємодії з центральною базою в оперативному режимі, так і робота в автономному режимі у разі виникнення проблем з комунікаціями.

Спочатку система призначалася для автоматизації роздрібних операцій малих і середніх об'ємів. Вона охоплює депозити, кредити, підтримує автоматичні касові апарати і торгові термінали. Система не має «Головної книги», але має інтерфейси до Finance One, Oracle Financials і Peoplesoft, які реалізовують цю функцію. Документарні операції реалізовуються системою Intrafins. У 1995 р. була додана підтримка множинних лімітів, управління портфелями і проектами, автоматизація взаємозаліків, моделювання продажу.

У секторі казначейства були реалізовані функції валютного і міжбанківського дилинга, торгівлі дорогоцінними металами і цінними паперами і корпоративні кредити.

Перша версія АБС Platon (IMS Business System Corp., USA) була розроблена для двох корейських банків, що знаходяться в Нью-Йорку в 1985 р. АБС написана на 4GL Progress і працює на широкому колі Unix-платформ. У 1996 р. була випущена 32-розрядна версія для платформи Windows NT, але реального продажу поки немає. Є інтерфейси до СУБД ORACLE, DB2 і DB2/400.

Platon охоплює основні операції валютного і міжбанківського дилинга, комерційні і споживчі кредити, іпотеку, прийом і випуск акредитивів, роботу з рахунками ностро. АБС має кошти обробки і передачі основних фінансових повідомлень через SWIFT, CHIPS, FEDWIRE і телекс (через відповідні інтерфейси).

Оскільки Platon має обмежені можливості в частині казначейства, був розроблений інтерфейс до системи валютного дилинга і казначейства фірми Financial Software Systems (FSS), яка охоплює процеси фронт- і бек-офісу.

Спочатку Opics (The Frustum Group, USA) задумувався як бек-офісна система казначейства, однак невдовзі розробники полічили необхідним додати і функції автоматизації фронту-офісу.

У 1993 р. була підготовлена перша комерційна версія АБС, яка була впроваджена у відділенні Barclays Bank в Майамі. Загалом ранні версії Opics виглядали швидше як системи рівня підрозділу, не замінюючи існуючі бек-офісні системи банку, а доповнюючи їх. Невдовзі була додана підтримка фьючерсов, біржових опціонів, угод про майбутню процентну ставку і валютного свопу. Система мала кошти безпеки, відновлення і рестарту і підтримувала многофилиальную організацію.

У 1995 р. були додані підтримка репо і звичайних акцій. На рівні фронту-офісу з'явилися можливість введення операцій і моделювання прибутків і збитків «Що, якщо». Крім того, був забезпечений онлайновий інтерфейс з Microsoft Office за допомогою механізмів DDE. У той же час АБС не підтримувала роздрібних операцій, синдицированних кредитів і документарних операцій.

Система працювала на безлічі ПК-орієнтованих платформ (Novell, Windows 95, Windows NT, OS/2 і Unix). Перші версії Opics використали СУБД Sybase, але потім були додані кошти роботи з будь-якою СУБД, підтримуючою стандарт ODBC.

До 1997 р. АБС була допрацьована до рівня «універсального рішення» для банків, потребуючих підтримки як казначейських, так і роздрібних операцій. Незважаючи на те що в ряді функцій (операції з дорогоцінними металами, репо, фьючерси, опціони, угоди про форвардну ставку) Opics має переваги навіть перед такими загальновизнаними лідерами систем банківської автоматизації, як Midas і Equation, роздрібний сектор має слабу функціональність і не здатний обробляти великі об'єми операцій.

Ця АБС є лідером по кількості нових банків-користувачів. У той же час потрібно відмітити, що 10% банків її, що купили систему не використовують. Остання обставина свідчить про наявність проблем, що виявляються на стадії експлуатації системи. На російському ринку система просувається фірмою MKI.

Перша версія АБС Olympic (ERI Bancaire SA, Switzerland) з'явилася в 1989 р. на платформі AS/400 як результат нової розробки, орієнтованій на роботу з приватними особами. Першими ринками збуту АБС були Швейцарія і Люксембург, де Olympic конкурувала в основному з місцевими розробками, однак невдовзі вона була функціонально розширена і стала конкурентом таких традиційно сильних в казначейському секторі систем, як Midas, IBIS/AS і Globus. Одним з великих користувачів системи (700 автоматизованих робочих місць) стала швейцарсько-американська Discount Bank amp; Trust Company.

Olympic розроблена для підтримки роботи фронт- і бек-офісу - від прийому клієнтських розпоряджень, включаючи електронний банкинг, до остаточних розрахунків і повідомлень. АБС підтримує фронт-офіс портфельних менеджерів і ділерів, валютного дилинг, міжбанківського дилинг, цінні папери, свопи, фьючерси, опціони, додані в 1995 р. спільно з кредитним модулем, реєстрацію і облік роздрібних операцій, документарні операції (в основному, ті функції цих підсистем, які потрібно для виконання щоденних операцій по приватних банківських послугах). Крім того, є інтерфейси до SWIFT і основним кліринговим системам. З точки зору виробника Olympic - клієнт-орієнтована АБС з оновленням позицій в реальному часі.

Хоч дві третини банків-користувачів використовують АБС саме для обслуговування приватних осіб, інші використовують Olympic для підтримки всіх напрямів бізнесу. BPER (Люксембург), наприклад, крім усього іншого використовує систему для обслуговування більше за 100 пайових інвестиційних фондів. Banque de Luxemburg використовує Olympic для надання роздрібних послуг, включаючи депозити приватних осіб, і інвестиційної діяльності, розташовуючи приблизно 500 робочих місць, підключених до одного комп'ютера AS/400.

Типовий проект по впровадженню Olympic займає від 6 до 9 місяців. Приблизно половину цього часу займає настройка. Система має центральну модель даних і біля 200 призначених для користувача таблиць, що настроюються, які описують атрибути продукту, включаючи авторизацію, процеси, тарифи, правила обліку і звіти.

У 1995 р. початі роботи по перенесенню АБС на платформу Windows NT. Система розробляється на мові З++ з використанням объектноориентированной технології і концепції сховищ даних.

Безумовний лідер справжнього огляду - краща функціональність і друге місце по кількості продажу. У той же час не можна не відмітити, що як роздрібна система Olympic не дуже підходить для обробки великих об'ємів операцій валютного і міжбанківського дилинга, хоч є прецеденти, коли йому були віддані переваги перед Midas і Globus.

Істотною обставиною, що обмежує можливість застосування АБС Olympic в російських банках, є відсутність фірми, що просуває її на місцевому ринку. Для впровадження і подальшої експлуатації цієї АБС банку зажадається або організувати спеціалізовану дочірню фірму, яка зробила б локалізацію АБС і надалі здійснювала б її супровід, або самостійно виконати весь об'єм робіт по локалізації і супроводу, як, наприклад, поступив Конверсбанк при переході до АБС Samic.

АБС Symbols (System Access Pte Ltd., Singapore) сингапурской фірми System Access є однією з самих нових пропозицій на ринку банківських систем. Уперше система була запропонована в 1989 р., і її першим користувачем став Credit Suisse First Boston Bank в Сингапуре. Перша версія АБС складалася з облікового ядра і основних функціональних модулів казначейства. Виробник проводив агресивну маркетингову політику (від якої не відмовився і зараз), маючи намір «встановити Symbols у всіх головних фінансових центрах до кінця 1993 р.». Перший значний успіх за межами Південно-Східної Азії прийшов в 1991 р.- був підписаний контракт на 1,73 млн. долл. з Південноафриканським Standard Merchant Bank. У той час цей був найбільший користувач Symbols, що має 250 робочих місць, оснащених терміналами Olivetty, підключеними до серверів Pyramid.

Основною причиною, по якої Standard Merchant Bank вибрав Symbols, була прийнята в банці орієнтація на продукцію ORACLE. Аналогічна стратегія застосовувалася і в лондонському Standard Bank (по відношенню до якому Standard Merchant Bank є дочірнім). Standard Bank також оцінював Symbols, коли підбирав систему на базі ORACLE, але зрештою віддав перевагу АБС Globus фірми Temenos, в основному через невпевненість, що виробник АБС Symbols зможе його ефективно супроводити в даному регіоні, хоч Standard Merchant Bank пропонував надавати необхідну допомогу в питаннях супроводу АБС. Така СУБД- орієнтована стратегія стає все більш популярною, особливо при необхідності консолідувати дані з різних джерел в одному сховищі. ORACLE є очевидним вибором для цього. Одночасно багато які банки в Південно-Східній Азії, Східній Європі хотіли б мати систему, що базується на нових технологіях. System Access старається використати в своїй маркетинговій політиці обидва цих факту.

Ряд контрактів на постачання Symbols були ініційовані фірмою ORACLE, наприклад контракт на 2,5 млн. долл. з SKB Banka в Словенії в 1995 р. У міру того як ORACLE концентрував свою увагу на вертикальних ринках, більш великі банки ставали потенційними клієнтами System Access. У міру того як System Access все більш спиралася на технології ORACLE, підтримка з боку виробника СУБД ставала більш відчутною. Іншим чинником, що зближує ORACLE і System Access, є спроба ORACLE забезпечити банківську функціональність в «Головній книзі» Oracle Financials. У результаті для Symbols і Oracle Financials були розроблені взаємні інтерфейси, а System Access отримала статус партнера. Проте рівень підтримки зі сторони ORACLE залишається сильно залежним від конкретної країни: в деяких країнах вона робить тільки маркетингові послуги, в інших - бере участь в проектах по впровадженню.

Основна діяльність System Access за межами Південно-Східного регіону здійснюється через дистриб'юторів. Найбільш продуктивною на сьогоднішній день є співпраця з московською компанією ФОРС. У 1995 р. ФОРС уклав контракти на постачання Symbols в банки «Російський Кредит» і «Зеніт». ФОРС виконав адаптацію АБС до специфічних російських умов; локалізована версія розповсюджується під мазкої Symbols-R.

Значною подією є також підписаний на початку 1998 р. контракт з банком «Петровський» в Санкт-Петербурге. Цей контракт став частиною дворічного російського проекту Financial Institutions Development Program, на який Міжнародний банк реконструкції і розвитку виділив 9 млн. долл. ФОРС буде відповідати за впровадження Symbols. Система буде підтримувати позики, цінні папери, валютний дилинг, міжбанківські позики, внутрирегиональние і міжнародні платежі, управління активами і пасивами на мережі філіали і головного офісу. Тендер по вибору АБС для банку «Петровський» проводився протягом двох років і його результат був названий керівником європейського відділення System Access «дивним».

System Access позиціонує АБС Symbols як рішення для середніх об'ємів операцій - мінімальна установка підтримує 12 користувачів. Наявність проблем в інструментальній частині і в механізмах доступу до даних виробник компенсує можливістю придбання АБС разом з початковими кодами системи, покладаючи тим самим відповідальність за виправлення помилок і подальший розвиток системи на користувача. Характерними прикладами такого підходу є банки «Російський кредит» і Staal Bankiers (Нідерланди).

Незважаючи на зростання числа банків-користувачів, не все відбувається гладко. Впровадження Symbols буває важким, аж до відмови від використання цього продукту.

Як відмічалося раніше, Symbols цілком базується на ORACLE. Він написаний в середовищі розробки ORACLE і використовує генератор звітів ORACLE для того, щоб користувачі могли створювати свої специфічні звіти і запити до бази даних. Система може працювати на будь-якій платформі, яку підтримує ця СУБД - іншими словами, на всіх платформах, відмінних від AS/400. Переважно система орієнтована на Unix платформи, але була зроблена версія для Next і - в 1997 р.- для Windows NT.

АБС побудована за модульним принципом. До першої версії були додані позики, документарні операції і депозити приватних осіб. Графічний інтерфейс користувача планувалося реалізувати в середині 1994 р., однак він з'явився тільки в 1996 р., коли з'явилися відповідні можливості середи розробки ORACLE.

Також була заримована підтримка роздрібних операцій. Вона планувалася на кінець 1993 р., але перша фаза була реалізована в середині 1994 р. Сектор роздрібних банківських послуг зараз є головною областю, на якої сфокусировано увагу виробника. Перший пілотний проект Symbols, що обробляє великі об'єми роздрібних операцій, був впроваджений у другому півріччі 1996 р. в Mauritius Commercial Bank і International Exchange Bank на Філіппінах. Зараз Symbols використовується для підтримки мережі з приблизно 200 філіали.

System Access вважає, що сектор роздрібних банківських послуг більше за доходен, ніж корпоративний. Така позиція допомагає залучити інтерес потенційних партнерів, таких як ORACLE і постачальники обчислювальної техніки. Виробник продовжує розвивати цей напрям, додаючи інтерфейси до автоматичних кас, систем обслуговування пластикових карт і пр. Було також заявлено про завершення в першому півріччі 1997 р. проекту «Кибер-банкинг», що дає можливість отримання роздрібних банківських послуг через Інтернет. Однак на початку 1998 р. цей проект знаходився в стані невизначеності в зв'язку із заявою виробника, що Symbols не буде мати власних коштів Інтернет-банкинга, а буде взаємодіяти з системами, що пропонуються третіми фірмами.

Інша розробка, що планується, яка так і не реалізовувалася - «ділерська кімната». Передбачається, що проект буде завершений до середини 1996 р. і буде включати в себе аналітику, введення операцій, обробку лімітів і т. д. Розглядався також проект створення сховища даних, яке могло б взаємодіяти як з Symbols, так і з іншими АБС, надаючи кошти генерації консолідованої звітності. Одним з коштів посилення функції генерації звітності була вибрана система пошуку даних ORACLE OLAP Express Analiser, до якої був розроблений інтерфейс з Symbols.

У подальших планах виробника - додавання до системи засобу інтегрованого управління потоками даних з використанням ORACLE InterOffice.

Офіційною датою появи системи Globus (Temenos Systems SA, Switzerland) на ринку інтегрованих банківських систем вважається 1988 р. Однак Globus виник не на пустому місці. Прообразом АБС була корпоративна розробка Citibank, виконана ще в 1977 р. (АБС Cosmos). Згодом система переписувалася на замовлення Lloyds Bank. Перша версія Globus працювала під управлінням операційної системи Pick на комп'ютерах Рг^є. З технічної точки зору Pick завжди виглядав дуже привабливо, особливо в частині функціональності і дружественности призначеного для користувача інтерфейса. Проте в банківському середовищі Pick поширення не отримав. Тому в 1989 р. було виконане перенесення АБС Globus на платформу Unix, і тим самим істотно розширився спектр обладнання, на якому ця АБС може працювати. Потрібно відмітити, що всі «метаморфози» АБС здійснювалися під керівництвом і за безпосередньою участю тих же фахівців, які починали розробляти АБС ще в Citibank.

GLOBUS був розроблений із застосуванням СУБД Universe фірми VMark Software, що спрощувало перенесення АБС з однієї платформи на іншу.

До 1992 р. Globus мав 25 банків-користувачів. Примітним є контракт з лондонським Standard Bank, підписаний в 1993 р. Інформаційні технології Standard Bank орієнтовані на ORACLE-технології, і з цієї точки зору використання АБС на базі СУБД Universe не є ідеальним рішенням. Ключовим аргументом на користь такого вибору була відвертість Universe, що дозволила без ускладнень організувати обмін даними між АБС Globus і ORACLE-додатками.

Функціональний розвиток АБС GLOBUS здійснюється постійно шляхом включення в основний продукт окремих розробок, що виконуються для конкретних замовників. Наприклад, модуль акредитивів був доданий в 1992 р. з ініціативи Bank Handlowy (Люксембург). У 1995 р. пішли модулі синдицированних кредитів і угоди про форвардну операцію. У 1994 р. Temenos (виробник АБС GLOBUS) купив систему Brokers' Wonder, що автоматизує роботу з фьючерсами і опціонами. Система була призначена для настільних комп'ютерів і мала вісім користувачів, серед яких ABN-Amro і Bank Julius Baer (Швейцарія). Спочатку до цієї системи був розроблений інтерфейс з Globus, а в 1995 р. система була інкорпорована в Globus як стандартний модуль.

Модуль Global Information Server (GIS) був випробуваний в лондонському Standard Bank. Цей компонент надає користувачам доступ до зовнішніх джерел даних, а також служить для генерації звітів з бази Globus за допомогою SQL-запитів і зв'язку їх з такими додатками, як електронні таблиці і текстові процесори. Аналогічно були розроблені інтерфейси між АБС Globus і офісним пакетом Uniplex, що включає електронні таблиці, діловий календар, електронну пошту і графіку.

У версії G7, що вийшла в середині 1996 р., з'явилися модулі процентного свопу, обробки прострочених кредитних платежів і керуючої інформації. У випущеній невдовзі версії G7.1 був доданий модуль обробки зображень і підтримка інтерфейса DDE для зв'язку з додатками Microsoft.

Розглядалися перспективи перенесення АБС з платформи Universe на платформи СУБД ORACLE і Sybase. Однак згодом від цих планів відмовилися в основному через те, що VMark Software протягом останніх років істотно переробила СУБД в частини інтеграції з іншими базами даних і механізмів обробки транзакцій.

Велику увагу виробник приділяє питанням розвитку і супроводу. Стратегією фірми є підтримка єдиної версії системи. Звичайно нові версії системи з'являються один раз в рік. Процедура оновлення системи в банку, як правило, зводиться до завантаження з декількох магнітних стрічок.

У березні 1997 р. була продемонстрована версія АБС для Windows NT, однак готовий для пілотних випробувань проект, функціонально ідентичний UNIX-версії, з'явився тільки на початку 1998 р.

У планах Temenos означається підтримка Інтернет-банкинга. Спочатку для приватних, а потім і для корпоративних клієнтів будуть доступні наступні функції:

оплата чеків;

формування постійних розпоряджень;

платежі;

управління рахунками;

запит на кредитування;

запит курсів валют;

оцінка портфеля.

Крім цього планується організувати на Web-сайте виробника сторінку для підтримки користувачів.

На російському ринку просування і супровід системи здійснює фірма AviComp Services AG, бізнес-партнер розробника Globus швейцарської фірми Temenos Systems SA.

Отже, виходячи з міркувань складності настройки і подальшого супроводу найбільш переважними для впровадження в російських банках є наступні АБС:

Symbols (виробник System Access; підтримку в країнах СНД здійснює НПФ ФОРС);

Globus (виробник Temenos; підтримку в країнах СНД здійснює AviComp).

Ці АБС в повній мірі задовольняють сучасним технологічним вимогам і мають високі функціональні можливості. Крім того, з всіх систем на Unix-платформі тільки ці дві мають централізовану підтримку авторизованними організаціями на території СНД.

Безумовний інтерес також представляє АБС Olympic (виробник ERI Bancaire) - найбільш функціонально розвинена сучасна банківська система на платформі AS/400. Істотним недоліком, що обмежує можливість її впровадження, є відсутність централізованої підтримки в країнах СНД регіональним представником розробника. Проте, потрібно враховувати наявність в Росії позитивного досвіду впровадження в одному з великих комерційних банків локалізованої ним зарубіжної АБС.

Традиційна філіальна модель банківського бізнесу, особливо роздрібного, є досить дорогою. Модель банківського бізнесу, заснована на розвитку дистанційного банківського обслуговування, в більшості випадків може виявитися більш ефективним з точки зору вартості бізнесу і його рентабельності. При цьому не затверджується, що роздрібне банківське обслуговування сьогодні можливе взагалі без філіальної мережі. Підсумком впровадження дистанційного обслуговування повинне бути раціональний розвиток філіальної мережі і відповідне зниження загальних витрат на розвиток бізнесу.

У побутовому розумінні під дистанційним банківським обслуговуванням мається на увазі проведення банківських операцій без візиту клієнта в банк (на основі розпоряджень, що передаються їм видаленим образом). Сучасні форми дистанційного банківського обслуговування, про які мова піде нижче, з'явилися порівняно недавно з появою персональних комп'ютерів, нових коштів телекомунікацій і зв'язку і ряду інших технологій.

Дистанційне банківське обслуговування (ДБО) має багато форм і назв - в англійській мові, наприклад, використовуються терміни remote banking, direct banking, home banking, internet banking, on-line banking, phone banking, mobile-banking, WAP-banking, SMS-banking, GSM-banking, TV- banking... Відрізняючись в нюансі, перераховані терміни описують особливу область відносин між банком і клієнтом - управління рахунками на відстані по каналах видаленого доступу.

Послуги ДБО тягнуться від найпростіших інформаційних сервісів типу отримання інформації про залишок на рахунку до таких складних форм обслуговування, як отримання кредиту в режимі видаленого доступу або розміщення заявок брокеру на фондовому або валютному ринку. Обслуговування різних сегментів ринку вимагає від банків використання різних технологій, пристроїв і каналів доступу. Канали доступу, т. е. кошти комунікації, які використовує клієнт для управління рахунками, можуть бути самими різними - банкомат, телефон, стільниковий телефон з підтримкою протоколу WAP або протоколу обміну короткими повідомленнями SMS, Інтернет, сервіс-центр (Call-центр), personal Digital Assistant, електронна пошта, факс, спеціалізовані інтерфейси до сервісу-провайдер типу Visa Interactive, Integrion, CheckFree. Банк, що надає своїм клієнтам повний набір сервісів ДБО, тим самим стає телекоммуникационнофинансовим центром, в який по різних каналах стікаються розпорядження клієнтів.

Клієнти такого «телекомунікаційного» банку можуть використати для проведення операцій будь-якої з каналів доступу, що підтримуються або користуватися різними комбінаціями каналів в залежності від ситуації. Наприклад, можна використати комп'ютер на робочому місці при управлінні рахунками з роботи, мобільний телефон - по дорозі додому і звичайний телефон або домашній комп'ютер з виходом в Інтернет - вдома. Як правило, розпорядження формуються і передаються клієнтами в режимі самообслуговування, хоч при необхідності клієнт може провести операції за допомогою оператора Call-центра банку.

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

Процессинг дистанційних розпоряджень проводиться банком за допомогою відповідного програмно-апаратного комплексу підтримки ДБО (далі «система ДБО»), задачею якого є взаємодія з клієнтом, реєстрація дистанційних розпоряджень, їх обробка, забезпечення безпеки і ряд інших функцій, більш детально розглянутих нижче.

Крім системи ДБО, в банку, як правило, можуть бути встановлені інші спеціалізовані системи ведіння рахунків (СВС), призначені для рішення специфічних задач, наприклад, системи для роботи з депозитами або платіжними картами. У разі наявності декількох СВС доцільна інтеграція сервісів, що підтримуються цими системами, в тому числі надання клієнту можливості управління всіма рахунками в різних системах через інтерфейс системи ДБО.

Передумови прискореного розвитку систем ДБО в цей час полягають в наступному:

Конкуренція. У умовах переходу від індустріальної моделі економіки до інформаційного суспільства з акцентом на мережеві технології традиційні банки з їх консервативними брендами і ресурсами стикаються із загрозою, вихідною від динамічних молодих фінансових інститутів, що будують свою стратегію на максимальному використанні самих передових технологій і що мають гнучку структуру для створення нових сервісів і продуктів. Посилюється також конкуренція з боку небанківських організацій - операторів зв'язку, ведучих рахунки клієнтів і що пропонують різні платіжні і розрахункові послуги.

Зміна моделі банківського обслуговування. У цей час в багатьох розвинених країнах внаслідок розвитку технологій і телекомунікацій відбувається помітна еволюція класичної філіальної моделі банківського бізнесу. Функції існуючої роздрібної мережі поступово вужчають, і філіали все більш нагадують спеціалізовані сервіс-центри, в той час як сфера поширення ДБО зростає.

Міграція населення і інтернаціоналізація. Стараючись найбільш повно задовольнити бажання своїх діючих і потенційних клієнтів, банки вимушені враховувати міграцію населення, що посилилася в останні роки всередині країн і за їх межі. Працюючи по старинке, банк практично не має шансів зберегти клієнтів, що переїжджають в місця, де у нього немає філіали. Дистанційне банківське обслуговування дозволяє банку з легкістю надавати свої послуги клієнтам, що знаходяться в будь-якій точці земної кулі, де є кошти телекомунікацій.

Зміна психології. Перехід до постиндустриальному суспільства характеризується темпом життя, що прискорюється. Час стає товаром в тому значенні, що все більше людей починають ставити знак рівності між втратами часу і втратами грошей. З точки зору клієнтів, ДБО набагато ефективніше за ходіння по відділеннях банків, і банки не можуть не враховувати цього.

Кошти комунікації. Найважливішим чинником, без якого розвиток ДБО був би неможливий, є поява доступних коштів передачі, зберігання і обробки інформації. Зокрема, мова йде про зниження цін на персональні комп'ютери і стільникові телефони, появу компактних комп'ютерів (персональних коммуникаторов) і виникнення такої загальнодоступної середи передачі інформації, як Інтернет.

Криптографія. Успіхи криптографії протягом останніх десятиріч дозволили створити надійні і практично безкоштовні кошти аутентификація і цифрового підпису, завдяки чому закладена основа для такого основоположного для ДБО поняття, як видалений контракт - висновок операції в цифровому вигляді при відсутності фізичного контакту сторін.

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

Коммодіфікация.

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

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

Ще більш значний виграш отримує банк. По-перше, це конкурентні переваги по відношенню до інших банків, що ще не устигли впровадити у себе ДБО. Бізнес, побудований на моделі ДБО, легше масштабується, оскільки число клієнтів, що обслуговуються не обмежується кількістю філіали і відділень і персоналом банку. Банківське обслуговування стає екстериторіальним, банк може обслуговувати іногородніх і іноземних клієнтів, не відкриваючи додаткових видалених відділень. Крім того, з'являється можливість забезпечити цілодобовий сервіс, що для такої протяжної країни, як Росія, актуально в плані залучення видалених клієнтів. Спрощується розширення бізнесу і впровадження нових продуктів. Оскільки всі операції проводяться на центральному комп'ютері, додавати додаткові послуги можна швидко і без істотних організаційних витрат.

По-друге, це зниження витрат. ДБО дозволяє знизити операційні витрати в десятки і сотні разів внаслідок зниження чисельності персоналу і накладних витрат на управління відділеннями. Якщо вартість проведення простої банківської операції у відділенні складає (для західного банку) біля 1 долл., то вартість операції через систему ДБО складає одиниці або частки центів.

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

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

Необхідно згадати і недоліки ДБО. Використання каналів дистанційного доступу неминуче відкриває нові можливості для зловживань, тому питання безпеки повинні поміщатися при розробці стратегії ДБО важливу. Віддаляючись від клієнта, банк втрачає можливості, пов'язані з людським спілкуванням. Бажано тому передбачити в структурі сервісів «точки контакту», наприклад, нарівні з дистанційним обслуговуванням пропонувати послуги, що вимагають візиту клієнта в банк.

Шляхи розвитку ДБО можуть бути різні. Частина банків розвиває ДБО у вигляді додаткового сервісу передусім тому, що клієнту це зручне, а для будь-якого банку зручність клієнта - головна мета. При такому підході банк не отримує значної економії, зате виграє у конкурентів. Клієнтам пропонується максимально широкий вибір послуг, вони можуть здійснювати операції як через звичайні філіали, так і через телекомунікаційні канали доступу. Интерактивность поєднується з можливістю «людського» спілкування з працівниками банку в офісі і по телефону. Такий підхід можна назвати сервісом-орієнтованим, а банки, що дотримуються цієї концепції, - «багатоканальними» банками. Як правило, по такому шляху йдуть великі роздрібні банки, бажаючі знаходитися в руслі передових тенденцій розвитку і що розраховують в перспективі добитися раціоналізації своєї роздрібної мережі.

Є і інший підхід, при якому у розділ кута ставиться мінімізація витрат, і з цією метою організується окремий «віртуальний» банк, який працює тільки через Інтернет і інші канали доступу. Економію, що Отримується такі банки готові розділити з клієнтами: як правило, вони надають клієнтам більш високі ставки по внесках, чим звичайні банки. Крім того, деякі з віртуальних банків повертають клієнтам частину комісій за зняття грошей в банкоматах, як би компенсуючи відсутність власної інфраструктури. Однак останнім часом в США з'явилися ознаки уповільнення притоки клієнтів у віртуальні банки на фоні їх стоку, що збільшився. Експерти пояснюють це завищеними очікуваннями в частині якості сервісу у віртуальних банках, що примушує клієнтів перейти на обслуговування в звичайні банки, що надають послуги ДБО. Серед причин називаються також низька оцінка надійності віртуальних банків, відсутність схем гарантування депозитів і невисока прибутковість їх функціонування в зв'язку з величезними витратами на рекламу.

Як вже відмічалося, ДБО об'єктивно вимагає використання автоматизованої банківської системи. Щоб скласти уявлення про складність полнофункциональной системи ДБО, ми приводимо нижче список вимог до функцій такої системи і сервісів, які повинні надаватися з її допомогою:

Екстериторіальність і безперервність роботи системи. Клієнту надається можливість управління коштами незалежно від його знаходження і часу діб.

Множинність каналів і пристроїв доступу. У системі повинна бути передбачена можливість використання різних каналів і пристроїв доступу в будь-якій комбінації.

Интерактивность обслуговування. Система повинна забезпечувати можливість проведення операцій в режимі самообслуговування.

Клієнту повинна надаватися можливість вибору між проведенням операцій в інтерактивному режимі і через оператора.

Проведення операцій в режимі реального часу в тих випадках, коли це можливе.

Мінімізація ручної обробки операцій. Технологія повинна бути організована так, щоб по можливості виключити або скоротити стадії, що вимагають ручної обробки. Можливість оперативного розвитку системи і додавання нових каналів і пристроїв доступу без внесення істотних змін в її архітектуру.

Підтримка основних систем управління персональними фінансами (Quicken, Microsoft Money).

Доступність сервісів по всіх каналах і для всіх ресурсів 24 години в доби 7 днів в тиждень.

Точність, актуальність і наглядність інформації, що надається, можливість настройки формату представлення на рівні окремих клієнтів, доступ до інформації в режимі реального часу.

Єдиний простір рахунків. Одноманітний доступ до всіх рахунків і іншої інформації клієнта незалежно від розподілу цієї інформації по інформаційних системах, що використовуються фінансовим інститутом, прозоре переміщення активів клієнта між різними системами ведіння рахунків.

Можливість масштабування системи по мірі збільшення числа клієнтів і зростання потоку транзакцій.

Стійка робота в періоди пікових навантажень.

Можливість оперативної реалізації нових продуктів з метою своєчасної реакції на потреби клієнтів і дії конкурентів.

Модульна архітектура для забезпечення перспектив довготривалого розвитку системи.

Високий рівень гарантій цілісності і безпека даних і транзакцій.

Максимальна капіталізація на інвестиціях, зроблених фінансовим інститутом в інші (суміжні) інформаційні системи.

Інтеграція з іншими інформаційними системами, що використовуються фінансовим інститутом, із збереженням автономного функціонування і розвитку цих систем.

Можливість персонализації сервісів, реалізації технології індивідуального обслуговування.

Наявність гнучкого і інтерфейса, що розвивається до платіжних і розрахункових систем, що використовуються в країні знаходження банку і за рубежем.

Підтримка продуктів, властивих звичайним автоматизованим банківським системам, депозити, поточні рахунку, позики і т. п.

Робота системи ДБО в режимі доступу з робочих місць операціоністів операційних залів банку.

Можливість роботи з різними пристроями ідентифікації і можливість додавання нових пристроїв. Клієнт повинен мати можливість вибору рівня сервісів в залежності від своїх можливостей і потреб.

Архітектура системи ДБО, що задовольняє перерахованим вище вимогам, показана на малюнку.

Доступ клієнтів до системи по різних каналах здійснюється через контроллери каналів, де під контроллером розуміється программноаппаратний комплекс, що забезпечує взаємодію між системою і клієнтом по каналу доступу. Задача контроллера каналу складається в наданні клієнту відповідного інтерфейса, підтримці пристроїв доступу, що використовуються з даним каналом, реєстрації дистанційних розпоряджень клієнтів і створенні відповідних електронних документів в базі даних системи. У числі іншого контроллер каналу займається обробкою поступаючої від клієнта інформації (наприклад, приймає дані, що вводяться клієнтом на клавіатурі телефонного апарату) і передачею клієнту відповіді системи. У процесі реєстрації дистанційного розпорядження контроллер активно взаємодіє з іншими компонентами системи. Функції і архітектура контроллера каналу залежать від особливостей каналу: сервери телефонних каналів складаються з плати комп'ютерної телефонії і відповідного програмного забезпечення, сервер для каналу Інтернет представляє з себе програму на Інтернеті-сервері. Як правило, контроллер каналу вимагає для установки окремого сервера.

Зареєстровані дистанційні розпорядження клієнтів, представлені електронними документами в базі даних системи ДБО, обробляються системою обробки дистанційних розпоряджень, задача якої складається в перетворенні дистанційних розпоряджень в реальні проводки по рахунках клієнтів і створенні документів (квитанції, сповіщення, платіжні доручення і т. п.), супутніх операції.

Система ведіння рахунків представляє, по суті, операційний день системи ДБО. Функції системи ведіння рахунків виходять з назви - зберігання інформації про клієнтів, їх рахунки, проводки, проведених операціях. У залежності від рішення система ведіння рахунків може бути як самостійною системою, так і частиною АБС банку.

У разі використання самостійної системи повинні бути реалізовані механізми відображення (обліку) операцій, проведених через систему ДБО, в АБС банку. Принципово можливі два механізми обліку: аналітичний і синтетичний. У разі аналітичного обліку кожному рахунку, відкритому в системі ДБО, відповідає один рахунок в АБС банку. По мірі накопичення в системі ДБО змін, викликаних операціями, що проводяться клієнтами або банком (нарахування відсотків і т. п.), ці зміни відбиваються в АБС банку. Для цього за допомогою шлюзу АБС формується файл змін, який обробляється коштами АБС банку, внаслідок чого в операційному дні банку створюються відповідні проводки. У разі синтетичного обліку в АБС банку відкриваються зведені рахунки, кожний з яких відповідає певній групі внутрішніх рахунків системи ДБО. Відображення змін проводиться так само, як і у разі аналітичного обліку з тією відмінністю, що в АБС банку утворяться консолідовані проводки по зведених рахунках. Для підтримки взаємодії між зовнішніми системами і системою ДБО з метою створення інтегрованого набору сервісів використовуються шлюзи. Задачею шлюзу є формування електронних документів (у вигляді файлів, запитів і т. п.) в форматі, зрозумілому зовнішньою системою, і обробка електронних документів, що поступають із зовнішньої системи. Структура шлюзу залежить від особливостей зовнішньої системи, в деяких випадках, наприклад, шлюз може бути представлений модулем імпорту/експорту файлів, в інших - сукупністю збережених процедур і видів бази даних. Швидкість обміну також може широко варіюватися від файлового обміну до авторизационних запитів в режимі реального часу.

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

Проблема, яку сьогодні доводиться вирішувати фінансовим інститутам, полягає в забезпеченні високого рівня і одноманітності сервісу при доступі по самим різним каналам доступу і за допомогою самих різних пристроїв доступу. Складність задачі зростає, якщо фінансовий інститут використовує декілька інформаційних систем, що базуються на різних платформах, частина з яких може надаватися третіми сторонами. При визначенні стратегії впровадження систем ДБО фінансовим інститутам доводиться враховувати, що інформаційні технології змінюються настільки швидкими темпами, що час появи нових каналів або пристроїв доступу може порівнятися згодом циклу розробки і впровадження інформаційних систем. Системи ДБО повинні реалізовуватися на платформах, що допускають можливість швидкої настройки і розширення, додавання нових сервісів, нових каналів і пристроїв доступу.

- Задоволення вимог до системи ДБО, перерахованих вище, є вельми непростою і далеко не дешевою задачею. Неправильний вибір фінансовим інститутом стратегії розробки і впровадження такої системи спричиняє цілком реальний ризик пізнього виходу на ринок і втрату конкурентних переваг.

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

Навіть якщо система забезпечує високий рівень интерактивности і велику частину операцій проводиться клієнтами в автоматичному режимі, залишається необхідність організації цілодобової клієнтської служби. Насправді, як би ні був автоматизований процес проведення операцій, завжди залишаються питання, які не можуть бути вирішені без участі оператора Call-центра.

По вищеперелічених причинах більшість банків користується послугами зовнішніх організацій при розробці і впровадженні системи ДБОе В найбільш загальній постановці в схемі аутсорсинга (див. малюнок) беруть участь наступні суб'єкти:

Учасник - Банк, що надає своїм клієнтам дистанційне банківське обслуговування.

Клієнт - Фізична або юридична особа, що відкрила рахунок у Учасника і що є його клієнтом.

Аутсорсер - Спеціалізована компанія, що здійснює реєстрацію і обробку дистанційних розпоряджень клієнтів Учасника.

Розрахунковий Банк - Банк, ведучий рахунку Учасників і що виконує розрахункові функції (на схемі не показаний). У приватному разі функції Аутсорсера і Розрахункового Банку можуть бути об'єднані і знаходитися у ведінні Розрахункового Банку.

У основі технології обслуговування клієнтів, що пропонується інших банків через Систему Телебанк лежить розподіл праці, при якому всі питання, що стосуються традиційного обслуговування клієнтів входять в компетенцію банку-учасника. Банк-учасник самостійно визначає конфігурацію фінансових продуктів ДБО, укладає договору з клієнтами, веде їх рахунки, здійснює касові операції, проводить свою тарифну і процентну політику і надає ті види банківського обслуговування, які вимагають особистої присутності клієнта (продаж дорожніх чеків, видача пластикових карток, оформлення кредитів, довіреності і т. д.). Аутсорсеру передаються функції процесингового центра дистанційного обслуговування (інформаційно-технічне обслуговування, реєстрація і обробка дистанційних розпоряджень клієнтів Учасника). У свою чергу, проведення розрахунків відповідно до дистанційних доручень клієнтів Учасника здійснюється Розрахунковим Банком.

Взаємодія між учасниками Дистанційного банківського обслуговування оформляється наступними парами договорів: між Аутсорсером і Розрахунковим Банком, Учасником і Розрахунковим Банком, Учасником і Клієнтом і між Учасником і Аутсорсером. Договір Учасника з Клієнтом є договором рахунку, в якому додатково визначаються умови і порядок дистанційного банківського обслуговування Клієнта Учасником. Договір між Учасником і Аутсорсером визначає умови і порядок надання дистанційного банківського обслуговування Аутсорсером. Ніяких юридичних відносин між Клієнтом і Аутсорсером не виникає. Таким чином, Учасник несе відповідальність перед своїми Клієнтами, Аутсорсер і Розрахунковий Банк несуть відповідальність перед Учасником.

Аутсорсер і Розрахунковий Банк стягують з Учасника комісійні винагороди за інформаційно-технічне і розрахункове обслуговування у відповідності зі своїми тарифами. Учасник стягує комісійні винагороди з Клієнтів за розрахунково-касове і дистанційне банківське обслуговування у відповідності зі своїми тарифами.

Безпеку Клієнтів, Учасника і Аутсорсера забезпечується використанням системи паролів, змінних одноразових кодів, програмних і фізичних засобів ідентифікації і цифрового підпису. У разі доступу по каналах Інтернет додатковий захист забезпечується використанням стандартних коштів (SSL). Інформаційний обмін між Учасником і Аутсорсером захищений від несанкціонованого доступу використанням електронного цифрового підпису на несиметричних ключах.

При використанні банком послуг сторонньої компании-аутсорсера банк отримує значні переваги для забезпечення конкурентних позицій на ринку:

Відсутність істотних витрат на введення нової послуги.

Можливість залучення масового клієнта зручним і сучасним сервісом.

Побудова зарплатних схем, заснованих на ДБО і карткових продуктах.

Отримання комісій за обслуговування, що в цей час для банків стає одним з основних джерел доходів.

Надання клієнтам можливості використання об'єднаної роздрібної мережі банка-аутсорсера і інших банків-учасників для проведення операцій внеску-зняття готівки.

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

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

Питання безпеки діляться на дві групи. До першої групи відносяться питання захисту клієнта від несанкціонованого доступу до його інформації, що знаходиться в системах банку або зв'язку, що передається по лініях. Так, система ДБО повинна забезпечити конфіденційність інформації про клієнта (залишки і надходження на рахунки, що проводяться операції) і захист від спроб несанкціонованого доступу до коштів клієнта. Потрібно відмітити, що захист клієнта має на увазі опосередковано і захист інтересів банку, оскільки конфлікт з клієнтом з приводу розголошування його інформації може мати для банку неприємні наслідки.

Друга група питань відноситься до захисту від несумлінних клієнтів (що можуть, наприклад, в корисливих цілях оспорювати проведені операції).

Забезпечення безпеки при використанні системи ДБО засноване на використанні механізмів контролю доступу і повноважень і включає рішення наступних задач:

- Ідентифікація - встановлення відповідності між абонентом, що встановив з'єднання по каналу видаленого доступу, і клієнтом системи ДБО. Ідентифікація клієнтів проводиться на призначене для користувача ім'я, яким є певна послідовність символів. З урахуванням того, що деякі пристрої доступу підтримують введення тільки цифрової інформації, доцільно імена користувачів в системі ДБО обмежити цифровими послідовностями.

Аутентификація - підтвердження повноважень абонента використати введений ним ідентифікатор клієнта.

Контроль цілісності розпоряджень - комплекс заходів, що забезпечує неможливість зміни змісту розпорядження при передачі від абонента до системи ДБО по каналу видаленого доступу.

Забезпечення неотрекаемости - встановлення авторства розпорядження, що забезпечує неможливість відмови клієнта від операції, проведеної на основі і відповідно до розпорядження.

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

Способи рішення задач контролю доступу і повноважень різні в залежності від каналу доступу. У деяких випадках, наприклад при проведенні операцій через Інтернет, можливе досягнення дуже високого рівня захисту і спільне використання декількох механізмів захисту, в інших, наприклад при доступі по телефону, кошти захисту обмежені. Існуючі в даний момент кошти захисту розглядаються нижче.

Найбільш простій і найменше надійний спосіб аутентификація клієнта полягає у введенні клієнтом коду або пароля, відомого тільки йому. Доступ по більшості з перерахованих вище каналів передбачає передачу інформації по відкритих мережах, що не дозволяє забезпечити надійний захист пароля від перехоплення і подальшого використання. Таким чином, пароль може розглядатися швидше як перша лінія оборони, що відсіває певну частку «непрофесійних» спроб несанкціонованого входу в систему ДБО.

Таблиця нумерованих кодів (також званих сеансовими ключами), кожний з яких є паролем. Відмінність від постійного коду складається в тому, що кожний змінний код може бути використаний тільки один раз, що робить безглуздим перехоплення. Після вичерпання всіх кодів клієнту видається нова таблиця. Досвід ГУТА Банку показує, що в середньому таблиця з ста кодів вичерпується за півроку, що не спричиняє дуже великих незручностей для клієнта. Недоліком змінних кодів є необхідність для клієнта носити з собою таблицю, оскільки запам'ятовування декількох десятків кодів, очевидно, неможливе. Попадання таблиці в руки зловмисника (наприклад, шляхом копіювання) дає останньому доступ до рахунків клієнта. Рівень захисту може бути підвищений при використанні комбінації пароля, що запам'ятовується клієнтом, і таблиці кодів. Слабим місцем таблиці змінних кодів також є можливість використання атаки, заснованої на емуляції зловмисником системи ДБО з метою отримання від клієнта поточного змінного коду і його подальшого використання для проведення операції від імені клієнта.

Захищений локальним паролем фізичний пристрій, за допомогою якого клієнт може динамічно отримувати код доступу в систему. Прикладами токенов є такі пристрої, як Active Card і Tele I.D. Токен зареєстрований в системі ДБО на клієнта і певним чином синхронізований з сервером системи, що дозволяє системі визначити, що код був дійсно отриманий за допомогою токена клієнта. Фактично токен є аналогом таблиці змінних кодів, але на відміну від неї захищений локальним паролем. Крім генерації змінних кодів, токени можуть виконувати ряд інших функцій, наприклад обчислювати MAC-код для розпоряджень, що передаються, що забезпечує цілісність повідомлень. На жаль, відомі авторам токени використовують для обчислення MAC-кодів криптографічні алгоритми на симетричних ключах, що не дозволяє забезпечити властивість неотрекаемости. Недоліком токенов є і їх відносно висока ціна (біля 50 долл. для ActivCard і 30 долл. для Tele I.D.), що обмежує їх застосування для обслуговування масової клієнтури.

Криптографія на асиметричних ключах представляє найбільш надійний спосіб захисту інформації, що забезпечує рішення всіх вищеперелічених задач. Клієнт створює пару ключів (секретний і відкритий), з яких відкритий ключ передається в Банк, секретний знаходиться в розпорядженні клієнта і відомий тільки йому. Дистанційні розпорядження, що Передаються шифруються і підписуються електронно-цифровим підписом на секретному ключі клієнта. Банк перевіряє підпис за допомогою відкритого ключа клієнта.

При використанні криптографічного захисту велике значення має надійне зберігання секретного ключа. Для зберігання можуть використовуватися звичайні носії інформації (дискета, жорсткий диск) або захищені носії (смарт-картки, таблетки пам'яті). Найбільш надійним представляється спосіб, коли зберігання виготовляється в EEPROM-пам'яті смарт-картки і криптографічні обчислення також виготовляються в пам'яті смарт-картки. У цьому випадку секретний ключ клієнта ніколи не покидає захищеного простору смарт-картки, чим забезпечується найвища міра захисту секретної ключової інформації від несанкціонованого доступу.

Недоліком криптографічного захисту є необхідність навчання клієнтів користуватися такими коштами. У разі смарт-карток і таблеток-пам'яті недоліком є висока ціна (від 5 долл.) і необхідність використання спеціалізованих ридеров.

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

Інтеграція платіжних карт і системи ДБО істотно розширює спектр послуг, що пропонуються і вирішує проблему зняття готівки з рахунку - одну з найбільш серйозних проблем, з якими стикаються банки при впровадженні ДБО. З іншого боку, держатель картки отримує можливість більш гнучко управляти коштами на карткових рахунках.

Ідеальним варіантом потрібно вважати випадок, коли спецкарточние рахунку ведуться в системі ДБО або коли карткова система має функционал ДБО.

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

отримання по всіх каналах доступу інформації про залишок на карт- рахунку і отримання виписок по карткових рахунках;

поповнення карткових рахунків шляхом переказу коштів в банк- емітент або шляхом файлового обміну, якщо карткові рахунки ведуться в банку, де встановлена система;

перекази коштів з карткових рахунків на рахунки в системі ДБО і здійснення платежів безпосередньо з рахунків платіжних карт;

оперативне повідомлення держателів карт про проведення операцій по них.

Якщо ще декілька років назад основні події в області ДБО були пов'язані з використанням персональних комп'ютерів і банківськими операціями через Інтернет, то в цей час центр тягаря змістився в сторону ДБО з використанням персональних інтелектуальних комунікаційних пристроїв, таких як мобільний телефон або персональний коммуникатор. Поєднання переносимості і персональности з обчислювальними здібностями і екраном дисплея робить інтелектуальні мобільні пристрої прекрасною платформою для розвитку нових технологій ДБО.

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

Мобільний телефон фактично є симбиозом телефону і комп'ютера і поєднує ряд функцій, які роблять його ідеальною платформою для розвитку ДБО:

функції комунікації з можливістю передачі голосової інформації, тонів, даної в цифровому форматі;

функції ідентифікації, аутентификація і цифрового підпису;

функції введення і виведення на/з екрана, в тому числі символьних даних;

обчислювальні функції (завдяки наявності процесора);

функції зберігання інформації (завдяки наявності пам'яті);

функції завантаження даних «по повітрю» в фоновому режимі на стільникові телефони в режимі очікування;

функції активної передачі даних на стільниковий телефон по Push- каналах.

У даний момент існує дві основні різновиди мобільного банкинга з використанням стільникових телефонів: на базі протоколу WAP (Wireless Access Protocol) і на базі протоколу SMS (Short Message Service).

У випадку WAP-банкинга стільниковий телефон грає приблизно таку ж роль, як комп'ютер при Інтернет-банкинге. На стороні банку встановлюється Веб-сервер, підтримуючий сторінки, підготовлені відповідно до протоколу WML (Wireless Markup Language, протокол розмітки сторінок, оптимізований відповідно до обмежень мобільного зв'язку). Зміст сторінок передається в микробраузер стільникового телефону і відображається на дисплеї. Введення даних і їх передача в банк проводяться, як і у разі Інтернету, шляхом передачі форми. Очевидною перевагою WAP-банкинга є його зручність для користувача - можливість навігації по сайту банку, наочне уявлення і зручне введення інформації (в тому числі і буквеної).

SMS-банкинг заснований на використанні механізму коротких повідомлень - спеціального каналу передачі даних, що спочатку використовувався операторами стільникового зв'язку для передачі службової інформації. За допомогою таких коротких повідомлень (довжина інформаційного блоку - 140 байтів) на стільниковий телефон передається інформація банку, наприклад список рахунків або виписка по рахунку, а в банк передаються дані, введені клієнтом. Додаткові можливості виникають в зв'язки з використанням таких механізмів, як передача даних на телефон, що знаходиться в режимі очікування, «по повітрю» (Over the Air, OTA) і посилка повідомлень (Push). При допомозі OTA банк може, не запрошуючи клієнта в офіс, оновлювати інформацію (наприклад, список операцій) на стільниковому телефоні з точністю до індивідуального клієнта. Механізм Push представляє широкі можливості для побудови системи нотифікації, для повідомлення клієнтів про настання певних подій (наприклад, списанні коштів з рахунку або досягненні встановленого клієнтом значення котировання цінного паперу).

Технології WAP і SMS-банкинга отримують подальший розвиток при використанні SIM-карток. Будучи обчислювальним пристроєм з внутрішньою захищеною пам'яттю, SIM-картки являють собою ідеальний пристрій для зберігання ключової інформації і виконання криптографічних обчислень всередині захищеного пристрою. Використання SIM- карток дозволяє забезпечити якісно новий рівень фінансової і інформаційної безпеки. Крім того, SIM-картки представляють хорошу платформу для зберігання даних клієнта (наприклад, персонального списку операцій). У поєднанні з ОТА-завантаженням даних це дозволяє забезпечити високий рівень персонализації послуг ДБО.

Безпечні мобільні додатки можуть бути засновані не тільки на використанні SIM-карток. Синергетичний ефект від спільного використання смарт-карток, випущених банком, і мобільного телефону представляється вельми сильним. Смарт-картка надає засіб безпечного проведення фінансових операцій, а мобільний телефон - гнучку і зручну платформу для використання цих сервісів. З цієї точки зору, можливо, найбільш гнучкий підхід складається в додаванні до мобільного телефону другого інтерфейса для смарт-карток. Такий підхід має ряд переваг, оскільки дозволяє використати смарт-картки третіх виробників без використання SIM-картки і розділяє функції операторів зв'язку і інші додатки. Використання другого слота (насправді, стандарт допускає до восьми слотов) є стандартом в світі GSM і дозволяє використати другу смарт-картку, наприклад EMV, за допомогою стільникового телефону. Така комбінація забезпечує ефективну реалізацію рішень, пов'язаних з електронною готівкою типу VisaCash.

Ще більш високий рівень інтеграції виникає при використанні стільникових телефонів як платформа для надання банківських послуг на основі смарт-карток шляхом використання SIM-карток в багатозадачному режимі. При цьому нові сервіси можуть додаватися просто шляхом динамічного завантаження нових додатків, необхідних клієнту, по повітрю. Не здається дуже сміливим технологічне припущення, що багатозадачні смарт-картки і фінансові послуги складуть основний напрям розвитку на наступній фазі еволюції мобільних послуг.

Перспективи розвитку мобільного банкинга виглядають вельми багатообіцяюче. Досить часто аналітиками висловлюється припущення, що персональні комп'ютери, незважаючи на їх популярність, не є найкращою платформою для доставки фінансових сервісів. Проблема в тому, що персональний комп'ютер, незважаючи на назву, не є повністю персональним пристроєм. Мобільний телефон, навпаки, є персональним пристроєм, з яким власники не розлучаються велику частину часу, що робить його ідеальною платформою для таких речей, як фінансове обслуговування. Крім того, соціологічні дослідження говорять про те, що мобільний телефон розглядається людьми як модний аксесуар і необхідний засіб спілкування, а персональний комп'ютер - швидше як засіб виробництва.

У розвинених країнах перспектива швидкого поширення мобільного банкинга пояснюється об'єктивними чинниками:

швидко зростає число клієнтів, що віддають перевагу і що активно використовують безготівкові електронні платежі;

число мобільних телефонів в даний момент перевищує проникнення персональних комп'ютерів;

проведення операцій через мобільний телефон простіше, ніж через комп'ютер;

користувачі мобільного банкинга представляють привабливий сегмент, оскільки є в основному молодими і спроможними людьми;

при використанні Push-технологій і механізмів нотифікації мобільний банкинг забезпечує якісно новий рівень контролю стану рахунків з боку клієнта.

Перспективність стільникових телефонів як платформи для розвитку мобільного банкинга підтверджується аналізом динаміки зростання числа стільникових телефонів. На кінець 1999 р. частка населення, що користується мобільними телефонами в Європі, становила 40%, а в Фінляндії - і зовсім більше за 70%. Очікується, що до 2002 р. частка мобільних телефонів перевищить 100%, оскільки багато які будуть мати не один телефон.

У завершення даної теми відмітимо, що розвиток технологій мобільного банкинга ще далеко не досяг граничної точки. Зміни в області мобільного зв'язку носять вибуховий характер. Продовжується зростання швидкості передачі даних. З введенням Universal Moblie Telephone Services (UMTS) швидкість передачі даних досягне 144 кбит/з, а до 2005 р. очікується подальше зростання до 2 Мбіт/з. Збільшення швидкості передачі знімає обмеження на об'єм даних, що передаються і відкриває нові можливості для розвитку. На хвилі прогресу в області мобільного зв'язку формується нова модель ведіння бізнесу - мобільний бізнес, однією з основних складових якого є мобільний банкинг.

Перехід від банкоцентрированной до клиентоцентрированной моделі фінансового обслуговування спричиняє зміну форм взаємодії між банками і клієнтами. З розвитком електронної комерції поступово вимальовуються контури нової схеми фінансового обслуговування, в якій незнайомі один з одним клієнти банків взаємодіють в рамках деякої платформи, що забезпечує можливість висновку операцій в електронній формі на відстані між незнайомими персоналиями, а їх банки забезпечують розрахунки в режимі реального часу. У світлі сказаного задача банку складається в створенні ринкового простору і забезпеченні механізмів, необхідних для здійснення операцій між клієнтами.

Розглянуті вище способи дистанційного керування рахунками передбачають, що власник рахунку дає банку доручення перевести гроші (кредитувати) на рахунок, що явно указується (кредитова модель). Але розуміння ДБО тільки як форми активного управління рахунками в рамках кредитової моделі було б неповним. З урахуванням сказаного вище про розвиток електронної комерції і зміну функцій банків не менш цікаві форми ДБО, засновані на дебетовій моделі.

У випадках коли операція не спричиняє безпосередньої взаємодії власника рахунку і банка або така взаємодія по яких-небудь причинах небажано, потрібно дебетова модель розрахунків. При дебетовій моделі розрахунків власник рахунку укладає з банком договір про безакцептне списання коштів зі свого рахунку при настанні певних подій, наприклад при надходженні з вказаного клієнтом джерела запиту на списання коштів. На дебетовій моделі розрахунків засновані всі системи, що використовують платіжні картки з магнітною смугою, - при проведенні розрахунків по картці рахунок її держателя безакцептно дебетується банком при надходженні з платіжної системи електронного документа, підтверджуючого, що держатель де-небудь розрахувався за допомогою картки.

Дебетова модель розрахунків представляє інтерес в зв'язку з розвитком електронної комерції, де взаємодія між клієнтом і банком суперечить вимозі проведення розрахунків в режимі реального часу. Нижче сформульовані принципи побудови системи розрахунків на базі існуючих систем управління рахунками, що розвиваються окремими компаніями.

Однією з умов успішного розвитку електронної комерції як B2B, так і B2C є наявність системи розрахунків між сторонами. Система розрахунків повинна:

підтримувати розрахунки в режимі реального часу;

підтримуватися великим числом учасників, в ідеалі це повинен бути національний стандарт електронних розрахунків;

бути відкритою системою і забезпечувати можливість приєднання нових учасників;

характеризуватися прийнятними вартісними параметрами як для учасників, так і для клієнтів;

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

У даний момент в Росії не існує платіжної системи, що задовольняє всім перерахованим вище умовам. Є декілька систем дистанційного керування рахунками, розроблених рядом російських банків, в тій або інакшій мірі що задовольняють перерахованим умовам. Оскільки розробка національної системи електронних розрахунків найближчим часом представляється малоймовірною, найбільш правильним представляється рішення створення відкритої системи розрахунків (відкритої платіжної системи, ОПС) на базі існуючих систем, основним принципом якого повинна бути «м'яка» інтеграція, що забезпечує виконання перерахованих вимог при умові збереження можливості незалежного існування і розвитку існуючих систем. У якійсь мірі такий підхід нагадує ідеологію CORBA, що забезпечує можливість взаємодії разноплатформенних інформаційних систем.

Схематично архітектура відкритої розрахункової системи показана на малюнку.

Відкрита платіжна система включає в себе безліч локальних платіжних систем (ЛПС) і декілька інститутів, централизованно що надають ресурси, для яких доцільне спільне використання, наприклад Розрахунковий Банк.

Кожна ЛПС має певну кількість клієнтів, якою надаються сервіси, характерні для даної ЛПС, в тому числі ведіння рахунків, можливість дистанційного керування рахунками і т. п. Сервіси різних ЛПС не зобов'язані бути однаковими. ЛПС, вхідні в ОПС, залишаються автономними, в тому значенні, що зберігають внутрішню організацію, бізнес-процеси і сервіси і можуть розвиватися незалежно від інших ЛПС і ОПС.

Для забезпечення інтеграції окремих ЛПС в єдину ОПС для ЛПС реалізовується набір інтерфейсних функцій у відповідності зі специфікаціями, затвердженими ОПС. Інтерфейсні функції ЛПС формують шар абстракції, що відділяє ЛПС від ОПС. Задача шара абстракції полягає в перетворенні повідомлень, що поступають з ОПС або інших ЛПС, у внутрішній формат ЛПС і зворотне перетворення повідомлень, що направляються назовні, відповідно до вимог специфікацій ОПС.

Розрахунки між ЛПС засновані на обміні ними повідомленнями у вигляді електронних документів стандартного формату. Обмін повідомленнями відбувається через будь-яку середу, що забезпечує можливість передачі електронних документів, наприклад Інтернет або комунікаційну інфраструктуру провайдер стільникового зв'язку. У останньому випадку мобільні телефони виступають як інтелектуальні вузли мережі.

Кожна ЛПС надає два набори сервісів. Внутрішні сервіси, специфічні для кожної ЛПС, надається ЛПС своїм клієнтам, при цьому взаємодія між клієнтом і ЛПС відбувається за правилами ЛПС. До внутрішніх сервісів відносяться, наприклад, сервіси по дистанційному керуванню рахунками. Надання внутрішніх сервісів не спричиняє взаємодії з іншими ОПС.

Зовнішні сервіси надаються у випадках, коли в транзакції бере участь клієнт інший ЛПС, і потрібно організація взаємодії з інший ЛПС.

Будучи заснованої на механізмі обміну сполученнями між компонентами, ОПС представляє з себе систему захищеного електронного документообігу. Задача організації захищеного електронного документообігу може бути вирішена стандартними коштами шляхом використання шифрування обмінюваних документів і електронно-цифрового підпису з використанням криптования на несиметричних ключах. Проблема розподілу публічних ключів між учасниками однієї платіжної системи вирішується або шляхом безпосередньо обміну ключами між учасниками електронного документообігу, або шляхом використання власного сервера сертифікатів локальної платіжної системи. Використання окремого сервера сертифікатів всередині ЛПС доцільне внаслідок необхідності забезпечення сертфикатами клієнтів ЛПС.

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

Необхідний як мінімум наступний спектр підсистем ДБО:

для клієнтів банку - юридичних осіб, в тому числі і для корпоративних VIP-клієнтів - «класичний» «банк - клієнт»;

для клієнтів банку - фізичних і юридичних осіб - «тонкий» Ін- тернет-«банк - клієнт»;

для клієнтів банку - фізичних і юридичних осіб - комп'ютерна телефонія, що має на увазі як тільки інформаційне (опционально), так і повноцінне платіжно-розрахункове обслуговування;

для банків-кореспондентів і підрозділів банку (філіали, відділень, додаткових офісів, обмінних пунктів і т. д.) - банківська розрахункова система.

Практика показує вдале застосування різних з вищеперелічених послуг в деяких сучасних банках. При цьому система ДБО не тільки вирішує поточні або перспективні задачі банку, але і «підказує» банку принципово нові види бізнесу, такі, наприклад, як організація електронної комерції, що тільки розвивається серед своїх клієнтів і їх підприємств-суміжників, а також здійснення Інтернету-розрахунків.

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

окремої підготовки адміністратора;

свого власного інтерфейса і механізму прив'язки до баз обліку в банку (наприклад, до АБС або картковій системі);

особливого, несхожого на інші підсистеми ДБО процесу впровадження;

відмінного від інших механізму адміністрування, протоколювання і аудиту.

У зв'язку з цим стає очевидною необхідність використання єдиної комплексної системи ДБО банку, одного разу інтегрованої в облікові бази банку - АБС, систему приватних внесків і інш.

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

«Інтернет - клієнт - Банк» позиціонується і як самостійний продукт, і як частина інтегрованої системи ДБО. Відповідно, «Інтернет - клієнт - Банк» є одним з способів підготовки і доставки в банк насамперед платіжних, а також інакших документів від клієнта. Система, таким чином, здійснює функції фронту-офісу банку, доставляючи підготовлені і відправлені клієнтами документи в універсальну банківську частину ДБО, де і проводиться їх подальша обробка.

Нижче перераховані основні задачі підсистеми «Інтернет - Клієнт - Банк»:

проведення різних типів платіжних документів клієнтів;

обмін повідомленнями довільного формату;

отримання виписок в різних видах і форматах, а також інакшої інформації з банку;

організація Інтернет-комерції як самому банку, так і будь-якому його клієнту;

побудова розрахункових і клірингових систем в режимі реального часу;

Відмітні особливості

Для успішного впровадження підсистема «Інтернет - Клієнт - Банк» володіє наступними двома основними перевагами:

юридична значущість і абсолютна захищеність документообігу банку з «тонким» браузерним клієнтом;

масовість впровадження, що виражається як в абсолютній простоті інсталяції системи у клієнта (максимум інсталяції повинен виражатися в натисненні setup.exe), так і в низькій вартості самої системи і володіння нею.

Будь-яка не володіюча цими двома властивостями система «тонкого» «Інтернет - клієнт-Банк» приречена або на провал, або на переродження в «класичного» «товстого» «банк - клієнта», що має на комп'ютері клієнта об'ємне спеціальне програмне забезпечення.

Два вищенаведених твердження, що є, по суті, визначенням «Інтернет - клієнта - Банк», диктують і особливості побудови системи:

мінімальний об'єм клієнтської частини - тільки система захисту і ключі в об'ємі однієї дискети;

використання тільки стандартного НТТР-протоколу;

використання тільки стандартних коштів криптографії (Excellence, Lan Crypto, Верба і інш.). Не використовується SSL або інакші юридично не значущі в Росії протоколи. Можливість сертифікації ФАПСИ;

абсолютна юридична значущість і безпека документообігу - кожний документ підписується ЕЦП, весь http-трафік в обидві сторони шифрується і протоколюється. У іншому випадку зберігається імовірність зловмисних підробок як самих форм, так і правил їх заповнення. Таким чином, зневага підписом, шифруванням і протоколюванням http-трафіка з банку є потенційно небезпечним для побудови фінансового документообігу і не забезпечує юридичну значущість;

мінімальний http-трафік «банк - клієнта» в сеансі, можливість роботи через proxy-сервер;

універсальність засобу доступу до Мережі - стандартний браузер (MS IE і інш.). При цьому доступ до системи може бути здійснений з будь-якої точки світу з будь-якого комп'ютера (таку гнучкість не забезпечує, наприклад, спосіб захисту, коли користувач проходить додаткову авторизацію за своєю фіксованою IP- адресою);

безумовна простота і масовість впровадження;

гнучкість системи і внесення будь-яких настройок, в тому числі редагування/додавання документів;

звичний і зручний, але в той же час не громіздкий інтерфейс.

Юридична значущість роботи з системою «Інтернет - Клієнт -

Банк»

«Інтернет - Клієнт - Банк», як і будь-яка інша банківська послуга клієнту, повинна мати під собою чітку юридичну базу. Саме внаслідок відсутності такої Інтернету-рішення багатьох розробників не знайшли свого застосування в реальному житті. Юридична значущість підсистеми «Інтернет - Клієнт - Банк» в рамках комплексу ДБО забезпечується наступними основними принципами:

між клієнтом і банком повинен існувати договір, що визначає їх взаємовідносини, а також рішення конфліктних ситуацій з посиланнями на основні функції системи і скріплений фізичними підписами і відтисненнями печатей сторін. Ключовим моментом такого договору є поняття електронно-цифрового підпису банку і клієнта;

саме для забезпечення юридичної значущості договору використовуються «стандартні», добре відпрацьовані системи ЕЦП і шиф- рації (Excellence, Lan-Gypto і інш.). Обов'язкова також можливість використання (опционально) СКЗИ, сертифікованих ФАПСИ;

при підписанні договору банк і клієнт оформляють акт фізичної передачі ЕЦП і реєстрації ключів, а також передачу однієї дискети з інсталяцією програмного забезпечення (цю інсталяцію, проте, клієнт може «скачать» і з банківського сервера - в залежності від того, як складений договір);

подальший підпис клієнтських документів, а також всього http- трафіка від клієнта в банк і зворотно здійснюється за допомогою переданої - згідно з актом - ЕЦП;

обов'язковий підпис всього трафіка з банку, оскільки в іншому випадку зберігається імовірність зловмисних підробок форм документів.

Масовість впровадження «Інтернет - Клієнт - Банк», як було сказано вище, забезпечується ціною системи і абсолютною простотою початку роботи з нею або її інсталяції.

У цей час питанням безпеки даних в розподілених комп'ютерних системах приділяється дуже велика увага. Розроблена безліч коштів для забезпечення інформаційної безпеки, призначених для використання на різних комп'ютерах з різними ОС. Як один з напрямів можна виділити міжмережеві екрани (firewalls), покликані контролювати доступ до інформації з боку користувачів зовнішніх мереж.

Проблема міжмережевого екранування формулюється таким чином. Нехай є дві інформаційні системи або дві безлічі інформаційних систем. Екран (firewall) - це засіб розмежування доступу клієнтів з однієї безлічі систем до інформації, що зберігається на серверах в іншій безлічі.

Екран виконує свої функції, контролюючи всі інформаційні потоки між цими двома множинами інформаційних систем, працюючи як деяка «інформаційна мембрана». У цьому значенні екран можна уявляти собі у вигляді набору фільтрів, що аналізують минаючу через них інформацію і на основі закладених в них алгоритмів що приймають рішення: пропустити цю інформацію або відмовити в її пересилці. Крім того, така система може виконувати реєстрацію подій, пов'язаних з процесами розмежування доступу, зокрема фіксувати всі «незаконні» спроби доступу до інформації і - додатково - сигналізувати про ситуації, що вимагають негайної реакції, т. е. підіймати тривогу.

Звичайно екрануючі системи роблять несиметричними. Для екранів визначаються поняття «всередині» і «зовні», і задача екрана складається в захисті внутрішньої мережі від «потенційно ворожого» оточення. Найважливішим прикладом потенційно ворожої зовнішньої мережі є Інтернет.

Гнучкість і масштабованість системи забезпечується використанням широко-поширених технологій Інтернет. Тема 4. Кредит і кредитна система Суть і види кредиту:  Тема 4. Кредит і кредитна система Суть і види кредиту: Виберіть вірну відповідь: Структура кредиту являє собою єдність наступних елементів: а) кредитор, позичальник, банк; б) кредитор, позичальник, вартість, що позичається; в) суб'єкти кредиту і банк; г) банк, позичальник, забезпечення кредиту. Основною властивістю кредиту
Тема 4. КООРДИНАЦІЯ ВИБОРУ В РІЗНИХ ГОСПОДАРСЬКИХ СИСТЕМАХ:  Тема 4. КООРДИНАЦІЯ ВИБОРУ В РІЗНИХ ГОСПОДАРСЬКИХ СИСТЕМАХ: № 1. Ви присутні на диспуті між прихильником ринкової і прихильником централизованно-керованої економіки. Перший з названих учасників затверджує: «Ринок - завжди і скрізь найбільш ефективна форма господарства». Другий же заперечує:
Тема 2. Конституційне право РФ: Поняття і предмет конституційного права, Конституція 1993 р.:  Тема 2. Конституційне право РФ: Поняття і предмет конституційного права, Конституція 1993 р.- основний закон держави. Конституційний статус особистості, конституційні права, свободи і обов'язок, гарантія прав і свободи особистості і проблема їх дотримання. Особливості
Тема 8. Комунікаційна політика.: Маркетингові комунікації є складовою частиною масовою:  Тема 8. Комунікаційна політика.: Маркетингові комунікації є складовою частиною масової комунікації і мають ряд відмітних особливостей від останньої. По-перше, маркетингові комунікації точно направлені на цільову аудиторію, що говорить об їх цілеспрямованому
ТЕМА 3.5. КОМЕРЦІЙНІ БАНКИ, ЇХ ОПЕРАЦІЇ І ПОСЛУГИ:  ТЕМА 3.5. КОМЕРЦІЙНІ БАНКИ, ЇХ ОПЕРАЦІЇ І ПОСЛУГИ: Комерційні банки (КБ) і їх місце в банківській системі. Особливості функціонування КБ в сучасній економіці. Роль КБ в здійсненні розрахунків і кредитуванні економіки. Банківські безготівкові розрахунки і принципи їх організації. Пасивні операції
Тема 1.5. Вимір грошової маси. Грошовий обіг і його закони:  Тема 1.5. Вимір грошової маси. Грошовий обіг і його закони: Важлива роль грошей у ринковій економіці вимагає не тільки якісного (теоретичного) визначення їхньої сутності і функцій, але і їхній кількісного (емпіричного) виміру. Це зв'язано з тим, що: повиннео існувати відповідність між емпіричним
Тема 5.1. Історія розвитку і структура побудови банківської системи:  Тема 5.1. Історія розвитку і структура побудови банківської системи РФ: У містах-республіках середньовічної Русі, в Пськове і Новгороде, перші купецькі асоціації виникли вже в 13 в. А в 1665 р. псковский воєвода А. М. Ордин-Нащекин створив невеликий банк для підтримки «маломочних» купців. Він проіснував недовго і