分布式账本、智能合约、业务标准和ISO20022（译）

〇内容概述
分布式账本技术（Distributed Ledger Technology，以下简称DLT）和智能合约（Smart Contract，以下简称SC）有希望促成金融业的自动化转型，已经引起了金融机构和技术厂商的极大兴趣。目前针对金融行业，在技术上对于安全性、可恢复性和可扩展性等要求的改进已经取得了较大的进展。但是，抛开技术来讲，要解决多方参与者环境下的自动化问题，还需要业务参与者对共享数据、业务流程、职责分工进行定义并形成共识，这就处于业务标准的范畴。本文的重点是讨论这些业务标准如何应用于分布式账本技术。

本文从两个角度对这个主题进行思考：
1. DLT/SC应用的前提条件是什么，当前是否满足这些条件？DLT/SC标准的特征是什么，我们可以从之前的工业标准化过程中学到什么经验？
2. 现有的标准在哪些方面可以复用，复用的好处是什么？

我们的结论是DLT/SC的业务标准是十分重要的，但是当前由于在实现思想和技术路径方面呈现了百花齐放的格局，再加上技术本身仍未成熟，所以直接进行大规模标准化的难度很高。然而，我们还是可以根据当前趋势对标准的发展方向提出一些建议，包括用于定义DLT实施和使用场景（例如金融工具、关系和生命周期处理）的方法论。我们认为这些标准都必须是开放的，而不能由单个商业机构来控制，以此来确保业界有足够的信任来参与到该过程中。
本文的第二部分对使用现有标准（包括ISO 20022）的优点进行探索，基于SWIFT系统对固息债券进行了DLT/SC的概念验证（Proof-of-Concept，PoC）和系统开发。我们的结论是，现有的标准无法覆盖DLT/SC的所有特点，但它们也有明显的价值：可以避免在业务定义、不同DLT之间和与现有金融行业基础设施之间互操作性方面的重复工作。我们的进一步结论是：随着DLT/SC标准不断发展，ISO 20022可以为这项技术在业务和实施路线上提供很好的基础。
作为在金融行业业务标准方面的积极参与者，SWIFT组织领域内具有广泛实践经验的参与者、监管者和行业标准制定者，希望在DLT开放业务标准的形成和实际运作方面承担领导者的角色。

一绪论
分布式账本技术（DLT）和智能合约（SC）有希望促成金融业的自动化转型，它们已引起了金融机构和技术厂商的极大兴趣。更多关于技术以及应用可行性的内容可以在SWIFT意见书（position paper）中找到。该文的一个结论是：缺少标准化是阻碍这项技术在整个行业内大规模应用的关键因素。这个观点也在SWIFT的另一篇学术论文（The Impact and Potential ofBlockchain on the Securities Transaction Lifecycle）中得到进一步论证。
当前，整个行业将更多的关注点放在DLT/SC的技术标准层面，例如创建一个更健壮且互操作性更好的技术平台。然而，如果需要将DLT/SC技术用于解决复杂问题，行业必须同时对部署在DLT平台上的数据含义及格式、业务流程和法律含义形成共识，也就是业务的标准化。本文将主要的关注点放在DLT/SC应用的业务标准化方面。
金融行业的报文和数据标准通过降低规格文件的模糊性、鼓励高效复用现有知识、技能和技术，来更好地创建具备健壮性且互操作性强的业务流程。这些标准通过两种手段来实现如下目标：第一是为持续准确地获取和发布正式的业务规格提供方法论；第二是为业务内容和业务规格的发展提供治理流程。
将一个复杂的业务流程完全装入单个DLT环境的可能性不大（当前已经有许多分布式账本平台，同时更多这样的平台正不断涌现），这也是探索标准化的第二个重要理由：业务流程要求DLT与现有的自动化机制以及DLT间进行互操作，包括报文和接口交互（API）。为了使技术标准间的协同更加安全和无缝地进行，需要对DLT平台以及已广泛开展业务的平台间进行持续和互相引用定义。因此，本文的进一步目标是探索在DLT环境下的新标准，以及现有报文及数据标准在可复用性和互操作性方面的本质。
电子化的报文已经在金融行业自动化业务处理中使用了数十年。当这项技术最初出现时，通常是在某一特定的市场和社区中实施，这也导致了众多独立的本地业务标准的出现。近年来，如ISO 20022（报文）和ISO 17442（法律主体身份标识）的全球标准已尝试最终取代独立的本地标准，以期减少这些重复且互相竞争标准的数量。但是，取代一个已经在特定市场运行良好的标准并不是一件易事，所以这种众多标准共存的低效状态还将持续存在一段时间。因此，在DLT/SC发展过程中需要吸取这方面的经验教训，尽量在技术发展初期就避免可能引起低效的碎片化标准出现。同时，标准选择的时机也非常重要。如果在充分了解技术的可能性和局限性之前过早施加标准，也可能引起标准过快失效的风险，这也是当前我们在DLT/SC领域所处的现状。所以，本文希望可以为DLT/SC标准化的方向提供一些大致但不是先入为主的观点，同时也对如何学习和复用现有标准以及如何开展具体的应用提供一些思路。

