Solutions · Savings-finance companies
The whole operation, in one auditable core
Designed for the daily realities of a licensed savings-finance company — pools, draws, collections, reconciliation, audits. Not module by module: end to end.
Daily realities
Sound familiar?
- Regulation tempoWaiting for system changes whenever BDDK rules move: every circular update turns into a software project.
- Draw-day stressProving the fairness of a draw after the fact: scattered minutes, hand-compiled lists, late answers to questions.
- Reconciliation burdenManual reconciliation between bank accounts, the pool ledger and accounting; cent-level differences mean days of tracing.
- Audit preparationWeeks of evidence gathering before every audit; a folder of screenshots, e-mails and spreadsheets.
- Growing painsNew branch, new product, new campaign — each one a request waiting in the vendor queue.
Scenario
One allocation period, as the operations manager sees it
Step by step, from preparing the period to end of day: which screen writes which event, and which rule applies where.
Operations manager · Demo TF step 01 of 07
Clear the task inbox
Before the period the suspense queue is closed: unmatched transfers are matched to the next installment or refunded; because a contract with an overdue installment cannot enter the period, the delinquency tasks are handled first.
From need to module
Every need maps to a clear subset of the catalogue
Operational needs map to specific modules of the 28-module catalogue; not integrations, but parts of one body.
| Need | Modules | How it is met |
|---|---|---|
| Savings plan and tariff management | catalog · calc · rule-engine | Plans are defined on screen and tested by simulation; every contract is pinned to the rule version in force at establishment. |
| Pool and allocation operations | pool · allocation · treasury | Liquid pool monitoring, allocation periods and forward-looking capacity projection inside the core. |
| Fair, provable draws | allocation · lottery · audit | Draws reproducible from seed and locked participant list; closed with a five-part frozen evidence set. |
| Collections and matching | collections · tasks · accounting | Recorded payments match the next open installment; unmatched ones land in the suspense queue and the task inbox. |
| Remote customer acquisition | kyc · crm · compliance | A remote onboarding flow from application to contract — a module of the core, not a separate product. |
| Accounting and regulatory reporting | accounting · reporting · eod | Journal entries derived from the event ledger; report preparation and submission under four-eyes, once per period. |
Integration
Integration points
Talking to the ecosystem is the platform’s job — the adapter layer is standard, integration is not a project. Which seam works today and which ships as a port is stated plainly in the documentation.
- Identity verificationIdentity-verification provider port (document OCR, NFC, liveness, video-call capability flags); KPS/NVİ adapters
- BankingPayment-recording REST endpoint; virtual IBAN and statement matching through the institution’s own collection infrastructure
- MASAK and complianceSanctions-screening port, compliance cases and review tasks
- Accounting / ERPEvent stream (AMQP, tfs.events), contract CSV export, chart-of-accounts mapping
- CommunicationsSMS and e-mail channel ports; KEP and e-signature adapters
- Open APIEvery module exposed over REST; event stream subscriptions and ClickHouse analytics views
Migrating from your current system, or greenfield?
In a half-day technical discovery we map out both paths — data migration strategy included.