Открытый API для платформ дистанционного банковского обслуживания

Андрей Григоров

ведущий архитектор департамента систем электронного банковского обслуживания, R-Style Softlab

Сегодня на наших глазах происходит революция в сфере банковского обслуживания, и мы, разработчики программного обеспечения, стоим в первых рядах вершителей изменений. Тесное и эффективное сотрудничество между банками и финтехом — вот основной вектор развития. Банки ожидают найти новые точки роста за счёт инновационных технологий, финтех-стартапы же ищут в лице банков инвесторов и стратегических партнёров. У первых есть клиентская база, у вторых – идеи и решения, как сделать клиентов счастливее. Но что нужно, чтобы это сотрудничество состоялось? Как банкам стать полигоном для инноваций, а новым финтех-компаниям получить возможность подготовить продукт, готовый к запуску в кратчайшие сроки? Попытаемся дать ответы на эти вопросы, рассмотрев одну из технических сторон дела, а именно интеграцию разрабатываемых приложений с системами ДБО банка на основе открытого API.

Для начала определим условия, которые благоприятно влияют на образование союза банка и финтех-стартапа:

• Банк должен предоставлять открытый API-интерфейс для подключения разработчиков сторонних сервисов. Наличие открытого API к системам банка, а также, возможно, и «песочницы» для сторонних разработчиков делает банк привлекательным для молодых стартапов, которые смогут разработать пилотные продукты под API данного банка.
• Разрабатываемые сторонними разработчиками сервисы не должны стоять в стороне от уже существующих систем банка (интернет-банк, мобильный банк и др.), а должны влиться в его ИТ-среду, стать ещё одним каналом связи с банком.

Омниканальность

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

Открытый банкинг. Что уже есть?

Идея открытого банкинга, строящегося на основе открытого API, не нова. Так, например, с 2010 года в Германии при участии крупнейших банков страны развивается проект Open Bank Project (OBP)¹.

Его цель — создание открытого API для банков, которым разработчики и финтех-компании могут пользоваться для создания клиент-ориентированных приложений и сервисов, требующих доступа к таким данным клиентов банка, как история выполненных транзакций и списки счетов. Помимо доступа к клиентским данным OBP API предоставляет возможность получить так называемые «открытые данные» (open data): списки подразделений и банкоматов, описание банковских продуктов.

Другим примером открытия банком API для разработчиков является API банка Fidor Bank AG². Среди российских аналогов можно отметить проект «Альфа-банка» — «Альфа-старт»³, предоставляющий ИТ-стартапам API для подключения к услугам банка, таким как приём платежей, денежные переводы между пользователями, онлайн-кредитование.

Наряду с банками свои API открывают и платежные системы. Так, значимым событием начала этого года стало появление Visa Developer Center⁴ — сервиса, через который Visa предоставляет доступ к своим технологиям сторонним разработчикам.

Следует отметить, что развитие технологий открытого API в настоящее время переходит на уровень государственного регулирования. В 2015 году правительство Великобритании инициировало создание Open Banking Working Group (OBWG) — экспертной группы, в которую вошли представители банков, финтех-компаний и специалисты в области открытых данных. Целью работы данной группы является создание стандарта открытого банковского API (Open Banking Standard) и исследование влияния открытого банкинга на клиентов банка, регуляторов и финансовую индустрию. Правительство Великобритании ожидает, что внедрение данного стандарта позволит Соединённому королевству удержать лидирующее положение в финтех-индустрии.

Не отстают и другие страны Евросоюза. C 12 января 2016 года вступила в силу вторая редакция европейской платежной директивы PSD2⁵, одним из требований которой является открытие банками API третьим сторонам. Ожидается, что исполнение требований регуляторов должно усилить в Европе конкуренцию на рынке мобильных и онлайн-платежей за счёт более простого выхода на рынок технологических нефинансовых компаний.

В России вопрос регулирования отрытого банкинга со стороны государства пока ещё не анонсировался. Однако при этом очевидно, что банкам, которые хотят остаться в мировом тренде, уже сейчас необходимо предпринимать шаги в сторону внедрения открытого API, не дожидаясь дополнительного стимула со стороны ЦБ.

Три кита открытого банкинга

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

• Данные.
• Удачно спроектированный, реализованный и поддерживаемый API.
• Полная и корректная организация информационной безопасности данных и сервисов.

Взглянем на каждого «кита» поближе.

Типизация данных

Следуя терминологии, предложенной рабочей группой Open Banking Working Group, все данные, которыми оперирует банк, можно разделить на три категории:

1. Закрытые (closed). К этому типу относятся внутренние регламенты банка, правила ценообразования, алгоритмы установки курсов конвертации валют, данные о рентабельности банка, то есть все то, что является коммерческой тайной банка и обеспечивает его преимущество в конкурентной борьбе на рынке.
2. Разделяемые (shared). К этому типу относятся данные клиентов банка, доступ к которым ограничен и предоставляется в соответствии с установленными правилами. Это информация об истории выполненных транзакций, о балансе карт, а также данные о счетах клиента, которые, в частности, могут быть использованы для инициирования выполнения новых платежей.
3. Открытые (open). Данные, к которым каждый может получить доступ, использовать их и распространять. Например, это может быть список отделений банка или информация о типах вкладов, которые клиент может открыть в банке.

При проектировании открытого API ориентируются на последние два типа — разделяемые и открытые данные.

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

• требующие авторизации при обращении к сервису (для разделяемых данных);
• не требующие авторизации (для открытых данных).

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

Архитектура API

