ТЕМА 2. ІНФОРМАЦІЙНІ СИСТЕМИ У ФІНАНСОВО-КРЕДИТНИХ УСТАНОВАХ
2.1. Особливості АІС у фінансових і банківських установах
За системного підходу структурні складові управління такі: 1) керуюча система, або суб’єкт управління (СУ); 2) керована частина, або об’єкт управління (ОУ); 3) інформаційна система (ІС), через яку, власне, і відбувається зв’язок між СУ та ОУ.
ІС є неодмінною складовою в організації управління і містить у собі такі основні частини:
1) сукупність економічних даних на відповідних носіях, організованих певним способом;
2) методи, способи, технічні засоби й технології збирання, обробки, зберігання, пересилання інформації та її надання користувачам.
Залежно від застосовуваних технічних засобів обробки інформації розрізняють ручні, механізовані та, у разі використання автоматів, насамперед ЕОМ, автоматизовані ІС (АІС).
Для банківських установ потрібно зазначити такі особливості при створенні АІС.
Висока продуктивність АІС, її здатність швидко переробляти інформацію, відстежувати зміни на об’єкті, у навколишньому середовищі та максимально їх ураховувати.
Об’єкти й процеси, якими керують, а також і сама система управління (керування) можуть бути складними і територіально розподіленими. Так, у разі окремого комерційного банку або відділення, котре територіально й організаційно зосереджене в одному місці, створення його АІС вимагатиме підходу й технологій обробки даних, відмінних від тих, що застосовуються, тоді коли банк являє собою сукупність відділень або філій, які територіально розміщені в різних місцях регіону.
У першому разі банк розглядається як один об’єкт, як єдине ціле, де практично немає проблеми передавання та приймання первинних даних.
У другому разі структура АІС складніша, застосовуються інші технології обробки даних. Тут можливі проблеми збору та передавання даних із відділень до головної контори. Відповідно АІС буде багаторівневою системою, причому проблеми збирання, передавання й обробки даних вельми складні як з технічного, так і з організаційного боку.
3. Для фінансово-кредитних установ, і для банківських насамперед, об’єкт управління — керована частина, або основне їх «виробництво» — також пов’язане з виробленням і переробкою інформації. Адже основою діяльності таких установ є, по суті, робота з інформацією, яка часто стає і предметом і продуктом праці не лише відповідних інформаційних систем, а й установи в цілому.
Отже, у фінансово-кредитних установах автоматизація «основного виробництва» зводиться до автоматизації операцій обробки даних відповідних документів, тобто до обробки інформації. Цим такі установи істотно відрізняються від промислових підприємств, де автоматизація основного виробництва являє собою автоматизацію процесів обробки матеріальних потоків, а отже, створення АІС тут означає автоматизацію інформаційних процесів, пов’язаних із основним виробництвом, а не самого виробництва.
АІС у ФКУ, і насамперед у банківських установах, не тільки обробляють управлінську інформацію, а й виконують автоматизацію операцій «основного виробництва» (обробка даних відповідних документів у процесі здійснення грошових розрахунків, надання кредитів, нагромадження коштів і т.ін.). Формально такі АІС можна подати як синтез автоматизованої системи обробки управлінської інформації (АСУу) та автоматизованої системи основного виробництва (АСОВ):
АІСФКУ = АСУу + АСОВ.
4. Першочерговість автоматизації операцій «основного виробництва» є специфічною вимогою, коли йдеться про створення АІС у банках та інших фінансово-кредитних установах. Саме з огляду на цю вимогу зазначені АІС істотно відрізняються від АІС виробництвом (АСУВ), які автоматизують обробку лише інформації про хід основного виробництва. Цією особливістю пояснюється, здебільшого, і факт широкого впровадження ЕОМ у банківських і фінансових установах. Адже на будь-якому економічному об’єкті передусім автоматизується «основне виробництво».
Зауважимо, що ступінь автоматизації АСУу і АСОВ у АІСФКУ нині різний — вищий у АСОВ і нижчий у АСУу. Крім того, розв’язання завдань управління на промислових підприємствах автоматизоване значно вище, ніж в АІС ФКУ. Тобто широке застосування у фінансово-кредитних установах ЕОМ, і насамперед персональних комп’ютерів, забезпечується здебільшого завдяки автоматизації основного виробництва.
Банківські автоматизовані інформаційні системи (БАІС) або, як їх ще називають, електронні банківські системи (ЕБС) — це системи, які виконують переказування (переміщення) грошей, а також реєструють і аналізують інформацію про ці операції з використанням комп’ютерів і сучасних засобів зв’язку.
5. Банківські АІС відрізняються від решти таких систем ще й тим, що використовувана в них інформація має бути надійно захищена, а вони самі повинні мати підвищену «живучість» і безвідмовність у роботі.
2.2. Вплив специфіки діяльностіі структури банків на структуру їх АІС
Основна діяльність будь-якого економічного об’єкта є визначальною як при створенні структури об’єкта управління, формуванні управлінського апарату, так і при розробці АІС розглядуваного об’єкта. Від зазначеної діяльності залежить зрештою перелік розв’язуваних задач, методи й способи їх розв’язання, обсяги та потоки інформації, методи збору, зберігання, обробки та передавання даних. Тому аналіз основ та особливостей діяльності банківських установ і з’ясування специфіки їх роботи — неодмінні умови створення відповідних АІС.
В Україні функціонує дворівнева банківська система. На першому рівні перебуває Національний банк України (НБУ), на другому — комерційні банки (КБ) різних форм власності, спеціалізації та сфери діяльності.
Організаційно НБУ не є унітарною установою, а також має ієрархічну структуру: на першому рівні — Центральне управління НБУ, а на другому — територіальні (здебільшого обласні) управління цього банку (ТУ НБУ).
Комерційні банки мають різну структуру, яка істотно впливає на структуру їх АІС і технологію обробки даних. Усі КБ за структурою можна поділити на такі типи.
Перший тип — так звані «унітарні» КБ, які не мають філій або відділень і територіально та організаційно розміщені в одному місці (в одному приміщенні).
Другий тип — це КБ, які мають багаторівневу (два і більше рівнів) структуру, де на верхньому рівні перебуває головна контора (офіс), а на нижніх рівнях — філії та відділення, котрі розміщені в межах одного регіону. Те, що всі підрозділи КБ зосереджені в одному регіоні, є істотним, оскільки згідно з чинним положенням усі КБ та їх філії реєструються і перебувають на обліку у відповідних територіальних управліннях НБУ.
До третього типу структур можна віднести комерційні банки, які мають регіональні відділення та філії, котрі розташовані в різних регіонах і відповідно зареєстровані та перебувають на обліку в різних ТУ НБУ.
Задачі, проблеми управління, збору, передавання та зберігання даних, а отже, і структура банківської АІС для різних типів структур істотно різні.
У разі КБ зі структурою першого типу вся інформація про роботу самого банку та його клієнтів зосереджена практично в одному місці. Відповідна БАІС являє собою сукупність кількох інформаційно взаємопов’язаних функціональних і забезпечуючих АРМ, на яких базується автоматизація головних видів діяльності банку.
До множини таких АРМ належать АРМ-3 (його називають ще АРМ НБУ) з виконання міжбанківських розрахунків зазначеного банку з використанням системи електронних платежів (СЕП) НБУ, а також комплекс програмних і технічних засобів (ПТК) із забезпечення роботи електронної пошти (ЕП) НБУ (обслуговуючий АРМ), на базі якої і працює СЕП.
Автоматизовані робочі місця можуть бути об’єднані в локальну обчислювальну мережу (ЛОМ) або працювати автономно, але неодмінно мають бути інформаційно узгоджені між собою. Отже, технічний комплекс (ТК) таких систем може являти собою або ПК, об’єднані в ЛОМ, або автономні персональні ЕОМ, інформаційний зв’язок між якими здійснюється з допомогою машинних носіїв.
Сукупність функціональних АРМ (ФАРМ) внутрішньобанківських розрахунків у БАІС об’єднують в єдину систему — програмно-технічний комплекс під назвою «Операційний день банку» (ОДБ), котрий забезпечує автоматизоване виконання внутрішньобанківських розрахункових і бухгалтерських операцій протягом одного операційного дня банку.
Нагадаємо, що операційний день банку — це та частина його робочого дня (як правило, перша половина), котра призначена для приймання та обслуговування клієнтів і виконання банківських операцій. При цьому платіжні повідомлення, що надійшли до банку протягом операційного дня, мають бути відображені на особових рахунках клієнтів та у відповідних розділах бухгалтерського обліку (балансу) того самого робочого дня.
Загальну схему БАІС банківської автономної установи унаочнює рис. 2.1.

Рис. 2.1. Загальна структура АІС комерційного банку:
ЕПД — електронні платіжні документи; ППД — платіжні документи на паперових носіях
Згідно з чинним положенням платіжні документи в СЕП можуть надходити лише через АРМ-3. У нових версіях АРМ-3 вилучено функцію ручного вводу таких документів, тому останні можуть надходити до АРМ-3 лише з ОДБ БАІС. У складі ПТК ОДБ рекомендується виокремлювати спеціальне АРМ бухгалтера електронних платежів (АРМ БЕП), яке дає змогу відповідному працівникові банку протягом банківського дня проглядати й роздруковувати файли обміну між АРМ-3 і ОДБ та перевіряти електронні підписи на документах, які надходять із СЕП, або накладати електронний підпис на підготовлені до відправлення до СЕП документи, а також створювати файл, що являє собою квитанцію-підтвердження про отримання файлів від СЕП.
«Багатокористувацький» програмний комплекс «Клієнт—банк» автоматизує процеси формування, приймання, відправлення й передавання фінансових та інших повідомлень між клієнтами й банком. Зв’язок установлюється, як правило, по телефонних каналах через систему електронної пошти. Така система надає клієнтові низку переваг порівняно з традиційними методами передавання платіжних повідомлень (пошта, телеграф, телекс), оскільки під час роботи з цією системою всі операції з оплати виконуються в офісі клієнта.
Застосування банківських автоматів (банкоматів) передбачає використання магнітних пластикових карток (МПК), за допомогою яких через автомат можна виконувати деякі банківські операції, такі як видача готівки, одержання інформації про стан рахунка і т.ін.
Множина інших функціональних АРМ в БАІС (крім ОДБ), як правило, включає в себе ФАРМ з автоматизації управління кредитними, депозитними та касовими операціями, АРМ з управління валютними операціями, ПТК статистики й аналізу фінансового стану банку та управління ліквідністю, АРМ маркетингових операцій, ПТК інформаційного забезпечення керівництва банку тощо.
У разі багаторівневої структури КБ зі створенням АІС виникають додаткові проблеми. Насамперед це проблема передавання даних на великі відстані й забезпечення при цьому їх безпеки, достовірності й конфіденційності; проблеми оцінювання фінансового стану банку як сукупності елементів; управління територіально-регіональним розподілом фінансів, формування статистичної та оперативної звітності по банку в цілому і т.ін.
Оскільки робота з клієнтами ведеться на всіх рівнях, то можливі різні системи її організації, а отже, і застосування різних моделей і методів розв’язування одних і тих самих задач у різних елементах.
У цілому АІС комерційного банку також є ієрархічною організаційною структурою, котру можна подати як сукупність АІС підрозділів (елементів) такої установи, причому з різними завданнями (функціями) і різними методами виконання одних і тих самих завдань для елементів різних рівнів.
У разі складної структури КБ зв’язок між його елементами, а відповідно і їх АІС може реалізуватися або у процесі використання послуг ЕП НБУ та інших систем електронного передавання даних, або створенням власних систем передавання даних.
Особливості БАІС істотно залежать і від виду діяльності та характеру виконуваних банком операцій.
Говорячи про БАІС, здебільшого мають на увазі автоматизацію традиційних послуг, тобто фактично автоматизацію виконання завдань (функцій, операцій) основного виробництва. Але існують ще й функції управління, які також можуть бути ефективно автоматизовані. Скажімо, максимізація кредитів (оскільки прибуток банку тим вищий, чим вища частка кредитів) і мінімізація залишків. Водночас банки мають забезпечувати повернення грошових коштів за депозитними вкладами, на вимогу клієнтів, нараховувати та видавати проценти, а також проводити платіжні операції своїх клієнтів. Для цього їм потрібні наявні грошові кошти, і тут постає завдання забезпечення ліквідності банку, тобто його достатньої здатності виконувати свої зобов’язання перед клієнтами.
Якщо банк має у своїй структурі філії чи відділення, тобто є сукупністю банківських установ, які працюють за «лімітом», постають проблеми відстежування використання лімітів, їх розрахунку та розподілу між елементами системи протягом того чи іншого періоду, зокрема протягом дня.
Водночас кожний КБ є ризиковим підприємством, котре має зводити цей ризик до мінімуму, дбаючи про те, щоб він не впливав на прибуток його клієнтів. Звідси випливають завдання оцінювання платоспроможності позичальників та розміру ризику; визначення сумарних обсягів повернення грошових коштів за виданими й узятими позиками, за депозитними вкладами, за вимогами клієнтів; оперативного обліку наявності грошових коштів та можливості їх використання протягом певного періоду і т.ін. Взагалі постають проблеми управління ресурсами банку в часі, оцінювання й аналізу ситуації типу: «що буде, коли?» та «що потрібно, аби?».
Управляти ресурсами банку не менш складно, ніж виробництвом на підприємстві. Адже існують численні джерела надходження й використання коштів, причому потужність цих джерел різна та змінювана в часі, здебільшого стохастично. Відповідна математична задача не має прямого аналітичного розв’язання, тому доводиться застосовувати методи імітаційного моделювання, експертні системи тощо.
Загалом БАІС (ЕБС) забезпечують:
автоматизацію внутрішньобанківської діяльності, і насамперед операцій з обробки платіжних та інших документів у тих підрозділах банківської установи, які працюють безпосередньо з клієнтами;
автоматизацію виконання міжбанківських розрахунків та інших зовнішньобанківських операцій;
автоматизацію фінансових операцій у рамках міжнародного банківського бізнесу.
2.3. Принципи створенняі функціонування АІС ФКУ
Створюючи АІС чи будь-яку іншу систему, спираються на певні принципи — загальні вимоги, правила чи норми, яких слід додержуватись.
Так, згідно з нормативними документами під час створення автоматизованих систем (АС) необхідно керуватися принципами системності, розвитку, сумісності, стандартизації та ефективності.
1. Принцип системності. Необхідно встановлювати такі зв’язки між структурними елементами системи, які забезпечують її сумісність та взаємодію з іншими системами. Отже, усі зв’язки, елементи, функції та проблеми управління й діяльності мають розглядатися як єдине ціле.
2. Принцип розвитку (відкритості). Автоматизована система має створюватися з урахуванням можливості поповнення й оновлення її функцій та складу без порушення функціонування АС.
3. Принцип сумісності. Під час створення системи мають бути реалізовані інформаційні інтерфейси, завдяки яким ця система зможе взаємодіяти з іншими системами згідно зі встановленими правилами. Так, будь-яка АІС на рівні КБ має інформаційно взаємодіяти із системами установ НБУ, а АІС обласної податкової адміністрації — з АІС Головної податкової адміністрації України.
4. Принцип стандартизації. Під час створення систем мають бути раціонально застосовані типові, уніфіковані й стандартизовані елементи, проектні рішення, пакети прикладних програм тощо. Система та її елементи потребують стандартизації, аби можна було мінімізувати всі види витрат, уніфікувати прийоми, методи та інструкції, що ними керується персонал.
5. Принцип ефективності. Досягнення раціонального співвідношення між витратами на створення АС і цільовими ефектами, включаючи кінцеві результати, отримані від автоматизації, які не завжди і не обов’язково мають набирати грошової форми, це може бути час (вірніше, його економія), певні зручності, нові функції, імідж і т.ін.
Окрім розглядуваних основних можна додатково визначити ще деякі принципи створення й функціонування АІС ФКУ.
1. Принцип нових задач. Визначаючи перелік задач, які підлягають включенню в АІС, слід ураховувати основні технологічні операції обробки документів та завдання щодо забезпечення повноти, вчасності й оптимальності прийняття рішень, які раніше не виконувались через обмежені можливості обробки інформації.
2. Принцип надійності. Система має нормально функціонувати в разі виходу з ладу технічних засобів. Зрозуміло, наскільки цей принцип важливий для АІС у ФКУ, де існують специфічні вимоги до його реалізації і де втрата інформації рівносильна втраті грошових коштів. Саме з метою додержання цього принципу в АІС дублюють інформацію, технічні засоби, застосовують джерела безперебійного живлення тощо.
3. Принцип єдиної інформаційної бази. Ідеться про застосування єдиної системи класифікації та єдиної системи кодування, одних і тих самих структурних одиниць економічної інформації.
При створенні БАІС, крім того, виникають додаткові вимоги, тобто доводиться спиратися на деякі додаткові принципи.
А. Принцип безпеки даних.
А.1. Інформація має бути захищена як під час її безпосередньої обробки та зберігання в системі, так і в моменти обміну між комп’ютерами.
А.2. Має бути виключена можливість несанкціонованого доступу до даних у системі.
А.3. Усі операції в системі мають реєструватися.
А.4. Будь-яке порушення системи безпеки має бути виявлене.
Б. Принцип надійності системи. У БАІС мають бути однаково високонадійними як апаратне, так і програмне забезпечення. Інформація для клієнта має бути точною, доступною і надаватися йому без затримки. У разі виходу системи з ладу дані мають бути відновлені, а пошкодження усунене.
В. Принцип продуктивності системи. Потреба додержувати його випливає зі значної нерівномірності надходження потоків інформації, яку слід обробляти в певні проміжки часу, і жорстких вимог до термінів її обробки. Окрім того, БАІС повинна мати певний запас потужності, який забезпечує оперативне надання інформації клієнтові за його запитом незалежно від того, які інші роботи виконуються водночас цією системою. У БАІС має бути передбачена також можливість пакетної обробки інформації, особливо коли йдеться про підбиття щоденного банківського балансу.
Г. Принцип пристосування (адаптації). Із часом робота банків змінюється, виникають нові види діяльності та послуг. Тому існуючі інформаційні системи мають бути придатними для модифікації та розширення. Більше того, система може бути повністю перероблена, але інформація при цьому має зберігатися.
Водночас із розширенням обсягів банківської діяльності, зростанням кількості клієнтів збільшуються відповідно й обсяги оброблюваної інформації. Тому БАІС має бути такою, щоб цю систему можна було розширювати, не порушуючи її цілісності.
Д. Важливою є також і вимога щодо зручності, простоти та ефективності експлуатації системи. Банки насамперед обирають системи, які легко встановлювати, використовувати й обслуговувати.
Зауважимо, що розглянуті вимоги вельми загальні, а отже, кожний банк хоча й зацікавлений додержувати їх, проте ступінь їх зацікавленості різний. Завжди при створенні системи існують індивідуальні вимоги до неї і кращою із пропонованих АІС буде та, яка краще підходить до цих вимог.
2.4. Загальна структура ІС, функціональна та забезпечуюча частини. Компоненти системи
Інформаційні системи, зокрема у фінансово-кредитних установах, належать до класу складних, тому для кожної такої системи існує проблема декомпозиції, тобто поділу її на простіші складові (елементи) та подання її у простішому вигляді як сукупності тих чи інших (скажімо, якомога більших) її частин.
Будь-яка АІС поділяється на функціональну та забезпечувальну частини (ФЧ та ЗЧ), які, у свою чергу, поділяються на простіші елементи — підсистеми, котрі також припускають подальший поділ.
До складу забезпечувальної частини входять підсистеми технічного, математичного, лінгвістичного, правового, інформаційного, організаційно-методичного та ергономічного забезпечення.
Підсистема технічного забезпечення (ТЗ), у свою чергу, складається з чотирьох елементів.
1. Технічні засоби — комплекс технічних засобів (КТЗ), використовуваних для одержання, вводу, підготовки, перетворення, обробки, зберігання, реєстрації, виводу, відображення, використання та передавання даних і реалізації керівних дій.
2. Методичні та керівні матеріали щодо КТЗ.
3. Технічна документація, що стосується КТЗ.
4. Персонал, який обслуговує КТЗ.
Підсистема математичного забезпечення (МЗ) являє собою сукупність застосовуваних математичних методів, моделей і алгоритмів.
Підсистема програмного забезпечення (ПЗ) об’єднує програми постійного користування (системні програми, пакети прикладних програм (ППП), СУБД тощо).
Підсистема лінгвістичного забезпечення (ЛЗ) — це сукупність мовних засобів для формалізації природної мови, опису інформації та інших елементів ІС.
Підсистема правового забезпечення (ПрЗ) складається з правових норм і нормативів, які пов’язані із функціонуванням АІС, слугують для юридичного обгрунтування її створення й функціонування, а також визначають юридичний статус результатів такого функціонування.
Підсистема інформаційного забезпечення (ІЗ) містить у собі використовувані дані та правила їх отримання, зберігання, оновлення, а також організації структури й змісту інформаційних сукупностей. Ця підсистема охоплює інформаційні ресурси, а також засоби їх опрацювання, зокрема структуризації і систематизації.
Підсистема організаційно-методичного забезпечення (ОМЗ) — це набір прийомів, правил, документів, інструкцій і положень, які забезпечують створення системи та взаємодію її складових у процесі функціонування всієї системи.
Підсистема ергономічного забезпечення (ЕЗ) становить множину взаємопов’язаних вимог, спрямованих на узгодження психологічних, антропометричних, фізіологічних особливостей і можливостей людини, з одного боку, і технічних характеристик засобів автоматизації, параметрів робочого середовища на робочому місці — з іншого.
У ФЧ АІС вирізняють такі елементи: функціональні підсистеми, блоки, або комплекси задач та окремі задачі.
Функціональна підсистема — це відносно самостійна частина системи, яку виокремлено за певною ознакою, що відповідає конкретним функціям і завданням управління. Цю підсистему можна розглядати як самостійну систему, що характеризується певним цільовим призначенням, відокремленістю інформаційної бази, методичною спрямованістю обчислень економічних показників і спеціалізацією робіт.
Здійснювати декомпозицію ФЧ АІС — поділяти цю систему на підсистеми, комплекси задач і окремі задачі — можна як за окремими ознаками, так і за їх сукупністю.
Найчастіше функціональні підсистеми утворюють за такими ознаками: 1) стадіями управління (прогнозування, планування, облік тощо); 2) елементами виробничого процесу (праця, матеріали, грошові кошти тощо); 3) апаратно-організаційною ознакою (структурні підрозділи); 4) функціональною (виконувані функції) ознакою.
В АІС банківських установ функціональні підсистеми можна виокремлювати за ознакою управління елементами банківської діяльності: підсистема управління і проведення розрахункових, кредитних і депозитних операцій тощо.
Наприклад, достатньо типовою, на нашу думку, є система «Автоматизований банк», що працює в одному з КБ України, яка містить такі головні її підсистеми.
1. Підсистема управління розрахунками (основне ядро). Містить у собі шість блоків задач, зокрема ОДБ, «Щоденний оборотно-сальдовий баланс», «Клієнт—банк», «Бухгалтерська статистична звітність», «Облік міжбанківських електронних платежів»і т.ін.
2. Підсистема управління кредитними операціями (ресурсами). Охоплює вісім комплексів задач (КЗ), серед яких облік кредитних договорів, аналіз показників за довгостроковим кредитуванням і т. ін.
3. Підсистема управління валютними операціями (з виходом на СВІФТ). Включає в себе чотири комплекси задач. Насамперед це облік біржових операцій і статистична звітність за валютними операціями.
4. Підсистема управління фінансами. Містить у собі три комплекси задач, зокрема облік акцій, аналіз стану оплати за кредитні ресурси.
5. Підсистема внутрішньобанківського обліку охоплює шість комплексів задач. Це, зокрема, розрахунок заробітної плати, облік кадрів, облік матеріалів, облік основних фондів і швидкозношуваних предметів.
6. Незалежна інформаційно-пошукова система (ІПС), що стосується юридичних і текстових документів, документів управління безпеки, а також контролю виконавчих документів тощо.
Отже, із шести перелічених підсистем чотири можна віднести до АСОВ і лише одну до АСУ.
ФЧ може реалізуватися на різній технічній базі та з різною (централізованою, децентралізованою і мішаною) технологією обробки даних.
У разі централізованої технології завдання (зокрема й щодо розв’язування задач обчислювального характеру) виконують безпосередньо в обчислювальному центрі (ОЦ) у повному обсязі фахівці служб інформатики. Децентралізована технологія реалізується на системах малих, зокрема й персональних комп’ютерів у вигляді АРМ. Мішана технологія передбачає, що частина задач і операцій виконується на АРМ, а інша (це здебільшого узагальнюючі операції) — на ОЦ.
Як показує досвід, децентралізована обробка даних у АІС ефективніша за централізовану, оскільки в ній забезпечується прямий доступ користувача-фахівця до ЕОМ, тобто уможливлюється обробка даних без посередників, котрі можуть вплинути на правдивість і правильність інформації, а також знизити оперативність виконання відповідних завдань.
Забезпечити прямий доступ і організувати децентралізовану обробку даних можна двома способами: обладнати велику ЕОМ виносними пультами і встановити їх на робочих місцях користувачів-фахівців або встановити на зазначених робочих місцях персональні комп’ютери. В обох випадках функціона-льними елементами АІС є функціонально-спеціалізовані АРМ (ФСАРМ).
Отже, АРМ слід розуміти як цілком певний набір персональних термінальних пристроїв, котрі завдяки залученню обчислювальних потужностей великої ЕОМ дають змогу виконувати на робочому місці інформаційне обслуговування користувача-фахівця в обсязі та режимі, які потрібні для виконання його виробничих (службових) функцій. Можлива й інша інтерпретація: АРМ — це сукупність ПК і спеціального програмного забезпечення, що зорієнтоване на певну сферу використання і забезпечує безпосереднє інформаційне обслуговування користувача-фахівця в потрібному і достатньому для його діяльності обсязі та режимі.
Отже, ФЧ АІС комерційного банку є сукупністю функціонально-спеціалізованих АРМ, перелік і кількість яких залежить від обраної технології та поділу функцій між виконавцями. На практиці всі банківські операції пов’язані між собою єдиною технологією, котра зумовлена такими чинниками: специфікою операцій; спеціалізацією окремих груп працівників і підрозділів банку; поділом обов’язків між ними. Ці чинники й визначають конкретну множину ФСАРМ, число яких в АІС різних банківських установ є різним.
Наприклад, багато банківських АІС містять у собі ФСАРМ адміністратора, головного бухгалтера, бухгалтера, старшого оператора, оператора, контролера, касира, фахівця з МФО, а також забезпечувальні АРМ із ведення нормативно-довідкової інформації (НДІ), початкового пуску системи, виконання «відкату» і т.ін.
Найтиповішою в даний час може вважатися структура БАІС, що охоплює комплекс оперативно-обрахункових операцій (ОДБ); АРМ кредитного відділу; АРМ депозитного відділу; АРМ із міжбанківських розрахунків; АРМ з роботи з філіями; АРМ фондового відділу; АРМ з управління ліквідністю; АРМ з управління активами і пасивами; АРМ маркетингу; блок із забезпечення інформацією керівництва КБ (рис. 2.2).

