Sicherheit und Compliance
Regulierung: eine Grenze, keine Kontrolle
Wir blockieren verbotene Aktionen nicht zur Laufzeit — wir legen sie in der Oberfläche gar nicht erst an. Eine regelwidrige Operation ist keine abgelehnte Anfrage, sondern eine Operation, die nicht existiert.
Grenzen
Eine Operation, die nicht existiert, kann nicht verletzt werden
- 01Für die Bestellung von Sicherheiten während der Ansparphase gibt es keine Maske — und auch die Serviceschicht lehnt sie ab.
- 02Keine Rolle besitzt eine Operation zum Bearbeiten eines Verlosungsergebnisses.
- 03Das Abzugsfeld eines Widerrufs kann nicht bearbeitet werden.
- 04Für den Pool sind nur drei Abflussarten definiert; eine vierte existiert nicht.
- 05Eine Verlosung, die das Kontingent überschreitet, kann nicht gestartet werden.
Alle 36 Validierungsregeln sind auf einen konkreten Regulierungsartikel zurückführbar.
Verlosung
Prüffähige Verlosung: ein fertiges Nachweispaket
Jede Ziehung schließt mit einem fünfteiligen, kryptografisch verifizierbaren, zeitgestempelten Nachweispaket.
- 01Unveränderliches ProtokollbandJeder Schritt der Ziehung wird auf einem unveränderlichen, zeitgestempelten Protokollband festgehalten.
- 02Eingefrorene BerichtskopieDer Bericht zum Ziehungszeitpunkt wird eingefroren; keine spätere Sicht kann ihn ersetzen.
- 03FunktionstrennungsmatrixWer die Ziehung vorbereitet, freigegeben und veröffentlicht hat, wird in einer Matrix festgehalten.
- 04Reproduktion aus Seed und ListeDas Ergebnis kann aus dem Seed und der gesperrten Teilnehmerliste unabhängig reproduziert werden.
- 05Lesendes PrüferprofilPrüfer greifen über ein Profil, das nichts verändern kann, auf das gesamte Nachweispaket zu.
Kontrollen
Compliance ist Design, keine Konfiguration
- Ausrichtung am BDDK-BS-KommuniquéEntworfen entlang der Erwartungen des IT-Kommuniqués der türkischen Bankenaufsicht: Prüfpfade, Zugriffsverwaltung, Funktionstrennung, Redundanz und Prüffähigkeit sind Architekturannahmen, keine Nachrüstungen. Prüfungsbereitschaft ist tägliche Arbeitsweise, kein Projekt.
- Append-only-PrüfpfadFinanzereignisse und administrative Aktionen sind unveränderliche Einträge — keine Updates, keine Löschungen. Die Laufzeit-Datenbankrolle hat auf den Ereignis- und Prüfpfadtabellen kein UPDATE/DELETE-Recht. Wer was wann und mit welcher Berechtigung getan hat, ist über die traceId lückenlos nachvollziehbar.
- Vier-Augen-PrinzipKritische Vorgänge — Vertragsfreigabe, Veröffentlichung einer Verlosung, Einreichung von Aufsichtsmeldungen, Tarifänderungen — trennen Erfasser und Freigeber. Niemand gibt die eigene Arbeit frei (MSG-S-21); die Freigabekette liegt im Prüfpfad.
- KVKK / DSGVOPersonenbezogene Daten werden zweckgebunden klassifiziert, der Zugriff ist rollen- und anlassbezogen. Aufklärung, Einwilligung und Betroffenenrechte sind in KVKK- wie DSGVO-Terminologie als Workflows modelliert. Löschbegehren werden über eine mit Aufbewahrungspflichten vereinbare Anonymisierung erfüllt.
- Datenresidenz je InstitutWo die Daten eines Instituts liegen, wird im Vertrag definiert und die Infrastruktur entsprechend aufgebaut. Für Institute mit Datenresidenz in der Türkei wird Inlandshosting unterstützt.
- Identität und ZugriffOIDC-Authentifizierung in Produktion (Authorization Code + PKCE), Berechtigungscodes als Realm-Rollen, Sitzungsrichtlinien. Entwickler-Header werden in ausgerollten Umgebungen abgewiesen.
Kontrollregister
Vierzehn Kontrollen, jede an einen Mechanismus gebunden
Compliance ist keine Artikelliste, sondern ein Mechanismus, der läuft. Jede Zeile nennt eine Kontrolle, den Mechanismus, der sie durchsetzt, den Nachweis, den eine Prüfung sieht, und ihre Grundlage.
| Nr. | Kontrolle | Mechanismus | Nachweis / Code | Grundlage |
|---|---|---|---|---|
| CTL-01 | Append-only-Journal | Die Laufzeit-Datenbankrolle hat auf es.events und audit.audit_log kein UPDATE/DELETE-Recht; Korrekturen sind Stornobuchungen. | (stream_type, stream_id, seq) · recorded_at | BDDK-BS-Kommuniqué · Prüfpfade |
| CTL-02 | Vier-Augen-Prinzip | Erfasser und Freigeber sind getrennt; contract:approve erlaubt nicht, den eigenen Vertrag freizugeben. Auch Berichtsvorbereitung und Einreichung sind verschiedene Personen. | MSG-S-21 | Funktionstrennung |
| CTL-03 | Authentifizierung | OIDC Authorization Code + PKCE (S256), Token-Lebensdauer 900 s; Entwickler-Header werden in ausgerollten Umgebungen abgewiesen. | MSG-G-12 | Keycloak 26 · Realm tfs |
| CTL-04 | Route → Berechtigungstabelle | Jede Schreibroute ist an einen Berechtigungscode gebunden (party:create, contract:approve, lottery:run, delivery:manage…); eine Anfrage ohne Treffer wird abgewiesen. | MSG-G-12 · Realm-Rollen | Minimale Rechte |
| CTL-05 | Mandantenisolation | Der Header x-tenant wird gegen ^[a-z0-9][a-z0-9-]{0,31}$ geprüft; je Mandant ein eigenes Durable Object und SQLite-Journal, on premise ein isolierter Stack je Institut. | MSG-G-02 | Datenresidenz · Isolation |
| CTL-06 | Finanzlage-Gate | Ohne genehmigten Eigenkapital-/Bilanzsummen-Eintrag oder mit einer Standardquote unter 3 % wird kein neuer Vertrag geschrieben; Erfassen und Freigeben sind verschiedene Rollen. | MSG-S-56 · prudential:approve | MADDE 20 |
| CTL-07 | Informationsfrist | Ein Vertrag kann nicht abgeschlossen werden, solange das vorvertragliche Informationsformular jünger als ein Tag ist; die Regel-Engine lehnt ab. | MSG-S-05 | MADDE 16/5 |
| CTL-08 | Insider- und Risikogruppengrenze | Das Verbot von Verträgen mit Insidern und die Grenze für Verträge mit einer Person oder Risikogruppe relativ zum Eigenkapital werden beim Abschluss geprüft. | MSG-S-57 | MADDE 22/A |
| CTL-09 | Zuteilungsschwelle | Ein Vertrag kommt nicht in die Periode, bevor 40 % des Betrags angespart und 40 % der Laufzeit vergangen sind; mit überfälliger Rate bleibt er draußen. | AllocationEvaluated | MADDE 21/2 |
| CTL-10 | Reservefonds und Kapazität | 5 % des Poolsaldos werden zurückgehalten; Kapazität = Saldo × Deckungsquote, vom Treasury abgeleitet, nie eingegeben. | deliveryCapacity | MADDE 30/1 |
| CTL-11 | Integrität der Ziehung | SHA-256-Digest der gesperrten Liste, aufgezeichneter Seed und Algorithmusversion; die Ziehung der Periode ist einmalig; verifyLottery reproduziert und vergleicht. | LotteryDrawn · expectedSeq 0 | Fünfteiliges Nachweispaket |
| CTL-12 | Zahlungsfrist Verkäufer | 10 Werktage ab Zuteilung; in der Lieferakte verfolgt, die Auszahlung schreibt fünf Buchungen in einer Unit of Work. | DeliveryDisbursed | MADDE 17/9 |
| CTL-13 | Veröffentlichung von Regelwerken | Die Veröffentlichung verlangt eine Referenz auf die eingereichte Dokumentversion, und jeder Wert muss dem autoritativen Wert im Dokument entsprechen. | MSG-S-92 | MADDE 15 |
| CTL-14 | Dokumentations-Gate | Gesperrte Seiten werden ohne geprüften Schlüssel nicht ausgeliefert (private, no-store, noindex); gespeichert wird nur der SHA-256 eines Schlüssels, und das Sperren eines Mandanten schließt ihn. | 401 · tfs_docs_key | Control Plane |
Die Codes stammen aus dem dreisprachigen Meldungskatalog der Plattform, die Artikel aus der Verordnung über Gründung und Geschäftsgrundsätze der Sparfinanzierungsgesellschaften; die Aussagen beschreiben Gestaltungsziele, keinen Zertifizierungsanspruch.
Sicherungsschichten
Die Architektur selbst trägt die Compliance
Drei Architekturentscheidungen tragen die Compliance — keine Prozessdokumente.
- Der Prüfpfad ist GeschäftsdatenDas Ereignisjournal ist die append-only geführte Single Source of Truth: Salden, Berichte und Ansichten werden daraus abgeleitet. Unlöschbar, unveränderlich, wieder abspielbar.
- Zeitliche RegelfixierungJeder Vertrag wird auf die bei Abschluss gültige Regelwerksversion fixiert. „Welche Regel hat diese Rate erzeugt?“ hat immer eine eindeutige Antwort.
- Mandanten-IsolationsmodellIm verwalteten Profil hat jedes Institut ein eigenes Durable Object und ein eigenes SQLite-Journal; im On-Premise-Profil einen isolierten Stack je Institut. Die Hosting-Schicht ist anbieterneutral.
Releases
Laufend aktuell, nie überrascht
Die Plattform wird kontinuierlich aktualisiert, mit Support von N bis zurück zu N-5. Sie häufen nie „Versionsschulden“ an. Jedes Upgrade folgt einer Standard-Pipeline.
- 01Wirkungsanalyse
- 02Test
- 03Abnahme
- 04Produktion
- 05Rollback-Plan
- Kalenderausschlüsse
- Upgrades werden nie geplant in: Verlosungstagen · volumenstarken Zeiträumen · Periodenabschlüssen
Deployment
Deployment-Profile
Das Institut entscheidet, wo die Plattform läuft; zentrales Monitoring und eine Standard-Pipeline aus Dev / Test-UAT / Produktion gelten für alle drei.
- Das Rechenzentrum des InstitutsDie Plattform läuft vollständig im eigenen Rechenzentrum, auf eigener Infrastruktur (Docker Compose oder Helm). Datenresidenz und physische Kontrolle bleiben beim Institut.
- Private Cloud im LandEine dedizierte, isolierte Private-Cloud-Umgebung mit Hosting in der Türkei. Die Daten bleiben im Land; die Betriebslast wird geteilt.
- Managed HostingInstallation, Monitoring und Release-Betrieb werden von Karya Bilişim verantwortet. Für lizenzierte Institute erfordert die Auslagerungsfrage nach Artikel 32 ein Rechtsgutachten.
Sicherheitsdokumentation und Prüfungsunterstützung
Für technische Dokumentation vor der Prüfung, Architekturdiagramme und die Kontrollmatrix wenden Sie sich an unser Team.