Data Architecture
Data Domains
Data is organised into clearly defined domains owned by the corresponding services. Cross-service access occurs through APIs or event streams, not through shared database access.
| Domain | Examples of Data | Retention Driver |
|---|---|---|
| Identity | User profile, KYC attributes, device bindings, authentication events. | Regulatory (KYC/AML retention rules per jurisdiction). |
| Ledger | Transactions, entries, balances, reconciliations. | Statutory accounting and audit requirements. |
| Payments | Payment requests, rail selections, partner references, callbacks. | Rail and partner dispute windows; AML record-keeping. |
| Cards | Card metadata, tokens, authorisations, disputes. | Scheme (Visa/Mastercard) and PCI DSS requirements. |
| Credit | Credit builder loan terms, repayment schedules, bureau reports. | FCRA and bureau retention rules. |
| Compliance | Screening hits, case files, SAR/STR records. | Regulatory retention (typically 5+ years). |
| Analytics | Aggregated, de-identified usage and performance data. | Internal analytical use. |
Sensitive Data Classification
Data is classified into four tiers, each with distinct handling requirements:
| Tier | Description |
|---|---|
| Tier 1 — Regulated cardholder data | Full PANs, CVV, track data. NEVER stored in Kredete systems; handled only by PCI-DSS-compliant partner processors. Systems referencing these values handle tokens only. |
| Tier 2 — Personally identifiable information (PII) | Names, addresses, dates of birth, government ID numbers, KYC documents, biometric templates. Encrypted at rest and in transit; access is role-based and fully audited. |
| Tier 3 — Financial and transactional data | Balances, transactions, ledger entries, partner references. Encrypted at rest; strict service-to-service access controls. |
| Tier 4 — Operational and analytical data | De-identified, aggregated, or non-sensitive attributes used for product analytics and reporting. |
Sensitive Data Flow
Sensitive data traverses the platform according to the following principles:
- All client–server traffic is TLS 1.2+ encrypted; internal service-to-service traffic is mutually authenticated and encrypted.
- Card data is captured directly into partner-hosted fields or SDKs, never passing through Kredete application servers in the clear.
- KYC documents are uploaded directly to object storage using signed, short-lived upload URLs; server-side encryption is applied on write.
- Biometric templates used for face authentication are stored as irreversible representations; raw images are not retained beyond the verification step.
- Database-level encryption uses managed keys under the organisation's key-management service, with key rotation performed on a defined schedule.
Data Storage Components
- Primary transactional stores: relational databases (e.g., PostgreSQL) for ledger, accounts, payments, and compliance domains, deployed as managed clusters with synchronous replication and point-in-time recovery.
- Caching and in-memory stores: managed Redis for session state, rate limiting, FX quote caching, and hot read paths.
- Event streaming: a managed message bus used for domain events, audit log ingestion, and asynchronous orchestration between services.
- Object storage: used for KYC documents, exported reports, and other large artefacts, with server-side encryption and object versioning enabled.
- Analytical store: a columnar data warehouse for business intelligence, product analytics, and regulatory reporting, fed from the operational stores via change-data-capture and event streams.