Рис. 2.2. Структура функціональної частини БАІС
Автоматизація діяльності банку починається з найбільш трудомістких операцій з обслуговування клієнтів. Тому в операційних відділах створюють АРМ бухгалтера, економіста, контролера, операціоніста і т.ін., які далі об’єднуються в локальну мережу. Операційний відділ під час своєї роботи створює автоматизовану базу даних (БД), що є основою для контролю, аналізу, статистичної звітності, комерційної та управлінської діяльності.
Далі автоматизуються міжбанківські розрахунки та міжфілійний обіг, організовується обмін інформацією між відділеннями банків тощо.
Зауважимо, що АІС кожної банківської установи повинна мати також автоматизовану базу даних для кредитного відділу, відповідні АРМ його працівників, а також АРМ керівника для виконання завдань прогнозування діяльності банку, перспективного та поточного планування, вироблення варіантів прийняття рішень тощо. АРМ керівника має, як правило, свій оперативний архів, локальну БД керуючого та доступ до всіх архівних даних банку.
На закінчення зазначимо, що кожна АІС, незалежно від функціональних можливостей (останні можуть бути істотно різними: від розв’язання однієї задачі або їх комплексу до виконання всієї сукупності завдань щодо діяльності об’єкта) містить у собі всі головні структурні елементи. Так, у будь-якій АІС неодмінно присутні функціональна та забезпечувальна частини, елементи технічного, програмного й іншого забезпечення.
2.5. Організація робіт зі створення АІС
2.5.1. Стадії та етапи розробки АІС
Процес створення АІС являє собою сукупність упорядкованих у часі, взаємопов’язаних і об’єднаних у стадії та етапи робіт, виконання яких необхідне і достатнє для створення системи, що відповідає заданим вимогам.
Розглянемо докладніше відповідні стадії та етапи.
1. Стадія формування вимог до АІС.
Етапи: обстеження об’єкта і обгрунтування необхідності побудови системи; формування вимог користувача до неї; оформлення звіту і заявки на її розробку (тактико-технічне завдання).
2. Стадія розробки концепції АІС.
Етапи: вивчення об’єкта; виконання необхідних науково-дослідних робіт (НДР); розробка варіантів концепції АІС і вибір того з них, який задовольняє вимоги користувача; оформлення звіту про виконану роботу.
3. Стадія розробки технічного завдання.
Етапи: розробка технічного завдання та його затвердження.
4. Стадія ескізного проектування.
Етапи: розробка попередніх проектних рішень стосовно системи та окремих її частин.
5. Стадія технічного проектування.
Етапи: розробка проектних рішень стосовно системи та її частин; розробка документації АІС та її частин; розробка й оформлення документації на поставляння або розробку виробів для комплектування системи; розробка завдань на проектування в суміжних частинах проекту автоматизації.
6. Стадія робочого проектування.
Етапи: розробка робочої документації на систему та її частини; створення або адаптація програм.
7. Стадія впровадження системи в дію.
Етапи: підготовка об’єкта автоматизації до впровадження АІС; підготовка персоналу; комплектування АІС (програмними і технічними засобами, інформаційними виробами); будівельно-монтажні роботи; пусконалагоджувальні роботи; попередні випробування; дослідна експлуатація; приймальні випробування.
8. Стадія супроводження.
Етапи: виконання робіт згідно з гарантійними зобов’язаннями та післягарантійне обслуговування.
Залежно від складності автоматизовуваних процесів і завдань не всі стадії є однаково обов’язковими. Із перших трьох стадій обов’язковою є третя, результатом виконання якої має бути затверджений документ «Технічне завдання» (ТЗ). Розробляє його, як правило, замовник. ТЗ поділяється на дев’ять розділів і визначає вимоги до автоматизованих функцій і завдань та до видів забезпечення; регламентує організацію розробки, розміри витрат, терміни виконання стадій і етапів робіт тощо.
Охарактеризуємо стисло головні розділи ТЗ.
Розділ 1. Загальні відомості. Подаються повна та умовна назви роботи, замовника і об’єкта.
Розділ 2. Призначення та мета роботи. З’ясовуються призначення та мета автоматизації.
Розділ 3. Характеристика предметної області. Наводяться відомості про об’єкт управління та процеси, які потрібно автоматизувати, про умови виконання завдань.
Розділ 4. Основні вимоги. Цей розділ найважливіший у ТЗ. Формулюються вимоги до шуканих вирішень і системи в цілому, до взаємозв’язків і взаємодії різних комплексів задач одного з одним та з іншими системами, до рівня автоматизації, технічного, програмного, інформаційного та інших видів забезпечення.
У наступних розділах уточнюються обсяги та терміни виконання робіт, визначаються інші параметри створюваної системи.
Зауважимо, що обсяг ТЗ може змінюватися в доволі широких межах. Наприклад, у однієї і тієї самої фірми-розробника ТЗ на «Багатокористувацький програмний комплекс «Клієнт—банк» становить п’ять сторінок, а на систему ОДБ — понад 40.
Результат виконання стадії технічного проектування являє собою документ «Технічний проект» (ТП), який складається із загально-системної документації та документів щодо функціональної та забезпечувальної частин.
Документація стосовно ФЧ містить проектні рішення з автоматизації функцій та постановки завдань або їх комплексів, а документація стосовно ЗЧ — проектні рішення з інформаційного, програмного, технічного та інших видів забезпечення.
На стадії робочого проектування (РП) до найбільш трудомістких операцій належать розробка та відлагодження робочих програм.
Зауважимо, що в разі об’єднання стадій технічного та робочого проектування обсяг документації зменшується (приблизно на 20%).
На стадії впровадження системи відбувається її пробна експлуатація, на підставі якої виправляються виявлені при цьому недоліки та помилки. Водночас визначаються обсяги виконаних робіт і встановлюється відповідність здобутих результатів вимогам технічного завдання.
2.5.2. Розробка автоматизованого розв’язаннязадач за умов функціонування АІС
Організація розробки автоматизованого розв’язання окремих задач або їх комплексів в тому разі, коли на об’єкті функціонує АІС, має свою специфіку, оскільки тоді, як правило, технічний комплекс і базове програмне забезпечення (ПЗ) уже задані. За таких умов розглядуваний процес розробки автоматизованого розв’язання задач поділяють на вісім етапів.
1. Формулювання вимог — аналог ТЗ.
2. Постановка задачі — елемент ТП.
3. Побудова алгоритму розв’язання задачі — елемент ТП.
4. Розробка контрольного прикладу (КП) — елемент ТП.
5. Розробка машинної блок-схеми та програм — елемент РП.
6. Відлагодження розроблених програм на контрольному прикладі — елемент РП.
7. Відлагодження розроблених програм на реальних даних (пробна експлуатація) — стадія 7-ма.
8. Прийняття в промислову експлуатацію — стадія 8-ма.
Зауважимо, що етапи 6-й і 7-й можна об’єднати, якщо для контрольного прикладу взяти реальні дані і не розробляти машинну блок-схему (її розробляють, як правило, лише для складних алгоритмів).
Етапи є елементами відповідних стадій розробки, і їх сутність та зміст залежать від використовуваних технічних і програмних засобів. Цю залежність у якісному плані ілюструє табл. 2.2.
Таблиця 2.2
Номер і назва етапу
Відповідна стадія
Ступінь залежності етапу



ПЗ
ТЗ

1. Формулювання вимог
ТЗ
—
—

2. Постановка задачі
ТП
слабка
слабка

3. Побудова алгоритму
ТП
середня
”

Закінчення табл. 2.2
Номер і назва етапу
Відповідна стадія
Ступінь залежності етапу



ПЗ
ТЗ

4. Розробка КП
ТП
сильна
”

5. Розробка машинної блок-схеми та програм
РП
те саме
”

6. Відлагодження
РП
”
сильна

7. Пробна експлуатація
7-ма
”
”

8. Прийняття в експлуатацію
8-ма
м
”

