Home / Platform
Function Atlas. Everything the platform can do – down to the individual process.
The functional map of our securities core banking platform: by capability area, along the customer journey, from the perspective of your department or by technical building block. Every process with status, degree of automation and detail sheet.
processes in the atlas
of which in production
fully automated
21modules in 6 capability areas
9phases in the customer lifecycle
Inner ring: six capability areas. Outer ring: 21 modules. Select a module to see its processes; each process opens a detail sheet.
Your customer's journey – from application to closure. For each phase: what happens, which processes run and which documents are produced.
Choose your department: your day with the platform and the processes you are responsible for.
The technical building blocks of the platform and the processes they support.
Status: Function Atlas v1.5. Shown publicly are processes that are in production, in progress, covered via partners or planned. Detailed process descriptions, templates and test cases are available to clients in the Manual.
Platform · Architecture
Architecture. How the platform is built.
Our own core built on Erlang/OTP and PostgreSQL, operated in a separate AWS environment for each client. Click a building block for an explanation.
Users & channels
Customer appWeb & mobile · BERNA
Back officeWeb app · CAMILLA
Partner & client systemsREST · OpenAPI
Onboarding & online branchin progress
HTTPS · sign-in via OpenID Connect (OIDC)
AWS · own, isolated environment per client DEV · UAT · PROD
Access
Route 53 & ACMDNS, TLS
CloudFrontWeb delivery
API GatewayREST & WebSocket
Load BalancerHealth checks
Cognito / OIDCIdentity & permissions
Platform core ANGELAErlang/OTP · ECS Fargate · rolling deploy without downtime
REST gatewayBookings, cash accounts, securities accountsScheduler & batchesBrokers & cost centresEmail · SMS · in-appLocalisation
Business logic in the databasePostgreSQL · Amazon RDS
Stored proceduresHistory & audit trailClient data
Reporting FRANZISKAAWS Lambda · Python
Statements & certificatesDelivery via Object Lambda
Integration
WM importSecurities data
SWIFT & CAMTMT5xx · MT940 · CAMT.053
TaxboxAcquisition data
KISTAM & reportsChurch tax, tax reports
File exportSFTP · HTTPS with certificate
Storage
S3 importversioned, private
S3 report workdirReports, exports
Log archiveS3 · CloudWatch
Secrets & parametersSecrets Manager · SSM
SWIFT · SFTP · HTTPS · REST
Surrounding systems
Custodian banks & depositaries
Central securities depositoriese.g. Clearstream
Banks & payments
WM Datenservice
Tax authoritiesBZSt, reports
General ledger / accounting
Regulatory reporting
Exchanges & brokers
Operations & delivery
GitHub→CodeBuild & tests→ECR→CloudFormation · IaC
CloudWatch monitoringAdmin access without public endpoints
Quality & assurance
Bankfactory AI agentsAutomated testsGoBD-audited · IDW PS 860
Architecture principles
Business logic that remains stable for years
Separation of concerns
Business rules, process orchestration, data storage and integration are deliberately decoupled.
Business logicTechnologyIntegrationOperations
Event- and rule-based
Processes are chains of traceable steps – triggered by events, time windows (batch) or external responses.
EventBatchRules
Auditable and reproducible
Every processing step can be evidenced functionally and technically – with rules, input parameters and state changes.
Audit trailHistory
Integration first
Loose coupling via events, stable APIs and clear versioning; adapters keep client-specific formats away from the core.
EventsAPI contractsVersioning
Processing engine
Step chains instead of ad-hoc logic, idempotency for robust retries, explicit exception and reprocessing paths.
Rule engine
Versioned rules with an approval process and rule context (validity, institution, product, time).
Event & data layer
Consistent, historised persistence for traceability, reproduction and long-term analysis.
Observability & audit
Throughput, latencies, error rates and a business process view for operations, reconciliation and internal audit.
Implementation patterns
Parallel operation, step-by-step migration along clear process boundaries, controlled cut-over with reconciliation.
Typical surrounding systems
Trading and orders, core banking and customer management, custodians, reporting, data & BI.
Operations
Horizontal scaling, resilience through decoupled components, multi-tenancy, least privilege and segmentation.
Environments
Separate accounts for DEV, UAT and PROD; promoted builds instead of manual intervention, reproducible deployments.
Technology stack
Proven technologies
Questions & answers
All questions about the platform
Structure & data
How is the system structured?
The platform is organised in layers: front ends (channels), edge and API (access and routing), platform core (domain logic), data storage (transactions and documents) and integrations (adapters to surrounding systems).
- Channels
- Mobile app, web app, back office web app
- Edge
- CDN, load balancer, API gateway, OIDC IAM
- Core
- Framework Angela (domain modules)
- Data
- PostgreSQL (RDS) and object storage (S3)
- Surrounding systems
- Partner bank, central securities depository (e.g. Clearstream), integration hub, finance/accounting, reporting/BI
Which business modules does the platform core cover?
The platform core covers the key domains of securities and account processes: account management, securities account management, order management, payment processing, securities processing, tax and regulatory, reporting, back office operations. Publicly we show the capability view; the internal service breakdown is part of the technical documentation.
What is the Framework Angela?
The Framework Angela is a proprietary development of DISACON AG and the technical foundation of our securities core banking platform. It provides the central process logic, integration patterns and core components to map securities account and securities processes in a modular, scalable and audit-proof way.
Which data is held where?
Transactional states are stored relationally, documents and artefacts in object storage.
- Relational DB
- PostgreSQL (Amazon RDS) for business states, history and consistency
- Object storage
- Amazon S3 for documents, exports, workdir artefacts and log archives
- Logging
- ALB logs in S3; additional log archive (S3 Archive)
How are external systems connected?
Connections run via an integration layer that decouples surrounding systems from the core.
- Inputs
- REST API, file transfer (SFTP; CSV/PDF), financial formats (SWIFT MT/MX)
- Function
- Mapping and validation, adapter per partner, idempotency, reprocessing
- Target systems
- Partner bank, Clearstream, X-Hub, ABACUS, Reporting Manager, financial accounting
Which user groups and clients are there?
The platform is used via different clients; in addition there is partner and operations access.
- Internal users
- Back office (web app) and operational tools
- Customers
- Web app and mobile app (e.g. berna web app and berna mobile app)
- Internal web app
- camilla web app (for internal users)
- Partners
- Partner data centre (connected to the API gateway)
- Developers
- GitHub as source control for build and deployment
Cloud, security & operations
What does the AWS cloud infrastructure look like?
The cloud infrastructure is divided into edge, workloads, data storage and operational functions.
- DNS and TLS
- Route 53 and AWS Certificate Manager (ACM)
- CDN
- CloudFront for web delivery (e.g. camilla and berna)
- Ingress
- API Gateway, public ALB, OIDC
- Workloads
- ECS/Fargate cluster (angela backend), Lambda (report, tbd)
- Data
- RDS, S3 buckets (web apps, certstore, workdir)
- Logging
- ALB logs to S3; log archive bucket
- Observability
- CloudWatch for monitoring and logging
- Config and secrets
- SSM Parameter Store
- Private access
- Private ALB and bastion for administrative paths
How do CI/CD and deployment work (multiple AWS accounts)?
CI/CD is implemented as a pipeline and can be run across separate accounts (e.g. build account and deploy account).
- Source control
- GitHub
- Build
- CodeBuild
- Registry
- ECR
- Deployment
- CodePipeline, CloudFormation
- Targets
- ECS/Fargate (containers) and Lambda (batch/reporting)
How are security and traceability addressed?
- Ingress via defined gateways (CDN, API Gateway, load balancer)
- Authentication/authorisation via OIDC/IAM
- History and correlation of processing steps for auditability
- Monitoring/logging and archiving (CloudWatch, S3 log archive)
How does DISACON separate tenants?
DISACON separates tenants at infrastructure level. Each tenant receives a fully separate operating environment with clear technical isolation. Thanks to cloud operation, this separation is particularly efficient and cost-effective. Provisioning is fully automated via infrastructure as code, so new tenant environments can be delivered and operated quickly, securely and in a standardised way.
Is the platform tied to a particular cloud provider?
The platform runs in the cloud on hyperscaler infrastructure. It is designed so that, going forward, it can also be operated in multi-cloud or data centre environments without replacing the core of the solution.
Has the system been audited?
Yes. The Framework ANGELA, the technical and functional basis of our securities core banking platform, has been audited by Deloitte under IDW PS 860 in conjunction with IDW PH 9.860.4 with regard to the GoBD requirements (German principles for the proper keeping of books and records). The audit confirms that the framework has a consistent and robust control framework throughout for meeting the GoBD requirements. All key functions – in particular booking logic, audit trail, data processing and retention – rely on this central control and processing framework.
Technology & performance
Why Erlang?
Erlang was built specifically for highly available, fault-tolerant and scalable systems – originally in telecommunications, where billions of messages are processed in real time. These properties are essential for maximum reliability.
Why business logic directly in the database?
By placing the central logic directly in the database, we avoid complex middleware, reduce sources of error and speed up processing considerably. The result: traceable processes and maximum performance without unnecessary intermediate layers.
Are these proven technologies?
We rely on a proven architecture with modern technology stacks that have already proven themselves in highly sensitive applications such as WhatsApp or Klarna.
How does performance hold up as volumes grow?
In our load analysis, processing time is around 10 milliseconds per trade – even in the scenario with 220 million trades per year.
Can the solution be scaled efficiently?
The architecture scales in stages: computing capacity can be added without base costs rising to the same extent.
Business questions
Is tax calculation integrated into the platform?
Yes. The platform covers the tax processing of investment income for the German market in an integrated way. The tax logic is part of the process chain and can therefore be built directly into end-to-end processing.
Can an external tax engine be connected (e.g. SECTRAS)?
Yes, in principle. The platform can be integrated so that external tax logic – for example SECTRAS from cpb – is used as part of the end-to-end process chain. In-depth functional and technical discussions have already been held on how an external tax engine can be cleanly integrated into the existing process logic. A production connection is typically a separate integration project.
Can the platform be operated as a custodian bank?
Yes. The platform can also be used in a custodian bank environment. It supports the processes and integrations required to meet custodian-specific requirements and to operate within the corresponding allocation of roles.
Is white-label operation possible?
White label is on DISACON's roadmap and enables several tenants to be operated, each under their own liability umbrella. Customers are run in separate environments with their own data storage, ensuring complete data isolation, high performance and audit-proof processes. White-label operation for tenants without their own liability umbrella is possible in principle and can be implemented as an individual project, but is not currently planned as standard.