基于开放金融构建：创始人关于同意、牌照与分销的行动手册

1. 构建受监管的信任型产品

开放金融应设计为受监管的信任型产品。产品承诺取决于客户是否理解哪些数据将流转、由谁接收、将提供何种服务，以及授权如何撤回。技术承诺取决于身份、认证、授权、安全通信、数据完整性和服务可用性。商业承诺取决于可衡量的客户价值、可行的渠道，以及能够覆盖合作伙伴费用、数据成本、合规和支持成本的经济模型。

创始人应先界定客户任务，再选择API或牌照路径。该任务可能是为小企业进行现金流预测、为贷款机构提供可负担性证明、为家族办公室进行账户聚合、为市场平台发起支付，或为保险公司提供续保洞察。每项任务都应明确用户、决策、所需数据、允许用途、输出、频率和负责提供方。这可以防止架构沦为缺乏运营决策的数据源集合。

董事会应批准一项包含五个相互关联论证的产品论点。客户论证证明存在具有重大影响的问题，并且数据能够支持有效决策。边界论证将每项活动映射到实体、国家、牌照、豁免或受监管合作伙伴。同意论证证明目的、范围、身份验证、续期和撤回。交付论证证明数据质量、韧性、投诉处理和记录留存。经济论证证明收入、获客、合作伙伴成本、服务成本、损失敞口和现金跑道。

CBUAE 将开放金融描述为以同意为驱动、数据丰富、协作、安全且以客户为中心。其框架包括数据共享和服务发起。这一范围使创始人的产品定义成为监管设计的输入。决策记录应识别哪个组成部分属于受监管金融服务、哪个属于技术服务，以及由哪一方作出客户承诺。

客户价值、监管许可、同意、交付和经济性作为一个由董事会控制的系统协同运作。

2. 在构建之前梳理活动、实体和司法管辖区

牌照边界取决于法律实体在特定司法管辖区开展的活动。财务健康、承保洞察或嵌入式财资管理等产品标签并不能回答边界问题。该映射应将服务分解为数据收集、数据共享、账户信息、分析、建议、安排、贷款、保险分销、支付发起、托管、客户资金处理及外包技术。

对于每项活动，创始人应记录执行实体、客户所在地、数据持有方所在地、受监管交易对手、合同角色和面向客户的表述。该映射应显示谁接收数据、谁决定目的、谁作出财务决策、谁发起交易、谁处理投诉以及谁承担责任。跨境交付可能形成多个相互关联的边界。

《UAE 开放金融条例》规定，任何法人除非被视为持牌，否则不得在未持有开放金融牌照的情况下在UAE提供开放金融服务。申请必须明确申请人寻求的是数据共享权限还是服务发起权限。规则手册还定义了技术服务提供商，但技术标签并不能证明某项活动不受牌照监管。具备资质的UAE律师应确认拟议结构。

沙特阿拉伯的框架结合了业务规则、客户体验指南、API规范、运营指南、测试与认证。SAMA 宣布在沙盒阶段结束后开始向提供开放银行服务的金融科技公司发放牌照。在英国，开放银行服务以及关联支付、信贷、咨询或保险活动可能涉及不同的监管许可。创始人在确定产品架构或上线日期之前，应取得书面意见，并在适当情况下与监管机构沟通。

表 1. 活动与牌照边界登记表

官方规则确立起点；合格顾问应确认具体实体、活动和司法管辖区。

3. 将同意视为生命周期

同意界面只是更长控制体系中的一个环节。生命周期始于产品说明服务、数据、接收方、目的和期限之时。它贯穿身份核验、身份验证、授权信息记录、数据请求、使用、续期、修改、撤销、删除、投诉和审计。同意记录应与每一项下游使用相关联。

