High-Level System Architecture
Architectural Principles
The Kredete platform is built on the following architectural principles:
- Service-oriented. The platform is decomposed into bounded services organised around product and regulatory concerns, rather than a monolith.
- Separation of money movement and user experience. Ledger, payments, and compliance services are isolated from the consumer-facing application layer so that user-facing changes do not affect money-movement guarantees.
- Immutable ledger. All balance-affecting activity is recorded as append-only double-entry ledger records. Balances are always derived, never stored mutably.
- Defence in depth. Security is enforced at the network, platform, application, and data layers, with PCI DSS scope deliberately minimised by routing card data through tokenised partner services.
- Observability by default. Every service emits structured logs, metrics, and distributed traces; every money-movement event is independently auditable.
System Layers
The platform can be understood in six layers:
| Layer | Purpose | Representative Components |
|---|---|---|
| Client layer | User-facing applications | iOS app, Android app, web marketing site (kredete.io), in-app AI agent. |
| Edge & API gateway | TLS termination, WAF, rate limiting, authentication, request routing | CDN, WAF, API gateway, identity provider. |
| Application services | Product logic and user journeys | Accounts, Payments, Remittance, Cards, Credit, Savings, Loans, Crypto, Services. |
| Core platform services | Cross-cutting capabilities used by application services | Ledger, FX, Compliance (KYC/AML), Risk, Fraud, Notifications, Rewards, Identity. |
| Integration layer | Adapters to third-party providers and payment rails | Banking adapters, card issuer adapters, credit bureau adapters, crypto on-ramp adapters. |
| Data & infrastructure | Storage, messaging, compute, and observability | Relational and analytical databases, object storage, message bus, container platform, monitoring stack. |
Conceptual Architecture Diagram (Textual)
The following describes the conceptual flow of a typical user-initiated transaction (e.g., sending USD to a recipient in Nigeria):
- The mobile client submits an authenticated request through the edge layer.
- The API gateway validates the session, applies rate limiting, and forwards the request to the Remittance service.
- The Remittance service resolves the corridor, obtains a live FX quote from the FX service, and creates a pending transaction.
- The Risk and Fraud services evaluate the transaction against behavioural and rules-based models, including the user's risk tier; the Compliance service applies sanctions and AML screening.
- On approval, the Ledger service records a pending double-entry posting against the user's USD wallet.
- The Integration layer initiates the payout through the appropriate partner rail (e.g., NGN payout via a Nigerian banking partner, or a card-funded on-ramp via Coinflow where applicable).
- When the partner confirms settlement, the Ledger service finalises the posting, and the Notifications service informs the sender and recipient through the app.
This pattern — client → gateway → product service → core services → integration layer → partner rail — is consistent across all money-movement flows on the platform.