二关于业务标准

正式规格和业务标准是对具备一定复杂度的业务进行自动化的基本前提，特别是业务涉及多方参与者或/且涉及金额较大时。当前的业务标准通常分为两类：一类是参考数据（referencedata），另一类是报文发送（messaging）。
参考数据标准对关键的数据要素（如货币、法人、证券等）定义全局唯一的代码。这些标准通常同时定义数据格式（如货币代码的长度和格式、用于描述货币的属性等）和数据本身（如公认的货币代码：EUR、USD等等）。参考数据标准可以确保重要业务数据的一致性。
报文发送标准正式描述了行业参与者在业务流程中进行交换的业务消息内容，例如支付和证券结算。报文发送标准使用参考数据标准对数据要素进行规定，这样也使模糊性降到最低。目前已经存在许多报文发送标准，但是在架构方面最先进的、业务领域覆盖最广泛的标准是ISO 20022。本文以ISO 20022标准作为案例，但本文中的发现对于其它报文发送标准也同样适用。
对于ISO 20022更加完整的描述详见附录A，这里将该标准的一些重要特点进行说明：

这是一个制定报文发送标准的方法论，同时也是基于这个方法论创造的消息内容。
通用的业务语义可提高标准的一致性并降低模糊性，它独立于报文发送和消息引用的定义。
该标准以强大的治理流程为特点，将标准化的控制权交给其使用者。
这些特点确保不同业务领域参与者的报文发送标准在数据格式和语义上是互相兼容的。这是十分重要的，因为这样可以使业务标准的创建更加分散，同时不影响标准的完整性。
ISO 20022的用户社区可根据不同的市场情况来创建各自市场的规范和指引，同时与其他社区的规范保持高度兼容。

三标准的治理

所有业务标准都需要一个治理流程来维持其一致性和完整性，同时允许标准随着业务发展的需要而不断改进。
ISO 20022有非常开放和高效的治理模型（详见附录A）。这个模型符合成功标准的治理模式，也就是联合用户社区的力量参与标准制定，并采取严格的程序和合理的发布频率来确保业务领域的变化可以被用户接受。在DLT/SC技术逐渐成熟的过程中，任何新的业务标准的推出，都需结合现有标准（如ISO 20022）的经验和最佳实践，这一点是十分重要的。

四法律的考量

在报文发送领域，某一参与者发送或者接收标准消息时承担的法律责任通常不是在标准中规定的，而是在消息使用的上下文规则中定义的。例如，欧元的零售支付是由欧洲支付委员会发布的SEPA中进行规定。
然而，这些规则的准确含义取决于报文发送标准定义的清晰程度，在DLT/SC的标准方面也是如此。

五走向DLT/SC的业务标准