CBUAE框架包含同意与授权管理器，支持隐私指令的创建、管理、执行和撤销。其《开放金融条例》要求明示同意、适当身份验证和安全通信。印度提供了有用的操作规范：账户聚合器指令要求标准化的同意凭证，包含客户身份、所请求的金融信息、目的、接收方、通知地址、创建和到期详情，以及账户聚合器的身份和签名。该框架还要求具备撤销功能，以及可记录、审计和核验的电子凭证。

创始人应创建权限对象，而不是静态的接受标记。该对象应包含用户及授权身份、服务、数据类别、账户或产品、数据持有方、接收方、目的、使用频率、开始时间、到期时间、身份验证证据和司法管辖区。它应记录每一次使用、续期、修改和撤销。下游处理方应收到当前状态，并在授权结束时停止使用数据，但须遵守律师确认的任何合法留存义务。

同意表述应与产品实际运行相匹配。被描述为财务洞察的用途，不应在未告知的情况下支持无关的营销、模型训练或转售。若隐私法下可能适用其他法律依据，公司应将该分析同开放金融许可区分开来。欧洲数据保护监督机构已明确警告，不要将拟议的 FiDA 许可与 GDPR 同意相混淆。

每一次数据使用都应能够对应到当前授权、已声明的目的以及可操作的撤销路径。

4. 设计身份、身份验证与授权

身份回答的是谁在操作。身份验证检验该主张。授权决定经核验的个人或组织可以批准什么。这些控制必须保持彼此独立，尤其是对于设有董事、员工、代表、顾问且签署权会发生变化的企业。

产品应按操作类型定义保障要求。查看公开产品目录不同于共享交易数据、添加接收方、发起付款或变更企业委托。风险较高的操作可能需要更强的身份验证、经数据持有方确认、针对具体交易的检查或另一名获授权人员。CBUAE 法规要求相关流程采用可靠且有效的身份验证，至少实施双因素认证，并在风险较高的情况下采取额外措施。

企业客户需要授权证明。公司应确定该人员是否能够约束该实体、访问每个账户并转授权力。仅凭单一用户登录不应自动确立组织权限。流程应记录角色、法律实体、相关账户或产品、授权来源、到期时间及变更。当人员离职或委托发生变化时，流程应支持移除权限。

身份验证数据应最小化并受到保护。当受监管框架提供安全重定向或基于令牌的方法时，创始人应避免收集银行凭证。印度《账户聚合器指令》规定，对于在金融信息提供方处开立的账户，聚合器不应访问客户的认证凭证。安全设计应包括凭证边界、证书验证、令牌管理、会话控制、设备与欺诈信号、恢复、监控以及经过测试的事件响应。

5. 将同意与数据及 API 架构相连接

开放金融平台需要实现从客户授权到每一次 API 调用和数据对象的可追溯性。架构应将当前许可标识符、参与方身份、目的和范围传入访问控制决策。它应拒绝已过期、已撤销、不匹配或范围过宽的请求，并保留符合法律要求的不可变事件记录。

CBUAE 框架整合了参与方目录、数字证书、API 门户、沙盒、API Hub、同意管理器、服务保障、报告和案件解决工具。API 聚合器旨在为底层接口提供统一的实施入口。这奠定了基础设施基础；每家提供方仍需要针对其应用、目的、客户旅程、下游处理和服务义务建立控制措施。

创始人应为每个数据元素维护数据契约。契约应定义来源、含义、格式、币种、时点、质量规则、允许用途、转换、数据血缘和保留期限。财务数据可能缺失、重复、延迟、被冲正、分类方式不同，或在账户状态变化的情况下提供。决策服务应说明其如何处理这些状态。模型输出应区分经核验的源数据、派生特征和管理层假设。

韧性设计应围绕客户损害和决策关键性展开。架构应处理数据持有方不可用、回调延迟、数据集不完整、许可被撤销、交易重复、证书过期、模式变更和依赖项故障等情况。服务级别、重试逻辑、备用沟通和人工解决应与合作伙伴达成一致。安全监控应覆盖参与方身份、异常访问、范围过大、令牌滥用和数据外泄。

