МУБ — что же это такое?

Объектная технология моделирования банка облегчает жизнь не столько программистам, сколько пользователям. МУБ позволяет им самостоятельно конструировать представление банка, что в рамках системы реализуется примерно в такой последовательности:

• Активы, пассивы и внебалансовые позиции банка разделяются на несколько реальных агрегированных позиций (под агрегированной позицией мы понимаем портфель однотипных позиций, например, портфель кредитов в валюте USD физическим лицам, которые не являются инсайдерами).
• Состояние рынка формализуется в виде набора индикаторов (курсов валют, биржевых котировок, фондовых индексов, процентных ставок и т. д.), динамика которых образует сценарий.
• Для любой агрегированной позиции выбирается соответствующая модель представления из имеющихся в составе системы. Каждая модель имеет свою специфику, предназначена для позиций одного или нескольких типов и может быть использована для нескольких агрегированных позиций.
• Каждая агрегированная позиция «привязывается» к нескольким рыночным индикаторам, которые в наибольшей степени влияют на ее состояние.

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

Надо сказать, что разделение банка на агрегированные позиции — исключительно важный вопрос. С одной стороны, чем агрегированные позиции будут мельче, тем более тонкие нюансы мы сможем учесть при расчете эволюции банка. С другой стороны, чрезмерная детализация затрудняет принятие решения, и тогда за деревьями не виден лес.

Рассмотрим простой пример. Допустим, банк реально работает только с рублями и долларами, хотя иногда проводит операции и с казахскими тенге. Разумно ли выделять отдельные агрегированные позиции для требований и обязательств по последней валюте? Вся прелесть состоит в том, что система МУБ предоставляет пользователю возможность самому разобраться с этой проблемой, не прибегая к помощи компании-разработчика. Причем решение данного вопроса не означает его фиксацию раз и навсегда.

Итак, разделяя банк на агрегированные позиции, не нужно обязательно охватывать все возможные типы, а брать только те, с которыми вы реально работаете, остальные же целесообразно агрегировать «до кучи», как «прочие». Если в будущем появятся новые значимые позиции или изменится критерий отнесения позиции к «прочим», то пользователь самостоятельно сможет добавить их в систему.

То же касается показателей, на которые пользователь ориентируется при принятии решений. Дело в том, что система МУБ рассчитывает эволюцию банка на будущий период, а показатели — это всего лишь отдельные характеристики эволюции. Данные эволюции кредитного учреждения являются основой всех показателей, поэтому, не особенно погрешив против истины, можно утверждать, что МУБ позволяет конструировать расчет любых показателей. Отметим, что речь идет не только и не столько о показателях текущего состояния, но о характеристиках будущего. Разумеется, мы имеем в виду показатели, которые можно просчитать исходя из заданного пользователем разделения банка на агрегированные позиции. Допустим, пользователь сгруппировал все кредиты физических лиц в одну агрегированную позицию. Но в таком случае он не сможет определить долю ипотечного кредитования в упомянутом портфеле. Если в этом есть необходимость, то нужно создать две агрегированные позиции: одну — для ипотечных кредитов, другую — для остальных.

МУБ рассчитывает будущее, но не прогнозирует его

Когда мы говорим, что система МУБ рассчитывает эволюцию банка и прогноз его будущего состояния, то подразумеваем именно расчет, для которого планы по управлению позициями и сценарий развития рынка — это исходные данные. Хотя в систему МУБ можно встроить модули прогнозирования рынка (если пользователь таковым доверяет) и поиска оптимальных планов, но не это составляет суть системы.

МУБ может рассчитать последствия заданных вариантов управления ресурсами и рыночных сценариев, но ответы на вопросы «как управлять?» и «как поведет себя рынок?» все-таки придется искать самому пользователю. Система МУБ значительно облегчает решение задач анализа и управления, взяв на себя рутинные вычисления и оставив руководителям и аналитикам банка наиболее интересную и интеллектуальную часть работы. Иначе и быть не может. Не зря же серьезные разработчики говорят о системах поддержки принятия решений, а не собственно принятия решений. Вряд ли стоит полностью полагаться на компьютерные прогнозы рынка и рецепты управления (по крайней мере, если речь идет о периодах, превышающих одну неделю), какую бы высокую надежность ни сулили создатели «прогнозирующих» и «решающих» систем.

Отдельно остановимся на вопросах оценки рисков. Здесь есть два пути:

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

Масштабные оценки в силу своей достоверности имеют существенные преимущества, а сложности расчета можно преодолеть, используя систему МУБ. Она, разумеется, поможет и при получении вероятностных оценок — достаточно задать ей прогнозируемые сценарии. Однако, пожалуй, главным достоинством МУБ является именно возможность расчета масштабных оценок — практически их нельзя получить без такой системы.

Нужна ли МУБ банкам?

В процессе общения с клиентами часто возникают вопросы, касающиеся целесообразности использования «Модели управления банком» в кредитном учреждении. Среди них выделим два наиболее часто встречающихся.