DLT/SC究竟有什么特别之处，它们是如何改变行业的规则呢？分布式账本技术提供了一个统一、一致和共享的业务状态视角。从本质上来说，该技术可以消除业务参与者之间消息传递的需求，以及消除参与者在自身系统中维护数据独立拷贝的需求。因此，DLT可以减少点对点的消息传递以及其他数据同步和核对操作。智能合约通过将业务逻辑从当前需要参与者之间进行复杂交互的模式，转变为只需要参与者各自独立执行的模式，进一步提高了处理效率。
从报文发送模式到DLT/SC模式的转变，要求我们重新思考业务标准。报文发送使业务参与者之间可以对某一笔特定环境下的特定交易共享特定的信息。一个标准的报文通常包含两个不同的功能（我们可能无法较好地区分）：第一个功能是通知一个事件或者发起一个行为（例如发起一笔支付）；第二个功能是按照接收方的要求传递相应的信息，以完成该行为（例如发送1000美元给Jane Smith的12345账户）。在DLT/SC环境下，我们可以将这两个功能进行分离，并且可在某些情况下排除其中一个甚至是两个功能。例如，完成一笔支付所需的部分或者所有信息可能已经在账本中存在，所以不需要再重新发送一次，而只需要发送支付命令即可。同理，发起支付的业务事件可通过在账本中的智能合约进行自动触发，而不需要由外部参与者发起。DLT这些具有颠覆性的潜力，可避免当前业务流程中大量信息交互的需要（最终也可能会使业务流程中的部分参与者变得不再是必须的）。
因此，如何正式形成DLT/SC的使用场景，DLT/SC的标准将会是什么样子？可以确定的是，标准需定义存在账本中的数据范围，以及数据的表现形态和含义。对于智能合约应用，需要同时定义合约逻辑的行为。在做进一步探讨前，我们必须首先对DLT/SC的实现做一些基本的假设。这个领域的发展十分迅速，有许多互相竞争的项目尝试改善DLT技术的方方面面：参与许可、智能合约语言、可扩展性和性能等等。其中一些特点会随着技术的发展而发展，其他的特点可能是更加基础性的。例如，分布式账本的一个共同本质是所有节点中保存了相同的数据。对于一些使用场景，例如在土地注册中，对于数据的共享和开放可能是大家所期望的，但对于金融行业的许多应用来说，情况却恰恰相反。因此，DLT技术需要进一步发展，以确保数据不是在所有地方都是相同的，或者只有特定的参与方才能获得特定的数据。此外，只有特定的参与者才能触发相应的行为（例如：只有账户的所有者才可以使用该账户发起一笔支付）。在报文发送领域，参与者可以获得的信息是通过所传递的报文规定的，且参与者的角色定义了参与者是否可以发送报文。在DLT/SC领域，我们同样需要寻找类似“谁可以做什么”的定义。
此外，由于业务内容和行为很可能由智能合约及其基础的数据模型来定义，且这种定义是用面向对象的语言来编程的，所以合约需要支持继承、多态等特性，数据也需要进行封装和行为定义。最后，智能合约有另一个可能的公共特性：为确保账本的一致性，不同节点中运行的合约必定产生相同的结果。这引入了一个重要的限制：每个节点的计算结果必须是相同的，所有的节点可同时获得计算中需要用到的所有数据，且这些数据必须是相同的。这也预示着这些数据应在账本中可见，不管是由用户程序提供的还是由外部数据源（称为Oracle）提供的。因此，除了由参与者自身共享的业务数据之外，还需要对智能合约使用的数据进行仔细考量。
基于上述观察，我们可以对DLT/SC应用的正式形成和标准化得出一些结论：

正式规格描述实现业务处理的数据和行为。这里的数据不仅仅局限于对外展示的数据，规格也需要在业务处理过程中所涉及的内部数据进行规定。
需要对交易中涉及的参与者角色进行定义。同时根据这些角色定义，需要对谁可以看到什么数据以及谁可以做什么进行规定。在运行过程中，为了对这些限制进行观察，DLT平台需要支持身份的严格认证以及访问控制。
正式模型不会与任何具体的实现方式进行绑定（与ISO20022逻辑消息在格式方面的独立性相似），所以其表现形式必须是抽象的，但也必须是具体的。在理想的情况下，这些具体的规格可以转换成为具体的实现，但在初期实现这个目标却不太现实。
尽管逻辑定义相对于具体实现是独立的，但逻辑定义也需要对目标的实现技术进行一些初步的假设，包括支持基本的面向对象原则。
与报文发送标准一样，对于标准的方法论和元模型的区分十分重要。这个过程需要对捕获的信息和规格的标准化本身进行正式的说明。

