О программных интерфейсах к банковским информационным системам

Открыты ли открытые API?

Интерфейс прикладного программирования или API (application programming interface) – это соглашение, в соответствии с которым одна программа для решения своих задач может запрашивать услуги у другой программы, предоставляющей доступ к некоторым своим возможностям. Когда заходит речь об API банков, обычно подразумевается наличие доступа к функциям банковских информационных систем из программ, разработанных третьими лицами, для:

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

Во многих публикациях предназначенные для перечисленных целей API банков, уже существующие или ещё ожидаемые, называют «открытыми». При этом возникают следующие вопросы:

1. Как могут открытые API использоваться для предоставления и общедоступной, и конфиденциальной информации?
2. Если API открытые, означает ли это, что воспользоваться ими может любой желающий?
3. Могут ли устанавливаться барьеры на доступ к открытым API, например, в виде ценза по правовому статусу или заградительных тарифов?

Для того, чтобы подойти к ответу на эти вопросы, нужно уточнить понятие «открытый API», которое зачастую используется на уровне интуиции и вдобавок смешивается с англоязычным термином «Open API». Задача не так проста, как кажется. Например, Фонд свободного программного обеспечения приложил много усилий к выработке определения, что же такое «свободное программное обеспечение», однако периодически всё равно продолжают вспыхивать споры по этому вопросу.

История появления Open API

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

В наиболее простом случае, когда взаимодействующие программы работают на одном компьютере, говорят о локальном API, например, между операционной системой и выполняющейся под её управлением программой, таком как POSIX или Win32/64 API. Данные в этом случае передаются через общие области оперативной памяти компьютера.

С распространением вычислительных сетей возникла необходимость в организации взаимодействия между программами, работающими на разных компьютерах. Появились такие технологии как RPC, DCOM и CORBA. Их работа основана на отправке по сети пакетов, содержащих информационные запросы в двоичном коде определённой структуры, и получении пакетов с ответами в аналогичном виде.

В настоящее время наиболее распространённой сетевой технологией является Web – система размещённых в сети Интернет взаимосвязанных документов (страниц), обмен данными в которой осуществляется по протоколу HTTP. Это обусловило популярность Web API, реализованных на основе соглашений SOAP и REST, подразумевающих сетевой обмен сообщениями в формате структурированного текста XML и JSON [1].

Благодаря лаконичности и удобству использования в веб-приложениях, связка HTTP + REST + JSON завоевала наибольшую популярность в качестве негласного стандарта на взаимодействие программных систем через сеть Интернет и легла в основу RESTful Web API.

Для того, чтобы облегчить использование API заинтересованными сторонами, было разработано соглашение Open API Specification (спецификация открытых API). Оно описывает стандартный способ документирования RESTful Web API в виде, пригодном как для чтения людьми при ознакомлении с возможностями и особенностями работы API, так и для автоматической генерации программных модулей, реализующих работу с API. На настоящий момент актуальна версия 3.0.2 спецификации Open API [2].

Таким образом, термин «Open API» означает RESTful Web API, удовлетворяющий требованиям спецификации Open API. Такое толкование отличается от смысла, который несёт понятие «открытый API» во многих публикациях, где авторов больше заботит возможность получения доступа к API, нежели их технологическая основа.

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

Вариант классификации API

С точки зрения целевой аудитории API можно разделить на внутренние и внешние.

Если в компьютерной системе, принадлежащей одной организации, программные подсистемы взаимодействуют посредством API, то такие API можно назвать внутренними (internal) API этой организации. Например, внутренние API могут использоваться для взаимодействия учётно-операционной системы банка (далее – УОС) с системой обслуживания транзакций по банковским карточкам этого же банка.

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

По уровню доступа API можно разделить на публичные и защищённые. Если банк реализует выдачу из АБС сведений о местонахождении своих структурных подразделений, курсах валют в обменных пунктах, времени и режимах работы банкоматов, то API, предоставляющие такие сведения, будут публичными (public). Информация, передаваемая через такие API обычно размещена в открытом доступе для всех желающих на интернет-сайтах банков.

С другой стороны, услуга по выдаче информации о состоянии клиентских счетов и выполнению операций со счетами может быть предоставлена только тому клиенту, который является владельцем этих счетов. Такого рода услуги должны предоставляться через защищённые (protected) API, реализующие помимо самого информационного обмена процедуры взаимной аутентификации клиента и банка, а также шифрование передаваемых данных.

С учётом предложенной классификации, проиллюстрированной рисунком, можно позиционировать, например, API, о которых идёт речь в Докладе Д. Л. Калечица «Об интерфейсах прикладного программирования» [3]: платёжные API попадут в категорию внешних защищённых API, информационные – в категорию внешних публичных API. Решение о том, к какой категории внешних API отнести статистические API, требует дополнительных знаний о степени конфиденциальности передаваемых через них сведений.

