jpskill.com
🛠️ 開発・MCP コミュニティ

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. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

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. 複式簿記の実装

  1. 勘定科目表(資産、負債、資本、収益、費用)を定義します。
  2. 借方/貸方列を持つ仕訳帳テーブルを作成します。
  3. 残高検証(借方の合計 = 貸方の合計)を実装します。
  4. 不変の取引ログで監査証跡を追加します。
  5. 照合クエリを構築します。

2. 決済処理パイプライン

  1. 支払いリクエストと冪等性キーを検証します。
  2. 保留中の取引レコードを作成します。
  3. リトライロジックを使用して決済処理業者を呼び出します。
  4. 非同期確認のためにWebhookを処理します。
  5. 元帳エントリをアトミックに更新します。
  6. 領収書と監査ログを生成します。

3. 精度計算のセットアップ

  1. 適切な数値型(DECIMAL、NUMERIC、BigDecimal)を選択します。
  2. 通貨に基づいてスケール(小数点以下の桁数)を定義します。
  3. 管轄区域ごとの丸め規則を実装します。
  4. 計算ヘルパー関数を作成します。
  5. オーバーフロー/アンダーフローの検証を追加します。

ベストプラクティス

  • 金額は最小単位(セント、パイサ)の整数として保存します。
  • データベースの型には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

  1. Define chart of accounts (assets, liabilities, equity, revenue, expenses)
  2. Create journal entry table with debit/credit columns
  3. Implement balance validation (sum of debits = sum of credits)
  4. Add audit trail with immutable transaction logs
  5. Build reconciliation queries

2. Payment Processing Pipeline

  1. Validate payment request and idempotency key
  2. Create pending transaction record
  3. Call payment processor with retry logic
  4. Handle webhook for async confirmation
  5. Update ledger entries atomically
  6. Generate receipt and audit log

3. Precision Calculation Setup

  1. Choose appropriate numeric type (DECIMAL, NUMERIC, BigDecimal)
  2. Define scale (decimal places) based on currency
  3. Implement rounding rules per jurisdiction
  4. Create calculation helper functions
  5. 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