Ledger and balance architecture
Immutable double-entry postings, a documented chart of accounts, and balances derived from entries so every figure traces to the event that produced it.
- Double-entry
- Idempotency
- Point-in-time balances
Fintech & Financial Services
Money software that can prove its own numbers
We build payment, lending, and wealth systems on a ledger you can audit, with controls that hold up when volume, regulators, and partner banks all arrive at once.
Double-entry
ledger at the core, not a reporting view
Exactly once
payment effects under retries and replays
T+0
reconciliation against provider statements
The hard part
Why financial systems drift out of agreement
Financial products run across processors, banks, ledgers, and compliance vendors that rarely agree in real time. A retry becomes a double charge, a webhook arrives twice, a provider restates yesterday. We design one transaction model across all of it, with idempotency, reconciliation, approval controls, and evidence built into the flow rather than bolted on before an audit.
- 01
Partners disagree about reality
Processors, banks, and card networks settle on different clocks. Without a canonical model, support teams arbitrate balances by hand and month-end becomes a negotiation.
- 02
Controls arrive after the fact
Approval limits, segregation of duties, and monitoring get added once a regulator asks. Retrofitting them into a live money path is far more expensive than designing them in.
- 03
Retries turn into real money
Network timeouts are normal. Without idempotency keys and a durable state machine, a routine retry becomes a duplicated payout that someone has to claw back.
What we build
The pieces a regulated money product needs
Each area below is something we have built into production and can take ownership of end to end.
Payments, payouts, and cards
Provider-agnostic payment orchestration with routing, retries, disputes, and refunds handled as explicit states rather than exception branches.
- ACH & SEPA
- Card issuing
- Payout rails
Onboarding, KYC, and KYB
Identity, sanctions, and business verification wired into a case workflow that analysts can actually work, with decisions and evidence retained.
- Sanctions
- Document review
- Case queues
Monitoring and risk decisioning
Rules and models scoring transactions in the request path, with reason codes surfaced to operators and every decision reproducible after the fact.
- Rules engine
- Reason codes
- Replay
Reconciliation and settlement
Automated matching against provider files, aged break reporting, and a workflow for the exceptions that genuinely need a human.
- Break detection
- Statement ingest
- Ageing
Reporting and audit evidence
Regulatory and financial reporting generated from the same ledger the product runs on, so operations and compliance never diverge.
- Audit trail
- Reg reporting
- Exports
Technology
What we build financial systems with
Chosen for correctness under concurrency, durable workflows, and evidence that survives an audit.
- 01
Product surface
Interfaces that make money state legible
- Next.js
- React
- TypeScript
- Tailwind CSS
- React Native
- 02
Services and ledger
Correctness under concurrency
- Go
- Java / Kotlin
- PostgreSQL
- Temporal
- gRPC
- 03
Events and data
Durable movement between systems
- Kafka
- Debezium
- Snowflake
- dbt
- Redis
- 04
Platform and assurance
Evidence that controls are working
- AWS
- Kubernetes
- Terraform
- Vault
- OpenTelemetry
How we work
From money model to live reconciliation
Step 1
Model the money
We map accounts, entries, and every state a transaction can occupy, including the unhappy ones, before writing service code.
Step 2
Prove the invariants
Property tests and simulated provider failures confirm balances stay correct through retries, partial failures, and out-of-order webhooks.
Step 3
Wire the controls
Limits, approvals, segregation of duties, and monitoring go into the transaction path with the evidence trail they will later be audited against.
Step 4
Launch and reconcile
We run shadow reconciliation against live provider files before cutover, so day one differences are understood rather than discovered.
Questions
What finance teams ask us first
A provider reports its view of your money, not your product's obligations to each customer. Once you hold balances, split fees, or settle across more than one provider, you need your own double-entry record. It is far cheaper to start with one than to reconstruct history later from provider exports.
Build the money system you can explain
Tell us where balances, payments, or reconciliation are costing you time. We will come back with an architecture and a first slice worth shipping.