ISO 20022 и JSON: баланс между стандартизацией и гибкостью в API.

Рост внедрения ISO 20022 и рост спроса на API привели к значительным инновациям в финансовой отрасли. Однако богатые стандарты данных ISO 20022 могут противоречить простоте и минимализму, которые поощряет JSON — фактический формат данных, используемый в API. Эта проблема может затруднить отрасль в реализации преимуществ, которые может дать ISO 20022.

В этой статье мы рассматриваем проблемы, с которыми сталкиваются разработчики и индустрия, пытаясь согласовать гибкость и простоту JSON с богатством данных ISO 20022. Мы также рассмотрим текущие усилия по решению этой важной проблемы.

ISO 20022 — это глобальный стандарт для обмена данными между финансовыми учреждениями, охватывающий такие области, как платежи, валютные операции, платежные карты, торговое финансирование и ценные бумаги. Стандарт отличается содержательностью, структурированностью и гибкостью, что делает его значительным шагом вперед по сравнению с предыдущими глобальными стандартами, такими как ISO 15022 (формат машинного перевода SWIFT) и ISO 8583 (используемый для карточных платежей и платежей между счетами).

В отрасли предпринимаются согласованные усилия по внедрению стандарта ISO 20022, поскольку его преимущества наиболее очевидны, когда его используют все. Темпы этих изменений ускорились по мере того, как всё больше инициатив совершили переход — многие автоматизированные клиринговые дома (ACH) по всему миру теперь используют новый формат для платежей с высокой и низкой стоимостью, а также систему трансграничных платежей SWIFT. Его использование пока не повсеместно распространено, некоторые системы поддерживают устаревшие форматы, особенно для массовых платежей, однако для локальных систем платежей в режиме реального времени широко используется стандарт ISO 20022.

Сфера деятельности ISO 20022 сосредоточена на обмене информацией, но ключевое преимущество заключается в том, что учреждения используют Data Dictionaryopens в новой вкладке для поддержки своих внутренних моделей данных, по сути, принимая общий язык. Это означает, например, что атрибуты, составляющие сторону (имя, адрес, дата и место рождения и т.д.), совпадают, когда сторона является должником в трансграничной транзакции или владельцем счета в запросе на смену счета.

Стандарт ISO 20022 не зависит от формата, но конкретные схемы сообщений официально публикуются только в виде XSD (XML Schema Definitions) и доступны в каталоге сообщений. Это привело к тому, что XML стал наиболее широко используемым форматом для обмена сообщениями ISO 20022.

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

Разработчики API, особенно при проектировании REST API1, часто придерживаются минимализма, отдавая приоритет эффективности и передавая только необходимые данные для конкретного запроса и ответа. Информация, обмениваемая через API, обычно передаётся в формате JSON (JavaScript Object Notation), который похож на XML, но имеет некоторые незначительные несовместимости.

Поскольку стандарт ISO 20022 не публикует схемы JSON, и в настоящее время нет общепринятых правил представления данных в этом формате², это может создавать проблемы для разработчиков API, желающих использовать этот стандарт.

ISO 20022 поддерживает глобальные сценарии использования финансовых сообщений, то есть каждое сообщение будет включать множество элементов. Хотя ключевые элементы, необходимые для выполнения конкретного обмена бизнес-сообщениями, например перевод кредита, остаются довольно последовательными (имя должника, имя кредитора, сумма, валюта и т.д.), существует различия в использовании этих элементов. Например, в местных клиринговых центрах агент должника (Bank of the Debtor) в Германии определяется с помощью BIC (Business Identifier Code) или Bankleitzahl (BLZ – производится от IBAN), а в Австралии он идентифицируется по номеру BSB (Государственное отделение банка).

Для учёта этого сообщения ISO 20022 структурированы так, чтобы вы могли предоставить либо один из этих вариантов, но такая гибкость приводит к более крупным сообщениям, чем это было бы строго необходимо для любого конкретного случая использования.

Когда разработчики разрабатывают API с акцентом на минимализм, они часто включают только элементы, специфичные для их случая использования, например, если они находятся в Великобритании, нет особых причин для включения BSB-номера, поскольку все агенты будут идентифицированы кодом сортировки. Аналогично, если агент можно идентифицировать только с помощью сортировочного кода, то зачем включать часть структуры сообщения ISO 20022, если имя элемента можно изменить, следующий пример подчёркивает это:

Вот как выглядят британский сортировочный код и номер счета в XML-базовом экземпляре ISO 20022:

</CdtrAcct>

    <CdtrAgt> 

        <FinInstnId> 

            <ClrSysMmbId> 

                <ClrSysId> 

                    <Cd>GBDSC</Cd> 

                </ClrSysId> 

                <MmbId>080800</MmbId> 

            </ClrSysMmbId> 

        </FinInstnId> 

    </CdtrAgt> 

    <CdtrAcct> 

        <Id> <Именно> 

            <Othr> <Отр> 

                <Id>21325698</Id> 

            </Othr> 

        </Id> 

    </CdtrAcct> 

Код «GBDSC» определяет, что идентификатор участника — это «британский внутренний сортировочный код», а идентификатор/другое/идентификатор содержит номер счета.

Для сравнения, ниже показано, как те же данные передавались через API открытого банкинга Великобритании, которые были «разработаны с использованием элементов и компонентов сообщений ISO 20022, где это было возможно»3, обратите внимание на меньший размер, а также на изменение имён элементов, кодов и структуры:

"Кредиторский счет": {
"SchemeName": "UK.OBIE.SortCodeAccountNumber",
"Идентификационный номер": "08080021325698"
}

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

• API SEG (Группа оценки стандартов) открывается в новой вкладке для регистрации, разработки и поддержки ресурсов API.
• ISO/TC 68/WG4 (Технический комитет 68/Рабочая группа 4), группа, отвечающая за управление и обновление стандарта ISO 20022, изучает, как изменить стандарт для формализации внедрения ресурсов ISO 20022 на базе JSON, а также внедрить шаблон для помощи моделистам, желающим зарегистрировать разные форматы для публикации стандарта (например, JSON Schema).
• Группа технической поддержки ISO 20022 (TSG) планирует обновить и пересмотреть свой документ о передовых методах работы с JSON (ссылка на него приведена в нижнем колонтитуле), чтобы предоставить дополнительные рекомендации по моделированию JSON.

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

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