董事会证据包应包括架构、数据清单、处理者地图、威胁模型、测试结果、事件计划、恢复目标、依赖项登记册和退出策略。独立测试应与风险和监管预期相匹配。

表2. 同意与信任控制登记册

控制设计应依据现行方案、隐私法和受监管活动进行确认。

6. 确定产品在价值链中的位置

创始人可以作为受监管的开放金融提供商、技术服务提供商、代理或分销商、向受监管机构提供的产品层，或跨市场的组合开展运营。每种定位都会改变控制权、资本、推向市场时间、收入分成、责任、数据权利和客户归属。

直接牌照可支持战略控制和持久的许可资产。它还需要治理、财务资源、监管沟通、合规运营、安全、报告、审计和持续监督。受监管合作伙伴路径可加速接触客户和基础设施。合作伙伴可能控制审批、数据访问、定价、客户入驻、产品变更和终止。白标路径可带来分销，同时限制创始人的可见度和数据使用。

应逐项服务、逐个市场地作出决策。董事会应比较创造客户价值所需的权利与各模式的义务和依赖关系。合同审查应涵盖监管角色、获准的数据用途、知识产权、模型所有权、服务水平、审计、分包、投诉、客户沟通、定价、最低承诺、责任、变更控制、终止与过渡。

创始人还应决定谁拥有客户同意关系。如果受监管合作伙伴获取并控制授权，创始人可能无法重复使用数据、联系客户或迁移服务。如果创始人是获授权的接收方，则可能承担更广泛的监管与隐私义务。产品架构与估值论证应反映可执行的合同，而不是假设的客户关系。

路径的选择取决于业务活动、控制要求、能力、合作伙伴依赖度和市场证据。

7. 围绕关键业务流程设计分发

当服务嵌入经常性、关键的业务流程时，开放金融分发会变得更强。示例包括日常资金管理、月度结账、信贷申请、供应商付款、保险续保、投资报告或家庭财务规划。工作流程为连接数据、回传结果、采取行动和完成支付提供了理由。

创始人应为每个渠道定义触发条件、决策、用户、频率、依据和结果。银行渠道可能提供可信的准入和庞大的既有客户基础，但会涉及采购、集成、风险审查和收益共享。会计平台渠道可以在已验证的财务活动节点触达小企业。市场平台可以将支付或信贷服务连接到交易。顾问渠道可以增加解读，但在涉及受监管建议时，需要权限、适当性和行为分析。

分发协议应使激励与客户结果保持一致。仅基于审批或交易量的收入可能会鼓励不精准的目标定位。该模式可以包括平台费、使用费、经核实的节省、服务层级或共享经济收益，但须经法律与行为审查。公司应在要求时披露重大商业关系，并防止排名或推荐逻辑因付款而受到扭曲。

渠道集中度应纳入董事会风险登记册。一个合作伙伴可能成为客户、数据、授权、身份、支付和收入的来源。创始人应测试终止、定价变化、审批延迟、产品限制和迁移。在合同和监管允许的情况下，直接了解客户、可迁移的产品证据以及不止一个可行渠道可以提升韧性。

分发计划应通过已验证的结果跟踪激活情况。指标可以包括合格用户、授权完成率、有效数据覆盖率、决策完成率、客户行动、留存使用、付费转化和服务成本。没有经常性价值的高连接数量并不能证明分发成效。

表 3：分发模式的经济性与控制

商业条款和指标仅为示意性类别；运营模型应采用已签署合同和经核实业绩。

8. 构建从授权到付费成果的单位经济模型

单位经济模型应跟随客户旅程。从符合条件的用户或企业开始，然后衡量授权启动、完成身份验证、有效数据连接、可用数据覆盖、完成决策、客户行动、付费转化、留存使用和支持。每一次转化都有成本和失败原因。

