fintech-engineer
金融システムの設計から規制対応、高精度な計算まで、フィンテック開発全般を支援するSkill。
📜 元の英語説明(参考)
Expert in financial technology systems, double-entry ledger design, high-precision math, and regulatory compliance. Use when building payment systems, ledger architectures, financial calculations, PCI compliance, or banking integrations. Triggers include "fintech", "ledger", "double-entry", "financial calculations", "PCI compliance", "banking API".
🇯🇵 日本人クリエイター向け解説
金融システムの設計から規制対応、高精度な計算まで、フィンテック開発全般を支援するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-17
- 取得日時
- 2026-05-17
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
フィンテックエンジニア
目的
適切な会計原則、規制遵守、高精度な計算を備えた金融テクノロジーシステムの構築に関する専門的なガイダンスを提供します。元帳設計、決済処理アーキテクチャ、および財務データの整合性に特化しています。
使用する場面
- 複式簿記システムまたは会計データベースの設計
- 高精度な金融計算の実装(浮動小数点エラーの回避)
- 決済処理パイプラインの構築
- PCI-DSSまたはSOXコンプライアンスの確保
- 銀行API(Plaid、Stripeなど)との連携
- 通貨換算および多通貨システムの処理
- 金融取引の監査証跡の実装
- 照合システムの設計
クイックスタート
このスキルを呼び出すのは、以下の場合です。
- 元帳または会計システムを構築する場合
- 精度を要する金融計算を実装する場合
- 決済処理アーキテクチャを設計する場合
- 規制遵守(PCI、SOX、PSD2)を確保する場合
- 銀行または決済APIを統合する場合
以下の場合には呼び出さないでください。
- 金融コンテキストのない一般的なデータベース設計 →
/database-administratorを使用してください - 金融に特化しないAPI統合 →
/api-designerを使用してください - 一般的なセキュリティ強化 →
/security-engineerを使用してください - MLベースの不正検出モデル →
/ml-engineerを使用してください
意思決定フレームワーク
Financial Calculation Needed?
├── Yes: Currency/Money
│ └── Use decimal types (never float)
│ └── Store amounts in smallest unit (cents)
├── Yes: Interest/Rates
│ └── Use arbitrary precision libraries
│ └── Document rounding rules explicitly
└── Ledger Design?
├── Simple: Single-entry (tracking only)
└── Auditable: Double-entry (debits = credits)
主要なワークフロー
1. 複式簿記の実装
- 勘定科目表(資産、負債、資本、収益、費用)を定義します。
- 借方/貸方列を持つ仕訳帳テーブルを作成します。
- 残高検証(借方の合計 = 貸方の合計)を実装します。
- 不変の取引ログで監査証跡を追加します。
- 照合クエリを構築します。
2. 決済処理パイプライン
- 支払いリクエストと冪等性キーを検証します。
- 保留中の取引レコードを作成します。
- リトライロジックを使用して決済処理業者を呼び出します。
- 非同期確認のためにWebhookを処理します。
- 元帳エントリをアトミックに更新します。
- 領収書と監査ログを生成します。
3. 精度計算のセットアップ
- 適切な数値型(DECIMAL、NUMERIC、BigDecimal)を選択します。
- 通貨に基づいてスケール(小数点以下の桁数)を定義します。
- 管轄区域ごとの丸め規則を実装します。
- 計算ヘルパー関数を作成します。
- オーバーフロー/アンダーフローの検証を追加します。
ベストプラクティス
- 金額は最小単位(セント、パイサ)の整数として保存します。
- データベースの型にはDECIMAL/NUMERICを使用し、FLOATは決して使用しないでください。
- すべての金融操作に冪等性を実装します。
- すべての取引について不変の監査ログを保持します。
- 複数テーブルの更新にはデータベーストランザクションを使用します。
- 丸め規則を文書化し、一貫して適用します。
アンチパターン
| アンチパターン | 問題点 | 正しいアプローチ |
|---|---|---|
| 金銭にfloatを使用する | 精度誤差が蓄積する | decimal型または整数セントを使用する |
| 可変の取引記録 | 監査証跡が破壊される | 追記専用ログ、論理削除 |
| 冪等性の欠如 | 重複請求の可能性 | すべての変更に冪等性キーを使用する |
| 監査可能なシステムに単式簿記を使用する | 照合または監査ができない | 借方と貸方が一致する複式簿記 |
| 税率をハードコードする | コンプライアンス違反 | 設定駆動型、バージョン管理された規則 |
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Fintech Engineer
Purpose
Provides expert guidance on building financial technology systems with proper accounting principles, regulatory compliance, and high-precision calculations. Specializes in ledger design, payment processing architectures, and financial data integrity.
When to Use
- Designing double-entry ledger systems or accounting databases
- Implementing high-precision financial calculations (avoiding floating-point errors)
- Building payment processing pipelines
- Ensuring PCI-DSS or SOX compliance
- Integrating with banking APIs (Plaid, Stripe, etc.)
- Handling currency conversions and multi-currency systems
- Implementing audit trails for financial transactions
- Designing reconciliation systems
Quick Start
Invoke this skill when:
- Building ledger or accounting systems
- Implementing financial calculations requiring precision
- Designing payment processing architectures
- Ensuring regulatory compliance (PCI, SOX, PSD2)
- Integrating banking or payment APIs
Do NOT invoke when:
- General database design without financial context → use
/database-administrator - API integration without financial specifics → use
/api-designer - Generic security hardening → use
/security-engineer - ML-based fraud detection models → use
/ml-engineer
Decision Framework
Financial Calculation Needed?
├── Yes: Currency/Money
│ └── Use decimal types (never float)
│ └── Store amounts in smallest unit (cents)
├── Yes: Interest/Rates
│ └── Use arbitrary precision libraries
│ └── Document rounding rules explicitly
└── Ledger Design?
├── Simple: Single-entry (tracking only)
└── Auditable: Double-entry (debits = credits)
Core Workflows
1. Double-Entry Ledger Implementation
- Define chart of accounts (assets, liabilities, equity, revenue, expenses)
- Create journal entry table with debit/credit columns
- Implement balance validation (sum of debits = sum of credits)
- Add audit trail with immutable transaction logs
- Build reconciliation queries
2. Payment Processing Pipeline
- Validate payment request and idempotency key
- Create pending transaction record
- Call payment processor with retry logic
- Handle webhook for async confirmation
- Update ledger entries atomically
- Generate receipt and audit log
3. Precision Calculation Setup
- Choose appropriate numeric type (DECIMAL, NUMERIC, BigDecimal)
- Define scale (decimal places) based on currency
- Implement rounding rules per jurisdiction
- Create calculation helper functions
- Add validation for overflow/underflow
Best Practices
- Store monetary values as integers in smallest unit (cents, paise)
- Use DECIMAL/NUMERIC database types, never FLOAT
- Implement idempotency for all financial operations
- Maintain immutable audit logs for every transaction
- Use database transactions for multi-table updates
- Document rounding rules and apply consistently
Anti-Patterns
| Anti-Pattern | Problem | Correct Approach |
|---|---|---|
| Using floats for money | Precision errors accumulate | Use decimal types or integer cents |
| Mutable transaction records | Audit trail destroyed | Append-only logs, soft deletes |
| Missing idempotency | Duplicate charges possible | Idempotency keys on all mutations |
| Single-entry for auditable systems | Cannot reconcile or audit | Double-entry with balanced journals |
| Hardcoded tax rates | Compliance failures | Configuration-driven, versioned rules |