If you run or build technology for a community bank or credit union, you’ve probably heard the pitch: “offer Bitcoin services to your customers.” But the follow-up question is always the same — how do you actually do it without blowing up your existing infrastructure?
Galoy, the team behind the Bitcoin banking platform Lana, has published a technical philosophy that answers exactly this question. Here’s what it means for you.
The Problem: Your Core System Isn’t Going Anywhere
Traditional banks run on legacy core banking systems — and replacing them is expensive, risky, and politically controversial. Most digital asset vendors either ask you to rip and replace, or bolt on something so complex that your IT team needs six months just to understand it.
Neither option works for a 200-person credit union or a regional community bank. 
The Galoy Approach: A “Sidecar” That Plugs Into What You Have
Galoy built Lana as a modular monolith, a single, self-contained system that handles Bitcoin-backed lending, Lightning payments, stablecoins, and custody. Instead of forcing your team to manage dozens of microservices, it deploys as one coherent unit.
Why does that matter for you?
- Less operational burden — One system to deploy, monitor, and support. No orchestration layer, no inter-service communication failures, no distributed debugging nightmares.
- Works with your existing middleware — Lana doesn’t dictate how it connects to your stack. Whether you use Kafka, RabbitMQ, or a REST API, integration is defined at the boundary on your terms.
- Financially consistent — Any operation that touches multiple domains (customer identity, loan approval, accounting, compliance audit) either completes fully or rolls back entirely. No partial transactions. No reconciliation headaches.
Why “Modular Monolith” Is the Right Call for Banking
This is actually a well-established engineering pattern that the banking world is only now rediscovering. The key insight: the compiler enforces module boundaries, not organizational trust or documentation. If a developer accidentally creates a dependency between two modules that shouldn’t talk to each other, the build fails. This makes the codebase safe to evolve without a large engineering org watching every change.
For banks evaluating vendors, this means:
- Easier audits: the whole system is one deployable artifact
- Fewer failure modes: no network calls between internal services
- Faster feature delivery: a change that spans lending, approvals, and accounting is a single deployment, not a coordinated rollout across three services
What You Can Actually Offer Customers
Once Lana is running inside your infrastructure, your institution can offer:
- Bitcoin-collateralized loans
Customers lock BTC, receive fiat credit lines without selling their Bitcoin - Lightning Network payments
Instant, low-fee Bitcoin transactions for remittances, payroll, or merchant settlement - Stablecoin accounts
Dollar-denominated digital wallets with programmable controls - Self-custody support
Customers hold their own keys while your bank handles compliance and KYC rails
Is This for You?
This architecture is purpose-built for client-controlled infrastructure, meaning you run it in-house, not on Galoy’s cloud. For regulated institutions with data sovereignty requirements or clients in jurisdictions with strict data residency rules, this is essential.
If you’re a large bank with hundreds of engineers and strict service ownership boundaries, microservices may still be the right call. But for community banks, credit unions, challenger banks, and Bitcoin-native fintechs, Lana’s approach offers institutional-grade reliability without institutional-grade complexity.