标准化的过程需要经历很多工作，但与ISO 20022一样，我们可以大致想象DLT/SC主要由一个三层模型所组成：第一层是业务/概念层，对于不局限于DLT的关键性概念提供可复用的定义；第二层是逻辑层，对于DLT实现的使用场景进行抽象但精准的定义（例如金融工具，它的相互关系及生命周期）；第三层是物理层，是对已有DLT/SC技术使用场景的具体实现，这种实现可以是完整的，也可以是一个框架性的（未来可根据选定的技术进一步实现）。

DLT/SC技术还有其他的一些重要特点可能会影响到标准的制定。其中一个特点是当数据在整个网络中完成复制并达到不可篡改的状态后，带宽和存储成为需要重点考虑的问题。近年来，在带宽和存储方面的进步使消息本身的大小不再是一个突出的问题，但这仅局限于除了超低延迟和高吞吐量以外的应用。当采用DLT/SC后，需要对这些问题进行重新斟酌，并设计更为高效的系统，比如在某个特定的使用场景中，只存放所需的最小数据集，并使用参考数据、参考代码、在账本中的地址等方式获取公共数据。

六标准和合约

到目前为止，我们讨论了智能合约的处理特点，但是智能合约不只是在账本中实现业务逻辑。
为实现一个协议的全部或者部分过程的自动化执行，业界对于智能合约是否可以替换常规的法律合约，或是成为它们的电子镜像，还是对它们进行补充并未能达成一致。但无论采取何种方式，这些合约的行为必须得到适当的理解，并且是可预测的，这也是标准化可以发挥作用的地方。这个过程可能有很多种形式：标准的设计模式来为合约实现提供一致性保证；经测试和业内认可的标准化合约库可以提供具体的实现；合约特征库可用于集成客户的合约；领域特定语言（Domain Specific Language，DSL）可以简化合约的获取并提供向自然（法律）语言转换的形式；标签机制可以将法律文本参数化并形成智能合约。根据前面章节中的方法，对智能合约的标准化和ISO 20022中描述的标准化方法论、语义、业务逻辑和数据结构有明显相通之处。扩展业务报告语言（eXtended Business Reporting Language，XBRL）证明了通过标签模型，自然语言文本也可以转换成为机器能够处理的语言。

七与DLT/SC的互操作性和可复用性

7.1引言
ISO 20022是当前商业领域中最广泛采用的一种标准，而且它的架构上将业务概念与报文发送相分离，因此可考虑将ISO 20022作为DLT/SC需要实现业务内容的来源，以及一种实现DLT/SC与其他自动化机制相互操作的手段。
本章将首先描述ISO 20022的哪一部分可以被复用、如何被复用以及在DLT/SC中使用时会有哪些限制和不足。其次，为了更全面地支持DLT/SC，本章将探讨一个新的标准需要如何对ISO 20022进行改变或扩展。
本文所用的素材来源于SWIFT所尝试的对一个简单固定收益债券全生命周期进行自动化处理的概念性验证。选择该用例的一部分原因是当今债券处理的机制相对复杂，包括了众多参与者和活动组件，因此说DLT/SC在机制简化上可能存在机会。另一部分原因是该用例场景可以包括与其他技术，如票面利息报文发送的互操作。这个概念验证是基于ERIS平台，使用的是Solidity语言。

7.2ISO 20022业务模型
如在附录A中所描述的，ISO 20022定义了一种分层架构体系，最上层是原则上与任何自动化机制无关的、只描述关键业务概念的抽象模型。这可以用来查找在DLT/SC场景中可共享和复用的内容。

下图描绘了现有的ISO 20022以及假设存在的DLT/SC标准中可以共享的业务定义。

图1 DLT/SC的逻辑模型

图2 债券处理过程中的各交互方