Примітки
1. У ТЗ висуваються вимоги до ТК та ПЗ, тому воно практично не залежить від них.
2. Вважаємо, що «сильний» ступінь залежності означає: роботу на відповідному етапі не можна виконати без урахування специфіки конкретного ТК чи ПЗ; «середній» — роботу виконати можна, врахувавши істотні властивості даного типу ТК або ПЗ; «слабкий» — роботу можна виконати без урахування особливостей ТК чи ПЗ.
2.5.3. Опис постановки задачі та її розробка
Опис постановки задачі (ПОЗ) (комплексу задач) є елементом технічного проекту.
У разі машинної та автоматизованої обробки даних обсяг поняття «задача» охоплює:
1) процес машинної обробки даних, тобто безпосереднє розв’язання задачі машинними засобами;
2) метод розв’язування;
3) процедури підготовки даних до обробки;
4) використання даних, зокрема й для прийняття управлінських рішень.
Організовуючи автоматизоване розв’язання задачі, необхідно прийняти певне і конкретне рішення з перелічених питань, а отже, щоб реалізувати автоматизоване розв’язання задачі, слід насамперед розробити її постановку, яка має містити про цю задачу всі необхідні для її автоматизованого розв’язання відомості.
Склад і зміст постановки задачі (комплексу задач) залежить від специфіки останньої та умов розв’язання. Загалом ПОЗ складається з таких основних розділів: 1) характеристика задачі; 2) вихідна інформація; 3) вхідна інформація.
Окрім того, виконується опис алгоритму автоматизованого розв’язання задачі, який може бути включений до ПОЗ як розділ 4-й або бути викладений окремо.
Іноді ПОЗ містить і розділ «Розрахунок економічної ефективності», де обґрунтовується ефективність розв’язання задачі за допомогою ЕОМ.
Схарактеризуємо стисло кожний розділ ПОЗ.
Розділ 1-й містить інформацію про призначення задачі (комплексу задач); перелік об’єктів, у процесі управління якими розв’язується задача; періодичність і тривалість розв’язування; умови, за яких припиняється розв’язування автоматизованим способом; інформаційні та технологічні зв’язки з іншими задачами (комплексами) АІС; посади осіб і (або) назви підрозділів, які визначають умови та часові характеристики конкретного розв’язання (рішення) та поділ обов’язків між персоналом і технічними засобами в різних ситуаціях розв’язування задачі (комплексу задач).
Розділ 2-й (вихідна інформація) складається з переліку та опису вихідних повідомлень (тобто форм відомостей, відеограм, відеокадрів тощо) та переліку й опису структурних одиниць інформації вихідних повідомлень.
Опис вихідних повідомлень має вигляд таблиці, що містить назву кожного повідомлення, його ідентифікатор, форму подання (документ, відеокадр, сигнал тощо), періодичність і термін видачі.
Описуючи структурні одиниці вихідних повідомлень, зазначають назву одиниці, ідентифікатори вихідних повідомлень, яким вона належить, вимоги до точності обчислення цієї одиниці, її умовне позначення.
Розділ 3-й (вхідна інформація) містить перелік і опис вхідних повідомлень та перелік і опис структурних одиниць інформації вхідних повідомлень, які мають самостійне змістове навантаження.
Під вхідною інформацією розуміють дані, які є необхідними для розв’язання задачі й надходять у вигляді документів і повідомлень різної форми. Опис вхідних повідомлень задається також у вигляді таблиці і містить найменування повідомлення, його ідентифікатор, форму подання, строки й частоту надходження.
Опис структурної одиниці вхідного повідомлення складається з її найменування, потрібної точності числового значення та вказівки щодо джерела відповідної інформації (повідомлення, яке містить цю одиницю).
ПОЗ розробляється в такій послідовності. Якщо техніко-економічна суть задачі є зрозумілою, то розробку починають із визначення вихідної інформації розв’язуваної задачі, із опису змісту та форми вихідних повідомлень і способів їх подання, визначення реквізитів та носіїв вихідних даних.
Після встановлення вихідних даних визначають необхідні вхідні дані та розпочинають розробку алгоритму розв’язування за-дачі — послідовності правил отримання вихідних даних на підставі вхідних. Із розробленого алгоритму визначається також інформація для зберігання та нагромадження. На закінчення відпрацьовується система внесення змін до інформації задачі.
Для перевірки правильності алгоритму розробляють контрольний приклад, який слугує також для забезпечення відлагодження програм та їх тестування під час експлуатації.
Практика показує, що найкращий контрольний приклад — це приклад, побудований на реальних даних. Проте скористатися таким прикладом можна не завжди через відсутність потрібних реальних даних або через те, що їх забагато (у такому разі відлагодження програми дуже ускладнюється й уповільнюється) чи наявні реальні дані не повністю відбивають усі можливі варіанти розв’язування.
ПОЗ істотно спрощується, коли для її розв’язання використовуються типові проектні рішення (ТПР) та пакети прикладних програм (ППП). Тоді фактично розробляється лише розділ 1-й, а в 2-у та 3-у розділах ПОЗ відбувається просте «прив’язування» (добір) потрібних повідомлень ППП (ТПР) або зазначені розділи не розробляються зовсім.
2.5.4. Опис алгоритму розв’язування задачі
Алгоритм являє собою правило розв’язання задачі, сформульоване як послідовність обчислювальних, логічних та інших дій (кроків), виконуваних з метою отримання потрібного результату. Алгоритм може бути заданий словесно (засобами природної мови), математичним або графічним описом. Крім того, алгоритм може задаватися алгоритмічною мовою.
В АІС ФКУ алгоритми описуються здебільшого математичним або графічним способом, а також алгоритмічною мовою. Графічному опису передує, як правило, побудова математичної моделі — математичного опису алгоритму. Такий опис полягає у формалізованому (із застосуванням математичних символів) поданні всіх розглядуваних залежностей і методів відшукання значень вихідних даних на підставі вхідних.
Графічний опис алгоритму виконується здебільшого у вигляді структурної схеми. Кожний її елемент являє собою фрагмент алгоритму, який описує певні (повністю визначені) дії з даними. Послідовність дій зображується за допомогою ЛІНІЙ ПОТОКУ ІНФОРМАЦІЇ. Напрям потоку інформації «згори — вниз» і «зліва — направо» вважається основним і стрілками не позначається.
Будуючи схему алгоритму, використовують геометричні фігури — умовні позначення, кожне з яких має стандартний і цілком визначений нормативними документами як зміст, так і вигляд. Наприклад, овалом позначається початок або кінець алгоритму, прямокутником — арифметичні та інші операції з даними і т.ін.
Існують певні графічні позначення і для типів носіїв та форм передавання даних, тому за допомогою таких позначень можна подати не лише машинний алгоритм, а й усю технологію розв’язування задачі та обробки інформації.
До ПОЗ включають здебільшого як математичний, так і графічний опис алгоритму. У разі, коли готують окремий документ «Опис алгоритму», поділяють його на розділи: призначення та характеристика комплексу задач, використовувана інформація, результати розв’язання задач комплексу, математичний опис алгоритму, графічний його опис.
Алгоритмічна мова — це спеціальна мова зі своїм алфавітом, словником, правилами побудови слів, словосполучень, речень, в якій кожне слово має одне і цілком певне значення. Якщо таку мову створено на основі природної мови, то відповідні алгоритми досить просто описуються й читаються.
Зауважимо, що загалом ступінь деталізації опису алгоритму залежить від ерудиції та знань його виконавця, причому опис графічний або алгоритмічною мовою є проміжним. Кінцевим є опис машинною мовою або мовою програмування (якщо алгоритм виконуватиме машина).
Розрізняють кілька рівнів деталізації (задання) алгоритму автоматизованого розв’язання задач АІС ФКУ.
Рівень «інформаційної моделі», або «нульовий», дає уявлення про використовувані вхідні і вихідні повідомлення та форми їх подання. Наводиться графічне (символьне) зображення всіх зазначених повідомлень: вхідних — з одного боку, а вихідних — із протилежного відносно зображення самої задачі. Водночас зазначають, де саме утворюються вхідні і де використовуються вихідні повідомлення. Якщо задача порівняно проста, то такої точності задання алгоритму достатньо для його реалізації.
Наступний (перший) рівень — це рівень, коли алгоритм задається з точністю до робіт з інформаційними масивами й загальних операцій із ними (сортування масиву, вибір, злиття тощо) та з точністю до блоків розрахунків показників за заданими формулами. Багато з таких блоків алгоритму (сортування, добір, обчислення середнього і т.ін.) уже можуть бути реалізовані відповідними командами (операторами) мов високого рівня. У разі одного масиву досить просто за допомогою відповідних команд типу REPORT реалізується блок видачі на друк повідомлення в табличній формі.
Коли у процесі видачі вихідних повідомлень беруть участь два масиви (найчастіше — масив числових значень і кодів реквізитів та масив довідкових даних, який містить розшифрування кодів), доводиться організовувати пошук даних за кодом. Тобто необхідна подальша деталізація алгоритму (хоча в сучасних мовах високого рівня існують відповідні типові засоби видачі повідомлень).
Ще вищим є другий рівень деталізації алгоритму, що означає його задання з точністю до робіт з окремими записами інформаційних масивів, до маніпулювання з полями записів (вибір записів за умовою, пошук за ключем, перехід за номером запису, добір полів, аналіз значень окремих полів і т.ін.).
Як правило, цим рівнем можна обмежитися, якщо йдеться про автоматизоване розв’язання економічних задач у фінансово-кредитних установах та про автоматизацію операцій обробки документів. Проте щодо задач математичної логіки, контролю й захисту інформації такої деталізації недостатньо. Доводиться деталізувати алгоритм до рівня роботи зі складовими частинами полів (символами, байтами), а іноді навіть зі складовими елементами байтів — бітами, що є по суті граничним рівнем задання деталізації алгоритму.
ТЕМА 3. АВТОМАТИЗАЦІЯ РОЗРАХУНКОВИХ, КАСОВИХ І ВАЛЮТНИХ ОПЕРАЦІЙ
3.1. Характеристика розрахункових і касовихоперацій як об’єктів автоматизації
Інформаційні системи комерційних банків в Україні пройшли ряд етапів свого розвитку, поступово здійснився перехід від механізованої обробки інформації до комплексної автоматизації. Переломним моментом у становленні банківських комп’ютерних технологій став 1994 рік, коли міжбанківські розрахунки було переведено на безпаперові технології. З цього моменту в усіх банках обов’язково запроваджувались комп’ютерні технології, основу яких становить програмно-технологічний комплекс «Операційний день банку» (ОДБ), а передача інформації за межі банку здійснюється за допомогою спеціальних АРМ — АРМ підсистеми «Клієнт—Банк», АРМ НБУ (АРМЗ) та АРМ для виконання міждержавних розрахунків.
У структурі будь-якого ОДБ можна виділити три типи функціональних блоків, існування яких випливає із загальної технології його роботи. Це блоки початку роботи (відкриття ОДБ), блоки роботи протягом робочого дня і блоки закінчення роботи (закриття ОДБ).
Блоки відкриття ОДБ забезпечують обробку паролей та ідентифікацію користувачів, уведення дати поточного банківського робочого дня та обробку отриманих з АРМ-НБУ файлів початку роботи. При цьому коригується довідник банків-учасників СЕП, визначається значення кореспондентського рахунка банку на початок робочого дня, проводиться очистка відповідних оперативних баз даних та ін. При відкритті ОДБ виконується також: накопичення відсотків за попередній день по рахунках з процентними ставками, створення копій вхідних основних масивів стану особових та балансових рахунків на початок дня. Якщо це день початку місяця, кварталу або року, то по балансових рахунках формуються відповідні вхідні залишки на початок періоду, обнулюються обороти за місяць, квартал або рік. При відкритті ОДБ відбувається також встановлення для співробітників банку повноважень про допуск до особових рахунків; зміна повноважень, перерозподіл функцій і рахунків для обробки між працівниками банку, зміна відповідального виконавця, що веде рахунок, та ін.
Протягом дня відповідними блоками ОДБ виконуються операції по реєстрації нових клієнтів, відкриттю або закриттю рахунків і забезпеченню вводу первинних платіжних документів клієнтів та їх обробки. Прийняті від клієнтів документи розподіляються на «внутрішні», у яких платник і одержувач є клієнтами даного банку, та «міжбанківські», у яких одержувачем є клієнт іншого банку. На основі першої групи документів виконуються внутрібанківські проводки (тобто здійснюється зміна залишків на рахунках), а на основі другої формуються файли типу А (початкові міжбанківські платежі для їх передачі в СЕП). Проводка «оплата» виконується тільки у випадку, якщо вона не приводить до ситуації «червоне сальдо» по одному із кореспондуючих рахунків.
Блоки закриття ОДБ забезпечують перевірку наявності балансу, формування та видачі відомостей по накопичених оборотах за місяць (квартал, рік), створення копій основних файлів, архівацію платіжних документів, видачу вихідних форм про обороти за день, формування, архівацію і друкування виписок. Залежно від дня, місяця, кварталу, року блоки закриття формують звітність для НБУ, а також інформацію для податкових органів та інших служб.
Крім функціональних блоків ОДБ містить і блоки ведення та друкування довідково-нормативної інформації, блоки «відновлення» («відкатів»), тобто виконання перерахунків з певного моменту часу. Як правило, є «коротке» і «довге» відновлення. Різниця між ними полягає в тому, що «коротке» використовується для виправлення помилок лише по тих документах, які ще не відправлені в СЕП. Воно може використовуватися і у випадку отримання «відбійної» квитанції на якийсь раніше відправлений файл А. Суть «довгого» відновлення полягає у відтворенні ситуації на момент закриття будь-якого минулого дня з послідовним перерахуванням усіх операцій наступних днів.
До головного меню кожного конкретного пакета ОДБ включені основні технологічні функції — підсистеми, перелік яких не задається нормативними документами, а тому є оригінальним у програмному комплексі ОДБ кожного розробника.
У головному меню ОДБ, як правило, основні технологічні функції закріплені за робочими місцями операціоніста, контролера, технолога та адміністратора БД.
Робоче місце операціоніста є ключовим у банківській інформаційній системі, оскільки тут виконуються головні операції з обробки оперативної інформації, зокрема ввід платіжних документів, оперативний контроль за виконанням операцій, переведення вкладів, робота з картотеками, контроль за неоплаченими документами, огляд і роздрукування виписок із особових рахунків і т.ін.
Технологія вводу інформації полягає в тому, що операціоніст переносить реквізити з кожного банківського документа через екранну його форму у вхідний файл. Перед вводом записується номер пачки, який під час наступних операцій вводу автоматично збільшується на одиницю. У процесі вводу номера рахунка перевіряється його наявність у файлі особових рахунків, а з файла довідника клієнтів вибираються необхідні дані про клієнта. За тією самою технологією вводяться дані про одержувача для внутрішніх документів. Вводячи міжбанківські документи, перевіряють МФО на наявність банку-одержувача в довіднику та на можливість існування в ньому заданого особового рахунка. Сума документа вводиться двічі — це елемент технології, за допомогою якого контролюється правильність вводу. Водночас висвітлюються прогнозні залишки на рахунку — залишок після оплати цього документа. На стадії вводу інформації виокремлюють такі макети (типи вхідних потоків) даних: платежі, що проходять через кореспондентські рахунки; платежі, що проходять через касу банку; внутрішні проводки банку, що відображають розрахункові операції між двома клієнтами банку; видавання й погашення позик; виправлення помилок тощо.
Робоче місце контролера передбачається не в усіх пакетах ОДБ. У деяких пакетах на практиці функції контролера включені до меню на АРМ операціоніста чи на АРМ технолога, де здійснюється програмний та технологічний контроль. Традиційно на АРМ контролера дублюються функції операціоніста з вводу інформації та обробки. На АРМ контролера можуть бути покладені й інші функції, наприклад регулювання послідовності надходження початкових міжбанківських документів до регіонально-розрахункової палати (оплата документів дозволяється або забороняється шляхом їх блокування).
Робоче місце технолога включає найширший перелік технологічних функцій, які можна поділити на щоденні та періодичні з формування звітності за відповідний період часу.
Щоденні функції такі.
1. Вилучення документів попереднього операційного дня з бази оперативних даних.
2. Відкриття ОДБ, під час якого програмний комплекс створює копії файлів вхідного сальдо за аналітичними рахунками й балансом, які використовуються протягом операційного дня; нагромаджує процентні числа за попередній день, якщо є рахунки з процентними ставками; установлює поточну дату; очищує нагромаджувальні обороти за попередній день і т.ін. Перелік робіт, які виконуються при відкритті ОДБ, як правило, задається у певному файлі і може коригуватися.
3. Контроль за вводом документів на робочих місцях. Документи, що вводяться операціоністами, розміщуються у вхідних файлах, а після закінчення вводу документів на них формується статистика вводу — здійснюється контрольна перевірка правильності і повноти введених документів. Якщо перевіркою не виявлено помилок, то вхідний файл буде автоматично дописаний до головного файла оперативної інформації. Технолог обов’язково контролює, чи з усіх робочих місць надійшли документи перед закриттям операційного дня.
4. Обробка документів операційного дня здійснюється спеціальною програмою, яка в більшості ОДБ має власну назву «Оплата». Програма «Оплата» виконує проведення (змінює залишки на рахунках) за внутрішніми документами, які було введено операціоністами чи отримано через підсистему «Клієнт—банк», за початковими міжбанківськими, а також за зворотними міжбанківськими документами, прийнятими через АРМ НБУ. Програма «Оплата» може виконуватися в інтерактивному та автоматичному режимах. Інтерактивний режим передбачає запуск програми через визначений інтервал часу і нагромадження певної кількості неоплачених документів у головному файлі оперативної інформації. Якщо задано режим «автоматично», то система після кожної зміни меню автоматично запускає програму «Оплата». Під час виконання програми виконуються такі операції:
обробка файла «Динамічний стан коррахунка» і видання на екран інформації про стан LORO- і NOSTRO- коррахунків;
зчитування з АРМ НБУ файлів зворотних міжбанківських платежів, запис їх до файла оперативної інформації та формування і передача у зворотному напрямі квитанцій про прийняття та обробку цих файлів;
власне оплата документів — залишки на рахунках змінюють, заносячи до запису позначку «Оплачено». У разі наступних запусків програми «Оплата» ці документи вже не оплачуватимуться;
вибір оплачених міжбанківських документів і компонування їх у файл для засилання в АРМ НБУ, а також занесення потрібних позначок до відповідного запису основного файла оперативної інформації;
опрацювання квитанцій за відправленими та прийнятими платіжними повідомленнями. Якщо за деякими документами приходить відбійна квитанція, то система автоматично переводить документ у розряд невибраних;
формування протоколу несплачених документів із зазначенням причин несплати.
5. У разі виявлення помилки в сплачених документах їх виправляють так: усі документи у файлі оперативної інформації переводяться до стану несплачених, поновлюється вхідне сальдо з урахуванням заново відкритих рахунків, виправляються помилки (сторно-проводки) і здійснюється процедура «Оплата».
6. Закриття операційного дня полягає у виконанні певних інформаційно-нагромаджувальних робіт і створенні в пам’яті ЕОМ і на дисках копій файлів. Ці роботи виконуються суворо за списком, заданим у спеціальному файлі. Запуск пункту «Закриття ОБД» супроводжується послідовним виконанням таких дій: перевірки наявності балансу; нагромадження денних оборотів за балансовими рахунками в БД; нагромадження інформації за касовими проведеннями дня, включення виписок за особовими рахунками в архів, нагромадження плати за розрахунково-касове обслуговування, формування звітного файла Z і т.ін. Після виконання цих програм на монітор видається повідомлення про ситуацію на кінець робочого дня в інформаційній системі банку.
Робоче місце адміністратора БД забезпечує виконання важливих функцій у системі, а саме поточної роботи з документами, ведення фонду нормативно-довідкової інформації, установлення й конфігурування робочих місць користувачів, виконання «відкатів» у системі, переведення файлів операційного дня в «архівні». На практиці не завжди суворо додержують єдиного визначення функцій для АРМ адміністратора БД, і такі функції по-різному розподіляються між технологом і адміністратором. Адже програмно-технологічний комплекс ОДБ дає змогу комплектувати перелік функцій на кожне АРМ системи.
Адміністратор БД виконує поточну роботу з документами, підтримуючи в робочому стані файли оперативної інформації, які містяться в центральній БД. Серед них головним є файл платіжних документів, до якого входять такі реквізити: номер макета; номер пачки; номер робочого місця; МФО банку-кореспондента; номер документа; особовий рахунок за дебетом; особовий рахунок за кредитом; сума за документом, а також технологічні реквізити. Крім того, до переліку реквізитів включаються дані, що характеризують стан електронного документа, вказуючи на те, чи виконаний документ перебуває в черзі на здійснення інших технологічних процедур. Зазначений файл протягом дня можна коригувати, поповнюючи чи вилучаючи записи, або використовувати для довідок.
У центральній БД формується й підтримується впродовж дня ще й файл залишків коштів на рахунках (сальдо), який включає такі реквізити: код виконавця за рахунком; ознаку щодо того, активний чи пасивний рахунок; номер особового рахунка; залишок на рахунку; суму дебетових оборотів за день; суму кредитових оборотів за день; символ звітності; процентну ставку і т.ін. Цей файл є основним для формування бухгалтерської та статистичної звітності. Інші файли оперативної інформації формуються на функціональних АРМ і при потребі пересилаються до центральної БД.
Інша важлива функція, що її закріплено за АРМ адміністратора БД, полягає у веденні фонду нормативно-довідкової інформації (НДІ). Відповідні файли формуються в центральних БД, а для використання передаються на локальні АРМ. Нормативна інформація записується у файли двох типів. Перший містить тексти нормативних актів, до яких звертаються спеціалісти за довідками, а другий включає нормативні показники, потрібні для роз-рахунків.
Окрему групу файлів НДІ становлять довідники. Вони поділяються на загальнодержавні, відомчі та внутрішньобанківські (локальні).
До загальнодержавних належать довідники форм власності, видів економічної діяльності, країн світу, валют і т.ін.
До складу відомчих довідників належать: реєстр банків, реєстр учасників СЕП; перелік регіональних розрахункових палат, перелік коррахунків, план рахунків; перелік звітних файлів; типи особових рахунків; видів кредитів; кодів платежів; видів документів, схем надання даних і т.ін.
До внутрішньобанківських довідників відносяться: перелік клієнтів; структура банку; види послуг із розрахунково-касових операцій, символи касових операцій, перелік статусів документів у системі тощо.
Електронні документи у файлах НДІ можна доповнювати, коригувати, вилучати та виконувати з ними інші процедури. Дозволяється це робити не всім користувачам, а лише тим, за якими адміністратор БД закріпив ці функції на їхньому робочому місці. Крім того, зазначені процедури можуть бути доступні користувачеві згідно з відповідним паролем.
У разі розмежування доступу до даних кожний важливий їх розділ може бути додатково захищений від несанкціонованого доступу кодуванням окремих ключів за допомогою процедури управління ключами. Отже, на кожному робочому місці в банківській системі встановлюється певна ієрархія функцій для користувача.
Серед усіх технологічних процедур особливе місце посідає технологія повернення системи до минулого стану в рамках операційного дня, тобто «відкату» в системі. До нього звертаються в тому разі, якщо необхідно змінити виконану банківську операцію, наприклад через помилку, якої припустилися. Адміністратор БД вилучає документ із помилкою, записує у файл правильний документ і запускає систему, починаючи з уведення вхідного балансу.
Наприкінці робочого дня, після складання щоденного балансу за допомогою пакета програм «АРМ статистичної звітності» формуються звітні файли і засобами електронної пошти надсилаються до НБУ.
Після закриття операційного дня адміністратор БД або технолог системи виконують процедури занесення оперативної інформації до архіву. Архівні файли, у разі потреби, можна читати і використовувати для складання звітів або формування довідок за запитами але ні в якому разі не змінювати.
Зауважимо, що для обробки банківської інформації крім технологічних застосовуються й функціональні АРМ, призначення яких розглядається далі.
Розрахункові та касові операції належать до основних, найбільш трудомістких та відповідальних у банківській діяльності. Тому для виконання цих операцій завжди насамперед застосовувалась обчислювальна техніка. Сьогодні в банківських інформаційних системах комплекс розрахункових і касових операцій становить підсистему, головне призначення якої — автоматизувати проведення (виконання) розрахункових і касових операцій, їх облік, контроль і складання звітності про рух коштів на рахунках клієнтів та балансових рахунках банку.
Згідно з призначенням такої підсистеми виконуються функції: відкриття особових рахунків, їх перегляд, доповнення й коригування, введення та обробка первинних платіжних документів, формування довідкової фінансової та технологічної інформації про стан особових рахунків через такі процедури, як блокування особового рахунка на встановлений термін, вилучення закритих рахунків, перепризначення відповідального виконавця, котрий веде цей особовий рахунок, виконання операцій з визначення та зміни залишків коштів на особових і балансових рахунках.
Особовий рахунок являє собою аналітичний реєстр бухгалтерського обліку руху грошових коштів у банку, правила виконання операцій з якими задаються нормативними документами НБУ. Кожний особовий рахунок відкривається за відповідним балансовим рахунком. Номер особового рахунка включає в себе чотиризначний код балансового рахунка (АААА), ключовий розряд (В) і не більше дев’яти знаків аналітичного рахунка (ЕЕЕЕЕЕЕЕЕ). Тобто номер особового рахунка може мати не більше 14 знаків, а його структура має такий вигляд: ААААВЕЕЕЕЕЕЕЕЕ. Типове значення сегмента (Е) включає в себе характеристику контрагента — один знак, порядковий номер рахунка контрагента (клієнта) — два знаки і код клієнта — шість знаків.
У коді балансового рахунка перший знак задає клас, перші два — розділ і три — групу рахунка. Він є обов’язковою складовою номера особового рахунка. Це дає змогу отримувати суми оборотів та залишків на балансових рахунках на основі даних особових рахунків, які відносяться до заданого балансовогорахунка.
Для автоматизації розрахунково-касових операцій і контролю за їх здійсненням створюють автоматизовані робочі місця (АРМ): операціоніста, контролера, технолога, бухгалтера, касира. Кожне з перелічених АРМ має різний набір функцій, різний рівень доступу до бази даних. Так, головний бухгалтер має у своєму розпорядженні найповніший перелік функцій: відкриття, закриття та вилучення особових рахунків, внесення змін до їх реквізитів тощо.
Інформаційну базу (ІБ) розрахунково-касових операцій утворює сукупність певним чином структурованої (як документи чи файли) інформації, використовуваної під час виконання завдань підсистеми. Всю наявну ІБ поділяють на зовнішню та внутрішню.
Зовнішня ІБ — це сукупність вхідних повідомлень — документів та файлів, що надходять від клієнтів даного банку, інших комерційних банків, державних структур, різних юридичних і фізичних осіб. До них належать платіжні доручення, грошові чеки, векселі, меморіальні ордери, оголошення про внесення готівки, касовий план, реєстри платіжних документів тощо, файли платіжних доручень, що надходять від інших банків через систему міжбанківських електронних платежів НБУ (СЕП), систему міжнародних електронних платежів (СВІФТ) та від клієнтів банку через підсистему «Клієнт—банк».
Внутрішня ІБ як сукупність даних на машинних носіях, використовуваних для виконання завдань з обліку й контролю розрахунково-касових операцій, містить у собі файли з довідковою, оперативною та архівною інформацією. До файлів довідкової інформації належать довідники клієнтів банку, банків, балансових рахунків і операцій з коштами, довідники каси (довідник для складання форм звітності 747 і 748, а також довідник касових символів).
Файли оперативної інформації протягом робочого дня формуються або на підставі вхідних повідомлень, які надходять операціоністу у вигляді паперових чи електронних (по мережі) документів, або під час обробки оперативної інформації.
Наприклад, в ОДБ «УНІТА-БАРС» це такі файли: OPER — оперативні документи дня за балансовими рахунками у гривнях; OPERV — те саме у валюті; OPERN — те саме за позабалансовими рахунками; SALDO, SALDOVІ, SALDONB — залишок і рух коштів на рахунках відповідно в гривнях, у валюті та за позабалансовими рахунками.
Архівні файли — це файли результатної інформації, сформовані після складання балансу та записані в архів. За допомогою файлів довідкової, оперативної та архівної інформації виконуються завдання з обліку та контролю розрахункових і касових операцій.
3.2. Автоматизація внутрібанківських розрахункових операцій
Автоматизація розрахункових операцій виконується за допомогою програмного комплексу ОДБ, який дає змогу в будь-який момент його функціонування дістати інформацію про рух коштів на поточних, кредитних, депозитних та інших рахунках. Залежно від конструктивних характеристик програмного комплексу ОДБ автоматизація проведення розрахункових операцій їх обліку і контролю здійснюється в національній валюті та валюті інших країн в одному або в двох окремих ОДБ. У більшості програмних пакетів ОДБ передбачається, що головними виконавцями автоматизації розрахункових операцій є операціоністи, контролери, технологи. Для них у банківській системі створюються відповідні АРМ (робоче місце контролера є не в усіх банках). Конкретний перелік операцій для кожного АРМ залежить від запровадженого технологічного процесу, наявності технічних засобів, обсягу документообороту тощо. Слід відмітити, що деякі роботи жорстко прив’язані до виконавців.
При автоматизації розрахункових операцій у банківських установах вирізняють операції введення первинних платіжних документів (ППД) та формування відповідних файлів ППД і, власне, розрахункові операції, тобто операції оплати, які приводять до зміни стану залишків і оборотів на відповідних особових і балансових рахунках.
Одна із широко розповсюджених технологій автоматизованого виконання розрахункових операцій передбачає, що перші операції виконуються на АРМ операціоністів або операторів, з підключенням АРМ контролера, а другі операції виконуються, як правило, на АРМ технолога. При такій технології на АРМ операціоніста, оператора і контролера не можна змінити стан рахунків. Він може бути змінений тільки з АРМ технолога. При цьому операції введення даних і їх обробки розділені в часі, що дає можливість управляти в банкові протягом операційного дня процесом оплати та рухом коштів.
Інша технологія передбачає, що операціоніст виконує не тільки ввід даних і формування файлів ППД, а і в інтерактивному режимі проводить їх обробку. Тобто він має безпосередній доступ до всіх даних особового рахунка і виконує операції оплати.
Технологічний процес автоматизації розрахункових операцій здійснюється за допомогою програм, які об’єднані у модуль із назвою «Особові рахунки». Цей модуль перед його запуском налагоджують, виконуючи такі дії:
визначають кориговані параметри особових рахунків, такі як термін зберігання закритих особових рахунків, надання дозволу на коригування вхідних залишків на особових рахунках і т.ін.;
установлюють повноваження стосовно допуску співробітників банку до особових рахунків;
визначають типи особових рахунків, необхідних для податкової адміністрації;
закріплюють за особовими рахунками процентні ставки.
Базовою функцією під час автоматизації розрахункових операцій є відкриття нових особових рахунків. Виконує її головний бухгалтер або за його дорученням провідний технолог через меню системи ОДБ. Увійшовши до пункту меню «Особові рахунки», переходять до пункту «Відкриття особових рахунків». При цьому зазначають (задають) такі реквізити: тип особового рахунка, який вибирається з переліку, що відкрився за допомогою функціонального клавіша; рівень секретності рахунка, що задається обмеженнями доступу до нього; вид валюти рахунка, який вибирається курсором з висвітленого на екрані переліку; реєстраційний номер клієнта в банку; номер балансового рахунка; номер особового рахунка клієнта; назва особового рахунка, дата відкриття; підстава для відкриття рахунка; тип особового рахунка для податкової адміністрації; ознаки звітності; ознаки для розрахунку платежів за розрахунково-касове обслуговування; код відповідального виконавця, операціоніста; нарахування процентів за залишки.
Супроводження особових рахунків виконується на робочих місцях відповідальних виконавців-операціоністів і технолога. Крім відповідальних виконавців доступ до особових рахунків з різними повноваженнями мають працівники валютного відділу, каси, головний бухгалтер та керівники служб банку. Усім зазначеним працівникам доступна функція перегляду особових рахунків, виконувати яку можна по-різному.
Найчастіше переглядається окремий особовий рахунок, для чого насамперед входять до меню другого рівня (пункт «Перегляд особових рахунків»). Перш ніж увійти в цей режим, необхідно в екранному вікні набрати номер рахунка.
Функція перегляду особових рахунків дає змогу:
переглянути реквізити рахунка, зокрема номер балансового рахунка, тип рахунка, його призначення та інші довідкові ознаки;
визначити оперативний стан особового рахунка, а саме: вхідний залишок, поточні обороти коштів, вихідне сальдо рахунка.
Для роботи з окремим особовим рахунком до меню другого рівня включений пункт коригування, що надає такі можливості:
змінити відповідального виконавця, що веде рахунок;
установити чи зняти блокування з особового рахунка;
змінити тип рахунка при зміні статей плану рахунків або коду валюти;
закрити особовий рахунок, зазначивши дату та підстави для його закриття.
Перегляд списку особових рахунків, закріплених за даним балансовим рахунком як режим меню, дає змогу:
дістати впорядкований за заданою ознакою список особових рахунків, в якому зазначено номер рахунка, ім’я клієнта, поточне сальдо й обороти коштів;
головному бухгалтеру банку дістати інформацію про стан балансового рахунка (вхідний залишок, поточні обороти, вихідний залишок), а також дату останньої модифікації рахунка;
вивести на друкування або занести до файла список особових рахунків.
У режимі перегляду списку особових рахунків є можливість переглянути список особових рахунків, на яких обліковується валюта. При цьому програмні засоби забезпечують отримання списку особових рахунків, упорядкованих за заданими ключовими ознаками, а також вибір окремого рахунка та видачу щодо нього всієї поточної інформації.
Перегляд історії особових рахунків здійснюється після входження до меню з такою самою назвою. Наступний рівень меню дає змогу користувачеві вибрати балансовий чи позабалансовий рахунок. Увійшовши до пункту меню «Вид рахунка», користувач може послідовно задати з клавіатури номери балансового й особового рахунків, за якими він отримує на екрані розшифрування руху коштів. Таке розшифрування можна дістати за вказаний день або період.
Перезакріплення особових рахунків — заміна одного відповідального виконавця на іншого здійснюється на АРМ адміністратора БД і головного бухгалтера. Тут можна перепризначити один або кілька особових рахунків, деяку групу або всі балансові рахунки.
Виконання розрахункових операцій, тобто обробка платіжних документів та зміна величини сум залишків і оборотів на відповідних особових рахунках здійснюється шляхом запуску відповідної програми. Програма може запускатися як безпосередньо користувачем через відповідний пункт меню, так і в автоматичному режимі при виконанні певних умов, наприклад, через відповідний (заданий) інтервал або в певні моменти часу, наявності певної кількості необроблених ППД та ін.
Розрахунок процентів за залишками на особових рахунках і сум для сплати клієнтами за розрахунково-касове обслуговування здійснюється за двома варіантами технологій.
Варіант 1-й передбачає, що процентні ставки фіксуються у файлі-довіднику типів особових рахунків і не залежать від розміру залишків коштів на рахунках.
Суму процентів для сплати j-му клієнтові за р-й розрахунковий період обчислюють згідно з таким алгоритмом:
, (4.1)
де Sjpd — сума залишку коштів на особовому рахунку j-го клієнта за d-й день р-го розрахункового періоду; Nd — процентна ставка на d-й день.
Для машинного виконання алгоритму (4.1) сума залишку вибирається з файла особових рахунків, а процентна ставка задається в довіднику типів особових рахунків або в спеціальному файлі, створеному для цього розрахунку.
Варіант 2-й машинного розрахунку процентів також виконується за алгоритмом (4.1), але процентна ставка вибирається з довідника відповідно до діапазону сум залишків коштів на рахунку. При цьому проценти визначаються за середньодобовий залишок грошових коштів на особовому рахунку.
За результатами розрахунку складається меморіальний ордер, на підставі якого інформація заноситься до БД, а далі передається клієнтам у формі виписки з рахунка.
Аналогічно до розрахунку процентів за залишками на особових рахунках визначаються суми, що їх мають сплатити клієнти за розрахунково-касове чи інше обслуговування. Загальна методика й алгоритми лишаються незмінними, але інформаційна база формується за іншими ознаками.
Наприклад, базова сума Sjpd для розрахунку за касове обслуговування формується як сума касових оборотів на підставі записів відповідного файла, а процентна ставка вибирається з файла-довідника або задається користувачем.
Для виконання розрахунку процентів потрібні програми об’єднуються у програмний модуль, підключення якого здійснюється через відповідний пункт меню, який розкривається, як правило, такими підпунктами: «Історія процентів», «Ввід із файла», «Зміна процентів за балансовими рахунками», «Нарахування процентів», «Формування відомості нарахованих процентів», «Календар розрахунково-касових операцій».
За допомогою першого пункту меню «Історія процентів» підключаються програми, які виконують введення і коригування процентних ставок. Входячи в цей режим, слід задати номер рахунка, для якого встановлюється чи коригується процентна ставка; тип валюти (іноземна/національна), діапазон дат вводу (перегляду, коригування) процентної ставки. Зміна вноситься в поле «Тип процентної ставки» довідника типів особових рахунків. Форма документа на екрані дає змогу вводити одну процентну ставку або діапазон сум. Якщо потрібно вилучити окремий запис із процентною ставкою, цей запис слід позначити, а потім вилучити за допомогою клавішів, вказаних в інструкції користувачеві.
Змінити процентні ставки за даним рахунком можна також, не вводячи інформацію з клавіатури, а використовуючи відповідний файл. Ця процедура виконується за допомогою пункту меню «Ввід із файла». При цьому на моніторі показується діапазон дат для нарахування процентів. Якщо з’ясується, що для якогось особового рахунка вже введено процентні ставки в цьому діапазоні, то зміни в базі даних не виконуються, а всі виявлені помилки виводяться в протокол.
Сформувавши вхідні дані, виконують процедури нарахування процентів. При цьому режим розрахунку процентів дає змогу: обчислювати проценти за залишками на окремих особових рахунках або за групою рахунків, що мають процентні ставки за вказаний період часу; сформувати журнал розрахункових процентів, що використовуються далі для складання проводок про виплату процентів; скласти відомість розрахунку процентів (за одним чи групою рахунків). На екрані заповнюються такі поля: інтервал дат, розрахунок за одним чи кількома балансовими рахунками, тип валюти, діапазон номерів балансових рахунків, номер особового рахунка.
Після заповнення всіх названих полів у нижній частині екрана з’являються інформаційні повідомлення про хід виконання процедур. Результати виконання розрахунків заносяться у відомість нарахування процентів, яка є основою для складання відповідних проводок про виплату процентів за залишками на рахунках. Деякі пакети програм ОДБ дозволяють обчислювати проценти за залишками на особових рахунках у пакетному й інтерактивному режимах. У разі використання інтерактивного режиму можна імітувати розрахунковий процес. Здобуті результати аналізують відповідальні виконавці, які приймають рішення щодо виплати процентів за залишками на особових рахунках.
В інтегрованих банківських інформаційних системах виокремлюють підсистему автоматизованого обліку вкладних операцій, яка має забезпечити автоматизацію оперативного та бухгалтерського обліку операцій про вклади фізичних осіб, комунальних, митних та інших платежів населення. Ці операції здійснюються на АРМ операціоніста, бухгалтера, технолога, а також на віддалених робочих місцях. Технологічний процес обліку вкладних операцій включає такі етапи: ведення довідників видів вкладів, типів особових рахунків, вкладників, банків, підприємств, контрагентів, операцій; ввід інформації про рух коштів вкладників (зарахування та списання); ведення особових рахунків вкладників; прийняття комунальних, митних та інших платежів від населення; складання видатково-прибуткових касових ордерів. Виконуються ці операції за тими самими технологіями, що й облік операцій на розрахункових рахунках. Окрім того, у режимі «Відправлення документів» інформація передається в БД ОДБ з віддаленого відділення чи робочого місця за допомогою підсистеми «Клієнт—банк».
Завершальною функцією модуля автоматизації розрахункових операцій є складання звітності, яка може видаватися на екран, до друку чи надходити по каналу зв’язку для передачі до НБУ. Звітна інформація формується у вигляді затверджених структур звітів, аналітичних таблиць та довідок, що є відповідями на запити.
До меню «Оперативні звіти» входять функції формування, перегляду й друкування вихідної інформації за такими формами щоденної бухгалтерської звітності банку: виписка з особового рахунка клієнта та оборотно-сальдова відомість. Виписка з рахунка видається у двох примірниках. Перший передається клієнтові як інформація про фактичний рух коштів на рахунку, а другий залишається в банку як архівний документ. На старті режиму отримання виписок необхідно зазначити період і тип звіту, тобто уточнити, чого саме стосується звіт: заданого особового рахунка чи всіх особових рахунків, закріплених за відповідним виконавцем.
Під час формування вихідного документа залишок коштів на рахунках визначається згідно з алгоритмом:
, (4.2)
де Shr, Shrj, Shrk — відповідно залишок, надходження та витрати коштів за h-й період за r-м рахунком згідно з j-м прибутковим чи k-м видатковим документом.
Фінансовий стан банку відображають оборотно-сальдова відомість і оборотно-сальдовий баланс. Відомості формуються та видаються за особовими рахунками, закріпленими за відповідальним виконавцем або за всіма особовими рахунками банку на вказану дату. Процедуру складання оборотної відомості включено до інтерфейсу відповідального виконавця для видачі звіту за закріпленими рахунками та до інтерфейсу адміністратора БД для складання звіту за всіма особовими рахунками банку. Користувач має змогу сформувати документ на екрані для попереднього перегляду чи аналізу, а також для друкування наприкінці робочого дня.
Зауважимо, що оборотно-сальдова відомість може бути сформована і після закінчення операційного дня банку на підставі інформації, записаної в історії особових рахунків.
Оборотно-сальдовий баланс складається щодня на АРМ головного бухгалтера чи адміністратора БД. Він видається на екран або до друку (перед початком формування документа задаються параметри згідно з інструкцією для користувача). Розрахунки оборотів і вихідних залишків виконуються за тим самим принципом, що й при формуванні виписки з особового рахунка, тобто за аналогічним алгоритмом. При цьому обороти та залишки виводяться за балансовими рахунками четвертого порядку, а за рахунками третього та другого порядку нагромаджуються проміжні підсумки. До вихідної форми заносяться такі реквізити: вхідні залишки, дебетові та кредитові обороти, вихідні залишки в розрізі номерів особових рахунків, залишки й обороти номерів балансових рахунків; підсумок оборотів і залишків за кожним класомрахунків.
Крім зазначених документів через меню модуля розрахункових операцій можна сформувати й інші зведені та довідкові внутрішні документи, наприклад, відомість відкритих і закритих особових рахунків, відомість залишків на особових рахунках і т.ін.
За розрахунковими операціями кожний комерційний банк звітує перед НБУ. Щодня на підставі БД ОДБ формується звітний файл №1 — дані про залишки на рахунках, який передається за схемою: КБ —РУ, РУ — ЦРП. Файл №1 за змістом відповідає звіту 1Д — КБ — баланс комерційного банку.
Наприкінці місяця КБ передає до НБУ файл №2 — дані про обороти та залишки на рахунках, який відображає зміст звіту1—КБ — баланс комерційного банку. КБ передає до НБУ один раз на рік або за вимогою файл №15 — дані про кількість клієнтів, що відображено формою 752 звітності.
3.3. Автоматизація касових операцій банку
Автоматизована обробка касових документів з огляду на їхню специфіку виокремлена у відповідний модуль програмно-технологічного комплексу ОДБ. В основу технології автоматизованого опрацювання касових операцій покладено такий принцип — відповідальний виконавець з контролю за рухом коштів на особовому рахунку клієнта під час вводу касових документів перевіряє наявність особового рахунка, виявляє ознаки заблокованості чи закриття рахунка, наявності на ньому коштів. У момент прийому чи видачі готівки касир на своєму робочому місці виконує операцію «Оплата», заносячи відповідний запис до робочого файла, де фіксуються зміни залишків коштів на рахунках. Скоригувати чи вилучити документ можна лише до моменту виконання операції «Оплата». У разі відповідного налагодження системи зазначена операція може виконуватися також із інтерфейсу технолога. Модуль «Каса» функціонує за такими режимами: прибуткова каса, видаткова каса, вихідні форми, регламентні роботи, об’єкти інкасації.
Зауважимо, що в меню «режими» спочатку вказуються процедури, які виконуються найчастіше, а далі наводяться ті процедури, до яких протягом дня звертаються лише один чи декілька разів.
Для виконання режимів автоматизованого обліку операцій з готівкою слугують: АРМ касира, АРМ відповідального виконавця, АРМ бухгалтера, АРМ адміністратора БД. Залежно від повноважень користувача й згідно з паролями доступу до заданого АРМ включаються різні пункти меню. Але при цьому насамперед виконуються регламентні роботи. До них належать:
роботи, виконувані в разі інсталяції модуля та в аварійних ситуаціях (ініціалізація файлів БД з касовими документами, ініціалізація журналу регламентних робіт, зміна стану модуля, зберігання документів поточного дня);
роботи, виконувані протягом поточного операційного дня (відкриття дня за касою, поповнення документів поточного дня, закриття дня за касою з архівацією касових документів, огляд журналу регламентних робіт);
регламентні роботи з архівними касовими документами (наприклад, перегляд касових документів з архіву).
Ініціалізація касових файлів — це та операція, за допомогою якої адміністратор БД очищає всі касові документи в разі інсталяції модуля «Каса» або під час аварійних ситуацій. У машинному журналі регламентних робіт ведеться протокол усіх дій, виконаних у цьому режимі із зазначенням дати, часу здійснення операції і табельного номера особи, котра виконала цю операцію. Журнал регламентних робіт можна переглядати і при потребі ініціалізувати.
До регламентних робіт, які виконуються щодня, належать відкриття і закриття дня каси. Ці режими запускаються з робочих місць відповідального виконавця та адміністратора БД. При цьому послідовно виконуються перевірки, аби встановити, чи не ведуться регламентні роботи, чи відкритий операційний день банку. Окрім того, під час відкриття каси перевіряється дата відкриття, яка не повинна повторюватися, а під час закриття виконуються додаткові перевірки й процедури обробки інформації. З’ясовується зокрема, чи коректні файли касових документів (усі документи мають бути оплачені, зареєстровані в касових журналах, їх символи мають відповідати шаблонам за структурою), чи коректно відкрита каса, чи наявні касові документи. Якщо документів немає, то каса закривається, але архів не створюється. Закриття каси передбачає, що в журналі регламентних робіт фіксується, коли й хто закривав касу, та наводяться контрольні суми, а спеціальна програма записує в архівну БД поточні файли (ці процедури виконуються автоматично). Зрештою на екран виводиться повідомлення про результати виконання програми із закриття каси.
Режими регламентних робіт дають змогу прочитати касовий документ із архіву за будь-який день роботи каси, але тільки після закриття дня за касою.
Робота відповідального виконавця (бухгалтера) з касовими документами зводиться до виконання ряду процедур, що пропонуються користувачеві на екрані. Виконання підпрограми може супроводжуватися допоміжними процедурами, які забезпечують коректність технології та достовірність результатів обробки вхідних даних. Так, після створення відповідальним виконавцем одного чи кількох касових журналів до них записуються касові документи. Основною процедурою в роботі відповідального виконавця з касовими журналами є введення документів у режимах «оприбутковування», «видатки» і «грошові перекази». Кожний документ задається в екранній формі з подальшим переліком реквізитів: тип (поодинокий, зведений), номер документа, особовий рахунок клієнта, сума за документом, код касової операції. До поля «Касир» заноситься табельний номер касира, а до поля «Бухгалтерська проводка» записується час оплати документа. Зміни до особових рахунків вносяться не тоді, коли касовий документ записується в журнал, а під час виконання процедури «Оплата документа».
Робота касира з касовими документами виконується в режимах «Прибуткова каса» або «Видаткова каса» за допомогою процедури «Оплата документів». Касиру пропонується екран зі списком ще не сплачених касових документів поточного дня, введених всіма відповідальними виконавцями на поточний момент часу. Обслуговуючи клієнта, касир вибирає рядок, тобто необхідний документ, і натисканням відповідного клавіша запускає програму оплати документа чи відмови від оплати. Підпрограма оплати документа виконує бухгалтерські проводки згідно з кодами рахунків і видами операцій з готівкою, а також фіксує ці зміни у відповідних машинних регістрах (бази даних) аналітичного обліку банківських операцій. У разі відмови касира оплатити документ в полі «Бухгалтерська проводка» в журналі відповідального виконавця з’явиться відповідна помітка, а в полі «Касир» — табельний номер касира. Виконавши процедуру «Оплата документа», касир видає клієнтові готівку, якщо операція видаткова, або квитанцію, якщо операція прибуткова. Касир повторює процедури оплати документів доти, доки на екрані не з’явиться повідомлення: «Немає документів для оплати». При цьому через деякий проміжок часу процедуру вибору документів пропонується повторити.
У режимі виконання операцій грошових переказів, тобто оформлення прийому готівкових коштів від клієнтів, рахунки яких відкриті в інших банках, відповідальний виконавець заводить або вибирає з існуючих касовий журнал грошових переказів. Документи за операціями грошових переказів вводяться так само, як і прибуткові та видаткові документи. Після правильного вводу документів натисканням відповідного клавіша запускаються програми, згідно з якими документ записується до касового журналу без проводки або з виконанням бухгалтерських проводок. Можливий і такий варіант, коли виконується бухгалтерська проводка і друкуються рядки журналу на принтері. У режимі грошових переказів формується меморіальний ордер, виконується проводка транзитного переказування коштів до інших банків і нараховуються суми сплати за банківські послуги.
Банки організовують іноді виносні каси, функції яких також автоматизуються. Робота виносних кас автоматизується таким чином.
1. Програмно-апаратний модуль забезпечує автоматизацію обліку готівкових коштів на робочому місці касира.
2. По каналу зв’язку системи «Клієнт—Банк» передаються меморіальні ордери проводок виносної каси.
3. Відповідальний виконавець приймає ці меморіальні ордери й здійснює операцію «Оплата».
4. Адміністратор БД кілька разів протягом дня та перед закриттям виконує регламентні роботи, створюючи та доповнюючи при цьому касові журнали роботи виносних кас. Такі журнали виносних кас включають в архів касових документів, а надалі використовують під час формування касових звітів.
У режим «Вихідні форми» включаються процедури зі складання, перегляду та друкування щоденних оперативних форм звітності. Технологія виконання цих процедур передбачає введення дати, на яку формуватимуться звітні форми, а також утворення робочого файла. Користувачеві пропонується для вибору список таких вихідних форм: прибутковий касовий журнал, видатковий касовий журнал, довідка касира з прибутків, довідка касира з видатків, зведена довідка про касові обороти, довідка щодо видів касових операцій, довідка щодо БД каси, перелік неоплачених і сторнованих документів. Окрім того, інформаційна система формує звітні файли стосовно прогнозу готівкового обігу та касових оборотів. Прогноз готівкового обігу розробляється на підставі файлів, які формуються згідно з касовими заявками, прогнозними розрахунками, що надходять від підприємств і установ, а також архівними даними за попередні періоди. Результати обробки інформації видаються як прогнозні розрахунки касових оборотів (форма 720-н), календар видачі готівки на заробітну платню (форма 729-н) і т.ін. Звіти про касові обороти складаються на підставі файлів оперативної інформації БД ОДБ. Результати обробки інформації формуються у звітні файли: №12 — дані про касові обороти символів форма 747Д, №13 — дані про касові обороти символів форми 778. Ці звітні файли передаються комерційним банком до регіонального управління НБУ.
3.4. Автоматизація обліку та регулювання валютних операцій
Валютні операції відіграють важливу роль у діяльності банківських установ. Вони здійснюються в «Укрексімбанку», у комерційних банках та їх філіях, на міжбанківській валютній біржі та в інших фінансових установах. Контролюють і регулюють операції з валютою структурні підрозділи НБУ. Щоб підвищити ефективність роботи зазначених підрозділів і оперативність обліку валюти, уникнути помилок, а також мати змогу діставати необхідну інформацію для контролю та приймати рішення під час регулювання валютних операцій, у ІБС виокремлюють підсистему «Валюта». З її допомогою облік операцій з іноземною валютою можна організувати так, що за кожним кодом валюти та кожним клієнтом відкривається окремий особовий рахунок. За вільно конвертованими валютами клієнтам банку може бути відкрито один мультивалютний рахунок.
Важливою особливістю зазначеної підсистеми є те, що одночасно із занесенням до регістрів бухгалтерського обліку валютних документів відображається проведення за рахунками гривневого покриття в національній валюті згідно з курсом на початок операційного дня. Це дозволяє на будь-який час отримати консолідований баланс, що включає суми на рахунках гривневого покриття як еквівалент валютних коштів, що перебувають у банку.
На практиці існують два підходи до організації автоматизованого обліку валютних операцій. Перший полягає в тому, що валютні операції обліковуються протягом дня за допомогою окремого програмного комплексу ОДБ, а наприкінці дня формується консолідований баланс. Другий, більш прогресивний підхід полягає в тому, що рух коштів у національній та іноземній валютах обліковується за допомогою одного ОДБ. Згідно із цим підходом обробляють інформацію в банківських системах розвинених країн. У такому разі в пакеті ОДБ усі програми з обслуговування особових рахунків і формування звітності працюють для підрахування національної та іноземної валюти. Технологію використання таких програм наведено в підрозділі 4.1. Крім того, в ІБС є ряд засобів, які призначені виключно для роботи з іноземною валютою. Вони здебільшого підпорядковані в ієрархії меню пакета ОДБ пункту «Валютні операції», куди, як правило, входять такі підпункти:
нормативно-довідкова інформація щодо валюти;
введення, оплата, пошук і редагування валютних документів;
автоматизація обліку операцій в обмінних пунктах;
котирування (переоцінювання залишків на валютних рахунках у разі зміни курсів валют);
нарахування процентів за валютою;
засоби для інсталяції та спеціальні регламенти за валютними операціями;
нагромадження даних і формування вихідних форм за валютою.
Зазначені функції в ІБС виконуються за допомогою таких автоматизованих робочих місць: АРМ операціоніста, АРМ технолога чи адміністратора БД, АРМ касира, АРМ бухгалтера, АРМ спеціаліста валютного відділу, АРМ керівників. Залежно від організаційної структури банку для кожного АРМ компонується конкретний набір функцій.
Зауважимо, що на окремі АРМ можуть виводитися завдання обробки даних про валюту, які не введені до головного меню. Наприклад, на АРМ фахівця валютного відділу виконуються завдання визначення попиту (та пропозиції) на валюту і т.ін. В ієрархії меню функції наводяться в тій послідовності, в якій найчастіше до них звертаються, а вивчати їх доцільно в послідовності, яку закладено в технології виконання.
Першим етапом у технології є налагодження керуючих параметрів підсистеми, виконуване для встановлення режимів роботи в підсистемі «Валюта». Початкове значення параметрів завантажується в БД під час установлення програмних модулів.
У разі закритого ОДБ параметри змінюються через меню за ієрархією (ланцюжком) «Підсистема «Валюта»(«Параметри системи» ( «Налагодження системи». Перелік і зміст параметрів визначає розробник системи.
Нормативно-довідкова інформація щодо валюти вводиться, коригується і видається користувачеві через пункт меню «Довідник валют», котрий надає доступ до довідників валют, країн, курсів валют, банків, які працюють з валютою, платників і одержувачів коштів у форматі S.W.І.F.T., клієнтів, відкритих валютних особових рахунків, банківських операцій, балансових рахунків і т.ін. Технологія формування й підтримання зазначених довідників аналогічна застосовуваній під час обліку національної валюти.
Автоматизація обліку операцій в пунктах обміну валюти здійснюється за допомогою комп’ютера або касового апарата. Останній спосіб не є перспективним, тому розглянемо комп’ютерну технологію обробки даних у пунктах обміну валюти. Полягає вона в тому, що організується АРМ касира, перед упровадженням якого в пунктах обміну валюти налагоджується відповідна система. Перше входження до неї відбувається з використанням паролів адміністратора та податкового інспектора за замовчуванням. Далі вводять загальну інформацію фіскальної пам’яті та робочі параметри через пункт головного меню «Податковий інспектор» (підпункт «Загальні параметри»).
Загальну інформацію фіскальної пам’яті становлять заводський номер комп’ютера, заводський номер накопичувача на жорсткому диску, дата занесення номерів, реєстраційний номер комп’ютерної системи, дата реєстрації. Робочими параметрами системи є назва уповноваженого банку, номер і назва обмінного пункту, адреса обмінного пункту, дата початку роботи пункту. Надалі коригування наведених параметрів можливе після входження в систему через пароль податкового інспектора. Під час налагодження вводять також низку пускових параметрів, граничний розмір комісійних винагород і водночас формують довідники валют, підзвітних осіб, номери довідок та інкасаторських сумок. Коли систему налагоджено, касир може виконувати належні операції. Він входить до пункту головного меню «Операційний день», де в таблиці наведено перелік його функцій, зокрема відкриття операційного дня, введення курсів валют, авансування, підкріплення касира та інкасація валюти, обмінні операції, закриття операційного дня. Основною процедурою є обмінні операції: купівля та продаж валюти або обмін купюр. На моніторі касир вибирає вид операції, код валюти і вводить суму. Після цього на екран виводяться сума й назва валюти, що її касиру необхідно прийняти або видати. На принтері друкується довідка для клієнта.
Закінчивши роботу, касир закриває операційний день обмінного пункту і формує звіт через відповідний пункт меню. До розділу звітів входять реєстр проданої валюти, реєстр купленої валюти, реєстр обміну валюти, реєстр необмінних операцій (авансування, інкасації, підкріплення та передавання валюти), звіт касира, курс купівлі/продажу валюти. Вся звітна інформація записується в архів, звіт касира роздруковується і передається до банку.
Ввід, оплату, пошук і коригування валютних документів виконують засобами ОДБ. Вводить валютні документи відповідальний виконавець із пункту меню «Підсистема «валюта» («Ввід валютних документів»). Відповідна програма забезпечує виконання таких процедур: ввід і вхідний контроль валютних документів, установлення початкового статусу документа, запис документа в БД, друкування реєстру валютних документів.
Процедура «Оплата» валютних документів здійснюється технологом системи. Перед оплатою документа технолог може продивитись його реквізити та додаткову службову інформацію.В результаті виконання процедури «Оплати» змінюються залишки на валютних рахунках у масиві «Сальдо». При оплаті виконується проводка як в іноземній, так і в національній валюті.
Пошук і коригування електронних валютних документів здійснює відповідальний виконавець чи технолог системи. Якщо документ коригується до виконання з ним процедури «Оплата», то таке коригування полягає лише в зміні реквізитів документа, а коли змінюється зміст документа, з яким уже виконано процедуру «Оплата», то постає потреба змінити залишки на рахунках, скоригувавши основний оперативний масив за валютою та масив «Сальдо».
Котирування залишків на валютних рахунках виконується в разі зміни облікового курсу НБУ. Тоді переоцінюється лише гривневий еквівалент іноземної валюти, а сума на валютних рахунках лишається незмінною. Алгоритм розрахунку сум у національній валюті під час котирування грунтується на зіставленні суми, обчисленої за поточним курсом валюти, з фактичним залишком у національній валюті на даному рахунку. Бухгалтерська проводка складається на різницю цих сум. До алгоритму включено також процедури округлення сум. У процесі виконання котирування формуються записи за рахунками прибутків або збитків, на які заносяться фінансові результати. Результати обробки даних не лише записуються у файли, а й формуються у відомості котирування.
Нагромадження даних, формування вихідних (звітних) форм є найважливішим етапом технологій автоматизованого обліку й регулювання валютних операцій.
Нагромадження даних про валютні операції здійснюється протягом дня у БД обмінних пунктів, у файлах оперативної інформації, що формуються пакетом програм ОДБ у філіях чи головних банках. На підставі цих даних можна отримати відповіді на запити, а також аналітичні таблиці про поточний стан обігу валютних коштів, залишки коштів на валютних рахунках клієнтів та інші зведення. Наприкінці робочого дня, коли закрито пакет «Операційний день банку», оперативна інформація надходить до архівної БД і формуються бухгалтерські та статистичні зведення й звіти. Ці документи охоплюють інформацію за день або за деякий інший календарний період. Вони поділяються на внутрішні і зовнішні.
Внутрішні вихідні документи формуються на моніторах АРМ фахівців та керівників і при потребі роздруковуються. До таких документів належать зведення про купівлю/продаж валюти, інформація про рух і залишки коштів на валютних рахунках, реєстр ордерів валютного відділу, відомості про валютні ресурси тощо. Ці документи використовуються для аналізу валютних операцій і прийняття управлінських рішень.
Зовнішні вихідні документи передають клієнтам НБУ, податковій інспекції та іншим державним структурам. Вони спочатку видаються на монітор фахівців для аналізу, а далі надсилаються до відповідних структур у вигляді виписок з валютних рахунків для клієнтів, звітних файлів для НБУ чи звітних паперових документів або файлів для податкової адміністрації.
Виписки з валютних особових рахунків клієнтів формують щодня у двох примірниках, один з яких передається клієнтові, а другий залишається в банку як архівний документ. Кожна виписка включає такі реквізити: назва банку; дата і час формування звіту; номер особового рахунка; назва організації (власника коштів); назва і код валюти; курс цієї валюти; вхідний залишок; обороти й сальдо на рахунку в іноземній і національній валютах; проведені документи (вид операції); МФО кореспондента; особовий рахунок кореспондента; номер документа; сума за документом в іноземній і національній валютах.
Виписка за валютними особовими рахунками формується в кількох режимах. Так, у режимі «Виконавець» формуються виписки для кожного виконавця за закріпленими за ним рахунками. У режимі «Клієнт» видаються виписки за всіма чи зазначеними клієнтами. У режимі «Банк—клієнт» формуються виписки, які надсилаються клієнтам по каналах зв’язку. Виписки можуть формуватися за попередній операційний день, на зазначену дату чи будь-який період.
Особливу групу вихідних документів становлять пробний баланс, звітний баланс, оборотно-сальдова відомість у валюті, консолідований баланс. Звітний баланс формується за поточний день за вказаним кодом валюти чи за всіма валютами. Усі суми у звіті наводяться в національній та іноземній валютах. Протягом дня (під кінець) формується пробний баланс для попереднього аналізу. Остаточний варіант балансу складається після закриття операційного дня. Всі пакети ОДБ, що використовуються у банках, дають змогу складати баланс за поточний день, баланс на задану дату, баланс за вказаний період.
Зауважимо, що комп’ютерні системи дозволяють формувати на монітор сальдовий і оборотно-сальдовий баланс, який на практиці часто називають оборотно-сальдовою відомістю.
Заключною процедурою процесу обробки даних засобами пакета ОБД є складання консолідованого балансу. Спочатку складається пробний консолідований баланс для оперативного аналізу інформації, а після закриття операційного дня видається остаточна форма консолідованого балансу. Баланс формується за всіма валютними рахунками так, що суми перераховуються в одну валюту, код якої необхідно вказати у вхідних параметрах режиму.
Для обліку валютних операцій і формування відповідних вихідних документів використовуються АРМ:
операціоніста валютного відділу — ведуться валютні рахунки клієнтів, рахунки підзвітних осіб (касирів пунктів обміну валюти), виконується введення первинних платіжних документів і формування відповідних файлів первинних даних, проводяться експортно-імпортні операції, контролюється розподільний рахунок і т.ін.;
технолога валютного відділу — виконуються операції зі встановлення курсів валют, переоцінювання валют, передачі на оплату всіх введених бухгалтерських документів, проведення змін залишків на рахунках та операції із закриття ОДБ;
операціоніста ОДБ — функції, аналогічні тим, які виконує операціоніст валютного відділу (їм підпорядковані спільні рахунки, що їх вони безпосередньо контролюють).
формування звітності і друкування вихідних форм — складається баланс, оборотно-сальдова відомість, меморіальні ордери за особовими рахунками клієнтів.
За допомогою пакета «АРМ статистична звітність» формуються звітні файли, а саме: 01 — дані про залишки на рахунках (щоденний); 39 — дані про курс та обсяги операцій з іноземною валютою (щоденний); 40 — дані про рух коштів на кореспондентських рахунках іноземних банків в Україні (щоденний) та інші звітні файли.
Сформовані звітні файли передаються засобами електронної пошти до Регіонального управління НБУ, а після узагальнення — до валютного управління центрального апарату НБУ.
ТЕМА 4. АВТОМАТИЗАЦІЯ КРЕДИТНИХ І ДЕПОЗИТНИХ ОПЕРАЦІЙ
4.1. Основні автоматизовані функції при проведенні кредитних та депозитних операцій
Кредитні та депозитні операції є основними видами діяльності комерційних банків, а для деяких із них ці операції стали головним джерелом доходів. Тому вдосконаленню кредитних та депозитних операцій банки приділяють значну увагу, впроваджуючи комп’ютерні технології для автоматизації функцій управління кредитами та депозитами. Така автоматизація на практиці здійснюється в різних формах, на базі різних апаратних і програмних засобів, створюються, зокрема, системи, які не лише обробляють інформацію, а й підтримують управлінські рішення, що значною мірою знижує трудомісткість облікових робіт, підвищує якість рішень, що приймаються.
Технології виконання кредитних і депозитних операцій за змістом, послідовністю виконання та способами формування даних взаємоблизькі, тому їх доцільно розглядати в єдиному циклі технологічних процесів автоматизованої обробки даних. Але ці операції ще слабо структуровані, недостатньо формалізовані і важко піддаються автоматизації. Тому в підсистемі управління кредитами та депозитами часто застосовують інтерактивний режим виконання комп’ютерних технологій. Для цієї підсистеми характерна також неоднорідність завдань, зумовлена складністю предметної області. Адже банк працює з різними кредитами та депозитами, тобто йдеться про різні терміни, призначення, способи надання та погашення і т. ін. Проте практичний досвід показує, що всю сукупність функцій управління кредитами та депозитами з метою їх автоматизації можна об’єднати в типові комплекси: прогнозування й планування, облік і контроль, аналіз і регулювання. Кожний із цих комплексів виконується на відповідній стадії технології обробки інформації за допомогою закріплених апаратних і програмних засобів, тобто на виділених АРМ.
Розглянемо автоматизовані функції підсистеми управління кредитами та депозитами за стадіями технології.
Прогнозування й планування.
1. Визначення стратегії кредитування та депозитної політики.
2. Формування портфеля заявок за кредитами та депозитами.
3. Розрахунок кредитоспроможності клієнтів.
4. Оцінка ризику під час кредитування.
5. Планування рентабельності операцій.
6. Складання угод про кредит і депозитний вклад.
7. Складання плану-графіка кредитування.
8. Складання плану-графіка виплати процентів за кредитами та депозитами.
9. Складання плану-графіка погашення кредитів.
10. Розрахунок резервів за кредитами та депозитами.
Облік і контроль.
1. Відкриття рахунка.
2. Облік операцій за кредитними і депозитними рахунками.
3. Нарахування процентів.
4. Контроль за виконанням угод.
Аналіз і регулювання.
1. Формування звітів.
2. Аналіз, підтримання рішень.
Зауважимо, що наведений перелік функцій управління кредитами та депозитами на практиці автоматизований різною мірою, причому найменше автоматизовано визначення стратегії кредитно-депозитної політики. Ці функції, а також формування портфеля заявок належать до класу завдань стратегічного маркетингу. Кожне таке завдання розв’язується не для кожного кредиту окремо, а загалом для процесу кредитування на певний період. Розв’язування формується з урахуванням економічної ситуації і має якісний характер (наприклад, перевагу надавати тим чи іншим кредитам або певним типам клієнтів). Для автоматизації цієї функції доцільно застосовувати типові пакети програм статистичного аналізу даних (STATІSTІCA, статистичні функції EXSEL). Перспективним є напрямок розв’язання цих задач з використанням системи підтримання та прийняття рішень. На решті стадій технології обробки інформації автоматизуються функції, що пов’язані з конкретними кредитами чи депозитами. Розглянемо технологічні аспекти автоматизованого рішення основних комплексів задач управління кредитно-депозитними ресурсами банку.
4.2. Загальна технологія автоматизованого розв’язання основних комплексів задач управління кредитно-депозитними ресурсами
Автоматизація розрахунку кредитоспроможності позичальника полягає у визначенні показників, що характеризують акуратність останнього щодо розрахунків за раніше отриманими кредитами, його поточний фінансовий стан і перспективи змін, а також спроможність у разі потреби мобілізувати кошти з різних джерел і забезпечити оперативну конверсію активів у ліквідні кошти.
Методика визначення показників кредитоспроможності полягає ось у чому. Згідно з даними бухгалтерської та статистичної звітності клієнта обчислюють значення відповідних коефіцієнтів і порівнюють їх із нормативними. На підставі такого порівняння видаються рекомендації про можливість надання кредиту. Якщо потрібний глибший аналіз, вивчається поточна виробнича діяльність клієнта, беруться до уваги звітні дані за більший проміжок часу і обчислюються додаткові показники.
Вхідна інформація для обчислень вибирається з документів, що надійшли від клієнта, нормативно-довідкових БД і БД поточної інформації, що містяться на АРМ кредитного відділу. Від клієнта надходять: баланс підприємства і звіт про фінансові результати. На підставі цих документів створюються масиви «Баланс підприємства» і «Фінансові результати», в яких фіксуються всі потрібні для обчислень дані. Нормативно-довідкову інформацію для встановлення кредитоспроможності беруть із довідників: клієнтів, статей балансу, статей фінансового звіту, нормативних показників і методичних рекомендацій НБУ з визначення кредитоспроможності, а також архівних файлів, де містяться відомості про всі видані банком кредити.
Використовуючи інформацію зі згаданих щойно БД, на АРМ кредитного відділу за допомогою спеціального пакета програм обчислюють показники кредитоспроможності позичальника. Згідно з діючими нормативними актами кредитоспроможність позичальника встановлюється за такими показниками, як прострочена заборгованість за позикою; непогашені борги та коефіцієнти — незалежності, фінансової стабільності, маневрування, інвестування, покриття балансу; ефективність використання власних коштів, використання фінансових ресурсів, платоспроможність, ліквідність, рентабельність. Перелік показників задається через меню. Розглянемо як обчислюють деякі показники.
Коефіцієнт фінансової стабільності р-го підприємства на дату h:
,
де Zpr — пасив балансу, що відображає джерела власних та прирівняних до них коштів підприємства; — довгострокові позичені кошти; — підсумок активу балансу.
Коефіцієнт використання фінансових ресурсів р-м підприємством на дату h:
,
де — балансовий прибуток підприємства.
Коефіцієнт платоспроможності р-го підприємства на дату h:
,
де — запаси та витрати підприємства показані в 2-му розділі активу балансу на дату h; — сума 3-го розділу активу балансу; — загальна сума активу балансу.
Коефіцієнт абсолютної миттєвої ліквідності для р-го підприємства на дату h:
,
де — значення рядка балансу «Каса»; — розрахунковий рахунок; — валютний рахунок; — інші грошові кошти; — сума за 1-м розділом пасиву балансу; — сума за2-м розділом пасиву балансу.
Рентабельність власної продукції:
,
де — балансовий прибуток, вибирається з масиву фінансових результатів; — виручка від реалізації продукції (фінансові результати).
Результати обчислень видаються на екран у разі потреби до друку за формами таких вихідних повідомлень: показники взаємостосунків позичальника з банком, показники для аналізу кредитоспроможності позичальника, проранжований перелік клієнтів.
Показники взаємодії з банком формуються на базі масивів балансу та кредитних операцій. З масиву балансу вибираються значення рядків останнього, що характеризують непогашені в строк кредити, а з масиву кредитних операцій — інформація про виконання договірних зобов’язань клієнта за попередній період.
Для аналізу кредитоспроможності позичальника до відповідного вихідного документа заносяться такі відомості: назва та код клієнта-позичальника; назва та фактичне (розраховане) і нормативне значення показників кредитоспроможності; абсолютне та відносне відхилення розрахункового показника від нормативного (або того, що характеризує попередній період); дата, на яку складається документ. У разі потреби може бути обчислена рейтингова оцінка фінансового становища кожного з позичальників, котрі зробили заявку на кредит. Цей показник видається за формою документа «Проранжований перелік клієнтів». Вихідні документи використовують фахівці кредитного відділу та керівництво банку для аналізу кредитоспроможності та прийняття рішення щодо укладення угоди на видачу кредиту.
Автоматизація розрахунків під час оцінювання ризику банку у процесі кредитування здійснюється за допомогою спеціального пакета програм АРМ статистичної звітності, який передано Національним банком України до всіх комерційних банків. Цей пакет містить методику розрахунку нормативів ризику, передбачених для визначення Інструкцією про порядок регулювання й аналізу діяльності комерційних банків (максимальний розмір кредиту на одного позичальника; норматив великих кредитних ризиків, норматив максимального розміру кредитів, гарантій і поручительств, наданих одному інсайдеру; норматив максимального сукупного розміру кредитів, гарантій і поручительств, наданих інсайдерам; норматив максимального розміру наданих міжбанківських позик; норматив максимального розміру отриманих міжбанківських позик). Через меню задається перелік нормативів для розрахунків (виконуються на задану дату).
Вхідна інформація для розрахунків вибирається з масиву, сформованого під час складання бухгалтерського балансу банку, а також масиву нормативів, де зафіксовано граничні розміри останніх, і масивів-довідників, в яких приведений перелік показників і форм звітності.
Норматив ризику визначається за наведеними далі алгоритмами.
Норматив максимального розміру ризику на одного позичальника, значення якого не має перевищувати 25%:
,
де Зс — сукупна заборгованість за позичками, міжбанківськими кредитами та врахованими векселями одного позичальника (за 100% узято суму позабалансових зобов’язань, виданих щодо цього позичальника); К — капітал банку.
Норматив «великі кредитні ризики», максимальне значення якого не має перевищувати 8-кратного розміру капіталу банку:
НВ = Ск / К,
де Ск — сукупний розмір великих кредитів, наданих комерційним банком.
Норматив максимального розміру кредитів, гарантій і поручительств, наданих одному інсайдеру, що не має перевищувати 5%:
,
де Рк1 — сукупний розмір наданих банком позик, поручительств, урахованих векселів.
Норматив максимального сукупного розміру кредитів гарантій і поручительств, наданих інсайдерам, значення якого не має перевищувати 40%:
,
де РК — сума розмірів наданих банком позик (у тому числі міжбанківських), поручительств, урахованих векселів.
Норматив максимального розміру наданих міжбанківських позик, що не має перевищувати 200%:
,
де МБн — загальна сума наданих комерційним банком міжбанківських позик.
Результати автоматизованого розрахунку нормативів ризику утворюють відповідний масив і видаються для аналізу за формою вихідного повідомлення, де наведено дату, на яку здійснюється розрахунок; назву нормативного показника; обчислене та нормативне значення показника, а також відхилення першого із цих значень від другого. Працівники кредитного відділу використовують вихідні повідомлення для аналізу ступеня ризику та прийняття з приводу видачі кредиту остаточного рішення.
Крім нормативів ризику, які розраховуються згідно з методикою НБУ, банки в разі оформлення кредиту можуть глибше досліджувати ризик. Для автоматизації розрахунку розширених показників у кредитному відділі має бути сформований спеціальний пакет програм.
Автоматизація ведення кредитних і депозитних угод полягає у виконанні таких процесів: заведення нових угод, огляд списку угод, редагування окремих записів, вилучення окремих угод.
Заведення нової угоди зводиться до послідовного заповнення таких полів файла угод: номер угоди, код валюти, реєстраційний номер і назва клієнта банку, вид кредиту, дати початку і закінчення дії угоди, сума угоди, процентна ставка, тип особового рахунка, номер особового рахунка для угоди і статус угоди. У системі розрізняють 6 статусів: чорновик, умовний, виконуючий (має хоча б одну бухгалтерську проводку), пролонгований, закінчений, архівний.
Список угод оглядають через екранну форму документа, куди викликаються записи з файла угод із заданими користувачем ознаками (номер угоди, реєстраційний номер та назва клієнта і т.ін.). Для огляду можуть викликатись окремі записи або інші масиви. Під час огляду не можна вносити зміни до полів. Для цього використовується спеціальна процедура «редагування».
Редагування виконується за типовою схемою обробки даних файла угод. Коригувати поля можна лише тих записів угод, для яких зафіксований статус чорновика. Для коригування угод, що мають інший статус, використовуються спеціальні процедури, наприклад пролонгація, вилучення.
Процедура «пролонгації» можлива лише щодо тих угод, в яких наступає закінчення терміну дії. Вибір цієї процедури дозволяє вивести на екран інформацію про дату погашення останньої частини кредиту, дату виплати нарахованих процентів, дату останнього платежу за угодою. Користувачем вводиться дата пролонгації, дата, до якої продовжено термін дії угоди, після чого угода набуває статусу виконуваної.
Оформлюючи депозитні та міжбанківські кредитні угоди, у відповідних полях фіксують вид депозиту чи міжбанківського кредиту, код і назву вкладника чи номер МФО та назву банку. Решту полів файла угод лишають без змістових змін для всіх типів угод. Кожна угода характеризується статичними і динамічними параметрами. До статичних параметрів належать сума угоди, термін дії угоди, клієнт, джерела фінансування, група ризику, санкції в разі заборгованості. Динамічними параметрами, що визначають поточний стан угоди на задану дату, є процентна ставка, характеристика стану угоди, рахунок угоди, періодичність нарахування процентів та кореспондентські рахунки під час нарахування останніх. У процесі «життя» угоди може змінюватись її стан.
Завершується перша стадія технології автоматизованого управління кредитами та депозитами (прогнозування й планування) складанням планів-графіків кредитування, планів-графіків виплати процентів за кредитами та депозитами, а також графіків погашення кредитів.
На другій стадії комп’ютерних технологій управління кредитами та депозитами виконують комплекси завдань з відкриття кредитних і депозитних рахунків; обліку банківських операцій, що фіксуються на них; обчислення процентів за кредитними та депозитними операціями; контролю за виконанням договірних відносин між банком і клієнтом.
Після укладання угоди, тобто оформлення всіх необхідних документів, здійснюють організаційні й технологічні процедури з відкриття рахунка. Для виконання технологічних процедур такого типу у програмному комплексі є спеціальна підпрограма «Особові рахунки за угодою». Технологія її виконання така сама, як і в разі відкриття розрахункового рахунка.
Автоматизація обліку операції на кредитних і депозитних рахунках виконується за типовою схемою обробки вхідних документів. Вхідними документами під час відображення на рахунках кредитних і депозитних операцій слугують розпорядження чи меморіальні ордери на зарахування коштів на рахунок, а також прибуткові і видаткові документи.
Першою операцією в технології обробки вхідних повідомлень є ручне введення документів операціоністом через екранні шаблони. Під час такого введення здійснюється логічний (програмний) контроль інформації, записуваної в поля вхідного файла. В окремих пакетах ОДБ передбачене повторне введення документів уже іншим виконавцем у режимі «Контрольний ввід». Коли на екрані з’являється повідомлення «Документ знайдено» (це означає, що вхідне повідомлення записане в базу даних без помилок), інформація передається на наступну операцію — оплату документа, тобто запис (або їх сукупність) заноситься до файла платіжних документів дня — господарська операція відображається на бухгалтерських рахунках. Основну БД організовано так, що можна на задану дату визначити рух коштів і використати відповідні показники для обчислення процентів за депозитами та кредитами.
Нарахування процентів за депозитами та кредитами здійснюється спеціальним програмним модулем щодо всіх клієнтів або за вказаними рахунками. Програма дає змогу на початку розрахунку змінити через екранну заставку процентну ставку. Результати обчислень записуються у спеціальний файл, з якого інформація після огляду на екрані записується в основну БД або видається на друк для оформлення відповідних документів.
Контроль виконання угод за кредитами та депозитами здійснюють спеціальними програмними засобами і запускають за допомогою екранного меню, де зазначаються функції персонального і групового контролю за угодами.
Персональний контроль означає, що на екран після вказаних типу та номера угоди видається зміст угоди (перелік необхідних фахівцеві реквізитів) і дані з кредитних рахунків: суми залишку та руху коштів, відомості щодо нарахування та виплати сум за процентами.
Груповий контроль за кредитами та депозитами здійснюється на підставі фактичних даних, сформованих на екрані, а при потребі — на підставі виданих до друку таблиць. Перелік таких таблиць задається в меню, і користувач вказує, які таблиці слід складати. У них наводяться суми та процентні ставки за кредитами та депозитами у межах дня, обороти за окремими позичковими рахунками протягом зазначеного періоду, кількість угод, сума і процентні ставки за кредити — окремо за депозитами та міжбанківськими кредитами. Щодо трьох останніх документів задається період або дата, на яку складається документ. Крім наведених, за допомогою засобів EXCEL, можуть бути сформовані й інші документи, якщо підготовлено робочий масив з необхідними даними на базі файла угод і файла, що відображає операції на кредитних і депозитних рахунках.
На третій стадії комп’ютерних технологій управління кредитами та депозитами формуються звіти, складаються аналітичні таблиці, а також обчислюються прогнозні показники, використовувані для підтримки та прийняття рішень.
Формування звітів за кредитами та депозитами здійснюється автоматично на підставі баз даних оперативної інформації, що сформовані пакетом програм ОДБ. Для цього використовується пакет програм АРМ зі статистичної звітності. В екранному меню цього пакета задається перелік звітів, які слід складати на задану дату. Це такі звітні файли:
03 — дані про суми й процентні ставки за кредитами та депозитами (щоденно);
04 — дані про суми та процентні ставки за кредитами (щомісячно);
05 — дані про суми та процентні ставки за депозитами (щомісячно);
16 — дані про заборгованість за пролонгованими, простроченими та сумнівними кредитами;
інші файли.
Зазначені файли передаються до Регіонального управління НБУ, де використовуються для складання звітів, які передаються на верхній рівень інформаційної системи НБУ.
Складання аналітичних таблиць здійснюється на АРМ спеціалістів кредитного та депозитного відділів банку. Режим передбачає виконання технології обробки інформації в два етапи. Попередньо готуються дані та задаються такі поля: тип договору, повний чи скорочений склад вхідної інформації, період (часові межі) інформації — дві дати, що вказують на періодичність. При підготовці вхідних даних необхідно вибрати варіант технології їх формування (використовувати базові дані за попередній період чи враховувати зміни).
Коли закінчено підготовку інформації, система переходить до другого етапу — режиму обчислення показників для складання таблиць або графіків.
Аналітичні таблиці можуть змінюватися, задаватися користувачем. У них наводяться договірні, реальні та прогнозні значення показників. Договірні значення задаються умовами угоди, а реальні відображають дію угоди на задану дату. Прогнозні характеристики обчислюють окремо за допомогою спеціальних пакетів програм під назвою — «Прогноз кредиту». Аналітичні таблиці можуть відбивати динаміку змін тих чи інших показників, що дає змогу прогнозувати дії, а також приймати рішення. Для прийняття рішень фахівці та керівники звертаються до системи із запитами, на які формуються відповіді за допомогою спеціальних пакетів програм чи мови маніпулювання даними.
ТЕМА 5. ЕЛЕКТРОННА ПОШТА НБУ ЯК ОСНОВА ВЗАЄМОДІЇ МІЖ БАНКАМИ УКРАЇНИ
5.1. Структура, призначення та можливості електронної пошти НБУ
Електронна пошта (ЕП) складається загалом із вузлів — комп’ютерів, які мають змогу встановлювати один з одним з’єднання для передачі електронних листів (повідомлень) своїх абонентів. Вузли поділяються на абонентські пункти АП 1-го типу (АП-1) та абонентські пункти 2-го типу (АП-2) (поштамти).
Кожний АП-1 передає в інші вузли лише ті повідомлення, які були підготовлені його абонентами, і приймає від решти АП лише адресовані його абонентам повідомлення. На відміну від АП-1 АП-2 передає на інший поштамт або на АП-1 будь-які повідомлення.
Будь-яке повідомлення ЕП має бути адресним, тобто мати свою електронну поштову адресу. З погляду логіки для того, щоб адреса була інформативною, необхідно, аби вона включала в себе ідентифікатор абонента (кінцевого користувача — КК) і поштові координати, які визначають місцезнаходження КК. Правила адресації в різних системах ЕП відрізняються одне від одного, але ці логічні елементи присутні завжди.
Електронна пошта НБУ — це комп’ютерна мережа, яка ефективно працює з 1994 року. Головним поштовхом до її створення було те, що для банків не є прийнятною технологія, коли повідомлення передаються через центри (вузли), які не належать їм. Водночас враховувалась і можливість кращого регулювання завантаження, забезпечити потрібну швидкість передачі та доставки повідомлень тощо.
Електронна пошта НБУ являє собою програмно-технічну та адміністративно-технологічну мережу, яка забезпечує обмін даними в банківській системі України. Вона призначена для надійного та якісного приймання і передавання електронних повідомлень. Джерелами та одержувачами останніх можуть бути як різні програмні продукти (зокрема й прикладні програми), так і фізичні особи. Вони є кінцевими користувачами системи. Систему ЕП НБУ створюють поштові вузли. Розрізняють Центральний, регіональні та абонентські вузли.
Центральний і регіональні вузли є абонентськими вузлами2-го типу, а решта вузлів — АП 1-го типу. До них належать вузли, що розміщені в комерційних банках України, а також в урядових і державних установах, які взаємодіють з банківською системою. Організаційно вузли ЕП, за винятком АВ, є структурними підрозділами системи НБУ, котрі у своїй діяльності керуються чинним законодавством України, ухвалами НБУ, відповідними положеннями про ці підрозділи та положеннями про ЕП НБУ.
Центральний вузол (ЦВ) — це підрозділ Центрального управління НБУ, а регіональні вузли (РЕВ) — підрозділи відповідних територіальних управлінь НБУ.
Абонентський вузол може входити до складу будь-якої установи (КБ і т.ін.), що виконує всі умови, які ставляться в разі підключення абонентів до ЕП, і бере участь у роботі системи. Вузли можуть бути пов’язані між собою за допомогою виділених чи комутованих телефонних і телеграфних каналів зв’язку або через радіоканал і супутникові системи передачі даних.
Система ЕП НБУ дає змогу інтегрувати локальні обчислювальні мережі (ЛОМ), які існують в її вузлах. Використовуючи ЕП, кожний користувач робочої станції (РС) ЛОМ її вузла може відправити повідомлення у вигляді текстового файла, підготовленого з використанням довільного текстового редактора; графічного файла, що містить графічні конструкції будь-якого вигляду; файла бази даних типу .DBF; файла табличного процесора. Інший абонент, який перебуває в іншому регіоні і є користувачем ЛОМ свого вузла, може приймати ці повідомлення на свою РС.
Переваги ЕП НБУ такі: висока швидкість доставки повідомлень та можливість автоматизувати в установі процес обробки документації, починаючи з її отримання.
Система ЕП НБУ не є системою діалогової взаємодії і має такі особливості:
формування й приймання поштових повідомлень — процеси, що розділені в часі і виконуються незалежно від процесів встановлення з’єднань між вузлами та передачою даних;
система ЕП використовує архітектуру, коли повідомлення запам’ятовується на одному вузлі, а далі передається за маршрутом до іншого вузла доти, доки воно не буде доставлене адресатові. Така архітектура забезпечує передачу даних навіть у разі можливих відказів засобів зв’язку;
ЕП НБУ дає змогу передавати повідомлення одночасно багатьом користувачам завдяки введенню спеціального механізму «групи вузлів» і вказуванню кількох адресатів при формуванні «поштового конверта».
Система ЕП НБУ допомагає організовувати взаємодію між програмними комплексами автоматизації банківської діяльності, які містяться в різних вузлах. При цьому забезпечується весь сервіс щодо зберігання, документування й надійності доставляння кореспонденції.
Можливе підімкнення до ЕП НБУ серверів для факсимільного й телексного зв’язку, що дозволяє надавати додаткові послуги, додатковий сервіс кінцевому користувачеві.
Система ЕП НБУ підтримує роботу абонентського вузла на базі використання таких технічних засобів: ІВМ-сумісних персональних комп’ютерів, «Науеs» — сумісних модемів, що відповідають стандартам V.22 bіs, V.32, V.32bіs, криптографічнх блоків, комутованих телефонних каналів загального користування або спеціалізованої мережі «Іскра-2». Кількість каналів визначається інтенсивністю та обсягами передавання/приймання даних у вузлі. У разі використання кількох телефонних каналів для зручності в роботі організовують один груповий номер.
У Центральному і регіональних вузлах додатково підключають робочі станції, на яких виконуються програми управління з’єднаннями і транспортування даних. (Потрібно зберігати на вузлі дані, що надходять, розподіляти їх між відповідними вузлами та забезпечувати транспортування).
Залежно від типу вузла використовується певний набір програмного забезпечення. У ЦВ і РЕВ це мережні ОС NetWare фірми NOVELL, вузлова версія ProCarry, операційна система DOS 5.0. На абонентських вузлах використовуються DOS, версія 3.30 і вищі; один із комутаційних мережних пакетів NetWare, ProCarry, РіeNET, АSТRA, АCROCOM, мережні елементи UNІX. Найпоширенішою (частка її становить близько 85%) є система ProCarry, хоча останнім часом починає зростати й частка UNІX.
В ЕП ведеться довідник вузлів ЕП, який міститься в кожному вузлі системи у вигляді файла з іменем «SPRUSNBU.DBF». Цей довідник фактично описує адресний простір вузлів ЕП. Він ведеться в ЦВ, служби якого забезпечують актуалізацію довідника й готують коректури для розсилання по всіх інших вузлах ЕП НБУ. Кожний вузол має належне лише йому поштове ім’я.
Для АВ, які містяться в банківських установах, ім’я вузла складається з чотирьох знаків, де перший знак є постійним (латинська буква «U»), другий — латинська буква, яка визначає регіон (область) України (наприклад, «А» — Вінницька область, «В» — Волинська і т.д.), третій знак задає код типу або множини банківських установ, а четвертий — номер вузла в даному типі чи множині банківських установ.
Загальну схему мережі зображено на рис. 2.3.

Рис. 2.3. Структурна схема ЕП НБУ
Система має суто ієрархічну трирівневу структуру. На 1-у рівні перебуває ЦВ, на 2-у містяться регіональні вузли, а на 3-у — абонентські вузли. Кожний АВ входить лише до одного регіонального, а регіональні вузли входять до ЦВ. Завдяки тому, що РЕВ — це, як правило, обласні вузли (крім Київського), то забезпечується охоплення всієї території країни.
Звичайний режим роботи вузлів — запитово-активний для вузла нижчого рівня щодо вищого. Тобто АВ як вузол 3-го рівня є запитово-активним, сам активізує запит до (і тільки до) відповідного свого регіонального вузла як вузла 2-го рівня. Так само у звичайному режимі РЕВ є запитово-активним щодо Центрального вузла системи, але на відміну від АВ він може генерувати запит і до будь-якого свого нижчестоящого абонентського вузла. Відповідно ЦВ може генерувати запит до кожного регіонального вузла.
На множині вузлів пошти для забезпечення передавання повідомлень визначається набір маршрутів, де описуються шляхи доступу від одного вузла до іншого. Ці маршрути використовуються при транспортуванні поштових повідомлень. З огляду на ієрархічну структуру ЕП доставляння поштового повідомлення (ПОП) між двома РЕВ можливе лише через ЦВ. Ясна річ, що і ПОП АВ одного РЕВ до АВ іншого РЕВ іде транзитом через ЦВ. Можливі маршрути в ЕП можна записати у вигляді:
АВ(а) ( РЕВ ( АВ(б), АВ(а) ( РЕВ(а) ( ЦВ ( РЕВ(б) ( АВ(б).
Поштові повідомлення, або «поштові конверти», є тими одиницями інформації, які передаються між вузлами системи ЕП.
Усяке ПОП складається з даних службового заголовка та інформаційної частини, яку називають також «тілом повідомлення». До ПОП можуть підключатися (додаватися) додаткові файли, які описуються в службовому заголовку і передаються адресатові разом із повідомленням.
Зауважимо, що розмір повідомлення істотно залежить від застосовуваних програмних транспортних засобів. Скажімо, коли як транспортний засіб використовується програмний пакет ProCarry, розміри поштових повідомлень теоретично необмежені. У разі використання NetWare розмір файла, «запакованого» в конверт, і файла доповнень має не перевищувати 64 кбайтів. При цьому обсяг заголовка ПОП є порівняно невеликим і залежно від використовуваних програмних транспортних засобів становить від 300 до 500 байтів.
Одним з елементів заголовка ПОП є адреса одержувача. Вона складається з поштового імені вузла-адресата, тобто імені АВ, РЕВ або ЦВ, та імені локального користувача (ЛК) на цьому вузлі, якому безпосередньо й призначені дані. При цьому вважається, що в кожному вузлі ЕП може визначатися свій набір, своя множина імен локальних користувачів.
Ім’я локального користувача (його ідентифікатор) — це набір від одного до восьми символів латинського алфавіту. Ідентифікатори ЛК різних вузлів ЕП ні між собою, ні з іменами самих вузлів ніяк не пов’язані. Тобто в рамках одного вузла вони мають бути унікальними. Проте на різних вузлах ЕП допускаються однакові імена ЛК. Наприклад, майже на кожному вузлі ЕП є ЛК з іменем «АDMІN».
Роль ЛК можуть відігравати як фізичні особи, так і задачі (програмні комплекси), що використовують ЕП для отримання й передавання інформації між вузлами. Зокрема програмно-технічний комплекс АРМ-3 у вузлах комерційних банків, маючи ім’я ЕLPLAT, використовує ЕП для передавання та приймання електронних платіжних повідомлень за міжбанківськими платежами.
У поштовій адресі для відокремлення ідентифікатора абонента від імені поштового вузла використовують значок «@» (банківське «а»). Наприклад, поштова адреса може мати вигляд: ADMІN@UAR0, де ADMІN — ім’я ЛК на вузлі UAR0.
5.2. Взаємодія між вузлами і користувачами ЕП НБУ
Взаємодія локальних користувачів вузлів у ЕП НБУ реалізується через набір програмних засобів, які згідно з термінологією протоколу Х.400 називають «агентом користувача» (АК). З їх допомогою може виконуватися підготовка ПОП із різних файлів даних, формування конвертів і їх передача до ЕП для подальшого розсилання адресатам. З допомогою АК вибирають також дані з поштових конвертів. Роль АК відіграють програми ТОМАІL і UZERМАІL. Через АК у вузлах ЕП НБУ можлива як інтерактивна (діалогова), орієнтована на людину, так і пакетна (автоматична) взаємодія з поштовою системою.
Транспортування даних виконується з допомогою програмних засобів — «агента передавання повідомлення» (АПП). Базовим і найпоширенішим транспортним засобом в ЕП НБУ є пакет ProCarry. Особливістю цього пакета є те, що в разі «аварійного» завершення передачі він забезпечує її продовження з місця, в якому було перервано повідомлення.
Загальна технологія пересилання поштового повідомлення така:
1) створення первинного файла з даними, які потрібно переслати;
2) «конвертування» первинного файла. При цьому він упаковується з метою зменшення його обсягу;
3) пересилання «конверта» у потрібний вузол;
4) «розконвертовування» отриманого «конверта».
Усі ПОП, які проходять через вузли ЕП НБУ, зберігаються в архіві повідомлень (АрхП) вузлів. АрхП — це по суті набір каталогів, де зберігаються «конверти», які оброблялися на вузлі протягом дня.
Інформація архіву ЕП НБУ є розосередженою по мережі (вузлах). Термін зберігання архівів банківських документів здебільшого досить значний (залежно від видів документів 2—10 років). Перед розробниками ЕП НБУ постає проблема задовольнити ці вимоги, диференційовано підходячи до строків зберігання даних.
Взаємодія між вузлами ЕП відбувається так. Якщо на вузлі є повідомлення для абонента іншого вузла, то можливі два варіанти доставки цього повідомлення.
1. Якщо вузол є пасивним щодо вузла-адресата, то ПОП уміщується в чергу для даного адресата і буде звідти забране віддаленим вузлом лише після того, коли останній сам установить зв’язок. Отже, із РЕВ ПОП забираються в абонентські вузли (як правило, з ініціативи останніх). На практиці ЦВ та регіональні вузли майже безперервно перебувають на зв’язку, тоді як протягом дня є періоди відсутності зв’язку між РЕВ і АВ.
2. Якщо вузол-відправник ПОП є активним щодо вузла-адресата, то він сам установлює зв’язок і передає повідомлення.
На вузлі повідомлення може з’явитися двома шляхами. Перший — у результаті роботи програм агента користувача. У такому разі повідомлення «народжується» на самому вузлі і надходить до вихідного каталогу вузла (OUTPUT). Другий шлях — коли ПОП доставляється з іншого вузла, тобто надходить по каналах зв’язку. Тоді воно потрапляє до вхідного каталогу вузла (ІNPUT).
Якщо отримане з деякого вузла ПОП транзитне, тобто призначене для іншого вузла, то після реєстрації його отримання у статистичному журналі воно надходить із вхідного каталогу вузла до вихідного його каталогу. Коли отримане повідомлення адресоване локальному користувачеві на цьому самому вузлі, то воно вміщується в каталог вхідних повідомлень відповідного користувача цього вузла.
Наголосимо, що копії всіх ПОП, що надійшли як для ЛК, так і транзитних, зберігаються в архіві вузла. Крім того, інформація про них уміщається у файл статистики роботи вузла, який являє собою довідник для архіву.
Файл статистики звичайно доступний Адміністраторові вузла й містить такі реквізити: оригінальне ім’я файла повідомлення; від кого і кому повідомлення надіслано (коди вузлів і абонентів відповідно відправника та одержувача); дата і час підготовки конверта; дата і час отримання конверта; дата і час підготовки квитанції; дата і час розкриття конверта; розмір файла в байтах; характеристика руху файла (отримання, транзит, відправлення) і т. ін.
Важливою функцією в ЕП є забезпечення й підтвердження факту доставки конверта. Тому в ЕП є функція генерації та обліку підтверджень доставки поштових повідомлень. Такі підтвердження формуються лише в кінцевому вузлі-одержувачі. Підтвердження формується як файл-квитанція про доставку ПОП у момент, коли воно потрапляє до вхідного каталогу у вузлі-адресаті. Квитанція формується автоматично програмами АК, якщо в заголовку ПОП, яке надійшло, встановлено ознаку видачі підтвердження доставки.
Файл-квитанція за своєю структурою аналогічна файлу повідомлень і надсилається на адресу абонента-відправника. Облік проходження цього файла здійснюється на всіх транзитних вузлах ЕП, а у вузлі-відправнику ПОП підтвердження доставки реєструється, але до архіву не надходить, оскільки знищується.
У кожному вузлі ЕП кінцевому користувачеві надаються такі можливості.
1. Формування з будь-яких раніше отриманих або підготовлених файлів поштових конвертів для їх наступної передачі.
2. Формування ПОП безпосереднім введенням даних із клавіатури персонального комп’ютера або редагування попередньо сформованих заготовок (телеграми, листи тощо).
3. Розсилання циркулярних повідомлень, а також передача інформації для групи вузлів.
4. Ведення статистичних файлів та архіву повідомлень у кожному вузлі для документування його роботи.
5. Ведення журналів роботи кожного локального користувача вузла із вхідною кореспонденцією.
6. Вибирання даних із поштових конвертів, які доставлені адресатові засобами ЕП.
7. Забезпечення зберігання всієї прийнятої кореспонденції навіть у разі збігу імен файлів-повідомлень.
8. Можливість формування та видача підтвердження про обробку поштового повідомлення користувачем-адресатом. (Це квитанція не про доставку, а про безпосередню обробку — розкриття конверта користувачем).
Зрозуміло, що це дає змогу використовувати ЕП для розв’язання найрізноманітніших функціональних задач і операцій банківської та фінансової діяльності. Насамперед ЕП НБУ використовується для забезпечення можливості виконання міжбанківських розрахунків. Саме на базі ЕП НБУ створена й функціонує система електронних міжбанківських платежів (СЕП) банків України. Нині засобами ЕП користуються, виконуючи такі задачі:
забезпечення транспортних вимог системи міжбанківських електронних платежів (пріоритетне завдання ЕП НБУ);
передача нормативних, директивних та інших документів НБУ;
передача курсів валют;
передача та збір статистичних даних;
передача директив, запитів, звітів, довідок тощо;
подання звітів з оформлення заборгованості векселями;
передача програмного забезпечення загального та системного користування, змін і доповнень до нього та ін.
За допомогою ЕП НБУ може бути створена така, що охоплює всю країну, система масових електронних платежів із використанням електронних грошей.
У кожному вузлі ЕП НБУ крім довідника зазначених вузлів існують два масиви нормативно-довідкової інформації (НДІ), які описують специфіку конкретного вузла: його конфігурацію та локальних користувачів.
У файлі конфігурації (NODE.CFG), котрий має структуру, аналогічну файлу конфігурації DOS (CONFІC.SYS), задаються поштовий ідентифікатор вузла та інші параметри, які використовують програми агента користувача. Вказується створюваний під час підготовки вузла до роботи в системі ЕП шлях до каталогів локальних користувачів вузла. Довідник ЛК вузла (LUSERS.NDE) містить список усіх локальних користувачів даного вузла. Він також створюється під час запуску вузла і може коригуватися адміністратором вузла.
В ЕП за допомогою спеціальних програмних засобів обліковуються та аналізуються помилкові та «збійні» ситуації.
Система ЕП НБУ має понад 2 тис. вузлів (у тому числі 26 РЕВ і 1 ЦВ). Кількість її учасників постійно зростає. Оскільки число кінцевих користувачів на вузлах пошти знаходиться в межах від 5 до 120, загальна кількість користувачів, яким надаються послуги ЕП, перебуває, відповідно, в межах від 2000 ( 5 = 10 000 до 2000 ( 120 = 240 000.
Обсяги інформації, що їх обробляють Центральний і регіональні вузли, становлять за місяць десятки гігабайт. Швидкість обміну даними між АВ і РЕВ доволі висока і досягає майже15 000 біт/с, або близько 2 000 байт/с. Така швидкість поки що достатня для ділових повідомлень, але вимоги до неї постійно зростають, тому система постійно розвивається і модернізується.
Нині розробляються методи, згідно з якими для передавання даних між вузлами застосовуються радіоканали та оптичні канали, пропускна здатність яких у багато разів більша, ніж у телефонних ліній. Появляється можливість передачі мовних фрагментів у складі повідомлень ЕП.
За час роботи ЕП як її розробниками, так і користувачами було створено багато різних програм, зорієнтованих на роботу ЕП, на використання й розширення її можливостей.
Зауважимо, що в інформаційно-довідковій службі ЦВ є бібліотека таких програм.
Перспективою розвитку ЕП крім поліпшення якісних показників її роботи (скорочення строку доставки повідомлень, зменшення кількості відказів, можливість підключення нових вузлів, збільшення обсягів передачі тощо) є також розробка часткових шлюзів передавання та приймання даних із інших мереж, зокрема й із мережі ІНТЕРНЕТ. Зрозуміло, що при цьому постає проблема додаткових облікових і контрольних функцій, оскільки ЕП НБУ є системою закритого типу й такою, що забезпечує виконання специфічних завдань і послуг. Аналогічні проблеми пов’язані зі створенням шлюзу ЕП НБУ на інші поштові системи.
ТЕМА 6. СИСТЕМА ЕЛЕКТРОННИХ МІЖБАНКІВСЬКИХ ПЛАТЕЖІВ НБУ
6.1. Призначення та структура системиміжбанківських електронних платежівНаціонального банку України
Система міжбанківських електронних платежів Національного банку України (СЕП НБУ) — це загальнодержавна платіжна система, яку створено з метою виконання (як за дорученням клієнтів, так і за зобов’язаннями банків один перед одним на території України) розрахунків між банківськими установами в електронній формі.
Розрахунки між банками ведуться на підставі кореспондентських рахунків банків, які відкриваються в регіональних управліннях НБУ.
Регіональне управління (РУ) НБУ — це установа НБУ, яка уповноважена виконувати в межах певного регіону визначені чинним законодавством функції та операції від імені головної установи НБУ. Головною вважається установа НБУ, яка обслуговує рахунки регіональних управлінь НБУ при здійсненні міжбанківських розрахунків.
Операції з розрахунків між банківськими установами відображаються на відповідних балансових рахунках плану бухгалтерського обліку в банках. Загалом міжбанківські розрахунки на території України можуть виконуватися такими способами: установленням прямих кореспондентських відносин між банками; через СЕП НБУ; через узгоджені з НБУ мережі систем розрахунків комерційних банків (КБ). Комерційні банки України вільні у виборі форм та способів розрахунків.
НБУ як центральний банк країни бере безпосередню участь у міжбанківських розрахунках і організовує їх реалізацію. Саме НБУ є гарантом платіжної системи в цілому і системи міжбанківських електронних платежів зокрема. Інші банки України як учасники міжбанківських розрахунків несуть солідарну відповідальність за їх стан і діють відповідно до нормативних актів НБУ та договорів учасників міжбанківських розрахунків.
Основу існуючої системи міжбанківських розрахунків України становить мережа розрахункових палат НБУ, яку було створено згідно з Постановою Правління НБУ від 16.07.93 за № 57. Вона складається з Регіональних розрахункових палат (РРП) і Центральної розрахункової палати (ЦРП), які функціонують на базі застосовуваної системи бухгалтерського обліку та звітності НБУ.
Регіональна розрахункова палата — це підрозділ РУ НБУ, до функцій якого належить обслуговування системи електронних платежів і впровадження нових платіжних технологій у межах відповідного регіону. РРП обслуговують установи комерційних банків, для яких відкриті кореспондентські рахунки (КР) у відповідних територіальних управліннях НБУ.
Центральна розрахункова палата являє собою підрозділ центрального управління НБУ, який має обслуговувати систему електронних платежів на всій території України і зводити міжрегіональний баланс. ЦРП виконує також функції РРП для банківських установ Києва та Київської області (регіону).
Робота системи електронних міжбанківських платежів грунтується на таких головних принципах.
1. СЕП функціонує за схемою типу «брутто», оскільки кожна наступна оплата виконується окремо з урахуванням підсумкового сальдо, отриманого на попередній операції.
2. Транзакції (ТА), тобто банківські операції з переказування грошових коштів, зокрема за кордон, відображаються в режимі реального часу на технічних кореспондентських рахунках банків (ТКР) у РРП.
Наприкінці дня результати розрахунків відображаються на кореспондентських рахунках банків у відповідних РУ НБУ. Завдяки цьому учасники розрахунків мають необхідну інформацію для прогнозування стану ліквідності та своїх дій.
3. Транзакції, які потенційно приводять до стану овердрафту, тобто до стану, коли на рахунку банку виникає дебетове сальдо, блокуються. Отже, початкові платежі від банків приймаються лише в межах, які визначаються розміром поточного залишку на кореспондентському рахунку.
4. Ініційована банківською установою транзакція не підлягає відміні.
5. Ініціатива транзакції належить банкові, який дебетує власний рахунок. Можливість дебетування рахунка іншого учасника СЕП надано лише відповідним підрозділам НБУ для обмеженого переліку типів транзакцій. Банк, якому потрібно дебетувати рахунок іншого банку, може передати йому через СЕП ініційований запит про необхідність проведення даної транзакції за ініціативи останнього. Тобто в СЕП існують і електронні документи у вигляді запитів.
6. Головним режимом роботи системи є передача електронних платіжних документів та підтвердження їх отримання (квитування). СЕП виключає необхідність використання паперової технології.
7. У кожному РУ НБУ, точніше в його підрозділі РРП, ведуться транзитні рахунки для відстежування транзакцій, ініційованих, але не закінчених протягом одного банківського дня. Це дає змогу організувати роботу учасників СЕП з урахуванням специфіки кожного з них, скажімо нестійкої роботи каналів зв’язку і т. ін.
8. Граничні суми транзакцій у системі не обумовлені. Неявними межами можуть бути собівартість транзакції (мінімальна) та поточне значення кореспондентського рахунка банку — ініціатора (максимальна).
9. Банки виконують початкові платежі в СЕП у межах значення свого КР. Щоб змінити цю умову, у СЕП створено можливість накладати для окремих банків ліміт на поточне значення КР (ЛТК), ліміт на загальну суму початкових оборотів (ЛПО) і використання механізму бізнес-правил.
10. СЕП є власністю НБУ і обслуговує комерційні банки на договірній основі.
Система міжбанківських електронних платежів має трирівневу ієрархічну структуру.
На 1-у, верхньому рівні СЕП міститься Центральна розрахункова палата. Вона обслуговується програмно-технічним комплексом АРМ-1, що виконує такі основні функції:
1) «пересилання» міжрегіональних електронних документів засобами електронної пошти Національного банку України;
2) перевірку правильності формування електронних документів;
3) формування й підтримання в робочому стані основних довідників НБУ;
4) захист електронних документів і системи в цілому від несанкціонованого доступу;
5) диспетчеризацію (бухгалтерський технологічний контроль) проходження міжрегіональних платежів і синхронізацію закриття дня банку.
На 2-у рівні мережі перебувають регіональні розрахункові палати, які обслуговуються своїми програмно-технічними комплексами АРМ-2.
АРМ-2 — це програмно-технічний комплекс (ПТК), установлений у РРП і призначений для обслуговування певної кількості банків цього регіону та організації взаємодії з іншими АРМ-2. РРП може експлуатувати один чи кілька АРМ-2 залежно від кількості банків регіону та активності проведення ними міжбанківських платежів. Кожне АРМ-2 забезпечує виконання таких основних операцій:
1) обмін електронними документами між самою РРП і банками-учасниками міжбанківських розрахунків;
2) формування та відправлення міжрегіональних платежів до ЦРП;
3) отримання міжрегіональних платежів від ЦРП та їх аналіз;
4) обмін електронними документами з іншими АРМ-2 своєї РРП.
5) захист електронних документів і їх обробка від несанкціонованого втручання.
На 3-у нижньому рівні СЕП перебувають учасники міжбанківських електронних розрахунків, які діють на підставі угод із РРП на проведення розрахунків та Положення про міжбанківські розрахунки в Україні згідно з Регламентом функціонування мережі розрахункових палат України. Учасниками електронних платежів можуть бути і здійснювати за допомогою СЕП міжбанківські розрахунки будь-які кредитно-фінансові підприємства й організації, котрі мають відкриті КР у відповідних РУ НБУ та задовольняють вимоги, що їх висуває НБУ до учасників СЕП.
Юридичні особи ще не є учасниками мережі електронних платежів і можуть користуватися її послугами лише через посередництво безпосередніх «учасників», укладаючи з ними відповідні договори.
У розпорядження кожного з учасників платежів надається єдина копія програмно-технічного комплексу з умовною назвою АРМ-3 (або інакше АРМ НБУ), через який банк обмінюється інформацією із СЕП за допомогою файлів, структура та функціональне призначення яких визначені в документі «Інтерфейс між САБ і АРМ-3системи електронних платежів (СЕП)». АРМ-3 на рівні банку—учасника розрахунків забезпечує виконання таких основних операцій:
1) перевірку пакетів платіжних документів, які підготовлені банком, що експлуатує даний АРМ-3;
2) обмін електронними документами з відповідною РРП;
3) захист системи від несанкціонованого втручання.
Оскільки для передачі пакетів використовується система електронної пошти НБУ, то банк одночасно є й абонентським вузлом цієї пошти, а АРМ-3 — одним із основних кінцевих користувачів цього вузла. Відповідно АРМ-2 є кінцевим користувачем вузла2-го рівня ЕП НБУ, а АРМ-1 — один із основних користувачів Центрального вузла ЕП НБУ.
Між учасниками СЕП на різних рівнях циркулюють різного роду платіжні документи. Зокрема, на рівні КБ-РРП — електронні документи (ЕД) і документи на паперових носіях (ПД), а на рівні РРП / ЦРП — ЕД.
Загальну структуру СЕП НБУ України можна подати у вигляді схеми, зображеної на рис. 2.4.

