Security and compliance
Regulation: a boundary, not a check
We do not block forbidden actions at runtime — we never create them in the interface. A non-compliant operation is not a rejected request; it is an operation that does not exist.
Boundaries
An operation that does not exist cannot be violated
- 01There is no collateral field during the savings period — and the service layer refuses it too.
- 02No role has an operation to edit a draw result.
- 03The deduction field of a withdrawal cannot be edited.
- 04Only three outflow types are defined for the pool; a fourth does not exist.
- 05A draw exceeding the quota cannot be started.
All 36 validation rules trace back to a regulation article.
Lottery
Auditable draws: a ready evidence set
Every draw closes with a five-part, cryptographically verifiable, time-stamped evidence set.
- 01Immutable record tapeEvery step of the draw is kept on an immutable, time-stamped record tape.
- 02Frozen report copyThe report at the moment of the draw is frozen; no later view can replace it.
- 03Segregation-of-duties matrixWho prepared, approved and announced the draw is recorded in a matrix.
- 04Reproduction from seed and listThe result can be reproduced independently from the seed and the locked participant list.
- 05Read-only auditor profileThe auditor reaches the whole evidence set through a profile that can change nothing.
Controls
Compliance is design, not configuration
- BDDK IS communiqué alignmentDesigned along the expectations of the BDDK information-systems communiqué: audit logs, access management, segregation of duties, redundancy and auditability were built into the architecture from the start. Audit readiness is a daily way of working, not a project.
- Append-only audit trailFinancial events and administrative actions are immutable records — no updates, no deletes. The runtime database role has no UPDATE/DELETE privilege on the event and audit tables. Who did what, when and with which permission is traceable end to end through the traceId.
- Four-eyes principleCritical operations — contract approval, draw announcement, regulatory submissions, tariff changes — separate maker and checker. The maker cannot approve their own work (MSG-S-21); the approval chain is kept in the audit trail.
- KVKK / GDPRPersonal data is classified by purpose; access is limited by role and justification. Disclosure, consent and data-subject rights are modelled as workflows in both KVKK and GDPR terms. Erasure requests are met through anonymisation compatible with financial retention duties.
- Data residency per institutionWhere each institution’s data resides is defined in the contract and the infrastructure is set up accordingly. Domestic hosting is supported for institutions that require data residency in Türkiye.
- Identity and accessOIDC authentication in production (Authorization Code + PKCE), permission codes as realm roles, session policies. Developer headers are refused in deployed environments.
Controls ledger
Fourteen controls, each bound to a mechanism
Compliance is not a list of articles but a mechanism that runs. Every row names a control, the mechanism that enforces it, the evidence an audit will see and its basis.
| No | Control | Mechanism | Evidence / code | Basis |
|---|---|---|---|---|
| CTL-01 | Append-only ledger | The runtime database role has no UPDATE/DELETE privilege on es.events and audit.audit_log; corrections are reversal entries. | (stream_type, stream_id, seq) · recorded_at | BDDK IS communiqué · audit logs |
| CTL-02 | Four-eyes principle | Maker and checker are separated; holding contract:approve does not let you approve a contract you established. Report preparation and submission are separate people too. | MSG-S-21 | Segregation of duties |
| CTL-03 | Authentication | OIDC Authorization Code + PKCE (S256), 900 s token lifespan; developer headers are refused in deployed environments. | MSG-G-12 | Keycloak 26 · realm tfs |
| CTL-04 | Route → permission table | Every write route is bound to a permission code (party:create, contract:approve, lottery:run, delivery:manage…); an unmatched request is refused. | MSG-G-12 · realm roles | Least privilege |
| CTL-05 | Institution isolation | The x-tenant header is validated against ^[a-z0-9][a-z0-9-]{0,31}$; one Durable Object and SQLite ledger per tenant, an isolated stack per institution on premise. | MSG-G-02 | Data residency · isolation |
| CTL-06 | Financial-position gate | Without an approved equity / total-assets record, or with a standard ratio below 3%, no new contract is written; entering and approving are different roles. | MSG-S-56 · prudential:approve | MADDE 20 |
| CTL-07 | Disclosure period | A contract cannot be established while the pre-contract disclosure form is less than one day old; the rule engine refuses. | MSG-S-05 | MADDE 16/5 |
| CTL-08 | Insider and risk-group limit | The ban on contracts with insiders and the limit on contracts with one person or risk group relative to equity are checked at establishment. | MSG-S-57 | MADDE 22/A |
| CTL-09 | Allocation threshold | A contract cannot enter the period before 40% of its amount is saved and 40% of its term has elapsed; one with an overdue installment stays out. | AllocationEvaluated | MADDE 21/2 |
| CTL-10 | Reserve fund and capacity | 5% of the pool balance is held back; capacity = balance × coverage ratio, derived by the treasury, never typed in. | deliveryCapacity | MADDE 30/1 |
| CTL-11 | Draw integrity | SHA-256 digest of the locked list, recorded seed and algorithm version; the period’s draw is single-use; verifyLottery reproduces and compares. | LotteryDrawn · expectedSeq 0 | Five-part evidence set |
| CTL-12 | Seller payment deadline | 10 business days from allocation; tracked on the delivery file, the disbursement writes five postings in one unit of work. | DeliveryDisbursed | MADDE 17/9 |
| CTL-13 | Rule-set publication | Publication requires a reference to the filed document version and every value must match the authoritative value in that document. | MSG-S-92 | MADDE 15 |
| CTL-14 | Documentation gate | Gated pages are not served without a verified key (private, no-store, noindex); only the SHA-256 of a key is stored, and suspending a tenant closes it. | 401 · tfs_docs_key | Control plane |
Codes come from the platform’s trilingual message catalogue, articles from the Regulation on the Establishment and Operating Principles of Savings-Finance Companies; the statements describe design goals, not a certification claim.
Assurance layers
The architecture itself carries compliance
Three architectural decisions carry compliance — not process documents.
- The audit trail is business dataThe event ledger is the append-only single source of truth: balances, reports and screens are derived from it. Undeletable, immutable, replayable.
- Temporal rule pinningEvery contract is pinned to the rule-set version in force at establishment. “Which rule produced this installment?” always has a definite answer.
- Institution isolation modelIn the managed profile every institution has its own Durable Object and its own SQLite ledger; in the on-premise profile an isolated stack per institution. The hosting layer is provider-neutral.
Releases
Continuously current, never surprised
The platform is updated continuously, with support from N back to N-5. You never accumulate “version debt”. Every upgrade follows a standard pipeline.
- 01Impact analysis
- 02Test
- 03Acceptance
- 04Production
- 05Rollback plan
- Calendar exclusions
- Upgrades are never scheduled in: Draw days · High-volume periods · Period-end closings
Deployment
Deployment profiles
The institution decides where it runs; central monitoring and a standard dev / test-UAT / production pipeline apply to all three.
- The institution’s data centreThe platform runs entirely in the institution’s own data centre, on its infrastructure (Docker Compose or Helm). Data residency and physical control stay with the institution.
- Domestic private cloudA dedicated, isolated private-cloud environment hosted in Türkiye. Data stays in the country; the operational load is shared.
- Managed hostingInstallation, monitoring and release operations are run by Karya Bilişim. For licensed institutions the Article 32 outsourcing question requires a legal opinion.
Security documentation and audit support
Contact our team for pre-audit technical documentation, architecture diagrams and the control matrix.