收入应与可执行事件挂钩：订阅期、经核实交易、平台许可、使用量或合同服务。合作伙伴分成、API 费用、卡组织费用、支付成本、欺诈、损失、客户支持、争议、合规审查、云、模型运营和数据修复应计入边际贡献。即使软件毛利率看起来很高，整合和监管成本也可能造成较长回收期。

创始人应将数据可用性与决策价值区分开来。更多账户或属性可能提高复杂性，却不会提升客户成果。产品团队应确定每项决策所需的最小可靠数据集，然后测试额外数据是否能改善准确性、速度、包容性或经济性。任何自动化决策都应有与活动和司法辖区相适应的证据、公平性和质疑框架。

定价应反映客户价值和负责任的风险分配。贷款机构可能为经核实的可负担性或现金流洞察付费。小型企业可能为节省时间、避免费用或更好的流动性可见性付费。平台可能为留存率或交易提升付费。管理层应避免将未经证实的数据副产物或未来交叉销售估值为当前收入。

董事会应审阅同期群桥接分析。该桥接分析应按来源和市场比较实际授权完成率、有效数据、服务使用、收入、合作伙伴成本和支持。图4中的示意性数值仅用于说明方法。公司预测应采用已观察到的同期群和经批准的假设。

指数化数值为示意性管理层假设；公司决策需要经核实的同期群和已签署的商业条款。

9. 将监管、数据和合作伙伴依赖关系纳入计划并计入定价

成本基础应包括维持许可和可靠性所需的工作。许可或认证可能需要法律咨询、申请工作、治理、财务资源、适当性评估、合规人员、政策、审计、报告、保险、网络安全、测试和年度维护。产品变更可能触发通知、批准或重新认证。

合作伙伴成本不应仅建模为收入分成。整合、入驻、尽职调查、安全审查、最低承诺、卡组织费用、客户支持、争议和变更请求可能消耗创始人现金。协议可能允许合作伙伴调整价格、暂停访问或要求返工。管理层应运行基准、下行情景和终止情景。

数据质量具有经济成本。缺失账户、不一致的描述符、延迟更新和模式变更可能导致人工审核、错误决策、客户投诉和模型漂移。预测应包括可观测性、对账、异常解决和支持。服务架构应识别哪些数据缺陷会被检测、披露、修复或转交至数据源。

在所选活动要求时，应评估监管资本和客户资金保障义务。创始人应将运营资金跑道与受限资本或客户资金安排分开。将所有现金视为可自由支配的融资计划可能高估执行能力。

10. 围绕证据关卡安排融资顺序

开放金融公司在收入规模化之前可能消耗大量资本。融资路线图应将每一批资金与能够降低产品、监管、技术、分销和经济风险的证据相连接。若没有更清晰的关卡，更大规模的融资轮可能为仍然未解决的并行依赖事项提供资金。

第一道关卡证明客户工作流程和参与意愿。证据可包括观察到的流程、获授权的设计合作伙伴和明确成果。第二道关卡确认监管边界建议、实体架构设计以及监管机构或方案路径。第三道关卡在受控环境中证明同意、身份验证、数据质量、安全与符合性。第四道关卡通过已签约合作伙伴或可重复的直接客户群证明分销。第五道关卡在更大规模扩张之前证明贡献、服务可靠性和治理。

融资工具应与不确定性和谈判地位相匹配。股权吸收产品和市场风险，并影响创始人持股。可转换工具或类似工具可推迟定价，同时带来折扣、上限、利息、期限和控制权影响。在收入可见度和股权支持能够履行其固定义务的情况下，风险债务可延长现金跑道。合作伙伴融资或实施费用可验证需求，同时引入排他性、路线图或定价权。合格的法律、税务和财务顾问应确认相关条款。