Рис. 2.4. Загальна структура СЕП України
Банківський електронний документ — це банківське повідомлення встановленого формату, яке містить у собі інформацію про перерахування коштів і зберігається у файлі на машинних носіях, а також передається у складі файла засобами електронної пошти.
Адресат, отримавши файл платіжних документів, передає на адресу відправника підтвердження у вигляді файла-квитанції, що містить основні характеристики первинного файла, а також результати перевірки (коди помилок, які були виявлені під час отримання файла платіжних документів) з рішенням про те, чи прийнято файл до обробки чи ні.
Банківські повідомлення у вигляді електронних документів мають задовольняти таким головним вимогам.
1. Бути підготовлені, передані та прийняті з використанням програмно-технічних засобів, які сертифіковані й затверджені НБУ. Кожному електронному платіжному документу в АІС КБ автоматично присвоюється ідентифікатор, який включається до його складу і є унікальним у межах даної банківської установи протягом одного банківського дня.
2. Банківські електронні документи мають бути захищені спеціальними засобами, які надаються централізовано Національним банком України, згідно з Положенням про систему захисту електронних банківських документів в обчислювальній мережі Національного банку України та Положенням про арбітражні послуги служби захисту електронних банківських документів в обчислювальній мережі НБУ. Їх захист грунтується на використанні методів ідентифікації вузлів відправника та отримувача повідомлення, його шифрування і дешифрування на основі використання методів криптографії у вузлах-адресатах, а також під час передавання по каналах ЕП, накладання електронного підпису й авторизації відправника та отримувача електронного банківського документа.
Для шифрування і дешифрування ЕД застосовуються як програмні, так і апаратні методи. Так, у АРМ-3 комерційних банків використовується програма шифрування і дешифрування з іменем TRESOR. Вона встановлюється для кожного КБ і його АРМ-3 індивідуально, захищена від можливості копіювання і працює (шифрує або розшифровує підготовлені чи отримані ЕД) з використанням спеціальних індивідуальних «ключів», серед яких немає двох однакових (їх через певний проміжок часу змінює служба безпеки НБУ).
Розробляється і впроваджується також система використання апаратного захисного обладнання — так званих модулів шифрування, які працюють з використанням шифрувального «ключа», що міститься на спеціальній пластиковій картці. Цю картку (вона має вбудований мікропроцесор і забезпечує високий рівень захисту «ключів») видають відповідальним працівникам банку, які мають право підпису банківських платіжних документів.
Використання самої картки передбачає введення додаткової системи паролів для авторизації її користувача.
Крім того, у СЕП існує також система захисту платіжних документів, яка грунтується на проведенні постійного оперативного банківського обліку, контролю та аналізу обсягів і напрямів руху грошових коштів, які «несуть» ЕД на всіх етапах маршруту їх переміщення.
Під час функціонування СЕП між її елементами циркулюють інформаційні потоки різного призначення. Одним із найважливіших і найпотужніших потоків інформації є потік, який складається з файлів платіжних документів, котрі ініціюють переміщення грошових коштів.
Файли-квитанції, які забезпечують і підтверджують правильність проходження потоків платіжних документів, у своїй сукупності створюють потоки підтвердження платежів і є другими після них за потужністю.
Така складна система, як СЕП потребує високого рівня синхронізації роботи її елементів, тому в системі існують потоки зазначеної синхронізації. Файли цих потоків несуть у собі повідомлення ЦРП (воно регламентує регіональним ланкам СЕП характер технологічного режиму та його зміну), а також дані про вибрані режими роботи елементів системи.
У системі електронних міжбанківських платежів циркулюють також потоки аварійних сигналів і контрольної інформації, що присутні на всіх її рівнях.
6.2. Проходження платежів у СЕП
Платіжні документи готуються в АІС комерційного банку. Оскільки для передачі платіжних документів використовується ЕП НБУ, то одиницею обміну даними між елементами СЕП є не окремий платіжний документ, а пакет (конверт) платіжних документів у вигляді файла певного типу. Залежно від результатів перевірки пакета він може або не може бути прийнятий «у цілому» (без вилучення в ньому коректних документів).
Підготовлені в БАІС у вигляді файла типу А документи з початкових міжбанківських розрахунків надходять до АРМ-3, де їх перевіряють на відповідність вимогам, що їх передбачено СЕП. Забраковані на рівні АРМ-3 документи не потрапляють до СЕП. У такому разі АРМ-3 формує для ОДБ БАІС файл помилок типу «О», в якому зазначаються номери забракованих документів файла А та коди виявлених у них помилок.
Якщо результат перевірки, здійснюваної на АРМ-3, позитивний, пакет платіжних документів (файл типу А) із цього ро-бочого місця надходить до АРМ-2 РРП, що обслуговує даний банк.
На АРМ-2 РРП пакет також перевіряється на відповідність прийнятим у СЕП вимогам. Якщо пакет приймається, то платіжні документи з нього просуваються по СЕП далі. У противному разі пакет не приймається загалом без виокремлення в ньому коректних документів. При цьому у файлі-квитанції типу Т про отримання файла типу А, вказуються номери забракованих у ньому документів та кодів наявних у них помилок.
Забраковані на рівні АРМ-2 файли не обробляються і не повертаються до АРМ-3, а зберігаються у відповідних базах даних АРМ-2 і можуть бути використані як довідковий матеріал.
Якщо АРМ-2 забракував файл, припустимою є спроба повторно надіслати на нього файл з таким самим іменем і тим самим змістом. Після того як файл прийнято на АРМ-2, наступні примірники файла з тим самим іменем на цьому робочому місці не розглядатимуться. Квитанція про повторну обробку зазначених файлів також не формується. Відповідальність за розміщення в одному пакеті коректних і некоректних платіжних документів покладається на комерційні банки.
АРМ-2, прийнявши пакети платіжних документів, «розкриває» ці пакети і, перш ніж передати їх далі, групує отримані документи за таким правилом.
Якщо банк-отримувач платіжного документа обслуговується тим самим АРМ-2, то формується пакет (у вигляді файла типу В) безпосередньо для цього банку.
Якщо ж банк-отримувач платіжного документа обслуговується іншим АРМ-2 тієї самої палати, то формується пакет (у вигляді файла типу С), який містить усі платіжні документи від банків даного АРМ-2 для банків АРМ-2 отримувача. Сформований такий пакет надсилається до АРМ-2 РРП.
Якщо ж банк-отримувач обслуговується іншою РРП, то даний платіжний документ включається до пакета (також файл типу С), який містить усі платіжні документи від банків даної РРП для банків РРП-отримувача. Сформований такий пакет відправляється відповідному АРМ-2 відповідної РРП.
АРМ-2 у РРП-отримувачі приймає пакет платіжних документів від АРМ-2 РРП-відправників поряд із пакетами платіжних документів від своїх комерційних банків, розкриває прийняті пакети і відповідно перегруповує вміщені в них документи. Зрештою платіжний документ потрапляє до пакета (файл типу В) для банку-отримувача і відправляється йому в разі його виходу на зв’язок з РРП.
Отже, на рівні РРП отримують «конверти» з платіжними документами, розкривають їх і працюють безпосередньо з документами: формують із них нові пакети, не змінюючи суті та змісту самих документів.
Для однозначного визначення «долі» кожного пакета платіжних документів використовується механізм файлів-квитанцій ЕП НБУ про підтвердження отримання пакета. При цьому кожний АРМ СЕП, який отримав пакет ПД, обов’язково формує файл-квитанцію на нього, в якій зазначається, приймає він цей пакет чи ні (в останньому разі наводяться причини відмови). Файл-квитанція надсилається АРМ-відправникові пакета платіжних документів. Лише після отримання квитанції про прийняття документів абонент-відправник (КБ або РРП) виконує відповідні розрахункові операції, пов’язані з платіжними документами пакета.
На підставі аналізу файлів-квитанцій і пакетів завжди можна встановити факт і час проходження (непроходження) за маршрутом вузлів СЕП кожного відправленого із КБ платіжного документа. На цій базі в СЕП працює система з надання довідок про проходження документів.
Відображення сум платежів при міжбанківських розрахунках на відповідних особових і балансових рахунках забезпечує можливість проведення бухгалтерського обліку і контролю правильності проходження платежів на рівні як КБ, так і РУ НБУ.
Бухгалтерський облік і контроль виконання платежів на рівні КБ здійснюють, як правило, також і ПТК ОДБ.
У СЕП існує й система бухгалтерського обліку, яка забезпечує облік і контроль проходження грошових коштів по міжбанківських розрахунках, в розрізі таких основних операцій.
{І} — списання коштів із кореспондентського рахунка КБ (сума файла типу A).
{ІІ} — зарахування коштів на транзитний рахунок КБ (сума файла типу B).
{ІІІ} — зарахування коштів на кореспондентський рахунок КБ після підтвердження їх отримання (сума файла типу S).
{ІV} — переміщення коштів між різними АРМ-2 одного регіону, тобто зарахування коштів на транзитний рахунок АРМ-2-одержувача (сума файла типу C).
{V} — переміщення коштів між різними АРМ-2 одного регіону, тобто зарахування коштів на внутрішній рахунок АРМ-2-одержувача після підтвердження їх отримання (сума файла-квитанції підтвердження типу R про отримання файла С).
{VІ} — переміщення коштів за межі регіону: зарахування коштів на транзитний регіональний рахунок (сума файла типу C).
{VІІ} — переміщення коштів за межі регіону: зарахування коштів на рахунок регіону в Головній установі НБУ (сума файла типу R).
{VІІІ} — перерахування коштів між регіонами, виконуване в Головній установі НБУ (сума файла типу R).
{ІX} — зарахування на внутрішній рахунок АРМ-2 — одержувача коштів, що надійшли з іншого регіону (сума файла типу R).
{X} — списання коштів із рахунка установи НБУ (сума файла типу A).
{XІ} — зарахування коштів на транзитний рахунок установи Національного банку України (сума файла типу B).
{XІІ} — зарахування коштів на рахунок установи Національного банку України після підтвердження (сума файла типу S).
У разі, якщо платіжний документ був прийнятий у СЕП, але не доведений до одержувача того самого банківського дня, він залишається в одній із РРП, через які проходить, і відправляється одержувачу наступного банківського дня. Суми коштів, які залишилися в РРП, відображаються на відповідних транзитних і технічних рахунках стосовно одержувачів коштів. Отже, із закінченням роботи всієї системи на підставі даних РРП про кошти на зазначених рахунках можна визначити загальний розмір платежів, які залишилися на «ночівлю» у СЕП, хто є їх одержувачами і т.д. Можна також, урахувавши обороти коштів за день, визначати переміщення грошової маси між регіонами тощо.
У забезпеченні нормальної роботи такої складної системи, як СЕП дуже важливими є регламентація етапів технології та узгодження роботи всіх її елементів у часі.
ЦРП працює протягом усіх робочих днів. Упродовж робочого дня ЦРП працює у звичайному режимі з передачі та контролю даних. Основне програмне забезпечення ЦРП — комплекс АРМ-1 працює в автоматичному режимі. Наприкінці робочого дня виконуються зведені баланси міжрегіональних платежів. За умови їх успішного завершення із ЦРП до РРП надсилається дозвіл на виконання технологічного етапу — «Кінець робочого дня».
Коли від усіх РРП отримано сигнал про закінчення робіт, у ЦРП виконуються заключні роботи з формування та передачі до Центрального управління НБУ звітних форм, а також системні процедури, пов’язані із закінченням поточного робочого дня і підготовкою до початку наступного, включаючи архівацію даних тощо.
У РРП до початку робочого дня також виконуються підготовчі системні роботи. До цього часу ОДБ відповідного РУ НБУ передає кожному АРМ-2 інформацію про стан кореспондентських рахунків банків, які ним обслуговуються. Протягом робочого дня в РРП обробляються платіжні дані за загальною технологією. Кожний АРМ-2 РРП працює в циклічному режимі. Інтервал циклу (повної обробки даних) становить від 15 до 30 хв. залежно від кількості прийнятих пакетів і документів у них. Після кожного циклу створюються дублі (копії) баз даних АРМ-2 за станом на кінець технологічного сеансу.
Наприкінці робочого дня за погодженням із ЦРП у РРП виконується етап технології під назвою «Закінчення початкових міжрегіональних оборотів РРП». На цьому етапі вона ще приймає дані від КБ, але акумулює їх і не передає до інших РРП. Отримані суми платежів відкладаються на відповідних рахунках РРП-отримувача. Інформація про виконання цього етапу передається до ЦРП.
Технологічний етап роботи «Кінець робочого дня» для РРП настає після сигналу ЦРП. Цей етап може виконуватися, якщо отримано дозвіл від ЦРП на його виконання і немає відправлених, але не підтверджених РРП-отримувачем міжрегіональних платежів. На цьому етапі в РРП припиняється робота з приймання платіжних документів і виконуються заключні роботи з формування банкам виписок із їх ТКР, передача оборотів по ТКР за день до ОДБ РУ НБУ, передача звітних форм, технічної інформації до ЦРП і т.ін. Виконуються також системні роботи, пов’язані із закінченням робочого дня та підготовкою до початку наступного, включаючи архівацію даних тощо.
Регламент роботи КБ передбачає також виконання етапу «Початок робочого дня», який полягає у встановленні зв’язку його АРМ-3 з відповідним АРМ-2 РРП. Під час першого сеансу зв’язку АРМ-3 отримує від АРМ-2 файл стану кореспондентського рахунка в РУ НБУ, файл коригувань списку учасників СЕП і т.ін.
Початкові платежі з КБ до СЕП дозволяється передавати до початку в РРП технологічного етапу «Кінець робочого дня». До цього моменту протягом дня банк сам визначає і проводить сеанси зв’язку з РРП, а також обробляє здобуті дані.
Етап технології «Кінець робочого дня» здійснюється в КБ за умови, що на всі відправлені файли платіжних документів (файли типу А) отримано від РРП файли-квитанції (типу Т), а також сформовано й відправлено до РРП файли-квитанції (типу S) на всі отримані банком від РРП зворотні платежі (файли типу В).
Ознакою закінчення банком роботи на поточний день є передача ним до РРП файла «Протокольний звіт» (файл типу Z). Якщо цей файл не може бути переданий до РРП через порушення зв’язку, то інформація про закінчення обміну банку з РРП має бути передана в той самий день телефоном.
По закінченні робочого дня в КБ архівують та звіряють дані, видають на друкування реєстри платіжних документів для кожного клієнта і т.ін.
Графік взаємодії РРП із КБ може коригуватися, але повідомлення про це доводиться до банку не менш як за три доби до моменту, коли зміни стануть чинними.
6.3. Інформаційна взаємодія СЕП із банківськоюустановою та регіональним управлінням
6.3.1. Інформаційний обмін СЕПіз комерційним банком
Обробка всіх (тих, що надійшли як безпосередньо від клієнта, так і за допомогою СЕП) платіжних розрахункових документів на рівні КБ виконується за допомогою ПТК «Операційний день банку» (ОДБ). Отже, обмін і взаємодія КБ із СЕП через АРМ-3 зводяться до інформаційного обміну та взаємодії АРМ-3 з ПТК ОДБ і реалізуються через процедуру обміну відповідними файлами встановленої структури.
Усі файли обміну є текстовими (у термінах MS-DOS). Вони мають, по суті, однакову будову і складаються з таких рядків: службового, заголовного та інформаційного:

