Андрей Григоров, ведущий эксперт, IТ-архитектор систем электронного банковского обслуживания компании R-Style Softlab, поделился своим видением перспектив развития в России практик работы с отрытыми банковскими данными с использованием API.
— Андрей, на ваш взгляд, открытие банками и платежными системами своих API — это дань моде, выполнение требований регуляторов или веление бизнеса?
— Я считаю, что распространение в настоящее время идей открытых API является закономерным этапом развития банковского ПО, в частности систем ДБО. Если проследить эволюцию систем дистанционного обслуживания, то можно заметить, что сейчас открытые API создаются на базе опыта, накопленного десятилетиями.
Вначале финансовые учреждения развивали интернет-банкинг. В этот период решались вопросы интеграции с бэк-офисными системами, дорабатывались АБС, на стороне которых создавался приватный API, предоставляющий интернет-банку доступ к информации об используемых клиентами банковских продуктах и проводимых с ними операциях.
Следующим этапом, который, к слову, еще не завершился, стало развитие приложений мобильного банкинга. На первых порах через мобильные приложения предоставлялись информационные сервисы, такие как просмотр списка счетов, получение информации о проведенных транзакциях и просмотр остатка на карточном счете. Для этого, в принципе, мог использоваться уже созданный API на стороне АБС. Однако такой подход приводил к тому, что системы интернет- и мобильного банка могли быть разделены и работать независимо друг от друга. Сейчас ситуация существенно изменилась, так как отсутствие взаимосвязи между различными каналами, невозможность продолжения операции, начатой через один канал, используя другой канал, — это не то, чего ожидают клиенты от современной кредитной организации.
Развивая омниканальные системы ДБО, позволяющие клиентам беспрепятственно и прозрачно переключаться с канала на канал, банки переносят API, использующийся мобильными приложениями, на сторону платформ, на которых функционируют интернет-банки. Естественным дальнейшим развитием API для мобильного банка является его усовершенствование и открытие сторонних сервисов для разработчиков. Тем самым появляется еще один канал ДБО, используя который банки ожидают найти новые точки роста за счет инновационных решений, предлагаемых финтех-компаниями.
Следует отметить, что наличие открытого API к системам банка делает его привлекательным для молодых стартапов, которые смогут разработать пилотные продукты под API данного кредитного учреждения, при этом больших финансовых вложений со стороны финансовой организации в этом случае не потребуется.
Если в России вопрос государственного регулирования открытого банкинга еще не стоит и инициатива развития открытого API исходит от банков, желающих следовать мировым трендам, то, например, в Евросоюзе уже с января этого года вступила в силу вторая редакция европейской платежной директивы PSD2, одним из требований которой является открытие финансовыми учреждениями API третьим сторонам. Один из ожидаемых эффектов — усиление в Европе конкуренции на рынке мобильных и онлайн-платежей, в первую очередь за счет более простого выхода на рынок технологических нефинансовых компаний.
— Какие именно данные и кому доступны благодаря банковским API?
— В общем случае можно говорить, что банковские данные делятся на три категории: открытые, разделяемые и закрытые. Примерами открытых данных являются информация о параметрах вкладов, которые клиент может открыть в банке; размеры ставок по кредитным продуктам; режим работы и адреса отделений и банкоматов. Эти данные может использовать каждый. К разделяемым относятся данные клиентов банка, доступ к которым ограничен и предоставляется в соответствии с законодательством и принятыми в финансовом учреждении регламентами. Например, это информация об остатках на счетах клиента, история выполненных транзакций или сведения, которые могут позволить инициировать выполнение транзакций от лица клиента. К закрытым данным относятся внутренние регламенты банка, используемые алгоритмы и правила ценообразования, то есть все то, что составляет коммерческую тайну и обеспечивает конкурентные преимущества.
Таким образом, через открытый API будет предоставляться доступ к открытым и разделяемым данным. К первым — без ограничений, ко вторым — по разрешению клиента в соответствии с установленными правилами и ограничениями.
— Как обеспечивается должный уровень информационной безопасности?
— С технической точки зрения организация процесса доступа сторонних информационных систем к клиентским данным в рамках использования открытого API не сильно отличается от организации взаимодействия с приложениями мобильного банка. Так, при создании серверной части систем ДБО, отвечающих за обработку запросов к открытому API, следует исходить из того, что любым данным, передаваемым в запросах, нельзя доверять, так как они могут быть изменены злоумышленниками. Следовательно, все входные данные должны проходить предварительную проверку. В том случае, если на стороне серверной части не выполняется должная проверка связи текущей сессии пользователя с данными, которые передаются в запросе, злоумышленник может, подменив параметры запроса (например, идентификатор счета назначения перевода), инициировать выполнение операции, недопустимой с точки зрения бизнес-процессов, заложенных в систему ДБО.
Однако у многих клиентов банка возникают опасения, что стороннему сервису станет доступно слишком много персональной информации. Поэтому при проектировании процесса аутентификации и авторизации обязательно следует предусматривать возможность не передавать учетные данные, например такие, как логин и пароль к интернет-приложению. К тому же у клиента банка должна быть возможность ограничить набор данных, к которым он предоставляет доступ. Выполнить эти требования позволяет открытый протокол авторизации OAuth 2.0.
— Какие технологии лучше всего подходят для построения API (SOA и т.д.)?
— На текущий момент для реализации открытых API наибольшее распространение получили RESTful-сервисы, проектируемые с учетом требований REST-архитектуры и использующие обычно JSON как формат представления данных. Однако протокол SOAP, который реализует концепцию удаленного вызова процедур RPC и использует XML-документы в качестве формата передачи сообщений, также продолжает использоваться многими разработчиками.
Так как потенциальное количество операций и методов, предоставляемых в банковском API, может достигать нескольких сотен, на первый план выходит задача качественного документирования и описания API. При этом для организации быстрой разработки программных продуктов, использующих предложенное API, необходимо применять такой формат описания сервисов, который позволит в автоматическом режиме генерировать программный код.
Наиболее перспективным технологическим решением, которое позволяет получить комплексное и четкое описание REST API, является Swagger. С его помощью создаются как машиночитаемое описание API, так и интерактивная пользовательская документация, позволяющая выполнять тестовые запросы к сервисам прямо со страницы с их описанием. Подобный подход по генерации документации REST API используется в платформе InterBank RS, на основе которой компания R-Style Softlab разрабатывает системы ДБО. Отмечу, что в 2016 году формат описания API, применяемый Swagger, стал основой для Open API Specification, разрабатываемого под управлением Linux Foundation-стандарта для описания REST API.
— Приживется ли, по вашему мнению, стандарт PSD2 у нас в стране?
— Действие директивы PSD2 распространяется только на страны Европейского союза. Можно ожидать появления альтернативных инициатив от ЦБ, однако в настоящий момент со стороны государства нет каких-то требований по предоставлению API третьим сторонам. Поэтому, если говорить о влиянии PSD2 на российский банковский сектор в части отрытых API, то, скорее всего, эти требования будут выступать ориентиром для тех банков, которые хотят не отставать от западных коллег.
В любом случае стоит обратить внимание на то, как в других странах решают проблему стандартизации работы с открытыми данными. Так, в 2015 году правительство Великобритании инициировало создание Open Banking Working Group (OBWG) — экспертной группы, в которую вошли представители банков, финтех-компаний и специалисты в области открытых данных. Эта группа занимается разработкой стандарта открытого банковского API (Open Banking Standard) и исследованием влияния открытого банкинга на клиентов банка, регуляторов и финансовую индустрию. С первыми результатами работы группы можно ознакомиться уже сейчас — подготовлен отчет, описывающий основные составляющие разрабатываемого стандарта. Кстати, рекомендации, представленные в отчете — такие как поддержка версионности API, использование при построении открытого API REST-архитектуры, JSON в качестве формата передачи данных и Swagger как инструмент описания API — были учтены нашей компанией при создании новых версий REST API платформы InterBank RS и мобильного приложения InterBank Mobile Retail, использующего это API.
— Есть ли реализованные кейсы в мире и в России? О каких тенденциях уже можно говорить?
— Первые реализации идей открытого банкинга, строящегося на основе открытого API, появились достаточно давно. Так, с 2010 года в Германии при участии крупнейших банков страны развивается проект Open Bank Project (OBP). Наряду сбанками свои API открывают и платежные системы. Наиболее ярким событием начала 2016 года стало открытие Visa API для сторонних разработчиков — Visa Developer Center.
Российские банки тоже не стоят в стороне. Например, Банк Открытие в ноябре этого года предоставил API личному кабинету пользователя и сервису переводов с карты на карту финалистам конкурса финтех-приложений Open Fights. Наша компания в одном из крупнейших госбанков России недавно внедрила на платформе InterBank RS систему мобильного банка, в которой используется REST API, обладающий свойствами «открытости». Он охватывает более 50 операций, которые могут быть выполнены с данными физическим лицом — клиентом этого кредитного учреждения. Сюда входят: получение списков текущих счетов, карт, вкладов, кредитов, а также их основных атрибутов (номера счетов, остатки на счетах, тарифные планы); получение информации об истории операций, выполненных в разных каналах системы ДБО; получение информации о начислениях через систему ГИС ГМП по паспортным данным, ИНН пользователя или уникальному идентификатору начисления; оплата начислений за коммунальные услуги (ГИС ЖКХ) и др. При необходимости банк сможет не только использовать API для организации работы приложений мобильного банка, но и открыть его для использования разработчиками сторонних сервисов.
В июле этого года компания Gartner на знаменитой кривой цикла зрелости технологий поместила технологии открытых банковских API в группу набирающих популярность. Если следовать таким прогнозам, то в скором будущем нас ждет большое количество примеров различных вариантов использования открытого API. Эти попытки будут и удачными, и неудачными, но в результате на их основе сформируются работающие кейсы, которые получат массовое распространение.
