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

Бизнес-домены:

• Управление платежами и наличностью
• Ценные бумаги
• Торговые услуги, иностранная валюта, картовые платежи

Определения сообщений:

• acmt Управление счетами
• auth Власти
• camt Управление денежными средствами
• pacs Очистка и расчет платежей pain Инициация платежей
• remt Уведомление о платеже

Наборы сообщений:

• camt.052 Отчет банка для клиента о счете
• camt.053 Выписка банка для клиента
• camt.054 Уведомление о дебетировании/кредитовании клиента
• camt.056 Запрос на аннулирование платежа FI для FI
• camt.057 Уведомление о получении
• pacs.002 Отчет о статусе платежа FI для FI
• pacs.004 Возврат платежа
• pacs.008 Клиентский кредитный перевод FI для FI
• pacs.009 Кредитный перевод финансового учреждения
• pain.001 Инициация кредитного перевода клиента
• pain.002 Отчет о статусе платежа клиента
• pain.012 Запрос на активацию платежа кредитора

Стандарт ISO 20022 революционизирует систему обмена сообщениями, вводя иерархическую систему классификации. Эта структура начинается с высокоуровневой классификации, известной как бизнес-домен. В каждом бизнес-домене мы сталкиваемся с набором определений сообщений, в каждом из которых находится разнообразный ряд наборов сообщений. Для иллюстрации рассмотрим следующий пример:

Бизнес-домены:

Платежи и управление денежными средствами Очистка и расчет платежей

Определение сообщения:

Клиентский кредитный перевод FI для FI (pacs.008)

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

Идентификатор сообщения

Идентификаторы участников:

Структура сообщения:

Диаграмма иллюстрирует структуру сообщения ISO 20022, передаваемого по сети SWIFT с использованием услуги FINplus. Эта услуга специально разработана для поддержки различных бизнес-доменов ISO 20022 на платформе SWIFT Interact.

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

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

Элементы XML:

XML-документ содержит данные в элементах и вложенных элементах, где структура соответствует иерархии, определенной схемой XML. В руководствах по использованию CBPR+ мы часто используем концепцию уровней для описания вложенных отношений между элементами. В этом контексте элемент уровня 2 является подэлементом или дочерним элементом другого элемента уровня 1.

Например, в документе pacs.008 «Кредитный перевод клиента» дата межбанковского расчета классифицируется как элемент уровня 2. Он выступает в роли подэлемента, находясь внутри элемента «Информация о транзакции кредитного перевода», который занимает позицию на уровне 1. Эта иерархическая схема через уровни помогает понять вложенную структуру и взаимосвязи между различными элементами XML-документа, что облегчает навигацию и интерпретацию данных, заключенных в документе.

Правила именования:

Имена элементов в XML подчиняются определенным правилам:

Имя может состоять из букв, цифр и других символов, но не должно начинаться с цифры или знака препинания. Имя не должно начинаться с XML, xml или Xml. Пробелы в имени не допускаются.

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

Правила именования элементов сообщений MX:

В базе данных существуют общие правила именования, которые применяются к большинству элементов. Схема именования следует стилю верхнего CamelCase, соблюдая следующие правила:

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

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

Множественность элементов сообщений MX (число вхождений):

Элемент сообщения MX определяет свою кардинальность, указывая количество вхождений в наборе с помощью минимальных (min) и максимальных (max) значений. Эти значения дают представление о количестве экземпляров, которые могут существовать для данного элемента в контексте сообщения MX. Минимальное значение указывает на наименьшее количество допустимых вхождений, а максимальное значение обозначает наибольшее допустимое количество вхождений для данного элемента в пределах набора. Используя min и max, структура сообщения MX устанавливает границы и ограничения для наличия определенного элемента, что способствует четкости и точности представления данных.

Пустые элементы XML:

Пустой элемент XML — это элемент в XML-документе, который не содержит данных и, следовательно, считается пустым. Хотя это может показаться нелогичным с точки зрения бизнеса, это признанная особенность XML. Такая ситуация часто возникает, когда вложенный элемент под родительским элементом допускает различные варианты, но при этом нет требования обязательного использования элемента с минимальной кратностью 1 или правила, определяющего наличие хотя бы одного из вложенных элементов. В сущности, пустой элемент XML представляет отсутствие данных в конкретном контексте, как это определено структурой и правилами схемы XML.

Пожалуйста, пишите на английском языке.

Правила:

Формальные правила:

Эти правила подлежат проверке в сети, и их идентификация включает термин "Rule", добавленный к описанию правила. Формальные правила являются неотъемлемой частью процесса валидации и должны соответствовать определенным критериям, чтобы считаться действительными и обязательными.

Текстовые правила: В отличие от формальных правил, текстовые правила не подлежат проверке в сети. Их идентификация включает термин "TextualRule", добавленный к описанию правила. Эти правила могут предоставлять дополнительную информацию, контекст или рекомендации, но не подлежат проверке в сети.

Рекомендательные правила: Эти правила предлагают лучшие практики, но не являются обязательными и не проверяются в сети. Они идентифицируются путем добавления термина "Guideline" к описанию правила. Эти правила служат рекомендациями для улучшения практик, но не имеют обязательного характера, как формальные правила.

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

ISO 20022 Внешние списки кодов:

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

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

Читать сейчас :https://finhotspot.com/introduction-to-iso-20022/