Глава 5. Автоматизація банківської справи Ищите Господа, когда можно найти Его, призывайте Его, когда Он близко. (Библия, книга пророка Исаии 55:6) Узнать больше о Боге
Главная Книги Статьи Реклама на сайте

ТЕКСТЫ КНИГ ПРИНАДЛЕЖАТ ИХ АВТОРАМ И РАЗМЕЩЕНЫ ДЛЯ ОЗНАКОМЛЕНИЯ

Глава 5. Автоматизація банківської справи

5.1. Особливості автоматизації
В останні роки банківська система нашої країни (БС) переживає бурхливий розвиток. Не зважаючи на існуючі недоліки українського законодавства, що регулює діяльність банків, ситуація неухильно змінюється на краще. Пройшли часи, коли можна було легко заробляти на спекулятивних операціях з валютою. Сьогодні все більше банків роблять ставку на професійність своїх співробітників і нові технології.
Важко уявити собі більш сприятливий грунт для запровадження комп’ютерних технологій, ніж банківська діяльність. Майже всі завдання, які виникають у процесі роботи банку, піддаються автоматизації. Швидка і безперебійна обробка значних потоків інформації є одним із головних завдань будь-якої великої фінансової організації. Тому необхідна наявність обчислювальної мережі, яка дозволяє обробляти інформаційні потоки, що все збільшуються і збільшуються. Крім того, банки мають достатні фінансові можливості для використання найсучаснішої техніки. Однак не слід вважати, що середній банк готовий витрачати величезні суми на комп’ютеризацію. Банк є, насамперед, фінансовою організацією, яка призначена для отримання прибутку, тому затрати на модернізацію повинні бути співставленими з очікуваною користю від її проведення. Відповідно до загальносвітової практики, в середньому затрати банку на комп’ютеризацію складають не менше 17 % від загальної суми річних витрат.
Інтерес до розвитку комп’ютеризованих банківських систем визначається, головним чином, стратегічними інтересами. Як показує практика, інвестиції в такі проекти починають приносити прибуток лише через певний період часу, необхідний для навчання персоналу та адаптації системи до конкретних умов. Вкладаючи кошти в програмне забезпечення, комп’ютерне і телекомунікаційне обладнання та створення бази для переходу до нових обчислювальних платформ, банки, в першу чергу, прагнуть до здешевлення і прискорення рутинної роботи та перемоги в конкурентній боротьбі.
Нові технології допомагають банкам, інвестиційним фірмам та страховим компаніям змінити відносини з клієнтами і знайти нові засоби для отримання прибутку. Аналітики сходяться на думці, що нові технології найбільш активно впроваджують інвестиційні фірми, потім йдуть банки, а останніми їх приймають на озброєння страхові компанії.
Завдання, що стоїть перед фінансовими організаціями, однакове. Це інтеграція нових систем у розподілену архітектуру локальних та глобальних мереж.
Банківські комп’ютерні системи на сьогоднішній день набули найбільшого розвитку серед галузей прикладного мережевого програмного забезпечення (ПЗ). Потрібно відзначити, що БС – дуже вигідний ринок для будь-якого виробника комп’ютерів та ПЗ.
Як приклад передових технологій, що використовуються в банківській діяльності, можна назвати бази даних на основі моделі “клієнт-сервер” (характерним є використання ОС Unіx та БД Oracle); засоби міжмережевої взаємодії для міжбанківських розрахунків; служби розрахунків, цілком орієнтовані на Іnternet, і багато іншого.

5.2. Комп’ютеризовані банківські системи
Сьогодні БС дозволяють автоматизувати практично всю банківську діяльність. Серед основних можливостей БС, заснованих на використанні сучасних мережевих технологій, слід згадати системи електронної пошти, бази даних на основі “клієнт-сервер”, засоби віддаленого доступу до мережевих ресурсів системи, для роботи з мережами банкоматів і багато іншого [4, 6].
На світовому ринку існує маса готових БС. Основним завданням, яке стоїть перед службою автоматизації західного банку, є вибір оптимального рішення і підтримка працездатності вибраної системи. У нашій країні ситуація дещо інша. При виникненні банківської сфери в Україні питанням автоматизації спочатку приділялось недостатньо уваги. Більшість банків пішли шляхом створення власних систем. Такий підхід має свої переваги і недоліки. До перших слід віднести: відсутність необхідності у великих фінансових вкладах на придбання БС, пристосованість БС до умов експлуатації (до існуючих ліній зв’язку), можливість постійної ефективної модернізації системи. Недоліки такого підходу очевидні: необхідність в утриманні великого комп’ютерного штату, несумісність різних систем, відставання від сучасних тенденцій розвитку і багато іншого.
Однак є приклади придбання та успішної експлуатації банками дорогих банківських систем. Сьогодні найбільш популярними є змішані рішення, при яких частина модулів БС розробляється комп’ютерним відділом банку, а частина закуповується у незалежних виробників.

5.3. Функції банківських систем
БС звичайно реалізуються за модульним принципом. Широко використовуються спеціалізовані потужні або універсальні комп’ютери, які об’єднують декілька локальних мереж (LAN). У БС застосовується міжмережевий обмін і віддалений доступ до ресурсів центрального офісу банку для виконання операції “електронних платежів”. Банківські системи повинні мати засоби адаптації до конкретних умов експлуатації. Для підтримки оперативної роботи банку БС повинна функціонувати в режимі реального часу OLTP (On-Lіne Transactіon Processіng).
Основні функції БС (реалізуються у вигляді незалежних модулів однієї системи): автоматизація всіх щоденних внутрішньобанківських операцій, ведення бухгалтерії та складання підсумкових звітів; комунікація з філіями та іногородніми відділеннями; автоматизована взаємодія з клієнтами (так звані системи “банк-клієнт”); аналітичний аналіз усієї діяльності банку і вибір оптимальних у даній ситуації рішень; автоматизація роздрібних операцій – застосування банкоматів і кредитних карток; автоматизація міжбанківських розрахунків; автоматизація роботи банку на ринку цінних паперів; автоматизація процесів оперативного отримання необхідної інформації, яка впливає на фінансову ситуацію в режимі OLTP.
Таким чином, будь-яка банківська система є складним комплексом, що об’єднує сотні окремих комп’ютерів, LAN, WAN.

