T/CBA 225-2025 银行企业级数据字典编制指南

　　ICS 03.060 CCS A11

　　团 体 标 准

　　T/CBA 225—2025

　　银行企业级数据字典编制指南

　　Guidelines for the compilation of bank enterprise data dictionary

　　2025-12-18 发布 2025-12-18 实施

　　

　　中 国 银 行 业 协 会

　　

　　发

　　

　　布

　　T/CBA 225—2025

　　目 次

　　前言 II

　　引言 III

　　1 范围 1

　　2 规范性引用文件 1

　　3 术语和定义 1

　　4 编制原则 2

　　5 编制方法 3

　　6 银行企业级数据字典框架结构 4

　　7 银行企业级数据字典属性 5

　　7.1 数据项属性说明 5

　　7.2 域属性说明 9

　　7.3 词根属性说明 12

　　7.4 扩展属性说明 13

　　附录 A(资料性) 银行企业级数据字典分类体系示例 14

　　附录 B(规范性) 约束/条件说明 15

　　附录 C(资料性) 数据项及相关对象定义流程示例 16

　　附录 D(资料性) 银行企业级数据字典模板示例 17

　　附录 E(资料性) 银行企业级数据字典应用场景示例 19

　　附录 F(资料性) “贷款五级分类代码 ”数据项及相关对象示例 20

　　附录 G(规范性) 银行企业级数据字典的数据类型 22

　　附录 H(规范性) 银行企业级数据字典的数据格式 24

　　附录 I(资料性) 扩展属性示例 25

　　参考文献 26

　　I

　　T/CBA 225—2025

　　前 言

　　中国银行业协会(China Banking Association，CBA)于2000年5月在民政部注册成立，是全国性银行业自律组织，国家金融监督管理总局为业务主管单位。凡经业务主管单位批准设立的、具有独立法人资格的银行业金融机构(含在华外资银行业金融机构)和经相关监管机构批准、具有独立法人资格、在民政部门登记注册的各省(自治区、直辖市、计划单列市)银行业协会以及相关监管机构批准设立，具有独立法人资格的依法与银行业金融机构开展相关业务合作的其他类型金融机构，以及银行业专业服务机构均可申请加入中国银行业协会成为会员单位。

　　中国银行业协会日常办事机构为秘书处。秘书处设秘书长1名，副秘书长若干名。根据工作需要，中国银行业协会设立多个专业委员会，其中银行业产品和服务标准化专业委员会旨在开展银行业产品和服务标准化工作，包括制定和发布银行业的产品和服务标准，积极参与制定国家标准、行业规划，参与制定有关政策和法律法规，不断提高银行业产品和服务质量。

　　本文件按照T/CBA 1—2021《中国银行业协会团体标准化文件的结构和起草规则》的规定起草。

　　请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。

　　本文件由中国邮政储蓄银行股份有限公司提出。

　　本文件由中国银行业协会银行业产品和服务标准化专业委员会归口。

　　本文件起草单位：中国银行业协会、中国邮政储蓄银行股份有限公司、中国建设银行股份有限公司、中国农业银行股份有限公司、交通银行股份有限公司、中信银行股份有限公司、中国光大银行股份有限公司、广发银行股份有限公司、中国工商银行股份有限公司、中国银行股份有限公司、兴业银行股份有限公司、中国民生银行股份有限公司、厦门国际银行股份有限公司、北京银行股份有限公司。

　　本文件主要起草人员：赵成刚、李海丽、蔡苗、张放、温国梁、许艳、贾宁、裴立伟、向俊、沈澍、刘超、王德宇、刘巍、艾霁坤、李琛琛、吴晓渊、张芯芮、叶建娥、王雅、郭惠晴、潘学芳、张琪、宋蕊、张文博、陈斌、赵崟杰、文州、胡思远、杨登科、窦志勇、黄晓菲、杨润泓、张萃、李宇健、冯宇星、郭子润、郑加兴、方婧、张宁。

　　本文件为中国银行业协会制定，其著作权为中国银行业协会所有。

　　地 址: 北京市西城区月坛南街1号院5号楼11-12层

　　电 话: 010-66291132

　　邮 编: 100045

　　邮 箱: cba.china@china-cba.net

　　传 真: 010-66553356

　　II

　　T/CBA 225—2025

　　引 言

　　数据标准化是银行业持续发展金融科技、深化推进数字化转型的基础性工作。企业级数据字典是数据标准化工作中的重要组成部分，它通过统一数据标准、明确数据定义和业务含义，构建起全行级的数据共识，有效破除部门数据壁垒。

　　据调研，在银行业中，企业级数据标准的建设通常遵循两种技术路线。一是直接以数据字典和数据项为核心，推进全行统一的业务语义与数据定义管理，并将其作为信息系统开发的基础。二是遵循ISO/IEC 11179系列标准，建立完整的元数据注册库，以实现对数据元的全面管理;在此基础上，依据ISO 20022等标准构建报文， 以交易数据为基础形成数据存储(数据库)，进而通过报文的组合来支持各项业务任务。

　　具体采用哪种技术路线，需综合考量银行当前的信息系统状况、可投入资源、预期实现周期等因素。值得注意的是，这两种路线并非相互冲突，面对特定的数字化任务，它们在多数情况下能够取得相近的实施效果。其中，“企业级数据字典 ”因其建设门槛相对较低、实现难度较小，且在全行范围内统一了数据定义，能为信息系统设计与数据分析等场景提供一致的基础，故而常被视为最佳实践。此举不仅能有效提升数据质量与一致性，保障数据分析、风险管控及监管合规的准确性，更能支持业务的敏捷创新。企业级数据字典为数据驱动决策、智能化应用和精细化运营提供了可信赖的数据基石。

