Say Hello to FinKore. Rules Are Boring (But Necessary).

Will Gittens — Sat, 07 Nov 2026 19:10:47 +0000

I've been developing software for over 25 years. I've worked with old COBOL systems, modern web applications, financial platforms, and pretty much every generation of technology in between.

And there's something that has always bothered me.

Why the hell are we still rewriting the same financial rules?

Every time someone starts a new fintech, ERP, banking application, or financial SaaS, the story repeats itself.

How should we round money? What happens when two operations modify the same financial record? Can an approval become invalid? What should happen when a transaction fails halfway through? How do we preserve audit evidence?

Different companies. Different architectures. Different programming languages.

Same fundamental questions.

And somehow, we keep answering them from scratch.

So I started digging.

I went back to old books, financial systems, legacy implementations, regulations, and years of experience working with financial software.

Looking for the rules that should never have been reinvented in the first place.

What I found wasn't a shortage of solutions. It was a shortage of shared, precise, verifiable foundations.

We have countless libraries, frameworks, platforms, and architectures.

But how often do we agree on what the correct financial behavior should actually be?

That's where FinKore started.

Meet FinKore.

FinKore is an open-source initiative to define a common foundation for financial software.

It's not another framework or SaaS.

It's not an Lib you install and magically solve your financial problems.

FinKore is about defining the rules before writing the code.

The idea is simple: fundamental financial behavior should be documented, explicit, testable, and independent of programming languages.

Your application might be written in TypeScript, Java, Go, or something that hasn't even been invented yet.

The underlying financial rules shouldn't change just because your technology does.

So Rules first. Code after.

FinKore is organized around three fundamental layers:

CoreDoc -> Specifications -> Conformance

CoreDoc establishes the financial principles and obligations. This is where we explain why a rule exists.

Specifications translate those principles into precise technical requirements, defining expected behavior, constraints, and failure conditions.

Conformance provides portable test cases with inputs and expected results, allowing implementations to be evaluated against the same requirements.

That's the idea behind FinKore.

Not to tell you which framework to use, but to establish what behavior your implementation should guarantee.

Five domains. One shared foundation.

FinKore currently focuses on five foundational domains:

Money: Exact calculations, currency, rounding, allocation, and serialization.
Workflow: Valid state transitions, lifecycle behavior, and rejection rules.
Audit: Preserving evidence of what happened, who acted, and what must remain traceable.
Approvals: Decisions, conditions, approval validity, and the facts behind authorization.
Financial Entities: Identity, validation, revisions, and controlled changes.

These are not complete banking products or accounting systems. They are building blocks that financial applications can use to establish predictable behavior.

And importantly, FinKore doesn't decide your business policies for you.

It defines the foundation. Your application defines its own business rules, architecture, and integrations.

What about AI?

If an AI doesn't know which rounding policy applies, when an approval expires, or how an operation must behave after rejection, it will make assumptions.

And assumptions are dangerous in financial software.

FinKore provides explicit specifications and machine-readable operation contracts that can help developers and AI-assisted workflows work from defined expectations instead of inventing behavior.

AI should implement financial rules, not invent them.

I'm not trying to build this alone.

This is probably the most important part.

I don't believe one developer, one company, or even one engineering team has all the answers.

A developer understands implementation constraints. An accountant understands financial obligations. An auditor understands evidence and controls. A financial architect understands how these requirements interact across systems.

FinKore needs all of these perspectives.

That's why the project is open-source and community-driven.

I want people to challenge the specifications, find missing scenarios, question assumptions, propose edge cases, and help make the foundation stronger.

You don't need to contribute code.

Sometimes a difficult question from an auditor is more valuable than a thousand lines of implementation.

We're just getting started.

FinKore already has published specifications, portable conformance cases, documentation, and a growing set of discussions about financial behavior.

But I see this as the beginning, not the finish line.

I want FinKore to become a shared reference that developers can rely on when building financial products, regardless of the technology they choose.

Not because everyone should write the same code.

But because we shouldn't have to reinvent the same financial foundations forever.

Your product may be unique. Your financial rules don't have to be.

If you've worked with financial software, I'd love to hear what rules you've had to implement over and over again.

And if you disagree with something in FinKore, even better. Open a discussion.

That's how we improve it.

Explore the project: https://finkore.dev

GitHub: https://github.com/willgittens/FinKore

Define once. Build many times.

DEV Community: Will Gittens