AI Governance for Fintech Teams

Why Fintech AI Rules Are Different

Fintech code is different from most software because errors have direct financial consequences. A rounding error in a payment processor: charges customers wrong amounts. A race condition in a transfer service: allows double-spending. A logging gap: fails a PCI DSS audit. A missing authorization check: exposes account data. These are not bugs that get fixed in the next sprint — they are compliance violations, financial losses, and trust destruction.

AI-generated code in fintech must be correct by default, not correct after review. The AI rules for fintech encode: decimal precision requirements (never use floating point for currency), transaction atomicity (every financial operation is all-or-nothing), audit trail completeness (every state change is logged with who, what, when), PCI scope awareness (which data is cardholder data, where it can flow), and regulatory patterns (KYC verification before account creation, AML checks before transfers).

The governance framework: fintech AI rules are not suggestions — they are constraints. The AI must not generate code that violates these constraints even if the developer asks for a quick shortcut. The rule file should encode: 'Never store raw card numbers. Never use float for currency. Never skip audit logging for financial operations. Never process payments without idempotency keys.'

Decimal Precision: The Number One AI Rule for Fintech

The most critical fintech AI rule: never use floating-point numbers (float, double, number) for currency calculations. 0.1 + 0.2 = 0.30000000000000004 in JavaScript, Python, Java, and every language using IEEE 754 floating point. For a payment processor handling millions of transactions: these tiny errors accumulate into real money discrepancies that fail audits.

The correct patterns by language: JavaScript/TypeScript: use a decimal library (Decimal.js, dinero.js) or store amounts as integers (cents: 1299 = $12.99). Python: use the decimal.Decimal module (from decimal import Decimal; amount = Decimal('12.99')). Java: use BigDecimal (never Double for money). Go: use shopspring/decimal or store as int64 cents. Rust: use rust_decimal crate. AI rule: 'All currency values: integer cents or decimal library. No float, no double, no JavaScript number for money. The AI must generate the correct decimal type for the project language.'

Storage and transmission: database columns for currency should be DECIMAL(19,4) or NUMERIC, not FLOAT or DOUBLE. API responses should transmit amounts as strings ('12.99') or integer cents (1299), not JSON numbers (which are floating point). AI rule: 'Database: DECIMAL type. API: string or integer representation. Never trust a float between systems.'

Transaction Atomicity and Idempotency

Every financial operation must be atomic: either it completes fully or it does not happen at all. A transfer between accounts: debit account A AND credit account B within the same database transaction. If the credit fails: the debit must roll back. AI rule: 'Financial operations: wrap in a database transaction. Use BEGIN/COMMIT/ROLLBACK. No partial state — if any step fails, everything rolls back.'

Idempotency: every payment, transfer, or charge must include an idempotency key. If the client sends the same request twice (network retry, user double-click): the operation executes exactly once. Pattern: client generates a unique key (UUID), server stores it with the operation result, duplicate requests return the cached result. AI rule: 'Payment endpoints: require an idempotency key parameter. Check for existing key before processing. Return cached result for duplicate keys. Never process a payment twice.'

Concurrency control: when multiple requests modify the same account balance simultaneously, use optimistic locking (version field on the account) or pessimistic locking (SELECT FOR UPDATE). Without locking: race conditions allow overdrafts, double-spending, or incorrect balances. AI rule: 'Account balance updates: always use locking. Optimistic (check version before update) or pessimistic (SELECT FOR UPDATE). Never read-then-write without a lock.'

PCI DSS and Regulatory Compliance Rules

PCI DSS (Payment Card Industry Data Security Standard): defines how cardholder data (card numbers, CVV, expiration dates) must be handled. The AI rule: 'Never store raw card numbers in the database. Use a payment processor (Stripe, Adyen, Braintree) that handles card data. If the application must handle card data: it enters PCI scope, requiring annual audits, network segmentation, and encryption at rest and in transit.'

Data classification: the AI must understand which fields are sensitive. Card numbers (PAN): PCI scope, never store raw. CVV: never store, period (even encrypted). Social Security numbers: PII, encrypt at rest, audit access. Account balances: financial data, audit all reads and writes. The AI rule: 'Before generating a data model: classify every field. Sensitive fields require: encryption at rest, audit logging on access, and access control checks.'

Audit logging: every financial operation must produce an audit log entry with: who (user ID, API key), what (operation type, amount, accounts), when (timestamp), result (success/failure, error details), and idempotency key. The log must be immutable (append-only, no updates or deletes). AI rule: 'Every financial endpoint: emit an audit event after the operation. Log to an append-only store. Include all context needed to reconstruct the operation.'

Fintech AI Governance Summary

Summary of AI governance rules that every fintech team should encode in their AI rule files.

• Currency: never float. Use integer cents or decimal library. DECIMAL columns in database
• Transactions: atomic (BEGIN/COMMIT/ROLLBACK). No partial financial state ever
• Idempotency: every payment/transfer requires an idempotency key. Process once, return cached
• Locking: optimistic or pessimistic locking for account balance updates. No read-then-write
• PCI: never store raw card numbers or CVV. Use payment processor tokens
• Data classification: classify every field. Sensitive fields get encryption + audit + access control
• Audit logging: append-only, immutable, every operation logged with full context
• AI constraint: these rules are not optional. The AI must not generate violating code even if asked