　　为指导银行企业级数据字典的编制工作，充分发挥其在提升数据一致性与质量方面的核心作用，进而全面提升数据治理能力，特制定本指南。

　　本文件结合银行业机构当前开展数据标准化工作的实际情况，归纳出适用于银行业的企业级数据字典编制方案，包括企业级数据字典的编制原则、编制方法、框架结构、属性说明等内容。本文件的实施将有助于银行业相关机构企业级数据字典管理体系的建设和开展数据标准化工作。

　　III

　　T/CBA 225—2025

　　IV

　　T/CBA 225—2025

　　银行企业级数据字典编制指南

　　1 范围

　　本文件给出了编制银行企业级数据字典的一般方法，提供了银行企业级数据字典框架结构、属性说明。

　　本文件适用于银行业金融机构的企业级数据字典的编制。

　　2 规范性引用文件

　　下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件;不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

　　JR/T 0105—2014 银行数据标准定义规范

　　3 术语和定义

　　GB/T 18391.1—2009、GB/T 25000.24—2017、JR/T 0105—2014、ISO/TR 21718:2019界定的以及下列术语和定义适用于本文件。

　　3.1

　　属性 attribute

　　一个对象或实体的特性。

　　[来源：GB/T 18391.1—2009，3.1.1] 3.2

　　数据项 data item

　　在特定上下文内数据的最小可识别单位，其定义、标识、允许值和其他信息是由一组属性指定。术语条目注 1：字段被认为是数据项的同义词。

　　术语条目注2：数据项是数据值的物理对象"容器"。

　　[来源：GB/T 25000.24—2017，第24部分：数据质量测量] 3.3

　　数据字典 data dictionary

　　以一致的方式给出数据项定义和规范的集合。

　　[来源：ISO/TR 21718:2019，3.4，有修改] 3.4

　　企业级数据字典 enterprise data dictionary

　　是企业在全域范围内统一维护的、结构化的数据字典。

　　1

　　T/CBA 225—2025

　　3.5

　　词根 vocabulary

　　构成词汇的基本元素，可以独立存在，也可与其他词根组合形成新的词汇。在企业级数据字典中，词根用于统一数据项中文名称的用词表达，并提供从中英文名称到英文简写的映射关系。

　　3.6

　　域 domain

　　全称为数据域。用于规范企业级数据字典中数据项的数据类型、数据格式、允许值等技术属性的集合，包括定义允许值的代码类域，以及不定义允许值的非代码类域。

　　3.7

　　代码集 code set

　　代码类域的允许值的集合，是对代码类域的详细解释说明，以组的形式进行体现。与代码类域是一对一的对应关系，包含代码取值、代码名称、代码说明等信息。

　　3.8

　　数据标准 data standard

　　对数据的表达、格式及定义的一致约定，包含数据业务属性、技术属性和管理属性的统一定义。业务属性包括中文名称、业务定义、业务规则等，技术属性包括数据类型、数据格式等，管理属性包括数据定义者、数据管理者等。

　　[来源：JR/T 0105—2014，3.3] 3.9

　　必选 mandatory

　　总是要求的。

　　术语条目注 1：适用于企业级数据字典属性的三种约束条件之一。表明该属性所要求的条件。

　　[来源：JR/T 0105—2014，3.5]

　　3.10

　　条件选 conditional

　　在某一规定条件下所要求的。

　　术语条目注 1：适用于企业级数据字典属性的三种约束条件之一。表明该属性所要求的条件。

　　[来源：JR/T 0105—2014，3.6]

　　3.11

　　可选 optional

　　允许但非必要的。

　　术语条目注 1：适用于企业级数据字典属性的三种约束条件之一。表明该属性所要求的条件。

　　[来源：JR/T 0105—2014，3.7]

　　4 编制原则

　　4.1 集中统筹原则

　　银行企业级数据字典由银行统一编制。

　　4.2 开放易用原则

　　主要表现在：

　　a) 兼容国家、行业、团体、国际标准， 以及管理部门要求;

　　b) 充分考虑当前技术现状及未来一段时间技术发展趋势，使数据字典具有可扩展性;

　　2

　　T/CBA 225—2025

　　c) 满足企业内部的业务经营管理和系统建设需求，并及时更新，形成适用性强、时效性强、可以落地的企业级数据字典。

　　4.3 统一规范原则

　　企业级数据字典的编制遵循统一的编制方法、框架结构、属性描述规则，对数据信息进行规范化、结构化定义。

　　5 编制方法

　　5.1 识别编制对象

　　进行充分的业务调研、技术调研及需求分析，识别出企业在各类应用场景中广泛使用且需要统一规范的数据项，并按照中文名称及业务含义进行筛选、去重处理，形成数据项范围清单。应用场景建议考虑：

　　a) 各业务领域经营管理场景;

　　b) 各类数据分析场景;

　　c) 各信息系统。

　　5.2 编制银行企业级数据字典分类体系

　　针对企业内的数据项按照一定分类、层次进行编目，提炼形成目录体系，便于数据项的检索、获取及管理。 目录体系建议考虑：

　　a) 目录结构相对稳定;

　　b) 具有一定扩展性，满足企业未来业务发展需要。

　　银行企业级数据字典分类体系示例参见附录A。

　　5.3 设计银行企业级数据字典定义框架

