
Domain Fintech
Apply fintech domain rules—decimal money types, immutable ledgers, and audit-friendly Rust patterns—while implementing trading, payments, or accounting backends.
Overview
Domain FinTech is an agent skill for the Build phase that encodes fintech domain constraints—decimal precision, immutable audit trails, and transaction consistency—for Rust backend design.
Install
npx skills add https://github.com/actionbook/rust-skills --skill domain-fintechWhat is this skill?
- Layer 3 domain constraint table linking audit, precision, consistency, compliance, and reproducibility to Rust choices
- Hard rule: never use f64 for money—use rust_decimal::Decimal
- Immutable audit trail guidance via Arc<T> and event-sourcing patterns
- Double-entry consistency enforced through validated transaction types
- Trace-down links to ownership and type-driven design modules in the Actionbook stack
- 5-row domain constraints table (audit trail through reproducibility)
- 3 critical constraint blocks: financial precision, audit requirements, consistency
Adoption & trust: 700 installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are modeling money, trades, or payments in Rust and risk float rounding, mutable ledger rows, or designs that fail audit and double-entry expectations.
Who is it for?
Indie builders writing Rust APIs or services for trading, payments, ledgers, or accounting where precision and immutability are non-negotiable.
Skip if: Non-financial CRUD apps, front-end-only work, or teams that are not using Rust regardless of domain keywords.
When should I use this skill?
Building fintech apps in Rust—trading, decimal/currency math, transactions, ledgers, payments, exchange rates, precision, rounding, or accounting.
What do I get? / Deliverables
Your agent applies documented domain rules and Rust patterns (Decimal, Arc, validated transactions, tracing) before you commit domain types and ledger flows.
- Domain-aligned Rust design decisions (Decimal, Arc, transaction types)
- Constraint checklist applied to proposed models or diffs
Recommended Skills
Journey fit
FinTech constraints shape core backend modeling and types during implementation, which maps cleanly to the Build phase. The skill maps domain rules to ownership, value objects, and transaction types—backend and domain-layer concerns in Rust services.
How it compares
Domain constraint skill for Rust money logic—not a payment-gateway integration or a SOC2 audit checklist.
Common Questions / FAQ
Who is domain-fintech for?
Rust developers building fintech, trading, or payment systems who want agent guidance aligned to precision, audit, and consistency rules rather than generic backend patterns.
When should I use domain-fintech?
During Build/backend when designing transaction types, ledgers, exchange rates, or any code path that stores or computes monetary amounts in Rust.
Is domain-fintech safe to install?
The skill is declarative domain guidance without prescribed shell or network tools; confirm repo provenance and review the Security Audits panel on this Prism page before install.
SKILL.md
READMESKILL.md - Domain Fintech
# FinTech Domain > **Layer 3: Domain Constraints** ## Domain Constraints → Design Implications | Domain Rule | Design Constraint | Rust Implication | |-------------|-------------------|------------------| | Audit trail | Immutable records | Arc<T>, no mutation | | Precision | No floating point | rust_decimal | | Consistency | Transaction boundaries | Clear ownership | | Compliance | Complete logging | Structured tracing | | Reproducibility | Deterministic execution | No race conditions | --- ## Critical Constraints ### Financial Precision ``` RULE: Never use f64 for money WHY: Floating point loses precision RUST: Use rust_decimal::Decimal ``` ### Audit Requirements ``` RULE: All transactions must be immutable and traceable WHY: Regulatory compliance, dispute resolution RUST: Arc<T> for sharing, event sourcing pattern ``` ### Consistency ``` RULE: Money can't disappear or appear WHY: Double-entry accounting principles RUST: Transaction types with validated totals ``` --- ## Trace Down ↓ From constraints to design (Layer 2): ``` "Need immutable transaction records" ↓ m09-domain: Model as Value Objects ↓ m01-ownership: Use Arc for shared immutable data "Need precise decimal math" ↓ m05-type-driven: Newtype for Currency/Amount ↓ rust_decimal: Use Decimal type "Need transaction boundaries" ↓ m12-lifecycle: RAII for transaction scope ↓ m09-domain: Aggregate boundaries ``` --- ## Key Crates | Purpose | Crate | |---------|-------| | Decimal math | rust_decimal | | Date/time | chrono, time | | UUID | uuid | | Serialization | serde | | Validation | validator | ## Design Patterns | Pattern | Purpose | Implementation | |---------|---------|----------------| | Currency newtype | Type safety | `struct Amount(Decimal);` | | Transaction | Atomic operations | Event sourcing | | Audit log | Traceability | Structured logging with trace IDs | | Ledger | Double-entry | Debit/credit balance | ## Code Pattern: Currency Type ```rust use rust_decimal::Decimal; #[derive(Clone, Debug, PartialEq)] pub struct Amount { value: Decimal, currency: Currency, } impl Amount { pub fn new(value: Decimal, currency: Currency) -> Self { Self { value, currency } } pub fn add(&self, other: &Amount) -> Result<Amount, CurrencyMismatch> { if self.currency != other.currency { return Err(CurrencyMismatch); } Ok(Amount::new(self.value + other.value, self.currency)) } } ``` --- ## Common Mistakes | Mistake | Domain Violation | Fix | |---------|-----------------|-----| | Using f64 | Precision loss | rust_decimal | | Mutable transaction | Audit trail broken | Immutable + events | | String for amount | No validation | Validated newtype | | Silent overflow | Money disappears | Checked arithmetic | --- ## Trace to Layer 1 | Constraint | Layer 2 Pattern | Layer 1 Implementation | |------------|-----------------|------------------------| | Immutable records | Event sourcing | Arc<T>, Clone | | Transaction scope | Aggregate | Owned children | | Precision | Value Object | rust_decimal newtype | | Thread-safe sharing | Shared immutable | Arc (not Rc) | --- ## Related Skills | When | See | |------|-----| | Value Object design | m09-domain | | Ownership for immutable | m01-ownership | | Arc for sharing | m02-resource | | Error handling | m13-domain-error |