Итак, первое. Задачи, о возможности решения которых объявили разработчики МУБ, чрезвычайно полезны. Стиль решения — замечательный. Но действительно ли система МУБ так хороша, как это декларирует R-Style Software Lab.? Правда ли, что она умеет решать заявленные задачи? И вообще, можно ли доверять отечественным специалистам в столь сложных проблемах? Вот если бы это была известная западная компания, тогда конечно… И второе. Система МУБ — это просто калькулятор. Нельзя ли вместо него с успехом использовать MS Exсel?

Начнем по порядку. Во-первых, как было сказано выше, МУБ — это технологическое, а не научное достижение. МУБ состоит из множества маленьких моделей, написанных в едином стандарте. Каждая такая моделька в отдельности не представляет собой ничего сверхъестественного, в нее заложены обычные расчеты, формулы для которых прописаны в любом учебнике. Эффект достигается именно за счет комплексной обработки всех позиций и внешних факторов (курсов валют, ставок и т. п.), а не за счет применения каких-то оригинальных формул.

Возьмем, например, модель представления депозитного портфеля. Она содержит расчет платежей по процентам и основному долгу, суммы накопленных процентов, обязательных резервов и т. п. Все это рассчитывается при заданных процентных ставках, курсе валюты (для учета курсовой разницы), коэффициенте резервирования и т. п. Ну и что здесь особенного? Если расчеты в подсистемах по учету срочных вкладов не вызывают у пользователей недоверия, то они не должны вызвать беспокойства и в МУБ.

Во-вторых, МУБ — это главным образом инструмент для расчета последствий принимаемых решений и других важнейших вопросов, ответы на которые имеют огромное значение при управлении ресурсами. Если кому-то дали хороший рубанок — это еще не гарантия, что доски у него будут гладко обструганы. В неумелых руках они все равно останутся корявыми, и инструмент здесь не виноват. С другой стороны, очевидно, что без рубанка даже золотые руки ничего не смогут сделать с неровными и шероховатыми досками.

И наконец, в-третьих, откуда такое недоверие к отечественным специалистам? Ведь речь идет не о российской экономической школе, которая лишь несколько лет решает задачи в условиях рынка. В основе аналогичных систем западных производителей на 80—90% лежит математика-арифметика. Посудите сами, вопросы бухгалтерского учета операций и их юридического оформления в системе не затрагиваются, а в остальном банковская сфера деятельности (в отличие от промышленных предприятий) достаточно формализована. Если и задействованы какие-то модели, то скорее математические, чем экономические. Яркий тому пример — системы управления торговыми операциями на бирже. Кстати, а как у нас в Отечестве с математикой? Так вот, со всей ответственностью заявляю, что в области математики мы действительно «впереди планеты всей» — и здесь нет ни грамма иронии. Именно наши математики обучают на Западе тех, чьи программы пользуются у нас таким авторитетом. Это наши выпускники-программисты (из МГУ, МФТИ, МИФИ, МВТУ и т. д.) нарасхват в западных фирмах, за чьи продукты наши пользователи готовы выложить кругленькую сумму (у кого, конечно, есть деньги).

Отступая от темы, скажу, что половина моих знакомых коллег-математиков в последние годы выехала за кордон (иногда доходит просто до смешного, когда на научном семинаре где-нибудь в Германии оказывается, что мало кто говорит по-немецки, но большинство — по-русски). Тем не менее другая-то половина осталась! Думаете, остались те, что похуже? Нет, уезжают, как правило, те, кто тяготеет к теоретическим задачам, — они устраиваются преподавать в зарубежных университетах. Прикладники, которые собственно и нужны при создании программ, чаще всего остаются.

Перейдем к сравнению МУБ с MS Exсel. Здесь, скорее всего, проявляется либо слабое понимание проблемы, либо незнание, что такое МУБ, либо укоренившаяся привычка решать все проблемы с помощью Excel.

Прежде всего, MS Exсel просто не потянет требуемый объем данных, так что на нем сразу можно ставить крест. Обратимся к его более мощному аналогу — MS Access. Заметим, однако, что MS Access уже не так-то прост. Для его использования нужно как минимум уметь программировать на языке Visual Basic. Что тут скажешь? Формально на этом языке можно запрограммировать весьма сложные задачи, но то же самое можно сделать и с помощью любого другого инструмента.

Кроме того, если учесть такие «мелочи», как коллектив профессиональных программистов, несколько человеко-лет программирования, пару лет на разработку технологии и ее становление и прочая, и прочая, то, действительно, систему, подобную МУБ, при помощи MS Access создать можно. Только коллектив ее творцов будет уже, пожалуй, не подразделением банка, а профессиональным производителем программ. А уж что касается себестоимости такого продукта, то она многократно превысит стоимость закупки и установки готовой системы.

Подведем черту. Создание системы МУБ со всеми ее качественными преимуществами — это результат технологических достижений разработчиков. Нас могут спросить: «Раз тут главное — технология, то почему речь шла только о банках? Почему в статье говорится «объектное моделирование банка», а не объектное моделирование предприятия и банка, в частности»? Спросят — и будут правы. Но ответ незатейлив: просто все начиналось с банка. В процессе решения проблем автоматизации управления рисками и ресурсами кредитных учреждений была разработана объектная технология, которую практически без изменений можно перенести на автоматизацию управления и страховой компанией, и казначейством, и другими подобными учреждениями.