　　结合企业内实际情况，设计银行企业级数据字典的框架结构，内容包括：

　　a) 银行企业级数据字典的各个组成部分;

　　b) 各组成部分之间的关系;

　　c) 各组成部分的属性，针对本文件中的必选属性，都宜纳入;针对本文件中的可选属性，根据本企业需求确定是否纳入;针对本文件中的条件选属性，根据本企业是否符合条件来确定是否纳入;针对扩展属性，根据本企业的需求确定是否纳入。约束/条件说明参见附录 B。

　　银行企业级数据字典的框架设计方法见第6章。

　　5.4 制定数据项定义的流程

　　数据项定义以复用已有数据字典为基础，确保定义的一致性与完整性。流程包括以下内容：

　　a) 定义业务属性;

　　b) 定义技术属性;

　　c) 定义管理;

　　d) 扩展其他属性。

　　数据项及相关对象的定义流程示例见附录C。

　　3

　　T/CBA 225—2025

　　5.5 定义数据项的属性

　　定义银行企业级数据字典中各数据项及相关对象的属性及其关系，包括但不限于：

　　a) 数据项属性定义;

　　b) 域属性定义;

　　c) 代码集属性定义;

　　d) 词根属性定义;

　　e) 数据项、词根、域及代码集之间的关联关系。

　　数据项及相关对象的属性见第 7 章。

　　5.6 编制银行企业级数据字典

　　按照银行企业级数据字典分类体系，将数据项清单进行编目，作为银行企业级数据字典的正文部分。按照对应编码顺序，将域清单、代码集清单及词根清单进行排序，作为银行企业级数据字典的附录部分。

　　银行企业级数据字典模板示例详见附录 D。

　　5.7 应用银行企业级数据字典

　　银行企业级数据字典在信息系统建设各阶段提供统一的数据定义依据，并应用于数据标准实施、数据质量控制和数据安全管理等场景。应用场景示例参见附录 E。

　　6 银行企业级数据字典框架结构

　　银行企业级数据字典框架由数据项、域、词根组成，各组成部分由若干属性明确其特征。其中：

　　a) 银行企业级数据字典的基本对象为数据项;

　　b) 银行企业级数据字典的附属对象包括域、词根;

　　c) 域限定了数据项实际存储时的数据类型、数据格式和允许值的集合;

　　d) 代码集描述了代码类域的允许值的集合，是域的附属对象;

　　e) 词根统一了数据项中文名称、英文名称和英文简称的用词表达;

　　f) 业务属性描述数据与银行业务相关联的特性;

　　g) 技术属性描述数据与信息技术实现相关联的特性，是数据在信息系统项目实现时统一的技术方面定义;

　　h) 管理属性是描述企业级数据字典与数据管理相关联的特性，是数据管理在企业级数据字典管理领域的统一要求。

　　银行企业级数据字典框架如图1所示。

　　4

　　T/CBA 225—2025

　　图 1 银行企业级数据字典框架

　　基于上述框架定义的一个数据项及相关对象示例参见附录F。

　　7 银行企业级数据字典属性

　　7.1 数据项属性说明

　　7.1.1 概述

　　数据项的属性包括业务属性、技术属性、管理属性。业务属性包括数据项编号、业务分类、中文名称、英文名称、英文简称、业务定义、制定依据、取值范围、业务规则等。技术属性包括域编号、域中文名称、数据类型、逻辑数据格式、物理数据格式等。管理属性包括数据定义者、数据管理者、数据使用者、注册系统、数据标准编号等。

　　数据项属性框架如图2所示。

　　5

　　T/CBA 225—2025

　　图 2 数据项属性框架

　　注：图中的“ 引用域的属性 ”关系，是指数据项所引用的域对应的属性信息。

　　7.1.2 数据项编号

　　含义：企业级数据字典中数据项的唯一识别标识。

　　约束/条件：必选。

　　定义方法：

　　a) 采用定长的数字或字母顺序编码法;

　　b) 在企业级数据字典中唯一。

　　示例 ：000001。

　　7.1.3 业务分类

　　含义：按照业务情况将企业级数据项划分到不同的类别。

　　约束/条件：必选。

　　定义方法：

　　a) 可根据本银行机构的实际业务情况进行划分;

　　b) 可根据本银行机构的实际业务情况对业务分类进一步细分。

　　6

　　T/CBA 225—2025

　　示例：合约。

　　7.1.4 中文名称

　　含义：企业级数据项的统一中文命名， 由一个或多个词根构成。

　　约束/条件：必选。

　　定义方法：

　　a) 在企业级数据字典中唯一;

　　b) 从业务上区分不同的数据项，宜易于被使用人员理解和识别，充分体现业务含义;

　　c) 命名原则上不使用副词、介词、助词、连词、语气词之类的虚词。

　　示例：账户名称。

　　7.1.5 英文名称

　　含义：是企业级数据项的统一英文全称命名，主要是根据中文名称的含义进行英文翻译。

　　约束/条件：可选。

　　定义方法：

　　a) 原则上使用官方翻译或行业内较为通用的英文词汇，可由标准化的词根翻译得出;

　　b) 语义顺序与中文名称语义顺序相同。

　　示例 ：account name。

　　7.1.6 英文简称

　　含义：根据业务习惯，被普遍认可的、能够唯一标识企业级数据项的英文命名，是英文名称的简化。约束/条件：必选。

　　定义方法：

　　a) 在企业级数据字典中唯一;

　　b) 原则上使用官方翻译或行业内较为通用的英文缩写，可由标准化的词根翻译得出;

