Overview
A service-oriented banking system with separate customer and operations portals, balanced double-entry accounting, idempotent payment workflows, immutable audit history, and independent reconciliation.
Back
LeCore Banking Platform
An event-driven retail banking platform built for financial correctness, recoverable payments, and operational control.
9
Backend Services
2
Banking Portals
Double-entry
Ledger Model
Kubernetes
Deployment
The Problem
- Prevent double spending and reject unbalanced journal entries while deriving balances from durable accounting records
- Recover from ledger timeouts without charging a customer twice or losing a payment between services
- Give operations teams a searchable audit trail and an independent payment-to-ledger reconciliation view
- Keep retail users and privileged operational tooling isolated behind explicit access controls
The Solution
- Separated identity, customer, account, payment, ledger, audit, and reconciliation into accountable service boundaries
- Implemented idempotent payment and ledger commands with durable outbox events and deduplicating Kafka consumers
- Built distinct Angular portals for customers and operations staff behind a single policy-enforcing API gateway
- Created an independent ASP.NET Core reconciliation service that correlates payment events with ledger postings
Architecture Overview
High-level architecture of the application.
Experience Layer
separate Angular retail and operations portals for customer and administrative workflows
Edge Layer
API gateway handling authentication, routing, rate limits, and trusted identity headers
Domain Layer
Spring Boot services for identity, customers, accounts, payments, ledger, and audit
Control Layer
ASP.NET Core reconciliation service providing independent payment-to-ledger evidence
Platform Layer
PostgreSQL, Kafka, Redis, OpenTelemetry, and Kubernetes infrastructure
Key Highlights
Balanced double-entry journal posting
Idempotent, retry-safe payment workflows
Customer registration and internal transfers
KYC review and controlled account funding
Immutable audit event history
Payment-to-ledger reconciliation queues
Role-protected operations portal
Metrics, health checks, and distributed tracing
Challenges
- Coordinating a payment lifecycle across independently deployed services without distributed database transactions
- Handling at-least-once event delivery and out-of-order messages without duplicating financial effects
- Distinguishing short event-delivery delays from genuine reconciliation exceptions
- Enforcing gateway-only access and least-privilege network paths across a Kubernetes deployment
Results
- Delivered a complete retail journey for registration, account visibility, and internal transfers
- Made financial correctness explicit through atomic balanced postings and idempotent references
- Equipped operations staff with customer, KYC, account, payment, audit, and reconciliation workflows
- Established cluster-ready deployment boundaries with probes, resource limits, network policies, and observability
What I Learned
- Financial correctness belongs in the domain model, not in infrastructure conventions
- Independent controls need events that carry enough financial facts to verify an outcome
- Eventual consistency needs explicit timing rules so transient delays do not become false incidents
- Operational screens are essential product features in a distributed financial system