Financial behavior, made explicit

A foundation for financial software.

FinKore is an open-source, language-independent specification for financial behavior. You get explicit requirements, portable acceptance cases, and operation contracts for machine clients.

Your team implements the rules in your own product, choosing the language, architecture, and tools to execute the cases.

Read the CoreDoc Implementation guide First contribution guide
FinKore Core 2.0.2 stable
FinKore

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

Handling amounts, approving changes, preserving history: the same questions recur across financial products. FinKore makes those rules explicit, so your team can build on a shared reference instead of defining them from scratch.

One amount, two explicit policies

What happens to 10.005 EUR?

At scale 2, the declared rounding mode changes the result. CoreDoc requires an explicit policy; the Money specification defines each mode.

Follow the rule and its acceptance cases
Expected results at scale 2
ModeResult
HALF_UP10.01 EUR
HALF_EVEN10.00 EUR

  • Specifications

    Precise financial requirements, stable identifiers, invariants, and portable errors, refining the CoreDoc obligations.

  • Acceptance case manifest

    Discover portable inputs and expected observations, linked to requirements for evaluation in your environment.

  • Agentic Contract

    Canonical operation semantics, inputs, outputs, errors, effects, and safety metadata for machine clients.

Repository maintenance tools validate these published artifacts. Your team supplies the financial implementation and owns invocation, observation, comparison, and reporting. Artifact checks do not execute financial behavior or establish implementation conformance.

CoreDoc → Specifications → Conformance CoreDoc states financial obligations. Specifications refine them into precise requirements, and conformance artifacts describe portable acceptance cases. 01 · START HERE CoreDoc Review the financial principle. 02 · READ THE REQUIREMENTS Specifications Read the precise behavior. 03 · REVIEW THE CASES Conformance Find the expected observations. CoreDoc → Specifications → Conformance Read top to bottom: review the CoreDoc principle, read the specification requirements, then find the conformance cases. 01 · START HERE CoreDoc Review the financial principle. 02 · READ THE REQUIREMENTS Specifications Read the precise behavior. 03 · REVIEW THE CASES Conformance Find the expected observations.
CoreDoc is the entry point. Specifications and acceptance cases follow its financial obligations.

Explore the CoreDoc

Know the principle.
Explore the rule.

Start with the question in front of you. Open a principle, choose a rule, and read its reasoning here on the site.

5 principles 19 foundational rules

These are the CoreDoc foundations. The domain specifications refine them into precise requirements.

Read the complete CoreDoc
CORE-001Monetary IntegrityHow do amounts retain their value and currency through calculation?
Read the principle
  1. CORE-001.1Amount and currency are inseparable
  2. CORE-001.2Exact calculation and explicit rounding
  3. CORE-001.3Incompatible currencies are not combined or compared
  4. CORE-001.4Allocation conserves the source value
CORE-002Controlled Financial StateWhich changes are permitted, and what happens when a change is rejected?
Read the principle
  1. CORE-002.1Lifecycle changes require a declared valid transition
  2. CORE-002.2Validation is complete, fact-based, and non-mutating
  3. CORE-002.3Rejected actions have no partial financial effect
  4. CORE-002.4Mutability is declared by state and field
CORE-003Financial History and EvolutionHow are original facts preserved when later actions change their effect?
Read the principle
  1. CORE-003.1A committed event preserves essential evidence
  2. CORE-003.2Committed history is not destructively rewritten
  3. CORE-003.3Corrections and related evolution preserve original facts
  4. CORE-003.4Redaction preserves evidence of history
CORE-004Approval IntegrityWhat was approved, by whom, and does that approval still apply?
Read the principle
  1. CORE-004.1Approval requirements state subject, eligibility, and outcome
  2. CORE-004.2Missing facts do not create an approval exemption
  3. CORE-004.3Decisions remain tied to their facts and history
  4. CORE-004.4Chain status follows declared requirements and decisions
CORE-005Identifiable and Determinable Financial MeaningCan a reviewer identify the subject, distinguish conditions, and reproduce the outcome?
Read the principle
  1. CORE-005.1Continuing financial subjects retain stable identity
  2. CORE-005.2Materially distinct conditions remain distinguishable
  3. CORE-005.3Evaluation follows declared facts and context

Licensing · Built for commercial adoption

Build on FinKore.
Keep your product yours.

Designed for banks, fintechs, SaaS platforms, and ERPs. Build on shared financial rules while keeping control of your technology and the business you build around it.

Explore the licensing

  • Commercial use. No royalties.

    Build proprietary products and paid services without license royalties or a required support purchase.

  • Your implementation. Your choices.

    Choose your language, stack, and deployment. Your original implementation of the rules can remain proprietary.

  • Open foundations. Clear terms.

    MPL-2.0 preserves the license and notices of covered FinKore files when you distribute them, including your modifications.

Supporting the journey

Partners

No project grows without great partners. My special thanks to those who supported FinKore at key stages of its journey.

The person behind FinKore

Meet the Founder

Will Gittens

Will Gittens

Founder & Lead Maintainer FinKore

With over 25 years in software engineering, Will Gittens has built and led software projects across international teams, working extensively with complex financial systems, approval workflows, expense management, and enterprise applications.

His experience in financial software reinforced a belief: the most important engineering decisions should never be hidden inside implementation details. They should be explicit, testable, and open to scrutiny.

That belief led him to create FinKore.

As Founder and Lead Maintainer, Will is responsible for the project's architectural direction, technical consistency, and long-term vision. His ambition is to bring together engineers, architects, and domain specialists who can challenge assumptions, contribute their expertise, and collectively raise the standards of financial software engineering.

He believes the most valuable open-source projects are not defined by how much code one person writes, but by the knowledge they bring together and the trust they earn over time.

“Great foundations are not built by one person. They are built through shared knowledge, strong principles, and the commitment to make things better.”

Connect with Will on LinkedIn