　　c) 语义顺序与中文名称语义顺序相同;

　　d) 英文单词缩写字母全部大写，单词缩写间用下划线连接。

　　示例：ACC_NAME。

　　7.1.7 业务定义

　　含义：基于产生数据的业务流程对数据业务口径和相关业务场景的详细描述，是数据业务含义的自然语言表述。

　　约束/条件：必选。

　　定义方法：

　　a) 业务定义需精准、细致，以利于数据字典使用人员理解，不宜循环引用或直接用中文名称或系统名称进行定义;

　　b) 业务定义可参考相关国家标准和行业标准、外部监管机构的定义、银行内部业务制度、信息系统业务需求定义、行业经验的总结性归纳等内容;

　　c) 业务定义需要与数据项其他属性相匹配，例如：不出现编码型数据项的业务定义描述为代码型的情况等。

　　示例：按照风险程度将贷款划分为不同档次，其实质是判断债务人及时足额偿还贷款本息的可能性。

　　7

　　T/CBA 225—2025

　　7.1.8 制定依据

　　含义：描述数据项的业务依据来源。

　　约束/条件：可选。

　　定义方法：包括但不限于国家法律法规、国家标准、行业标准、外部监管要求、国际标准、银行内部制度和系统规范、行业惯例等。

　　示例：GB/T 12406-2022表示货币的代码。

　　7.1.9 取值范围

　　含义：描述数据项可接受的有效值范围，即允许值的集合，定义取值边界。

　　约束/条件：可选。

　　定义方法：

　　a) 金额型的数据项尽量明确区间范围，例如大于等于零或可以为负等;

　　b) 数值型的数据项尽量明确区间范围，并说明是否包括区间边界值;

　　c) 比例型的数据项尽量明确区间范围，并说明是否在数字后加“% ”(数值为 0 除外)。

　　示例：大于等于零。

　　7.1.10 业务规则

　　含义：银行业务对数据的约束条件的具体描述，包括相关业务的政策规定、政策规定发生作用的业务场景，例如数据的计算方法、数据的编码规则等内容。

　　约束/条件：条件选。

　　定义方法：

　　a) 编码型的数据项必填，描述编码的规则，可包括编码的长度、编码的构成、各组成部分的业务含义等;

　　b) 主要来源于外部监管机构规定、银行业务制度、信息系统业务需求等;

　　c) 若数据项由其他数据计算得出，可列出计算公式;

　　d) 若数据项可同时有多种取值，建议在业务规则中予以说明。

　　示例：第1-6位：事件日期;第7-10位：顺序码;第11位：标志。

　　7.1.11 数据定义者

　　含义：对数据的业务属性拥有最终业务解释权的组织。通常为该数据所涉及银行业务的主管部门。约束/条件：可选。

　　定义方法：企业内部统一命名的机构名称。

　　示例：风险管理部。

　　7.1.12 数据管理者

　　含义：对数据管理负责的组织。通常为该数据所属信息系统的主管部门，或者负责数据管理的部门，对该数据的相关业务流程和管理流程具备相当的认识和理解，能够很好地分析和理解各种变更对数据质量以及数据项的影响。

　　约束/条件：可选。

　　定义方法：企业内部统一命名的机构名称。

　　示例：数据管理部。

　　8

　　T/CBA 225—2025

　　7.1.13 数据使用者

　　含义：合法地收集、有限度地控制、使用有关数据的组织。数据使用者要协助审核对数据项的变更建议，并识别潜在的影响和问题。

　　约束/条件：可选。

　　定义方法：企业内部统一命名的机构名称。

　　示例：运营管理部。

　　7.1.14 注册系统

　　含义：指数据项注册时所依据的信息系统。

　　约束/条件：可选。

　　定义方法：企业内部统一命名的系统名称。

　　示例：个人业务核心系统。

　　7.1.15 数据标准编号

　　含义：指数据项所遵循的数据标准项的唯一标识符。

　　约束/条件：条件选，仅限数据项与数据标准可映射时存在。

　　定义方法：企业内部统一数据标准的唯一标识符。

　　示例 ：000001。

　　7.1.16 域编号

　　引用域的域编号，相关定义同7.2.2。

　　7.1.17 域中文名称

　　引用域的域中文名称，相关定义同7.2.3。

　　7.1.18 数据类型

　　引用域的数据类型，相关定义同7.2.4。

　　7.1.19 逻辑数据格式

　　引用域的逻辑数据格式，相关定义同7.2.5。

　　7.1.20 物理数据格式

　　引用域的物理数据格式，相关定义同7.2.6。

　　7.2 域属性说明

　　7.2.1 概述

　　域属性包括域编号、域中文名称、数据类型、逻辑数据格式、物理数据格式等。

　　域属性框架如图3所示。

　　9

　　T/CBA 225—2025

　　图 3 域属性框架

　　7.2.2 域编号

　　含义：企业级数据字典中域属性信息的唯一识别标识，管理域属性的唯一索引。

　　约束/条件：必选。

　　定义方法：

　　a) 采用定长的数字或字母顺序编码法;

　　b) 每项域建立唯一的域编号。

　　示例 ：000001。

　　7.2.3 域中文名称

　　含义：对域的统一中文命名。

　　约束/条件：必选。

　　定义方法：

　　a) 每项域对应唯一的域中文名称;

　　b) 域中文名称定义规范、表意清晰;

　　c) 域中文名称中体现数据类型。

　　示例：行政区划代码。

　　7.2.4 数据类型