5.4. Критерії вибору
Часто головним завданням комп’ютерного департаменту банку є вибір найкращого рішення із запропонованих на ринку варіантів БС або вибір стратегії розробки чи модернізації існуючої БС. Розглянемо критерії такого вибору.
Вимоги до складної банківської системи залежать від об’єму операцій, які проводяться банком. Мета – створення БС, яка б забезпечувала персонал і клієнтів банку необхідними видами послуг, за умови, що витрати на створення й експлуатацію не перевищують прибутків від впровадження БС.
Для вибору найбільш правильного рішення необхідно враховувати такі моменти.
Вартість БС. Необхідно звернути увагу на вибір обчислювальної платформи, мережевого обладнання, ПЗ, вартість обслуговування і супроводження системи, на що впливають стандартність платформи і кількість незалежних постачальників.
Можливість масштабування. У випадку росту банку вартість модернізації при невдалому виборі різко зростає. Необхідно, щоб обрана обчислювальна платформа допускала поступове нарощування ресурсів у тих частинах системи, де це буде потрібно.
Використання наявних ресурсів. Від ефективності використання наявних комп’ютерів, мереж і каналів зв’язку залежать витрати на побудову БС.
Наявність системи захисту інформації. Безпека даних є однією із головних вимог до БС. Повинна бути передбачена як стійкість роботи при неправильних діях персоналу, так і спеціалізовані системи захисту від несанкціонованого доступу до БС з корисливими, шахрайськими або іншими цілями. 
Система захисту та безпеки інформації в БС допускає: засоби фізичного обмеження доступу до комп’ютерів БС (ідентифікаційні картки, пристрої блокування); надання повноважень, привілеїв і прав щодо БС на рівні окремого користувача (співробітника або клієнта); засоби централізованого виявлення спроб несанкціонованого доступу до ресурсів БС, які дозволяють своєчасно вжити відповідні заходи; захист даних при передачі каналами зв’язку (особливо актуально при використанні відкритих каналів зв’язку, наприклад, мережі Іnternet); використання “цифрового електронного підпису” та інших криптографічних методів.
Надійність системи. Відмови окремих елементів БС не повинні призводити до її повного виходу з ладу. Крім того, необхідно забезпечити високу стійкість роботи БС в умовах дестабілізуючих факторів (наприклад, перешкод у лініях зв’язку або помилкових дій персоналу банку).
Наявність засобів відновлення при перешкодах. У БС повинні бути передбачені засоби для прогнозування, фіксації і локалізації різних позаштатних ситуацій та відмов обладнання (пошкодження та перевантаження каналів зв’язку, пристроїв зовнішньої пам’яті, порушення цілісності БД, спроби несанкціонованого доступу до системи).
Можливість адаптації до змін фінансового законодавства або структури банку та інших подій. Це реалізується за рахунок створення динамічних або генетичних БС.
Можливість роботи в режимі реального часу. Нині системи типу OLTP стають усе більш поширеними при створенні БС. Упровадження систем OLTP потребує від банку досить великих інвестицій, але їх переваги виправдовують усі витрати. Для створення систем цього типу можуть використовуватися:
· потужні універсальні комп’ютери і міні-ЕОМ, наприклад, фірм ІBM, DEC, NCR (до 70 % систем); можливості OLTP реалізуються за допомогою додаткового ПЗ;
· спеціалізовані багатопроцесорні відмовостійкі (SFT – System fault-tolerance) системи, наприклад, фірми Tandem, Suquent (близько 10 % систем); для SFT-комп’ютерів звичайно включають OLTP безпосередньо в ОС (наприклад, для комп’ютерів типу NonStop фірми Tandem).

