- •І технології
- •1.1. Фінансово-кредитна інформація та її особливості
- •1.3. Класифікація та кодування економічної інформації
- •1.4. Фінансово-кредитна система
- •2.2. Автоматизовані інформаційні технології, їх розвиток і класифікація
- •2.3. Автоматизоване робоче місце — засіб автоматизації роботи користувача
- •2.4. Поняття, мета і задачі технологічного забезпечення
- •2.5. Діалоговий режим автоматизованого опрацювання інформації
- •2.6. Мережевий режим автоматизованого опрацювання інформації
- •2.7. Технологія опрацювання текстової інформації
- •2.8. Технологія опрацювання табличної інформації
- •2.9. Інтегровані пакети для офісів
- •2.10. Системи управління базами даних
- •2.11. Інтегровані технології в розподілених системах опрацювання даних
- •2.12. Технологія використання експертних систем
- •2.13. Нейромережеві технології у фінансово-економічній діяльності
- •3.1. Технологія використання вбудованих функцій excel для фінансових розрахунків
- •2. Сталі ренти
- •3. Загальний потік платежів
- •4. Модель ціни акції
- •3.2. Підбір параметра
- •3.3. Оцінка інвестицій на основі Таблиці підстановки
- •3.4. Інформаційна технологія виконання бізнес-аналізу фінансових угод із цінними паперами
- •3.5. Диспетчер сценаріїв
- •4.1. Організаційно-концептуальні
- •4.2. Методологічні проблеми підтримки рішень з фінансового аналізу
- •4.3. Управління фінансовим ризиком у системі підтримки прийняття фінансових рішень
- •4.4. Моделі управління фінансовими ресурсами в системі підтримки прийняття фінансових рішень
- •4.5. Підтримка прийняття рішень
- •4.6. Проблеми оптимального управління запасами
- •5.1. Місцеві фінанси
- •5.2. Автоматизована система фінансових розрахунків
- •5.3. Структура та загальна характеристика підсистем автоматизованої системи фінансових розрахунків
- •5.4. Технологія розв'язування задач автоматизованої системи фінансових розрахунків у центральних та місцевих фінансових органах
- •6.1. Характеристика податкової системи України з погляду опрацювання інформації
- •6.2. Загальна характеристика автоматизованої системи «Податки»
- •6.3. Інформаційне забезпечення
- •6.4. Зовнішні інформаційні зв'язки
- •6.5. Автоматизовані інформаційні системи у страхуванні
- •6.6. Структура автоматизованої інформаційної системи «Страхування»
- •7.1. Особливості вітчизняних систем автоматизації банківських технологій
- •7.2. Теоретичні основи створення автоматизованих банківських систем
- •7.3. Стадії створення автоматизованих банківських систем
- •7.4. Інформаційне забезпечення автоматизованих інформаційних систем у банках
- •7.5. Програмне забезпечення автоматизованих банківських систем
- •8.1. Особливості документообігу у банку при використанні системи «Операційний день банку»
- •8.2. Склад задач, які розв'язуються за допомогою автоматизованої системи «Операційний день банку»
- •8.3. Технологія роботи з системою
- •9.1. Система обліку та контролю банківських валютних операцій
- •9.2. Система «Перекази! операції»
- •9.3. Автоматизована система ведення банківських договорів
- •9.4. Автоматизована система «Облік діяльності філій банку»
- •9.5. Система «Автоматизоване опрацювання даних в обмінному пункті»
- •9.6. Автоматизація фондових технологій в складі банківської діяльності
- •10.1. Основні вимоги до банківських комп'ютерних мереж
- •10.2. Корпоративна банківська мережа
- •10.3. Спеціалізовані системи «банк-клієнт»
- •10.4. Мережа Internet в банківській діяльності
- •10.5. Банкомати
- •10.6. Міжнародні банківські комп'ютерні мережі
- •10.7. Організація розрахунків в системі електронних платежів України
- •10.8. Технологія міжбанківських платежів у комерційному банку
- •10.9. Електронні системи обміну банківськими повідомленнями в Україні
- •11.1. Поняття безпеки банківських інформаційних систем
- •11.2. Загрози та безпека економічних інформаційних систем
10.8. Технологія міжбанківських платежів у комерційному банку
Всі файли, якими обмінюється комерційний банк із системою електронних платежів, умовно можна поділити на такі групи:
1) пакети платіжних документів:
vA — файл початкових платежів від банку в регіональну розрахункову палату;
vB — файл зворотних платежів у банк від банку-одержувача;
2) повідомлення між АРМ про завершення етапів опрацювання."
vK — кінець сеансу АРМ-2, звіт для АРМ-3 про зміну його коррахунку;
vZ — звіт про кінець дня АРМ-3;
vV — кінець дня АРМ-2, зведений документ для АРМ-3 про зміну його коррахунку;
3) файли-квитанції на пакети алатіжних документів та інші файли:
• vT — квитанція на vA;
vS — квитанція на vB. Всі перераховані квитанції видаються системою, тобто відповідним АРМ;
4) технологічні файли:
vU — завдання на коректуру списку учасників;
М — файл бізнес-правил;
5) файли нормативно-довідкової інформації:
SJVAL — довідник валют;
S_ER — довідник кодів помилок;
SJJCH — довідник банків учасників системи електронних
платежів;
SNR — довідник призначень платежу;
M_UCH — файл інвалютних коррахунків;
• USNG — довідник субкорреспондентів шлюзових банків. Для роботи з бізнес-правилами система «Операційний день банку»
повинно мати допоміжний блок, який називається АРМ-М. Він виконує ряд функцій:
для головного банку: • ведення бази даних бізнес-правил для філій;
378
зміна бізнес-правил для філій, формування та відправлення системою електронних платежів;
формування завдань філіям на коригування їх бізнес-правил;
одержання технологічної інформації із системи електронних платежів (файлів М. Т) проходження пакетів бізнес-правил до філії-адресата:
для філії:
ведення бази даних бізнес-правил, що встановлюються для філії;
приймання з системи електронних платежів — завдань на корегування бізнес-правил, виконання відповідної модифікації бази даних, відправлення в систему електронних платежів технологічної інформації (файлів М. S) про опрацювання пакета бізнес-правил;
перевірка початкових платежів філії на відповідність бізнес-пра-вилам і заборону виконання платежів, які не відповідають встановленим бізнес-правилам.
Можлива реалізація АРМ-М як однієї з підзадач АРМ-бухгшітера системи електронних ататежів.
Під час роботи за сьомою моделлю управління роботою філій за допомогою бізнес-правил формуються такі файли:
М. А — файл бізнес-правил, що формується та відправляється головним банком на АРМ-2;
• М. Т — файл-квитанція на відправлений файл бізнес-правил го ловному банку від АРМ-2;
М. В — файл бізнес-правил, які одержує філія від АРМ-2;
М. S — файл-квитанція на файл бізнес-правил, що відправляється
з філії на АРМ-2.
Файли бізнес-правил та квитанції на них мають структуру, аналогічну відповідним файлам системи електронних платежів.
Робота протягом одного робочого дня виконується за таким режимом:
відкривання нового дня;
початок дня;
передавання та приймання пакетів платіжних документів протягом дня;
379
Зацеркляний М. М., Мельников О. Ф.
ІНФОРМАЦІЙНІ СИСТЕМИ І ТЕХНОЛОГІЇ У ФІНАНСОВО-КРЕДИТНИХ УСТАНОВАХ P|fK
кінець дня;
сервіс.
При відкриванні нового дня встановлюється дата для даного банківського дня. Для неї формується каталог поточного банківського дня для відображення роботи системи протягом дня.
В режимі «початок дня» від АРМ-2 приймається низка файлів, які забезпечують роботу системи електронних платежів. Це такі файли:
• vK.OOO, що вміщує інформацію про кошти на коррахунку бан ку на початок робочого дня. Цей файл є обов'язковим, без ньо го не можна виконувати приймання та передавання платіжних документів;
vU — завдання на корегування списку учасників системи електронних платежів. Цей файл є необов'язковим. Він передається лише у випадках появи нових учасників системи електронних платежів.
Для банків, що працюють за сьомою моделлю, надходить файл типу vM, який вміщує бізнес-правила.
Режим «Передавання та приймання пакетів платіжних документів» є основним режимом функціонування системи електронних платежів.
В цьому режимі виконується передавання початкових платіжних документів, приймання та опрацювання документів, що надійшли електронною поштою.
Підготовка платіжних документів виконується в комерційних банках за допомогою власного пакета «Операційний день банку». При цьому система «Операційний день банку» повинна забезпечувати:
• формування всіх реквізитів платіжного документа;
• формування з окремих платіжних документів пакета початкових . платежів;
• розміщення сформованого пакета в каталозі обміну системи «Операційний день банку» та АРМ-3.
Документи, сформовані програмою «Операційний день банку», передаються в АРМ-3 у вигляді текстових файлів.
Приймання та передавання платіжних документів може виконуватися одноразовим завантаженням режиму «Передавання та приймання
380
пакетів платіжних документів» чи автоматично через певні проміжки часу (цей порядок задається параметрами АРМ-3).
АРМ-3 через певний час завантажує електронну пошту. При цьому він опрацьовує файли, які знаходяться у вхідних каталогах від «Операційного дня банку» і АРМ-2, розкладає файли-результати у вихідні каталоги для «Операційного дня банку» та для електронної пошти.
З кожним файлом, який надійшов до АРМ-3, виконуються такі дії:
перевірка на унікальність імені файла протягом банківського дня;
перевірка файла в цілому (правильність формування імені файла, відповідність його поточній даті роботи, відповідність структурі, обчислення та перевірка контрольних сум);
документальна перевірка файла.
Файл, що перевіряється, незалежно від результатів записується у каталог поточного робочого дня.
Якщо перевірений файл не приймається АРМ-3, то формується і надсилається відправнику файла (в «Операційний день банку» для файла vA чи в регіональну розрахункову палату для файла vB) квитанція, яка вказує на причини неприймання файла.
Для одержання довідки про відправлені та прийняті файли необхідно користуватися режимом «Сервіс».
На кожний відправлений в регіональну розрахункову палату файл vA обов'язково має прийти квитанція, за якою можна визначити, пройшли чи ні файли в системі електронних платежів. Якщо протягом деякого інтервалу (1-2 години) довідка не одержана, то це свідчить, що файл взагалі не надійшов у систему електронних платежів. В такому разі необхідно його відшукати у статистиці роботи електронної пошти чи зв'язуватись телефоном із регіональною розрахунковою палатою.
Регіонатьна розрахункова палата обслуговується комплексом АРМ-2, що працює циклічно в автоматичному режимі. За сеанс електронного опрацювання вважається один цикл опрацювання файлів, прийнятих на початку циклу. В сеансі опрацьовуються файли платіжних документів типу vA і vB, а також файли квитанцій типу vT і vS. Після закінчення сеансу регіональна розрахункова палата надсилає тим комерційним банкам, від яких у даному сеансі були одержані файли типу \А та vS, файл із інформацією про динамічний стан технічного
381
Зацеркляний М. М., Мельников О. Ф. <^>Л
ІНФОРМАЦІЙНІ СИСТЕМНІ ТЕХНОЛОГІЇ У ФІНАНСОВО-КРЕДИТНИХ УСТАНОВАХ ШщИ
кореспондентського рахунку — файл типу vK. Ця інформація дає змогу формувати пакети платіжних документів для передавання в систему електронних платежів таким чином, щоб не допустити овердрафт.
АРМ-3 приймає від «Операційного дня банку» тільки файли поточного банківського дня. АРМ-3 передає в «Операційний день банку» всі файли незалежно від їх банківської дати, крім файлів vB.
«Операційний день банку» повинний опрацьовувати незалежно від дати файли V і U. При надходженні в «Операційний день банку» більше одного файла U вони повинні бути опрацьованими в хронологічному порядку.
Єдиний тип файлів системи електронних платежів, який може прийматися і опрацьовуватися за різні банківські дні — це файл В, В день формування пакета «функціональний підтип файла системи електронних платежів» формується рівним «0». Якщо в день формування пакета платежу файл не був проведеним по технічному коррахунку банку, то він переночує на спеціальному рахунку в регіональній розрахунковій палаті, який дістав умовну назву «нічного», і на наступний банківський день АРМ-2 привласнює даному пакету нове ім'я і знову відправляє його банку.
При цьому:
склад і вміст платіжних документів пакета (тобто інформаційних
рядків пакета) не змінюється;
• день і місяць в імені файла (і в заголовному рядку) зміниться — заноситься дата нового банківського дня;
• до «функціонального підтипу» імені файла додається одиниця. Таким чином, непідтверджені файли В відправляються одержува чу протягом 9 банківських днів (в день формування vB «функціональ ний підтип» рівний 0, в подальші дні змінюється відповідно на «1», «2»,..., «9»). Система електронних платежів не зберігає файли vB біль ше 10 днів. Файли, не підтверджені протягом цього терміну, піддягають примусовому квотуванню в регіональній розрахунковій палаті.
Режим «Кінець дня» складається з декількох етапів. Необхідними умовами завершення дня є:
• одержання квитанції від регіональної розрахункової палати на всі відправлені банком файли початкових платежів;
382
Розділ 10 БАНКІВСЬКІ КОМП'ЮТЕРНІ МЕРЕЖІ
• одержання квитанцій від «Операційний день банку» на всі одер жані банком від регіональної розрахункової палати і надіслані до «Операційного дня банку» факти зворотних платежів.
АРМ-3 виконує перевірку, чи на всі відправлені в регіональну розрахункову палату файли vA одержано фашіи-квитанції vT. Якщо в регіональну розрахункову палату відправлені файли типу vA і виконано закривання банківського дня раніше, ніж прийшли квитанції на них., то це вважається порушенням технології роботи в системі електронних платежів. АРМ-3 контролює цю ситуацію і видає повідомлення про те, що закривати день ще не можна з тієї причини, що в системі залишились не квотовані файли vA.
Формується і відправляється в АРМ-2 файл vZ, який містить звіт про роботу системи за даний банківський день.
Протокольний звіт використовується для архівування в регіональній розрахунковій палаті, обліку, звітності та для розв'язування спірних питань. Відправлення цього файла обов'язкове. Відправити файл vZ наступного дня неможливо.
Виконується архівування журналу програми криптографуванням. Після закривання дня створюється архів закритого дня. При спробі архівувати незакритий день видається відповідне повідомлення.
Усі файли системи електронних платежів є текстовими файлами. їх структура має такий вигляд:
службовий рядок;
заголовковий рядок;
інформаційні рядки.
Заголовковий рядок несе інформацію про файл у цілому. Зокрема, він вміщує інформацію про кількість інформаційних рядків у фашіі. Усі інформаційні рядки файла конкретного типу мають однакову довжину (крім файла vM). У деяких типів фашіів інформаційні рядки відсутні. В такому разі склад файла системи електронних платежів обмежується службовими та заголовковими рядками. Усі рядки (службовий, заголовковий і всі інформаційні) закінчуються символами повернення каретки, які позначаються як CRLF. Під час аналізу файла відсутність CRLF розцінюється як порушення структури файла. Розподілювачі кінця факта не
383
ІНФОРМАЦІЙНІ СИСТЕМНІ ТЕХНОЛОГІЇ У ФІНАНСОВО-КРЕДИТНИХ УСТАНОВАХ
використовуються. Службовий рядок використовується для підвищення безпеки та надійності системи електронних платежів.
Усі імена файлів інтерфейсу АРМ-3 — «Операційний день банку» мають таку структуру:
VtARxxmd. fnn,
де V — однобайтний ідентифікатор валюти у системі електронних платежів. Для української національної валюти введене позначення «v». Для інших валют 1-й символ імені файла містить однобайтний ідентифікатор валют згідно з довідником валют системи електронних платежів, який може приймати значення (А... Z, 0... 9); t — тип файла у системі електронних платежів (нині використовуються такі типи файлів: А, Т, В, S, К, Z, V, F, М, U, О). З розвитком системи список може розширюватися; ARxx —ідентифікатор банка в системі електронних платежів; А — однобайтний ідентифікатор АРМ-2 системи електронних платежів, якому підпорядкований банк. Згідно з діючою нині системою це — друга літера електронної адреси АРМ-2. Якщо банк не працює в системі електронних платежів у національній валюті, то ставиться цифра 0; R — ідентифікатор адміністративного регіону України, де розташована банківська установа; хх — унікальний ідентифікатор банку в межах даного регіону. Слід зазначити, що Rxx збігається з останніми трьома байтами електронної адреси банку в електронній пошті Національного банку України; ш — місяць банківського дня за 36-річною системою числення (1, 2, ..., 9, А, В, С); d — день місяця банківського дня за 36-річною системою числення (1, 2, ..., 9, А, В, С,..., U, V); f— функціональний підтип файла системи електронних платежів:
для типу F, М — підтип файла,
для типу В — ознака повторного передавання,
для всіх інших типів — 0;
nn — технологічний номер файла за 36-річною системою числення (00... ZZ). У ньому допускаються цифри від 0 до 9 і латинські літери.
Ім'я файла квитанції формується з імені файла, що квотується, шляхом заміни символу «тип файла» на відповідний тип квитанції (наприклад, А ->Т, В -+S).
384
АРМ-1, АРМ-2, АРМ-3 системи електронних платежів обмінюються інформацією у вигляді текстових файлів.
Кожний пакет платіжних документів повинний вміщувати документи в одній вачюті.
Файли, імена яких побудовані не за заданим стандартом системи електронних платежів, не розглядаються.
Файл А містить інформацію про початкові платежі банку-відправ-ника платежів у систему електронних платежів. Кожний інформаційний рядок несе інформацію про один платіжний документ, всі документи файла повинні бути представленими в одній валюті.
Заголовковий рядок файла А має структуру, подану в табл. 10.2.
Інформаційний рядок файла А має структуру, подану в табл. 10.3.
Реквізит «Номер (операційний) платежу» відповідає номеру, який поставив клієнт-відправник на платіжному документі. Реквізит «Ідентифікатор операціоніста банку А» містить ідентифікатор того операціоніс-та банку А, який сформував електронний платіжний документ і завірив його електронним цифровим підписом. На файл А завжди формується файл-квитанція Т.
Файл vT — це файл-квитанція на відповідний файл vA. Він містить інформацію про те, прийнятий чи ні відправлений на АРМ-2 пакет платіжних документів, якщо ні, то з якої причини.
Таблиця 10.2.
№ з/п |
Назва реквізиту |
Тип |
Довжина |
1 |
Назва файла |
С |
12 |
2 |
Дата+час створення файла |
D |
10 |
3 |
Кількість інформаційних рядків у файлі |
N |
6 |
4 |
Сума дебету по файлу |
N |
16 |
5 |
Сума кредиту по файлу |
N |
16 . |
6 |
Електронний цифровий підпис (ЕЦП) |
В |
64 |
7 |
Ідентифікатор ключа ЕЦП |
С |
6 |
8 |
ЕЦП заголовкового рядка |
В |
64 |
9 |
CRLF |
В |
2 |
Таблиця 10.3
№ з/п |
Назва реквізиту |
Тип |
Довжина |
1 |
МФО банку А |
N |
9 |
2 |
Особовий рахунок клієнта банку А |
N |
14 |
3 |
МФО банку Б |
N |
9 |
4 |
Особовий рахунок клієнта банку Б |
N |
14 |
5 |
Ознака «дебет/кредит» платежу |
С |
1 |
6 |
Сума платежу |
N |
16 |
7 |
Вид платежу |
N |
2 |
8 |
Номер операційний платежу |
С |
10 |
9 |
Валюта платежу |
N |
3 |
10 |
Дата платіжного документа |
D |
6 |
11 |
Дата надходження платіжного документа в банк |
D |
6 |
12 |
Назва платника (клієнта А) |
С |
38 |
13 |
Назва отримувача (клієнта Б) |
С |
38 |
14 |
Призначення платежу |
С |
160 |
15 |
Допоміжні реквізити |
с |
60 |
16 |
Код призначення платежу |
с |
3 |
17 |
Спосіб заповнення реквізитів 14-16 |
с |
2 |
18 |
Ідентифікатор клієнта А |
N |
14 |
19 |
Резерв |
С |
14 |
20 |
Ідентифікатор документа |
N |
9 |
21 |
Ідентифікатор операціоніста банку А |
С |
6 |
22 |
Номер рядка БІР |
N |
2 |
23 |
Резерв |
С |
8 |
24 |
ЕЦП основних реквізитів платежу |
В |
64 |
25 |
Ім'я файла А |
С |
12 |
26 |
Порядковий номер інформаційного рядка у файлі А |
N |
б |
27 |
Час проходження через АРМ-3 А |
Т |
4 |
28 |
Час отримання в АРМ-2А |
т |
4 |
29 |
Ім'я файла С |
с |
12 |
ЗО |
Порядковий номер інформаційного рядка у файлі С |
N |
6 |
386
Розділ 10 БАНКІВСЬКІ КОМП 'ЮТЕРНІ МЕРЕЖІ
Закінчення табл. 10.3
№ з/п |
Назва реквізиту |
Тип |
Довжина |
31 |
Час формування в АРМ-2 С |
Т |
4 |
32 |
Час одержання в АРМ-2 С |
т |
4 |
33 |
Ім'я файла В |
с |
12 |
34 |
Порядковий номер інформаційного рядка у файлі В |
N |
6 |
35 |
Час формування в АРМ-2 В |
Т |
4 |
36 |
Час одержання в АРМ-3 В |
т |
4 |
37 |
Дата одержання в АРМ-3 В |
D |
6 |
38 |
CRLF |
В |
2 |
Таблиця 10.4
№ з/п |
Назва реквізиту |
Тип Довжина' | |
1 |
Назва файла |
С |
12 |
2 |
Дата+час створення файла |
D |
10 |
3 |
Кількість інформаційних рядків у файлі |
N |
6 |
4 |
Сума дебету по файлу |
N |
16 |
5 |
Сума кредиту по файлу |
N |
16 |
6 |
Електронний цифровий підпис (ЕЦП) |
В |
64 |
7 |
ідентифікатор ключа ЕЦП |
С |
6 |
8 |
Назва квотованого (KB) файла |
С |
12 |
9 |
Дата+час створення KB файла |
D |
10 |
10 |
Кількість інформаційних рядків у KB файлі |
N |
6 |
11 |
Сума дебету по KB файлу |
N |
16 |
12 |
Сума кредиту по KB файлу |
N |
16 |
13 |
ЕЦП KB файла |
В |
64 |
14 |
Ідентифікатор ключа ЕЦП KB файла |
С |
6 |
15 |
Код помилки по KB файлу |
С |
4 |
16 |
Електронний підпис заголовкового рядка файла |
в |
64 |
17 |
CRLF |
в |
2 |
25*
387
Зацеркляний М. М., Мельников О. Ф.
ІНФОРМАЦІЙНІ СИСТЕМИ І ТЕХНОЛОГИ У ФІНАНСОВО-КРЕДИТНИХ УСТАНОВАХ ШШі
Файл vA у системі електронних платежів завжди приймається або ж не приймається в цілому, тобто якщо відбракований принаймні один платіж із файла, то інші платежі з цього ж файла також не приймаються до опрацювання.
Якщо vA містить помилки в одному або декількох платежах, то відповідний файл vT містить інформаційні рядки у кількості, яка дорівнює кількості виявлених помилкових документів. Кожний рядок однозначно ідентифікує помилковий документ із відповідними кодами помилок для кожного документа.
Структура заголовкового рядка файла Т має вигляд, поданий в табл. 10.4.
Якщо файл vA вміщує помилку не в платіжних документах, а в за-головковому рядку, то відповідний файл vT не має інформаційних рядків, а містить лише код помилки в інформаційному рядку.
Структура інформаційного рядка файла дається в табл. 10.5.
Файл Т формується лише АРМ-2. Реквізити «Сума дебету по файлу» і «Сума кредиту по файлу» дорівнюють відповідним сумам файла vA, що квотується, якщо файл прийнятий без помилок. Ці суми дорівнюють 0, якщо файл бракується з будь-якої причини.
Файл Т підтверджує нормальне приймання файла у тому випадку, якщо реквізит «Кількість інформаційних рядків» дорівнює нулю, інформаційні рядки взагалі відсутні, код помилки по KB файла дорівнює «0000» і виконуються такі співвідношення:
«Сума дебету по файлу А» = «Сумі дебету по KB файлу» «Сума кредиту по файлу А» = «Сумі кредиту по KB файла».
Таблиця 10.5
№ з/п |
Назва реквізиту |
Тип |
Довжина |
1 |
Порядковий номер інформаційного рядка (IP) у файлі А |
N |
6 |
2 |
Код помилки |
С |
4 |
3 |
CRLF |
|
|
388
Якщо файл vA містить помилку не в платіжних документах, а в за-головковому рядку, то відповідний файл vT не містить інформаційних рядків, а вміщує лише код помилки в інформаційному рядку.
Файл vB містить інформацію про зворотні платежі банку одержувачу платежів у системі електронних платежів. Кожний інформаційний рядок несе інформацію про один платіжний документ. На файл vB завжди формується файл-квитанція vS.
Структура заголовкового рядка файла vB збігається зі структурою заголовкового рядка файла vA. Структура інформаційного рядка файла vB збігається зі структурою інформаційного рядка файла vA. В полі «ЕЦП основних реквізитів платежу» знаходиться електронний цифровий підпис, який накладає АРМ-3 банку-відправника.
Файл vS — це файл-квитанція на зворотний файл vB. Він містить інформацію про те, прийнятий чи ні відправлений пакет платіжних документів, якщо ні, то з якої причини.
У випадку, якщо сам АРМ-3 провів вибраковку vB і навіть не передає його «Операційному дню банку», квитанція S генерується в АРМ-3 і автоматично надсилається до АРМ-2.
Файл vB у системі електронних платежів завжди приймається або ж ні в цілому, тобто, якщо з файла відбракований принаймні один платіж, то інші платежі з цього файла до опрацювання також не приймаються.
Якщо vB містить помилки в одному або декількох платежах, то відповідний файл vS містить інформаційні рядки, кількість яких дорівнює кількості виявлених помилкових документів. Кожний рядок однозначно ідентифікує помилковий документ із відповідними кодами помилок для кожного документу.
Якщо файл vB містить помилку не в платіжних документах, а в за-головковому рядку, то відповідний файл vS не містить інформаційних рядків, а містить лише код помилки в інформаційному рядку.
Зарахування грошей по файлу vB на коррахунок здійснюється тільки після одержання АРМ-2 квитанції S з нульовими кодами завершень на цей файл.
Структура заголовкового та інформаційного рядків файла vS збігається зі структурою відповідних рядків файла vT.
389
ІНФОРМАЦІЙНІ СИСТЕМНІ ТЕХНОЛОГІЇ У ФІНАНСОВО-КРЕДИТНИХ УСТАНОВАХ
Файл vK містить технологічну інформацію про сеанс роботи АРМ-2зАРМ-3:
список файлів vA, що надійшли від АРМ-3;
список файлів vB, на які надійшли файли vS від АРМ-3;
інформацію про величину технічного коррахунку, поточні ліміти
коррахунку тощо.
Розширення у назві файла відповідає номеру технологічного сеансу. Для відстеження правильності у послідовності файлів vK номер попереднього vK зазначається у заголовковому рядку поточного vK.
Файл із розширенням 000 містить інформацію станом на початок банківського дня регіональної розрахункової палати.
Кожний інформаційний рядок містить інформацію про один файл vA чи vB, на які надійшли файли типу vS. Якщо значення реквізиту «Коди помилок» дорівнюють «0000», то сума по даному файлу була проведена по коррахунку.
Файл vS формується у банку і є сигналом для АРМ-2 про те, що АРМ-3 цього банку завершив роботу після приймання/передавання файлів платіжних документів. Файл містить таку інформацію про роботу АРМ-3 з АРМ-2 протягом банківського дня:
список файлів vA, відправлених із АРМ-3 у систему електронних платежів;
список файлів vB, одержаних у банку, на які сформовані і відправлені у систему електронних платежів квитанції vS.
Файл vZ може не містити інформаційних рядків. Розширення файла Z повинно бути рівним «000». Якщо банк працює одночасно з декількома валютами, то на кожний тип валюти формується окремий файл vZ.
Кожний інформаційний рядок містить інформацію про один відправлений файл vA чи надісланий файл vB. Якщо значення реквізиту «Коди помилок» дорівнює «0000», то:
• для відправленого vA одержаний vT без помилок;
для одержаного vB прийнятий із системи «Операційний день банку» та переданий у АРМ-2 vS з нульовими кодами помилок. В усіх інших випадках треба аналізувати конкретні коди помилок. За технологією банк може відправляти протокольний звіт тільки тоді, коли на всі відправлені у регіональну розрахункову палату vA
390
БАНКІВСЬКІ КОМП'ЮТЕРНІ МЕРЕЖІ
одержані квитанції vT та на всі прийняті vB одержані із системи «Операційний день банку» і передані у регіональну розрахункову палату квитанції vS. Якщо банк посилає vZ у момент, коли який-небудь файл не дочекався квитанції, то цей стан файла відображається відповідним кодом помилки на цей файл.
Файл vV містить інформацію про значення технічного коррахунку та про платіжні документи банку:
початкові платежі, прийняті АРМ-2 від банку;
всі зворотні платежі, сформовані АРМ-2 для банку.
Кожний інформаційний рядок несе інформацію про один платіжний документ. Файл vV може не містити інформаційних рядків.
Файл U необхідний для автоматизованого корегування списку учасників електронних платежів у всіх АРМ системи електронних платежів (СЕП).
Структура заголовкового рядка файла U дається в табл. 10.6.
Таблиця 10.6
№ з/п |
Назва реквізиту |
Тип |
Довжина |
1 |
Назва файла |
С |
12 |
2 |
Дата+час створення файла |
D |
10 |
3 |
Кількість інформаційних рядків у файлі |
N |
6 |
4 |
Кількість банків — учасників СЕП до коригування |
N |
16 |
5 |
Кількість банків — учасників СЕП після коригування |
N |
16 |
6 |
ЕЦП файла |
В |
64 |
7 |
Ідентифікатор ключа ЕЦП |
С |
6 |
8 |
Кількість інвалютних коррахунків до коригування |
N |
6 |
9 |
Кількість інвалютних коррахунків після коригування |
N |
6 |
10 |
Резерв |
С |
32 |
11 |
ЕП заголовкового рядка файла |
В |
64 |
12 |
CRLF |
В |
2 |
391
ІНФОРМАЦІЙНІ СИСТЕМИ І ТЕХНОЛОГ!) У ФІНАНСОВО-КРЕДИТНИХ УСТАНОВАХ
Таблиця 10.7
№ з/п |
Назва реквізиту |
Тип |
Довжина |
1 |
Ознака операції |
С |
1 |
2 |
МФО банку |
N |
9 |
3 |
Назва банку |
С |
38 |
4 |
Коррахунок банку |
N |
14 |
5 |
Ідентифікатор банку у СЕП |
С |
4 |
6 |
Електронна адреса банку |
С |
4 |
7 |
Модель роботи з єдиним коррахунком |
С |
1 |
8 |
Номер моделі роботи з єдиним коррахунком |
С |
1 |
9 |
МФО головного банку чи 0 |
N |
9 |
10 |
Ідентифікатор валюти |
N |
3 |
11 |
Тип платіжної системи шлюзового банку |
С |
1 |
12 |
Ознака блокування банку |
С |
1 |
13 |
АРМ-2, який обслуговує валютний рахунок |
С |
1 |
14 |
Резерв |
с |
32 |
15 |
CRLF |
в |
2 |
Інформаційний рядок файла U має структуру, подану в табл. 10.7.