　　含义：根据数据的业务定义、业务规则和常见表现形式定义其采用的数据分类。

　　约束/条件：必选。

　　定义方法：

　　a) 每项域对应唯一的数据类型;

　　b) 遵循 JR/T 0105—2014，具体详见附录 G。

　　示例：代码类。

　　7.2.5 逻辑数据格式

　　含义：指域的逻辑定义下的格式，通过字母、数字及符号抽象描述数据的格式、 内容、长度信息。约束/条件：必选。

　　定义方法：原则上遵循 JR/T 0105—2014，具体详见附录 H。

　　示例：an..6。

　　7.2.6 物理数据格式

　　含义：根据数据库特征，定义技术落地时物理存储的数据格式，包括数据类型、数据长度等。

　　约束/条件：必选。

　　10

　　T/CBA 225—2025

　　定义方法：

　　a) 物理数据格式需根据不同数据库类型进行转换;

　　b) 一般包括 ORACLE 数据格式、PostgreSQL 数据格式、HIVE 数据格式等。

　　示例 ：CHAR(1)。

　　7.2.7 代码集属性说明

　　7.2.7.1 概述

　　代码集属性包括代码取值、代码名称、代码说明、代码层级、上级代码取值等。

　　建议数据类型(见7.2.4数据类型)为“代码类 ”和“标志类 ”的域具有代码集属性。

　　代码集属性框架如图4所示。

　　图 4 代码集属性框架

　　7.2.7.2 代码取值

　　含义：用来代表特定信息的一组符号或数字。

　　约束/条件：必选。

　　定义方法：

　　a) 宜设计为数字或字母或数字字母组合，即取值范围为“0 ”-“9 ”和“A ”-“Z ”;

　　b) 编码规则可采用顺序编码、层次编码等方式;

　　c) 顺序编码即依据数字或字母的大小依次编码;

　　d) 层次编码即在代码取值中体现不同代码之间的层次依赖关系;

　　e) 相同层级代码宜使用相同长度。

　　示例：110108。

　　7.2.7.3 代码名称

　　含义：描述代码的具体含义，帮助数据字典使用者理解数据。

　　约束/条件：必选。

　　定义方法：相同层级代码的代码名称不宜有重合含义。

　　示例：北京市海淀区。

　　7.2.7.4 代码说明

　　含义：描述使用代码的规则，包括不限于业务规则、与其他代码对应关系、已废止代码等。约束/条件：可选。

　　定义方法：用文字描述说明。

　　示例：一级行政区划。

　　11

　　T/CBA 225—2025

　　7.2.7.5 代码层级

　　含义：描述代码之间的层次关系结构。

　　约束/条件：可选。

　　定义方法：用数字描述层级。

　　示例：2。

　　7.2.7.6 上级代码取值

　　含义：描述本代码所属上一级代码的代码取值。

　　约束/条件：可选。

　　定义方法：与代码取值一致。

　　示例：110000。

　　7.3 词根属性说明

　　7.3.1 概述

　　词根属性包括词根中文名、词根英文名、词根英文简写等。词根属性框架如图5所示。

　　图 5 词根属性框架

　　7.3.2 词根中文名

　　含义：数据项的中文名称使用到的中文组成单元。

　　约束/条件：必选。

　　定义方法：

　　a) 词根中文名不允许重复出现;

　　b) 由单个或多个汉字组成。

　　示例：贷款、存款。

　　7.3.3 词根英文名

　　含义：根据词根中文名的含义进行的统一英文翻译。

　　约束/条件：必选。

　　定义方法：原则上翻译参考官方翻译和行业通用词汇。

　　示例：贷款-loan、存款-deposit。

　　7.3.4 词根英文简写

　　含义：根据词根英文名简写形成。

　　约束/条件：必选。

　　定义方法：

　　a) 词根英文简写与词根中文名一一对应;

　　12

　　T/CBA 225—2025

　　b) 一般通过在词根英文名的基础上删除元音字母缩至最短词根;

　　c) 通常由 3-5 位英文字母组成。

　　示例：贷款-LOAN、存款-DPST。

　　7.4 扩展属性说明

　　各银行可根据自身个性化需求，对本标准规定的属性进行扩展。扩展的属性宜遵循以下基本原则：

　　a) 选取属性时，可考虑新属性在应用中的特点以及工作的复杂、难易程度;

　　b) 建议选取的属性不仅满足当前阶段的应用需求，也满足将来一定时间内可能产生的标准化需求;

　　c) 扩展的属性不与本标准定义的现有的属性的名称、定义相冲突;

　　d) 扩展的属性元素宜按照本标准所确定的层次关系进行合理的组织。

　　扩展属性示例参见附录I。

　　13

　　T/CBA 225—2025

　　附录 A

　　(资料性)

　　银行企业级数据字典分类体系示例

　　A.1 范围

　　本附录给出了银行企业级数据字典分类体系示例。

　　A.2 银行企业级数据字典分类体系示例

　　参照业界通用的 FSDM 模型(financial services datamodel，广泛使用的一类企业级数据模型)，企业级数据字典中目录体系中，数据项一级类目包括 9 大主题，即参与人、产品、合约、资源项、事件、财务、渠道、位置、公共。

　　银行企业级数据字典目录体系示例如表 A.1 所示。

　　表 A.1 银行企业级数据字典分类体系示例

　　序号

　　一级类目

　　说明

　　1

　　参与人

　　指所有已经与银行建立联系、或者与企业的利益密切相关、或者企业希望保存其信息的自然人、组织、内部机构

