fintech-agreement-drafting-stephane-boghossian
An end-to-end method for drafting and finalising a complex, multi-pillar regulated fintech agreement — from intake to signature. Authored from a senior fintech lawyer's manual: a licensed payment-services provider engaging a counterparty across agent cash-in/cash-out, QR payments, wallet e-payments, and a marketplace, each with its own regulatory profile. Runs five phases and fourteen steps: regulatory mapping (activity-to-licence matrix, grey-zone classification gates), architecture (framework-plus-sub-agreement structure, ring-fenced marketplace), the regulatory–commercial balance (what flex
npx skills add lawve-ai/awesome-legal-skills --skill fintech-agreement-drafting-stephane-boghossian --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Guides the drafting of a regulated payments contract by structuring the process into intake, regulatory mapping, architecture, and phased drafting, with emphasis on separating framework terms from pillar-specific sub-agreements and addressing regulatory classification gates before drafting.
How it works
- Start with a Scope Gate to confirm this is a drafting method and that the licence terms are the source of truth.
- Phase 1 Intake & Regulatory Mapping produces an activity-to-licence matrix, classification gates, and a party-role map; identify each regulated activity (e.g., e-money issuance, agent cash-in/cash-out, QR payments, wallet e-payments).
- Step 2 resolves grey-zone classifications (e.g., QR activity) via regulator-facing positions or legal opinions; treat unresolved gates as execution blockers.
- Phase 2 Architecture prescribes a General Framework Agreement plus separate pillar sub-agreements (cash-in/cash-out, QR payments, wallet e-payments, marketplace), with an order-of-precedence clause and independent termination.
- Step 5 recommends ring-fencing the riskiest pillar (marketplace) into its own standalone agreement outside the regulated flow to avoid cross-contamination.
- Across phases, balance regulatory compliance with business practicality, avoiding drafting before regulatory mapping, and ensuring controls map to actual regulatory instruments.
When to use it
Use at project intake for a new regulated fintech deal or when restructuring a multi-pillar contract to ensure architecture, governance, and pillar independence align with licensing constraints.
What it can touch
Tools listed for use include: Read, Write, Edit, WebFetch, WebSearch. The process requires structuring outputs (activity-to-licence matrix, party-role map, framework-and-sub-agreements, grey-zone classifications) and maintaining references to the licence rather than inserting licence values.
Caveats
It states that the licence is the source of truth and refuses to invent licence-specific values or draft representations without executed evidence. It emphasizes that any execution blocker must be surfaced and not papered over; it does not provide regulator-specific outcomes or values.
# /fintech-agreement-drafting — Multi-Pillar Fintech Agreement Drafting Method You are a **drafting copilot for the lawyer on a regulated fintech matter** — not for the client, and not a substitute for the lawyer's own judgement. The matter is a deal in which a licensed payment-services provider (PSP) engages a counterparty across several distinct service lines, each carrying its own regulatory profile. The running worked example is a payments framework bundling **agent-based cash-in/cash-out, QR payments, wallet e-payments, and a marketplace integration** — but the method generalises to any regulated, multi-service fintech contract. Your job is to run a **repeatable, end-to-end method** from intake to signature. The structure follows the natural lifecycle of the matter: intake and regulatory mapping → architecture → core clause drafting → resolution of execution blockers → iteration to signature. For each step you hold three things in view: the **analytical task**, the **drafting output**, and the **traps** that delay or defeat execution. The full source manual ships alongside this skill as [`REFERENCE.md`](./REFERENCE.md). When the user wants the underlying prose, the worked tabl
- The Scope Gate (read at the start of every matter, never skip)
- Operating principles (the spine that runs through every step)
- How to drive this skill
- Step 1 — Identify each regulated activity and its licence basis
- Step 2 — Resolve classification gates early
- Step 3 — Map the parties' true roles
- Step 4 — Framework plus sub-agreements for multi-pillar deals
- Step 5 — Ring-fence the riskiest pillar
- The core tension
- Three techniques for reconciling the two
- Pushing back without breaching
- The negotiable / non-negotiable line — surface it early
- Step 6 — Allocate authority asymmetrically and explicitly
- Step 7 — Engineer the money mechanics
What does the fintech-agreement-drafting-stephane-boghossian skill do?
An end-to-end method for drafting and finalising a complex, multi-pillar regulated fintech agreement — from intake to signature. Authored from a senior fintech lawyer's manual: a licensed payment-services provider engaging a counterparty across agent cash-in/cash-out, QR payments, wallet e-payments, and a marketplace, each with its own regulatory profile. Runs five phases and fourteen steps: regulatory mapping (activity-to-licence matrix, grey-zone classification gates), architecture (framework-plus-sub-agreement structure, ring-fenced marketplace), the regulatory–commercial balance (what flex
How do I install it?
Run `npx skills add lawve-ai/awesome-legal-skills --skill fintech-agreement-drafting-stephane-boghossian --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From lawve-ai/awesome-legal-skills, a repository with 618 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.