问一家新的外汇经纪商，KYC 怎么做，得到的答案通常是三步：客户上传护照，验证服务商返回通过，运营人员点一下”批准”。这描述的是身份验证，不是开户流程。
一个客户可以顺利通过证件核验，同时仍然是你不能接受的客户——所在国家不属于持牌实体的可承接范围、客户分类不匹配所申请的产品、付款通道不可用、杠杆档位超出许可。”这本护照是真的”只回答了八个问题中的一个。
2026 年 8 月，ASIC 公布了当年 3 月至 6 月对九家网上经纪商的检查结果。其中包括：开户问卷未充分结合客户实际情况，以及部分系统允许客户重复甚至无限次尝试通过。ASIC 同时指出，复杂或高风险产品的治理不能在开户完成后停止，而应贯穿整个客户关系存续期间。ASIC 按主题汇总公布检查结果，并不表示每项问题都存在于全部九家机构。
这些是澳大利亚的规则，不能直接套用到其他司法辖区。但其中的运营教训是通用的：证件验证、客户评估、审批和账户开立，不能是四套彼此断开的系统。
开户流程必须回答的八个问题
在客户拿到实盘账户之前，系统里必须有依据能回答以下每一项：
- 申请人是否确为本人？
- 从 AML 和制裁角度，能否与其建立业务关系？
- 客户是否有资格使用所申请的产品？
- 应由哪个法律实体承接？
- 适用哪份协议和风险披露？
- 分配哪个服务器、账户类型和权限？
- 能否入金、交易、出金，限额多少？
- 哪些后续事件应触发重新审核？
这些问题彼此相关，但不能互相替代。通过身份验证，不代表制裁风险已被排查；通过制裁筛查，不代表客户理解强制平仓；开户流程走完，也不代表所有品种和杠杆档位都应同时开放。
在多数经纪商架构中，CRM 应作为客户状态的主要协调系统，或至少与合规案件系统共同维护唯一、明确的状态来源。交易平台负责执行该状态对应的账户配置。把这条边界划清楚，架构工作就完成了一大半。
第一步：先把数据结构化，再去用它
开户从上传护照之前就开始了。客户门户先生成 Client ID，并采集后续规则真正会读取的字段——居住国家、国籍、税务居民身份、职业、资金来源、预计入金规模、已接受的协议与授权记录。
这一步的错误几乎永远是同一个：居住国家、资金来源、所属实体被记成自由文本，或者更糟，只写在客服的备注栏里。下游任何规则都用不上它。司法辖区规则读不懂”客户说他去年搬去迪拜了”，它只认国家代码，否则就不会执行。
同一名客户还必须在四套各自生成编号的系统之间保持可识别：CRM、KYC 服务商、支付服务商、交易服务器。一个主 Client ID，逐一显式映射。
采集范围以合规框架的要求为准，不要多收。每多一个字段，就多一份保存义务和一份泄露风险敞口。
身份验证：真正要设计的是”结果不明确”的那部分
证件真伪、机读码或芯片读取、有效期校验、人脸比对、活体检测、重复身份识别——结果清晰的申请，自动化处理得很好。
需要设计的是不清晰的那些。证件反光、姓名转写与拉丁字段对不上、芯片损坏、合法改名，这些情况并不必然代表欺诈，也不应在没有区分原因的情况下统一作为最终拒绝处理。状态模型必须超出”通过/不通过”两档，至少还要有：无法确认、需要补充资料、需要人工审核。
人工审核是控制最容易悄悄失效的地方。如果复核人员不需要权限校验、不需要填写原因、不留审计记录就能把案件改成通过，那就不是控制，只是习惯。高风险例外应当要求第二人批准。
地址证明带出的是另一个问题：一致性。CRM 里申报的地址、水电账单上的地址、付款工具对应的国家、IP 讯号，四者不会总是一致。先做地址标准化，消除缩写和转写造成的误报，剩下的差异建立审核任务。任何情况下都不要让一个数据源无声地覆盖另一个。
AML 筛查是另一个问题，需要另一套答案
身份验证解决”客户是谁”。AML 解决的是”该不该跟他做生意”——制裁名单、PEP 身份、负面新闻、地域风险、资金与财富来源、预期账户活动，以及风险评级要求时的强化尽职调查。
对公司客户，只比对公司名称通常不够。董事、授权代表、股东、实际控制人和最终受益所有人，可能各自都需要单独识别、验证和筛查。
筛查结果不是二元的。同名命中可能需要进一步确认身份及匹配依据；PEP 命中是尽职调查的触发条件，不是自动拒绝的理由。所以系统需要的是案件管理、证据附件、分级审批和有记录的最终决定，而不是一个通过/失败的标记。
而且筛查必须重复执行。制裁名单会更新，客户会成为政治公众人物，股权结构会变动——开户当天的一次性检查看不到任何一项。真正的控制应覆盖开户后的持续或重复筛查；具体采用持续筛查、定期重筛还是事件触发复核，应根据适用规则和经纪商的风险政策决定。开户时的检查只是第一轮。
产品评估：ASIC 查出问题的地方
适当性、适合性、目标市场认定，在不同监管体系下是不同义务。把它们当成同一件事，正是经纪商会对错误的客户适用错误测试的原因。具体哪一项适用于哪个实体，由法律顾问判断。
可以通用的是 ASIC 描述的失效模式。如果同一份问卷可以无限次重做，问卷测的就是耐心而不是理解程度。随着尝试次数增加，通过率可能被人为推高，这份评估作为客户理解程度证据的价值也会明显下降。
可落地的对策有几种：限制即时重试次数、轮换题库、设置重考冷静期、多次失败转人工复核，或者限制产品权限而不是直接拒绝申请。
无论采用哪种政策，CRM 都必须保存问卷版本、客户答案、得分、尝试次数、时间戳和任何人工干预记录。两年之后，能说明客户当时接受了什么评估、为什么被放行的，只有这份记录。
风险评级与分流：一个决定，多个后果
风险评级把开户数据转化成可执行的东西——审批层级、所需证据、监控强度、复核频率、账户限制。无论用什么模型，合规人员必须能解释输出结果。拆解不开的评分，撑不过一次审计。
分流做的是另一件事。对跨境集团而言，客户居住地、所在地区、客户分类及申请产品等因素，共同决定哪个法律实体可以与其签约，其余配置由此顺延：
客户所在地与身份 → 法律实体 → 协议与披露 → 付款路径 → 交易环境 → 账户权限
有些国家完全禁止承接，有些需要强化尽职调查或人工批准。规则本身来自法律与合规部门；技术侧的要求是：版本可追踪、结果可测试、相同情形处理一致。
这里有一项控制比其他都重要：销售人员不应能够绕过获批准的合规流程，把客户转移到另一个法律实体。只要 CRM 里存在这条路径，分流矩阵就只是摆设。
账户激活：把决定变成配置
只有在强制检查全部达到可接受状态后，客户才应拿到实盘账户。受控的开户流程是这样的：
- CRM 确认所有强制检查已通过；
- 合规层确定法律实体与允许的产品；
- 账户规则确定交易环境、账户类型、基础货币与权限；
- 获授权的集成服务发出账户创建请求；
- 交易平台返回账户编号；
- CRM 保存客户—实体—账户的映射关系；
- 通过已批准的安全渠道下发登录资料。
注意这份清单里没有的东西：一个人在下拉框里手动挑选设置。
有账户也不等于所有功能都开放。注册待完成、KYC 审核中、合规复核中、已批准未激活、已开放交易、限制入金、限制出金、账户暂停、账户关闭——这些是含义各不相同的状态，应当作为显式值存在 CRM 里。员工绝不应该靠”客户有没有平台登录账号”来推断其合规状态。
这一步在 MT5 上怎么落地
对使用 MT5 的经纪商来说，交易平台是执行层，不是决策层：
CRM → 合规批准 → 账户配置服务 → MT5 账户 → Group 与权限
集成服务根据已批准的配置创建 MT5 账户，并分配 Group、基础货币、杠杆及相应权限。法律实体、IB 关系和内部 Client ID 等信息，则应根据具体架构在 CRM、集成层与 MT5 账户之间建立映射。实际可用字段和接口取决于经纪商的 MT5 环境及集成设计。
Group 分配应当来自经批准的规则表，键值为法律实体、客户分类、账户类型、货币、杠杆和定价模式，而不是靠运营人员记住命名规则。LIVE-EU-RETAIL-USD-30、LIVE-OFFSHORE-STD-USD-500 这类名称只是说明结构用的示例，正式命名应符合自身架构，并避免向客户暴露内部信息。
人工修改 Group 不必完全禁止，但必须要求权限、填写原因、记录修改前后的值。Group 错配可能造成杠杆、品种或隔夜利息设置错误，也可能让客户落在一套他从未被批准的实体配置下。
同一客户持有多个交易账户时，每个账户都必须挂在同一份客户主档下。这是客户层面的限制能够覆盖名下全部账户的前提。
账户激活之后，流程还在跑
付款是合规界面，不只是结算界面。第三方入金、银行所在国与申报居住地不符、入金金额明显超出申报档位、出金目的地突然变更——每一项都应按照既定规则触发预警、补充验证或合规案件，而不能只停留在支付服务商后台。支付服务商返回”成功”是付款结果，不是 AML 判断。
持续监控关注的是：新增制裁或 PEP 命中、身份证件到期、居住地或税务居民身份变化、股权与控制权变动、与客户申报档案不符的活动。需要注意的是，AML 交易监控与产品治理监控在概念上要分开：ASIC 2026 年针对 CFD 的工作聚焦的是产品设计与分销义务下的客户交易结果，即使读取的是同一批数据，也不等同于制裁筛查。
预警必须有预设处理动作——要求补充资料、建立案件、限制入金、限制新增交易或将账户转为只平仓模式、暂缓出金待审、调整产品权限、启动强化尽职调查，或终止客户关系。自动限制功能要充分测试：一条在客户持仓中途误拦正常账户的规则，制造的麻烦不比它解决的少。
复核周期应以风险为本，但时间不能是唯一触发条件。居住地址重大变更、税务居民身份变化、异常大额入金、最终受益所有权变动、制裁预警，或开户时所用证件到期，都应触发复核；复核期间账户能否继续交易，由既定政策决定，不由销售或客服临时判断。
故障处理与审计追踪
能不能扛过第一次审计，主要看两件事。
第一件是接口不响应时会发生什么。KYC 服务商超时，申请应进入可恢复的待处理状态，而不是默认放行去创建实盘账户。账户创建请求要具备幂等性，重试不能产生重复账户。失败任务进入运营队列，配预警和对账机制，而不是丢进一份没人看的日志。
第二件是复核人员能否在不问当事员工的情况下还原一个决定。谁批准了这个客户、什么时候、依据哪些证据、对应哪个版本的问卷、尝试了几次、为什么分到这个实体、为什么给这个杠杆、创建了哪个账户和 Group、之后谁改过配置、改动前后的值分别是什么。日志能回答这些，审计就是一次调取；答不上来，审计就变成调查。
日志要做访问控制、防篡改保护；也不要为了图方便把敏感证件复制到每一个关联系统。对一份主档做受控访问，比五份不受控的副本安全得多。
上线前该测什么
要测的是失败路径，不是顺利路径。重点包括：过期与无法读取的证件、人脸比对与活体检测失败、潜在制裁命中与 PEP 结果、问卷失败与重复尝试、禁止承接国家、实体分流、MT5 开户接口超时、重复 API 请求、Group 与杠杆分配、第三方入金、出金到新目的账户、证件到期、定期复核、限制与解除、账户关闭，以及完整还原审计记录。全程使用受控的非生产数据。
然后落实责任人。验证失败、服务商故障、可疑付款、Group 错配、逾期复核，都得有人负责。没有归属的例外会变成积压，积压最终会变成审计发现。
EBS FinTech 负责哪一部分
EBS FinTech 负责基础设施与集成层：CRM 与客户门户集成、KYC 服务商 API 对接、账户激活流程、MT5 账户自动创建、基于规则的 Group 分配、杠杆与产品权限逻辑、支付系统集成、重试与对账设计、服务器托管与运营预警。
我们不取代经纪商的律师和合规职能。哪些客户可以接受、需要什么证据、适用哪些限制，由他们判断。我们的工作，是把这些已经确认的决定，变成一套每个状态都有明确含义、每个例外都有负责人、每项权限都能追溯到一条经批准的规则、每个决定日后都能完整还原的技术流程——在第一万个客户身上的表现，和第一个客户完全一致。
正在规划新的外汇或 CFD 经纪商系统，或者想重新检查已经上线的开户架构？EBS FinTech 可以协助梳理从客户注册到交易账户受控激活的完整技术流程。
