Программный интерфейс взаимодействия (Application Programming Interface, сокращенно “API”) обеспечивает взаимодействие между разными системами и приложениями, благодаря чему функционал одного приложения стает доступным внутри другого. Вот простейший иллюстративный пример. Наверняка почти каждый из читающих этот текст много раз, работая в интернете, сталкивался с предложением авторизоваться на каком-либо сайте с использованием данных Facebook или аккаунта Google. Конечно, можно пройти регистрацию по стандартной схеме, тем более что этот процесс стараются делать не очень долгим, но если уже есть сторонний аккаунт, и предлагается осуществить вход с его помощью, так будет намного проще. Как это становится возможным?

Все дело в способности различных систем к взаимодействию (передаче данных) друг с другом с помощью специального интерфейса взаимодействия, который и называется API. По сути своей, это набор правил, объясняющих, как компьютеры или отдельные приложения должны контактировать друг с другом, благодаря чему появляется возможность разрешить сторонним участникам доступ к функциональности данных из своих систем и приложений. Эти внешние участники, к слову, вовсе необязательно что “внешние”, ведь это могут быть и департаменты внутреннего аудита, которым также необходим доступ к данным, например, отдела продаж. Кроме них, можно вспомнить про бизнес-партнеров и внешних разработчиков приложений, с которыми компании ведут бизнес. В целом, уже понятно, что без API деловое сотрудничество в современном понимании оказалось бы очень сильно затруднено.

Являются ли такие правила взаимодействия чем-то новым? В принципе, нет: API примерно того же возраста, что и современные компьютеры. Просто нынешняя “сетевая” инкарнация появилась уже с распространением популярных социомедийных платформ вроде Facebook или Twitter. Но еще и до них известная Amazon первой сделала огромный шаг вперед в освоении открытого доступа к цифровым ресурсам: в 2002 году свет увидел “API Mandate” , указание главы корпорации Джеффа Безоса о том, что все команды разработчиков Amazon отныне обязаны открыть свои данные и полную функциональность через специальный сервисный интерфейс.

Доступ к каждой отдельной системе/приложению осуществляется через определенные “конечные точки” входа и на основе определенных правил. Это очень похоже на подачу сведений для получения какого-либо документа в госдепартаменте - например, паспорта или визы. Нельзя просто прийти в консульство и забрать нужный документ, однако каждый визитер проходит определенную процедуру подачи и ждет рассмотрения в течение некоторого времени. Берущий необходимые документы в обработку работник консульства является аналогом “конечной точки”, а прописанный регламент подачи и рассмотрения - набором правил.

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

Какое значение это имеет для IAASB и разрабатываемых им стандартов?

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

1. Обеспечение доступа к данным организации (бухгалтерским журналам, реестрам и так далее)

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

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

Именно в этой области потенциально могут реализоваться самые значительные изменения для всей аудиторской сферы. Открытый и свободный доступ к специфическим данным третьих сторон - например, банков, и при этом в обход банковской тайны - означал бы без малого революцию в аудите. Определенные шаги в этом направлении уже предпринимаются в мировых юрисдикциях. В ЕС, например, действует Вторая платежная Директива 2015/2366, которая уже была воспринята многими как сокрушительный удар по банковской тайне, обязав банки открывать третьим сторонам данные по своим клиентам и платежной инфраструктуре.

Одновременно это также способствовало развитию открытого банковского обслуживания (Open Banking), и сегодня уже около 87% мировых стран (по данным The Paypers и выпущенного ими The Open Banking Report 2019) внедрили у себя API для Open Banking в той или иной форме. В каких-то из них введены для этого в действие формальные регулирующие стандарты: помимо Европы и ее Второй платежной Директивы PSD2, можно также назвать Великобританию, где действует Open Banking Standard, Австралию с ее Новой платежной платформой NPP (запущена в действие в конце 2020 года), или Гонконг с Open API Framework. В неформальном виде свои стандарты регулирования имеются у США, Новой Зеландии, Канады и Индии.

3. Обеспечение доступа к связанной с аудитом информации у внешних источников - например, макроэкономическим данным, данным по отрасли и т.д.

Использование данных внешних источников является распространенной практикой в аудите. Благодаря программным интерфейсам взаимодействия это можно быстро и легко сделать в стандартизированном формате (а именно так удобнее всего использовать данные в аудиторских аналитических процедурах).

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

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

Что это все будет значить для самого IAASB?

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

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

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