Transfer amount input silently truncates sub-cent precision instead of rejecting it

On the Transfer form, enter 10.005 as the amount and submit. Expect a validation error. Actual: the transfer submits successfully for a rounded amount with no warning.

Account balance shown on the client dashboard does not refresh after a successful transfer

Note the checking account balance, transfer $10 out, and check the balance shown on the dashboard immediately after the success toast. Actual: balance is unchanged; a manual reload shows the correct lower balance.

Transfer submit button is not disabled while a request is in flight, allowing duplicate submissions

On the Transfer form, fill valid fields and double-click Submit quickly. Inspect the network tab. Actual: two POST requests fire instead of one.

Teller-only internal note field is included in the client-facing account payload

Log in as the client demo user, open the Accounts view, inspect the Network tab response for GET /api/banking/accounts. Actual: each account object includes an internalNote field with teller-only text.

Concurrent transfers from the same account can both pass the balance check and overdraw the account

Fire two concurrent POST /api/banking/transfers requests from acct-3001 (balance $450.12) for $300 each. Expect the second to fail with insufficient funds. Actual: both succeed, leaving the account balance negative.

Idempotency-Key header on the transfer endpoint is accepted but not enforced

POST /api/banking/transfers twice with the same body and the same Idempotency-Key header. Expect one transfer to post. Actual: two separate transactions are created and the balance is debited twice.

Repeated small transfers accumulate floating-point drift in the stored account balance

Transfer $0.10 out of acct-2001 ten times in a row via the API and sum the expected debit ($1.00). Compare the account's final balanceCents to balanceCents_before - 100. Actual: off by 1 cent after repeated transfers due to float round-trip.

The teller approval-queue endpoint does not verify the caller holds the teller/admin playground session

Log in as the client demo user (not the teller). Send POST /api/banking/admin/approvals/appr-5001/decision with {"decision":"approved"} directly. Expect 403. Actual: 200, and the transfer is approved.

Transfer endpoint accepts a negative amount and credits the sender instead of rejecting the request

POST /api/banking/transfers with amountCents: -5000. Expect 400. Actual: 200, and both accounts' balances increase.

Transfer endpoint allows outbound transfers from an account still in pending_review (KYC-pending) status

POST /api/banking/transfers from acct-4001 (status pending_review) for $10. Expect 403. Actual: 200, and the transfer succeeds.

GET /api/banking/accounts/:id returns account data for an account the session's customer does not own

As the client demo user (owns acct-1001/acct-1002), GET /api/banking/accounts/acct-2001 (owned by a different customer). Expect 403/404. Actual: 200 with acct-2001's real balance.

Transaction history pagination skips a page of results

GET /api/banking/transactions?accountId=acct-1001&page=1&pageSize=2 then page=2&pageSize=2. Expect page 2 to start where page 1 left off. Actual: one transaction is skipped between pages.

Transfer endpoint ignores the account's overdraft limit and blocks any transfer exceeding the raw balance

POST /api/banking/transfers from acct-2001 (balance $968.30, overdraft limit $100.00) for $1000.00. Expect success (within overdraft). Actual: 400 insufficient funds.

Teller ledger view shows a stale balance for an account after the teller's own approval action changes it

As the teller, approve appr-5001 (a pending wire from acct-3001), then look up acct-3001 in the Customer Lookup panel. Expect the reduced balance. Actual: the balance shown is unchanged from before the approval.