OrdoSavings Finance Platform

Ordo · Karya Bilişim

The auditable core of savings finance

Pool ledger, lottery engine, contract lifecycle, identity and KYC, collections and audit trail — one event-sourced body. For processes under BDDK supervision: not waiting for audit day, but living audit-ready.

Plan a half-day discoveryTry the live simulation

A white-label platform: every institution goes live under its own brand. The screens here belong to the “Demo TF” sample installation.

28business modules
382functional requirements
3languages — tr · en · de
N-5version compatibility commitment
100%event-sourced audit trail

Capabilities

One core, eight capabilities

The whole of savings finance — from acquisition to settlement — runs on the same event ledger. The modules are not integrated with each other; they are parts of one body.

  1. 01Pool management and allocationLiquid pool ledger, allocation periods and capacity projection are part of the core. Capacity is derived by the treasury module, never typed in.
  2. 02Lottery engineDraws reproducible from the locked participant list, the recorded seed and the algorithm version. Each closes with a five-part evidence set.
  3. 03Contract lifecycleSaving, allocation, delivery, repayment and exits: every state transition is rule-bound and written to the event ledger.
  4. 04Identity and KYCRemote onboarding, identity and document verification, sanctions screening — modules of the same solution, not a separate product.
  5. 05Collections and reconciliationPayment recording, installment matching, the suspense queue and the pool-to-journal reconciliation; largest-remainder rounding on minor units.
  6. 06Rule engineEffective-dated rule sets bound to regulation articles. Every contract is pinned to the rule version in force at establishment.
  7. 07Audit trailAn append-only event ledger. The audit trail is not a by-product — it is the business data itself.
  8. 08Low-code studioScreen, field and flow changes made by the institution’s own team — within the boundaries of the core.

One day

A day in the life of an operator

Every screen in the console is a view of the same event ledger. Follow a working day, hour by hour, and see which module writes which event.

  1. 09:00Task inbox: what the night openedThe delinquency tasks (tiers 1/2/3), request-SLA tasks and suspense tasks opened by the end-of-day chain sit in one queue. Every task is bound to an event; closing it is written too.tasks · dunning · PaymentSuspended
  2. 09:40Four-eyes approvalA high-amount contract is in pending-approval. The approver may not be the user who established it (MSG-S-21); the approval is written as ContractApproved and ContractActivated.contract:approve · MSG-S-21
  3. 11:30Payment matchingA bank collection matches the next open installment exactly: the savings component goes to the pool, the fee component to income; the journal entry is posted in the same unit of work. An unmatched transfer lands in suspense — it is never lost.PaymentReceived · InstallmentMatched · JournalEntryPosted
  4. 14:00Period evaluationThe treasury derives capacity: balance × coverage ratio, reserve 5% (MADDE 30/1). Contracts past the 40% savings and 40% term threshold are ranked (MADDE 21/2); for a draw product the list is locked and the seed recorded.AllocationEvaluated · LotteryDrawn · EntitlementGranted
  5. 16:00Delivery fileValuation, insurance and collateral steps are recorded with their evidence. On disbursement the pool outflow, journal entry, repayment plan, collateral and notification are one unit of work; the seller is paid within 10 business days of allocation (MADDE 17/9).DeliveryStepCompleted ×3 · DeliveryDisbursed
  6. 00:00End of day (21:00 UTC)Delinquency scan, request-SLA scan and the pool-to-journal reconciliation. The result is written as EndOfDayCompleted; a second run for the same date returns the stored report.EndOfDayCompleted · idempotent

Live simulation

How is the pool shared?

Customers save into a common pool. Each period the platform ranks eligible contracts by savings ratio, then seniority, and grants entitlements while capacity lasts. The reserve fund holds back 5% of the pool (MADDE 30/1). Move the three controls and see who is granted, and why.

All simulations

Period inputs

Deterministicperiod DNM-2026-10 · portfolio 779d90d82499

Order: savings ratio first, then seniority. In production the capacity is derived from the treasury module, never typed in; the coverage ratio is a rule-pack parameter.

Reserve fund 5% · MADDE 30/1—
Allocable capacity—
Used ——
Remaining—
RankContractSavedNeedResult
Why this one and not that one?

The sample portfolio contains no real person or institution; the calculation runs in your browser and nothing is sent anywhere.