7.2.1 复用ISO 20022的业务模型
[h2]图3（A）（使用UML语言绘制）从ISO 20022标准中摘录了证券领域的业务模型。从该图中可以看出，证券是一种资产，债务工具（债券）是一种证券。该图进一步描绘了所有证券产品的共有属性以及债务工具的特有属性，包括票面利息支付所需的计算信息等。一些属性（业务元素）可以用简单的类型定义，例如文本类型。而其他一些属性需要由其他结构体（业务组件）定义，例如，债券发行人是由包含了名称、地址和其他标识符（如BIC代码）的组件所定义的。每个业务元素和业务组件在业务模型中用英文描述。
[/h2]通过仔细观察，我们不幸地发现这个模型被“污染”了（原文：polluted，译者注）。这不是由于报文发送机制本身，而是因为这个模型是基于当前债券发行和处理方式的假设前提，如图2所示。在DLT/SC环境中，这个模型也许不一定适用。
将ISO 20022业务内容在DLT/SC上下文复用的第一步即过滤基于当前业务架构的“噪音”假设。借用之前的特点，我们可将业务概念中的主要属性与次要属性相分离。例如，债券是一种允许发行人按约定条款从投资者（持有人）筹集资本的工具。这种典型条款有利息支付和本金支付条款。发行人、持有人和支付条款等是债券必备的属性。没有上述这些属性的工具则不是债券。尽管如此，当我们观察ISO 20022业务模型时，还可以找到很多次要属性。
我们从识别和移除这些属性开始，只将DLT/SC情景中必要的属性加进来。例如，业务模型定义了ISIN码（国际证券识别码），这是债券所必须的属性。原则上来说，分布式账本上的债务工具已有一个唯一的标识符，即它在账本上的地址。但只要其他业务或者技术场景需要引用，该债务工具就需要一个通用的标识符，所以ISIN这个属性需保留。我们也可在DLT/SC的用例场景下增加其他新的属性，但这不能简单机械地执行，这需要具体的业务知识和业务分析能力。
表1展示了一个从固定收益债券业务模型中抽象出的数据样例。这些组件是债券的定义和处理过程中所必须的以及基础组件。在该模型中没有定义哪些业务元素可由哪些参与者访问。ISO 20022虽然包括了业务角色这个概念，在该债券的例子中也定义了一些业务角色，但在业务模型中哪些角色可以读/写哪些数据并不明确。因此，当ISO 20022标准应用到DLT场景中，这些元素是缺失的。作为概念验证，下表中我们增加了橙色的一列来填补这个空白。

表1 债券描述业务模型

通过将证券和债券工具的业务属性合并，表1将业务模型中的继承关系“抹平”。业务模型中的继承关系只是用来表示业务概念之间的关系，而不是用来指导代码实现的。在我们的开发实现和逻辑展现中，可以引入继承关系，但这只是出于技术的考虑（代码内聚、代码复用等）。结合表1中的信息和上述的推论，基于ERIS Solidity实现的债券数据模型如图3（B）所示。
Solidity代码包括了主要组件的类定义、每个属性的get/set方法，以及对调用者是否满足执行请求条件的验证方法。表1中的内容只是一个开端，为了实现一个正式的分布式账本，我们需要指导开发人员在最佳实践和设计模式方面做进一步努力。

7.2.2 参考数据
[h2]许多ISO 20022数据元素是根据全球参考数据标准定义的，包括ISO货币代码、参与方识别号、ISO国家代码等。通过复用ISO 20022这些通用概念的定义（例如参与方和国家），DLT/SC的开发可自动复用这些标准。这个做法具有如下优点：高效的处理、通用性、与报文发送功能和接口的互操作性，以及与现有工业和私有数据模型的一致性。
[/h2]

7.2.3 业务行为
在ISO 20022中，业务行为从基于简单UML活动图的业务流程中获得，并通过参与方的报文传送及文字说明来表述。图3（C）给出了一个利息支付的例子。
当业务分析师从这些材料中推断DLT/SC所需要的信息时，是不能直接使用ISO 20022内容的。因为DLT/SC的自动化模式不同于点对点报文发送模式。同时，需要进一步说明的是，我们需要具体的业务知识，做更多的工作来定义如何进行需求分析，是通过采用领域特点语言，还是其他抽象的方式。对于本次概念验证，固定收益债券的这几个生命周期行为是直接通过Solidity语言实现的，包括票面支付。该实现参考了现有业务模型的报文流程，但并不是照搬过来直接使用。

