​
Banking Readiness

CrateStack ships a coherent set of primitives that regulated workloads ask for out of the box. The set is opt-in — adding @@audit to a model, or wrapping the router in IdempotencyLayer, costs nothing for services that don’t need the guarantees.

​
What’s In

The current banking-grade slice covers:
  1. duplicate-execution protection via IdempotencyLayer backed by SqlxIdempotencyStore (Postgres) or RedisIdempotencyStore (Redis)
  2. optimistic concurrency via @version + If-Match / ETag round-tripping
  3. transactional audit log via @@audit + cratestack_audit + pluggable AuditSink
  4. explicit transaction isolation via run_in_isolated_tx + @isolation
  5. per-principal rate limiting via RateLimitLayer + InMemoryRateLimitStore (single-replica) or RedisRateLimitStore (multi-replica, via cratestack-redis)
  6. soft-delete via @@soft_delete
  7. forward-only migrations via Migration + apply_pending with checksum drift detection
  8. runtime validators (@length, @range, @email, @regex, @uri, @iso4217) with PII-safe error messages
  9. Decimal scalar with a choice of two implemented backends — rust_decimal (default, fixed-precision) or bigdecimal (arbitrary precision) — additive as of 0.8.0, so different dependents in the same build can each pick their own; see Scalars

​
What’s Not

The track stops short of:
  1. zero-downtime migration generation from schema diffs
  2. cluster-wide idempotency replication (the chosen store — Postgres primary or Redis primary — is the single source of truth; multi-region active-active needs a coordinated store plugged into the trait)
  3. signed audit chains / immutable WORM storage
  4. field-level read masking or write blocking — model-level only
  5. an HSM-backed signing or key-management abstraction
  6. a working FIPS-validated crypto provider — cratestack-pg’s crypto-aws-lc-rs Cargo feature is reserved but not implemented: enabling it is a hard compile_error!, not a working FIPS mode, pending the TLS backend becoming a genuine per-crate choice across cratestack-sqlx/cratestack-client-rust (both currently hard-select the non-FIPS ring backend); see issue #334

​
Adoption Order

Banks typically adopt these in the order risk dictates. A realistic path:
  1. start with @@audit on every mutating model — gets you the forensic trail before anything else
  2. add @version to balances, ledger entries, transfers — protects against lost updates
  3. wrap mutating routes with IdempotencyLayer — protects against duplicate execution under client retries
  4. switch transfer/settlement procedures to @isolation("serializable") — closes the read-write skew window
  5. add RateLimitLayer per principal — caps abuse without code changes per route
  6. switch hard delete to @@soft_delete where retention rules require it
Each step is independent and can be reviewed in isolation. A FIPS-validated crypto provider would be a natural seventh step once production keys move into a validated module, but cratestack-pg’s crypto-aws-lc-rs feature isn’t a working FIPS mode yet — see “What’s Not” above.
  1. Idempotency for the duplicate-execution guarantee
  2. Optimistic locking for @version + ETag flow
  3. Audit log for @@audit and the transactional outbox
  4. Transaction isolation for run_in_isolated_tx and the retry policy
  5. Rate limiting for the per-principal token bucket
  6. Soft delete for @@soft_delete semantics
  7. Migrations for the forward-only runner
  8. Validators for @length, @range, @email, @regex, @uri, @iso4217
  9. Field attributes for @readonly, @server_only, @pii, @sensitive, @version
  10. Scalars for the Decimal backend selection
  11. Crypto for the FIPS provider toggle