Financial Market Master
This skill helps bank developers and Business Analysts understand financial market business knowledge in the context of banking IT systems.
When to Use
This skill is triggered when users:
- Ask about financial market concepts (derivatives, FX, fixed income, equity)
- Need to understand trade lifecycle processes
- Want to learn about collateral management and margin calls
- Seek knowledge about regulatory requirements
- Need business context for building trading/settlement systems
Core Workflow
Step 1: Identify the Domain
Determine which financial domain the user is asking about:
| Domain |
Reference File |
Topics Covered |
| Market Overview |
references/domain-overview.md |
Asset classes, market participants, infrastructure |
| Derivatives |
references/derivatives-basics.md |
Swaps, options, futures, forwards, pricing |
| Collateral |
references/collateral-management.md |
CSA, margin calls, VM/IM, eligible collateral |
| Trade Lifecycle |
references/trade-lifecycle.md |
Execution, confirmation, clearing, settlement |
| Regulations |
references/regulatory-framework.md |
EMIR, Dodd-Frank, MiFID II, Basel III, UMR |
| Risk Management |
references/risk-management.md |
VaR, PFE, CVA, Greeks, Stress Testing |
| Market Data |
references/market-data.md |
Curves, Surfaces, Fixings, Bootstrapping |
| Messaging |
references/messaging-standards.md |
SWIFT (MT/MX), FIX, FpML, ISO 20022 |
| Terminology |
references/glossary.md |
Financial terms A-Z |
Step 2: Load Relevant Reference
MANDATORY: Based on the domain identified, you MUST read the entire reference file before generating content:
| If user asks about... |
MUST READ |
Do NOT Load |
| CSA, margin, collateral, VM/IM |
references/collateral-management.md |
trade-lifecycle, derivatives |
| Swaps, options, futures, forwards |
references/derivatives-basics.md |
collateral, regulatory |
| Trade confirmation, clearing, settlement |
references/trade-lifecycle.md |
market-data, messaging |
| EMIR, Dodd-Frank, UMR, Basel |
references/regulatory-framework.md |
derivatives, market-data |
| VaR, PFE, CVA, Greeks |
references/risk-management.md |
messaging, regulatory |
| Curves, Surfaces, Fixings |
references/market-data.md |
collateral, regulatory |
| SWIFT, FIX, FpML, ISO 20022 |
references/messaging-standards.md |
risk-management |
| Term definitions |
references/glossary.md |
(load in addition to domain file) |
⚠️ NEVER generate content without loading the relevant reference first.
Step 2.5: Detect User Persona
Adapt content depth based on the user's role (inferred from context or explicit):
| Persona |
Focus |
Detection Hints |
| Developer |
Data Models, API fields, Message schemas |
mentions "database", "API", "schema" |
| Business Analyst |
Business Rules, CSA Clauses, Workflow logic |
mentions "requirement", "workflow", "stakeholder" |
| Operations |
Daily processes, Exception handling |
mentions "daily run", "exception", "dispute" |
| General |
Conceptual understanding |
no specific role indicators |
Step 3: Context-Driven Explanation
Always connect business purpose → concept definition → practical example → IT system impact.
Step 4: Verify Content (Self-Correction)
CRITICAL: Before generating the final document, verify your mental draft against the loaded reference file:
- Term Check: Are all used terms present in the reference or standard industry glossaries?
- Logic Check: Does the explained flow match the "Money/Asset Flow" framework?
- Hallucination Check: Did I drag in a concept from a different domain (e.g., applying Equity rules to IRS)?
Step 5: Generate Learning Document
Always generate a comprehensive learning document following these guidelines:
IMPORTANT OUTPUT RULES:
- Do NOT include instruction labels like "(REQUIRED)", "(DYNAMIC)", "(if applicable)" in output
- Table of Contents must have clickable links (
#section-name) matching actual generated sections
- References section must link to REAL external URLs (official docs, not placeholders)
- Replace all
[Topic], [Concept A] placeholders with actual content
MANDATORY - READ ENTIRE FILE: Before generating the document, you MUST load templates/learning-guide-template.md for the complete structure and formatting rules.
Key Requirements:
- Always include: Overview, Core Concepts, System Implementation, Real-World Scenarios, Appendix
- Add Lifecycle section for process/flow topics
- Add Comparison sections for explaining differences (VM vs IM, Pledge vs Title Transfer)
- Add Calculation section for topics with formulas
- All References URLs must be REAL, verifiable links (no placeholders)
Step 6: Save to Project Docs Directory (REQUIRED)
You MUST save the generated learning document to the project's docs directory.
Output Path Convention:
docs/fm-guide/[topic-name]-guide.md
Naming Rules:
- Use lowercase with hyphens for topic name
- Always suffix with
-guide.md
- Group under
fm-guide subdirectory
Examples:
| Topic |
Output Path |
| Margin Call |
docs/fm-guide/margin-call-guide.md |
| CSA |
docs/fm-guide/csa-guide.md |
| Acadia |
docs/fm-guide/acadia-guide.md |
| Trade Lifecycle |
docs/fm-guide/trade-lifecycle-guide.md |
| ISDA SIMM |
docs/fm-guide/isda-simm-guide.md |
After saving, notify the user with the file path so they can review the generated document.
Step 7: Ensure Document Viewer Exists (REQUIRED)
Before finishing, you MUST check and copy the viewer.html.
- Check if
docs/fm-guide/viewer.html exists in the project
- If NOT exists, copy from skill templates:
- Source:
fm-knowledge-guide/templates/viewer.html
- Destination:
docs/fm-guide/viewer.html
Implementation:
# Check and copy viewer.html if not exists
if (!(Test-Path "docs/fm-guide/viewer.html")) {
Copy-Item "<skill-path>/templates/viewer.html" "docs/fm-guide/viewer.html"
}
This ensures the document viewer is always available for browsing generated guides.
The viewer dynamically lists all .md files in the same directory.
Step 8: Launch Document Viewer (OPTIONAL)
If the user wants to view documents in browser, launch a local HTTP server:
npx -y http-server docs/fm-guide -p 0 -o /viewer.html
Options:
-p 0: Use any available port
-o /viewer.html: Auto-open browser to viewer
Viewer Features:
- Dynamically lists all
.md files in the directory
- Left sidebar for navigation
- Right panel renders Markdown with Mermaid diagrams
- Dark theme with modern UI
Topic Quick Reference
Derivatives
- Swaps: Interest Rate Swaps (IRS), Cross Currency Swaps (CCS), FX Swaps
- Options: Vanilla options, exotic options, swaptions
- Futures/Forwards: Exchange-traded vs OTC
Collateral Management
- CSA: Credit Support Annex under ISDA Master Agreement
- Margin Types: Variation Margin (VM), Initial Margin (IM)
- Margin Call Flow: Call → Agree → Pledge → Settle
Trade Lifecycle
- Pre-trade: Pricing, credit check
- Execution: Trade capture, booking
- Post-trade: Confirmation, matching, clearing, settlement
Key Dates
- Trade Date (T): When the trade is executed
- Value Date: When the trade takes economic effect
- Settlement Date: When cash/securities move
- Maturity Date: When the trade ends
Analyst Mindset & Research (New Frameworks)
When acting as a Bank Analyst, use these thinking frameworks before generating content:
1. Risk-First Thinking
"Who carries the risk if this fails?"
- Always identify Credit Risk (counterparty default) vs Operational Risk (process failure).
- Explain mechanics in terms of risk mitigation.
2. The Money/Asset Flow
"Where is the asset moving?"
- Trace the exact movement of cash/securities.
- Identify the legal ownership at each step (Pledge vs Title Transfer).
3. System Impact Analysis
"What breaks if this field is wrong?"
- Connect business concepts to specific database fields or API messages (SWIFT/FIX).
- Highlight "Load Bearing" data points (e.g., Trade Date, Notional).
4. Research Methodology
- Source of Truth: Prioritize ISDA, FpML, and Regulatory Texts (EMIR/Dodd-Frank).
- Cross-Check: Verify definitions across multiple jurisdictions (US vs EU often differ).
- Concrete Examples: Never leave a concept abstract; always provide a numerical or process example.
Anti-Patterns (NEVER List)
CRITICAL: The following behaviors ruin the credibility of the output.
- NEVER Invent Terms: If you don't know the industry standard term (e.g., "Variation Margin"), do not invent one (e.g., "Daily Collateral Adjustment"). Use the
glossary.md reference.
- NEVER Mix Jurisdictions: Do not blend US rules (Dodd-Frank) with EU rules (EMIR) without explicit distinction. They have different reporting fields and timelines.
- NEVER Assume Simple Interest: In financial markets, interest is almost always compounded or calculated with specific day-count conventions (ACT/360, 30/360, ACT/365).
- NEVER Ignore Settlement Lag: Trades rarely settle instantly (T+0). Always account for T+1, T+2 settlement cycles in process flows.
- NEVER Confuse VM and IM: Variation Margin (daily MTM settlement) ≠ Initial Margin (upfront risk buffer). They have different calculation methods, timing, and regulatory drivers.
- NEVER Omit Day Count Convention: Interest calculations MUST explicitly specify the convention (ACT/360 for money markets, 30/360 for bonds, ACT/365 for some jurisdictions).
- NEVER Ignore Netting Agreements: Gross vs Net exposure under ISDA CSA can differ by 10x+. Always clarify whether values are gross or net.
- NEVER Use Placeholder Links: All URLs in References section must be real, verifiable sources. Search for actual official documentation URLs.
Output Guidelines
- Use clear, precise financial terminology
- Include diagrams for complex flows (Mermaid format)
- Provide both business and technical perspectives
- Always cite concepts' practical implications for IT systems
Diagram Guidelines (REQUIRED)
Always use Mermaid format for all diagrams to ensure consistent styling across documents.
Supported Diagram Types
| Diagram Type |
Use Case |
Syntax |
flowchart |
Process flows, decision trees |
flowchart LR or flowchart TB |
sequenceDiagram |
Message exchanges, API calls |
sequenceDiagram |
graph |
Architecture, relationships |
graph TB or graph LR |
stateDiagram-v2 |
State machines, lifecycle |
stateDiagram-v2 |
Example Patterns
Process Flow:
flowchart LR
A[Start] --> B[Process] --> C[End]
Sequence Diagram:
sequenceDiagram
participant A as System A
participant B as System B
A->>B: Request
B-->>A: Response
Architecture Diagram:
graph TB
subgraph "Component"
A[Module A]
B[Module B]
end
A --> B
Style Rules
- Use subgraphs to group related components
- Add labels with
<br/> for multi-line text in nodes
- Keep diagrams focused - one concept per diagram
- Use consistent direction - LR for flows, TB for hierarchies
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: fm-knowledge-guide3description: Comprehensive guide for bank developers and Business Analysts (BAs) to master financial market business knowledge. Use this skill when users ask about derivatives (swaps, options, futures), collateral management (CSA, margin calls, VM/IM), trade lifecycle (confirmation, clearing, settlement), FX operations, fixed income, regulatory frameworks (EMIR, Dodd-Frank, UMR), or any financial market concepts they need to understand for building banking systems. Use when this capability is needed.4---56# Financial Market Master78This skill helps bank developers and Business Analysts understand financial market business knowledge in the context of banking IT systems.910## When to Use1112This skill is triggered when users:13- Ask about financial market concepts (derivatives, FX, fixed income, equity)14- Need to understand trade lifecycle processes15- Want to learn about collateral management and margin calls16- Seek knowledge about regulatory requirements17- Need business context for building trading/settlement systems1819## Core Workflow2021### Step 1: Identify the Domain2223Determine which financial domain the user is asking about:2425| Domain | Reference File | Topics Covered |26|--------|----------------|----------------|27| Market Overview | `references/domain-overview.md` | Asset classes, market participants, infrastructure |28| Derivatives | `references/derivatives-basics.md` | Swaps, options, futures, forwards, pricing |29| Collateral | `references/collateral-management.md` | CSA, margin calls, VM/IM, eligible collateral |30| Trade Lifecycle | `references/trade-lifecycle.md` | Execution, confirmation, clearing, settlement |31| Regulations | `references/regulatory-framework.md` | EMIR, Dodd-Frank, MiFID II, Basel III, UMR |32| Risk Management | `references/risk-management.md` | VaR, PFE, CVA, Greeks, Stress Testing |33| Market Data | `references/market-data.md` | Curves, Surfaces, Fixings, Bootstrapping |34| Messaging | `references/messaging-standards.md` | SWIFT (MT/MX), FIX, FpML, ISO 20022 |35| Terminology | `references/glossary.md` | Financial terms A-Z |3637### Step 2: Load Relevant Reference3839**MANDATORY**: Based on the domain identified, you MUST read the entire reference file before generating content:4041| If user asks about... | MUST READ | Do NOT Load |42|-----------------------|-----------|-------------|43| CSA, margin, collateral, VM/IM | `references/collateral-management.md` | trade-lifecycle, derivatives |44| Swaps, options, futures, forwards | `references/derivatives-basics.md` | collateral, regulatory |45| Trade confirmation, clearing, settlement | `references/trade-lifecycle.md` | market-data, messaging |46| EMIR, Dodd-Frank, UMR, Basel | `references/regulatory-framework.md` | derivatives, market-data |47| VaR, PFE, CVA, Greeks | `references/risk-management.md` | messaging, regulatory |48| Curves, Surfaces, Fixings | `references/market-data.md` | collateral, regulatory |49| SWIFT, FIX, FpML, ISO 20022 | `references/messaging-standards.md` | risk-management |50| Term definitions | `references/glossary.md` | (load in addition to domain file) |5152> ⚠️ **NEVER generate content without loading the relevant reference first.**5354### Step 2.5: Detect User Persona5556**Adapt content depth based on the user's role** (inferred from context or explicit):5758| Persona | Focus | Detection Hints |59|---------|-------|------------------|60| **Developer** | Data Models, API fields, Message schemas | mentions "database", "API", "schema" |61| **Business Analyst** | Business Rules, CSA Clauses, Workflow logic | mentions "requirement", "workflow", "stakeholder" |62| **Operations** | Daily processes, Exception handling | mentions "daily run", "exception", "dispute" |63| **General** | Conceptual understanding | no specific role indicators |6465### Step 3: Context-Driven Explanation6667> Always connect business purpose → concept definition → practical example → IT system impact.6869### Step 4: Verify Content (Self-Correction)7071**CRITICAL**: Before generating the final document, verify your mental draft against the loaded reference file:721. **Term Check**: Are all used terms present in the reference or standard industry glossaries?732. **Logic Check**: Does the explained flow match the "Money/Asset Flow" framework?743. **Hallucination Check**: Did I drag in a concept from a different domain (e.g., applying Equity rules to IRS)?7576### Step 5: Generate Learning Document7778**Always generate a comprehensive learning document** following these guidelines:7980> **IMPORTANT OUTPUT RULES**:81> 1. Do NOT include instruction labels like "(REQUIRED)", "(DYNAMIC)", "(if applicable)" in output82> 2. Table of Contents must have clickable links (`#section-name`) matching actual generated sections83> 3. References section must link to REAL external URLs (official docs, not placeholders)84> 4. Replace all `[Topic]`, `[Concept A]` placeholders with actual content8586**MANDATORY - READ ENTIRE FILE**: Before generating the document, you MUST load [`templates/learning-guide-template.md`](templates/learning-guide-template.md) for the complete structure and formatting rules.8788**Key Requirements**:89- Always include: Overview, Core Concepts, System Implementation, Real-World Scenarios, Appendix90- Add Lifecycle section for process/flow topics91- Add Comparison sections for explaining differences (VM vs IM, Pledge vs Title Transfer)92- Add Calculation section for topics with formulas93- All References URLs must be REAL, verifiable links (no placeholders)9495### Step 6: Save to Project Docs Directory (REQUIRED)9697**You MUST save the generated learning document to the project's docs directory.**9899**Output Path Convention**:100```101docs/fm-guide/[topic-name]-guide.md102```103104**Naming Rules**:105- Use lowercase with hyphens for topic name106- Always suffix with `-guide.md`107- Group under `fm-guide` subdirectory108109**Examples**:110| Topic | Output Path |111|-------|-------------|112| Margin Call | `docs/fm-guide/margin-call-guide.md` |113| CSA | `docs/fm-guide/csa-guide.md` |114| Acadia | `docs/fm-guide/acadia-guide.md` |115| Trade Lifecycle | `docs/fm-guide/trade-lifecycle-guide.md` |116| ISDA SIMM | `docs/fm-guide/isda-simm-guide.md` |117118**After saving**, notify the user with the file path so they can review the generated document.119120### Step 7: Ensure Document Viewer Exists (REQUIRED)121122**Before finishing, you MUST check and copy the viewer.html.**1231241. Check if `docs/fm-guide/viewer.html` exists in the project1252. If NOT exists, copy from skill templates:126 - Source: `fm-knowledge-guide/templates/viewer.html`127 - Destination: `docs/fm-guide/viewer.html`128129**Implementation**:130```powershell131# Check and copy viewer.html if not exists132if (!(Test-Path "docs/fm-guide/viewer.html")) {133 Copy-Item "<skill-path>/templates/viewer.html" "docs/fm-guide/viewer.html"134}135```136137This ensures the document viewer is always available for browsing generated guides.138The viewer dynamically lists all .md files in the same directory.139140### Step 8: Launch Document Viewer (OPTIONAL)141142If the user wants to view documents in browser, launch a local HTTP server:143144```bash145npx -y http-server docs/fm-guide -p 0 -o /viewer.html146```147148**Options**:149- `-p 0`: Use any available port150- `-o /viewer.html`: Auto-open browser to viewer151152**Viewer Features**:153- Dynamically lists all `.md` files in the directory154- Left sidebar for navigation155- Right panel renders Markdown with Mermaid diagrams156- Dark theme with modern UI157158159## Topic Quick Reference160161### Derivatives162- **Swaps**: Interest Rate Swaps (IRS), Cross Currency Swaps (CCS), FX Swaps163- **Options**: Vanilla options, exotic options, swaptions164- **Futures/Forwards**: Exchange-traded vs OTC165166### Collateral Management167- **CSA**: Credit Support Annex under ISDA Master Agreement168- **Margin Types**: Variation Margin (VM), Initial Margin (IM)169- **Margin Call Flow**: Call → Agree → Pledge → Settle170171### Trade Lifecycle172- **Pre-trade**: Pricing, credit check173- **Execution**: Trade capture, booking174- **Post-trade**: Confirmation, matching, clearing, settlement175176### Key Dates177- **Trade Date (T)**: When the trade is executed178- **Value Date**: When the trade takes economic effect179- **Settlement Date**: When cash/securities move180- **Maturity Date**: When the trade ends181182## Analyst Mindset & Research (New Frameworks)183184When acting as a Bank Analyst, use these thinking frameworks before generating content:185186### 1. Risk-First Thinking187> "Who carries the risk if this fails?"188- Always identify Credit Risk (counterparty default) vs Operational Risk (process failure).189- Explain mechanics in terms of risk mitigation.190191### 2. The Money/Asset Flow192> "Where is the asset moving?"193- Trace the exact movement of cash/securities.194- Identify the legal ownership at each step (Pledge vs Title Transfer).195196### 3. System Impact Analysis197> "What breaks if this field is wrong?"198- Connect business concepts to specific database fields or API messages (SWIFT/FIX).199- Highlight "Load Bearing" data points (e.g., Trade Date, Notional).200201### 4. Research Methodology2021. **Source of Truth**: Prioritize ISDA, FpML, and Regulatory Texts (EMIR/Dodd-Frank).2032. **Cross-Check**: Verify definitions across multiple jurisdictions (US vs EU often differ).2043. **Concrete Examples**: Never leave a concept abstract; always provide a numerical or process example.205206## Anti-Patterns (NEVER List)207208> **CRITICAL**: The following behaviors ruin the credibility of the output.2092101. **NEVER Invent Terms**: If you don't know the industry standard term (e.g., "Variation Margin"), do not invent one (e.g., "Daily Collateral Adjustment"). Use the `glossary.md` reference.2112. **NEVER Mix Jurisdictions**: Do not blend US rules (Dodd-Frank) with EU rules (EMIR) without explicit distinction. They have different reporting fields and timelines.2123. **NEVER Assume Simple Interest**: In financial markets, interest is almost always compounded or calculated with specific day-count conventions (ACT/360, 30/360, ACT/365).2134. **NEVER Ignore Settlement Lag**: Trades rarely settle instantly (T+0). Always account for T+1, T+2 settlement cycles in process flows.2145. **NEVER Confuse VM and IM**: Variation Margin (daily MTM settlement) ≠ Initial Margin (upfront risk buffer). They have different calculation methods, timing, and regulatory drivers.2156. **NEVER Omit Day Count Convention**: Interest calculations MUST explicitly specify the convention (ACT/360 for money markets, 30/360 for bonds, ACT/365 for some jurisdictions).2167. **NEVER Ignore Netting Agreements**: Gross vs Net exposure under ISDA CSA can differ by 10x+. Always clarify whether values are gross or net.2178. **NEVER Use Placeholder Links**: All URLs in References section must be real, verifiable sources. Search for actual official documentation URLs.218219## Output Guidelines220221- Use clear, precise financial terminology222- Include diagrams for complex flows (Mermaid format)223- Provide both business and technical perspectives224- Always cite concepts' practical implications for IT systems225226## Diagram Guidelines (REQUIRED)227228**Always use Mermaid format** for all diagrams to ensure consistent styling across documents.229230### Supported Diagram Types231232| Diagram Type | Use Case | Syntax |233|--------------|----------|--------|234| `flowchart` | Process flows, decision trees | `flowchart LR` or `flowchart TB` |235| `sequenceDiagram` | Message exchanges, API calls | `sequenceDiagram` |236| `graph` | Architecture, relationships | `graph TB` or `graph LR` |237| `stateDiagram-v2` | State machines, lifecycle | `stateDiagram-v2` |238239### Example Patterns240241**Process Flow**:242```mermaid243flowchart LR244 A[Start] --> B[Process] --> C[End]245```246247**Sequence Diagram**:248```mermaid249sequenceDiagram250 participant A as System A251 participant B as System B252 A->>B: Request253 B-->>A: Response254```255256**Architecture Diagram**:257```mermaid258graph TB259 subgraph "Component"260 A[Module A]261 B[Module B]262 end263 A --> B264```265266### Style Rules2672681. **Use subgraphs** to group related components2692. **Add labels** with `<br/>` for multi-line text in nodes2703. **Keep diagrams focused** - one concept per diagram2714. **Use consistent direction** - LR for flows, TB for hierarchies272273---274> Converted and distributed by [TomeVault](https://tomevault.io/claim/kooooooma) — claim your Tome and manage your conversions.275<!-- tomevault:4.0:skill_md:2026-04-11 -->