7.2.4 结论
[h2]为了实现与ISO 20022报文逻辑模型相当的DLT/SC的功能，我们需要更加稳定的底层，需要在设计元数据模型及方法体系方面完成更多的工作。尽管如此，我们已经找到了ISO 20022业务模型中可以复用的内容。由于这些内容是具体的、一致的，而且他们的定义是金融行业已批准和认可的，通过对这些内容适当的过滤、修改和补充，可以为DLT/SC的实现带来真正的价值。
[/h2]

图3(A) 从ISO 20022标准中摘录的证券的业务模型。从图中可以看出，证券是一种资产，债务工具（债券）是一种证券。该图进一步描绘了所有证券产品的共有属性以及债务工具的特有属性，包括票面利息支付所需的计算信息等。

图3(B) 用Solidity语言实现的一个固定收益债券智能合约的类图。该实现采用了ISO20022业务模型中的业务定义。

图3(C) ISO 20022利息支付中的业务流程

7.3报文的互操作性
[h1]重新使用ISO 20022定义来实现DLT/SC的关键优势会越发明显。
[/h1]在固定收益债券的概念验证（PoC）中，债券到期时，每个债券的持有人都会收到一笔付款。自动支付在金融系统内得到了很好的发展和应用，并且越来越依赖于ISO 20022报文。由于来源于相同的ISO 20022业务模型，对一笔付款所需的关键数据，如货币、金额、债券持有人的详细信息等的PoC验证，能与ISO 20022中的pacs.008客户信用转账报文结构完美兼容。
虽然Solidity代码在每个验证节点都会执行，但是每笔交易付款只能被严格控制为只能生成1次。因此，在PoC中，由客户端应用发送的付款报文只能被作为账户服务方的机构来处理。然而，账本中的智能合约可以将计算任务和数据打包成与ISO 20022相兼容的结构中，并发送至客户端。相同的原理可以应用到其他报文标准，包括一直控制全球银行间通信的SWIFT报文标准和与ISO 20022齐名的ISO 15022（证券报文）。

图4 ISO 20022端到端定义

八结论
正如本文绪论中所述，对DLT/SC案例进行大规模标准化目前还为时尚早。但是，尽管没有一个官方的验证方法，从已有的消息传输标准中重新定义数据标准和业务内容已经展现出了明确的价值和意义，尤其是拥有最广泛行业覆盖率和强适应性技术架构的ISO 20022标准。
好处主要体现在如下两个方面：
1. 在业务定义方面避免重复工作；
2. 利于分布式账本和现有金融行业的基础设施，包括电子报文之间的互通。
这些“速赢”的方法可以加速DLT/SC在商业解决方案方面的实施和接纳。
随着DLT/SC技术的成熟和稳定，以及业内实际使用经验的增加，动员一些标准化社区从行业层面制定新的标准来克服目前产生的分裂和混乱的局面就显得尤为重要。ISO 20022已经为这些标准的制定奠定了一定的基础。SWIFT（包括ISO 20022）作为过去40多年金融业务标准的重要贡献者，我们希望能在DLT开放式业务标准制定上继续充当先锋队，充分利用现有经验，发挥与产业层面、监管机构和标准制定机构间的密切联系。

附录AISO 20022
A.1关于ISO 20022[h1]ISO 20022有两个关键方面：一方面是方法论，即遵循一个方法，创造金融信息交换的标准；另一方面是消息体，在业务领域，需要用到一些信息。其中一些是已定义的信息，另一些信息是需要通过方法论来解释底层的概念和进程。
[/h1]

A.1.1 方法论
[h2]ISO 20022的方法论部分是通过元模型描述的，即可精确定义哪种信息能够获取。该方法论可分为三层：
[/h2]

业务/概念层：定义金融概念，如“信用转移”、业务流程等；
逻辑层：定义如信用转移的信息，用以服务于业务流程；
物理层：定义物理语法，如XML。