В настоящее время при построении сервисных систем, работающих поверх HTTP, наибольшее распространение получили протокол SOAP, который реализует концепцию удалённого вызова процедур RPC и в качестве формата передачи сообщений использует XML-документы, и RESTful веб-сервисы, построенные с учётом требований REST-архитектуры и использующие обычно JSON как формат представления данных.

Следуя мировым трендам в области программирования, разработчики Web API сейчас часто склоняются к использованию более удобных REST и JSON в качестве альтернативы тяжеловесным SOAP и XML. Однако следует отметить, что REST — это всего лишь архитектурный стиль, не являющийся утверждённым стандартом или протоколом, который даёт только рекомендации по организации распределённого взаимодействия компонентов системы в сети. Поэтому при создании API на основе REST следует обязательно проработать следующие моменты:

• составить набор ресурсов (сервисов), к которым предоставляет доступ API;
• определить формат передаваемых данных, ограничений и правил валидации значений;
• определить используемые HTTP-методы и HTTP-статусы;
• установить правила версионирования API;
• подготовить примеры использования созданного API и написать руководство пользователя для разработчиков.

Как можно заметить, большинство из перечисленных требований при применении SOAP-протокола удаётся удовлетворить с помощью WSDL-описания веб-сервиса. Так с помощью WSDL определяются наборы операций, задаётся XSD-схема для валидации передаваемых сообщений. При наличии WSDL у разработчиков, которые хотят использовать веб-сервис, нет проблем с тем, чтобы автоматизировать генерацию клиентского кода, — для популярных языков существует множество удобных библиотек и фреймворков, позволяющих это сделать.

Подобного повсеместно распространенного способа, как WSDL, для описания REST-сервисов пока ещё нет. В 2009 году компания Sun Microsystems предложила использовать для REST-сервисов аналог WSDL — WADL (Web Application Description Language), однако популярности среди разработчиков REST-сервисов он не снискал. Наиболее удачными технологическими решениями, которые позволяют получить комплексное, четкое, недвусмысленное описание REST API, являются RAML (RESTful API Modelling Language)⁶ и Swagger⁷. С их помощью создается машиночитаемое описание API, в тоже время удобное и для восприятия человеком. Учитывая, что с 2016 года формат описания API, применяемый Swagger, стал основой для Open API Specification⁸ — разрабатываемого под управлением Linux Foundation стандарта для описания REST API, наиболее перспективным при разработке новых сервисов видится использование Swagger.

Если не вдаваться в подробности, то основные возможности, которые предоставляет Swagger, таковы:

• Предоставление описания набора ресурсов (сервисов) в формате JSON или YAML, в том числе с учётом аспектов аутентификации и авторизации.
• Описание формата JSON объектов, передаваемых в запросах и ответах, с использованием JSON Schema⁹.
• Генерация документации по подготовленному описанию сервисов. При этом можно сделать документацию интерактивной, чтобы была возможность выполнять тестовые запросы к сервису прямо со страницы с его описанием.
• Возможность генерации кода клиентской и серверной частей для распространённых языков на основе JSON-описания REST API.
• Возможность использования подхода «bottom-up», когда описание REST API генерируется по коду уже разработанных сервисов.

Количество различных ресурсов и операций, которые банки могут предоставлять через открытый API, измеряется несколькими сотнями, потому помимо технической платформы, такой как Swagger или другие аналогичные решения, удобство API обеспечивается также наличием чёткого, логично сгруппированного набора сервисов. Например, джентельменский набор бизнес-операций, доступный в приложениях мобильного банкинга для физических лиц от ведущих российских компаний — разработчиков систем ДБО, можно по функциональному назначению разделить на несколько групп:

• сервисы авторизации и безопасности (аутентификация в системе, получение паролей 3-D Secure, привязка мобильного устройства к учетной записи клиента и др.);
• информационные сервисы (получение списка счётов/карт/кредитов клиента, формирование выписок, публикация списка отделений и банкоматов и др.);
• платёжные сервисы (перевод между счетами клиента, отплата услуг, переводы по номеру карты и др.);
• сервисы подачи заявок (на открытие или закрытие вклада, получение кредита).

И прежде чем перейти к вопросу информационной безопасности, вспомним то, без чего даже самый хорошо спроектированный и задокументированный API будет бессмысленным,— реализацию. Для того чтобы сторонние разработчики могли скорее проверить свои идеи и воплотить планы в реальность, вместе с доступом к описанию API банки должны предоставлять доступ к тестовым средам — своего рода «песочницам», где программисты смогут «поиграться» с API. Подобные «песочницы» могут быть организованы совместно с демо-стендами интернет-банков. Разработчики, имея доступ к демо-версии интернет-банка, смогут увидеть текущие возможности, предоставляемые клиентам банка, предложить новый вариант реализации существующей функциональности или создать дополнительные опции, отсутствующие в текущей системе ДБО.

Информационная безопасность

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

Заключение

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

Команда R-Style Softlab идёт в ногу со временем. В конце 2015 года в составе программного комплекса InterBank RS, на базе которого созданы омниканальные системы ДБО физических и юридических лиц, был реализован REST API. Он охватывает более 50 операций, которые могут быть выполнены с данными физического лица — клиента банка. Разработанный API уже используется в новой версии мобильного приложения InterBank Mobile Retail. Подробнее о новом REST API InterBank RS мы расскажем в одной из следующих статей нашего корпоративного блога.

¹http://www.openbankproject.com/

²http://docs.fidor.de/

³ http://start.alfabank.ru/

⁴https://developer.visa.com/

⁵http://ec.europa.eu/finance/payments/framework/index_en.htm#151008

⁶ http://raml.org/

⁷ http://swagger.io/

⁸ https://openapis.org/

⁹ http://json-schema.org/