5.5. Використання СУБД
Ядром довільної БС є засоби роботи з даними. У більшості сучасних БС у цій якості виступають потужні СУБД, які підтримують розподілену обробку даних. Розглянемо можливості СУБД Оrасlе, які використовуються при побудові автоматизованих БС.
Відомо, що СУБД Оrасlе є реляційною СУБД і не може виступати в ролі об’єктно-орієнтовного середовища розробки, тим паче розрахованого на деяку предметну галузь. У той же час можливості СУБД Оrасlе дозволяють засобами реляційної моделі емулювати об’єктну модель даних.
Модифікації банківської моделі у момент запуску та в процесі експлуатації системи. Дуже важливо забезпечити гнучкість налагодження банківських компонентів системи (банківські продукти, документообіг, система обліку) у ході відображення об’єктної моделі у структурі БД. Необхідну свободу дій забезпечує механізм створення й модифікації об’єктів СУБД, який дозволяє керувати структурами об’єктів фінансової системи та операціями над ними безпосередньо у процесі функціонування самої системи.
Зміни структури об’єктів банківської системи, які виконуються адміністратором, відображаються на таких рівнях СУБД: модифікація таблиць; перегенерація представлень (VІEW); створення триггерів, індексів, обмежувачів цілісності (СОNSТRАІNТ) та лічильників (SЕОUЕNСЕ); генерація пакетів процедур, які зберігаються.
Проблемно-орієнтована мова високого рівня. При реалізації інформаційної моделі банку бажаним є використання спеціалізованої мови для опису бізнес-процесів. Мова процедур РL/SOL, які зберігаються, є досить розвиненою, але не може виступати як проблемно-орієнтована для фінансової системи. Тому реалізуються засоби, які дозволяють створювати препроцесори з проблемно-орієнтованих мов високого рівня. Це дозволяє розробляти операції у термінах структур даних та функцій, які належать до предметної галузі, не використовуючи складних запитів низького рівня.
Поведінка інформаційної системи у різних ситуаціях. Банківська технологія повинна працювати у режимі реального часу, так як майже більшість операцій залежить від ситуації. Тому можливість будови параметризованих запитів на отримання й обробку даних – необхідна вимога до мови обробки даних. Це забезпечується використанням динамічної мови – SQL. Він дозволяє будувати складні блоки коду, що залежать від різних умов, параметрів та способу збереження данних, і виконувати їх з процедурами, які зберігаються. Динамічний SQL забезпечує емуляцію об’єктно-орієнтовної моделі даних з використанням внутрішніх словників системи та механізмів інкапсуляції, успадкування та перезавантаження операцій.
Фонові процедури. Більша частина банківських операцій може виконуватися у пакетному режимі, в той час як основні обчислювальні потужності не завантажені. Це визначається як операційною циклічністю, яка характерна для банку, так і службовими процесами, що мають технологічний характер. Механізми підтримки фонових процесів сервера Оrасlе дозволяють за допомогою засобів СУБД організовувати виконання загальносистемних завдань (ведення журналу дій користувачів, накопичення статистичної інформації, архівування тощо), що забезпечує їх незалежність від операційної системи.
Безпека. Безпека в системі забезпечується розподілом прав доступу користувачів до її інформаційних ресурсів. Керування статичним доступом досягається за допомогою внутрішніх засобів СУБД, наприклад, створенням ролей користувачів та призначенням у їх рамках прав на доступ до окремих представлень, таблиць із словника даних і до обмеженої множини процедур, які зберігаються, та пакетів. Користувач не має прямого доступу до таблиць і пакетів, його права динамічно перевіряються при виборі даних через механізм представлень та активації операцій через спеціальні механізми виклику. Разом з журналізацією дій та змін цей механізм забезпечує гнучку регламентацію та контроль над діями користувачів системи.
Клієнтська частина. Використання Оrасlе Саll Іnterface (ОСІ) надає доступ до усіх можливостей сервера Оrасlе з клієнтської частини архітектури клієнт-сервер. Структура ПЗ може бути досить універсальною, бо визначається суворо формалізованим описом усіх структур даних та операцій, які зберігаються у словниках. Це відноситься як до механізмів навігації користувача, так і до екранних форм вводу даних. Структура екранних форм визначається набором параметрів операції, яка викликається, та їх типами, що дозволяє автоматично генерувати форми при створенні нових операцій та зберігати їх опис на сервері в довільному та зручному форматі. Адміністратор системи може змінювати розташування та зовнішній вигляд керуючих елементів форми, додавати нові, які відображають додаткову інформацію.
Використання цих принципів зберігання інформаційних структур, які визначають інтерфейс з користувачем, забезпечують незалежність системи від клієнтської частини.
Доступ до файлів ОС. Для максимально ефективного використання програмного забезпечення банку може бути важливою організація взаємодії між процесами за допомогою засобів ОС. Доступ до файлів процедур операційної системи, які зберігаються, забезпечує архівацію та обробку даних на сервері без завантаження їх у базу даних, що іноді надає переваги у швидкості, дозволяє спростити обмін даними та їх обробку.
Серія БС концерну Іncosoft. Банківські продукти серії ТОТАL концерну Іncosoft побудовані на основі архітектури мережевих обчислень. Відкритість цієї архітектури дозволяє підтримувати широкий спектр СУБД та операційних систем серверів і клієнтських машин. На даний момент існує можливість використання СУБД Оrасlе, Іnformіx або DВ2. У якості операційної системи застосовуються Wіndows NТ, OS/2, UnіxWare, Solarіs, АІХ, НР-UХ. На клієнтських машинах використовується віртуальна Javа-машина під Wіndows 95/98/2000 або Wіndows NT, Java OS.
У моделі мережевих обчислень проміжною ланкою між СУБД та клієнтськими машинами є сервер процесів, в якості якого використовується брокер об’єктних запитів СОRВА 2.0.
Програмне забезпечення використовує Java Аррlісаtіоns та Аррlеts. При цьому клієнтські машини, побудовані за принципом “тонких” клієнтів, можуть знаходитись із сервером в одній мережі Іntranet, або звертатись до нього через Іnternet.

