а архітектура), безумовно, сприяє мінімізації операційного ризику. Справа в тому, що «монолітний» ПО, в якому одні й ті ж процедури використовуються для реалізації різних банківських продуктів, надзвичайно чутливо до модифікацій - будь-яке внесене в інтересах конкретної функціональності зміна може непередбачувано позначитися на інших функціях. А так як в даний час потік нормативних змін правил виконання банківських операцій та формування звітності досить інтенсивний, то і відповідні зміни в ПО АБС вносяться практично постійно.
) Мінімізація операційного ризику в АБС. Методологічний аспект.
В основі функціонування будь-якої автоматизованої інформаційної системи лежить двійкова логіка. Тому реалізація у вигляді програмного коду можлива лише для чітко формалізованих алгоритмів. Найяскравішою ілюстрацією цієї тези є створення в даний час шахових комп'ютерних програм, переважаючих шахістів-професіоналів. У цьому немає нічого дивного - адже шахова партія розвивається за чіткими, суворо визначеними правилами, кількість варіантів ходів для кожної фігури в кожній ситуації також аж ніяк не нескінченно. Тому формалізований опис правил у вигляді програмного коду цілком здійсненно, а кількість аналізованих варіантів залежить від швидкодії обчислювальних засобів. А так як комп'ютер не втомлюється і не «позіхає», то у нього є перевага перед людиною.
Повертаючись до операційних ризиків в АБС, в цьому зв'язку слід зазначити величезне значення для їх мінімізації методологічного забезпечення, під яким тут розуміється законодавча база. Справді, чим чіткіше прописані правила виконання операцій в законах, інструкціях, розпорядженнях та інших нормативних документах, тим менше ризик виникнення помилок при реалізації банківського продукту в АБС.
На жаль, поточна ситуація далека від ідеалу. Так, наприклад, задумана однозначна ідентифікація фізичних та юридичних осіб по ІПН не дала належного результату. Через це розробники АБС змушені винаходити свої власні евристичні алгоритми ідентифікації клієнтів, які не завжди спрацьовують правильно.
Іншим прикладом є правила формування документа «Платіжне доручення». Свого часу ці правила були доповнені порядком формування полів для податкових реквізитів. Однак такий важливий реквізит, як ПДВ, був залишений в неструктурованому полі «Призначення платежу», причому його друк у вихідний формі необхідно здійснювати з нового рядка. Цю ситуацію кожен розробник ПЗ також вирішує по-своєму.
Таких прикладів можна навести досить багато. Але ці проблеми в процесі експлуатації поступово вирішуються також емпіричним шляхом. В даний час у зв'язку з практикою застосування Федерального закону «Про протидію легалізації (відмиванню) доходів, одержаних злочинним шляхом, і фінансуванню тероризму» аналізований тут методологічний аспект набуває особливого значення.
Практично у всіх АБС з'явився додатковий функціонал для реалізації положень згаданого Закону та пов'язаних з ним нормативних актів Банку Росії та інших урядових органів влади:
ідентифікація клієнтів, встановлення та ідентифікація вигодонабувачів - збір інформації з метою протидії легалізації (відмиванню) доходів, одержаних злочинним шляхом, і фінансуванню тероризму;
виявлення операцій, що підлягають обов'язковому контролю, і інших операцій ...
