Financial software that keeps the ledger right at scale
Willowark builds the software layer around financial operations: transaction and points services, ledger and reconciliation engines, customer applications, and the integration connecting a modern stack to a core written decades ago. We remove the distance between what the business wants to launch and what the core was built to do.
Correctness is the design constraint. Writes are idempotent, so a retried message never double-posts. Money movement is modeled as immutable events with double-entry postings rather than mutable rows. Reconciliation runs against the system of record and pushes breaks to an exception queue. Migrations ship behind flags with shadow reads, proving the new path on live traffic before cutover.
A first engagement here is usually bounded on purpose: one reconciliation that is eating a team's week, one product the core cannot express, or one integration held together by a batch file and a person who knows why it fails. The constraints are regulatory and structural. Change windows are limited, examiners expect evidence rather than assurances, and the core's batch schedule sets the rhythm whether the new services like it or not. We design around that rather than pretending it is a greenfield stack.
Reviewed
Sound familiar?
If you've said any of these, we should talk.
“Our core can't do what we need, and replacing it isn't happening.”
You do not have to replace it. We build alongside the core behind a translation layer that isolates its quirks, so new products run on modern services while the core stays the book of record.
“Reconciliation takes three people and most of a week.”
We build the matching engine: normalized feeds from each source, configurable rules, tolerance handling, and an exception workbench showing only the breaks and their evidence. Matched volume clears itself, and people work what needs judgment.
“Every product launch turns into a year-long project.”
Usually one monolith owns everything, so every change becomes a full-regression event. We extract the parts that change most into independently deployable services with clear contracts and their own tests, so a launch touches a bounded surface.
“Audit wants a trail we cannot actually produce.”
We record what happened as append-only events — who, what, when, and the resulting balance — so history is reconstructable rather than inferred from logs. We engineer to your control requirements and produce evidence; the attestations stay yours.
“We have vendors for everything and none of them will talk to each other without a project.”
That is the integration tax of a best-of-breed stack. We build an integration layer that owns the mapping between each vendor's formats and your canonical data model, so adding or swapping a processor, screening provider, or origination system touches one adapter rather than every system that consumed it.
How this industry actually runs
The operation as we usually find it.
Banks, credit unions, lenders, and fintechs run on a core — FIS, Fiserv, Jack Henry, or something in-house — ringed by systems that must agree: card processors, ACH and wire rails, KYC and sanctions screening, loan origination, and regulatory reporting. Much still moves on batch windows and files: NACHA batches, ISO 8583 authorizations, ISO 20022 messages, nightly settlement. Around that sit examiners, BSA and AML programs, SOX controls, and PCI DSS scope wherever card data lands.
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 Banking & Financial Services.
- Event-driven services for transaction, points, and balance systems
- Double-entry ledger and posting engines with idempotent write paths
- Automated reconciliation with matching rules and an exception workbench
- Integration over core banking, card processing, and ACH file interfaces
- Legacy migration using dual writes, shadow reads, and staged cutover
- Audit-ready event history feeding regulatory reporting
- AI document processing for onboarding, loan files, and KYC evidence with human review on exceptions
- Monitoring and alerting on batch windows, file arrivals, and settlement variances
Capabilities we bring
Working in Banking & Financial Services?
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 Banking & Financial Services teams ask first.
Have you worked on systems at real financial scale?
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 are money there, so the discipline matches any balance-bearing system.
Can you work inside our PCI or regulatory scope?
We engineer to the requirement and keep scope small: tokenization at the edge, network and data segregation, least-privilege service accounts, and no cardholder data where it is not needed. Willowark claims no certifications of its own; we build to your control set.
How do you migrate a system that cannot go down?
Incrementally, with the old system still running. The new service consumes the same inputs in shadow mode, its outputs compared against production without affecting anyone. Once differences are resolved, traffic moves a slice at a time behind a flag.
Can you use AI safely inside a regulated financial environment?
Typically yes, with the scope kept narrow and the decisions kept with people. We use models for extraction, classification, and drafting — reading a loan file, routing a support ticket, summarizing a case — and keep credit, compliance, and money-movement decisions in deterministic code with human sign-off. Every model output is logged with its inputs so it can be reviewed, and nothing leaves your approved environment without your security team agreeing to it first.
We are a smaller institution. Is this kind of engineering only for large banks?
No. The patterns scale down well, and the problems are usually the same: a reconciliation done by hand, a product blocked by the core, a report assembled from three exports. Smaller institutions typically have fewer systems to integrate and shorter approval chains, which makes bounded projects easier to deliver. What changes is the size of the first project, not the discipline applied to it.
Strategy. Software. Systems.
Engineering for Banking & Financial Services.
Describe the problem in your own words. An engineer reads it — not a sales script — and tells you plainly what it would take.