Рис. 5.1. Система TOTALBank
Основні характеристики системи. Функціональними компонентами системи є: TOTALBank – комплексна інформаційна банківська система; TOTALSepNbu – система зв’язку комерційного банку з СЕП НБУ; TOTALReports – система звітності комерційного банку; TOTALClіentBank – система “клієнт-банк” з використанням Іnternet; TOTALCard – платіжна система на основі мікропроцесорних карток.
Система TOTALBank розрахована для роботи в Іntranet/ Іnternet з єдиною базою даних (рис. 5.1). Після введення первинного і відповідного йому контрольного документів проводки, що прогнозуються, результат одразу відображаються на рахунках. Новий стан рахунків відразу стає доступним іншим операціоністам і головному бухгалтеру, відображається в балансі та інших аналітичних документах.
Усі дані, що використовуються в роботі, зберігаються на сервері БД, до якого клієнтські робочі станції звертаються через сервер процесів. На сервер процесів винесена вся логіка обміну між клієнтом і БД, у той час як СУБД зайнята лише роботою з даними і не зберігає жодних процедур, які підвищують навантаження на сервер та ускладнюють перенесення системи при переході на іншу СУБД. При подібній організації інформаційного обміну вдається значно знизити мережевий трафік, а також спростити процедури інсталяції та супроводження модулів на робочих станціях (або навіть уникнути їх), оскільки замість них виконуються Аррlets, що завантажуються.
На відміну від систем “клієнт-сервер”, які є погано масштабованими, TOTALBank є системою, що масштабується лінійно. Масштабованість системи може досягатися за рахунок збільшення недорогих робочих місць та/або збільшення числа чи потужності серверів процесів. Для невеликих реалізацій усі сервери, включаючи WWW-сервер, можуть розміщуватися на одному комп’ютері.
При підключенні до Іntranet Wеb-сервера віддалені клієнти будуть працювати з АБС через Іntеrnеt. Це дозволяє банку легко вирішувати завдання, пов’язані з відкриттям представництв на будь-якій відстані від головного офісу.
Компоненти TOTALBank. Програмне забезпечення системи складається з трьох основних частин:
· Front Оffіce, призначений для співробітників банку, які працюють з клієнтами; дозволяє вводити документи та отримувати інформацію за рахунком;
· Васk Оffіce, призначений для співробітників банку, що виконують обробку інформації; дозволяє створювати, змінювати і закривати рахунки, налагоджувати платіжні операції, керувати планом рахунків, контролювати проходження документів за технологічною схемою;
· Рау Оffіce, призначений для управління потоком документів, що направляються через СЕП НБУ.
Конкретний набір функцій залежить від завдань, що стоять перед банком, відділенням або філією, і може варіюватися в різних реалізаціях системи.
Більшість функцій сконцентрована в інтегрованій банківській системі ТОТАLВаnk. Вона дозволяє виконувати прості і складні проводки, виконувати роботу з картотеками документів, розраховувати та проводити відсотки за позиковими і розрахунковими рахунками, проводити касові операції, формувати всі стандартні звітні документи тощо.
Обробник СЕП НБУ дозволяє автоматизовано приймати і відправляти міжбанківські документи у форматі системи електронних розрахунків НБУ.
Підсистема клієнтських платежів ТОТАLСlіentВаnk дозволяє відправляти в банк платіжні документи з офісу клієнта та отримувати з банку виписки, повідомлення про вхідні платежі, довідкову інформацію.
Є можливість формувати стандартні звіти в будь-який момент поточного операційного дня, а також за будь-який попередній день. Для банків з розвиненою мережею філій та відділень можна передавати в центральне відділення баланси, статистичну звітність, нормативи діяльності банку тощо. У центральному відділенні на основі всіх даних, що передаються, формуються зведені звіти у банку за будь-який період часу.
Клієнт-банк. Система клієнтських платежів (ТОТАLСlіentВаnk) працює за тими ж принципами, що й інтегрована БС (ІБС) ТОТАLВаnk, але в якості клієнтських частин використовуються Java-applets, що завантажуються за допомогою Wеb-сервера. Такий підхід дозволяє скоротити витрати на розгортання і супроводження системи, оскільки на робочих місцях необхідні тільки операційна система та броузер.
Робота клієнта банку з управління своїм рахунком виглядає таким чином. Після звернення броузера до вказаної адреси завантажується Java-аррlеt. Клієнту доступні стан рахунка та документи, що обробляються. Він може вводити документи інтерактивно, після чого вони зберігаються в СУБД у вигляді записів. Посадові особи клієнта можуть підписати їх, навіть якщо в цей час знаходяться в іншому місті, що робить дану систему унікальною порівняно з подібними. Підписані двома підписами записи допускаються до обробки в ІБС. Підписи клієнтів можуть зберігатися як на дискеті, так і на картці з мікропроцесором, яка є більш захищеним носієм інформації.
Для відправки великої кількості документів передбачена можливість формування списку документів на диску до оn-lіnе сеансу. Користувачі, не підключені до Іnternet, можуть скористатися альтернативними каналами доставки.
Функції системи. Система ТОТАLВаnk позбавляє можливості користувачів на робочих місцях отримувати таку інформацію, що стосується окремих файлів і функцій. Екранні форми містять лише фінансову інформацію, тобто документи і рахунки. У системі можуть формуватися складні, логічно пов’язані проводки (наприклад, одночасна проводка документів клієнта і комісії з операції). ТОТАLВаnk відслідковує стан документів та автоматично контролює їх проходження технологічним ланцюжком банку.
Дозволені операції визначаються автоматично, для чого використовується інформація про рахунок. Далі оператор працює з документом, при цьому йому надається вичерпна інформація як у валюті платежу, так і в покритті національною валютою. При виконанні проводки автоматично створюються всі необхідні платіжні документи.
Система ТОТАLВаnk формує звіти в будь-який момент роботи в поточному операційному дні. Передбачена можливість отримання звітів за будь-який попередній день. Якщо необхідно, нові звіти легко додаються і змінюються.
Безпека даних у клієнта і в банку організована багаторівневим захистом, заснованим не тільки на технічних рішеннях, але й організаційно, шляхом регламентації дій персоналу. Система побудована таким чином, що відкрита інформація не виходить з того робочого місця, де вона вводиться або обробляється. Захист конфіденційної інформації на місцях забезпечують самі користувачі, будучи при цьому зацікавленими особами.
При роботі з Іnternet система використовує визнані засоби захисту інформації, такі як SSL (Securіty Socket Layer), що дозволяють ідентифікувати клієнта, який звертається до ІБС, і навпаки, а також механізм підпису RSА. На WWW-сервері використовується один із стандартних fіrewall (засіб захисту), який з достатньою жорсткістю забороняє несанкціоновані доступи до Іntranet.
Потрібно враховувати, що обмін у мережах виконується пакетами, які можуть нести пов’язану інформацію, яка проходить різними маршрутами. Тому для отримання комерційної інформації потрібно зібрати всі пакети, розшифрувати їх і скласти логічно зв’язний запис. Таким чином, можливість фальсифікації в режимі реального часу малоймовірна, а можливість знищення пакетів на одному з вузлів вирішується стандартними засобами Іnternet, що гарантують доставку.