董事会应按关卡维护资金用途衔接表。监管、安全和整合工作应有明确交付物、验收证据和决策日期。招聘应围绕下一道关卡所需的能力。管理层应保留下行情景现金跑道，避免将未签约项目管线视为可用现金。

百分比和时间安排为示意性管理层假设；融资条款需要针对公司具体情况进行建模并寻求建议。

11. 将股权结构表和投资者权利作为运营约束进行治理

股权结构表影响创始人应对牌照、合作伙伴谈判和后续融资的能力。持股应按完全稀释基础建模，包括已发行股份、期权、认股权证以及按其可能转换条款计算的可转换工具。管理层应展示上限、折扣、利息、期权池增加和未来轮次的影响。

战略投资者可带来分销、数据、监管公信力或基础设施。其权利也可能限制与竞争对手建立合作、产品范围、地域扩张或退出。公司应仅对可执行的贡献进行估值，并对排他性、最惠条款、数据权利、路线图控制权和终止条款进行建模。

表4. 融资与股权结构表决策登记表

条款按运营和监管约束进行评估，并在需要时取得专家确认。

12. 通过可比性映射图进入市场

开放金融制度不应被视为可互换。创始人应比较范围、参与方模式、许可或认证、同意、身份验证、基础设施、数据集、发起权、商业准入、责任、隐私和实施状态。随后，产品可以采用通用控制核心并配合特定市场规则。

UAE 提供了一个中央框架，包括信任框架、API Hub 和共同基础设施服务。CBUAE 报告称，Al Tareq 已于 2025 年上线，其所述功能包括支付发起、e-KYC、支付令牌服务、标准化同意流程、收款人确认、数据共享 API 和保险报价服务。具体产品、参与方准入和推广阶段应通过最新官方材料和交易对手核实。

沙特阿拉伯运行开放银行框架，具备正式的业务和技术标准、测试与认证。英国拥有成熟的开放银行基础，并有 2025 年法案为智能数据计划提供权力；FCA 的开放金融工作将政策方向扩展到支付账户之外。印度采用持牌账户聚合器模式，具有详细的同意凭证以及对聚合器处理数据和凭证的限制。澳大利亚采用消费者数据权，包括经认可的数据接收方和授权代表。

欧盟委员会提出 FiDA，以将客户主导的访问扩展到更广泛的金融数据，并引入授权仪表板和金融数据共享计划。在依赖之前，应核查该提案的最终法律形式和时机。美国联邦规则也尚未确定：CFPB 表示，法院于 2025 年 10 月暂缓了合规日期，同时重新审议工作仍在继续。

市场优先级应遵循有评分的证据论证：客户工作流、可获取数据、允许的运营模式、合格合作伙伴、实施准备度、收入、获客、服务成本和资本。仅市场规模不足。

表 5. 多市场进入地图

本表记录发布时的官方框架状态；创始人在上线前必须重新核实规则、生效日期和批准情况。

13. 将隐私、数据最小化和客户控制产品化

隐私应体现在产品选择中。服务应仅请求为既定决策所需的最少数据，在明确期限内保留，并给予客户可用的控制权。当新目的得到说明和授权时，可以请求额外数据。内部便利不是客户目的。

产品团队应维护数据清单，将每个数据要素与目的、来源、法律分析、接收方、模型特征、保留、删除和客户沟通关联起来。敏感属性和派生推断需要特别审查。模型训练、产品研究、营销和合作伙伴报告应与提供所请求的服务分开分析。

客户仪表盘应显示有效权限、接收方、数据类别、目的、最近访问、到期和撤销情况。产品应说明撤回的后果，包括哪些未来服务会停止，以及根据适用法律义务哪些记录可能保留。撤销应传导至处理方和合作伙伴，并对例外情形进行调查。

UAE 的开放金融基础设施明确包括集中式同意管理。印度的指令要求同意属性、撤销和可审计性。拟议的欧盟 FiDA 框架使用权限仪表盘，而 EDPS 强调权限、数据最小化和数据保护法律依据的清晰性。这些示例支持一种产品模式：可见的授权、有限的使用和运营控制。

