Domain Architecture for FinTech
The domain model is events with monetary consequences: each billable action writes a small row — customer, kind, quantity, timestamp — keyed for per-customer aggregation. Pricing rules live as reviewed code, so the aggregation applies the rules that governed each event’s date. Balances and invoice drafts are derived records; the events underneath them are never edited, which is what makes a disputed invoice re-computable instead of arguable.
Compliance, Data Residency & Governance
Financial customers dispute invoices professionally, and regulators sample them occasionally; both want the same artefact — the event trail under a number. Because events, rules (with their git history), drafts, and approvals share the project in the European zone, a challenged charge is answered by re-running the period under its historical rules and showing the rows. Retention of the trail follows the same sweep discipline as every other financial record in the project.
Financial software lives under audit: who moved what, who approved it, and where the data sat while it happened. KERNSTACK’s contribution is structural rather than certificational — the project runs in one European zone on infrastructure the operator can name, every change arrives through a reviewed plan, and the trails auditors sample (payment events, approval decisions, export records) are tables in the same project instead of reconstructions across vendors. Statutory retention is expressed as fields and sweeps, so “kept for the required years, deletable after” is enforced by a scheduled job with a proof log.
Operational Impact on the Software Lifecycle Cloud
The monthly close changes texture: instead of reconciling three systems in a spreadsheet, finance reviews drafts the system derived, spot-checks the customers who look unusual, and approves. Engineering leaves the invoicing conversation because pricing changes are small reviewed diffs, and support answers “why this amount” from data instead of opening an investigation with the vendor.
Key Domain Entities & Workflows
- Primary FinTech Data Entities: accounts, ledger entries, payment events, supplier invoices, approval records
- Governed Lifecycle Workflows: KYC document review, payout approval, invoice approval, statement export, period close
- Integrated Platform Services: tables, functions, workers, analytics
Compare this integrated blueprint with the general Billing meter reference architecture or explore our European Sovereign Cloud guarantees.
Frequently asked questions
Yes. Events are immutable rows and pricing rules are versioned code, so the period re-derives under the rules that governed it. The recomputation and the original draft can be diffed line by line — the whole dispute becomes arithmetic.
No. The payment provider executes charges from approved drafts, and its outcomes (paid, failed, refunded) write back as events. Measurement and justification live in the project; money movement stays with the regulated specialist.
The same sweep discipline as other financial records: archive or delete on schedule, holds respected, proof logged. Meter history is financial evidence, so its retention is declared with the same care as the ledger’s.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.