RWA解决供应链金融中的痛点：从应收账款数字化到链上资产融资
供应链金融一直存在一个很现实的矛盾：真正缺资金的企业，往往不是核心企业，而是供应链上的中小供应商；真正拥有信用能力的企业，又很难把自己的信用有效传导到多级供应商。
传统供应链金融试图通过核心企业信用、应收账款、保理、仓单、订单融资等方式解决这个问题，但实际落地时仍然绕不开几个老问题：资产真实性难验证、确权周期长、信息孤岛严重、融资机构风控成本高、资产流转效率低，以及融资后资金和底层资产难以持续监控。
RWA（Real World Assets，现实世界资产）并不是简单地把“应收账款放到区块链上”。它真正有价值的地方，是把现实资产、法律权利、业务数据、融资关系和资金结算连接起来，并通过可编程的数字资产实现自动化流转。
BIS对Tokenisation的定义也强调了这一点：Tokenization并非单纯建立一个数据库，而是把资产信息与控制其转移的规则和逻辑结合起来，使交易能够根据预设条件自动执行。([Bank for International Settlements][1])
对于供应链金融而言，这意味着一个重要变化：
过去金融机构融资的是“企业信用+纸面材料”，未来可以逐步转向融资“可验证的资产权利+实时业务数据+可编程交易规则”。
一、供应链金融真正难在哪里
先不谈区块链。
如果把一笔典型的供应链融资拆开，可以看到它实际上包含五个不同问题：
货物/服务交付
↓
订单
↓
验收
↓
发票
↓
应收账款形成
↓
核心企业确权
↓
供应商融资
↓
核心企业付款
↓
融资机构收回本金
看起来流程并不复杂，但每一个环节都可能产生风险。
1. 应收账款真实性难验证
供应商拿着一张应收账款向金融机构融资，金融机构首先需要回答：
这笔交易真的发生了吗？
发票是真的吗？
货物真的交付了吗？
核心企业是否认可这笔债权？
这笔债权是否已经融资？
是否已经转让给其他机构？
是否存在重复融资？
传统模式下，这些信息分散在ERP、发票系统、物流系统、银行系统、核心企业供应链平台等不同系统里。
金融机构需要通过人工或接口进行交叉验证。
因此，融资审批的真正成本并不是“贷款审批”本身，而是：
证明这笔资产确实存在，并且能够被合法控制和处置。
二、核心企业信用为什么很难真正传导
供应链金融经常强调“核心企业信用”。
例如：
大型核心企业
│
├── 一级供应商
│ │
│ └── 二级供应商
│ │
│ └── 三级供应商
│
└── 经销商
核心企业可能拥有非常好的信用，但二级、三级供应商仍然可能融资困难。
原因在于核心企业的信用并不会天然变成一项可以交易的金融资产。
传统模式需要：
核心企业确认应付账款；
金融机构审核供应商；
核实债权；
签署转让/保理协议；
建立担保或其他增信关系；
放款；
后续进行账款管理。
每增加一级供应链参与者，信息验证和法律关系都会变复杂。
RWA真正值得关注的地方，就在这里：
它可以把“信用关系”进一步结构化为可验证、可转移、可编程的资产权利。
三、RWA到底改变了什么
RWA可以理解成三个层次。
第一层：现实资产
例如：
应收账款
仓单
商品
订单
租赁收益权
基础设施收益权
不动产
债券
基金份额
第二层：法律权利
真正有价值的不是区块链上的Token，而是Token背后对应的法律权利。
例如：
Token #A10293
│
├── 对应应收账款 100万元
├── 债务人：核心企业A
├── 到期日：2026-12-30
├── 已确权
├── 未质押
└── 当前权利人：融资机构B
第三层：链上规则
进一步把业务规则编码进去：
如果：
核心企业确认债权
AND
货物验收完成
AND
应收账款未融资
AND
KYC通过
AND
融资额度充足
那么：
允许发行资产Token
这才是RWA与普通数字化的区别。
BIS将Tokenisation描述为把传统资产上的权利记录到可编程平台，并把信息、规则和资产转移结合起来。([Bank for International Settlements][2])
四、RWA如何解决供应链金融的六大痛点
1. 从“证明资产存在”转向“资产状态持续可验证”
传统融资通常是在融资时验证一次。
例如：
T0：提交发票
T1：人工审核
T2：核心企业确认
T3：银行放款
T4：等待还款
但供应链资产其实是动态变化的。
RWA体系可以建立资产状态机：
CREATED
↓
DELIVERED
↓
ACCEPTED
↓
CONFIRMED
↓
TOKENIZED
↓
FINANCED
↓
MATURED
↓
SETTLED
任何状态变化都应该产生可审计事件。
例如：
{
"asset_id": "AR-2026-000183",
"debtor": "CORE-A",
"creditor": "SUPPLIER-B",
"amount": 1000000,
"currency": "CNY",
"status": "CONFIRMED",
"due_date": "2026-12-30",
"financing_status": "UNFINANCED"
}
这意味着金融机构看到的不再只是PDF、合同和发票，而是一套可以持续更新的资产状态。
五、解决重复融资问题
这是供应链金融非常典型的风险。
假设：
应收账款：100万元
供应商A
↓
银行1：融资80万
同时
↓
保理机构2：再次融资70万
如果两个机构之间没有共享账本，就可能发生重复融资。
RWA体系可以给每一个资产建立唯一标识：
Asset ID
↓
Legal Claim
↓
Token ID
↓
Ownership
↓
Financing Status
例如：
AR-2026-000183
Owner:
Bank-A
Face Value:
1,000,000 CNY
Financed:
800,000 CNY
Encumbered:
YES
Transferable:
NO
智能合约可以直接限制：
require(asset.financed == false, "already financed");
require(asset.encumbered == false, "asset encumbered");
require(asset.status == CONFIRMED, "not confirmed");
于是重复融资不再完全依赖人工审核。
需要强调的是：
区块链不能天然阻止现实世界的欺诈。
如果供应商一开始就提交虚假的交易数据，链上只能保证“错误的数据被可靠记录”，而不能自动保证“数据本身是真的”。
这也是RWA最大的认知误区之一。
BIS也明确指出，Tokenisation仍然面临法律、治理和经济层面的挑战，技术并不会自动消除信息不对称和金融中介需要承担的筛选职能。([Bank for International Settlements][3])
六、解决确权慢的问题
传统应收账款融资经常需要：
供应商
↓
提交合同
↓
提交发票
↓
核心企业确认
↓
银行审核
↓
签署融资协议
↓
放款
如果采用数字化RWA架构，可以把核心企业的“确权动作”直接变成一个数字事件：
Invoice
↓
ERP验证
↓
Core Enterprise Approval
↓
Claim Confirmed
↓
RWA Mint
例如：
{
"event": "RECEIVABLE_CONFIRMED",
"asset_id": "AR-2026-000183",
"confirmor": "CORE-A",
"timestamp": 1788000000,
"amount": 1000000,
"signature": "0x..."
}
金融机构收到这个事件后，可以自动进入下一步风控。
于是：
“核心企业盖章确认”逐渐变成“核心企业签名确认并产生可验证状态”。
七、解决资产流转效率低的问题
传统应收账款转让涉及大量合同和人工流程：
供应商
↓
保理公司
↓
银行
↓
资产管理机构
↓
投资机构
每一次转让都需要重新核验：
权利是否真实；
权利人是谁；
是否已经质押；
是否存在其他权利负担；
是否完成通知；
是否满足转让条件。
RWA可以把资产权利转移设计成标准化交易：
Seller
│
│ Transfer
↓
RWA Contract
│
├── Ownership Change
├── Compliance Check
├── Asset Status Update
└── Audit Event
↓
Buyer
这也是Tokenisation真正具有金融基础设施意义的地方。
BIS认为，Tokenisation能够将信息、清算、资产转移和规则执行整合到可编程平台，并通过条件执行减少传统流程中的对账、人工干预和结算摩擦。([Bank for International Settlements][2])
八、解决跨机构对账问题
传统供应链金融最容易被低估的成本之一就是“对账”。
假设一个项目涉及：
核心企业ERP
↓
供应商ERP
↓
物流平台
↓
电子发票系统
↓
银行系统
↓
保理系统
↓
资金托管系统
每个系统都有自己的数据库。
于是出现：
系统A：100万元
系统B：100万元
系统C：98万元
系统D：100万元
到底哪个是真实状态？
RWA系统可以建立统一的资产ID：
Asset ID = AR-2026-000183
所有系统围绕这个ID交换状态：
ERP
│
├── Order
│
├── Invoice
│
└── Acceptance
↓
RWA Registry
↓
┌──────┼──────┐
↓ ↓ ↓
Bank Factor Investor
区块链在这里最重要的价值不是“去中心化”，而是：
让多个互不完全信任的参与者围绕同一资产状态建立可验证的一致性。
九、RWA+智能合约：把融资条件写成代码
真正有技术含量的RWA供应链金融，不应该只是“数据库+Token”。
核心应该是：
资产状态机 + 风控规则 + 智能合约 + 预言机 + 结算系统。
一个简化的架构如下：
┌──────────────────┐
│ Core Enterprise │
│ ERP / SCM / CRM │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Data Integration │
│ API / Event Bus │
└────────┬─────────┘
│
┌────────────┴────────────┐
▼ ▼
┌────────────────┐ ┌────────────────┐
│ Asset Registry │ │ Oracle Service │
│ 资产登记中心 │ │ 外部数据验证 │
└────────┬───────┘ └────────┬───────┘
│ │
└────────────┬────────────┘
▼
┌───────────────────┐
│ RWA Smart Contract│
│ Asset State │
│ Ownership │
│ Financing │
│ Settlement │
└─────────┬─────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
Bank Factor Investor
│
▼
Settlement Layer
十、一个供应链RWA智能合约应该怎么设计
简化后的Solidity结构可以这样设计：
contract SupplyChainRWA {
enum Status {
Created,
Confirmed,
Financed,
Matured,
Settled,
Defaulted
}
struct Asset {
bytes32 assetId;
address creditor;
address debtor;
uint256 faceValue;
uint256 dueDate;
Status status;
bool pledged;
bool financed;
}
mapping(bytes32 => Asset) public assets;
function confirmAsset(
bytes32 assetId
) external onlyCoreEnterprise {
Asset storage asset = assets[assetId];
require(
asset.status == Status.Created,
"invalid state"
);
asset.status = Status.Confirmed;
}
function finance(
bytes32 assetId
) external onlyFinancialInstitution {
Asset storage asset = assets[assetId];
require(
asset.status == Status.Confirmed,
"asset not confirmed"
);
require(
!asset.financed,
"already financed"
);
asset.financed = true;
asset.status = Status.Financed;
}
}
生产环境当然不能这么简单。
真正的系统还需要：
权限控制；
多签；
升级策略；
暂停机制；
合规检查；
资产冻结；
违约处理；
事件索引；
审计；
密钥管理；
灾备。
智能合约的目标不是把整个供应链业务搬到链上，而是：
把那些规则明确、需要多方确认、适合自动执行的环节放到可验证的执行环境中。
十一、预言机才是RWA真正的关键基础设施
RWA项目最大的技术难点之一其实不是Token，而是Oracle。
因为区块链无法直接知道：
货物有没有到？
发票有没有付款？
仓库里还有多少货？
核心企业ERP里的订单状态是什么？
物流是否异常？
商品价格是多少？
这些信息都来自链下。
因此必须建立：
Real World
│
▼
Enterprise Systems
│
▼
Data Verification
│
▼
Oracle
│
▼
Blockchain
例如：
{
"asset_id": "WH-2026-00091",
"warehouse": "WH-A",
"commodity": "Copper",
"quantity": 500,
"unit": "TON",
"status": "STORED",
"timestamp": 1788001234,
"source": "WMS-A",
"signature": "..."
}
关键不是“Oracle把数据放到链上”，而是：
谁有权提供数据？数据能否篡改？数据源之间是否能够交叉验证？发生争议时谁承担责任？
所以高质量RWA项目必须建立数据来源分级：
Level 1
核心企业签名数据
Level 2
银行/金融机构确认数据
Level 3
ERP/WMS/TMS系统数据
Level 4
第三方审计数据
Level 5
IoT / GPS / Sensor
Level 6
公开市场数据
不同资产应该采用不同的数据可信度模型。
十二、RWA并不意味着所有数据都上链
这是RWA架构设计中特别重要的一点。
供应链中存在大量商业敏感信息：
供应商价格；
客户名单；
采购量；
合同条款；
银行授信额度；
交易对手信息。
这些信息不适合全部公开写入区块链。
更合理的架构是：
┌───────────────┐
│ Blockchain │
│ │
│ Asset ID │
│ Ownership │
│ Hash │
│ State │
│ Proof │
└───────┬───────┘
│
Hash / Proof
│
▼
┌─────────────────┐
│ Off-chain Data │
│ │
│ Contract │
│ Invoice │
│ ERP Data │
│ Logistics │
└─────────────────┘
链上保存：
身份
状态
所有权
时间戳
哈希
交易记录
证明
链下保存：
合同
发票
物流
订单
财务数据
企业隐私数据
这比“所有东西上公链”更符合实际企业金融系统的要求。
十三、RWA与传统供应链金融系统应该如何融合
真正可以落地的系统不会推翻现有银行系统。
正确方式应该是：
Existing Financial Infrastructure
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Bank ERP Core
│ │ │
└─────────────────┼─────────────────┘
▼
RWA Middleware
│
┌──────────┴──────────┐
▼ ▼
Asset Registry Compliance
│ │
└──────────┬──────────┘
▼
RWA Network
│
┌──────────┼──────────┐
▼ ▼ ▼
Bank Factor Investor
因此，RWA不是“重新开发一套银行”。
它更像是一层：
连接现实资产、企业系统和金融基础设施的资产协议层。
十四、融资可以进一步变成“自动触发”
假设某供应商拥有：
应收账款：1,000,000元
融资比例：80%
融资期限：90天
年化利率：5%
传统流程：
提交申请
↓
人工审核
↓
确认资产
↓
授信
↓
签合同
↓
放款
RWA体系可以变成：
Asset Confirmed
↓
Risk Score >= Threshold
↓
No Existing Financing
↓
KYC Passed
↓
Loan Limit Available
↓
Smart Contract Execute
↓
80% Financing
更进一步，可以实现：
货物验收
↓
自动确权
↓
RWA发行
↓
自动融资
↓
核心企业付款
↓
自动偿还融资
↓
资产Token销毁/结清
这就是“可编程金融”的真正意义。
十五、DVP和DVR：RWA最值得关注的结算模式
传统交易经常存在：
A先付款
↓
等待B交付资产
或者：
B先交付
↓
等待A付款
双方都承担对手方风险。
Tokenisation可以实现条件同步执行。
例如：
IF
Asset Ownership Transfer == SUCCESS
AND
Payment == SUCCESS
THEN
Settlement = FINAL
即：
资产转移
↕
资金支付
两者形成原子化结算。
BIS近年来的Tokenisation研究持续强调原子结算、可编程性和DVP的价值；2026年的Project Agorá进一步展示了多币种Tokenised Central Bank Reserves与Tokenised Commercial Bank Deposits进行原子结算的可行性。([Bank for International Settlements][4])
这对跨境供应链金融尤其重要。
十六、法律问题比技术问题更重要
这是RWA供应链金融必须正视的问题。
假设链上存在：
Token #123
但法律上究竟意味着什么？
可能只是：
“某个平台数据库里的一个数字资产。”
也可能意味着：
“持有人依法享有某项应收账款债权。”
两者完全不是一个概念。
因此，RWA必须建立：
Token
↓
Legal Agreement
↓
Underlying Asset
↓
Claim
↓
Enforceable Right
如果链上Token和现实世界法律权利没有建立清晰映射，那么Token本身的金融价值非常有限。
十七、电子可转让记录是RWA的重要法律基础
这一点经常被技术团队忽略。
UNCITRAL《电子可转让记录示范法》（MLETR）提出了电子可转让记录的法律框架，其覆盖的典型场景包括提单、汇票、本票和仓单等。
它强调三个核心问题：
如何识别电子记录；
谁对电子记录拥有控制；
如何保证电子记录的完整性。
MLETR明确采取技术中立原则，并允许登记系统、Token和分布式账本等技术实现电子可转让记录。([联合国国际贸易法委员会][5])
这对于供应链金融非常重要。
因为供应链金融的底层资产恰恰大量来自：
应收账款
仓单
提单
票据
订单
贸易单据
如果法律体系不能承认数字记录对应的权利，那么技术层面的Token化很难真正完成金融资产的闭环。
十八、RWA供应链金融的风险模型
RWA不能简单理解成“区块链降低风险”。
它实际上会把风险重新分配。
可以建立如下风险矩阵：
风险 | 传统模式 | RWA模式 |
|---|---|---|
资产虚假 | 高 | 可降低，但无法消除 |
重复融资 | 高 | 可显著降低 |
对账风险 | 高 | 降低 |
数据篡改 | 中高 | 链上记录较强 |
Oracle错误 | 较低 | 新增 |
智能合约漏洞 | 无 | 新增 |
私钥风险 | 无 | 新增 |
法律执行风险 | 高 | 仍然存在 |
系统互操作 | 高 | 仍然存在 |
隐私泄露 | 中 | 设计不当可能升高 |
所以RWA不是：
“区块链把风险消灭了。”
而是：
把一部分传统操作风险降低，同时引入新的技术、治理和法律风险。
FSB和BIS近期研究也强调，Tokenisation目前规模仍有限，其效率、成本和流动性收益存在潜力，但同时伴随运营复杂性、流动性和监管不确定性等新的风险。([Bank for International Settlements][6])
十九、生产级RWA系统的技术架构
如果真正开发一套供应链RWA平台，可以采用类似下面的分层设计：
┌───────────────────────────────────────────┐
│ Application Layer │
│ Supplier │ Bank │ Factor │ Investor │
└─────────────────────┬─────────────────────┘
│
┌─────────────────────▼─────────────────────┐
│ Business Layer │
│ Financing │ Factoring │ Settlement │
│ Risk │ Compliance │ Asset Management │
└─────────────────────┬─────────────────────┘
│
┌─────────────────────▼─────────────────────┐
│ RWA Asset Layer │
│ Asset Registry │ Ownership │ Lifecycle │
│ Tokenization │ Transfer │ Encumbrance │
└─────────────────────┬─────────────────────┘
│
┌─────────────────────▼─────────────────────┐
│ Smart Contract Layer │
│ Permission │ State Machine │ Settlement │
│ Compliance │ Escrow │ Payment Rules │
└─────────────────────┬─────────────────────┘
│
┌─────────────────────▼─────────────────────┐
│ Oracle Layer │
│ ERP │ WMS │ TMS │ Invoice │ Market Data │
└─────────────────────┬─────────────────────┘
│
┌─────────────────────▼─────────────────────┐
│ Enterprise Systems │
│ ERP │ SCM │ Bank │ Payment │ Tax │ KYC │
└───────────────────────────────────────────┘
如果使用Go作为后端，可以进一步拆分成：
rwa-platform/
├── cmd/
│ ├── api/
│ ├── oracle/
│ ├── indexer/
│ └── settlement/
│
├── internal/
│ ├── asset/
│ ├── financing/
│ ├── compliance/
│ ├── oracle/
│ ├── settlement/
│ └── risk/
│
├── contract/
│ ├── Asset.sol
│ ├── Financing.sol
│ └── Settlement.sol
│
├── repository/
│ ├── mysql/
│ └── redis/
│
└── pkg/
├── crypto/
├── event/
└── signature/
核心事件可以设计成Event Sourcing：
type AssetEvent struct {
AssetID string
EventType string
Actor string
Timestamp int64
Payload []byte
Signature string
}
例如：
ASSET_CREATED
↓
ASSET_DELIVERED
↓
ASSET_ACCEPTED
↓
ASSET_CONFIRMED
↓
ASSET_TOKENIZED
↓
ASSET_FINANCED
↓
ASSET_SETTLED
这样做的好处是：
资产当前状态可以计算出来，同时完整保留历史状态变化。
二十、为什么RWA最适合“高价值、强确权”的供应链资产
并不是所有资产都适合Tokenization。
BIS提出的“tokenisation continuum”实际上指出，不同资产在法律、治理和技术方面的Tokenisation难度差异很大。越容易Token化的资产，新增价值可能越有限；真正高价值的场景往往也是法律和治理最复杂的场景。([Bank for International Settlements][1])
供应链金融应该优先选择：
高价值
+
强确权
+
稳定现金流
+
标准化程度高
+
数据可验证
+
法律关系清晰
例如：
第一阶段
核心企业已确认的应收账款。
第二阶段
仓单、标准化商品资产。
第三阶段
跨境贸易单据。
第四阶段
订单、未来应收账款等风险更高的资产。
不要一上来就Tokenize所有东西。
二十一、一个现实可行的RWA落地路线
企业如果准备实施RWA，建议不要从“发Token”开始。
正确顺序应该是：
第一阶段
资产数字化
↓
第二阶段
资产确权
↓
第三阶段
资产唯一标识
↓
第四阶段
资产状态机
↓
第五阶段
链上登记
↓
第六阶段
融资自动化
↓
第七阶段
资产流转
↓
第八阶段
自动结算
其中最重要的不是第六阶段，而是前面的：
资产标准化和确权。
如果现实世界的数据质量很差，那么上链只是把混乱的数据变成不可篡改的混乱数据。
二十二、RWA不会消灭银行，而会改变银行的角色
一个很容易出现的误解是：
RWA + 区块链 = 去银行化。
实际上更可能发生的是相反的情况。
银行依然需要承担：
KYC；
AML；
授信；
风险定价；
资本管理；
流动性管理；
合规审查；
最终结算；
违约处置。
技术改变的是银行获取和管理资产的方式。
传统银行：
企业
↓
材料
↓
人工审核
↓
授信
↓
放款
RWA银行：
企业
↓
实时资产数据
↓
资产状态
↓
风险引擎
↓
自动化授信
↓
可编程融资
银行从“人工处理大量材料”，逐渐向“管理数字化资产和风险”转变。
二十三、真正的终局不是“区块链供应链金融”
RWA最终可能推动的并不是简单的：
“把供应链金融搬到区块链。”
更大的变化是建立一个：
资产原生数字化的金融基础设施。
未来可能出现：
订单
↓
交付
↓
确权
↓
资产Token
↓
融资
↓
交易
↓
抵押
↓
再融资
↓
结算
整个生命周期由机器可读规则驱动。
一个资产从产生开始，就具有：
Identity
Ownership
Status
Valuation
Encumbrance
Financing
Settlement
金融机构不再需要每一次交易都从零开始验证资产。
这才是RWA最值得期待的地方。
二十四、结语：RWA真正解决的是“资产可信流转”
供应链金融过去最大的瓶颈，并不是“没有钱”。
而是：
金融机构很难低成本地确认资产、控制资产、跟踪资产并最终处置资产。
RWA提供了一种新的技术范式：
现实资产
↓
数字化确权
↓
唯一资产身份
↓
链上状态
↓
可编程规则
↓
融资
↓
流转
↓
自动结算
但必须看到，RWA不是一个简单的区块链项目。
它至少同时涉及：
金融、供应链、法律、数据、密码学、智能合约、身份认证、风控和支付结算。
其中最难的问题甚至不是Token怎么发行，而是：
Token到底代表什么法律权利？谁保证底层资产真实存在？谁负责Oracle数据？发生违约以后谁能够执行权利？不同机构之间如何互操作？
只有把这些问题解决，RWA才不会停留在“链上发资产”的概念验证阶段。
对于供应链金融而言，RWA最有价值的方向不是制造一个新的投机资产，而是把过去高度依赖人工、纸质凭证和机构间对账的资产融资流程，逐步变成一种：
资产可验证、权利可控制、状态可追踪、交易可编程、结算可自动执行的数字金融基础设施。
这也是RWA真正可能改变供应链金融的地方。
参考资料
Bank for International Settlements（BIS），The tokenisation continuum，BIS Bulletin No.72。([Bank for International Settlements][1])
Bank for International Settlements（BIS），Annual Economic Report 2026，关于Tokenisation、统一账本、原子结算及可编程金融基础设施的研究。([Bank for International Settlements][4])
United Nations Commission on International Trade Law（UNCITRAL），Model Law on Electronic Transferable Records (MLETR)，2017。([联合国国际贸易法委员会][5])
[1]: https://www.bis.org/publications/bulletin-72-tokenisation-continuum?utm_source=chatgpt.com "The tokenisation continuum"
[2]: https://www.bis.org/publications/aer-2025/next-generation-monetary-financial-system?utm_source=chatgpt.com "III. The next-generation monetary and financial system"
[3]: https://www.bis.org/publications/aer-2023/blueprint-future-monetary-system-improving-old-enabling-new?utm_source=chatgpt.com "III. Blueprint for the future monetary system: improving the old, enabling the new"
[4]: https://www.bis.org/publ/arpdf/ar2026e.pdf?utm_source=chatgpt.com "BIS Annual Economic Report 2026"
[5]: https://uncitral.un.org/en/texts/ecommerce/modellaw/electronic_transferable_records?utm_source=chatgpt.com "UNCITRAL Model Law on Electronic Transferable Records (2017) | United Nations Commission on International Trade Law"
[6]: https://www.bis.org/publications/fsi-summary-financial-stability-implications-tokenisation-executive-summary?utm_source=chatgpt.com "Financial stability implications of tokenisation - Executive Summary"