Failed/rejected transactions logged with reason code

A failed authorization denial, insufficient-funds rejection, or rate-limit block is not a neutral event — it is a potential indicator of credential stuffing, account takeover, or fraud probing. If it is not logged with a reason code, your security team has no signal to detect these patterns. PCI-DSS 4.0 Req-10.2.1.7 explicitly requires logging of invalid logical access attempts. NIST 800-53 AU-2 requires logging of failed login attempts and failed authentication events. FINRA Rule 4511 requires complete books and records, which include rejected transactions. CWE-778 (Insufficient Logging) covers the failure to record security-relevant events. An attacker probing for accounts with insufficient-funds errors on micro-transactions to enumerate valid account IDs will leave no trace if rejections are silently swallowed.

Wrap every failure path in src/services/transaction.ts with an explicit log write before throwing, and define a fixed set of reason codes as a TypeScript union or enum:

type FailReason =
  | 'INSUFFICIENT_FUNDS'
  | 'ACCOUNT_FROZEN'
  | 'AUTHORIZATION_DENIED'
  | 'INVALID_INPUT'
  | 'RATE_LIMITED'
  | 'ACCOUNT_NOT_FOUND';

async function logFailure(
  userId: string, operation: string, amount: number, reason: FailReason
) {
  await db('transaction_logs').insert({
    user_id: userId, operation_type: operation, amount,
    result: 'fail', reason_code: reason,
    timestamp: new Date().toISOString()
  });
}

// In executeTransfer:
if (account.balance < amount) {
  await logFailure(userId, 'transfer', amount, 'INSUFFICIENT_FUNDS');
  throw new TransactionError('Insufficient funds');
}

A catch-all block at the route level does not satisfy this requirement — each named failure condition needs its own reason_code recorded before the exception propagates.