董事会应在商业指标之外获得隐私和同意指标。示例包括每个用例的范围、权限完成率、已撤销权限、下游确认时间、未经授权访问事件、保留例外、投诉和整改。通过混淆性设计获得的高转化率会带来法律和信任风险。

14. 建立数据、模型和决策问责制

开放金融数据常用于评分、预测、建议和自动化操作。公司应记录源数据如何转化为决策。记录应明确数据集、转换、特征、模型或规则、输出、用户、操作和问责负责人。应区分客户事实、第三方数据、衍生值和管理层假设。

数据质量控制应测试完整性、时效性、对账、重复处理、冲正和币种。缺失的活期账户可能扭曲可负担性。延迟交易可能扭曲现金流。分类错误可能扭曲财务健康建议。当证据低于已批准阈值时，产品应对输出加以限定或停止输出。

模型治理应与后果相匹配。公司应界定预期用途、禁止用途、训练与验证数据、性能、稳定性、偏差或排斥风险、人工复核、监测、质疑和变更控制。开放金融许可本身并不授权对数据的所有使用，也不能证明自动化决策是公平的。

客户解释应针对具体操作进行设计。预测可以显示来源日期和不确定性。信用建议可以识别主要因素，并在需要时提供复核路径。付款指令应在确认前显示金额、收款方和授权。投诉和更正流程应能触达数据或决策的负责人。

董事会应将模型表现与商业成果和客户损害一并审查。审批通过率、收入或参与度应同时附带数据覆盖率、错误、人工覆盖、投诉、不利结果和补救措施。重大变更应重新审视业务边界、同意和合作伙伴批准。

15. 以合同明确生态系统的问责与退出

开放金融通过由数据持有方、机制、身份服务商、云服务、受监管机构、分析服务商和分销商组成的生态系统提供。合同应反映权限、数据、服务和资金的实际流向。

责任矩阵应明确客户承诺、许可获取、身份验证、API 操作、数据质量、决策、交易、投诉、退款、事件、监管报告和记录。每项责任都应有证据来源和升级路径。当客户只看到一个界面但有多家机构共同提供服务时，责任归属不明确尤其危险。

退出机制应在依赖关系变得重大之前设计。该计划应涵盖客户沟通、有效许可、数据返还或删除、过渡协助、凭证、模型、未了结交易、争议、监管通知和业务连续性。创始人应知道在同意、合同和法律框架下，能否将客户和数据迁移至另一合作伙伴。

董事会应测试严重的合作伙伴情景。该情景可假设立即暂停、数据中断、定价变化、牌照问题或被竞争对手收购。管理层应说明客户影响、义务、现金影响、替代能力和决策权。该情景重视在公司形成依赖之前的韧性。

表 6. 董事会治理与上线检查清单

每个关口都需要最新证据和指定负责人；未解决的法律结论仍由合格顾问负责。

16. 通过五道关口实施120天创始人计划

第1至20天建立客户与边界证据。团队定义工作流程、客户成果、实体、活动、司法辖区和合作伙伴。团队就拟议结构获取书面法律意见，启动所需的监管或计划机制接洽，并识别数据和许可要求。第一道关口批准具体用例和有效运营路径。

第21至45天构建同意与信任设计。产品、法律、合规、安全和数据团队创建许可对象、客户旅程、身份验证、API架构、数据契约、威胁模型、事件计划和处理者映射。团队测试撤销和下游状态。第二道关口要求可审计的旅程和已关闭的关键安全发现。

第46至70天验证服务和分销路径。创始人整合受控数据、验证质量、测试决策、记录模型治理、配置投诉流程并商定合作伙伴职责。商务团队就客户归属、经济条款、服务、变更和退出进行谈判。第三道关口要求完成测试以及可执行的用户触达路径。

