theme-banking

name	theme-banking
description	Banking / fintech application palette: variants, pages, entities, and flows for building a varied financial app. Use when theme_preset is banking.

Banking theme

Domain

Apps that hold balances and move money between accounts. The invariants that matter — balance never goes negative without overdraft, transfers respect limits, you can only see your own accounts — are exactly where the interesting exploits live.

Application variants — pick ONE per lab

Honor any hint in theme_free_text / custom_prompt; otherwise pick one.

• Retail checking/savings — accounts, transfers, payees, statements.
• Digital wallet — balance, top-up, peer-to-peer send, request money.
• Lending / loans — loan applications, repayment schedule, balance.
• Brokerage / investing — portfolio, buy/sell orders, holdings, watchlist.
• Crypto exchange — wallets per asset, trades, deposits/withdrawals.
• Neobank / budgeting — spending categories, budgets, goals, round-ups, virtual cards.
• B2B treasury / payments — company accounts, batch payouts, approval workflow, beneficiaries.

Roles — choose the set that fits the variant

• user (account holder) — view own accounts, transfer, pay, statements.
• service — back-office/scheduled jobs (interest, settlement) where relevant.
• admin (back office) — view/adjust any account, approve large transfers.

Most exploits run as user.

Candidate pages — select a coherent subset

Size the subset to endpoint_count. Candidates: dashboard/overview, accounts list, account detail, transfer money, payees/recipients, scheduled payments, transactions/statements, statement detail, card management, dispute a charge, profile/settings, notifications, loan application & schedule (lending), portfolio / holdings / trade / watchlist (brokerage), asset wallets / deposit / withdraw / trade (crypto), admin back-office.

Candidate entities (seed tables) — select what the variant needs

• users — id, email, password_hash, role
• accounts — id, user_id, type, currency, balance_cents, overdraft_limit_cents
• transactions — id, account_id, kind, amount_cents, balance_after_cents, created_at
• transfers — id, from_account_id, to_account_id, amount_cents, status
• payees — id, user_id, name, account_number, routing (saved bill-pay / transfer recipients — a real retail-banking concept)
• scheduled_payments — id, user_id, payee_id, amount_cents, cadence, next_run_at
• cards — id, account_id, last4, status, daily_limit_cents
• statements — id, account_id, period, document_path?
• disputes — id, transaction_id, user_id, reason, status
• loans (lending) — id, user_id, principal_cents, rate_bps, status
• loan_payments (lending) — id, loan_id, amount_cents, due_at, paid_at
• holdings (brokerage/crypto) — id, user_id, symbol/asset, qty, avg_price_cents
• orders (brokerage/crypto) — id, user_id, symbol/asset, side, qty, price_cents, status
• watchlist (brokerage) — id, user_id, symbol
• wallets (crypto) — id, user_id, asset, balance
• deposits / withdrawals (crypto/wallet) — id, user_id, asset, amount, status, address?

Seed multiple users each with ≥2 accounts/holdings so cross-account exploits are possible.

Candidate user flows — select the ones matching chosen pages/features

1. Dashboard → open an account → view its transactions.
2. Transfer between own accounts → balances update.
3. Add a saved recipient (payee) → send an external transfer (limit-checked).
4. Schedule a recurring payment / standing order → it appears in upcoming.
5. Manage a card → freeze / unfreeze / change its limit.
6. View a statement → download it.
7. Dispute a transaction → status updates.
8. (lending) Apply for a loan → review the repayment schedule → make a repayment.
9. (brokerage) Search a symbol → place a buy/sell order → holdings & cash update.
10. (crypto) Deposit to an asset wallet → trade between assets → withdraw.

Candidate endpoints — a feature may span several

Endpoints are a shared surface, not owned 1:1 by a feature (a single feature often spans several, and an endpoint can back multiple features). Pick a coherent subset alongside the pages above. Grouped by area:

• accounts — GET /api/accounts, GET /api/accounts/{id}, GET /api/accounts/{id}/transactions
• transfers — POST /api/transfers, GET /api/transfers, GET /api/transfers/{id}
• payees / scheduled — GET/POST /api/payees, PUT/DELETE /api/payees/{id}, GET/POST /api/scheduled-payments
• cards — GET /api/cards, POST /api/cards/{id}/limit, POST /api/cards/{id}/freeze
• statements / disputes — GET /api/statements/{id}, POST /api/transactions/{id}/dispute
• loans (lending) — POST /api/loans, GET /api/loans/{id}, POST /api/loans/{id}/repay
• trading (brokerage/crypto) — GET /api/holdings, POST /api/orders, GET /api/orders/{id}, GET/POST /api/watchlist
• crypto — GET /api/wallets, POST /api/deposits, POST /api/withdrawals
• admin — /api/admin/accounts/{id}, POST /api/admin/transfers/{id}/approve

Where vulnerabilities fit naturally

• idor → GET /api/accounts/{id}, /api/transfers/{id}, /api/statements/{id} — read/operate on another customer's account.
• business_logic → transfer exceeding daily limit, negative/zero amount, rounding abuse, repay-into-credit, sell/withdraw more than held.
• race_condition → concurrent transfers double-spending the same balance; withdraw twice before balance settles.
• auth_bypass → reach a protected account action (e.g. a transfer) without a valid session.
• privilege_escalation → user reaching /api/admin/... back-office actions.
• idor/business_logic → set another account as the to/from of a transfer.

Diversity guidance

Pick ONE variant and a coherent subset — a wallet app and a brokerage should not share a page list. Size to endpoint_count; let theme_free_text / custom_prompt bias the variant and naming. Vary account types, currencies, and limits so two banking labs feel like different institutions.