　　2

　　产品

　　是指银行提供的可满足客户需求且能够为企业带来收益的金融服务，以及参与金融市场活动所使用的金融工具

　　3

　　合约

　　又称为合同，契约，是平等的当事人之间设立、变更、终止民事权利义务关系的协议。合约作为一种民事法律行为，是当事人协商一致的产物，是两个以上的意思表示相一致的协议。依法成立的合同从成立之日起生效，具有法律约束力。这里合约主要指银行与客户在业务过程中签立的合同，或与合作伙伴、员工达成的合作意向、合作规则的承诺及合作协议

　　4

　　资源项

　　是资产的统称，指任何公司、机构和个人拥有的任何具有商业或交换价值的东西

　　5

　　事件

　　是银行为业务目标的实现或业务的执行而希望保留的将发生或已发生的活动

　　6

　　财务

　　指描述银行总账、会计科目、账套、会计期间等财务相关信息

　　7

　　渠道

　　指银行为客户提供各种产品和服务的方式或途径，包括：网点柜面、自助设备、电子银行、电子支付、收单业务等

　　8

　　位置

　　是指银行希望保存的地址或地理区域的信息

　　9

　　公共

　　包括公共代码和业务参数，经常在数据标准定义过程中，被多个标准主题引用的公共信息

　　14

　　T/CBA 225—2025

　　附录 B

　　(规范性)

　　约束/条件说明

　　B.1 约束/条件

　　属性的一个说明符，说明一个属性是否应当总是在银行企业级数据字典中选用或有时选用(即有值)。约束/条件说明如表B.1所示。

　　表 B.1 约束/条件说明

　　约束/条件名称

　　英文名称

　　缩写符号

　　规则描述

　　必选

　　Mandatory

　　M

　　表明该属性应选择

　　可选

　　Optional

　　O

　　表明该属性根据实际应用可以选择也可以不选

　　条件选

　　Conditional

　　C

　　说明可以选择该属性的条件，当该条件满足时，至少一个属性必选。“条件选 ”用于以下三种可能性之一：

　　1.表示在2个或2个以上属性中进行选择。至少存在一个属性必选

　　2.当已经选用另一个属性时，此属性为必选

　　3.当另一个属性已经选择了一个特定值时，此属性为必选

　　15

　　T/CBA 225—2025

　　附录 C

　　(资料性)

　　数据项及相关对象定义流程示例

　　C.1 范围

　　本附录给出了定义数据项及相关对象各属性的工作流程示例。 C.2 数据项及相关对象定义流程示例

　　数据项及相关对象定义流程示例如图C.1所示。

　　图 C.1 数据项及相关对象定义流程示例

　　16

　　T/CBA 225—2025

　　附录 D

　　(资料性)

　　银行企业级数据字典模板示例

　　D.1 范围

　　本附录给出了银行企业级数据字典模板的示例。

　　D.2 银行企业级数据字典模板示例

　　D.2.1 数据项清单模板

　　数据项清单如表D.1所示。

　　表 D.1 数据项清单模板

　　业务属性

　　技术

　　属性

　　管理属性

　　数据

　　业务

　　中文

　　英文

　　英文

　　业 务

　　制 定

　　取值

　　业 务

　　域编

　　数据

　　数据

　　数据

　　注册

　　数 据

　　项编

　　分类

　　名称

　　名称

　　简称

　　定义

　　依据

　　范围

　　规则

　　号

　　定义

　　管理

　　使用

　　系统

　　标 准

　　号

　　者

　　者

　　者

　　编号

　　数据项清单中的域编号，引用域清单中的域编号。 D.2.2 域清单模板

　　域清单如表D.2所示。

　　表 D.2 域清单模板

　　域编号

　　域中文名称

　　数据类型

　　逻辑数据格式

　　物理数据格式

　　D.2.3 代码集清单模板

　　代码集清单如表D.3所示。

　　表 D.3 代码集清单模板

　　域编号

　　代码取值

　　代码名称

　　代码说明

　　代码层级

　　上级代码取值

　　代码集清单中的域编号，引用域清单中的域编号。

　　17

　　T/CBA 225—2025

　　D.2.4 词根清单模板

　　词根清单如表D.4所示。

　　表 D.4 词根清单模板

　　词根中文名

　　词根英文名

　　词根英文简写

　　18

　　T/CBA 225—2025

　　附录 E

　　(资料性)

　　银行企业级数据字典应用场景示例

　　E.1 范围

　　本附录给出了银行企业级数据字典在数据管理和系统建设中的应用场景示例。

　　E.2 银行企业级数据字典在数据管理领域的应用示例

　　企业级数据字典可包含数据标准、数据质量、数据安全等多维度管理信息，通过将管理信息转化为可执行的结构化规则，在数据管理各相关环节实现管控。

　　a) 执行数据标准。企业级数据字典将数据标准转化为一系列可校验、可控制的结构化属性，通过将业务术语、命名约定、值域约束等标准内容成为字典中的结构化属性，为数据一致性校验、主数据识别、参考数据维护等管理活动提供可引用的权威定义;

　　b) 控制数据质量与安全。企业级数据字典为数据质量与安全管理提供了规则基准。通过定义数据质量规则与数据安全分级等扩展属性，提供统一的数据质量与数据安全策略依据，实现管控规则的集中定义与有效执行。

　　E.3 银行企业级数据字典在信息系统建设中的应用示例

　　在信息系统建设中，企业级数据字典为设计、开发、上线、运维等阶段提供了统一的数据规范。