Усі рядки (службовий, заголовний та інформаційні) закінчуються двома символами переведення каретки (СПК). Оскільки в деяких реквізитах, наприклад в електронно-цифровому підпису, можуть зустрічатися будь-які коди, потрібно розбивати файл на рядки під час його обробки й читання, узявши за основу стандартну довжину рядків, які зазначено в опису того чи іншого типу.
Службовий рядок містить інформацію, що пов’язана з роботою системи й забезпеченням її безпеки та надійності. Його довжина однакова для всіх типів файлів і дорівнює 102 байт разом із СПК.
Заголовний рядок містить у собі інформацію про конкретний файл, про кількість інформаційних рядків у файлі тощо. Для кожного типу файлів він має певну довжину, яка задається у структурі файлів цього типу.
Інформаційні рядки (ІР) мають однакову довжину для кожного (крім М) типу файлів, яка також задається в опису його структури. Деякі типи файлів можуть не мати інформаційних рядків.
Серед файлів обміну основними є файл початкових платежів даного банку до інших банків, так званий файл типу А, і файл зворотних платежів від інших банків, так званий файл типу В.
Файл типу А готується ОДБ банку і приймається ПТК АРМ-3 цього самого банку, а файл типу В приймається ОДБ від АРМ-3, яке, у свою чергу, отримує його від АРМ-2 РРП. Кожний інформаційний рядок файла А несе дані про один платіжний документ. В одному файлі можуть міститися платежі лише одного виду валюти.
Заголовний рядок файла типу А має довжину (разом із СПК), що становить 196 символів, і містить такі основні реквізити: найменування файла; дату і час його створення; кількість ІР у файлі; суму дебету і суму кредиту по файлу; ЕЦП файла і ЕЦП самого рядка та ін.
Довжина ІР файла А становить (разом із СПК) 594 символи. Кількість таких рядків у файлі A обмежена і має не перевищувати 1000. У структурі інформаційного рядка файла А можна виокремити два типи даних: реквізити, які характеризують конкретний платіж, і атрибути, які пов’язані з технологією обробки платежів у СЕП.
До першого типу належать: коди МФО банку-платника (банку А) та банку-одержувача коштів (банк Б); особові рахунки і найменування платника та одержувача коштів; сума і валюта платежу; його призначення; вид і дата платіжного документа; дата надходження документа до банку А і т.ін.
Другий тип включає ідентифікатор клієнта й операціоніста банку А; ЕЦП основних реквізитів платежу; ім’я файла A, порядковий номер ІР у файлі A і т.ін. Усі платежі у файлі A мають ЕЦП та ідентифікатор операціоніста.
Файл B містить інформацію про зворотні платежі на банк Б (отримувач платежів) у СЕП. Кожний його ІР містить дані одного платіжного документа. Структура заголовного та інформаційного рядків файла B така сама, як і структура відповідних рядків файла A.
Протягом банківського дня відбувається, як правило, кілька сеансів передавання та приймання платіжних документів клієнтів на міжбанківське обслуговування і, відповідно, кілька сеансів зв’язку АРМ-3 КБ з АРМ-2 РРП. Щоб забезпечити надійність роботи системи, на кожний відправлений чи прийнятий інформаційний файл типу А або В формується відповідний файл-квитанція типу Т для файла А і типу S для файла В.
Заголовний рядок файла-квитанції типу T містить 330 символів (разом із СПК) і крім даних, які характеризують сам файл Т, включає дані, які характеризують відповідний файл А (найменування файла А, дату і час його створення, кількість ІР у файлі А, суми дебету і кредиту по файлу А, його ЕЦП і т. ін.).
Інформаційний рядок файла Т, якщо він існує, має довжину всього в 12 символів і містить порядковий номер інформаційного рядка файла A і код помилки в ньому. Квитанцію T формує лише АРМ-2.
На отриманий файл B в ОДБ БАІС формується файл-квитанція типу S. Структура його заголовного й інформаційного рядків така сама, як і відповідних рядків файла T.
Зауважимо, що робота в системі передбачає також обмін інформаційно-технологічними файлами розглянутих далі типів.
Файл типу V — файл виписки із технічного кореспондентського рахунка банку за поточний банківський день. Він містить інформацію про значення КР і платежі банку за цей день.
Заголовний рядок цього файла має 427 символів; інформаційний його рядок містить 138 байт, зокрема й дані про один інформаційний рядок файла A або B. Тобто у файлі V відображаються всі інформаційні рядки файлів A і B за поточний день.
На підставі даних файла V в ОДБ КБ можна встановити значення залишків коштів на кореспондентському рахунку на початок наступного банківського дня.
Файл типу U призначений для коригування списку учасників електронних платежів та масиву інвалютних рахунків банків у всіх АРМ СЕП і ОДБ БАІС. Файли U мають послідовну нумерацію протягом року в десятковій системі числення. Номер файла вміщується в розширенні його імені й має вигляд (001, 002,...).
Заголовний рядок файла містить 240 знаків, а інформаційний — 121 знак. Інформаційні рядки можна умовно поділити на дві групи: рядки, які несуть інформацію про зміни в довіднику учасників платежів (S_UCH.DBF), і рядки, які змінюють інформацію в масиві інвалютних кореспондентських рахунків (M_UCH.DBF).
Файл K формується при сеансах зв’язку АРМ-3 з АРМ-2 протягом усього дня. Щоб можна було відстежувати правильність послідовності файлів K, у заголовному рядку поточного файла K вказується номер попереднього файла K. Файл K з розширенням 000 («К.000») містить інформацію за станом на початок банківського дня.
Довжина заголовного рядка файла К становить (разом із СПК) 381 байт. Крім типових реквізитів (ім’я файла, дата і час створення тощо), він містить дані про значення ТКР на початок та на кінець сеансу, поточні значення ЛТК і ЛПО, максимально можливу суму проплати та інші дані, які характеризують поточний стан банку.
Інформаційний рядок файла К має довжину в 141 символ і містить дані про один із файлів А чи В, що надійшли та були оброблені.
Для головного банку, який працює за моделлю з одним кореспондентським рахунком і в якого філії мають свої АРМ-3, в інформаційних рядках файла K наводяться файли як головного банку, так і його філій. Файли розміщуються групами по установах, тобто група файлів ГБ, група файлів 1-ї філії, 2-ї і т.д.
Зарахування грошових коштів по файлу B на ТКР банку виконується ТІЛЬКИ після успішного прийняття АРМ-2 квитанції S про прийняття відповідного файла В в банку. Банк, у свою чергу, інформується про це у файлі K або V.
Отже, кожний технологічний сеанс зв’язку КБ із РРП протягом дня приводить до обміну файлами типу А і Т, В і S та К.
Наприкінці робочого дня в ОДБ БАІС формується файл протокольного звіту про роботу за день типу Z з розширенням «000». Він містить інформацію про роботу банку з АРМ-2 упродовж усього банківського дня.
Переданий до РРП файл Z є сигналом для АРМ-2 про те, що відповідний банк закінчив роботу з приймання/передавання пакетів платіжних документів і квитанцій на них (файлів А,В,Т,S).
Якщо банк працює більш як з однією валютою, то в момент «формування Z» одночасно створюються та відправляються до РРП окремі файли Z за кожною з валют.
Заголовний рядок файла Z має 228 символів і містить дані про загальний розмір дебету і кредиту всіх оброблених за поточний день файлів А і В.
Кожний інформаційний рядок файла Z містить 141 символ і дані про один відправлений файл A або файл B, який надійшов і на який відправлено квитанцію S. Інформаційні рядки файла Z відображають файли лише сьогоднішнього банківського дня. Файл може не мати інформаційних рядків.
Згідно із застосовуваною технологією файл Z може бути сформований лише тоді, коли на всі відправлені файли типу А від АРМ-2 отримано файли-квитанції типу Т, а на всі прийняті файли типу В в ОДБ сформовано й передано до РРП відповідні файли-квитанції типу S.
Крім названих файлів в обміні можуть брати участь і технологічні файли типу «F», «О» та «М».
Файли типу F містять ліміти для філій банку і призначені для управління їх роботою в СЕП з боку головного банку. Вони поділяються на підтипи, різні за структурою та призначенням. Підтип файла визначається першим символом розширення його імені.
Файли підтипу F*.L* призначені для відправлення з головного банку до АРМ-2 значень лімітів, які він встановлює для своїх філій. Заголовний рядок файла має 196, а інформаційний — 75 символів, крім того, він містить код МФО філії та нові значення ЛТК і ЛПО.
Файли підтипу F*.T* призначені для відправлення головному банку із АРМ-2 поточних значень ТКР його філій, лімітів останніх і технологічної інформації про їх роботу. Заголовний рядок цього файла має 199, а інформаційний — 197 символів.
Файл типу О формує АРМ-3 і передає лише до ОДБ БАІС. Це технологічний файл, який призначений для інформування БАІС про причини відбракування файлів, що надходять від ОДБ та АРМ-2. Якщо файл забракований у цілому, то файл O не має інформаційних рядків.
Якщо помилки виявлено в окремих інформаційних рядках забракованого файла, то у файлі O буде стільки інформаційних рядків, скільки помилкових рядків виявлено в первинному файлі.
Заголовний рядок файла О містить 330, а інформаційний — 12 символів.
Файл типу М призначений для забезпечення реалізації сьомої моделі роботи КБ у СЕП. Він несе в собі бізнес-правила, що регламентують роботу філій банку.
Загальну схему обміну файлами між ОДБ та АРМ-3 комерційного банку унаочнює рис. 2.5.
1. Початок банківського дня

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