5.6. Операційний день банку
Програмне забезпечення повинно надати комерційному банку можливість розвиватись, збирати інформацію щодо клієнтів та обліку, підтримувати безпеку системи, здійснювати всі фінансові транзакції, поновлювати відсоткові ставки та обмінні ресурси валют, а також приймати необхідні рішення, підтримувати та модернізовувати правила ведення операцій, включаючи кредити і депозити, ринок позичкового капіталу, міжнародні платежі тощо.
Банківська система повинна забезпечувати весь банківський облік за прибутками та видатками, а також підготовку балансових звітів відповідно до вимог як Національного банку, так і міжнародного банківського та аудиторського секторів. Якщо прогресивний банк бажає процвітати, система повинна підтримувати весь діапазон діяльності, пов’язаної з міжнародним обміном валют. Від банківської системи може вимагатись також реалізація інших банківських функцій (документарні акредитиви, здійснення банківських операцій у віддаленому режимі, управління акціями та інвестиціями).
Отже, банківська система повинна вирішувати величезну кількість різноманітних завдань та нести відповідальність як основний двигун банку; базуватись на інтересах клієнтів, бути гнучкою, мультивалютною, ефективною та інтегрованою.
Такі вимоги висуваються до банківських систем сьогодні. А ще й десяти років не минуло з того часу, коли банки тільки починали свою автоматизацію. Однією з перших автоматизованих банківських систем стала система “Операційний день банку”. Розглянемо її детальніше.
Класично в межах завдання “Операційний день банку” повинні розв’язуватись такі питання.
1. Облік клієнтів банку.
1.1. Відкриття особових рахунків за балансовими рахунками.
1.2. Закриття особових рахунків.
1.3. Пошук та відображення інформації про клієнтів банку, складання звіту щодо їх кількості та особових рахунків.
2. Синтетичне врахування.
2.1. Урахування щоденних операцій із зарахування та списання з рахунків коштів клієнтів.
2.1.1. Введення та контроль вхідної інформації для проведення операцій за безготівковими розрахунками.
2.1.2. Зарахування коштів на рахунки за новими авізо та іншими розрахунковими документами.
2.1.3. Оплата документів за рахунок коштів, що є на рахунках клієнтів, та за рахунок кредиторів банку.
2.1.4. Врахування щоденних операцій банку з інструментальним накопиченням результатів проводок платіжних документів у базі даних про операції банку.
2.2. Формування даних синтетичного врахування.
2.2.1. Формування бухгалтерського журналу.
2.2.2. Нормування звітної картки:
а) формування звітної картки на початок втілення (заповнення “шапки”);
б) формування звітної картки на день втілення;
в) перенесення залишків у звітні картки на 1-ше число місяця;
г) перенесення залишків у звітні картки на 1-ше січня.
2.2.3. Введення залишків особових рахунків на початок впровадження.
2.2.4. Складання місячної оборотної відомості.
2.2.5. Складання річної оборотної відомості.
2.2.6. Складання балансу банку за визначений період (день, місяць, квартал, рік).
2.2.7. Формування щоденних зведених платіжних доручень за кредитом рахунків 830 і 871.
2.2.8. Складання щоденних виписок з особових рахунків клієнтів банку.
2.2.9. Формування залишків за рахунками клієнтів із заданими балансовими номерами станом на поточну дату.
2.2.10. Нарахування відсотків клієнтам за наявність коштів на їх розрахункових рахунках.
2.2.11. Розрахункові операції за акредитивами.
2.2.12. Ведення прибутково-видаткових касових журналів.
2.2.13. Накопичення інформації за позабалансовими рахунками.
2.2.14. Складання перевірочних відомостей залишків особових позабалансових рахунків.
2.2.15. Складання місячної оборотної відомості за позабалансовими рахунками.
2.2.16. Складання річної оборотної відомості за позабалансовими рахунками.
3. Розрахунок нормативів НБУ (сума коштів за депозитами та коефіцієнтами).
4. Врахування короткострокових та довгострокових позик.
4.1. Формування та ведення карток і журналу реєстрації термінових зобовязань.
4.2. Контроль за короткостроковими та довгостроковими позиками за термінами покриття.
4.3. Переведення позик, які не покриті вчасно, на рахунки простроченої заборгованості.
4.4. Формування меморіальних ордерів.
4.5. Формування підсумкових (за прибутками та видатками), а також прибутково-видаткових коштів до позабалансових рахунків 9921, 9971, 9961.
4.6. Складання розшифровки окремих рахунків балансу за термінами залучення та спрямуванням коштів.
4.7. Формування відомості відсоткових чисел.
4.8. Формування відомості нарахування відсотків.
5. Формування меморіальних ордерів обороту.
6. Формування і ведення картотеки № 1.
6.1. Відбір документів до картотеки № 1.
6.2. Ведення картотеки № 1.
7. Формування і ведення картотеки № 2.
7.1. Формування картотеки № 2.
7.2. Розміщення розрахунково-грошових документів у картотеці № 2 за умови відсутності коштів на рахунках клієнтів.
7.3. Формування повідомлень клієнтам про відсутність коштів на рахунках, реєстрація документів у журналі та картотеці № 2.
7.4. Формування підсумкових сум за прибутками до позабалансових рахунків 9929, 9932.
7.5. Оплата (повна чи часткова) в порядку календарної черги документів картотеки № 2 з розрахункових, позичкових рахунків та рахунків фінансування.
7.6. Формування дебетових авізо та меморіальних ордерів.
7.7. Формування журналів до картотеки № 2 за видатками.
7.8. Формування підсумкових сум за видатками та прибутково-видатковими ордерами до позабалансових рахунків 9929, 9932.
7.9. Нарахування пені за документами з картотеки № 2. Нарахування розміру та справляння пені за повної чи часткової оплати документів з картотеки № 2.
8. Формування та ведення картотеки № 3 до рахунка 9933.
8.1. Розміщення розрахунково-грошових документів у картотеці № 3.
8.2. Формування повідомлень клієнтам про причини несплати, реєстрація документів у журналі та картотеці № 3.
8.3. Формування підсумкових сум за прибутками та позабалансовим рахунком 9933.
8.4. Оплата (повна чи часткова) розрахункових документів із картотеки № 3 з рахунків фінансування.
8.5. Формування авізо та меморіальних ордерів.
8.6. Формування журналів до картотеки № 3 за видатками.
8.7. Формування підсумкових сум за прибутками та видатками та прибутково-видатковими ордерами до позабалансового рахунка 9933.
8.8. Нарахування пені за документами з картотеки № 3. Нарахування та справляння пені за повної чи часткової оплати документів з картотеки № 3.
9. Формування відомості врахування планів фінансування.
10. Врахування касових операцій.
10.1. Врахування грошового виторгу, що надходить на рахунки клієнтів.
10.2. Врахування та звітність при виконанні касового прогнозу.
11. Складання річного звіту за встановленими формами.
“Операційний день банку” (ОДБ) – програмне забезпечення, яке обслуговує внутрішню поточну діяльність банку (бухгалтерський облік, обслуговування рахунків клієнтів тощо). Іноді ОДБ включає внутрішню платіжну систему (ВПС) банку.
Бухгалтерський облік – це визначена система постійного, безперервного, взаємопов’язаного документального контролю за господарською діяльністю підприємства (у тому числі і банку) в грошовій формі. Предметом бухгалтерського обліку є стан власних (капітал) залучених коштів (пасиви) та їх розміщення в кредитні та інші активні операції (активи).
ВПС – програмно-технічний комплекс із власними засобами захисту інформації, який експлуатується банком і здійснює платіжний обіг між підрозділами банку та іншими банківськими установами.
Головне завдання ОДБ – ведення всіх рахунків бухгалтерського обліку, включаючи розрахункові і кореспондентські рахунки клієнтів. Усі зміни в рахунках здійснюються на підставі первинних документів.
Для ОДБ первинним є грошовий документ у паперовому чи електронному вигляді, що ініціює платіж. Це може бути розпорядження на платіж, касовий або меморіальний ордер, платіжне доручення, реєстр на зарахування чи списання та ін.
Характерна особливість первинних документів ОДБ у національній валюті – їх уніфікованість. Можна виділити дві групи документів.
1) Документи за безготівковими розрахунками: платіжне доручення (головний), платіжна вимога, меморіальний ордер та інші. В ОДБ вони вводяться та обробляються за єдиною технологією. Їх основне призначення – “обґрунтувати” платіж. 
Платіж – переміщення суми між двома рахунками. Усі платежі поділяються на внутрішньобанківські (обидва рахунки належать одному банку) і міжбанківські (рахунки знаходяться в різних банках).
2) Касові документи: прибутковий і видатковий касовий ордер. За традиційною банківською технологією, проводка може виконуватися лише за наявності санкції не менш ніж двох уповноважених співробітників.
Проводка (проводження) – короткий бухгалтерський запис, який відображає кореспонденцію рахунків. Записується таким чином:
а==>s==>b, 
де а – що дебетується;
b – що кредитується;
S – сума, що знаходиться на рахунку.
Як уже зазначалося, “операційний день банку” – програмне забезпечення, яке обслуговує внутрішню поточну діяльність банку. Платіжний документообіг є ключовою складовою діяльності банку, оскільки господарча (уставна) діяльність банку зводиться до організації розрахунків (платіжного обігу) в готівковій та безготівковій формах через вклади, кредитування, гарантії, консультації та ін. Наскільки чітко, технологічно організовано документообіг, настільки легко реалізується виконання основних функцій банку. У будь-якій автоматизованій банківській системі найважливішою є технологія, що покладена в основу документообігу.
Розглянемо основні вимоги, які висуваються до платіжного документообігу:
1) повинен мати універсальний, чіткій вхідний інтерфейс, через який надходять первинні грошові документи, що ініціюють платежі; при цьому для документообігу не повинно бути різниці між клієнтським грошовим документом та грошовим документом співробітників функціональних відділів банку; функціональний відділ – підрозділ банку, що займається основною функціональною діяльністю (кредитний, депозитний, вкладів населення, валютний, фондовий та ін.);
2) забезпечувати прозору маршрутизацію платіжних документів;
3) надавати можливість контролювати платіж на всьому маршруті його слідування;
4) чітко розрізняти відповідальність бухгалтерів за платежі, що ними здійснюються (модифікувати інформацію може лише той, хто має на це право в силу службових обов’язків);
5) сприяти підвищенню безпеки економічної інформації за рахунок розмежування доступу до неї різних категорій користувачів;
6) дозволяти скасування платіжного документа, якщо в ньому або документі, що до нього відноситься, знайдено помилку до закриття операційного дня.
Для здійснення максимального контролю при вводі кожний первинний документ вводиться двічі різними співробітниками. В обробку приймаються лише ті документи, результат двох незалежних вводів яких співпав. Документи за безготівковими розрахунками вводять операціоніст і контролер, а касові документи – операціоніст і касир.
Допускається і більш складна технологія, при якій усі введені документи за безготівковими розрахунками додатково переглядаються на окремому робочому місці бухгалтером, який “випускає” потрібні документи на подальшу обробку.
У загальному випадку банк для здійснення міжбанківських платежів може мати декілька кореспондентських рахунків (Ностро і/або Лоро), до яких обов’язково входить кореспондентський рахунок в управлінні НБУ.
Коли є декілька кореспондентських рахунків, то для кожного міжбанківського платежу необхідно вказати, через який із них він буде здійснений. Вирішує це завдання спеціальний співробітник для роботи з кореспондентськими рахунками (позиціонер).
Первинний документ, який виходить за межі банку, тобто обґрунтовує міжбанківський платіж, повинен “схвалюватися” трьома співробітниками: операціоністом, контролером та позиціонером.
Внутрішнє представлення (структура) первинного документа в ОДБ, так званий електронний документ, повинно включати:
· дату заповнення і номер документа (власні дата і номер);
· вид документа;
· кореспондентські рахунки (дебет і кредит);
· суму і призначення платежу.
Касовий документ додатково включає касовий символ і, якщо необхідно, платіж – комісію за касову операцію.
В ОДБ з кожним документом пов’язується і внутрішня інформація:
· ідентифікація документа;
· ідентифікація вводу і контролю (хто, коли і на якому робочому місці);
· стадія обробки документа та інше.
Усі об’єкти, з якими працює бухгалтерський облік, групуються на синтетичних рахунках, що відкриваються відповідно до єдиних планів рахунків. Усі особові рахунки в межах України мають унікальну ідентифікацію.
Рахунки – бухгалтерські реєстри (переліки, списки), на яких за економічним змістом групуються і відображаються всі об’єкти бухгалтерського обліку. Записи до них здійснюються на підставі первинних документів, якими оформляються всі банківські операції. Усі рахунки поділяються на балансові і позабалансові. Балансові рахунки бувають активними, пасивними та активно-пасивними.
1) Пасивні рахунки призначені для обліку власних і залучених коштів. На них відображаються фонди банку, вклади (до запитання, термінові, ощадні), прибуток банку, отримані міжбанківські кредити, кошти в розрахунках.
2) Суми на активних рахунках показують, як використовуються всі кошти (ресурси) банку. На них відображаються готівка в касах, залишки на рахунках у банках-кореспондентах, короткострокові і довгострокові позики, витрати на капітальні вкладення, приміщення і техніку.
3) Частина рахунків має змішаний характер – активно-пасивні. На позабалансових рахунках показується рух цінностей і документів, які надходять у банк на зберігання, інкасо або комісію.
Кожний банк (філія) в межах України має унікальний код (МФО). Кожний відкритий у банку рахунок має свій номер, який разом з МФО однозначно його ідентифікує.
МФО банку має 6 цифр, з яких 5 інформаційних і одна контрольна, що вираховується за п’ятьма першими.
Номер рахунка має 12 цифр (як правило, використовуються 9), із яких 3 цифри задають балансовий номер другого порядку, 8 (як правило, 5) цифр – порядковий номер рахунка в межах балансової групи й одна цифра – контрольна. Контрольна цифра обраховується за 11 (як правило, 8) інформаційними цифрами рахунка і кодом (МФО) банку.
Баланс банку – це бухгалтерський документ, який відображає стан власних і залучених коштів банку та їх розміщення в кредитні та інші активні операції.
Усі операції з рахунками, які входять в один баланс, задаються проводками. В ОДБ проводка частіше задається за допомогою обертів. Кожна проводка – це два оберта за кореспондентськими рахунками.
Усі операції відображаються на рахунках бухгалтерського обліку за допомогою подвійного запису, при якому кожна операція проводиться однією сумою за дебетом одного рахунка і кредитом другого. Цей взаємозв’язок бухгалтерського обліку називається кореспонденцією рахунків, а рахунки – кореспондентськими.
Для зручності підготовки різноманітних документів в ОДБ підтримується інформація про залишки на рахунках на різні дати.
Для зберігання залишку на рахунку використовуються додатні і від’ємні числа. Додатній залишок відповідає дебетовому, а від’ємний – кредитовому.
Якщо рахунок активний, то його залишок, як правило, невід’ємний; у випадку пасивного рахунка залишок недодатний.
Якщо баланс коректний, то сума усіх залишків на рахунках повинна дорівнювати 0.
При виконанні проводки a==s==>b рахунок а дебетується, а рахунок b кредитується на суму s. Залишки sа і sb на рахунках а і b відповідно змінюються за формулами:
sa = sa + s і sb = sb – s.
Якщо а – активний і b – пасивний рахунки, то “реальні” залишки на обох рахунках збільшуються, що відображає збільшення ресурсів банку.
Якщо а – пасивний і b – активний рахунки, то “реальні” залишки на обох рахунках зменшуються, що відображає зменшення ресурсів банку.
Наприклад, коли клієнт “знімає” з рахунка (забирає з банку) гроші готівкою, то а – рахунок клієнта і b – рахунок каси.
Внутрішня структура рахунка включає:
· повний номер рахунка;
· його назву;
· ідентифікацію клієнта;
· дати відкриття і закриття;
· тип рахунка (пасивний, активний, активно-пасивний);
· поточний та мінімально допустимий (межа) залишок.
Крім того, з кожним рахунком пов’язуються всі обіги за ним і залишки на ті дні, коли з рахунком виконувалися які-небудь проводки.
Мінімально допустимий залишок (межа) g для активного і пасивного рахунків показує значення, починаючи з якого виникає “червоне сальдо” (overdraw).
Для розрахункового рахунка клієнта (пасивний), як правило, g = 0.
Якщо g < 0, то g – мінімальна сума, яку клієнт зобов’язаний постійно тримати на рахунку (фактично – плата за обслуговування рахунка).
Якщо g > 0, то g – допустима сума кредиту для клієнта (контокорентний рахунок).
Кожний оберт за рахунком включає:
· ідентифікацію первинного документа, який “породив” цей обіг;
· кореспондентський рахунок;
· дату та суму оберту.
Якщо оберт за дебетом, то сума додатня, якщо за кредитом – від’ємна.
Кожний залишок за рахунком на конкретну дату включає:
· залишок (зі знаком) на кінець вказаної дати;
· суму обертів за дебетом і за кредитом (невід’ємні) на цю дату.
Первинний документ – це підстава для здійснення операції над рахунками, при виконанні якої буде сформовано декілька проводок.
Розглянемо на прикладі, як “будуються” проводки при виконанні деяких типових операцій, коли жодний підрозділ банку (філія, відділення) не має свого внутрішнього замкненого балансу.
Нехай маємо платіжне доручення на переміщення суми s з рахунка на рахунок b. Платіжне доручення – розрахунковий документ, який містить доручення покупця (платника коштів) банку про перерахування з його рахунка певної суми на рахунок постачальника (одержувача коштів).
Якщо обидва рахунки є рахунками цього банку, то виконується проводка а==s==>b.
Якщо b – рахунок в іншому банку, то спочатку виконується проводка а==s==>tr, де tr – фіксований транзитний (проміжний) рахунок.
Після розв’язування задачі позиціонування, тобто визначення, через який кореспондентський рахунок с повинен відправлятися платіж, виконується проводка tr==s==>с.
Видатковий касовий ордер на видачу суми s готівкою з 2 % комісійних за переведення коштів у готівку: якщо а – рахунок клієнта, k – рахунок каси і р – рахунок прибутку банку, то виконується дві проводки: 
а==s==>k і а==s*0.02==>р.
Припустимо, що проводка а==s==>b сформована на підставі первинного документа з номером n, тоді її виконання зводиться до виконання двох обертів:
1) за рахунком а на суму s (рахунок-кореспондент b);
2) за рахунком b на суму s (рахунок-кореспондент а).
Позначимо оберт за рахунком а на суму s1, виконаний датою d на основі документа n, як Оbr(а,s1,n.d). Він виконується за таким алгоритмом:
іf
Серед обертів за рахунком а датою d є
оберт за документом n на суму -s1
then
Знайдений оберт вилучається.
Змінюється залишок на рахунку sа на sа+s1 (sа= sа+s1). Змінюється залишок на дату d, зменшуючи оберти на |s1| за дебетом (s1 < 0) або за кредитом (s1 > 0), можливо, вилучаючи після цього залишок.
else
Додається цей оберт.
Змінюється залишок на рахунку sа на sa+s1 (sа=sа + s1). Змінюється залишок на дату d, збільшуючи оберти на |s1| за дебетом (s1 > 0) або кредитом (s1 < 0), можливо, додаючи залишок.
Нехай платіжна вимога на переміщення суми s з рахунка а на рахунок іншого банку b має номер n. Спочатку датою d виконується проводка на транзитний рахунок tr а==s==>tr, при цьому виконуються оберти за рахунками а і tr на суми s та -s. Відповідно до алгоритму це призводить до появи одного оберту Оbr (a, s, n, d) за рахунком а та одного Оbr(tr,-s,n,d) за рахунком tr. Після розв’язання задачі позиціонування переміщення завершується проводкою tr==s==>c, де с – кореспондентський рахунок. Проводка може виконуватися:
1) датою d – оберт Оbr(tr,-s,n,d) за транзитним рахунком буде вилучений, і з’явиться оберт за кореспондентським рахунком Оbr(c,-s,n,d);
2) датою d1 (пізніше) – додаються оберти за транзитним Obr(tr,s,n,d) і кореспондентським Оbr(с, -s, n, d) рахунками.
Часто банк має складну організацію, що впливає на структуру ОДБ. Відомо, що банк – це сукупність філій, які мають власні МФО і кореспондентські рахунки в НБУ, функціонують незалежно від інших філій і мають власний незалежний баланс. Але при цьому вони не є юридичними особами, а їх баланси враховуються в консолідованому балансі банку. Кожна філія має одне або декілька відділень, що обслуговують клієнтів і можуть мати замкнений баланс.
У простому випадку програмне забезпечення такого банку може складатися з декількох ОДБ, які працюють незалежно в кожній з філій, і додаткового комплексу програм, що дозволяють формувати загальні документи у банку (включаючи консолідований баланс) на підставі документів окремих ОДБ.
У більш складному випадку забезпеченням банку є єдиний ОДБ, що обслуговує всі філії, дозволяє здійснювати оперативний збір інформації, контроль та управління і має внутрішню платіжну систему.
При наявності єдиного ОДБ платіж між філіями банку є внутрішньобанківським, що здійснюється лише засобами ОДБ і не стосується зовнішніх кореспондентських рахунків. З’являється можливість ефективніше використовувати кошти на кореспондентських рахунках в інших банках шляхом централізованого вирішення задачі позиціонування.
Структурно базовий ОДБ включає такі блоки (вузли):
1) “Відділення” – обслуговування клієнтів, ввід, контроль та випуск первинних документів;
2) “Центр” (філія) – обробка документів, які прийшли з відділень, внесення змін у рахунки, ведення (супровід) балансу (балансів);
3) “Позиціонування” – прийняття рішень про переміщення сум за межі банку (філії), ведення лімітів за кореспондентськими рахунками;
4) “Фільтр” – узгодження форматів різних систем електронних платежів;
5) “Гіперцентр” (центральний офіс банку) – супровід єдиної спільної (загальної) бази рахунків, ведення консолідованого балансу банку, можливо, у розрізі філій і/або відділень.
Кожний із блоків (вузлів) може функціонувати на одному комп’ютері або локальній мережі; вузол має унікальний номер у межах ОДБ. Різні компоненти системи можуть бути розташовані на значній відстані один від одного. Зв’язок між різними вузлами здійснює окремий рівень ОДБ – електронна пошта. Залежно від cпособів з’єднань окремих вузлів ОДБ в єдиний комплекс формуються бази для різних внутрішньобанківських платіжних систем.
Розглянемо один із найпростіших варіантів організації ВПС, коли ОДБ включає єдиним блоком “Центр”, “Позиціонування” і “Гіперцентр”, які функціонують у центральному офісі банку.
При такій організації в усіх відділеннях і філіях розміщуються блоки “Відділення” і програми, які забезпечують рівень електронної пошти. Це знижує витрати на експлуатацію такої ОДБ, бо висококваліфікованих програмістів і більш потужну техніку можна зосередити в одному місці.
Для формування замкнених балансів окремими підрозділами банку та консолідованого балансу вся множина рахунків розбивається на декілька підмножин (груп), які не перетинаються. Кожну групу утворюють рахунки, які входять у замкнений баланс відділення, філії або центрального офісу. Взаємодія між ними при виконанні внутрішньобанківських проводок між рахунками із різних груп (балансів) відображається на внутрішніх кореспондентських рахунках, які, як правило, відображають залежність між різними групами (балансами). Взаємозв’язок різних груп рахунків за допомогою внутрішніх кореспондентських рахунків визначає роботу ВПС.
Розглянемо ієрархічний взаємозв’язок, при якому рахунки пов’язані з рахунками головної контори філії (баланси відділень входять у консолідований баланс філії), а головні групи рахунків філій пов’язані з рахунками центрального офісу, утворюючи в цілому ієрархічну (“деревовидну”) залежність.
Наприклад, нехай G1 – група рахунків центрального офісу, G21, G22 – групи рахунків головних контор двох філій, а G31, G32, G33, G34 – групи рахунків відділень.
Ієрархічна залежність цих семи груп рахунків повністю відображає залежність між окремими підрозділами банку.
Взаємозв’язок між групами забезпечують декілька пар кореспондентських рахунків:
l1, l2, l31, l32,133, l34 – рахунки Лоро;
n1, n2, n31, n32, n33, n34 – рахунки Ностро. 
При цьому рахунки l1 і l2 входять у групу G1;
n1, l3 , l32 – у групу G21;
n2, l33, l34 – у групу G22;
n31 – у G31;
n32 – у G32;
n33 – у G33;
n34 – у G34.
Нехай а і b – рахунки банку, який має декілька різних внутрішніх замкнених балансів, відповідно до яких усі рахунки розбиті на групи так, як показано на рис. 5.2.

