Money movement that stays correct under retries, races, and audits
Willowark builds the correctness-critical layer of fintech products: double-entry ledgers with immutable postings, idempotent write paths that survive at-least-once delivery, reconciliation engines that match against partner and network files, and the audit history compliance asks for and most schemas cannot produce. What we remove is the class of defects that only appears at volume — the duplicate posting, the out-of-order webhook, the balance nobody can explain.
We work as contract engineers where errors are expensive. That means modeling money movement as events with double-entry postings and deriving balances rather than mutating them, making every external call idempotent with keys that survive process restarts, and writing replay tests that inject duplicates and reorder deliveries deliberately. A new ledger runs in shadow against live traffic until balances match to the cent.
A first engagement in fintech is usually a bounded correctness problem with a deadline: a reconciliation break the sponsor bank has asked about, a provider migration that has to preserve every historical transaction, or an audit request that exposed how much history lives only in logs. We start by reading the data model and the webhook handlers, because that is where the defects hide, and we write the replay tests before we change anything. Small teams under examination pressure need work that is provably correct rather than finished, so every change ships with the evidence that it is.
Reviewed
Sound familiar?
If you've said any of these, we should talk.
“Balances live in a column and we cannot explain how they got there.”
We move to immutable double-entry postings where balances are derived, not updated. Every movement carries its source event, counterparty, and resulting position, so any balance is reconstructable and any discrepancy traces to a specific posting. The migration runs as a shadow ledger until it agrees with production.
“Our provider's webhooks arrive out of order, and sometimes twice.”
That is the normal behavior of these systems, so we design for it rather than around it. Events are deduplicated on the provider's identifier, state machines tolerate any arrival order and reject illegal transitions, and every write carries an idempotency key. Reconciliation against the provider's files is the backstop.
“Reconciliation is one person and a spreadsheet at the end of every month.”
We build the matching engine: normalized ingestion of settlement, network, and partner files, configurable rules with tolerance handling, and an exception workbench showing only the breaks and the evidence behind each. Matched volume clears itself daily rather than monthly.
“Compliance asks for a trail we assemble by hand every time.”
We design systems that record what happened as append-only events — actor, action, timestamp, inputs, resulting state — so history is reconstructed rather than inferred from logs. Reports generate from that record. We engineer to your control requirements; the attestations and certifications remain yours, not ours.
“We need to switch processors and cannot lose a single historical transaction in the move.”
Provider migrations are ledger migrations in disguise. We put an abstraction between your domain and the processor first, backfill historical transactions into your own event store so history no longer depends on the outgoing vendor, then run both providers in parallel on a slice of traffic and cut over by account cohort with rollback ready.
How this industry actually runs
The operation as we usually find it.
Most fintech companies are a product team sitting on top of other people's infrastructure: a sponsor bank, a card processor or issuing platform, ACH and RTP rails, a KYC and KYB vendor, and webhook streams that promise at-least-once delivery and mean it. Engineering is small and moves fast, and the ledger frequently began as a balance column because that was correct enough for the first thousand users. Then volume arrives: retried webhooks post twice, settlement files disagree with internal totals, disputes create transitions the model never anticipated, and sponsor-bank obligations around monitoring and examination become real.
Product, integrations, and the AI feature behind them
Components:
- Your product (web, mobile, API)
- Backend services (queues, jobs, evals)
- AI feature (retrieval, review gates)
- Data & integrations (warehouse, third parties)
Connections:
- Your product to Backend services (API)
- Backend services to AI feature (structured calls)
- Backend services to Data & integrations
What we build
Starting projects that fit Fintech.
- Double-entry ledgers with immutable postings, derived balances, and full replay
- Idempotent write paths and exactly-once effects over at-least-once delivery
- Reconciliation engines against sponsor-bank, processor, and network settlement files
- Integration with issuing platforms, ACH and RTP rails, and KYC or KYB vendors
- Append-only audit history and evidence pipelines for examination requests
- Live balance-system migrations using shadow ledgers, dual writes, and staged cutover
- Tokenization and data segregation so card and personal data touch fewer systems
- Transaction monitoring and alerting pipelines with rules, case management, and reviewer audit trails
Capabilities we bring
Working in Fintech?
Tell us the line.
What runs by hand, what is not connected, what you are trying to build. An engineer replies within one business day with whether and how we would approach it.
Common questions
What Fintech teams ask first.
Have you built systems where a bug is a money problem?
Yes. We worked with American Express on global loyalty and rewards, migrating legacy systems to event-driven microservices in Go across point tracking and the ledger, through to war-room production deployments. Points function as currency there, so the constraints match a payments product exactly.
Do we have to rewrite our ledger to fix this?
Usually not in one motion. We typically build the double-entry ledger alongside what you have, deriving it from the same events, and run both until balances agree. That gives you a provable comparison rather than a leap, and lets you cut over one account type at a time.
Can you work inside our PCI scope and our sponsor bank's requirements?
We engineer to the requirement and design to keep scope small: tokenization at the edge, network and data segregation, least-privilege service accounts, key management, and no sensitive data in services that do not need it. Willowark claims no certifications of its own; we build to your control set and support your assessors.
How do you get access to production data and systems without expanding our risk?
Usually we do not need production access for most of the work. We build against synthetic and masked data in your non-production environments, and where production access is unavoidable — a reconciliation investigation, a shadow ledger comparison — it is scoped to named individuals, time-limited, read-only where possible, and logged through your existing controls. We sign your agreements, work inside your identity provider, and never move data to our own systems.
Can AI help here, or is it too risky for money movement?
It helps at the edges, not in the ledger. Posting, balances, and state transitions stay deterministic and tested, because a model has no place deciding whether money moved. Where AI typically earns its keep is around that core: matching reconciliation breaks and suggesting causes, triaging support and dispute cases, extracting fields from partner documents, and drafting responses to examination requests from the audit record. Each of those runs with a human approving the outcome and a log of what the model saw.
More in Software & Technology
Strategy. Software. Systems.
Engineering for Fintech.
Describe the problem in your own words. An engineer reads it — not a sales script — and tells you plainly what it would take.