3. Кінець банківського дня

Рис. 2.5. Схема обміну файлами між банком і СЕП:

Зі створенням інтерфейсу між ОДБ і АРМ-3 не лише підвищується оперативність обробки, а й відкриваються нові можливості отримання в ОДБ, а отже, і в БАІС результативних даних з урахуванням інформації файлів А, В та поточного стану кореспондентського рахунка банку. Тобто зростає ступінь керованості банку.
6.3.2. Зв’язок СЕП із регіональним управлінням НБУ
Згідно з чинним положенням кореспондентські рахунки КБ відкриваються і ведуться у відповідних регіональних управліннях НБУ, а обробляються в ОДБ цих управлінь.
Одночасно в СЕП ведуться технічні кореспондентські рахунки, що слугують для відображення міжбанківських розрахунків, виконуваних через СЕП.
Практично ТКР у СЕП — це інформація в електронній формі, що відбиває зміни стану банківського рахунка, відкритого в балансі регіонального управління НБУ. Стан ТКР банку визначають, виходячи зі значення його реального кореспондентського рахунка на початок дня і сум, проведених ним через СЕП платежів. Якщо не існує інших джерел надходження грошових коштів на кореспондентський рахунок банку окрім як через СЕП, то значення ТКР збігається зі значенням кореспондентського рахунка.
Щоб забезпечити можливість відображення всіх платежів на кореспондентських рахунках банку, організовано обмін даними між АРМ-2 РРП і ОДБ (ОПЕРУ) РУ. Полягає він у тому, що значення кореспондентських рахунків банків за станом на початок банківського дня передаються із ОДБ РУ до АРМ-2 РРП.
На їх підставі АРМ-2 виконує такі дії:
1) інформує комерційні банки про значення їхніх кореспондентських рахунків;
2) відстежує значення цих рахунків під час виконання операцій протягом дня;
3) обмежує приймання платежів від банків.
По закінченні банківського дня обороти із ТКР за день передаються за допомогою файла зв’язку із АРМ-2 до ОДБ РУ. Крім того, АРМ-2 передає до ОДБ підсумки по платежах, що пройшли за цей день через СЕП. На їх підставі ОДБ, у свою чергу, коригує значення кореспондентських рахунків банків.
Комерційні банки отримують інформацію щодо проходження платежів і зміни їх кореспондентських рахунків із двох джерел: виписки із ТКР, яку приймають із АРМ-2, і виписки із ОДБ РУ (її називають «файл-КС»). Дані цих повідомлень мають бути узгоджені.
Для роботи СЕП із різними валютами кожній із іноземних валют присвоюється однобайтовий ідентифікатор (A...Z, 0...9). Довідник валют, які обробляються в СЕП, міститься у файлі S_VAL.DBF. Кожний пакет платіжних документів (файли типу А,В,С) містить документи однієї (і лише однієї) валюти, а імена всіх файлів СЕП (окрім файла типу U) включають також ідентифікатор валюти, якій відповідає зміст файла. Файл U учасників СЕП — єдиний для всіх видів валют. Комерційний банк може відкрити в рамках СЕП один (і лише один) кореспондентський рахунок у кожній валюті.
Імена всіх файлів інтерфейсу АРМ-3 з ОДБ є унікальними (і водночас змінними). Вони мають таку структуру:
vtARxxmd.fnn,
де v — однобайтовий ідентифікатор валюти в СЕП згідно з довідником S_VAL.DBF СЕП. Для національної валюти України v = «$». t — тип файла в СЕП. Нині в інтерфейсі можливі такі типи: A, T, B, S, K, Z, V, F, M, U, O. Із розвитком системи список типів файлів розширюватиметься; ARxx — ідентифікатор банку-учасника в СЕП.; m — місяць банківського дня; d — номер банківського дня місяця m. Значення m і d подаються в тридцятьшістковій системі числення (1,2,...,9,A,B,C,...,U,V); f — функціональний підтип для файлів типу F і M; nn — технологічний номер файла в тридцятьшістковій системі числення (00 ... ZZ).
Ім’я файла під час його передавання по маршруту та обробки в СЕП не змінюється, а ім’я файла-квитанції формується з імені основного файла заміною символу t (тип файла) на відповідний тип квитанції (наприклад, А на Т, В на S).
Завдяки запровадженій структурі імен файлів у СЕП організовано обробку лише файлів своїх типів і за певний день. Імена файлів широко застосовуються й для організації контролю та аналізу платежів, ідентифікації учасників і створення й ведення архівів даних як на рівні СЕП, так і в самих КБ.
6.4. Основні напрямки розвитку системи міжбанківських електронних платежів
Система міжбанківських електронних платежів НБУ України дедалі вдосконалюється й розвивається. Підвищується ступінь захищеності даних і зростає надійність роботи системи, програмні системи криптографування замінюються на апаратні засоби захисту, створюються й впроваджуються засоби перехресного захисту електронних платежів — накладання «електронного підпису» на документі різними виконавцями і т. ін.
Триває також створення в Україні на основі існуючої СЕП платіжної системи нового покоління (ПСНП), яка має враховувати перспективні потреби банківської сфери України та світовий досвід.
У ПСНП можна буде здійснювати грошові перекази в режимі реального часу (оn-lіеn) і працювати в пакетному режимі (оff-lіеn).
У новій системі буде також забезпечено можливість виходу в міжбанківську платіжну систему SWІFT, платіжні системи країн СНД. ПСНП матиме інтерфейс з усіма загальнодержавними електронними системами розрахунків, які застосовуватимуться на території України в майбутньому (система фондового ринку, національна система масових електронних платежів із використанням розрахункових карток тощо).
Розглянемо основні елементи ПСНП.
1. Головна книга (ГК) НБУ, яка вестиметься централізовано під управлінням інтегрованої банківської системи (ІБС). Кореспондентські рахунки банків при цьому являтимуть собою складову частину ГК.
2. Система моніторингу (управління) рахунків (СМР), яка разом з ІБС проводить моніторинг кредитними, технологічними й транзитними рахунками, що пов’язані з міжбанківськими платежами.
3. Система термінових платежів (СТП). За її допомогою банки проводять платежі великими сумами та термінові платежі.
4. Традиційна система міжбанківських електронних платежів (СЕП) як система клірингових розрахунків (СКР).
Платіжна система нового покоління зберігає та розвиває можливості й принципи існуючої системи електронних платежів. Зокрема, ПСНП базується на цілком безпаперовій технології і так само як і СЕП, є системою типу «брутто». Отже, кожній платіжній транзакції однозначно відповідає платіжний документ, який транспортується одержувачеві. Платіжні транзакції ніким не можуть бути відкликані. Не існує окремих обмежень на суми транзакцій.
Функціональну схему нової системи унаочнює рис. 2.6.

