OpenBank: a cloud-native banking reference platform you can run, but not bank on

What OpenBank actually is

OpenBank is a reference implementation of a retail banking platform, not a bank and not a finished product. The README is explicit: it is early-stage, community-driven, and not production-ready, and it is not licensed to operate as a bank. What it does provide is a large, in-repo collection of about 37 backend microservices written in Kotlin on Quarkus, a Next.js admin UI, and a Next.js developer portal. The project targets engineers who want to see how a modern bank might be assembled from domain-driven design, hexagonal microservices, double-entry ledger accounting, and PSD2 compliance. It is a blueprint with working code, deployed to an AWS sandbox that anyone can hit with a curl command. The distinction matters: this is a platform to learn from and extend, not something to put in front of real customers.

The architecture: event-driven microservices with a durable workflow core

The repository layout and status table reveal a clear architectural pattern. The core domain services cover account, ledger, transaction, and balance. Payments flow through a Temporal workflow: a transaction is submitted, goes through a sanctions and AML gate, then into the ledger, then updates the balance. Temporal is listed as live, with ADR-0101 referenced, and FX and statement flows also run on durable execution. This means OpenBank treats workflow durability as a first-class concern, not an afterthought. The system is event-driven, and the README mentions a PARTY_ERASED event that is handled fleet-wide for GDPR right-to-erasure, touching KYC, notification, and card-issuance services. That is a concrete example of how they propagate domain events across service boundaries. The customer edge is a BFF with OPA enforce mode on, which suggests policy-based authorization at the edge. The overall shape is a typical cloud-native banking stack: multiple services, an event bus, a workflow engine, and a GitOps deployment layer.

What works in the sandbox right now

The public sandbox at open-bank.tech exposes a set of live endpoints. You can create an account with POST /api/v1/accounts and get an IBAN with Czech mod-11 BBAN. You can get a balance, make a SEPA payment, a domestic payment, a SEPA Instant payment with a 10-second settlement window, and set up standing orders with a daily due-date sweep backed by an outbox. There is also an AI copilot endpoint, a PID endpoint for EUDI identity using OpenID4VP and OpenID4VCI, and an MCP endpoint for operations agents. All of these require a Bearer token from the Keycloak realm at kc.open-bank.tech. The README warns that the sandbox is a best-effort demo, not a service, and it may be reset, throttled, or taken offline at any time. That is a fair warning. The endpoints are real enough to test integration patterns, but you should not build a production client against them.

How to get it running

The README points to docs/QUICKSTART_SANDBOX.md for a curl walkthrough, but the repository itself is the primary artifact. To run OpenBank locally, you would clone the repo and follow the service-level documentation. The project uses self-hosted GitHub Actions runners with path-scoped gates, and GitOps auto-deploy via ArgoCD. The cloud substrate is AWS with EKS and OpenTofu. That means a full local deployment is not a single command; it is a multi-service orchestration. The README mentions a codespaces link, which suggests you can open the repo in GitHub Codespaces for a quick look. For the sandbox, the quickstart document presumably walks you through obtaining a token and hitting the API. The repository also has an admin UI at admin.open-bank.tech with Keycloak auth. If you want to deploy your own instance, you would need to replicate the AWS setup or adapt the OpenTofu configuration. This is not a turnkey application; it is a platform for engineers comfortable with Kubernetes and GitOps.

Where it falls short: stubs, missing live connections, and governance gaps

The status table is honest about what is not done. Interbank rails are wired to an ISO 20022 pipeline and a clearing simulator, but the live interbank network is not connected. SWIFT messaging is deployed with a pipeline, but there is no live SWIFT network connection. KYC, AML, and sanctions screening use real screening logic with pg_trgm, but vendor feeds are stubs. Lending has a four-eyes KYC gate but no live credit bureau integration. Fraud detection is deployed with a velocity-counter signal plane, but the rule engine is pending. Test coverage is a ratchet-only gate, meaning it only prevents coverage from decreasing, and only money-path services carry higher floors. These are significant limitations if you want to evaluate real-world integration behavior. The project is also early-stage: the roadmap has M1 complete, with M2, M3, and M5 in progress. The AI agent service and copilot are marked yellow, meaning they are in active development. If your use case depends on live external feeds or production-grade fraud detection, OpenBank is not there yet.

Governance and supply-chain security as code

One of the more distinctive aspects of OpenBank is that it treats governance and security as code. The README references ADR-0029 for versioning, release, and catalog governance, and ADR-0030 for supply-chain security including SBOM, signing, SAST, and pen-test findings. The project has a Scorecard badge and a best practices badge, and external pen-test P0-P2 findings are remediated. There is also an ADR-0136 about agent services being AGPL in the repo under an open-core model, which is a licensing nuance worth noting: the main project is Apache-2.0, but some agent services may have a different license. The CI enforces these gates, and the project uses self-hosted runners. This is a useful model for organizations that want to bake compliance into the development pipeline. However, it also means the project has a lot of moving parts: ADRs, CI workflows, ArgoCD applications, and multiple services. The learning curve is steep.

Alternatives and how they differ

OpenBank is not the only open-source banking reference platform. A common alternative is Apache Fineract, which is a mature, Java-based core banking system used by digital financial service providers, especially in microfinance. Fineract is a monolithic or modular application that runs on a relational database and provides REST APIs for accounts, loans, and clients. It is production-ready in the sense that it has been deployed in real institutions, but it does not have the same event-driven, microservices, cloud-native architecture as OpenBank. Fineract is less about demonstrating a modern Kubernetes-based stack and more about providing a functional core banking engine. Another alternative is the Mifos X platform, which builds on Fineract. The key difference is that OpenBank is a reference implementation for learning and sandboxing, with a heavy emphasis on governance-as-code and cloud-native patterns, while Fineract is a more traditional, battle-tested core banking system. If you need something you can actually run a small bank on, Fineract is closer to that, but it will not give you the same PSD2, EUDI, or Temporal workflow examples.

Maintenance and upgrade cost

The repository is actively maintained, with the last push on 2026-08-28 and recent releases for party-service v0.22.0 and admin-ui v0.218.0. The admin UI is versioned separately from the services, which is a sign of a mature release process. The project uses a monorepo with path-scoped CI gates, so changes to one service do not necessarily trigger full-fleet builds. That helps with upgrade cost, but the sheer number of services (37) means that keeping a deployment up to date is a significant effort. The README mentions that the entire backend fleet is now deployed to the AWS sandbox, including FINREP via its own ArgoCD Application. This suggests a GitOps-driven upgrade path: you update a manifest, ArgoCD syncs it. But the cost is in the operational overhead of running EKS, ArgoCD, Temporal, Kafka or similar, and the observability stack (OTel, Grafana, Prometheus, Loki, Tempo, Pyroscope). The license is Apache-2.0 for the main project, which is permissive, but the ADR about agent services being AGPL in the repo means you need to check the license of any service you plan to use in a closed-source product. This is not a project you can adopt casually; it requires a dedicated platform team.

Editorial conclusion

Adopt OpenBank if you are building a banking product prototype, a PSD2 compliance demo, or a teaching environment and need a working reference with real microservices, Temporal workflows, and an AWS sandbox. Do not adopt it for production banking: it is explicitly not production-ready, lacks live interbank and SWIFT connections, and requires a banking licence and regulatory approval. Before adopting, verify the current roadmap, check that the services you need are not in the yellow or red status column, and confirm that the vendor feeds (KYC, AML, credit bureau) are acceptable as stubs for your use case. OpenBank is a useful blueprint, not a bank.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes