-
Notifications
You must be signed in to change notification settings - Fork 0
Vision
Tiana_ edited this page May 30, 2026
·
1 revision
What FinCore Engine is, what it isn't, and why it exists.
FinCore Engine is the open-source fintech core for the JVM ecosystem: double-entry ledger, payment orchestration, KYC/AML compliance, and a JSON-DSL decision engine - all production-grade from the first commit.
The JVM market is underserved by open fintech infrastructure. Most teams either glue together Drools + Spring Batch + handwritten ledger code (slow, error-prone) or buy proprietary SaaS at $500K/year (vendor lock, opaque). FinCore Engine offers a third path: open-source infrastructure with rigorous correctness, modern DX, and a license (BSL 1.1) that prevents hyperscaler-fork commodification.
- A modular monolith today, designed for clean extraction to microservices later
- A production-grade ledger with double-entry invariants enforced at three layers (domain, service, database)
- A payment orchestration platform with idempotency, outbox pattern, retry topology, webhook delivery
- A compliance framework for KYC orchestration, AML rule evaluation, case management
- A JSON-DSL decision engine as a standalone library that can replace Drools in modern Kotlin/Spring teams
- A sandbox that gives developers a working fintech in 30 seconds via
docker compose up - An OSS project licensed BSL 1.1 with a 4-year change-date conversion to Apache 2.0
- A JVM-first offering in a market dominated by Go-based alternatives
- Not a TigerBeetle competitor. TigerBeetle is a low-level financial OLTP database with formally verified invariants, ~1000× the raw throughput of Postgres for ledger workloads. We're an application layer above. We use Postgres by default; TigerBeetle adapter ships Y1 H2 as pluggable storage. Use Postgres for 99% of cases, TigerBeetle for the 1%.
-
Not an ML toolkit. Risk scoring, anomaly detection, fraud detection - these are advisory inputs to deterministic rule evaluation, never authoritative. Plug-in interfaces (
RiskScorer,AnomalyDetector,AmlCopilot) live in OSS; trained models do not. - Not a banking license. It does not replace your sponsor bank, your KYC provider, your AML data feed, or your regulatory reporting obligations. It plugs into them.
- Not a multi-tenant SaaS. Each adopter handles tenancy at the deployment level. Naive multi-tenancy in fintech invites cross-tenant data leaks; we won't ship that until we have explicit, regulated answers.
- Not a complete neobank stack. Cards, mobile apps, statements - those are adopter responsibilities. We ship the financial backbone; the front end is yours.
- Not a hosted service. No "FinCore Cloud" in 2026. Self-hosted only.
Open-source fintech infrastructure has matured in Go (TigerBeetle, Formance, Blnk, Midaz) and stagnated in JVM (Adorsys Ledgers - last meaningful commit 2022). The JVM market - banks, regulated fintechs, JVM-shop neobanks - has no modern OSS option. They either rebuild it themselves (slow, error-prone) or buy SaaS (locked-in, expensive).
FinCore Engine fills that gap.
FinCore Engine exists to:
- Provide a high-quality, readable body of work the JVM/fintech engineering community can evaluate and adopt
- Provide infrastructure that downstream verticals can build on top of
- Test the BSL 1.1 anti-fork model in a serious project
Quality matters more than adoption metrics in Y1.
These are the principles that drive every decision:
- Correctness first, performance second. Money-handling code that's "fast enough" but loses 1 in 10⁶ transactions is unfit for purpose. We pay measurable latency cost (DB triggers, transaction boundaries, optimistic locking) for invariants that hold mathematically.
- Boring tech in the hot path. PostgreSQL, Spring Boot, Kotlin, Kafka API. None of these are "innovative" - that's the point. Innovation is in what we build on top (decision engine DSL, outbox correctness, plug-in architecture), not the foundation.
- Extraction-readiness over premature distribution. Modular monolith with clean boundaries, ready to extract per-service when adoption demands it.
- Audit-by-default. Every state change is observable, every decision is replayable, every transaction is immutable.
- Pluggable boundaries. External systems (banks, KYC, ML, sanctions, LLMs) are interfaces with sandbox implementations in OSS. Real implementations are adopter business.
- No marketing budget. Quality + content + transparency is the strategy.
- No funding. Bootstrapped on weekends and evenings. Sponsorship via GitHub Sponsors when adoption warrants.
- No feature creep. Strict scope per release. Saying "no" is part of the job.
- No coupling to private vertical business. The private vertical lives in a separate repo. The OSS has zero opinions about your domain.
- No proprietary moat in OSS. ML models, vendor adapters, customer data - never in the public repo.
- Building in public. Roadmap, retrospectives, decision rationale, performance benchmarks - all public.
- Senior engineers building fintech apps on JVM (banks, embedded finance, B2B PayTech, BNPL)
- JVM-shop teams that won't rewrite to Go for a fintech core
- Stripe-alternatives in earlier markets
- Banks/fintechs with legacy core wanting incremental modernization (decision engine module as Drools replacement)
- Engineering leaders evaluating reference architectures
- Conference attendees, blog readers, recruiters
- Private verticals built on top of the OSS
| Metric | Target | Stretch |
|---|---|---|
| GitHub stars | 1,500 | 3,000 |
| Public adopters mentioned | 1 | 3 |
| Conference talks accepted | 1 (KotlinConf) | 2 (+ SpringOne) |
| Blog posts published | 8 | 12 |
| GitHub Sponsors | $200/month | $1,000/month |
These are signals, not goals. The real goal is shipping a body of work the engineering community can evaluate and build on.
- Stars below 200 in Y1 → re-evaluate channels (HN, blog cadence, content)
- No public adopter mentions → consider visibility tactics (case studies, free consulting hours)
- Quality regression → all-hands fix sprint, no new features
We track these honestly in Risk-Register.
- v1.0 (Y2): production-stable, public SLOs, multi-region pattern
- v1.5 (Y2-Y3): TigerBeetle adapter, regulatory reporting (SAR/STR), ISO 20022 native
- v2.0 (Y3+): commercial layer (FinCore Cloud SaaS, enterprise support contracts) if community signals demand
- 2030+: every release published before that point auto-converts to Apache 2.0; community can fully fork
-
Try:
git clone && docker compose up && demo.sh - Star if it's useful
- Issue for bugs or questions (response within 48h Y1)
- Discuss in GitHub Discussions
- Contribute per CONTRIBUTING.md
- Sponsor via GitHub Sponsors when revenue allows
- Email for commercial inquiries: see SECURITY.md
- Roadmap - what's planned and when
- Architecture-Overview - how it's built
- FAQ - common questions
- Overview
- Services
- Data Model
- Domain Model
- Event Flow
- Security
- Observability
- Resilience
- SLA / SLI / SLO