С большой степенью вероятности можно предположить, что, говоря о банковских API, большинство авторов под «открытыми API» подразумевает «внешние API», как публичные, так и защищённые. К сожалению, словосочетание уже прижилось, однако ещё остаётся надежда на более точное определение в разрабатываемых национальных стандартах, как это предусмотрено пунктом 5 Дорожной карты [4].

API в банковской системе Беларуси

Для финтех-компаний и клиентов интерес представляют внешние публичные и защищённые API банков. Рассмотрим, как выглядит в этом аспекте ситуация на конец мая 2019 года. Из двадцати пяти проанализированных банков, действующих на территории Беларуси, внешние API в том или ином виде предоставляют девять (таблица).

Национальный банк Республики Беларусь (далее – НБРБ) в силу своей специфики предлагает только внешние публичные API для получения в структурированном виде общедоступной информации, такой как справочник банков, ставка рефинансирования, цены мерных слитков и курсы валют.

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

К сожалению, на интернет-сайте банка отсутствует справочник, консолидирующий информацию обо всех реализованных API. Узнать о существовании API для получения тех или иных сведений можно, лишь попав на страничку сайта, посвящённую искомым сведениям.

ОАО «АСБ Беларусбанк», ОАО «Белагропромбанк» и ОАО «Банк Дабрабыт», как и НБРБ, предоставляют внешние публичные API, реализованные по технологии Web API.

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

API ОАО «Банк Дабрабыт» возвращают ответ в формате XML, в отличие от остальных банков, ответ которых представлен в JSON. Кроме того, API этого банка не позволяют устанавливать фильтры и ограничивать объём возвращаемых сведений. Так, по запросу новостей выдаются статьи с 2016 года общим объёмом около одного мегабайта.

Наиболее полно спецификацию Open API реализовали банки ЗАО «Альфа-Банк» и «Приорбанк» ОАО. Помимо неформальных описаний API они предоставляют Swagger-файлы, позволяющие автоматизировать построение интерфейсов для использования API в приложениях, и тестовые площадки, где разработчики могут проверить применение API.

Перечисленные банки реализовали как публичные, так и защищённые API. Однако защищённые API позволяют только запрашивать информацию – сведения о счетах, остатках и движениях средств по счетам, о состоянии созданных и поступивших документов. Модифицировать же информацию или создавать новые документы через API нельзя.

Для использования как защищённых, так и публичных API, реализованных этими банками, требуется регистрация с получением маркеров доступа. Помимо этого, «Приорбанк» ОАО допускает к регистрации только юридических лиц и индивидуальных предпринимателей.

ОАО «Белгазпромбанк» и ЗАО «БСБ Банк» заявляют о наличии защищённых API для использования в рамках услуги дистанционного банковского обслуживания (далее – ДБО). Подробной информации о том, что они собой представляют, в открытом доступе нет. О наличии API в ОАО «Банк БелВЭБ» известно лишь из информационного сообщения банка от 22 мая 2019 года, в котором речь идёт о внедрении онлайн-кредита в приложении и на сайте партнёров банка посредством технологии открытых API.

Оценка текущей ситуации

Из приведенного выше обзора видно, что банки, предоставившие доступ к своим API, по-разному трактуют принцип открытости. Одни реализуют их в соответствии со спецификацией Open API, но при этом возводят барьеры на пути использования публичных API. Другие предоставляют к публичным API свободный доступ, не требуя выполнения дополнительных условий, однако ограничиваются неформальным документированием.

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

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

В то же время, предоставление информации, которая открыто присутствует на интернет-сайтах банков, в структурированном виде через публичные Web API может представлять интерес даже в простейшем варианте, когда веб-сервер банка по определённому адресу возвращает JSON-документ. Внедрение такого API не требует от банков больших затрат: веб-серверы уже давно вошли в состав их информационной инфраструктуры, а файлы с редко изменяющимися сведениями (такими как информация о региональной сети банка) могут быть подготовлены и поддерживаться в актуальном состоянии даже вручную.

Для удобства использования публичных API желательно унифицировать их адреса доступа и основные модели. Если договориться о том, что API всех банков будут доступны по ссылкам вида https://[веб.сайт.банка]/api, где «веб.сайт.банка» – это адрес банковского интернет-сайта, приведенный в справочнике НБРБ, то сбор информации по всем банкам можно осуществить простой итерационной процедурой.

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

Библиографический список:

1.  Ньюмен, С. Создание микросервисов / С. Ньюмен. – СПб.: Питер, 2016. – 304 с.
2.  Open API Specification [Electronic resource] // SmartBear Software. – Mode of access: https://swagger.io/specification/. – Date of access: 27.05.2019
3.  Калечиц, Д.Л. / Об интерфейсах прикладного программирования / Д.Л. Калечиц // Банкаўскі веснік. – 2018. – №7. – С. 9-11.
4.  Дорожная карта разработки стандартов открытых банковских API [Электронный ресурс] // Национальный банк Республики Беларусь, Научно-технологическая ассоциация «Конфедерация Цифрового Бизнеса». – Режим доступа: https://nbrb.by/payment/kcb/dorozhnaya-karta-api.pdf. – Дата доступа: 25.05.2019