Рис. 2.6. Функціональна схема платіжної системи нового покоління
Головні завдання нової платіжної системи такі.
1. Повніше забезпечення керівництва НБУ (для прийняття рішень щодо монетарної політики) оперативною та точною інформацією про переміщення грошових коштів і стан кореспондентських рахунків банків.
2. Скорочення витрат часу на виконання міжбанківських розрахунків та прискорення обігу грошових коштів, особливо великих сум.
3. Зменшення вартості банківського посередництва шляхом оптимізації платіжних засобів і раціоналізації системи.
Система передбачає для НБУ широкі можливості керування кореспондентськими рахунками банків і управління банківською діяльністю.
Для забезпечення безперервності процесу міжбанківських розрахунків на першому етапі створення ПСНП інформація із СТП до програм ОДБ банків-учасників має передаватися в існуючих на поточний момент форматах файлів обміну даними між ОДБ і СЕП.
ТЕМА 7. МОДЕЛІ РОБОТИ КОМЕРЦІЙНИХ БАНКІВ У СЕП
7.1. Характеристика «нульової» та «першої» моделей роботи комерційних банків у СЕП
У системі міжбанківських електронних платежів НБУ існує кілька моделей обслуговування комерційних банків. Застосування тієї чи іншої моделі обслуговування та взаємодії КБ із СЕП визначають здебільшого з огляду на такі чинники:
1. Спосіб взаємодії головного банку з його філіями. Можливі такі варіанти:
головний банк і всі філії є учасниками СЕП, мають свої АРМ-3 і взаємодіють між собою через СЕП;
банк має свою систему передачі даних, використовувану для взаємодії головного банку з його філіями;
для взаємодії та обміну даними між головним банком і філіями використовується ЕП НБУ (або інша мережа).
2. Організаційна структура КБ і кількість рівнів підпорядкованості. Можливі такі варіанти:
банк не має підлеглих філій;
існують два рівні підлеглості: головний банк — філії;
існують три рівні підлеглості: головний банк — регіональні управління — філії.
3. Розміщення головного банку та філій за адміністративними регіонами країни: усі вони містяться або в одному, або в кількох регіонах.
Отже, з огляду на кількість значень цих факторів загальна кількість можливих моделей такого розміщення досягає 18. Проте оскільки для однорівневих КБ можливий лише один (а не три) спосіб взаємодії із СЕП (через АРМ-3) і розміщені вони лише в одному регіоні, моделей буде 15.
Нині в СЕП розроблено вісім моделей, і кожний з банків працює за однією з них. Розглянемо основні характеристики та особливості цих моделей.
Так звана «нульова» модель передбачає, що як головний банк, так і всі його філії територіально розміщені в одному регіоні й обслуговуються однією РРП. При цьому всі вони мають відкриті окремі кореспондентські рахунки в РУ НБУ і ТКР у РРП цього самого управління. Передбачається також, що як головний банк, так і всі його філії мають АРМ-3 і коди МФО.
Скориставшись позначеннями: КБ — комерційний банк, ГБ — головний банк, Ф — філія головного банку, формально-логічні умови роботи банку за цією моделлю запишемо в такому вигляді.
1. ГБ і всі Ф ( Р, де Р — регіон.
2. Для ГБ і всіх Ф існують КР у РУ НБУ (КР — кореспондент-ський рахунок).
3. Для ГБ і всіх Ф існують ТКР у РРП РУ НБУ.
4. ГБ і всі Ф мають окремі ПТК АРМ-3 і коди МФО.
У разі роботи за цією моделлю як ГБ, так і філії є рівноправними учасниками СЕП і мають однакові можливості взаємодії з іншими учасниками системи, хоча головному банку надходить інформація про роботу його філій у СЕП.
Платежі філій відображаються на різних ТКР і різних КР, причому СЕП майже не дає засобів управління процесом здійснення платежів у філіях з боку ГБ. Окрім того, грошові кошти банку розподіляються між кількома КР, що також ускладнює управління ними. Саме і через це доцільно було створити «першу» модель.
«Перша» модель, як і «нульова», передбачає, що всі установи банку містяться в одному регіоні й обслуговуються однією РРП. Але філії не мають відкритих кореспондентських рахунків у РУ НБУ, що накладає певні особливості на технологію обслуговування їх міжбанківських платежів.
Формально-логічні умови роботи банку за «першою» моделлю можна записати так.
1. ГБ і всі Ф містяться в одному регіоні.
2. Для ГБ виконуються умови:
1) ГБ має відкритий КР у РУ НБУ і код МФО;
2) для ГБ існує ТКР у РРП;
3) у ГБ функціонує АРМ-3.
3. Для всіх філій ГБ, які є в регіоні, виконуються умови:
1) кожна філія має МФО;
2) філії не мають відкритих КР в РУ НБУ;
3) кожна філія має ТКР в РРП РУ НБУ;
4) кожна філія має свій ПТК АРМ-3.
Через відсутність у філій банку відкритих КР вони всі разом із ГБ працюють через один консолідований кореспондентський рахунок (ККР). Консолідованим називають такий кореспондентський рахунок, на якому відображаються міжбанківські розрахунки більш як однієї банківської установи. Кошти на цьому рахунку обліковуються так, що внесок кожної окремої філії у зміну його загального значення не розглядається. Отже, усі наявні ресурси банку перебувають на одному рахунку, що дає змогу ефективніше управляти їх використанням.
Субкореспондентські рахунки філій ведуться в головному банку засобами його ОДБ на підставі інформації, що надається йому СЕП.
Під час роботи за цією моделлю ТКР кожної філії на початок банківського дня набуває значення 0, а протягом банківського дня дорівнює різниці між відповідними і початковими оборотами цієї філії.
ТКР головного банку дорівнює значенню реального КР на початок дня, отриманому від ОДБ РУ НБУ, плюс денні залишки його і філій за цей день.
Під час роботи за цією моделлю відправлення й отримання платежів одночасно відображуються на ТКР головного банку і на ТКР тієї філії, яка відіслала або отримала платіж.
ГБ має змогу керувати роботою своїх філій у СЕП, задаючи їм ліміти в режимі реального часу. Для кожної філії головним банком можуть задаватися ліміти, як на величину поточного значення залишку (овердрафт) на ТКР (ЛТК) цієї філії, так і на суму (денних) початкових оборотів (ЛПО).
Кількість змін лімітів протягом дня є для філій технічно обмеженою і не може перевищувати 99. Головний банк обирає способи організації роботи та задання лімітів своїм філіям. Він може, зокрема, вдаватися до таких дій:
заборонити проведення платежів філією до отримання інформації з ГБ про розмір ліміту на даний банківський день;
установлення початкового нульового значення ліміту; у такому разі платежі ведуться або в межах значень ТКР філії, або значення ТКР її ГБ;
перенесення ліміту з кінця попереднього на початок поточного дня і дозвіл працювати з ним;
дозвіл проводити платежі в межах ТКР ГБ.
За допомогою технологічного файла типу К після кожного сеансу зв’язку з РРП для філії передається інформація про розміри поточного залишку на її ТКР та її лімітів.
Під час сеансу зв’язку з РРП у складі файла К до ГБ передаються як дані про стан ККР банку (без розрізнення впливу окремих філій, на загальну суму), так і дані про пакети платіжних документів самого банку та його філій. Завдяки цьому головний банк має змогу вести в себе субкореспондентські рахунки своїх філій.
Крім того, до ГБ із СЕП в інформаційних рядках файла виписок (файл типу V) надходять дані як про його платежі, так і про платежі філій. Це дає змогу ГБ перевіряти початкові та відповідні платежі філій, а також їх субкореспондентські рахунки.
На початок дня файл К.000 містить для ГБ дані про значення єдиного рахунка, а для філій ще й дані про ліміт для їх роботи.
Наприкінці кожного сеансу зв’язку до ГБ крім файла типу К з АРМ-2 передається додатковий файл типу F*.Т, що містить дані про поточні значення ТКР і лімітів його філій. Із цього видно, з якими лімітами працювали філії. Інформаційні рядки цього файла містять реквізити: МФО філії, поточне значення її ліміту та значення ТКР, а заголовний рядок включає суму всіх лімітів та залишків філій. Якщо філії обмінялися між собою платежами, то у файлі виписок V для ГБ такі платежі зустрінуться двічі: у групі початкових платежів філії і групі зворотних платежів.
Головний банк може здійснювати платежі в рамках значень єдиного кореспондентського рахунка, а філії — у рамках своїх ТКР (з урахуванням установлених лімітів).
Файл початкових платежів (типу А) СЕП приймає від філії в обробку, якщо він задовольняє всі вимоги, які випливають із ЛТК і ЛПО, установлених для даної філії:
а) поточний залишок філії мінус сума кредиту файла A плюс сума дебету файла A є не меншими за його ЛТК;
б) сума кредиту всіх відправлених за день файлів типу A певної філії мінус сума дебету всіх відправлених за день таких файлів плюс сума кредиту даного файла A і мінус сума його дебету не перевищують ЛПО цієї філії.
Крім того, файл типу А, що його відправляє філія, має задовольняти вимоги, які випливають зі значень ЛТК і ЛПО, встановлених для консолідованого КР.
Отже, файли А від ГБ перевіряють на виконання однієї умови, а такі файли від філій — на виконання трьох умов. Якщо файл А філії-відправника не задовольняє одну з них, то філія отримує файл-квитанцію з повідомленням про вихід у «жовте сальдо» і початкові її платежі в цьому сеансі зв’язку не приймаються. Тим часом інші філії працюють нормально. У разі надходження зворотних платежів на адресу філії та зміни залишку на її ТКР або зміни лімітів її робота щодо початкових платежів може бути відновлена. Можна також змінити загальну суму кредиту файла А для виходу із «жовтого сальдо» в іншому сеансі зв’язку.
Ліміти для філій ГБ задає або змінює протягом банківського дня, посилаючи до РРП файл типу F*.L. Його інформаційний рядок містить код МФО філії та нове значення її ліміту. У РРП на підставі цього файла негайно коригуються значення лімітів філій. Якщо МФО філії у файлі немає, то її ліміт лишається без змін.
Заповнюючи документи та формуючи будь-який масив типу А як відправника, можна проставляти МФО ГБ або філії незалежно від банку-одержувача. Що ж до банку-одержувача, то ним може бути МФО як ГБ, так і будь-якої філії.
7.2. Характеристика «другої» та «третьої» моделей роботи комерційних банків у СЕП
«Друга» модель роботи банку в СЕП так само, як і «перша», належить до регіональних моделей з єдиним кореспондентським рахунком. Але тут на відміну від «першої» моделі філії банку мають лише номер МФО.
Формально-логічний опис цієї моделі за першими двома пунктами збігається (крім п. п. 3.3 і 3.4) з описом «першої» моделі, а два останні пункти мають такий вигляд:
3) філії не мають ТКР в РРП РУ НБУ;
4) філії не мають АРМ-3.
Принципова різниця між «першою» і «другою» моделями полягає в тому, що під час роботи за «другою» моделлю всі філії банку взаємодіють із СЕП через АРМ-3 ГБ. Інших АРМ-3 у системі банку немає, тоді як згідно з «першою» моделлю АРМ-3 є в кожній філії банку, і вона сама виходить у СЕП.
Отже, платежі між філіями банку не відображаються в СЕП, а взаємодія ГБ і філій ГБ відбувається в кілька етапів.
1. Філії доставляють свої платіжні документи до відповідного ГБ. (Способи доставки можуть бути різними: кур’єром — паперові ПД, а також паперові ПД з копією на машинних носіях (дискети, НМЛ); по каналах зв’язку — у формі електронних документів).
2. ГБ групує документи, які надійшли до нього від філій, поділяючи їх на групи «міжфілійні платежі» та «інші».
3. Документи «інші», тобто ті, одержувачами яких є інші банки, у ГБ оформляються як файл початкових платежів (тип А) і відправляються до СЕП через АРМ-3 головного банку.
Аналогічно всі платежі інших банків до ГБ та його філій надходять від СЕП до АРМ-3 ГБ у вигляді файлів зворотних платежів (файл типу В). Розподіл та групування отриманих документів по філіях і їх доставка в філії-одержувачі реалізується засобами ГБ.
Отже, за такою технологією СЕП приймає пакети початкових платежів лише від ГБ і надсилає пакети зворотних платежів лише на ГБ, філії не мають безпосереднього зв’язку із СЕП, оскільки не оснащені АРМ-3, хоча можуть мати абонентський пункт ЕП НБУ. Усі звітні повідомлення СЕП також формуються і подаються лише для ГБ і включають дані про всі платежі, проведені останнім і його філіями через СЕП.
Усі файли СЕП, якими обмінюється ГБ і РРП, містять «електронну адресу» лише ГБ. При цьому у файлах типу А містяться первинні платежі як ГБ, так і його філій. Порядок розміщення платежів може бути вільним. У файлах типу А як МФО банку-відправника можуть бути зазначені МФО ГБ та МФО його філій, але вони не можуть бути вказані як МФО банку-одержувача, оскільки це означатиме помилку типу «платіж сам на себе». Аналогічно у файлі В як МФО банку-одержувача можуть бути зазначені як ГБ, так і його філії.
У файлі виписок для головного банку (тип V) містяться всі початкові та зворотні платежі як головного банку, так і його філій. Порядок, в якому платежі вміщені у файлі виписок, такий самий, як у файлах A і B.
У разі об’єднання банків, під час реорганізації системи управління або за інших умов можливе переведення банківської установи з роботи за «нульовою» чи «першою» моделлю на роботу за «другою» моделлю. При цьому банківська установа усувається як безпосередній учасник СЕП і працює в СЕП «опосередковано» через свій ГБ. З огляду на це слід забезпечити відсутність у СЕП платежів, які були адресовані безпосередньо їй як учаснику СЕП. Для цього протягом приблизно трьох днів виконується відповідна робота в АРМ-1, АРМ-2 і ОДБ РУ НБУ.
Модель номер «три» є аналогом «другої» моделі для міжрегіонального рівня. Формалізовано її можна подати так:
1. ГБ є в регіоні Р1, Ф є в регіонах Рі, і = 1, 2, 3, ...
2. Для ГБ і всіх Ф існують свої МФО.
3. Для ГБ існує:
1) КР у РУ НБУ регіону Р1;
2) ТКР у РРП регіону Р1;
3) ГБ має ПТК АРМ-3.
4. Для всіх філій виконуються умови:
1) Філії не мають КР у РУ НБУ.
2) Філії не мають ТКР у РРП РУ НБУ.
3) Філії не мають АРМ-3.
Рух сум платежів, як і в «другій» моделі, обліковується за місцезнаходженням ККР ГБ, без виділення вкладу окремих філій. Субрахунки філій у ГБ ведуться засобами його ОДБ. Філії мають власний МФО і занесені до списку учасників платежів. ГБ має АРМ-3 і через нього виконуються міжбанківські платежі як його власні, так і філій. За «третьою» моделлю працюють, як правило, банки, котрі мають свою електронну систему передачі даних і можуть її використовувати для проведення міжфілійних розрахунків.
Технологія взаємодії ГБ та його філій за «третьою» моделлю така сама, як і за «другою», з тією лише різницею, що для доставки документів від філій до ГБ тут використовуються, здебільшого, відповідні електронні системи передачі даних. Ця модель може бути реалізована як на своїй технічній базі, так і з використанням існуючих ЕСПД, у тому числі й ЕП НБУ, ІНТЕРНЕТ і т.ін.
Особливості формування файлів СЕП за «третьою» моделлю такі самі, як і за «другою», але навантаження на АРМ-3 в ГБ тут значно більше. Через це доводиться висувати деякі особливі вимоги до організації його роботи. Наприклад, для зв’язку ГБ із РРП використовуються, як правило, виділені канали зв’язку тощо.
7.3. Особливості роботи комерційних банків у СЕП за іншими моделями
Як показала практика, іноді постає потреба керувати платежами за правилами «першої» моделі для банків, філії яких розташовані в різних регіонах. З цією метою застосовують модель номер «чотири».
Робота цієї моделі базується на понятті «віртуального регіону», що тлумачиться як умовне «об’єднання» всіх філій і установ певного банку в межах регіону, де розташована РРП, яка обслуговує його ГБ. Головна ідея моделі полягає в тому, щоб у РРП регіону, де є ГБ, обробляти дані про платежі всіх його філій незалежно від їх фактичного місцезнаходження. Тобто умовно переводити їх до РРП, де є ГБ. Останній може за правилами «першої» моделі встановлювати ліміти для своїх установ і отримувати для контролю відповідні дані.
За такого підходу всередині «віртуального регіону» збільшуються потоки інформації, завантаження каналів зв’язку і ЕП НБУ, оскільки створюються додаткові файли для філій, які розташовані не в регіоні ГБ.
Описані щойно моделі обслуговують КБ з одно- і дворівневою структурою. «П’ята» модель призначена для КБ із трирівневою структурою. Під час роботи за цією моделлю з групи установ банку, які розташовані в одному адміністративному регіоні, виокремлюється одна — так зване регіональне управління. Інші установи цього банку в розглядуваному регіоні вважаються його філіями і безпосередньої участі в СЕП не беруть. Кожна з філій підпорядкована одному й лише одному регіональному управлінню.
У разі роботи за «п’ятою» моделлю головний банк взаємодіє з регіональними управліннями через СЕП за «першою», а регіональні управління із своїми філіями за «другою» моделлю. Отже, у РРП ГБ відкрито ТКР цього банку, а також усіх його регіональних управлінь, причому ГБ у файлах СЕП (типу K, F.T ,V) дістає інформацію про роботу регіональних управлінь у цілому і не «бачить» їхніх філій.
На початок кожного банківського дня ТКР регіонального управління беруть таким, що дорівнює «0», а обороти коштів регіонального управління включають у себе й обороти його філій, причому вклад кожної з них не виокремлюється (з точки зору СЕП).
«Шоста» модель роботи банків у СЕП, так само як і «п’ята», передбачає виокремлення регіональних управлінь і філій, кожна з яких підпорядкована лише одному регіональному управлінню.У цій моделі на відміну від «п’ятої» не лише ГБ взаємодіє з регіональними управліннями за «першою» моделлю, а й регіональні управління за нею взаємодіють зі своїми філіями через СЕП.
При цьому ГБ не має змоги безпосередньо керувати роботою окремих філій, але він дістає із СЕП (у файлах типу K, F.T ,V) інформацію про роботу як регіональних управлінь, так і їх філій.
«Сьома» модель є розширенням «четвертої» в тому розумінні, що ГБ має можливість обмежувати не лише категорії початкових виконуваних філіями платежів, а й операції на окремих балансових і особових рахунках усередині АІС філії з допомогою механізму бізнес-правил.
Бізнес-правила (БП) — це система задання логічних і бухгалтерських обмежень на платіжні й інші операції в системі електронних розрахунків НБУ і АІС банку. Сукупність БП являє собою базу знань, яка може встановлюватися та змінюватися. Вона реалізується у вигляді спеціалізованої захищеної бази даних і правил, яка модифікується й використовується за цілком певною технологією.
Кожне бізнес-правило визначає заборону на виконання певної платіжної транзакції. Якщо платіжний документ належить до такої транзакції (задовольняє розглядуване бізнес-правило), то його виконання блокується системою. Платіжний документ приймається до виконання, якщо він не відповідає жодному бізнес-правилу, які діють у даний момент.
Головний банк визначає, які зміни мають бути виконані в базі бізнес-правил філії. Ці зміни формуються у вигляді операторів мови БП і надходять до філії також за допомогою СЕП у складі файлів типу М. У філії послідовність операторів БП обробляють, і на підставі результатів такої обробки вносять зміни до складу бази БП. Якщо за допомогою БП забороняється виконання якоїсь множини платіжних транзакцій, то вона діє як на міжбанківські платежі (СЕП), так і на внутрішньобанківські проводки в АІС, включаючи роботу клієнта в системі «клієнт—банк».
Файли бізнес-правил і змін до них, які транспортуються у файлах СЕП типу M, регламентують роботу БАІС, АРМ-3 і АРМ-2, що обслуговує КБ.
Зауважимо, що загальна тенденція використання банками моделей випливає з тенденції, згідно з якою кожний банк намагається досягти дедалі вищої керованості власних грошових ресурсів, а тому виконується, як правило, перехід від «нульової» моделі до «першої», далі до «другої» (з розширенням банку) «третьої» і т.д. Щодо «четвертої» і «сьомої» моделей, то їх правомірно розглядати як тимчасовий варіант роботи банку, що може привести згодом до переходу до інших моделей або до безмодельної роботи КБ.
Зазначені моделі є основними. Подальша практика експлуатації СЕП і розвиток банківської діяльності можуть привести до розробки й нових моделей обслуговування банків.
Для кожного банку номер моделі, за якою він обслуговується, і залежність між його установами наводяться в довіднику учасників платежів СЕП (S_UCH.DBF). Цей довідник крім номера моделі містить код МФО банківської установи, її електронну адресу, статус (ГБ або філія), відомості про ієрархію підпорядкованості.
Перехід на будь-яку з моделей обслуговування чи зміна номера моделі, структури підлеглості філій виконується згідно із заявкою ГБ. Центральна розрахункова палата приймає рішення про день переходу, формує і надсилає файл типу U на коригування списку учасників електронних платежів. ЦРП при потребі може розіслати окремі технологічні інструкції, які є обов’язковими до виконання всіма учасниками СЕП і розрахунковими палатами.
ТЕМА 8. МІЖНАРОДНА ЕЛЕКТРОННА МЕРЕЖА МІЖБАНКІВСЬКИХ РОЗРАХУНКІВ
8.1. Призначення та основні можливості системи
Уже наприкінці 60-х років стало очевидним, що потужностей «паперових» систем банківських розрахунків замало для забезпечення надійного й швидкого зв’язку між банками та їх філіями в різних країнах. Становище ускладнювалося й через те, що різні банки використовували різні, часто практично несумісні системи розрахунків. З огляду на це й постала потреба створити «єдину мову» фінансових повідомлень і єдину систему їх передачі. Товариство міжнародних міжбанківських комунікацій СВІФТ (абревіатура утворена першими літерами англійської назви), засноване у травні 1973 року, почало створювати відповідну систему передачі банківських повідомлень, яка отримала таку саму назву.
Система СВІФТ — одна з найвідоміших комп’ютерних мереж, які було створено з ініціативи фінансових організацій. Станом на 1998 рік до мережі було підключено понад 6000 учасників із більш як 170 країн світу. Останнім часом до системи підключаються й банківські установи країн СНД, зокрема України.
Системи обробки банківських операцій можна поділити на два типи. До першого типу належать системи, в яких виконується оперативне пересилання та зберігання міжбанківських документів, а до другого — системи, в яких виконуються також функції, безпосередньо пов’язані з виконанням взаємних вимог і зобов’язань банків.
Система СВІФТ належить до першого типу систем.
Прикладом систем другого типу може бути система електронних міжбанківських розрахунків (СЕП) Національного банку України.
Головна мета створення СВІФТ і її основна функція полягають у тому, щоб надавати своїм користувачам цілодобовий доступ до високошвидкісної мережі передачі банківської інформації за умови високого ступеня контролю та захисту від несанкціонованого доступу.
Система СВІФТ базується на використанні єдиної мови, забезпечуючи єдину організацію обробки інформації, її захист і швидку передачу. Вона працює 24 години на добу і 365 днів у році. У разі, коли відправник і одержувач повідомлення працюють у мережі одночасно, то доставка повідомлення виконується протягом не більш як 20 секунд.
8.2. Концепція формування та передачі повідомлень
Система СВІФТ — типовий приклад використання мережі пакетної комутації. Дані передаються по мережі у вигляді структурованих повідомлень, кожне з яких призначене для виконання певної фінансової операції. Для кожного підключеного вузла та банку система індивідуально підтверджує приймання повідомлення та його обробку.
Особливістю СВІФТ є використання єдиних для всіх користувачів правил і понять. Єдина ділова мова поряд із можливістю підключення користувачів до єдиної всесвітньої мережі телекомунікацій перетворюють цю систему на важливий інтеграційний чинник сучасного фінансового світу. Розроблені типи повідомлень охоплюють сферу переміщення платежів клієнтів, міжбанківський рух платежів, дані про торгівлю грошима та валютою, виписки з поточних рахунків банків тощо.
Усі платіжні повідомлення вводяться в систему в стандартному форматі, який спрощує автоматизовану обробку повідомлень та їх розуміння отримувачем, виключаючи можливість різного тлумачення повідомлень відправником і одержувачем. Переваги стандартизації настільки очевидні, що стандартні тексти повідомлень СВІФТ стають стандартами «де-факто» для фінансових повідомлень.
Для забезпечення єдності підходу всі повідомлення поділено на 11 (0, 1, ..., 9, n) категорій, які охоплюють більш як 130 типів повідомлень. До 0-ї категорії належать системні повідомлення, які дають змогу взаємодіяти системі з користувачем. Такі повідомлення застосовуються для запитів щодо певних дій і отримання спеціальних звітів, для пошуку повідомлень у базі даних, для навчальних і тренувальних цілей.
До категорій 1—9-ї належать типи повідомлень, які призначено для визначення операцій, безпосередньо пов’язаних із банківською діяльністю. Категорії мають таке призначення: 1-а — операції з обслуговування клієнтів; 2-а — міжбанківські операції; 3-я — валютні операції; 4-а — акредитиви; 5-а — цінні папери; 6-а — операції з дорогоцінними металами, 7-а — документальний кредит, 8-а — дорожні чеки і 9-а — спеціальні повідомлення, пов’язані з банківськими операціями (запит, звіт, підтвердження тощо). Категорія n містить повідомлення загальної группи.
Будь-яке повідомлення в системі СВІФТ утворюється з чотирьох складових: заголовок, текст, посвідчення і закінчення.
Заголовок містить адресну інформацію, необхідну для доставки повідомлення, зокрема код одержувача (11 знаків), код термінала-відправника (поточний п’ятисимвольний номер, який виконує контрольну та захисну функції), трисимвольний код типу повідомлення і т.ін.
Тип повідомлення в системі визначається його трицифровим номером, в якому перша цифра визначає номер категорії, а останні дві — номер типу в категорії. Наприклад, код повідомлення 100 означає операцію «переказ за дорученням клієнта»; 200 — переказ за рахунок коштів банку; 300 — підтвердження валютної угоди тощо. Код Х99 у всіх категоріях означає вільний формат.
Для позначення валюти в повідомленнях застосовують трисимвольний код, в якому перші два символи визначають країну, а третій — валюту цієї країни. Наприклад, німецька марка буде закодована як «DЕМ».
Текст банківського повідомлення складається з послідовності полів, які заздалегідь пронумеровані двоцифровими кодами. Скажімо, 32 — сума, 70 — призначення платежу, 71 — за чий рахунок комісія, її сума тощо. Залежно від типу повідомлення поля можуть бути обов’язково заповнюваними або заповнюваними за вибором.
Посвідчення має гарантувати, що текст повідомлення не буде спотворений у процесі передавання. Фактично посвідчення відіграє роль «контрольної суми» і є, по суті, електронним підписом повідомлення.
Остання складова повідомлення — закінчення, слугує для визначення кінця повідомлення.
8.3. Структура системи та призначення її основних елементів
Структура системи СВІФТ має два рівні. На верхньому (першому) рівні вона містить два Операційні центри (ОЦ), один з яких розташований у США, другий — у Голландії. Другий рівень утворюють регіональні процесори (РП), які розміщені в більшості країн, чиї банки вступили до СВІФТ. Україна разом із деяким іншими країнами Східної Європи підключена до австрійського РП.
ОЦ становлять ядро системи й пов’язані з відповідними регіональними процесорами та між собою. Користувачі, включаючись до системи, з’єднуються з відповідним РП по виділених каналах зв’язку. Кожний РП відіграє роль концентратора повідомлень, через який останні передаються до ОЦ.
Обидва ОЦ мають продубльоване устаткування. Надійність їх роботи при цьому оцінюється в 99,995%.
До основних функцій ОЦ можна віднести ще й такі: збір інформації про роботу апаратури та програмного забезпечення СВІФТ (у тому числі й про збої та поломки); управління процесом відновлення після збоїв; динамічний розподіл ресурсів системи та розсилання нового програмного забезпечення і баз даних.
Для зв’язку РП із ОЦ використовуються виділені міжнародні лінії передачі даних. Зв’язок між ОЦ здійснюється по підводних і космічних каналах, причому СВІФТ має для цього власний геостаціонарний супутник над територією США. Загальну структуру СВІФТ унаочнює рис. 2.7.

