Start / Plattform
Funktionsatlas. Alles, was die Plattform kann – bis zum einzelnen Prozess.
Die fachliche Landkarte unserer Wertpapier-Kernbank: 6 Leistungsfelder, 21 Module, jeder Prozess mit Status, Automatisierung und Detailblatt – nach Leistungsfeld, entlang des Kundenwegs, aus Sicht Ihres Fachbereichs oder nach technischem Baustein.
Innerer Ring: sechs Leistungsfelder. Äußerer Ring: 21 Module. Wählen Sie ein Modul, um seine Prozesse zu sehen; jeder Prozess öffnet ein Detailblatt.
Der Weg Ihres Kunden – vom Antrag bis zur Schließung. Je Phase: was passiert, welche Prozesse laufen und welche Dokumente entstehen.
Wählen Sie Ihren Bereich: Ihr Tag mit der Plattform und die Prozesse, für die Sie verantwortlich sind.
Die technischen Bausteine der Plattform und welche Prozesse sie tragen.
Stand: Funktionsatlas v1.5. Öffentlich gezeigt werden produktive, in Umsetzung befindliche, über Partner abgedeckte und geplante Prozesse. Ablaufbeschreibungen, Vorlagen und Testfälle im Detail finden Kunden im Handbuch.
Plattform · Architektur
Architektur. So ist die Plattform gebaut.
Eigener Kern aus Erlang/OTP und PostgreSQL, betrieben in einer getrennten AWS-Umgebung je Mandant. Klicken Sie auf einen Baustein für die Erklärung.
Nutzer & Kanäle
Kunden-AppWeb & Mobile · BERNA
BackofficeWeb-App · CAMILLA
Partner & MandantensystemeREST · OpenAPI
Onboarding & Webfilialein Umsetzung
HTTPS · Anmeldung über OpenID Connect (OIDC)
AWS · eigene, isolierte Umgebung je Mandant DEV · UAT · PROD
Zugang
Route 53 & ACMDNS, TLS
CloudFrontWeb-Auslieferung
API GatewayREST & WebSocket
Load BalancerHealth-Checks
Cognito / OIDCIdentität & Rechte
Plattformkern ANGELAErlang/OTP · ECS Fargate · Rolling Deploy ohne Ausfall
REST-GatewayBuchung, Konten, DepotsScheduler & BatchesMakler & KostenstellenE-Mail · SMS · In-AppLokalisierung
Fachlogik in der DatenbankPostgreSQL · Amazon RDS
Stored ProceduresHistorisierung & Audit-TrailMandantendaten
Reporting FRANZISKAAWS Lambda · Python
Auszüge & BescheinigungenAuslieferung per Object Lambda
Integration
WM-ImportWertpapierdaten
SWIFT & CAMTMT5xx · MT940 · CAMT.053
TaxboxAnschaffungsdaten
KISTAM & MeldungenKirchensteuer, steuerl. Meldungen
Datei-ExportSFTP · HTTPS mit Zertifikat
Speicher
S3 Importversioniert, privat
S3 Report-WorkdirReports, Exporte
Log-ArchivS3 · CloudWatch
Secrets & ParameterSecrets Manager · SSM
SWIFT · SFTP · HTTPS · REST
Umsysteme
Depotbanken & Verwahrstellen
Zentralverwahrerz. B. Clearstream
Banken & Zahlungsverkehr
WM Datenservice
FinanzverwaltungBZSt, Meldungen
Hauptbuch / Fibu
Meldewesen
Börsen & Broker
Betrieb & Auslieferung
GitHub→CodeBuild & Tests→ECR→CloudFormation · IaC
CloudWatch MonitoringAdmin-Zugriff ohne öffentliche Endpunkte
Qualität & Nachweis
KI-Agenten der BankfactoryAutomatisierte TestsGoBD-geprüft · IDW PS 860
Architekturprinzipien
Fachliche Logik, die über Jahre stabil bleibt
Trennung der Verantwortlichkeiten
Fachliche Regeln, Prozessorchestrierung, Datenhaltung und Integration sind bewusst entkoppelt.
FachlogikTechnikIntegrationBetrieb
Ereignis- und regelbasiert
Prozesse sind Ketten nachvollziehbarer Schritte – ausgelöst durch Ereignisse, Zeitfenster (Batch) oder externe Rückmeldungen.
EventBatchRegeln
Auditierbar und reproduzierbar
Jeder Verarbeitungsschritt ist fachlich und technisch belegbar – mit Regeln, Eingangsparametern und Zustandsänderungen.
Audit-TrailHistorisierung
Integration first
Lose Kopplung über Events, stabile APIs und klare Versionierung; Adapter halten kundenspezifische Formate vom Kern fern.
EventsAPI ContractsVersionierung
Processing Engine
Schrittketten statt Ad-hoc-Logik, Idempotenz für robuste Wiederholungen, explizite Ausnahme- und Reprocessing-Pfade.
Rule Engine
Versionierte Regeln mit Freigabeprozess und Regelkontext (Gültigkeit, Institution, Produkt, Zeit).
Event & Data Layer
Konsistente, historisierte Persistenz für Rückverfolgung, Reproduktion und Langzeitauswertung.
Observability & Audit
Durchsatz, Latenzen, Fehlerraten und eine fachliche Prozesssicht für Betrieb, Reconciliation und Revision.
Einführungsmuster
Parallelbetrieb, schrittweise Migration entlang klarer Prozessschnitte, kontrollierte Umschaltung mit Reconciliation.
Typische Umsysteme
Handel und Order, Kernbank und Kundenverwaltung, Verwahrstellen, Reporting, Data & BI.
Betrieb
Horizontale Skalierung, Resilienz durch entkoppelte Komponenten, Mandantenfähigkeit, minimale Rechte und Segmentierung.
Umgebungen
Getrennte Accounts für DEV, UAT und PROD; promotete Builds statt manueller Eingriffe, reproduzierbare Deployments.
Technologie-Stack
Erprobte Technologien
Frage & Antwort
Alle Fragen zur Plattform
Aufbau & Daten
Wie ist das System grundsätzlich geschnitten?
Die Plattform ist in Ebenen gegliedert: Frontends (Kanäle), Edge und API (Zugang und Routing), Plattformkern (Domänenlogik), Datenhaltung (Transaktionen und Dokumente) und Integrationen (Adapter zu Umsystemen).
- Kanäle
- Mobile App, Web App, Backoffice Web App
- Edge
- CDN, Load Balancer, API Gateway, OIDC IAM
- Kern
- Framework Angela (Domänenmodule)
- Daten
- PostgreSQL (RDS) und Objektablage (S3)
- Umsysteme
- Partnerbank, Zentralverwahrer (z. B. Clearstream), Integrations-Hub, Finanz/Buchhaltung, Reporting/BI
Welche fachlichen Module deckt der Plattformkern ab?
Der Plattformkern bildet die wesentlichen Domänen der Wertpapier- und Kontenprozesse ab: Konto Management, Depot Management, Order Management, Zahlungsabwicklung, Wertpapierabwicklung, Steuern und Regulatorik, Reporting, Backoffice Operations. Öffentlich zeigen wir die Capability-Sicht. Die interne Service-Zerlegung ist Teil der technischen Dokumentation.
Was ist das Framework Angela?
Das Framework Angela ist eine Eigenentwicklung der DISACON AG und bildet die technische Grundlage unserer Wertpapier-Kernbank. Es stellt die zentrale Prozesslogik, Integrationsmuster und Kernkomponenten bereit, um Depot- und Wertpapierprozesse modular, skalierbar und revisionssicher abzubilden.
Welche Daten werden wo gehalten?
Transaktionale Zustände werden relational gespeichert, Dokumente und Artefakte in einer Objektablage.
- Relationale DB
- PostgreSQL (Amazon RDS) für fachliche Zustände, Historisierung und Konsistenz
- Objektablage
- Amazon S3 für Dokumente, Exporte, Workdir-Artefakte und Log-Archive
- Logging
- ALB Logs in S3; zusätzlich Log-Archiv (S3 Archive)
Wie werden externe Systeme angebunden?
Anbindungen erfolgen über einen Integration Layer, der Umsysteme vom Kern entkoppelt.
- Eingänge
- REST API, File Transfer (SFTP; CSV/PDF), Finanzformate (SWIFT MT/MX)
- Funktion
- Mapping und Validierung, Adapter je Partner, Idempotenz, Reprocessing
- Zielsysteme
- Partnerbank, Clearstream, X-Hub, ABACUS, Reporting Manager, Finanzbuchhaltung
Welche Nutzergruppen und Clients gibt es?
Die Plattform wird über unterschiedliche Clients genutzt; zusätzlich gibt es Partner- und Betriebszugriffe.
- Interne Nutzer*innen
- Backoffice (Web App) und operative Werkzeuge
- Kund*innen
- Web App und Mobile App (z. B. berna Web App und berna Mobile App)
- Interne Web App
- camilla Web App (für interne Nutzer*innen)
- Partner
- Partner Datacenter (Anbindung an API Gateway)
- Developer
- GitHub als Source Control für Build und Deployment
Cloud, Sicherheit & Betrieb
Wie sieht die AWS-Cloud-Infrastruktur aus?
Die Cloud-Infrastruktur gliedert sich in Edge, Workloads, Datenhaltung und Betriebsfunktionen.
- DNS und TLS
- Route 53 und AWS Certificate Manager (ACM)
- CDN
- CloudFront für Web Delivery (z. B. camilla und berna)
- Ingress
- API Gateway, Public ALB, OIDC
- Workloads
- ECS/Fargate Cluster (angela backend), Lambda (report, tbd)
- Daten
- RDS, S3 Buckets (web apps, certstore, workdir)
- Logging
- ALB logs nach S3; Log Archive Bucket
- Observability
- CloudWatch für Monitoring und Logging
- Config und Secrets
- SSM Parameter Store
- Privater Zugriff
- Private ALB und Bastion für administrative Pfade
Wie läuft CI/CD und Deployment (mehrere AWS-Accounts)?
CI/CD ist als Pipeline umgesetzt und kann über getrennte Accounts (z. B. build-account und deploy-account) betrieben werden.
- Source Control
- GitHub
- Build
- CodeBuild
- Registry
- ECR
- Deployment
- CodePipeline, CloudFormation
- Targets
- ECS/Fargate (Container) und Lambda (Batch/Reporting)
Wie werden Sicherheit und Nachvollziehbarkeit adressiert?
- Ingress über definierte Gateways (CDN, API Gateway, Load Balancer)
- Authentifizierung/Autorisierung über OIDC/IAM
- Historisierung und Korrelation von Verarbeitungsschritten für Auditierbarkeit
- Monitoring/Logging und Archivierung (CloudWatch, S3 Log Archive)
Wie erfolgt die Mandantentrennung bei DISACON?
Die Mandantentrennung erfolgt bei DISACON auf Infrastruktur-Ebene. Jeder Mandant erhält eine vollständig getrennte Betriebsumgebung mit klarer technischer Isolation. Durch den Cloud-Betrieb ist diese Trennung besonders effizient und kostengünstig umsetzbar. Die Bereitstellung erfolgt vollautomatisch über Infrastructure as Code, wodurch neue Mandantenumgebungen schnell, sicher und standardisiert ausgeliefert und betrieben werden können.
Ist die Plattform an einen bestimmten Cloud-Anbieter gebunden?
Die Plattform wird cloudbasiert auf Hyperscaler-Infrastruktur betrieben. Sie ist so gestaltet, dass der Betrieb perspektivisch auch in Multi-Cloud- oder Rechenzentrumsumgebungen umgesetzt werden kann, ohne den Kern der Lösung zu ersetzen.
Ist das System geprüft?
Ja. Das Framework ANGELA, die technische und fachliche Basis unserer Wertpapier-Kernbank, wurde von Deloitte nach IDW PS 860 i. V. m. IDW PH 9.860.4 im Hinblick auf die GoBD-Anforderungen geprüft. Die Prüfung bestätigt, dass das Framework über einen durchgängig konsistenten und belastbaren Kontrollrahmen zur Erfüllung der GoBD-Anforderungen verfügt. Alle wesentlichen Funktionen, insbesondere Buchungslogik, Audit-Trail, Datenverarbeitung und Aufbewahrung, greifen auf diesen zentralen Kontroll- und Verarbeitungsrahmen zurück.
Technologie & Performance
Warum Erlang?
Erlang ist speziell für hochverfügbare, fehlertolerante und skalierbare Systeme entwickelt – ursprünglich im Telekommunikationsumfeld, wo Milliarden von Nachrichten in Echtzeit verarbeitet werden. Diese Eigenschaften sind entscheidend für maximale Zuverlässigkeit.
Wieso Business-Logik direkt in der Datenbank?
Durch die zentrale Logik unmittelbar in der Datenbank vermeiden wir komplexe Middleware, reduzieren Fehlerquellen und beschleunigen die Verarbeitung erheblich. Das Ergebnis: nachvollziehbare Prozesse und maximale Performance ohne unnötige Zwischenschichten.
Handelt es sich um erprobte Technologien?
Wir setzen auf eine bewährte Architektur mit modernen Technologie-Stacks, die sich bereits in hochsensiblen Anwendungen wie WhatsApp oder Klarna erfolgreich bewährt haben.
Wie ist die Performance bei steigenden Volumina?
In unserer Lastanalyse liegt die Verarbeitungszeit bei rund 10 Millisekunden je Trade – auch im Szenario mit 220 Mio. Trades pro Jahr.
Lässt sich die Lösung effizient skalieren?
Die Architektur skaliert stufenweise: Rechenkapazität lässt sich zuschalten, ohne dass die Grundkosten im gleichen Maß steigen.
Fachliche Fragen
Ist die Steuerberechnung in die Plattform integriert?
Ja. Die Plattform bildet die steuerliche Verarbeitung von Kapitalerträgen für den deutschen Markt integriert ab. Die Steuerlogik ist Teil der Prozesskette und kann damit direkt in die End-to-End-Abwicklung eingebunden werden.
Kann ein externer Steuerkern angebunden werden (z. B. SECTRAS)?
Ja, grundsätzlich ist das möglich. Die Plattform kann so integriert werden, dass eine externe Steuerlogik – beispielsweise SECTRAS von cpb – als Bestandteil der End-to-End-Prozesskette genutzt wird. Dazu wurden bereits vertiefte fachliche und technische Abstimmungen durchgeführt, wie sich ein externer Steuerkern sauber in die bestehende Prozesslogik einbinden lässt. Eine produktive Anbindung ist dabei typischerweise ein separates Integrationsvorhaben.
Ist der Betrieb als Depotbank möglich?
Ja. Die Plattform kann auch im Umfeld einer Depotbank eingesetzt werden. Sie unterstützt die erforderlichen Prozesse und Integrationen, um depotbankspezifische Anforderungen abzubilden und den Betrieb in einer entsprechenden Rollenverteilung zu ermöglichen.
Ist ein White-Label-Betrieb möglich?
White-Label befindet sich auf der Roadmap von DISACON und ermöglicht den Betrieb mehrerer Mandanten mit eigenem Haftungsdach. Kunden werden dabei in separaten Umgebungen mit eigener Datenhaltung betrieben, wodurch vollständige Datenisolierung, hohe Performance und revisionssichere Audit-Prozesse sichergestellt werden. Ein White-Label-Betrieb für Mandanten ohne eigenes Haftungsdach ist grundsätzlich möglich und kann im Rahmen eines individuellen Projekts realisiert werden. Derzeit ist dies jedoch nicht als Standard vorgesehen.