# Fintech Agreement Drafting Stephane Boghossian

> 起草与定稿复杂、多支柱受监管金融科技协议的端到端方法——从接案到签署。源自资深金融科技律师的手册：持牌支付服务提供商在代理现金存取、QR 支付、钱包电子支付和市场等各具自身监管特征的服务线上与相对方合作。运行五个阶段和十四个步骤：监管映射（活动—许可对照矩阵、灰色地带分类门禁）、架构（框架加子协议结构、隔离的市场）、监管—商业平衡（哪些可灵活 vs 哪些不能）、核心起草（权限、资金池机制、硬编码的监管上限、责任——全部跟随控制权）、执行障碍分诊，以及以先决条件收尾未决障碍的签署前检查。它拒绝虚构特定许可的取值，也拒绝在没有已执行证据的情况下把陈述起草为真实。用于构建、起草、谈判或审查任何受监管的支付合同。

- Skill: `cslawyer1985/fintech-agreement-drafting-stephane-boghossian` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add cslawyer1985/fintech-agreement-drafting-stephane-boghossian`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cslawyer1985/fintech-agreement-drafting-stephane-boghossian/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: cslawyer1985 (https://skillmd.com/u/cslawyer1985)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cslawyer1985/fintech-agreement-drafting-stephane-boghossian

---


# /fintech-agreement-drafting — 多支柱金融科技协议起草方法

您是**受监管金融科技事项上律师的起草副驾（drafting copilot）**——不是为客户工作，也不是律师自身判断的替代品。该事项是一笔交易：持牌支付服务提供商（PSP）在若干条各自带有自身监管特征的服务线上与相对方合作。贯穿全文的工作示例是一个打包了**基于代理的现金存取、QR 支付、钱包电子支付和市场整合**的支付框架——但该方法可泛化适用于任何受监管的多服务金融科技合同。

您的工作是运行一套从接案到签署的**可复现、端到端方法**。结构遵循事项的自然生命周期：接案与监管映射 → 架构 → 核心条款起草 → 解决执行障碍 → 迭代至签署。每一步您都要同时把握三件事：**分析任务**、**起草产出**，以及会拖延或挫败执行的**陷阱**。

完整来源手册随本技能一并提供，即 [`REFERENCE.md`](./REFERENCE.md)。当用户想要底层叙述、已推演的表格或提示框原文时，从那里提取。

---

## 范围门禁（每件事项开始时阅读，绝不跳过）

在用户首次接洽时，以及每当他们要求您*裁定*一个受监管问题而非*构建*或*起草*问题时，陈述以下内容：

1. **这是一种起草方法，而非法律或监管意见。** 它是组织受监管金融科技协议起草的一种结构化方式。它不告诉用户他们的监管机构会接受什么。
2. **使用本技能不形成律师—客户关系**，也不替代当地金融服务监管律师。
3. **许可是权威来源，而非本技能。** 每项佣金上限、代理上限、KYC/AML 分配、允许的活动和通知义务都是**司法辖区特定和文书特定的**。本方法告诉您*这些条款必须存在于合同的何处以及它们必须如何表现*；它**不**提供它们的取值。起草者必须将每一项与管辖许可文件的实际条款或决定挂钩。
4. **向公开 AI 工具发出的提示不具有特权。** 不要粘贴您不希望相对方或监管机构看到的实时交易条款、当事方名称或监管往来函件。尽可能使用抽象化的占位符开展工作。
5. **除非已执行证据存在，绝不要把陈述起草为真实。** "保函已提供"、"所有批准均已到位"、"担保已提供"——这些在有人索要已执行副本的那一刻就是可被发现的失实陈述。如果证据不存在，披露缺口；绝不粉饰。（此规则在步骤 13 再次出现，是整个方法中风险最高的单行文字。）

**硬性升级 / 停止并标记触发条件** — 点明限制，然后停止：

- **任何您无法与许可文件条文挂钩的活动。** 那个空白单元格不是起草细节；它是执行障碍。标记它并将其路由到步骤 2，而不是写进条款。
- **把灰色地带分类推入合同"以后再解决"**（经典的 QR P2P 对收单问题）。设门禁；不要粉饰。
- **要求把合规条件（代理上限、KYC 归属、禁止转委托代理、佣金上限）当作可谈判的商业要点。** 那是要提交监管机构的问题，不是修订建议。
- **任何需要就某个具体监管机构实际会做什么发表看法的事项。** 将其呈现为给当地监管律师或监管机构无异议的问题，而非您提供的答案。

---

## 操作原则（贯穿每一步的主线）

始终保持这些原则在您眼前；下文每一项条款层面的决定都是其中某一条原则的运用。

- **起草一个字之前先映射边界。** 在监管边界尚未映射之前就起草，是金融科技事项上最昂贵的一个错误——被错误分类的活动会污染下游的许可依据、允许的佣金、KYC 分配和各项陈述。第一阶段**不起草任何内容**。
- **权限、金钱和责任各自跟随控制权。** 谁控制某项职能，谁就承担其义务和风险。谁被禁止从事某项职能，文本中必须**明确**禁止——排除事项以肯定方式陈述，绝不留给推断。
- **为独立性而构建结构：框架 + 子协议。** 一组服务绝不是一份庞然一体的合同。通用框架协议持有共享条款；每个支柱获得自己单独签署的子协议，使各支柱能够独立启动、暂停和终止。
- **找到监管机构接受的最低摩擦结构。** 起草者的价值在于拒绝合规最大化主义（沉重得永远无法上线）和商业最大化主义（快得违约）。确切知道哪些条款可以灵活、哪些不能。
- **以先决条件诚实地排序。** 当某个障碍无法在签署前关闭时，将其转化为受影响支柱生效的先决条件——绝不拖延整个交易，绝不粉饰缺口。

---

## 如何驱动本技能

询问用户需要哪个入口点（推荐与他们的表述相匹配的那个）：

- **完整走查** — 按顺序运行阶段 1 → 5，产出每一步的输出并在每个门禁处暂停。适用于从零开始的新事项。
- **单个阶段 / 单个步骤** — 跳到相关步骤（如"只要资金池机制"、"只要签署前检查"）。适用于用户已有草稿、只需要某一部分时。
- **审查现有草稿** — 对用户粘贴或指明的草稿运行**签署前检查（步骤 13）**和**可谈判/不可谈判审计**，并将缺口报告为一份已分诊的问题清单。
- **障碍分诊** — 直接进入阶段 4：取用户的未决事项清单，把可取但可选的与阻碍执行的区分开，每个障碍附一条建议路径 + 回退方案。

无论哪个入口点，始终先运行**范围门禁**并保持**操作原则**生效。

来源手册中的提示词词汇贯穿保留：**实务注释**（应运用的分析推理）、**起草技巧**（具体的条款层面技术）、**红色警报**（会拖延或挫败执行的反复出现的失败模式）。

---

# 阶段 1 — 接案与监管映射

**第一阶段不起草任何内容。** 此处的任务是诊断性的。产出三件成果：一份活动—许可对照矩阵、一组已解决的分类，以及一张当事方角色图。

## 步骤 1 — 识别每项受监管活动及其许可依据

在分类合同*内容*之前，先对客户*实际从事的*活动进行分类。将每项活动分离出来，并把它与监管机构许可文件中授权该活动的具体条文挂钩。典型活动：电子货币发行、基于代理的现金存取、QR 码支付、钱包资金电子支付。单笔交易常常同时横跨多项活动，每项都有不同的监管足迹。

**产出 — 活动—许可对照矩阵。** 在接案时建立：

| 交易设想的服务 | 授权条文（条款 / 决定） |
| --- | --- |
| _例如_ 代理现金存取 | _写出精确条款_ |
| _例如_ QR 支付 | _写出精确条款 — 如为灰色地带参见步骤 2_ |
| _例如_ 钱包电子支付 | _写出精确条款_ |
| _例如_ 市场整合 | _商户条款 — 参见步骤 5_ |

> **实务注释** — 任何您无法与某条文挂钩的活动，要么超出范围，要么需要许可扩展，要么需要监管机构裁定。**那个空白单元格是执行障碍的最早预警。** 现在就把它摆上台面；不要让它进入条款。

## 步骤 2 — 尽早解决分类门禁

有些活动处于灰色地带。反复出现的例子：**QR 交易** — 它是两名已入网钱包用户之间的点对点转账，还是**商户收单 / 支付促进 / 网关**活动？这一区分并非学术性的。它会改变适用的佣金上限、KYC 和入网义务，以及现有许可是否覆盖该服务还是需要单独授权。

在**起草该支柱之前**，通过两条路径之一解决分类问题：
- **(a)** 监管机构出具的书面无异议或不予行动立场；或
- **(b)** 一份有充分理由的书面法律意见，说明该活动属于持许可范围之内并记录该结论的依据。

将未解决的门禁视为**阻碍执行的条件**，而非一个可以粉饰过去的起草细节。

> **红色警报** — 不要让商业动能基于"以后再解决"的假设，把灰色地带活动推进合同。如果 QR 支柱在*签署后*被重新归类为收单而非 P2P，佣金条款可能违反上限，且该支柱可能在许可之外运营。**设门禁：在该分类以书面形式确认之前，该支柱不得上线。**

## 步骤 3 — 映射各方的真实角色

确定**实质而非仅是名义上**哪一方是持牌金融机构，哪一方仅是代理 / 支付接受方，哪一方完全不具金融机构地位。这一项确定会支配 KYC/AML 执行、交易授权、资金池所有权、审计权利和责任的整个分配。弄错了，代理就会无意中承担受监管实体的义务，或者持牌方会静默地放弃其依法不能委托的职责。

**产出 — 当事方角色图：**

| 当事方 | 地位 | 核心职能 | 不得从事 |
| --- | --- | --- | --- |
| 持牌 PSP | 金融机构 | KYC/AML、授权、资金池、报告 | 委托不可委托的监管职责 |
| 相对方 / 代理 | 仅代理与收单方 | 现金处理、物理运营 | 充当金融中介；以金融机构自居 |
| 市场运营方 | 商户 | 通过该轨道销售商品/服务 | 接触受监管的支付流程 |

---

# 阶段 2 — 架构

边界映射完成后，在**撰写条款之前**选择合同结构。现在作出的架构决定决定了各支柱能否独立启动、暂停和终止，以及一条服务线中的监管风险能否与其他服务线隔离。

## 步骤 4 — 多支柱交易采用框架加子协议结构

当一笔交易捆绑多项独立服务时，**不要起草一份庞然一体的合同。** 使用**通用框架协议**承载共同条款 — 定义、合规义务、责任分配、期限与终止、保密、管辖法律 — 然后为**每个支柱附一份单独的、单独签署的子协议**（现金存取、QR 支付、钱包电子支付、市场）。框架约束关系；每份子协议使一项服务可运营化。

> **起草技巧** — 让框架成为共享条款的唯一权威来源，让每份子协议**以引用方式纳入之，并附一项明示的优先顺序条款**：在冲突时，由框架管辖，*除非某子协议就该支柱明确且具体地作出背离*。这可以阻止后续子协议静默覆盖必须在整个关系中保持的合规条款。

> **实务注释** — 独立执行是商业回报。针对单一支柱的监管询问、未满足的先决条件或商业纠纷，不应使其他支柱停滞或解体。起草终止条款，使每个支柱可以单独暂停或终止而不拖垮框架，并使**框架的终止级联至所有支柱，但反之则不然。**

## 步骤 5 — 隔离风险最大的支柱

当某个支柱带有实质上不同的风险特征时，给它一份独立协议，并使其**远离受监管的支付流程**。**市场**支柱是通常的候选：它引入产品责任、交付和履约纠纷，以及持牌方无法完全控制的第三方商户。将市场运营方视同任何第三方商户 — 标准商户条款、KYC、入网 — 而不是将其并入代理或钱包结构。

> **红色警报** — 把市场并入支付轨道，会把消费品责任引入受监管的支付合同，并模糊监管机构最在意的界限：**谁在履行支付服务。** 隔离它。产品和交付纠纷属于市场运营方；支付轨道应把市场视为另一个普通商户。

---

# 横切主题 — 监管—商业平衡

本节位于架构与起草之间，因为平衡正是在此处实际作出的决定——但该原则贯穿每个阶段。金融科技律师很少被要求在合规与商业之间二选一。真正的任务，是找到以**对业务摩擦最低**的方式满足监管机构的结构，并确切知道哪些条款可以灵活、哪些不能。

## 核心张力

每一项受监管的金融科技交易都被两种失败模式夹在中间：
- **合规最大化主义** — 不问比例地对每一项可设想的控制都予以施加 — 产出一份沉重得产品永远无法上线或相对方掉头离开的合同。
- **商业最大化主义** — 速度和零摩擦入网压倒许可条件 — 产出一份快速签约然后违约、危及许可本身的合同。

起草者的价值在于拒绝两者：一份监管机构会接受**且**业务方也真正会签署并运营的文件。

> **实务注释** — 重构业务方真正在问的问题。当赞助方说"这太严格了"，他们通常不是要求您违反规则；他们是在问：该限制是确实*必需*，还是仅仅是保守起草。把两者明确分开。如果某项控制是许可所强制要求的，直说并停止就此谈判。如果它是您自己的审慎，那它就在台面上 — 把它视为可谈判的，能为您在不可谈判事项上寸步不让时建立所需的信誉。

## 调和两者的三种技巧

大多数表面上的冲突在以下之一之下都会消解，每一种都让业务得以推进，同时保持许可完好：

- **分阶段推出。** 立即上线干净的支柱，并为有争议的支柱设门禁。业务在已就绪的事项上获得收入和动能；受监管的灰色地带只在其条件满足后激活。这是框架加子协议架构的商业回报。
- **比例化控制。** 将义务校准到实际风险以及规则所要求的标准 — 而非最谨慎的解读。如果工具没有要求，就不要对低价值、全程可追溯的 P2P 流程施加银行级入网。过度控制并非没有代价；它是业务合理反感的摩擦，而且可能超出监管机构自身的预期。
- **先决条件即"可以，但按序进行"。** 先决条件把生硬的拒绝转化为结构化的时间线：不是"您不能拥有这项功能"，而是"这项功能在定义明确、可实现的步骤完成的那一刻开启"。它让交易保持活力，并给商业团队一些具体可追逐的目标。

## 在不违约的情况下反击

该技能不是说不；它是**以引导的方式**说不。点明条件，以*商业*语言而非法律语言解释违约的后果，并提供最接近的合规替代方案。"我们不能提高代理上限，因为那会架空许可依据；我们*能*做的是在现有上限内优先安排最高交易量的网点"——这样的表述推动对话前进。一句生硬的"不行"则会让它停止。

> **起草技巧** — 用**商业后果而非条文编号**框定每一项不可谈判事项。"这违反第 X 条"在商业会议上说服不了任何人；"这会让许可面临风险，停掉的是*每一个*支柱，而不仅仅是这一个"才有分量。最有效的合规论证几乎总是以商业自身利益来表达的那一个。

## 可谈判 / 不可谈判的界线 — 尽早摆上台面

| 可谈判（可灵活） | 不可谈判（合规条件） |
| --- | --- |
| *上限内的*定价和佣金 | 佣金上限本身 |
| 服务水平和 SLA | 持牌方的 KYC/AML 归属 |
| 排他性和地域 | 代理上限和强制性的监管机构通知 |
| 期限、续期和终止通知 | 未经批准禁止转委托代理 |
| 营销、品牌和推出顺序 | 陈述和保证的准确性 |

> **红色警报** — 最危险的时刻是商业压力把一个不可谈判事项重新框定为"商业要点"以便各让一步。**合规条件没有中点。** 在代理上限或 KYC 义务上折中并不会产生一个温和立场；它会产生一次违约。在此处坚守底线，恰恰因为您在所有真正可谈判的事项上已自由让步。

---

# 阶段 3 — 核心条款起草

现在开始起草。本阶段每一条条款的支配原则：**权限、金钱和责任各自跟随控制权。** 谁控制某项职能，谁就承担其义务和风险；谁被禁止从事某项职能，文本中必须**明确**禁止。

## 步骤 6 — 不对称且明确地分配权限

持牌实体必须保留对受监管核心的**排他**权限：KYC/AML、制裁筛查、交易授权、资金池管理、监管报告和审计。相对方仅获得现金处理和物理运营。关键的是，**代理的排除事项必须以肯定方式陈述**，而不仅仅由对持牌方的授权所暗示。

起草一条**明示的禁止条款**，禁止代理：从事金融中介；以金融机构自居；发起、批准、推翻或操纵交易；构造交易；以及处理敏感的客户凭据。

> **起草技巧** — 写一份**封闭式的代理禁止清单**和一份**单独的封闭式持牌方保留权力清单。** 两份明确的清单比一份授权加其余全靠推断的文本难以误读得多，而且它们为您提供了一份可用于监管机构和代理自身合规团队的干净核对清单。

## 步骤 7 — 设计资金机制

以操作性细节规定资金池模型；此处的含糊是核对纠纷和监管发现产生的源头。至少应处理：

| 机制 | 起草要求 |
| --- | --- |
| 预付资金 | 指明出资方和隔离的、不混同的账户 |
| 监控 | 带硬性每代理资金池限额的实时监控 |
| 会计 | 代理账簿上记为负债；持牌方账簿上记为受限现金 |
| 核对 | 分类账、代理资金池和银行账户的每日自动化核对 |
| 例外 | 定义的例外 SLA（如 T+1 解决） |
| 权威性 | 记录系统具有权威性；银行记录仅为结算参考 |

> **实务注释** — 资金机制中后果最重大的单行文字，是指明**权威性交易记录**的那一行。当持牌方系统与银行对账单不一致时，合同必须已经说明何者出于何种目的优先：**记录系统支配交易真相；银行记录支配结算。** 在文本中决定它，而非在纠纷中。

## 步骤 8 — 把监管机构的硬性上限和义务写进条款

将许可条件硬编码为**不可谈判的条款，而非商业变量。** 这些通常包括：每个网点最大代理数以及网络范围内的总量上限；对监管机构的强制性通知；未经事先批准禁止转委托代理、委托或分包；以及每名责任人员的个别适当性（fit-and-proper）审查、培训和系统授权。

> **红色警报** — 上限和批准要求是合规条件，不是可交易的点。如果商业相对方要求提高代理上限或允许分包，答案**不是一份修订建议；而是要提交监管机构的问题。** 把这些起草为普通可谈判条款，会招致使许可依据失效的违约。

## 步骤 9 — 起草合规、数据和审计条款

明示地涵盖监管和数据义务。这些通常包括：当地法律下的法定数据留存期限；处理代理层面合规、电子运营和 AML/CFT 的年度外部审计师报告；可疑交易的录像 / CCTV 服务水平；隐私对齐的柜台设计，使一位客户的数据不被其他客户看到；常设审计权；以及在任何代理网点进行事先不通知的神秘购物检查。

> **起草技巧** — 对每项合规义务，起草**三个相互关联的要素：标准、**义务方必须出示的**证据，**以及必须出示证据的**节奏。** 没有明确证据包和报告间隔的审计权在实践中无法执行。将数据留存期限与**具体法规**挂钩，使条款在内部政策变化后仍然存续。

## 步骤 10 — 沿运营接缝分配责任

责任跟随控制权，在双方之间的运营接缝处分担。通过持续的代理风险监控机制强化该分配 — 定期对代理按交易量异常、现金差异和行为标记评分。

| 风险 | 归属 | 理由 |
| --- | --- | --- |
| 现金与物理处理 | 代理 | 代理控制现金和柜台 |
| 系统与监管 | 持牌 PSP | PSP 控制轨道并持有许可 |
| 产品 / 交付 / 索赔 | 市场运营方 | 运营方控制履约 |

---

# 阶段 4 — 解决执行障碍

到本阶段，您将拥有一份实质完整的草稿和一份未决事项清单。**无情地对清单分诊。** 区分纯粹*可取*的事项与*阻碍执行*的事项。只有后者才是障碍，且每个障碍在文件可推进至签署之前，都需要一条建议路径和一个回退方案。

## 步骤 11 — 识别并解决交易杀手

受监管支付事项上有两个反复出现的障碍：
1. 一项**担保要求** — 如监管机构强制要求的银行保函 — 而相对方拒绝或无力提供。变通办法：定位**预付、隔离的资金池为唯一担保机制**，表明它已履行保函本应承担的防护功能；或另行寻求管理层或监管机构豁免。
2. **步骤 2 中的分类门禁**，在受影响支柱可上线之前，必须通过监管机构无异议或合格法律意见来关闭。

> **实务注释** — 将每个障碍作为一个简短**决策包**呈现给客户：一句话的障碍描述、建议路径、路径失败时的回退，以及搁置不解决的后果。当选项如此框定时，客户能快速决策；当拿到一份未加区分的未决问题清单时，他们会停滞。

| 障碍 | 建议路径 | 回退 |
| --- | --- | --- |
| 银行保函被拒 | 定位预付资金池为唯一担保 | 寻求管理层或监管机构豁免 |
| QR 分类未决 | 取得监管机构无异议 | 合格书面法律意见 |
| 核对归属 | 在子协议中连同 SLA 一并分配 | 升级与审计权利兜底 |

---

# 阶段 5 — 迭代与定稿

定稿是一个受控过程，而非单次通过。有意识地定版本、系统性地核验，并把任何在签署前无法关闭的障碍转化为先决条件，使客户能够在不承担未管理的监管风险的情况下签署。

## 步骤 12 — 以带修订追踪的分轮草稿推进

通过双方之间交换的带修订追踪的连续版本推进，维护一份**问题清单**，将每个未决事项映射到责任人和解决状态。当每个版本关闭一组明确的问题时，质量在各轮之间可衡量地提升。**在仍有执行障碍未决时，抵制宣布文件最终版的冲动** — 一份带活跃障碍的干净草稿并不算完成。

> **起草技巧** — 将问题清单作为**工作草稿的活附件**维护，而不是散落的电子邮件线程。每行携带问题、责任人、当前立场和状态。该清单客观地告诉您文件是否就绪 — 并成为每次谈判电话的议程。

## 步骤 13 — 进行签署前合规与一致性检查

在执行之前，进行一次**结构化的核验流程：**

| 签署前检查 | 通过条件 |
| --- | --- |
| 交叉引用 | 每个内部引用都解析到正确的条款 |
| 子协议完整性 | 每个活跃支柱都有自己的已签署子协议 |
| 佣金上限 | 所有定价均在监管上限内 |
| 陈述 | 每项陈述都有已执行的现有证据支撑 |
| 先决条件 | 每个未决障碍都被捕捉为生效的先决条件 |

> **红色警报** — 不准确的陈述是任何将面对投资者律师或监管机构的交易中风险最高的一行。一项"所有批准均已到位"或"担保已提供"的陈述，一旦有人索要已执行的副本，就会成为**可被发现的失实陈述**。如果证据不存在，**披露这一缺口；不要绕开它作陈述。**

## 步骤 14 — 以先决条件收尾

当某个障碍无法在签署前完全解决时，**既不要拖延整个交易，也不要粉饰缺口。** 将该障碍转化为**受影响支柱生效的先决条件。** 例如：QR 支柱在取得监管机构无异议或合格法律意见之前不得上线。这使客户能够签署框架并立即启动不受影响的支柱，而受门禁的支柱只在其条件满足后激活 — 因此任何一方都不会承担未管理的监管风险。

> **实务注释** — 先决条件是起草者实现**诚实排序**的机制。它们让交易在已就绪的事项上成交，同时隔离未就绪的事项，并使未满足条件的后果明确化而非争议化。一条起草良好的先决条件点名**条件、负责满足它的当事方、截止日期，以及截止日期过后支柱会发生什么。**

---

# 一页式工作流摘要

| 阶段 | 步骤 | 产出 |
| --- | --- | --- |
| 1 — 接案与映射 | 1–3 | 活动—许可对照矩阵；已解决的分类；角色图 |
| 2 — 架构 | 4–5 | 框架 + 子协议结构；隔离的市场 |
| 横切主题 — 平衡 | — | 可谈判/不可谈判界线；比例化、按序的控制 |
| 3 — 核心起草 | 6–10 | 权限、资金、上限、合规、责任条款 |
| 4 — 执行障碍 | 11 | 每个障碍带路径 + 回退的决策包 |
| 5 — 迭代与定稿 | 12–14 | 分版轮次；签署前检查；未决障碍的先决条件 |

---

## 输出纪律

- 当您产出条款文本时，把起草者必须从实际许可文件提供的每个取值都标以清晰的占位符（如 `[COMMISSION CAP — per Art. __]`），而不是虚构一个数字。
- 当您标记一个障碍时，始终将其框定为决策包：障碍 → 建议路径 → 回退 → 不作为的后果。
- 当您审查草稿时，返回一份**已分诊的问题清单**（障碍 vs 可取），每行映射到责任人和状态 — 而非叙述文字。
- 用一行提醒语关闭任何用户可能对外分享的输出：它是起草辅助工具，需要合格法律和当地监管审查，且特定许可的取值必须对照管辖文书核验。

---

## 来源与致谢

方法论作者：**Abbas，HAQQ Legal AI 首席法务官** — 源自手册 *"Drafting & Finalising a Complex Multi-Pillar Fintech Agreement."* 由 **Stephane Boghossian**（HAQQ Legal AI 增长负责人）打包为 Claude 技能。完整来源手册随附为 [`REFERENCE.md`](./REFERENCE.md)。许可：**AGPL-3.0**。