Рис. 8. Схема загальної структури СВІФТ
Із термінала банку-учасника системи через модем по національній мережі передачі даних повідомлення надходить до РП. Відповідальність за перевірку, достовірність і правильність такого повідомлення покладається на зазначені банки.
До основних функцій РП належать також: контроль правильності вхідних повідомлень; перевірка посвідчень (контрольних сум) повідомлень; передача позитивних або негативних підтверджень користувачам.
Усі користувачі системи мають свою адресу, за якою вони й відомі системі. Кожна така адреса відповідає певному основному РП, а саме тому, через вузол якого вона входить до системи.
8.4. Безпека передаваннята обробки повідомлень, фінансові витратиз підключення та роботи в системі
Безпека обміну повідомленнями дуже важлива для нормальної банківської діяльності. Саме тому їй приділяється велика увага і в системі СВІФТ. Високий рівень безпеки роботи системи досягається організаційними, програмними, технічними й технологічними засобами.
Організаційну гарантію безпеки та надійності роботи системи бере на себе Генеральна Інспекція — група спеціалістів, до обов’язків якої входить перевірка діяльності всієї компанії та її підрозділів. Ця структура підпорядкована безпосередньо лише Раді директорів, яка є виконавчим органом СВІФТ.
До всіх приміщень існує режим обмеженого та контрольованого доступу. Крім того, співробітники центрів працюють і переміщуються в обмежених їхніми обов’язками робочих зонах. Існують також спеціальні інструкції на випадок пожежі, терористичних актів, витікання газу, збоїв у живленні і т.ін.
На програмному рівні спеціальна система автоматично виявляє випадки несанкціонованого доступу або необгрунтованого проникнення в роботу регіонального процесора. Автоматично фіксуються й аномалії та відхилення від норм параметрів системи.
Крім того, кожному повідомленню при його вводі в систему автоматично присвоюється послідовний вхідний номер, а при виводі — вихідний. Повідомлення, які вводяться до системи з порушенням послідовності цих номерів, з відхиленнями від чинного стандарту, протоколу або формату, відкидаються.
Усі пересилання повідомлень на міжнародних лініях зв’язку кодуються СВІФТ з використанням шрифтів (вони діють і змінюються через випадкові проміжки часу) та спеціальних криптографічних пристроїв. Високий рівень безпеки забезпечується також системою контролю доступу до мережі, яка включає в себе місцеві паролі для вузлів, смарт-картки доступу, журнальні файли, в яких зберігається інформація про кожне підключення до мережі тощо. За час існування системи не було зареєстровано жодного випадку її «злому».
Фінансові витрати абонентів з підключення та використання системи можуть бути поділені на одноразові, щорічні та поточні на передавання повідомлень.
До одноразових витрат можна віднести вступний внесок у 400 тис. бельгійських франків, або приблизно 12 500 дол. США та оплату однієї акції вартістю в 1500 дол. США, а також витрати на придбання програмного (у сумі близько 100 ( 15 тис. дол. залежно від фірми-постачальника) та технічного забезпечення (у сумі близько 70 000 дол.).
В Україні до одноразових витрат потрібно додати й витрати (близько 1000 дол.) за підключення до мережі УКРПАК як телекомунікації СВІФТ. Отже, для початку роботи в системі СВІФТ потрібно заплатити близько 185 000 дол.
Щорічні витрати пов’язані із супроводженням програмного та технічного забезпечення, підготовкою спеціалістів, платою за оренду каналів і т. ін.
Поточні витрати залежать від числа відісланих повідомлень, оскільки за вхідні (отримані) повідомлення плата не береться. Становлять ці витрати від 0,3 до 0,5 дол. залежно від пріоритету повідомлення. Вважається, що довжина останнього не перевищує 325 знаків. Існує тенденція до зниження цих витрат.
Підключитися до СВІФТ може будь-який банк, котрий має валютну ліцензію та відповідні кошти.
Сама система СВІФТ, умови її впровадження та експлуатації, а також надавані нею послуги змінюються з часом (так тепер, крім чисто фінансових повідомлень, можна передавати файли довільної структури, а також платежі комерційної торгівлі), тому перед упровадженням доцільно дістати відповідні довідки щодо підключення до системи в Україні (за телефоном у Києві: (044) 244-15-79).
ТЕМА 9. ЕЛЕКТРОННІ ГРОШІ. АВТОМАТИЗАЦІЯ ПЛАТЕЖІВ
9.1. Типи та призначення електронних грошей
Гроші виконують п’ять головних функцій: міри вартості, засобів обігу, засобів платежу, засобів нагромадження вартості та світових грошей. Кожну із цих функцій вони виконують, набираючи однієї з форм, в якій можуть існувати. Наприклад, грошовий обіг є рух грошей у готівковій та безготівковій формі під час обслуговування кругообороту товарів та послуг.
Як засоби платежу та нагромадження гроші функціонують у готівковій формі.
У безготівковій формі гроші існують як записи на рахунках у кредитних і фінансових установах. Ці записи донедавна велися, здебільшого, на паперових носіях і безпосередньо сприймалися та оброблялися людиною. Зрозуміло, що коли такого роду інформація зберігається не на паперових, а на магнітних і машинних носіях, сприймається й обробляється електронними пристроями й машинами, то це також гроші в безготівковій формі, які можна назвати електронними грошима (ЕЛГ).
Коли йдеться про готівкову форму грошей, носіями вартості можуть бути предмети найрізноманітнішої форми та вигляду. Головне — вони мають забезпечувати учасникам «угоди» (платежу) можливість читати, точніше сприймати з них інформацію про розмір відображуваної ними вартості.
Отже, загалом під електронними грошима розуміють такі носії, сприйманої електронними системами обробки даних, інфор-