CWC Banking — Config-as-Code Core Banking

What it is

A from-the-ground-up redesign of core banking as configuration-as-code — deposits, loans, treasury, teller, fund management, trade finance, and regulatory reporting in one integrated system. Fund Manager, built on this core, goes live at the Ghana Revenue Authority Co-operative Credit Union next month. I own the architecture.

Configuration-as-code

Posting templates, product versions, fee schedules, interest and FX rates, limits, calendars, and tax rules are versioned, effective-dated data — not code. New product behaviour is new configuration over a small generic engine; nothing is overwritten, so "what rules applied on date X?" is a point-in-time query, not an archaeology project.

Auditable by construction — and beyond FlexCube

• Ledger is the only writer — subledgers build a PostingRequest and hand off to a single PostingService (PostingRequest → Template → Journal).
• Three-currency model (IAS 21) — every journal line stores transaction, functional, and reporting amounts with the FX-rate IDs used (FlexCube stores two; the third is reconstructed).
• Reversals-only — JournalEntry is immutable once posted; corrections are reversals, never in-place edits (FlexCube permits amendment).
• Event-driven — transactional outbox in the same DB transaction as the state change, inbox dedup, idempotency keys; Kafka transport.
• Multi-tenant — tenant + legal-entity isolation with per-tenant sharding.

These are the axes a regulator cares about — and where legacy core banking is weakest.

Scale

57 Gradle modules, ~200K LoC, 108 integration tests, 69 runnable API workflows, 360+ documentation pages. Spring Boot 4 / Java 21, Oracle EE + PostgreSQL, Kafka, Keycloak. Strict layered boundaries — circular dependencies are a build error.