Architecture

Six layers, one body

From channels to platform services: every layer runs on the same event ledger, bound to the same rule engine.

The full architecture
ChannelsMobile · Web · Branch · Call Center · PartnerDigital AcquisitionRemote onboarding · Identity verification · Document checksCorePool ledger · Lottery engine · Contract ledger · Rule engineOperationsTask inbox · Deliveries · Collections · Delinquency actionsFinance & ComplianceAccounting · Regulatory reporting · MASAK / BDDK · Audit trailPlatformIdentity & access · Low-code studio · Monitoring · Open APIONE BODY
Channels, digital acquisition, core, operations, finance and compliance, platform — in one deployment body.
01ChannelsMobile, web, branch, call centre and partner: five channels call the same calculation service. Installment, savings, rank and capacity are computed in one place; there is no “different number” between channels.
02Digital acquisitionRemote onboarding, identity and document verification, sanctions screening. The identity-verification provider is a port; the output of the models at the edge enters the core as a signal only.
03CorePool ledger, lottery engine, contract ledger and rule engine — where the money lives. An append-only event ledger, a rule version pinned to the contract, no AI.
04OperationsTask inbox, deliveries, collections and delinquency actions. The repetitive load is automated in the core; people stay only where they decide: exceptions, approvals, negotiation.
05Finance and complianceJournal entries derive from the event ledger; regulatory reports are prepared and submitted under four eyes, once per period. The MASAK and BDDK lines connect through abstracted adapters.
06PlatformIdentity and access (Keycloak; realm roles are the permission codes), the low-code studio, monitoring and an open API versioned per consumer. The brand triple is the institution’s; the code never forks.

Audit

What the auditor sees

The moment a draw closes its evidence set is frozen: five parts, time-stamped, reachable through a read-only profile. The auditor does not ask — they re-run it with the same seed and the same list.

  1. 01The record tape is immutable; every step of the draw is time-stamped.
  2. 02The result is reproduced independently from the recorded seed and the locked participant list.
  3. 03The auditor profile can change nothing; segregation of duties is recorded in the matrix.
The whole evidence set
Hover a part: it explains what the auditor sees there, and why.

Diagnosis

The problem is architecture, not a missing feature

The solutions on the market do record transactions — recording is not the problem. Under every day-to-day complaint sits an architectural root cause.

These five causes were resolved by architectural decisions — not by adding features.

Comparison

The usual way and Ordo’s way

Nine topics where the difference shows in an institution’s daily work.

TopicThe usual wayOrdo
Regulatory changeDevelopment request, waiting for a releaseRule package — live the same day
New product / planA months-long projectDefined on screen, tested by simulation
Screen / field changeA ticket to the vendorThe institution’s team, in the low-code studio
Audit evidenceManual compilation, daysA frozen evidence package from one screen
Capacity projectionSpreadsheetsPart of the core
Remote onboardingA separate product, a separate integrationInside the same solution
Accounting and regulatory reportingThird-party patchesOne source derived from the event ledger
InstallationMonths of customisationAutomation and ready-made packages
VersionsYou stay on your versionContinuously current, N-5 support

Who it is for

Three kinds of institution, one core

Compliance

Designed for compliance

Not a certification claim but a design principle: the controls were built into the architecture from the start.

These statements describe design goals; they are not a claim of formal certification or regulatory approval.

Next step

A half-day technical discovery

In a half-day discovery session we settle five questions together. The output is a proposal with a clear scope, architecture and timeline.

destek@karyabilisim.comDocumentation
  1. 01Inventory of the current systems
  2. 02Hosting preference
  3. 03Migration or greenfield?
  4. 04Deployment profile
  5. 05Priority phase

Surfaces

The operations team, the customer and the partner work on the same event ledger, on separate role-based surfaces dressed in the institution’s brand.

Ordo OperationsOpen the demo

Task inbox, four-eyes approval queue, lottery management, collections and reconciliation screens.

Ordo PortalOpen the demo

Plan status, installment calendar, payment history and contract opening through remote onboarding.

Ordo PartnerOpen the demo

Delivery file, valuation–insurance–collateral evidence steps and seller payment tracking.

The screens are representative interfaces drawn with the demo installation’s sample data; the real surfaces carry the institution’s brand.