ISO 20022 和 JSON，兼顾应用程序接口的标准化和灵活性

ISO 20022 的采用率不断提高，对应用程序接口（API）的需求也在不断增加，这为金融业带来了许多创新。然而，ISO 20022 丰富的数据标准可能会与应用程序接口中使用的实际数据格式 JSON 所鼓励的简单和简约相冲突。这个问题有可能阻碍行业实现 ISO 20022 所带来的好处。

在本文中，我们将探讨开发人员和业界在努力协调 JSON 的灵活性和简洁性与 ISO 20022 的数据丰富性时所面临的问题。我们还将了解目前为解决这一重要问题所做的努力。

ISO 20022 是金融机构之间交换数据的全球标准，涵盖支付、外汇、银行卡、贸易融资和证券等领域。该标准内容丰富、结构严谨、灵活多变，与之前的全球标准 ISO 15022（SWIFT 的 MT 格式）和 ISO 8583（用于银行卡支付和账户对账户支付）相比，是一个巨大的飞跃。

整个行业都在齐心协力推动 ISO 20022 的采用，因为当每个人都在使用 ISO 20022 时，它的好处就会最明显。随着越来越多的机构开始采用新格式，这一变革的步伐也在加快--目前全球许多自动清算所 (ACH) 都在使用新格式进行高额和低额支付，SWIFT 的跨境支付系统也在使用新格式。然而，对于本地实时支付系统而言，ISO 20022 的使用非常普遍。

ISO 20022 的适用范围侧重于信息交换，但其主要优势来自于各机构使用数据字典在新标签中打开，以支持其内部数据模型，实质上是采用了一种通用语言。举例来说，这意味着当一方是跨境交易中的债务人或账户转换申请中的账户所有人时，该方的组成属性（姓名、地址、出生日期和地点等）是一致的。

ISO 20022 作为一种标准，与格式无关，但具体的报文模式只以 XSD（XML 模式定义）的形式正式发布，并可从报文目录在新标签页打开，这使得 XML 成为交换 ISO 20022 报文最广泛使用的格式。

随着 ISO 20022 使用量的增加，对新的使用案例和新的数据交换方式的需求也在增加，其中一个突出的例子就是 API，它被金融机构用于多种应用，如允许 Access 账户信息、启动支付、开放银行或内部系统集成。

应用程序接口开发人员，尤其是在设计 REST 应用程序接口1 时，通常会采取一种简约的方法，将效率放在首位，只传输特定请求和响应所需的基本数据。通过应用程序接口交换的信息通常以 JSON（JavaScript Object Notation，JavaScript 对象符号）形式发送，JSON 与 XML 相似，但有一些不兼容之处。

由于 ISO 20022 没有发布 JSON 模式，目前也没有关于如何用这种格式表示 JSON 的通用规则2，这就给希望使用该标准的 API 开发人员带来了挑战。

ISO 20022 支持全球金融报文使用案例，这意味着每份报文都将包含许多元素。虽然执行特定业务信息交换（如信贷转账）所需的关键要素（债务人名称、债权人名称、金额、货币等）保持一致，但这些要素的使用方式却各不相同。例如，在德国的本地清算所中，债务人代理（债务人银行）使用 BIC（商业识别代码）或 Bankleitzahl（BLZ，源自 IBAN）来定义，但在澳大利亚，则使用 BSB 号码（银行州分行）来识别。

为了适应这种情况，ISO 20022 报文的结构允许您提供其中一个或另一个，但这种灵活性导致报文的篇幅比任何特定用例所严格需要的要大。

开发人员在设计应用程序接口时，强调最小化，通常只包含与其用例相关的特定元素，例如，如果开发人员在英国，就没有什么理由包含 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 "表示会员 ID 是 "英国国内分类代码"，Id/Other/Id 包含账户号码。

以下是通过英国开放银行应用程序接口传输相同数据的方式，这些应用程序接口 "在设计时使用了可用的 ISO 20022 报文元素和组件 "3 ，请注意尺寸变小了，但元素名称、代码和结构也发生了变化：

"债权人账户" ：{
"SchemeName" ："UK.OBIE.SortCodeAccountNumber" 、
"身份" ："08080021325698"
}

这个问题并不是英国开放银行特有的，而是整个行业都存在的问题，即基于 ISO 20022 的应用程序接口在实施时没有明确的最佳实践指南，也没有发布官方的 JSON 模式。方法支离破碎的风险很高，会导致实施之间的不兼容性，无法实现标准化所要实现的某些益处。业界已经发现了这一风险，ISO 20022 也采取了一些措施来降低这一风险：

• API SEG（标准评估小组）是为注册、开发和维护 API 资源而成立的。
• ISO/TC 68/WG4（第 68 技术委员会/第 4 工作组）是负责管理/更新 ISO 20022 标准的小组，该小组一直在研究如何修改标准，以正式引入基于 JSON 的 ISO 20022 资源，并引入一个模板，帮助建模人员注册不同格式，以便以标准发布（即JSON 模式）。
• ISO 20022 技术支持小组（TSG）希望更新和修订其 JSON 最佳实践白皮书（在页脚中引用），为 JSON 建模提供进一步指导。

随着金融业的不断发展，持续的标准化和互操作性至关重要。采用基于 JSON 的消息传递是创新的重要推动力，但它也带来了潜在的隐患，业界需要加以警惕。否则，它将面临前功尽弃的风险。

Mastercard积极参与这些倡议，并将继续与业界合作，推动建立一个既能采用新格式，又能保持对未来创新至关重要的标准化和互操作性的框架。