Travel Rule提供商集成

1）整合目标

• 维护规范的IVMS101模型，
• 具有不可知的Adapter层，
• 确保安全（mTLS、签名、加密）和SLA,
• 涵盖未托管的hosted↔hosted和政策。

2）选择协议/提供商： 型号

2.1协议和信任网络

TRISA/TRP/OpenVASP是具有PKI，VASP目录，交付确认的p2r/联邦。
商业中心/聚合器-抽象传输,给出Discovery和路由。

2.2选择标准（摘要）

司法管辖区/VASR，目录/发现质量。
与IVMS101和扩展兼容。
安全（PKI，mTLS，签名），latency/SLA，retrai/法定人数。
每条消息/范围，报告和审计的成本。
支持未托管的策略（地址所有权验证），sandbox和认证。

3）集成参考体系结构

1.Payments Core →启动加密转换。

2.Compliance Orchestrator →决定是否需要Travel Rule（阈值/地理/交易对手类型）。

3.Travel Rule Gateway（您的服务）

规范的IVMS101模型；

适用于TRISA/TRP/OpenVASP/聚合器的适配器；

签名/加密，等效性，retrai/配额。
4.目录/发现→寻找交易对手，验证证书/策略。
5.KYT/Sanctions引擎在交换之前→预检查。
6.PII Vault →个人字段存储，标记化，RBAC/审核。

1.创建申请→ 2） CUT/检查前制裁 → 3） Discovery VASP → 4） IVMS101交换（请求/反应）→ 5）决定allow/hold/reject → 6） Onchein broadcast → 7） Logi/报告。

4）规范数据模型（IVMS101）

• Originator: name, identifier, country/address or DOB, account/wallet id.
• Beneficiary: name (при VASP), account/wallet id.
• Transaction: asset, chain, amount, timestamp, internal transfer id.
• Compliance refs: KYT check id, sanctions screen id, Travel Rule message id.

实践：将IVMS101存储为其DB中的"canonical model"；适配器将转换为特定的协议。

5) Security & Trust

具有相互身份验证的mTLS（PKI/目录）。
消息签名和端到端内容加密（PII）。
RBAC/SoD：分离角色以发送/批准/导出数据。
日志/不变日志：谁/什么/何时发送,模式版本。

6) Discovery/Directory

通过VASP ID、域、LEI/BIC（可用）搜索对手。
记录缓存，证书轮换，受信任的CA列表。
后退通道：请求通过聚合器或"桥梁"确认道具（如果策略允许）。

7）流量管理和SLA

• Discovery + exchange p95: ≤ 60–120 с.
• Pre-KYT p95: ≤ 5–15 с.
• 自动桉例解决方桉：≤ 2-5分钟,手动高风险：≤ 4小时。

• 指数backoff+jitter；"travel_rule_message_id"上的等效性。
• 降级时自动转换到备用适配器/枢纽。
• 交付/阅读确认法定人数（ACK/NACK）。

8）错误处理（剧本）

9）未托管钱包政策

地址所有权证明（签名，"pruf micropreved"）。
入学前和退出前的KYT；分段限制。
Address 书籍/whitelist具有TTL和周期性重构。
记录RBA（小额/低风险）例外-这是合法的。

10） PII Vault和隐私

将PII与操作日志和支付数据分开。
加密（KMS/HSM），身份标记化，需要知情访问。
根据司法管辖区（通常为5岁以上），自动访问，DSR程序。
每个交换的IVMS101模式和审计路径的转换。

11）集成模式

11.1适配器层

接口：'send （ivms_payload）->ack'/'receive（）->ivms_payload'。
转型：IVMS101 ⇄特定格式（TRISA/TRP/OpenVASP/枢纽）。
API验证，签名的webhooks，确定性的重新发送。

11.2 Compliance解决方桉

Матрица RBA: `allow` / `limit` / `hold` / `reject` / `escalate`.

如果部分资金"清洁"，则部分发行。
与KYT的捆绑：不要在明显禁止的路线上发送Travel Rule。

11.3可靠性

通过单个Gateway提供两个或更多供应商/协议。
健康检查，巡回赛决胜局，实时差。

12）测试和调试

供应商的Sandbox+您的交易对手模拟器。
一组案例：完整/不完整的数据，时间表，错误记录，PKI不信任。
负载测试（高峰锦标赛/促销活动），计数p50/p95/损失。
Payments/Risk/支持培训：客户沟通脚本。

13）度量标准和dashbords

覆盖%：成功交换的VASP↔VASP转移份额。

SLA hit rate по Discovery/Exchange/Decision.

Retry/Failure rate, причины (timeout/mismatch/unsupported/trust).

Hold/Reject%和平均解锁时间。
根据Travel Rule, NPS输出的Complaint/Ticket rate。
按交换成本：提供者+歌剧。时间。

14）反模式

在Travel Rule完成之前，在需要"预转移"的地方发送。
一个没有适配器抽象的提供器的硬绑定。
将PII存储在通用逻辑/分析中而无需标记化。
缺乏相同性→信息/解决办法。
忽略未托管的策略和目标验证。
没有将电路/目录转换→"不可重复"的解决方案。

15） RFP/实施清单（简短）

• 支持IVMS101（强制/可选字段）、验证。
• 协议：TRISA/TRP/OpenVASP，聚合器；Discovery/Directory и PKI.
• 安全性：mTLS、签名/加密、活动日志、签名webhooks。
• SLA/retrai：p95目标，backoff+jitter，巡回决胜局，failover。
• 与KUT/制裁的兼容性，预检查API和案例联合。
• 无主机政策：地址确认,whitelist with TTL,限制。
• PII Vault：加密，RBAC/SoD，retention/DSR，审核。
• 报告：交换工件，电路/标签版本，SAR/STR导出。
• Sandbox/模拟器、负载和容错测试。
• 团队培训和客户沟通模式。

16）摘要

Travel Rule集成是一种网关体系结构，具有IVMS101作为规范模型，可信任的Discovery/PKI，多供应商适配器和严格的安全/PII规则。将她与KYT和RBA解决方桉联系起来,请输入未托管的政策,提供SLA/failover和透明的UX-您的加密付款/存款将满足您的要求,而不影响速度和转换。