Fintech Champion Advisor

Your agent for financial technology development — covering payment processing, banking APIs, compliance requirements, and secure financial application architecture.

When to Use This Agent

Choose Fintech Champion Advisor when:

• Integrating payment processors (Stripe, PayPal, Adyen, Square)
• Building financial applications with regulatory compliance (PCI-DSS, SOX, KYC/AML)
• Designing secure money transfer, ledger, or transaction systems
• Implementing banking APIs (Plaid, Open Banking, ACH, SWIFT)
• Building cryptocurrency or blockchain integrations

Consider alternatives when:

• You need general backend development — use a backend developer agent
• You need cloud infrastructure — use a cloud architect agent
• You need data analytics — use a data science agent

Quick Start

Copy
# .claude/agents/fintech-champion.yml
name: Fintech Champion Advisor
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: Fintech development agent for payment integration, banking APIs, compliance, and secure financial architecture

Example invocation:

claude "Design a payment processing system that integrates Stripe for card payments, handles webhook events idempotently, manages subscription billing, and complies with PCI-DSS requirements"

Core Concepts

Fintech Architecture Layers

Layer	Components	Requirements
Presentation	Payment forms, dashboards	PCI-compliant UI, no card data in DOM
API	Payment endpoints, webhooks	Idempotency, rate limiting, auth
Processing	Payment orchestration, routing	Retry logic, circuit breakers
Ledger	Transaction records, balances	Double-entry bookkeeping, audit trail
Compliance	KYC/AML, PCI-DSS, reporting	Data encryption, access controls

Payment Processing Flow

Customer → Tokenize Card (client-side)
  → Create PaymentIntent (server-side)
  → Confirm Payment (payment processor)
  → Webhook: payment_succeeded
  → Update ledger + send receipt
  → Webhook: payout.paid (settlement)

Error handling:
  → payment_failed → Retry or notify customer
  → charge.dispute → Automated evidence collection
  → Webhook missed → Polling fallback

Configuration

Parameter	Description	Default
payment_processor	Primary processor (stripe, adyen, paypal)	stripe
compliance_level	Compliance requirements (pci-saq-a, pci-saq-d, full)	pci-saq-a
currency	Primary currency	USD
ledger_type	Accounting model (single-entry, double-entry)	double-entry
webhook_strategy	Webhook handling (sync, async-queue, idempotent)	idempotent

Best Practices

1. Never handle raw card data on your servers. Use client-side tokenization (Stripe.js, Adyen Drop-in) to convert card details into tokens before they reach your backend. This keeps you at PCI SAQ-A (simplest compliance level) instead of SAQ-D (full audit).

2. Make every payment operation idempotent. Network failures cause duplicate requests. Use idempotency keys on all payment API calls so that retrying a failed request doesn't create duplicate charges. Stripe and most processors support idempotency headers natively.

3. Implement double-entry bookkeeping for all financial transactions. Every debit has a corresponding credit. This catches accounting errors, simplifies reconciliation, and provides an audit trail. Use a ledger table where every transaction creates two rows (debit and credit).

4. Process webhooks asynchronously with at-least-once delivery. Payment webhooks may be delivered out of order, duplicated, or delayed. Queue webhooks for async processing, store the event ID to detect duplicates, and design handlers to be idempotent.

5. Encrypt all financial data at rest and in transit. PCI-DSS mandates encryption for cardholder data. Use TLS 1.2+ for all API calls, AES-256 for data at rest, and never log card numbers, CVVs, or full account numbers — even in error messages.

Common Issues

Webhook events arrive out of order. A payment_intent.succeeded may arrive before payment_intent.created due to network timing. Design webhook handlers to be order-independent — check the current state of the resource (via API) rather than assuming a sequence.

Currency precision causes rounding errors. Never use floating-point types for money. Use integer cents (1234 = $12.34) or a dedicated money library. Floating-point arithmetic introduces rounding errors that compound across thousands of transactions.

Subscription renewals fail silently. Card expiration, insufficient funds, or bank declines cause renewal failures. Implement dunning logic: retry failed payments on a schedule (days 1, 3, 7), notify the customer, and suspend the account gracefully after repeated failures.