®01
支付 HSM 与密钥管理
目标架构，含设备选型和迁移方案
了解更多
服务于您所在行业的从业者。
- 银行与储蓄银行
- 支付服务商与收单机构
- 保险公司与资产管理机构
- 金融科技公司与支付机构
您的重点领域
理解任务。设计方案。
我们集成符合 PCI DSS 的支付 HSM 与密钥管理，通过受控接口将核心银行系统与数字渠道及 PSD2 要求的第三方接入连接起来，并搭建用于实时欺诈检测的数据平台。
从战略到系统
六个服务模块
六大行动领域。您可以选择想要深入了解的方向。
01支付 HSM 与密钥管理Thales payShield 10K · Utimaco Atalla AT1000 · IBM Crypto Express 8S
我们的方法
支付 HSM 负责校验 PIN、加密卡数据并生成令牌，明文密钥始终不会离开设备。我们提供厂商中立的咨询，涵盖 payShield 10K、Atalla AT1000、IBM Crypto Express 和 Futurex Excrypt，在卡片个人化场景下也包括 Entrust nShield HSMi。我们规划设有角色、法定人数和记录的密钥仪式，并将设备接入卡处理、收单和令牌化流程。PCI DSS 和 PCI PIN Security 从一开始就融入架构、运维流程和审计文件之中。
服务范围详情
- 目标架构，包含设备选型、跨站点冗余，以及从 payShield 9000 等旧设备的迁移路径
- 针对 LMK、ZMK 和 BDK 的密钥仪式，设有角色划分、法定人数、见证人和记录模板
- 通过设备的主机接口，对接卡处理、收单、自动取款机网络和令牌化
- 使用 KeyBRIDGE、payShield Manager 或 KMES Series 3 进行密钥管理，密钥块依据 TR-31 标准
- 涵盖密钥轮换、固件版本、监控和灾难恢复的运维手册
一家卡处理机构用 payShield 10K 替换已停止支持的 payShield 9000；密钥仪式全程留有记录，切换时间也安排在结算批处理之外。
02核心银行系统集成与 PSD2 接口Berlin Group NextGenPSD2 · API 网关 · Apache Kafka
我们的方法
核心银行系统管理账户、记账和产品，任何变更都不允许导致系统停摆。我们在核心系统和各渠道之间建立一层带版本管理的集成层，使网上银行、App、支付平台和 PSD2 所要求的第三方接入，都在核心系统之外实现。每个接口都经过自动化测试、配有权限管理并留有记录。
服务范围详情
- 接口目录，包含数据契约、责任人，以及与核心银行系统的依赖关系
- 使用 API 网关和 Apache Kafka 进行事件处理，避免渠道直接查询核心系统
- 依据 Berlin Group NextGenPSD2 的 PSD2 接口，包含授权同意管理和第三方核验
- 为每个接口提供自动化测试、版本管理和审批流程，变更不会导致核心系统停摆
- 面向日常运维的监控、容量规划和书面变更流程
一家区域银行将其银行 App 迁移到一层集成层上；产品变更通过带版本管理的接口触达 App，核心系统无需占用维护窗口。
03基于数据和人工智能的欺诈检测Apache Kafka · Apache Flink · XGBoost
我们的方法
欺诈模式的变化速度快于固定规则集。我们构建数据平台，通过流式处理整合交易、客户和设备数据，并在此基础上训练模型，在支付执行前对每一笔交易进行评分。规则与模型协同工作，每一次判断都可解释并留有记录，供客服、合规部门和监管机构核查。
服务范围详情
- 流处理平台，对接支付系统、客户档案、设备数据和制裁名单
- 结合规则集的评分模型，以历史欺诈案例和误报率进行验证
- 每一次判断都具备可解释性，供客服、合规部门和投诉处理使用
- 模型运维具备版本管理、数据漂移监测和受控的重新训练
- 依据欧盟《人工智能法案》和 GDPR 进行文档记录，包括系统分级和数据主体权利
一家支付服务商根据设备、商户类别和以往行为评估来自新国家的银行卡支付，而不是一概予以拦截；误报和投诉因此减少。
04DORA 韧性与第三方管控SIEM · OPSWAT · TIBER-EU
我们的方法
DORA 要求建立经过检验的 ICT 风险管理、事件报告流程、定期韧性测试，以及涵盖所有 ICT 服务商的信息登记册。我们梳理风险和依赖关系，建立检测、报告渠道和测试计划，并将服务商合同调整至法规所要求的水平。对于我们自身提供的服务，我们同样提供审计权、服务绩效指标和退出方案。
服务范围详情
- ICT 风险分析，绘制涵盖核心系统、支付渠道和服务商的依赖关系图
- 依据 DORA 要求的安全监控和事件响应，配有报告流程
- 从场景演练到依据 TIBER-EU 的威胁情报驱动渗透测试的韧性测试
- ICT 服务商信息登记册，核查合同中的审计权、绩效指标和退出条款
- 应急和恢复方案，配有留存记录的测试和结果报告
一家保险公司将合同、配置管理数据库（CMDB）和采购信息整合为统一的信息登记册；在下一次监管问询之前，关键服务商已签订带审计权和退出方案的合同补充协议。
05身份识别与客户身份验证FIDO2 与 Passkey · OpenID Connect · SAML
我们的方法
PSD2 要求采用两种独立因素进行强客户身份验证，监管机构对员工和管理员也提出同样的要求。我们将 Passkey、FIDO2、智能卡和签名机制集成到银行 App、网上银行和后台系统中，通过 OpenID Connect 对接身份提供方，并按双人复核原则管理 HSM 和核心系统的特权访问。登录记录会被留存，并作为信号输入欺诈检测系统。
服务范围详情
- 依据 PSD2 及强客户身份验证监管技术标准（RTS）制定的身份验证方案，包括例外情形和动态关联
- 在银行 App 和网上银行中使用 Passkey 和 FIDO2，为员工配备智能卡和令牌
- 通过 OpenID Connect 和 SAML 对接身份提供方，角色信息来自目录服务
- 针对 HSM 管理、核心银行系统访问和应急账户的特权访问管理
- 对登录进行记录和分析，供欺诈检测和审计人员使用
一家直销银行用 App 中的 Passkey 取代短信 TAN；转账的确认按照 PSD2 的要求，与金额和收款人动态绑定。
06面向支付和 PKI 的后量子密码就绪ML-KEM (FIPS 203) · ML-DSA (FIPS 204) · 混合证书
我们的方法
高性能量子计算机将破解 RSA 和椭圆曲线算法，而银行卡支付、网上银行和内部 PKI 目前都依赖这些算法。我们对支付 HSM、核心系统和各渠道中使用的密码学方法、密钥和证书进行盘点，评估设备的迁移能力，并分阶段规划向 ML-KEM 和 ML-DSA 的迁移。现有的支付 HSM 并非每一台都支持新算法，因此路线图从硬件层面开始规划。
服务范围详情
- 涵盖 HSM、PKI、TLS、签名和银行卡应用的密码资产清单，按数据保护期限进行评估
- 检查支付 HSM 和通用 HSM 的固件是否支持 ML-KEM、ML-DSA 和混合方案
- 在集成层实现密码敏捷性，使算法无需改动应用即可切换
- 针对内部 PKI、根 CA 和签发 CA 的混合证书和迁移方案
- 分阶段路线图，按数据保护期限和设备使用年限设定优先级
一家支付机构对 HSM、PKI 和接口建立了清单；内部 PKI 率先切换到混合证书，支付 HSM 则随下一次设备更换跟进。
典型项目场景
变革真正落地之处。
项目往往始于一个具体的挑战。以下示例将典型的现状、可能的解决思路和期望达成的结果结合在一起。
示例性现状说明，并非客户案例。
01 / 金融行业
某卡处理机构的 HSM 迁移
多代支付 HSM 并存，厂商已宣布停止支持，密钥仪式只有部分留有记录。
解决方案
制定包含设备选型的目标架构，为所有密钥类型建立留有记录的密钥仪式，切换安排在结算批处理之外进行。
经过认证的设备已投入运行，具备完整的 PCI 审计文件，并为自有团队提供了运维手册。
02 / 金融行业
某区域银行的新银行 App
App 直接访问核心系统，每次发布都需要维护窗口，PSD2 的接入通过一家缺乏透明度的服务商进行。
解决方案
建立带接口目录的集成层和 API 网关，依据 Berlin Group 标准自主运维 PSD2 接口。
发布不再需要占用核心系统的维护窗口，接口带版本管理并经过测试，同时具备供监管机构使用的证明材料。
03 / 金融行业
某保险公司的 DORA 合规落地
信息登记册并不完整，合同中没有约定审计权，韧性测试也没有留下结果文档。
解决方案
开展带依赖关系图的风险分析，为关键服务商签订合同补充协议，并建立带报告的测试计划。
具备了向监管机构说明情况的能力，测试留有文档记录，报告流程已投入日常运行。
协作
清晰的路径。与您的团队同行。
从初步了解情况到日常运维：我们会共同商定各阶段的优先事项、职责分工和成果。
我们的工作方式
- 01
评估
支付流程、核心系统、接口和合规差距
按优先级排序的措施清单、密码资产清单，针对 DORA 和 PCI 的差距分析 - 02
方案
目标架构、安全措施、运维模式
目标架构、设备选型、接口目录、运维模式、测试方案 - 03
实施
分阶段实施 HSM、接口和数据平台
完成集成的系统、留有记录的密钥仪式、测试、文档，以及每个阶段的审批 - 04
运维
监控、审计、知识转移
监控、密钥轮换、审计协助，以及分阶段移交
- 01
您希望改变什么？
当前面临的挑战，以及您期望达成的结果。
- 02
涉及哪些系统？
站点、应用和接口的概览。
- 03
有哪些约束条件？
项目时间安排、维护窗口和已知的依赖关系。
- 04
哪些人需要参与？
来自 IT、安全和运维部门的合适联系人。
背景与决策参考
什么是面向银行与金融服务机构的 IT 解决方案？
六大行动领域，从支付 HSM 到后量子密码学，由 OTOKO® 规划、集成并运维。每一次变更都能向监管机构和审计人员出示证明。整套解决方案均在德国数据中心运行。
面向银行与金融服务机构的 IT 解决方案，通过密码学手段保护支付安全，在不中断运行的情况下持续改造原有的核心银行系统，并就每一次变更向监管机构提供证明。OTOKO® 为此涵盖六大行动领域：支付 HSM 与密钥管理，核心银行系统集成与 PSD2 接口，基于数据和人工智能的欺诈检测，DORA 韧性与第三方管控，身份识别与客户身份验证，以及面向支付和 PKI 的后量子密码就绪。
与单纯的咨询项目相比，我们的不同之处在于运维和证明材料。每一次密钥仪式、每个接口和每个模型都配有记录、版本状态，以及 DORA、PCI DSS 和监管机构所要求的文件。密码学和硬件安全模块是我们的核心能力，因此 PIN 密钥、卡片密钥和证书都存放在经过认证的设备中，而不是以软件形式存放。
为什么选择 OTOKO® 服务银行与金融服务机构
- 密码学与 HSM
密码学和硬件安全模块是我们的核心能力。我们按照 PCI PIN Security 和各卡组织的要求，规划并运维支付 HSM、密钥仪式和 PKI。
- 德国数据中心
整套解决方案都在德国数据中心运行，从支付 HSM 到欺诈检测数据平台。
- 关键基础设施（KRITIS）与受监管行业
我们与关键基础设施运营方和受监管行业合作。我们熟悉金融行业监管机构、审计人员、信息安全部门和合规部门的期望。
- 同一团队负责到运维
同一个团队为您提供从咨询到运维的全程支持。密码学专家、集成开发人员和数据工程师全程参与，不会转交给第三方。
框架条件与详情
金融行业项目启动前的典型现状
大多数机构的问题并不在于缺乏技术，而在于历史遗留问题、证明材料的缺口，以及监管带来的时间压力。
01
没有路线图的支付 HSM
多代设备并行运行，密钥仪式只有部分留有记录，厂商支持也即将到期。
02
没有接口目录的核心系统
各渠道直接访问核心银行系统，没有人清楚全部的依赖关系，每次变更都需要占用周末的维护窗口。
03
滞后的欺诈检测
固定的规则集只能在交易执行之后才进行评估，误报占用大量客服资源，新的欺诈模式也要很晚才被发现。
04
停留在纸面上的 DORA 合规
信息登记册并不完整，服务商合同中没有约定审计权，韧性测试也没有留下结果文档。
三种运维模式
| 本地部署 | 德国云 | 超大规模云服务商 | |
|---|---|---|---|
| 数据存储 | 您的数据中心，您的 HSM 和核心系统 | 德国数据中心，依据 ISO 27001 运营 | Azure、AWS 或 Google Cloud，可选择区域 |
| 运维 | 您的团队，或由 OTOKO® 以托管服务形式运维 | 由 OTOKO® 运维，您的机构享有依据 DORA 的审计权 | 共同承担，平台服务由云服务商提供 |
| 工具 | 本地部署 payShield、Atalla 或 Crypto Express，Kafka、Kubernetes | 支付 HSM 即服务，托管的集成和数据平台 | payShield Cloud HSM、云 HSM 服务、托管数据服务 |
| 适用于 | PIN 处理、核心银行系统、密钥保管 | 对主权和审计权有需求的受监管机构 | 各类渠道、分析业务，以及应对负载高峰的弹性扩展 |
| 合规 | 完全掌控，证明材料来自您的 ISMS 和 PCI 合规范围 | 依据 GDPR 签订数据处理协议、DORA 合同条款，地点位于德国 | 数据处理协议、标准合同条款，以及按服务制定的退出方案 |
合作方式
项目
边界清晰的项目，例如 HSM 迁移或 PSD2 接口建设，具有明确的成果、里程碑和验收。
- 评估、方案、实施、移交
- 固定价格，或按里程碑以实际工作量计费
- 适用于设备更换、新渠道建设和审计准备
团队扩充
密码学专家、集成开发人员或数据工程师加入您的团队，使用您的工具和审批流程。
- 熟悉您的流程、系统和审计要求
- 可随项目进展灵活调整规模
- 适用于拥有自有团队、但存在人力缺口的机构
托管服务
OTOKO® 按约定的服务水平和报告要求，运维 HSM、集成层或数据平台，并提供 DORA 对第三方所要求的合同条款。
- 监控、密钥轮换、更新和支持
- 合同中约定审计权、服务绩效指标和退出方案
- 适用于没有自有团队运维 HSM 或平台的机构
标准与证明材料
金融行业各项要求的内容，以及 OTOKO® 为此提供的交付物。
| 标准项 | 要求 | OTOKO® 提供 |
|---|---|---|
| DORA | ICT 风险管理、重大事件报告、韧性测试、信息登记册，以及对 ICT 第三方服务商的合同管控 | 风险登记册、报告流程、测试计划、信息登记册，以及约定审计权、绩效指标和退出方案的合同 |
| PCI DSS | 通过网络分段、加密、访问控制、日志记录和定期审查来保护持卡人数据 | 合规范围界定、基于 HSM 的加密和密钥管理、日志记录，以及供 QSA 审计和 SAQ 自评使用的文件 |
| PCI PIN Security | PIN 处理只能在经过认证的 HSM 中进行，使用密钥块，密钥仪式留有记录，角色和保管相分离 | 依据 PCI PTS HSM 的支付 HSM、密钥仪式记录、依据 TR-31 的密钥块、角色方案，以及密钥保管证明材料 |
| PSD2 | 强客户身份验证、动态关联、面向第三方的接口，以及重大安全事件报告 | 身份验证方案、Passkey 和 FIDO2、依据 Berlin Group 标准的 PSD2 接口，以及针对监管技术标准（RTS）的证明材料 |
| GDPR | 合法性依据、数据最小化、数据主体权利、数据处理协议，以及针对画像分析的数据保护影响评估 | 面向欺诈模型的数据保护方案、假名化处理、删除方案、数据处理协议，以及协助完成影响评估 |
常见问题
好问题。清晰的答案。
15 条解答，涵盖您的行业、项目以及后续运维。
行业与行动领域6 问题
OTOKO® 为银行与金融服务机构提供哪些 IT 解决方案？
服务内容包括依据 PCI DSS 的支付 HSM 与密钥管理、核心银行系统与数字渠道的集成、面向欺诈检测的数据平台、DORA 合规落地、依据 PSD2 的客户身份验证，以及后量子密码就绪。每个行动领域都可以单独委托，也可以打包委托，均在德国数据中心运行。
OTOKO® 如何协助落实 DORA 合规？
我们梳理您的 ICT 风险，将系统和服务商记录在信息登记册中，并建立报告流程和韧性测试。对于我们自身提供的服务，我们同样提供约定审计权、服务绩效指标和退出方案的合同，正如 DORA 对第三方服务商的要求。这样，您的机构就能随时向监管机构说明情况。
现有的支付 HSM 能否继续使用？
通常可以。我们会检查固件版本、PCI 认证情况和厂商支持状态，只有在设备即将停止支持，或已无法满足后量子密码学等新要求时，才会规划更换。迁移过程会配有留存记录的密钥仪式和事先规划的切换窗口。我们与关键基础设施运营方和受监管行业合作，在那里，这套做法已是标准流程。
在新增渠道的情况下，核心银行系统如何保持稳定？
各渠道并不直接访问核心系统，而是访问一层带版本管理的接口和数据契约的集成层。App 或网上银行的变更只影响这一层，每个接口在发布前都会经过自动化测试。核心系统由此保留了自己的维护窗口，也仍然可以接受审计。
基于人工智能的欺诈检测是否符合 GDPR 和欧盟《人工智能法案》的要求？
是的，前提是从一开始就按此要求进行构建。每一次判断都可解释并留有记录，个人数据在应用场景允许的情况下会进行假名化处理，系统也依据欧盟《人工智能法案》完成清点和分级。借助判断记录，投诉案例可以被追溯，并向客户和监管机构说明依据。
我们应该何时开始部署后量子密码学？
现在就该开始，先从清点做起。卡数据和合同的保护期限，往往超过预计出现高性能量子计算机的时间，而支付业务中的设备更换又需要数年的提前规划。清点结果会显示哪些 HSM、证书和接口需要优先迁移，路线图则把迁移与本来就要进行的设备更新结合起来。
启动与实施5 问题
我们可以从单一行动领域开始吗？
可以。我们可以先界定一项具体任务，同时关注它与其余基础设施之间的接口，并在实施前明确哪些服务属于委托范围。
我们应该为初步沟通准备什么？
起步时，只需简要说明面临的挑战、涉及的系统以及您期望达成的结果即可。已知的时间节点和合适的联系人也会有所帮助。访问凭证或机密的系统文档不应包含在首次咨询中。
谁应该参与该项目？
安全架构师: 目标架构、HSM 方案、证明材料. 密码学专家: 密钥仪式、HSM 集成、PQC 路线图. 集成开发人员: 接口、API 网关、核心银行系统适配器. 数据工程师: 流处理平台、欺诈模型、监控. 合规顾问: DORA、PCI、PSD2、审计文件. 项目负责人: 里程碑、验收、报告.
时间计划和工作量是如何确定的？
我们会综合考察系统、接口、文档现状和运维方面的约束条件。经过协商确定的范围和里程碑，构成工作量评估的基础。缺少这些信息而给出的固定工期是不可靠的。
项目第一阶段会交付什么？
支付流程、核心系统、接口和合规差距 按优先级排序的措施清单、密码资产清单，针对 DORA 和 PCI 的差距分析
运维与持续完善4 问题
有哪些可能的合作方式？
项目: 边界清晰的项目，例如 HSM 迁移或 PSD2 接口建设，具有明确的成果、里程碑和验收。 团队扩充: 密码学专家、集成开发人员或数据工程师加入您的团队，使用您的工具和审批流程。 托管服务: OTOKO® 按约定的服务水平和报告要求，运维 HSM、集成层或数据平台，并提供 DORA 对第三方所要求的合同条款。
如何完成向运维的移交？
监控、审计、知识转移 监控、密钥轮换、审计协助，以及分阶段移交
我们之后可以再补充其他站点或系统吗？
这一点可以在最初的方案中予以考虑。有文档记录的接口和可复用的规则，为后续扩展打下基础。不过，每新增一个站点或系统，仍会针对其特殊需求单独进行评估。
该方案如何保持长期可运维？
职责分工、周期性任务和变更流程，会与技术实施一并确定。文档记录和知识转移有助于您的团队开展日常工作。具体包含哪些工作内容和持续支持，会在服务范围中明确约定。
金融行业
让我们一起探讨下一步。
让我们共同梳理，支付安全、核心系统集成与欺诈检测如何在您的机构中协同运作。
预约初步沟通