第71至95天运行受控群组。公司衡量许可完成、有效数据、决策完成、成果、支持、事件和合作伙伴服务。财务报告核对收入、合作伙伴成本、服务成本和现金。第四道关口授权整改或有限扩张。

第96至120天为规模化做准备。董事会审查市场状况、许可、符合性、运营能力、融资、股权结构表、下行跑道、合作伙伴集中度、留存成果和贡献。第五道关口授权设定市场与群组上限并附带停止规则。

每个阶段结束时都需提供证据，供董事会批准、有条件批准或退回整改。

17. 同时衡量信任、成果和贡献

记分卡应将许可、服务、客户成果、风险和现金联系起来。仅靠商业仪表盘可能会奖励那些造成同意薄弱、服务事件或无利可图的支持的活动。仅靠合规仪表盘可能会遗漏产品是否解决有价值的问题。董事会需要一个经核对统一的视图。

信任指标可包括权限完成、范围、续期、撤销、身份验证失败、未经授权的请求、客户投诉和事件恢复。交付指标可包括有效数据覆盖、数据新鲜度、延迟、决策完成、正常运行时间和合作伙伴绩效。结果指标应反映所述任务，例如预测准确性、节省的时间、避免的故障、改善的现金可见性或完成的交易。

商业指标应按群组划分。公司应跟踪符合条件的用户、已激活的权限、已付费结果、留存率、收入、合作伙伴分成、服务成本、支持、损失和获客。现金指标应显示收款、合作伙伴结算、受限现金、监管投资和现金跑道。预测与实际之间的差异应更新融资决策。

停止规则应在规模化之前获得批准。示例可包括未解决的未经授权访问、重大客户损害、未能传播撤销、权限或合作伙伴授权丧失、不可接受的服务中断、模型故障、不利投诉模式或现金跑道低于批准阈值。确切阈值是公司特定的管理决策。

18. 明确董事会决策

最终董事会材料应包含客户工作流、活动与实体图、书面范围建议、许可或合作伙伴路径、同意旅程、数据与 API 架构、安全证据、模型文档、合作伙伴合同、市场进入地图、单位经济性、股权结构表、融资计划、风险登记册、运营记分卡和 120 天记录。每一项都应标明其负责人、日期、来源和未解决事项。

董事会应批准一项有边界的决策。它可以授权一项服务、一个实体、一个市场、一个合作伙伴、一个客户群组和一个资本批次。条件应说明所需权限、方案或合作伙伴接受、安全事项关闭、投诉处理能力、服务水平、贡献证据和审查日期。扩展应需要下一个证据关口。

管理层应记录仍不确定的事项。待定的监管规定、法院中止、合作伙伴采购流程、许可证申请、客户预测或融资情景，都应连同其当前状态和后果一并呈现。公司应避免将计划中的权限、拟议的合作伙伴关系或预测转化呈现为已实现。

董事会还应批准责任安排。具名高管应负责客户承诺、监管范围、同意、安全、数据质量、模型、合作伙伴、投诉、经济性和现金。产品用途、数据、实体、市场、交易权利或分销的变化应触发重新评估。

当授权、数据和经济性保持一致时，开放金融可以成为有价值的分销与决策基础设施。创始人的优势来自在客户、合作伙伴、监管机构和投资者都能理解的结构内，以可靠证据解决一项关键工作流。

实施结论

创始人行动手册从客户决策开始，并将每项活动映射到执行该活动的实体、权限和司法管辖区。它将同意转化为可审计的生命周期，将授权与 API 和数据控制连接起来，并明确合作伙伴角色和退出权利。

商业规模化以已验证的结果为前提。分销应嵌入经常性工作流，单位经济性应从权限贯穿至已付费贡献，资金应根据证据关口释放。市场进入应反映当前官方制度及其不同的实施状态。

