Fintech Advisor
Strategic frameworks for fintech founders, operators, and product leaders. Knowledge-heavy by design — the right answer in fintech is usually a regulatory and economic judgment, not a calculation.
Disclaimer: This skill provides frameworks and orientation. It is not legal, regulatory, securities, tax, or investment advice. Every fintech business needs licensed legal counsel. Use this skill to organize internal thinking; engage specialist counsel for binding decisions.
Table of Contents
Keywords
fintech, payments, banking, neobank, lending, money transmitter, KYC, AML, PSD2, open banking, BaaS, banking-as-a-service, embedded finance, card issuing, ACH, SEPA, stablecoin, crypto, broker-dealer, RIA, regulation, compliance
Quick Start
Initial Regulatory Triage in 10 Minutes
- Write a 1-paragraph description of what your fintech does (who pays whom, in what form, who holds the funds)
- Run
python scripts/regulatory_trigger_checker.py business_description.txt
- Use the output as input to a conversation with a fintech-licensed lawyer — never as the conclusion
License vs. Partner Decision
- Read
references/license_vs_partner_playbook.md
- For each capability you need (hold funds, issue cards, originate loans, send payments), decide: get a license, or partner with a licensed entity (BaaS, sponsor bank)
- Most early-stage fintechs partner. License only if the unit economics or moat absolutely require it.
Core Workflows
Workflow 1: Regulatory Exposure Scoping
Goal: Understand which US / EU regulatory regimes a proposed fintech business model triggers, before committing to architecture.
Steps:
- Write a clear business description: who pays whom, what is held by whom, where the entity operates
- Run the trigger checker for a quick orientation
- Map each trigger to the relevant regulator (FinCEN, OCC, state banking commissioners, SEC, CFPB, FCA, BaFin, ACPR)
- Engage specialist counsel before designing infrastructure
- Document the regulatory architecture as part of the company's compliance file
Time Estimate: 4-8 weeks of legal scoping for a meaningful new build.
Workflow 2: License vs. Partner
Goal: Decide whether to get the regulated capability yourself, or buy it from a partner.
Steps:
- List capabilities needed: KYC/identity, custody, issuing, acquiring, lending, FX, deposit-taking
- For each, score on the 4-axis grid in
license_vs_partner_playbook.md: cost, time, control, economics
- Pick partners only where the regulator-of-record relationship can survive partner failure
- Document fallback plans if the partner is ever rate-limited, deprecates, or fails
Time Estimate: 6-12 weeks for major capability decisions.
Workflow 3: KYC/AML Program Design
Goal: Build a KYC/AML program that satisfies regulators and doesn't kill conversion.
Steps:
- Read
references/kyc_aml_basics.md
- Design tiered KYC: minimal at signup, enhanced when usage patterns trigger thresholds
- Pick risk-scoring vendor (Alloy, Sardine, Persona, Onfido) and write integration plan
- Establish ongoing monitoring: transaction monitoring rules, periodic refresh, sanctions / PEP screening
- Engage MLRO (Money Laundering Reporting Officer) before going live
Time Estimate: 8-16 weeks for first-time program design.
Tools
regulatory_trigger_checker.py
Scans a business description for keywords and patterns that map to regulatory regimes in the US and EU. Output is a list of candidate triggers, not a legal opinion.
python scripts/regulatory_trigger_checker.py business_description.txt
python scripts/regulatory_trigger_checker.py business_description.txt --json
Triggers detected:
- Money transmission (state-by-state US, e-money/payment institution EU)
- Lending (CFPB, state lending licenses, EU consumer credit)
- Securities (SEC broker-dealer, RIA, EU MiFID)
- Banking / deposit-taking (OCC, FDIC, EU credit institution)
- Payment services (PSD2 in EU, FCA in UK)
- Cryptocurrency (FinCEN MSB, NYDFS BitLicense, MiCA in EU)
- Custody of customer assets
Reference Guides
references/regulatory_landscape.md — Map of US and EU fintech regulators, what each covers, common trigger patterns
references/license_vs_partner_playbook.md — When to get a license, when to partner, partner failure planning
references/kyc_aml_basics.md — KYC tiers, risk-based monitoring, MLRO role, common pitfalls
references/embedded_finance_patterns.md — BaaS architecture, distribution-led fintech, B2B2C patterns
Templates
assets/regulatory_architecture_template.md — Document template for capturing regulatory decisions and partner choices
Best Practices
- Engage fintech-specialist counsel from day one. General-purpose corporate lawyers will miss regulatory triggers. The cost of specialist counsel up front is a fraction of the cost of a regulatory mistake.
- Don't hide behind partners. Even with a BaaS provider, your customers see your brand and the regulator may look through to you. Plan for partner failure.
- State-by-state US is real. Money transmitter laws are state-level — 49 different licenses possible. Most fintechs partner to avoid this.
- Sanctions are absolute. A $100 OFAC violation can cost $10M. Sanctions screening is non-negotiable.
- Treat compliance as product. Frictionless KYC and clear customer comms about why you're asking for documents are a competitive advantage.
Integration Points
- Pairs with
c-level-advisor/cs-fundraising-advisor — investors expect a clear regulatory architecture
- Pairs with
engineering/cs-security-engineer — fintech security goes beyond standard SaaS
- Pairs with
legal/ skills for contract / partner agreements
- Pairs with
business-growth/pricing-strategy — fintech pricing has unusual constraints (interchange, FX spread, float)
1---2name: fintech-advisor3description: Strategic advisory for fintech founders on US/EU regulatory triggers, license-vs-partner, KYC/AML, and embedded finance. Use when scoping a fintech idea or regulatory exposure, or mentioning fintech, money transmitter, neobank, KYC, or PSD2.4license: MIT + Commons Clause5---6
7# Fintech Advisor
8
9Strategic frameworks for fintech founders, operators, and product leaders. Knowledge-heavy by design — the right answer in fintech is usually a regulatory and economic judgment, not a calculation.
10
11> **Disclaimer:** This skill provides frameworks and orientation. It is **not** legal, regulatory, securities, tax, or investment advice. Every fintech business needs licensed legal counsel. Use this skill to organize internal thinking; engage specialist counsel for binding decisions.
12
13---
14
15## Table of Contents
16
17- [Keywords](#keywords)
18- [Quick Start](#quick-start)
19- [Core Workflows](#core-workflows)
20- [Tools](#tools)
21- [Reference Guides](#reference-guides)
22- [Templates](#templates)
23- [Best Practices](#best-practices)
24
25---
26
27## Keywords
28
29fintech, payments, banking, neobank, lending, money transmitter, KYC, AML, PSD2, open banking, BaaS, banking-as-a-service, embedded finance, card issuing, ACH, SEPA, stablecoin, crypto, broker-dealer, RIA, regulation, compliance
30
31---
32
33## Quick Start
34
35### Initial Regulatory Triage in 10 Minutes
36
371. Write a 1-paragraph description of what your fintech does (who pays whom, in what form, who holds the funds)
382. Run `python scripts/regulatory_trigger_checker.py business_description.txt`
393. Use the output as input to a conversation with a fintech-licensed lawyer — never as the conclusion
40
41### License vs. Partner Decision
42
431. Read `references/license_vs_partner_playbook.md`
442. For each capability you need (hold funds, issue cards, originate loans, send payments), decide: get a license, or partner with a licensed entity (BaaS, sponsor bank)
453. Most early-stage fintechs partner. License only if the unit economics or moat absolutely require it.
46
47---
48
49## Core Workflows
50
51### Workflow 1: Regulatory Exposure Scoping
52
53**Goal:** Understand which US / EU regulatory regimes a proposed fintech business model triggers, before committing to architecture.
54
55**Steps:**
561. Write a clear business description: who pays whom, what is held by whom, where the entity operates
572. Run the trigger checker for a quick orientation
583. Map each trigger to the relevant regulator (FinCEN, OCC, state banking commissioners, SEC, CFPB, FCA, BaFin, ACPR)
594. Engage specialist counsel before designing infrastructure
605. Document the regulatory architecture as part of the company's compliance file
61
62**Time Estimate:** 4-8 weeks of legal scoping for a meaningful new build.
63
64### Workflow 2: License vs. Partner
65
66**Goal:** Decide whether to get the regulated capability yourself, or buy it from a partner.
67
68**Steps:**
691. List capabilities needed: KYC/identity, custody, issuing, acquiring, lending, FX, deposit-taking
702. For each, score on the 4-axis grid in `license_vs_partner_playbook.md`: cost, time, control, economics
713. Pick partners only where the regulator-of-record relationship can survive partner failure
724. Document fallback plans if the partner is ever rate-limited, deprecates, or fails
73
74**Time Estimate:** 6-12 weeks for major capability decisions.
75
76### Workflow 3: KYC/AML Program Design
77
78**Goal:** Build a KYC/AML program that satisfies regulators *and* doesn't kill conversion.
79
80**Steps:**
811. Read `references/kyc_aml_basics.md`
822. Design tiered KYC: minimal at signup, enhanced when usage patterns trigger thresholds
833. Pick risk-scoring vendor (Alloy, Sardine, Persona, Onfido) and write integration plan
844. Establish ongoing monitoring: transaction monitoring rules, periodic refresh, sanctions / PEP screening
855. Engage MLRO (Money Laundering Reporting Officer) before going live
86
87**Time Estimate:** 8-16 weeks for first-time program design.
88
89---
90
91## Tools
92
93### regulatory_trigger_checker.py
94
95Scans a business description for keywords and patterns that map to regulatory regimes in the US and EU. Output is a list of candidate triggers, **not** a legal opinion.
96
97```bash
98python scripts/regulatory_trigger_checker.py business_description.txt
99python scripts/regulatory_trigger_checker.py business_description.txt --json
100```
101
102**Triggers detected:**
103- Money transmission (state-by-state US, e-money/payment institution EU)
104- Lending (CFPB, state lending licenses, EU consumer credit)
105- Securities (SEC broker-dealer, RIA, EU MiFID)
106- Banking / deposit-taking (OCC, FDIC, EU credit institution)
107- Payment services (PSD2 in EU, FCA in UK)
108- Cryptocurrency (FinCEN MSB, NYDFS BitLicense, MiCA in EU)
109- Custody of customer assets
110
111---
112
113## Reference Guides
114
115- **`references/regulatory_landscape.md`** — Map of US and EU fintech regulators, what each covers, common trigger patterns
116- **`references/license_vs_partner_playbook.md`** — When to get a license, when to partner, partner failure planning
117- **`references/kyc_aml_basics.md`** — KYC tiers, risk-based monitoring, MLRO role, common pitfalls
118- **`references/embedded_finance_patterns.md`** — BaaS architecture, distribution-led fintech, B2B2C patterns
119
120---
121
122## Templates
123
124- **`assets/regulatory_architecture_template.md`** — Document template for capturing regulatory decisions and partner choices
125
126---
127
128## Best Practices
129
130- **Engage fintech-specialist counsel from day one.** General-purpose corporate lawyers will miss regulatory triggers. The cost of specialist counsel up front is a fraction of the cost of a regulatory mistake.
131- **Don't hide behind partners.** Even with a BaaS provider, your customers see *your* brand and the regulator may look through to you. Plan for partner failure.
132- **State-by-state US is real.** Money transmitter laws are state-level — 49 different licenses possible. Most fintechs partner to avoid this.
133- **Sanctions are absolute.** A $100 OFAC violation can cost $10M. Sanctions screening is non-negotiable.
134- **Treat compliance as product.** Frictionless KYC and clear customer comms about why you're asking for documents are a competitive advantage.
135
136---
137
138## Integration Points
139
140- Pairs with `c-level-advisor/cs-fundraising-advisor` — investors expect a clear regulatory architecture
141- Pairs with `engineering/cs-security-engineer` — fintech security goes beyond standard SaaS
142- Pairs with `legal/` skills for contract / partner agreements
143- Pairs with `business-growth/pricing-strategy` — fintech pricing has unusual constraints (interchange, FX spread, float)