A BIAN-Informed Universal Banking Modular Monolith
"Enforcing the spirit of Mfowethu through enterprise-grade software infrastructure."
The Mkhungo Core Platform is an architectural Proof of Concept (PoC) exploring how a large universal banking capability landscape can be organised as a modular enterprise Java application.
Built using a Modular Monolith architecture with Spring Modulith, the platform is organised around explicit banking domains covering areas such as core banking, payments, lending, treasury, insurance, wealth management, risk, compliance, enterprise support, and digital channels.
The project's high-level domain taxonomy is informed by the Banking Industry Architecture Network (BIAN) landscape, which provides a reference vocabulary for identifying and grouping banking capabilities.
Phase 0 does not attempt to implement a complete production banking platform.
Instead, it focuses on establishing and validating the architectural foundations required for a large enterprise application:
- Domain decomposition
- Modular boundaries
- Dependency control
- Banking capability organisation
- Multi-project build structure
- Architectural verification
- Evolutionary architecture
The central question explored by this PoC is:
How can a large universal banking capability landscape be represented as strongly bounded application modules without prematurely introducing the operational complexity of a distributed microservice architecture?
The primary purpose of this project is architectural exploration.
The PoC investigates how a complex enterprise domain can be decomposed into coherent application modules while retaining the simplicity of a single deployable application.
The architecture focuses on:
- Identifying meaningful domain boundaries
- Organising banking capabilities into cohesive modules
- Preventing accidental coupling between modules
- Enforcing architectural constraints through automated tests
- Preserving future architectural optionality
- Allowing individual banking capabilities to be implemented incrementally
The objective is therefore not to simulate every operation of a real-world bank.
Instead, Phase 0 establishes an architectural foundation from which individual banking capabilities can evolve.
The platform follows a modular monolith architecture implemented with Spring Modulith.
The system remains a single deployable application while internally organising functionality into explicit domain modules.
┌─────────────────────────────┐
│ MFT Core Platform │
│ │
│ Single Application │
│ │
├─────────────┬───────────────┤
│ │ │
▼ ▼ ▼
Core Banking Payments Lending
│ │ │
├─────────────┼───────────────┤
│ │ │
▼ ▼ ▼
Treasury Insurance Risk
│
▼
Other Domains
│
▼
Explicit Module Boundaries
This approach provides:
- A single deployment unit
- Simplified infrastructure
- Local transactional consistency
- Faster development and debugging
- Explicit internal boundaries
- Controlled module dependencies
The architecture deliberately avoids premature microservice fragmentation.
The platform's high-level domain taxonomy is informed by BIAN banking concepts and is used as an organising framework for decomposing universal banking capabilities.
The project is not presented as a complete or certified implementation of the BIAN standard.
Instead, BIAN provides a reference vocabulary for identifying and grouping banking concerns into coherent architectural domains.
This allows the project to begin with a broad enterprise capability map rather than allowing technical implementation details to define the architecture.
The modular boundaries are designed to preserve future architectural optionality.
As the platform evolves, individual modules may be expanded, redesigned, or—where justified by operational requirements—considered for extraction into independently deployable services.
The current architecture deliberately reduces unnecessary coupling so that future evolution does not require restructuring the entire platform.
However, module extraction would introduce distributed-systems concerns such as:
- Independent data ownership
- Network communication
- Eventual consistency
- Distributed transactions
- Authentication and authorisation
- Observability
- Deployment complexity
- Operational resilience
Microservices are therefore treated as an architectural option, not as a default destination.
Business capabilities determine the primary module boundaries.
Banking Capability
│
▼
Domain Module
│
▼
Application Logic
│
▼
Infrastructure
The architecture begins with:
What capability does the organisation require?
rather than:
What controller, service, or repository should be created?
The platform begins as a single deployable application with explicit internal boundaries.
Distributed architecture should emerge when justified by:
- Independent scaling requirements
- Team ownership
- Deployment requirements
- Operational constraints
- Availability requirements
rather than being introduced by default.
Modules should communicate through explicitly defined contracts and application events rather than arbitrary access to internal implementation details.
The objective is to minimise unnecessary coupling and prevent individual modules from gradually becoming dependent on the internal structures of other domains.
Architecture is not treated as documentation that developers are expected to remember manually.
Architectural boundaries are verified through automated tests.
If an implementation introduces an invalid dependency between modules, the build can detect the violation.
The architecture is designed for incremental expansion.
Modules are implemented when the relevant banking capability enters scope rather than being populated simply to satisfy a predefined technical structure.
The complete capability landscape therefore provides the architectural map, while Phase 0 focuses implementation effort on selected domains.
| Category | Technology | Version / Details |
|---|---|---|
| Language | Java | 21 LTS |
| Framework | Spring Boot | 4.0.0-M1 |
| Architecture | Spring Modulith | 1.3.1 |
| Build System | Gradle Kotlin DSL | 8.14 |
| Database — PoC | H2 Database | In-memory |
| Database — Future | PostgreSQL | Planned integration |
| Logging | Logback / SLF4J | Rolling application logging |
| Observability | Spring Boot Actuator | Health and metrics |
| Testing | JUnit 5 / Spring Modulith Test | Module boundary verification |
The repository is organised into a central application runtime and domain modules representing major banking capability areas.
mkhungo-core-platform/
│
├── core-app/ # Central Spring Boot runtime
│ └── src/main/
│ ├── java/za/co/mkhungo/platform/
│ │ └── MftApplication.java # Application entry point
│ │
│ └── resources/
│ ├── application.yml # Platform configuration
│ └── logback-spring.xml # Logging configuration
│
├── modules/ # Banking domain modules
│ │
│ ├── core-banking/
│ │ ├── customer/
│ │ ├── account/
│ │ ├── transaction/
│ │ └── product-catalog/
│ │
│ ├── payments-clearing/
│ │ ├── payments-core/
│ │ ├── debit-mandate/
│ │ ├── cross-border/
│ │ └── cards/
│ │
│ ├── lending-credit/
│ │ ├── lending-core/
│ │ ├── mortgage/
│ │ ├── trade-finance/
│ │ └── collateral/
│ │
│ ├── treasury-markets/
│ │ ├── forex/
│ │ ├── treasury/
│ │ ├── derivatives/
│ │ └── securities/
│ │
│ ├── insurance/
│ │
│ ├── wealth/
│ │
│ ├── risk-compliance/
│ │ ├── compliance/
│ │ ├── regulatory-reporting/
│ │ └── audit-trail/
│ │
│ ├── enterprise-support/
│ │ ├── document-management/
│ │ ├── notification/
│ │ ├── workflow/
│ │ └── integration/
│ │
│ └── channels/
│ ├── mobile-api/
│ ├── internet-api/
│ ├── branch-api/
│ └── open-banking/
│
├── build.gradle.kts # Root build orchestration
├── settings.gradle.kts # Project hierarchy
├── gradle.properties # Gradle configuration
└── gradlew / gradlew.bat # Gradle wrapper
Each module represents a bounded area of banking functionality and provides an explicit location for capability-specific implementation as the platform evolves.
Phase 0 deliberately limits implementation scope while preserving the broader banking capability map.
The project distinguishes between:
- Active modules containing implemented domain logic
- Planned modules representing future banking capabilities
These modules currently participate in the PoC and contain active source code, domain logic, and persistence structures.
| Category | Active Modules |
|---|---|
| Core Banking | customer, account, transaction |
| Payments | payments-core |
| Lending | lending-core |
| Treasury | forex |
| Insurance | insurance-core |
| Risk & Compliance | compliance, regulatory-reporting, audit-trail |
These modules provide the initial implementation surface for validating the modular architecture.
The remaining banking capabilities are represented as Gradle sub-projects to preserve the intended architectural map and provide explicit locations for future implementation.
Examples include:
- Trade Finance
- Derivatives
- Wealth Management
- Open Banking
- Cards
- Mortgage
- Securities
- Document Management
- Workflow
- Digital Channels
These modules do not currently contribute business functionality to the Phase 0 runtime.
A modular architecture is only useful if its boundaries remain protected as the system evolves.
The platform includes automated architectural verification using Spring Modulith to validate that application modules respect the dependency rules defined by the architecture.
The verification process helps detect architectural erosion such as:
- Illegal dependencies between modules
- Unintended coupling
- Circular module relationships
- Internal implementation details leaking across boundaries
Developer Change
│
▼
Automated Architecture Test
│
▼
Module Boundary Verification
│
├── Valid Architecture
│ │
│ ▼
│ Build Continues
│
└── Boundary Violation
│
▼
Build Fails
Architecture therefore becomes an executable engineering constraint rather than a convention that developers are expected to remember manually.
# Windows
.\gradlew.bat :core-app:test --tests "za.co.mkhungo.platform.ArchitectureBoundaryVerificationTest"
# Linux / macOS
./gradlew :core-app:test --tests "za.co.mkhungo.platform.ArchitectureBoundaryVerificationTest"The verification tests may also generate architectural documentation to support ongoing visibility into module relationships.
- Java 21 LTS
- IntelliJ IDEA recommended
- Gradle Wrapper included
No external database installation is required for Phase 0.
The PoC uses an H2 in-memory database for local development and architectural experimentation.
- Clone the repository.
git clone https://github.com/NMandisa/mkhungo-core-platform.git
cd mkhungo-core-platform- Open the project root in IntelliJ IDEA.
- Allow Gradle to synchronise the project.
- Navigate to:
core-app/src/main/java/za/co/mkhungo/platform/MftApplication.java
- Run the
main()method.
./gradlew :core-app:bootRun.\gradlew.bat :core-app:bootRunOnce the application starts, the following development endpoints are available.
The platform uses the following application context path:
/mft-api
Inspect the in-memory database schema and development data.
http://localhost:8080/mft-api/h2-console
JDBC URL
jdbc:h2:mem:mkhungo_core_db
Username
sa
Password
Leave blank.
http://localhost:8080/mft-api/actuator/health
http://localhost:8080/mft-api/actuator/metrics
These endpoints provide basic runtime visibility during Phase 0 development.
The Mkhungo Core Platform explores several enterprise engineering and architecture concerns.
| Capability | Demonstration |
|---|---|
| Domain Architecture | Banking capabilities organised into coherent domain modules |
| Modular Architecture | Explicit application module boundaries |
| Enterprise Java | Java 21 and Spring Boot |
| Evolutionary Architecture | Modular monolith with future architectural optionality |
| Architecture Testing | Automated verification of module dependencies |
| Multi-Project Builds | Gradle-based modular project organisation |
| Domain Modelling | Banking capability organisation informed by BIAN concepts |
| Operational Foundations | Actuator, logging, testing and reproducible builds |
The purpose of the PoC is not to claim production banking completeness.
The purpose is to explore how a large enterprise banking application can begin with a disciplined architectural structure before individual capabilities are incrementally implemented.
The intended evolution of the platform follows an incremental approach.
Phase 0
│
├── Establish domain boundaries
├── Validate modular architecture
├── Implement selected core capabilities
└── Automate architectural verification
│
▼
Phase 1
│
├── Expand active banking domains
├── Introduce richer domain behaviour
├── Strengthen persistence and integration
└── Introduce PostgreSQL
│
▼
Phase 2
│
├── External integration
├── API and channel expansion
├── Event-driven workflows
└── Security and access management
│
▼
Future Evolution
│
├── Independent scaling where justified
├── Selective module extraction where justified
├── Distributed deployment if required
└── Expanded enterprise capability coverage
The architecture is intended to evolve according to demonstrated requirements rather than prematurely adopting distributed complexity.
The project reflects a broader engineering principle:
Enterprise architecture should make complexity manageable, not merely distribute it.
A large system does not become architecturally mature simply because it contains many microservices.
The objective is first to understand:
- The business domain
- The system boundaries
- The dependencies
- The data relationships
- The operational constraints
- The consequences of architectural decisions
Only then can technology choices be evaluated against actual requirements.
The Mkhungo Core Platform explores those principles within the context of universal banking.
Mkhungo Financial Technologies (MFT)
Built on the unshakeable foundation of Mfowethu.
| Property | Value |
|---|---|
| Project Type | Enterprise Architecture Proof of Concept |
| Phase | Phase 0 |
| Architecture | Modular Monolith |
| Primary Domain | Universal Banking |
| Status | Active Development |
| Author | Noxolo M. Mkhungo |
© 2026 Mkhungo Financial Technologies. All rights reserved.