120 天计划为董事会提供五项决策：验证客户任务和范围；批准同意与信任；接受可执行的服务和渠道；验证受控群组；并授权有边界的规模化。在得到公司证据和已批准决策支持之前，财务数值、记分卡阈值和时间安排仍为说明性管理假设。

参考文献

1. UAE 中央银行。开放金融。 https://www.centralbank.ae/en/our-operations/fintech-digital-transformation/open-finance/
2. UAE 中央银行规则手册。开放金融法规。 https://rulebook.centralbank.ae/en/rulebook/open-finance-regulation
3. UAE 中央银行规则手册。引言与范围，开放金融法规。 https://rulebook.centralbank.ae/en/rulebook/introduction-and-scope-2
4. UAE中央银行规则手册。附表1：开放金融框架详情。 https://rulebook.centralbank.ae/en/rulebook/schedule-1-%E2%80%93-details-open-finance-framework-0
5. UAE中央银行。2025年年度报告。 https://www.centralbank.ae/media/4qbn11cl/annual-report-2025-en.pdf
6. UAE中央银行。CBUAE发布《开放金融条例》，2024年6月27日。 https://www.centralbank.ae/media/rxfeelkt/cbuaei-2.pdf
7. 阿拉伯联合酋长国立法。关于个人数据保护的2021年第45号联邦法令。 https://uaelegislation.gov.ae/en/legislations/1972
8. 沙特中央银行。沙特阿拉伯的开放银行。 https://www.openbanking.sama.gov.sa/index-en.html
9. 沙特中央银行。SAMA开始向金融科技公司发放许可，以提供开放银行服务。 https://sama.gov.sa/en-US/MediaCenter/News/pages/news-1135.aspx
10. 沙特中央银行规则手册。第95条：支付服务提供商准入与开放银行。 https://rulebook.sama.gov.sa/en/article-95-1
11. 英国政府。2025年《数据（使用与访问）法案》。 https://www.gov.uk/government/collections/data-use-and-access-act-2025
12. 英国立法。2025年《数据（使用与访问）法案》解释性说明。 https://www.legislation.gov.uk/ukpga/2025/18/notes/division/4/index.htm
13. 金融行为监管局。开放银行与开放金融。 https://www.fca.org.uk/firms/open-banking-open-finance
14. 金融行为监管局。PS22/9，《新消费者义务》。 https://www.fca.org.uk/publications/policy-statements/ps22-9-new-consumer-duty
15. 印度储备银行。主指引：非银行金融公司——账户聚合商指引（2016年），2024年9月6日更新。 https://systemhealth.rbi.org.in/Scripts/BS_ViewMasDirections.aspx_id%3D10598%281%29.html
16. 澳大利亚竞争与消费者委员会。消费者数据权。 https://www.accc.gov.au/by-industry/banking-and-finance/the-consumer-data-right
17. 澳大利亚竞争与消费者委员会。《2020年竞争与消费者（消费者数据权）规则》。 https://www.accc.gov.au/system/files/CDR%20Rules%20-%20Final%20-%206%20February%202020.pdf
18. 欧盟委员会。关于金融数据访问框架的条例提案，COM(2023) 360 final。 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM%3A2023%3A0360%3AFIN
19. 欧洲数据保护监督局。关于《金融数据访问框架条例提案》的意见。 https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A52023XX01054
20. 消费者金融保护局。个人金融数据权利。 https://www.consumerfinance.gov/compliance/compliance-resources/other-applicable-requirements/personal-financial-data-rights/
21. 消费者金融保护局。《联邦法规汇编》第12编第1033部分，个人金融数据权利。 https://www.consumerfinance.gov/rules-policy/regulations/1033/
22. 国际清算银行。API 数据共享标准。 https://www.bis.org/publ/bppdf/bispap132.htm
23. 世界银行。金融消费者保护。 https://www.worldbank.org/en/topic/financialinclusion/brief/financial-consumer-protection