Рис. 5.2. Ієрархічна залежність груп рахунків

Якщо а і b входять в одну групу, то переміщення суми s з рахунка а на рахунок b вимагає однієї проводки а==s==>b.
Якщо а і b входять у різні групи (баланси), то реалізація переміщення суми s зачіпає внутрішні кореспондентські рахунки і вимагає більше ніж однієї проводки.
Наведемо типові приклади формування проводок: ==а входить у групу G31 і b – у групу G32:
а==s==>n31, l31 ==s==> l32, n32 ==s==> b;
== а входить у групу G31 і b – у групу G1:
а==s==> n31, l31==s==>n1, l1 ==s==> b;
== а входить у групу G31 і b – у групу G34:
а ==s==> n31, l31 ==s==> n1, l1 ==s==> l2, 
n2==s==> n34, n34==s==> b;
==а входить у групу G1 і b – у групу G32:
а==s==> l1, n1==s==> l32, n32==s==> b;
== а входить у групу G21 і b – у групу G32:
а==s==> l32, n32==s==> b.
У сучасних умовах для успішного розвитку та стійкості в конкурентній боротьбі комерційним банкам потрібно дещо більше, ніж засоби автоматизації типу ОДБ, тобто необхідно впроваджувати комплексні повнофункціональні системи, що підтримують інформацію на валютному ринку, ринку міжбанківських кредитів, фондовому ринку; автоматизацію більш складних, ніж бухгалтерський облік, банківських операцій; розрахунково-касове обслуговування, кредити, депозити та ін. Сьогодні вже не достатньо автоматизації лише “старих” банківських процедур, необхідно автоматизувати “найкращу практику”, тобто впроваджувати нові інформаційні технології.
Прогресивні напрями розвитку банків вимагають фундаменттальних змін, які можна здійснити шляхом введення прогресивних банківських систем. Основою для створення інтегрованих банківських систем може стати архітектура клієнт-сервер, реалізована, наприклад, у системі управління реляційними базами даних (Oracle, Sybase, Іnformіx, Іngress, Progress та ін.).

 

<< попередня     зміст     наступна >>

polkaknig(at)narod.ru, ICQ - 474849132 © 2005-2009 Матеріали цього сайту можуть бути використані лише з посиланням на даний сайт.