　　a) 系统设计阶段。系统设计人员基于业务需求进行数据库表结构设计，维护系统级数据项清单，并与企业级数据字典进行匹配映射，并实施所匹配字典项的属性;

　　b) 系统开发阶段。系统开发人员根据系统设计进行编码，以及相应的数据清洗或转换，确保系统数据库表满足企业级数据字典属性规范;

　　c) 系统上线阶段。数据管理人员根据企业级数据字典属性规则设置检查点，符合规则的数据库表才能够进入构建与发布环节;

　　d) 系统运维阶段。数据管理人员对生产环境的数据库表结构和数据内容进行监测，对偏离企业级数据字典规则的对象触发告警或阻断机制，保障系统长期符合数据规范。

　　19

　　T/CBA 225—2025

　　附录 F

　　(资料性)

　　“贷款五级分类代码”数据项及相关对象示例

　　F.1 范围

　　本附录给出了“贷款五级分类代码 ”数据项及相关对象的描述示例。

　　F.2 数据项及相关对象描述示例F.2.1 数据项定义

　　数据项编号：122212。

　　业务分类：合约/产品合约/贷款业务。

　　中文名称：贷款五级分类代码。

　　英文名称：loan five level class code。

　　英文简称：LOAN_LVL5_CLASS_CD。

　　业务定义：按照风险程度将贷款划分为不同档次，其实质是判断债务人及时足额偿还贷款本息的可能性。

　　制定依据：贷款风险分类指引。

　　取值范围：符合代码的取值范围。

　　业务规则：采用1位数字顺序编码。

　　数据定义者：个人金融部、公司金融部。

　　数据管理者：数据管理部、个人金融部、公司金融部。

　　数据使用者：个人金融部、公司金融部、各级分支机构。

　　注册系统：信贷业务平台。

　　数据标准编号：000024。

　　域编号：230039。

　　域中文名称：贷款五级分类代码。

　　数据类型：代码类。

　　逻辑数据格式：n1。

　　物理数据格式：ORACLE数据格式：CHAR(1)。PostgreSQL数据格式：CHARACTER(1)。HIVE数据格式： CHAR(1)。

　　F.2.2 域定义

　　域编号：230039。

　　域中文名称：贷款五级分类代码。

　　数据类型：代码类。

　　逻辑数据格式：n1。

　　物理数据格式：ORACLE数据格式：CHAR(1)。PostgreSQL数据格式：CHARACTER(1)。HIVE数据格式： CHAR(1)。

　　代码集示例如表F.1所示。

　　20

　　T/CBA 225—2025

　　表 F.1 代码集示例

　　代码取值

　　代码名称

　　代码说明

　　代码层级

　　上级代码取值

　　1

　　正常

　　借款人能够履行合同，没有足够理由怀疑贷款本息不能按时足额偿还

　　1

　　-

　　2

　　关注

　　尽管借款人目前有能力偿还贷款本息，但存在一些可能对偿还产生不利影响的因素

　　1

　　-

　　3

　　次级

　　借款人的还款能力出现明显问题，完全依靠其正常营业收入无法足额偿还贷款本息，即使执行担保，也可能会造成一定损失

　　1

　　-

　　4

　　可疑

　　借款人无法足额偿还贷款本息，即使执行担保，也肯定要造成较大损失

　　1

　　-

　　5

　　损失

　　在采取所有可能的措施或一切必要的法律程序之后，本息仍然无法收回，或只能收回极少部分

　　1

　　-

　　F.2.3 词根定义

　　词根示例如表F.2所示。

　　表 F.2 词根示例

　　词根中文名

　　词根英文名

　　词根英文简写

　　贷款

　　loan

　　LOAN

　　五级

　　five level

　　LVL5

　　分类

　　class

　　CLASS

　　代码

　　code

　　CD

　　21

　　T/CBA 225—2025

　　附录 G

　　(规范性)

　　银行企业级数据字典的数据类型

　　G.1 范围

　　本附录给出了银行企业级数据字典的数据类型。原则上遵循JR/T 0105—2014，各银行可根据自身管理需要，对数据类型进行调整。

　　G.2 数据类型G.2.1 编码类

　　编码是用少量、简单的基本符号，选用一定的组合规则，表示大量复杂多样的信息。

　　示例：客户编码、机构编码、产品编码。

　　G.2.2 代码类

　　代码是一套预先定义的，用来描述一个有限集合的事物或事物的属性，代码数据能够在一段时期内相对稳定。

　　示例：国家和地区代码、押品类型代码。

　　G.2.3 标志类

　　表示“是/否 ”意义的标志，1表示是， 0表示否。

　　示例：组合产品标志、雇员标志。

　　G.2.4 文本类

　　需要以文本的形式对与银行业务活动密切相关的对象和业务进行说明的数据。

　　示例：客户详细地址、产品说明。

　　G.2.5 金额类

　　以货币金额的形式体现的数据项，适用于各类财务信息。金额类数据项，需在业务定义中明确度量单位(元、万元等)。

　　示例：贷款余额、资产总额。

　　G.2.6 数值类

　　以整数或小数的形式体现的数据项，适用于各类以数量反映的信息。数值类数据项，需在业务定义中明确度量单位。

　　示例：营业场所办公面积、流通股数。

　　G.2.7 比例类

　　以比值的形式体现的数据项，适用于各类比率信息。

　　示例：利息税率、利率浮动幅度。

　　22

　　T/CBA 225—2025

　　G.2.8 日期类