业务/概念层包含正式定义的概念以及这些概念之间的关系（如现金账户是一种账户；账户有提供者和持有者；债券是一种证券；债券有发行者和持有者等）。这些内容并没有特定的信息。
逻辑层定义了逻辑信息定义，在一个业务流程中，一个角色能够使用逻辑信息定义去指导或通知另一个角色。逻辑信息指定的数据元素涉及业务/概念层的概念，能确保从一个逻辑信息定义到另一个的过程中逻辑信息语义定义明确、稳定、一致。逻辑层内容是指定报文的，但没有特定格式或信息传递技术。
物理层是逻辑信息的技术实现，能够从逻辑定义自动化地生成逻辑信息。实现几个物理层是有可能的，可允许ISO 20022逻辑定义从实施技术中解耦。

A.1.2 消息体
[h2]ISO 20022方法论允许关键概念和定义信息的正式化，以确保技术格式的规范定义明确且一致。这对于实施规范是一个很好的优势，因为它能确保分析更简单，并能实现规范的自动使用。
[/h2]由标准生成的规范能标准化处理，可作为标准的一部分正式发布。对于任何不止一次实施的流程，这是一个很好的优势，因为这给业务流程的自动化方式带来了全球化的一致性，减少了总体成本，并允许最佳实践被再次用于其他实施过程中。
已发布的ISO 20022包括业务/概念定义和逻辑信息定义。这些定义来自方法论和严格的维护过程。比如，ISO 20022中金融机构间的顾客信用转移（pacs.008）规范定义了在发出顾客信用转移（支付）指令时金融机构间传递的数据。在pacs.008规范中，数据元素适用于业务/概念层中的语义消息，比如贷款者、指令总量。ISO 20022也指定角色，如指令代理、最终债权人等，以及发送和接收业务内容信息的角色。

A.1.3 管理
[h2]ISO 20022管理有两方面，与作为方法论和内容存储库的两个角色相关联。标准本身作为有效的方法，通过ISO维护过程来管理。标准的使用者可以要求修订标准，ISO技术委员会（Technical Committee，以下简称TC）68下设立一个工作组，主要负责发表标准的新版本（现在的版本是ISO 20022：2013）。草案需上交至TC 68以获得批准。一旦获得批准，标准就会被移交至注册机构（Registration Authority，以下简称RA）（目前根据ISO的合同，RA由SWIFT经营）实施。RA负责技术标准的实施，包括维护标准的内容。ISO 20022管理的第二个方面是确保标准内容与业务的相关性和一致性。
[/h2]任何使用者都能提出创建新的ISO 20022信息（包括业务模型的新内容需要定义概念、术语和关系）。每项提案需要有正式的业务理由—一个详细阐述提案背景和动机的标准文档。RA会检查文档的完整性，然后提交至几个特定的标准评估小组（StandardsEvaluation Groups，以下简称SEGs）之一，该小组负责评判议案在业务条款里是否合适。如果合适，评估信息会提交至RA进行一致性和质量检查，然后交给合适的SEG进行审阅。SEG可以要求修订，提交者需在再次提交信息至RA进行发布前执行。
申请维护的流程类似。任何使用者，或者预期使用者，都能为现存的信息提交修改请求。相关的SEGs在一个年度内评估修订提案。如果请求被批准，通常认定最初的提交人适用于这个信息，RA将发布该信息的最新版本。

A.1.4 SWIFT、标准和ISO 20022
[h2]SWIFT已经引领金融业标准化40余年。SWIFT标准发展了原MT标准，同时保留了国际跨境支付的主导标准，并且覆盖了很多其他业务领域，包括证券结算和对账、企业合作、贸易金融和财政领域。
[/h2]SWIFT也是ISO 20022的重要贡献者。SWIFT成立了标准定义的工作组，是一个独立的、最重要的贡献者，主要体现在其与ISO的合同之下，作为ISO 20022注册机构负责信息定义、内容发布。SWIFT作为RA也在经营着一些其他关键行业标准，包括ISO 15022（证券信息传递）、ISO 9362（商业识别码，Bussiness Identifier Code，BIC）,ISO 10383（市场识别码，Market Identifier Code，MIC），ISO 13616（国际银行账户识别，International BankAccount Identifier，IBAN）。