　　需要以日期的形式体现的数据项，以描述银行业务发生的日期。

　　示例：客户出生日期、客户开户日期。

　　G.2.9 时间类

　　需要以时间的形式体现的数据项，以描述银行业务发生的时间。

　　示例：登录时间、取款时间。

　　G.2.10 日期时间类

　　需要以日期和当日时间的组合形式体现的数据项，以描述银行业务发生的日期和时间。

　　示例：账户开户日期时间、账户销户日期时间。

　　23

　　T/CBA 225—2025

　　附录 H

　　(规范性)

　　银行企业级数据字典的数据格式

　　H.1 范围

　　本附录给出了银行企业级数据字典的数据格式定义。原则上遵循JR/T 0105—2014，各银行可根据自身管理需要，对数据格式进行调整。

　　H.2 数据格式

　　a 字母字符

　　n 数字字符

　　an 字母数字字符

　　anc 字母数字汉字字符

　　M、N 表示自然数

　　M!a M位字母字符，定长

　　M!n M位数字字符，定长

　　M!an M位字母数字字符，定长

　　M!anc M位字母数字汉字字符，定长

　　a..M 最多为M位字母字符

　　n..M 最多为M位数字字符

　　an..M 最多为M位字母数字字符

　　anc..M 最多为M位字母数字汉字字符

　　aM.. 最少为M位字母字符

　　nM.. 最少为M位数字字符

　　anM.. 最少为M位字母数字字符

　　ancM.. 最少为M位字母数字汉字字符

　　aM..N 最少为M位最多为N位字母字符

　　nM..N 最少为M位最多为N位数字字符

　　anM..N 最少为M位最多为N位字母数字字符

　　ancM..N 最少为M位最多为N位字母数字汉字字符

　　M(N) M位数字字符，其中包括小数点和N个小数位(M>N+1)

　　YYYY-MM-DD 日期格式，表示年月日

　　HH:MM:SS 24小时格式

　　YYYY-MM-DDTHH:MM:SS:NNN 日期时间格式，表示某年某月某日某时某分某秒某微秒H.3 示例

　　7!an 表示定长7个字母数字字符。

　　anc3..8 表示最小长度为3，最大长度为8的不定长字母数字汉字字符。

　　12(2) 表示12位数字字符，其中包括小数点和2个小数位。

　　24

　　T/CBA 225—2025

　　附录 I

　　(资料性)

　　扩展属性示例

　　I.1 范围

　　本附录给出了数据质量、数据安全分类分级等相关扩展属性定义的示例。

　　I.2 数据质量属性说明

　　I.2.1 数据质量规则编号

　　含义：数据质量规则的唯一标识符。

　　约束/条件：可选。

　　定义方法：选取数据质量规则库中的规则编号。

　　示例：000001。

　　I.2.2 数据质量规则

　　含义：规定数据所符合的质量标准和要求。

　　约束/条件：可选。

　　定义方法：数据质量规则库中，所选数据质量规则编号对应的规则描述。

　　示例：证件类型为居民身份证时，证件号码应满足18位校验规则。

　　I.3 数据安全分类分级属性说明I.3.1 数据安全分类

　　含义：遵循国家数据分类分级保护要求，对本企业内部的数据进行分类，包括多个层级的分类。约束/条件：可选。

　　定义方法：参考JR/T 0197—2020相关要求，根据企业所管辖数据的类型、特性、规模、企业特性等因素，按照一定的颗粒度对数据进行合理的梳理、归类和细分。

　　示例：

　　一级子类：客户;

　　二级子类：个人;

　　三级子类：个人自然信息;

　　四级子类：个人基本概况信息。

　　I.3.2 数据安全分级

　　含义：根据金融业机构数据安全性遭受破坏后的影响对象和所造成的影响程度，对数据的安全性进行分级。

　　约束/条件：可选。

　　定义方法：参考JR/T 0197—2020相关要求，根据企业所管辖数据的类型、特性、规模、企业特性等因素，综合考虑本企业数据安全管理的总体目标和安全策略要求进行定义。

　　示例：3 级。

　　25

　　T/CBA 225—2025

　　参 考 文 献

　　[1] GB/T 5271.1—2000 信息技术 词汇 第1部分：基本术语

　　[2] GB/T 5271.4—2000 信息技术 词汇 第4部分：数据的组织

　　[3] GB/T 7408—2005 数据元和交换格式 信息交换 日期和时间表示法

　　[4] GB/T 12406—2022 表示货币的代码

　　[5] GB/T 18391.1—2009 信息技术 元数据注册系统(MDR) 第1部分：框架

　　[6] GB/T 18391.3—2009 信息技术 元数据注册系统(MDR) 第3部分：注册系统元模型与基本属性

　　[7] GB/T 20001.3—2001 标准编写规则 第3部分：信息分类编码

　　[8] GB/T 25000.24—2017 系统与软件工程 系统与软件质量要求和评价(SQuaRE) 第24部分：数据质量测量

　　[9] JR/T 0015—2004 银行信息化通用数据元

　　[10] JR/T 0027—2006 征信数据元 数据元设计与管理

　　[11] JR/T 0197—2020 金融数据安全 数据安全分级指南

　　[12] ISO 20022:2013 Financial services — Universal financial industry message scheme

　　[13] ISO/IEC 11179-1 :2023 Information technology — Metadata registries (MDR)—Part 1 :Framework

　　[14] ISO/TR 21718:2019 Intelligent transport systems — Spatio — temporal data dictionary for cooperative ITS and automated driving systems 2.0

　　26