Overview

1. Off-chain Solution Architecture

1.1 Overview of Service Architecture

The DEUSS platform operates as a hybrid off-chain / on-chain ecosystem connecting business applications, external service providers, and the EBSI blockchain layer. The off-chain architecture is operationally split into two major domains:

• DEUSS Core – technical platform and shared core domain operated as the exchange-side backend foundation
• Broker Platform / Distributor App – broker-facing domain containing the Broker Platform and the validator application

From an infrastructure perspective, both domains may initially run within a single Kubernetes cluster, but they are always deployed into separate namespaces and do not share relational or document data sources. Communication between these domains is based on secured REST API calls in a B2B service-to-service model. The architecture therefore combines:

• synchronous service integration for inter-domain communication
• isolated domain data ownership
• independent lifecycle and scaling per domain area This operating model enables phased delivery while preserving future readiness for full physical separation into dedicated clusters if required by scale, security, tenancy, or regulatory constraints.

Internal application structure follows a containerised micro services architecture orchestrated by Kubernetes and managed through Rancher, ensuring consistency, scalability, and isolation across development, test, and production environments. All components are deployed via Helm charts under a GitOps CI/CD pipeline (GitLab CI and Argo CD).

1.1.1 Production-ready Operational Model

The production operating model is based on a cloud-native Kubernetes platform with strong focus on operational resilience, security, automation, and observability. The platform operates using separated DEV, TEST/UAT, PROD, and DR environments with isolated namespaces, identities, secrets, and access permissions. Shared infrastructure services such as Istio, Kafka, monitoring, and identity management are centrally managed within the Kubernetes platform. Operational principles include:

• GitOps deployment model using ArgoCD and Helm
• Infrastructure as Code (IaC) and automated provisioning
• centralized observability (monitoring, logging, tracing, audit logging)
• event-driven communication using Kafka
• centralized IAM using Keycloak (OIDC/OAuth2, RBAC, Passkeys/MFA)
• zero-trust communication using mTLS and backend-enforced authorization
• Disaster Recovery and operational resilience mechanisms including backup, replication, and failover procedures (described in this document) Detailed implementation and security aspects are described in dedicated sections covering Security & Compliance, IDM, Traffic Management, and Access Control & Resource Authorization. Application Operation & Jurisdiction The final operational model and jurisdiction of the administrative application will depend on the target country and operating entity selected for the specific deployment. The platform is designed with the assumption that:
• operation and hosting will remain within the European Union (EU)
• data processing and operational governance will comply with applicable EU and local regulatory requirements
• the deployment model can be adapted to country-specific legal, operational, and regulatory constraints The architecture supports flexible deployment models including:
• private cloud
• national cloud
• on-premise deployment within the EU This approach allows the final operator to align the solution with GDPR, financial regulations, and local supervisory requirements. Cross-country Operational Governance The platform supports a federated operational model with local operational entities and centralized DEUSS coordination. Detailed roles, governance responsibilities, and cross-country data exchange principles are described in the dedicated Operational Governance section.

1.1.2 Blockchain Governance & Multi-Tenant Operating Model

The blockchain architecture is designed to support multi-tenancy, decentralized governance, and integration with multiple administrative applications. This is achieved through a template-driven deployment model leveraging the European Blockchain Services Infrastructure (EBSI) and standardized identity and access management. The integration and administrative framework is structured as follows: 1. Template-Driven Smart Contract Deployment The core business logic developed for the DEUSS platform is uploaded to the EBSI blockchain as reusable Smart Contract templates. Rather than being hardcoded to a single administrative application, these templates are instantiated dynamically. Access to deploy and interact with these templates is governed by standard EBSI access management protocols utilizing Verifiable Credentials (VCs). 2. Governance and Credential Management The initial DEUSS deployment is operated under a centralized governance model where the primary DEUSS operator manages administrative functions and platform governance. To manage or deploy an instance of the platform, an operator must possess the appropriate Verifiable Credentials.

• Initial State: The primary DEUSS operator will hold these credentials, granted via a formal agreement/contract with the EBSI operator (Europeum). At the initial rollout, all administrative actions and governance policies will be centrally managed by this primary DEUSS platform operator.
• Multi-Operator Expansion: The architecture inherently supports scaling to multiple administrative entities. If another operator establishes a contract with Europeum, they can be issued the required Verifiable Credentials to access the same EBSI smart contract templates. This allows them to deploy a completely independent instance of the marketplace. 3. Flexible Marketplace Administration & Delegation Each deployed instance of the DEUSS marketplace operates under its own distinct governance boundary. The company or entity deploying a specific instance has full autonomy over its operational model. While administration may initially be centralized under a single operator, the architecture natively supports the delegation of specific administrative functions to trusted third parties, allowing for flexible integration with various external administrative applications and management tools as the ecosystem matures.

1.1.3 Application layers

Layer	Primary Components	Core Functions
Front-End Layer components	DEUSS Web Portal (React), Investor Dashboard, Issuer Console, Administrative Interface	User interaction, onboarding, transaction initiation, and reporting.
Application (Back-End) Layer components	Microservices: User, Bond, Payment, AML/KYT, Compliance, Notification	Execution of business logic, workflow orchestration, and event publication.
Integration & Messaging Layer components	Apache Kafka, Istio Service Mesh, REST APIs for external interfaces	Event-driven integration, synchronous calls under mTLS, connectivity with external parties.
DLT Layer components	Smart Contracts, RPC Gateway, Web3Signer + Vault/HSM, Indexer (Subsquid)	On-chain transaction execution, state synchronization, and proof of settlement.
Infrastructure & Observability Layer	Kubernetes clusters (via Rancher), PostgreSQL HA (CloudNativePG), Vault, Grafana/Prometheus/Loki stack	Hosting, scaling, secret management, system monitoring, and logging.
External configurable components	Keycloak IDP, Licensed Payment Service Providers (PSPs), Indexer (Subsquid)	Ready to use components with DEUSS specific configuration.
Document storage components	S3 storage (Ceph)	Stores bond documents, issuer documentation, KYC materials, and other unstructured or binary data.
Data and metadata storage components	PostgreSQL relational database	Stores structured business objects—users, bonds, companies, transactions. Each service uses its own schema.

This modular setup provides operational resilience, transparency, and auditability, while the Applicant retains full control over regulated infrastructure functions such as order management, recordkeeping, and settlement.

1.1.4 Scalability Strategy

The DEUSS platform supports both horizontal and vertical scalability using Kubernetes-native mechanisms. The primary scalability mechanisms include: Horizontal Pod Autoscaling (HPA)

• Automatic scaling of application pod replicas based on runtime metrics such as CPU and memory utilization. Vertical Pod Autoscaling (VPA)
• Dynamic optimization of CPU and memory requests/limits for workloads based on observed resource consumption. Cluster Autoscaling
• Optionally, automatic scaling of Kubernetes worker nodes can be enabled when application workloads exceed currently available cluster capacity. In addition to Kubernetes-native scaling capabilities, the platform architecture supports:
• asynchronous processing using Kafka
• caching and optimized backend processing
• independent scaling of microservices
• isolated scaling of DEUSS Core and Broker Platform app domains This approach enables the platform to efficiently handle increasing workloads, fluctuating traffic, and future growth in the number of Issuers, Investors, and integrated partner systems.

---

1.2 Architectural Connectivity and Data Flow

Each user action on the front end triggers a secure call to backend microservices via an Ingress Gateway (Istio ingress fronted by Cloudflare WAF with Cloudflare tunnel).

1.2.1 Communication patterns within the off-chain system

• Cross-domain communication between DEUSS Core and Broker Platform is implemented via secured REST APIs.
• Internal service-to-service communication is controlled through the Kubernetes networking model and Istio policies.
• Blockchain-originated events are consumed by the indexing layer and propagated into off-chain backend processing flows.

1.2.2 Used technology stack

• Kafka handles asynchronous event publication and consumption between microservices.
• Istio provides secure synchronous communication with mutual TLS (mTLS) and routing control.
• Vault supplies temporary credentials and encryption keys at runtime.
• PostgreSQL stores off-chain data with high availability managed by the CloudNativePG operator.
• Web3Signer interacts with Vault/HSM to securely sign blockchain transactions.
• The Indexer (Subsquid-based) monitors blockchain events and relays them to Kafka topics for off-chain synchronization. For details on ingress, API gateway responsibilities, and service-to-service traffic control, see the dedicated article on Communication and Traffic Control with Istio. For more details on traffic management and data flow scenarios, see Traffic Management - External API Gateway, Blockchain Gateway, Ingress, Service mesh.

1.2.3 Communication patterns within the off-chain and blockchain

The solution is designed to support integration with the EBSI ecosystem and allows multiple independent Broker instances to connect to the blockchain network. Access to blockchain-related operations is not exposed directly to external systems. All integrated Broker instances are controlled through the DEUSS Core layer, where authorization, RBAC, tenant isolation (partner_id) and security policies are centrally enforced. The DEUSS Core instance operates with its own dedicated administration and governance boundary; only one administration domain is supported per deployed solution instance.

---

1.3 Cloud Infrastructure Provider

The Cloud Infrastructure Provider hosts DEUSS off-chain systems in a GDPR-compliant EU data center, certified under ISO 27001. Its responsibilities include:

• Secure compute, storage, and network resources;
• Load balancing, DDoS protection, and TLS termination;
• Backup and recovery storage;
• Monitoring and uptime guarantees under SLA (≥99.9% availability).

The provider has no access to blockchain nodes, private keys, or customer data.
DEUSS Kubernetes clusters are fully managed under DEUSS control through Rancher, ensuring all operational authority remains with the Applicant.

---

1.4 Platform Maintenance, Codebase Management, and Governance

Platform operation follows DevSecOps and change-management principles:

• Continuous Integration / Continuous Deployment is implemented using GitLab CI and Argo CD;
• CI pipelines in GitLab ensure build, automated testing, static code analysis (SonarQube), and vulnerability scanning before deployment;
• CD is managed via Argo CD (GitOps approach) with version-controlled deployment definitions;
• Deployment packaging is standardised using a single parametrized Helm chart, allowing selective deployment of platform components based on configuration;
• The platform is currently deployed into a single Kubernetes cluster supporting multiple environments:
  • Dynamic environment for the master branch
    • automatically redeployed on each merge to master
    • represents the latest integrated state of the platform
  • Dynamic environments for merge requests
    • created on demand per feature branch
    • deployment is triggered by adding a specific label (e.g., deploy) to the merge request
    • used for validation, testing, and stakeholder review
• Version-controlled Helm templates ensure reproducible and consistent releases across all environments;
• Dual approval is required for production releases (DevOps + Compliance Officer);
• All code and configuration changes are traceable and logged for audit purposes; Routine infrastructure maintenance may be supported by a designated DevOps partner, but deployment control and approvals remain solely with DEUSS. This ensures compliance with outsourcing control and four-eyes governance principles.

The off-chain part of the solution is intended to be open source. The source code will be publicly available; however, the project will follow a controlled contribution model:

• the main repositories remain protected
• direct modifications are not allowed
• changes are introduced through controlled forks and review/approval processes Security-sensitive operational configuration, secrets, deployment credentials, and runtime infrastructure settings are not intended to be publicly exposed. This approach provides transparency and auditability while maintaining operational and security control over production environments.

---

1.5 External Functional Service Providers

Third-party integrations provide specialized services beyond the Applicant’s regulatory perimeter. All external APIs are secured through TLS 1.3, JWT-based authentication, and Vault-managed credentials, routed via the API Gateway.

Function	Description	Interface & Security
Identity Verification (KYC/KYB/AML)	External validator conducts AML and KYB screening; returns verified identity tokens for access control.	REST API + Webhook (mTLS + JWT)
Payment Service Provider	Licensed Payment Service Provider (PSP) executes off-chain fiat settlements; provides status updates to DEUSS.	REST API + Webhook (TLS + HMAC)
ISIN / Reference Data Provider	Generates official ISIN codes and validates issuer reference data.	REST API (Vault-secured credentials)
Analytics / Scoring Service	Supplies risk and ESG ratings for SME issuers.	REST API (OAuth2 tokens)
Notification Gateway	Handles transactional communications to investors and issuers.	SMTP / Webhook (JWT authentication)

All partner connections are logged immutably, rate-limited, and monitored through Grafana for performance and SLA compliance.

---

1.6 Security, Compliance, and Data Protection

The platform applies a zero-trust security model integrating the following controls:

• mTLS for all internal communications (Istio Service Mesh);
• SPIFFE/SPIRE identities for workload authentication;
• Keycloak SSO for centralized access control, MFA enforcement, and short-lived OIDC tokens;
• Vault/HSM for key management and secret retrieval;
• Immutable audit logging via Loki and WORM object storage;
• Cloudflare WAF for perimeter protection;
• Row-Level Security (RLS) and Kafka partitioning by jurisdiction to enforce data segregation;
• GDPR compliance through pseudonymisation and data minimisation;
• DORA alignment via defined RTO/RPO targets and regular resilience testing. Regular independent audits confirm provider compliance with ESMA cloud outsourcing guidelines and the DLT Pilot Regulation.

1.6.1 Data Retention Policy

The DEUSS platform defines data retention policies based on data classification, legal obligations, security requirements, and operational needs, in alignment with GDPR principles and applicable financial regulations. The following retention categories are applied: Regulatory & Compliance Data (KYC/AML records, investor identification, transaction records, audit trails)

• retained for 5–10 years after the end of the business relationship. Business & Contractual Data (investor portfolios, offers, agreements, onboarding/case data)
• retained for the duration of the relationship and applicable legal retention period. Security & Audit Logs (user actions, access logs, audit events)
• retained for 1–5 years, with compliance-critical audit records retained longer where required. Technical & Operational Data (application logs, monitoring, telemetry)
• retained for 30–180 days unless required for security investigations or incident analysis. Key retention principles:
• data is classified by category and assigned a defined retention period
• retention must be justified by legal, regulatory, security, or operational requirements
• sensitive and compliance-critical records are protected using secure and immutable (WORM) storage where required
• expired data is automatically deleted or anonymized unless legal or regulatory obligations require extended retention This approach ensures compliance with GDPR, financial regulations, auditability requirements, and secure handling of sensitive platform data.

1.6.2 Privileged Access and System-wide Roles

The DEUSS platform applies strict Role-Based Access Control (RBAC) and least-privilege principles. System-wide access is limited to a minimal set of privileged operational and compliance roles. The following privileged roles may access selected cross-system information:

• System Administrator — operational configuration, infrastructure, user and platform management
• Compliance / Audit Role — read-only access to audit logs, transactions, and regulatory records
• Support / Operations Roles (L1/L2) — limited and controlled troubleshooting access for operational support activities Access to sensitive data (e.g. KYC, financial or compliance-related data) is:
• strictly role-restricted
• logged and auditable
• granted only on a need-to-know basis Partner (tenant/originator) data remains logically isolated and mutual visibility between partners is prohibited by default. All privileged access is protected using strong authentication (Passkeys/MFA), fully audited, and subject to periodic review. Additional controls such as approval workflows or just-in-time (JIT) access may be applied for elevated operations.

1.6.3 Partner Data Isolation and Tenant Access Control

The DEUSS platform enforces strict tenant isolation between partners (originators) to prevent unauthorized visibility of cases, financing offers, and related business data. All business data is associated with a specific partner_id, which serves as the primary tenant isolation boundary across the platform. Key protection mechanisms include:

• backend-enforced authorization
• strict RBAC enforcement
• backend-enforced authorization checks
• tenant-based filtering in all queries and APIs
• secure propagation of partner context (partner_id, partner_role) via OIDC/JWT tokens
• logical data segregation between partners
• separation of Partner APIs and Admin APIs
• centralized identity management via Keycloak
• encryption in transit and at rest Cross-partner access is denied by default and cannot be bypassed at the frontend level. All APIs validate ownership and partner context before granting access to requested resources. Partner status and lifecycle are centrally governed by the Partner Service. Suspended partners are immediately isolated across the platform by revoking API access and preventing continuation of active workflows. Additional safeguards include:
• immutable audit logging of access attempts & audit logging and monitoring of all privileged operations
• security and penetration testing focused on tenant isolation
• optional logical or physical data partitioning for sensitive datasets
• rate limiting and abuse protection This approach ensures confidentiality of partner data and prevents unauthorized visibility across tenant boundaries. This approach ensures that:
• partners operate in fully isolated data domains
• cross-partner visibility is technically prevented
• privileged administrative access remains controlled and auditable
• security and compliance requirements are consistently enforced across the platform.

---

1.7 Division of Responsibilities

Domain	Responsibility	Performing Entity
DLT Operations	Smart contract execution and transaction validation on EBSI	EBSI Node Operators
Platform Software	Development, integration, and maintenance of DEUSS systems	Applicant (DEUSS Operator)
Infrastructure Hosting	Cloud hosting and network availability under DEUSS control via Rancher	Cloud Infrastructure Provider (contracted)
Identity Verification	KYC/KYB and AML screening	Distributor - Independent Validator Provider/Service
Payment Settlement	Off-chain fiat settlement	Licensed Payment Service Provider (PSP)
Reference Data	ISIN assignment and validation	Authorized ISIN Provider
Regulatory Reporting	Logging, data retention, supervisory API access	Applicant (DEUSS Operator)

All service providers operate under contractual terms defining:

• Data protection obligations,
• Incident notification requirements,
• Termination and audit rights,
• consistent with Article 7(4) of the DLT Pilot Regulation and DORA.

1.8 Operational Resilience and Disaster Recovery

DEUSS maintains active-passive disaster recovery clusters in separate EU regions. Replication includes PostgreSQL (via Patroni), Kafka (via MirrorMaker), and MinIO object storage. Recovery objectives:

• RTO ≤ 2 hours, RPO ≤ 15 minutes for critical components. Quarterly DR tests validate recovery procedures. Infrastructure-as-code repositories and container images are mirrored to ensure continuity even under total primary site loss. Production Deployment and Scalability Expectations The DEUSS platform is designed for production deployment in a High Availability (HA) configuration from the initial launch. Application services are deployed in Kubernetes using multiple pod replicas with load balancing at the Kubernetes service and ingress level. The target operational model also includes a functional and regularly tested Disaster Recovery (DR) setup to minimize the risk of prolonged outages and support operational resilience. The anticipated initial production scale includes:
• tens to hundreds of Issuers
• thousands of Investors The platform is designed as a scalable cloud-native solution, allowing Kubernetes workloads and infrastructure resources to be horizontally scaled based on real production load, monitoring metrics, and operational growth requirements.

1.9 Operational Governance & Cross-country Data Exchange Model

The DEUSS operating model supports cooperation between local operational entities and centralized DEUSS coordination across multiple jurisdictions, including CZ, GR, SK, etc.

Local Operational Teams

Local operational entities are responsible for:

• collection and validation of local operational data
• compliance with national regulatory requirements
• communication with DEUSS and local operational support

DEUSS Central Platform

DEUSS acts as the central integration and coordination platform responsible for:

• data harmonization and interoperability
• centralized data exchange and aggregation
• operational monitoring and reporting
• coordination of shared platform services and governance processes

Central Governance

Central governance functions are responsible for:

• definition of global operational and compliance standards
• oversight of cross-country processes
• audit, reporting, and supervisory coordination

Data Exchange Principles

The platform supports secure cross-country data exchange using:

• secured APIs and encrypted communication channels
• standardized data formats (JSON, XML, CSV)
• periodic and event-driven data exchange mechanisms Supported exchange frequencies include:
• daily operational reporting
• weekly compliance and performance reporting
• monthly governance reporting
• ad-hoc incident and operational notifications This operating model enables standardized governance and interoperability across jurisdictions while preserving local operational and regulatory responsibilities.

---

2 Application components

2.1 Operating model split

The DEUSS operating model is based on three logical layers:

• DEUSS Core – single centralized Exchange platform.
• Broker Platform (and future implementations) – multiple independent broker-facing platforms.
• EBSI – common decentralized blockchain infrastructure.

2.1.1 DEUSS Core Exchange

The DEUSS Core Exchange represents the central exchange platform and the shared backend foundation of the DEUSS ecosystem. It provides common business capabilities, governance, blockchain integration, payment orchestration, registry management, workflow execution, and reporting services shared by all connected broker platforms. The DEUSS Core is designed as a single logical platform instance connected to the European Blockchain Services Infrastructure (EBSI). It acts as the central authority responsible for maintaining the shared marketplace state, executing blockchain operations, coordinating integrations with external service providers, and enforcing governance and security policies. Rather than exposing blockchain complexity directly to broker applications, the Core encapsulates blockchain interactions, partner governance, and operational workflows behind well-defined service APIs and event-driven integration patterns. This allows broker platforms to focus on business functionality while relying on the Core for shared infrastructure services. Main responsibilities:

• blockchain-facing backend integration
• registry-related logic
• partner integration logic
• payment integration orchestration
• canonical event ingestion and processing
• document and metadata handling for the DEUSS Core domain

2.1.2 DEUSS Core Exchange Application components

Governance Backoffice

Administrative frontend used by DEUSS operators for governance, partner administration, monitoring, manual interventions, and operational management.

---

Partner Service

Manages partner lifecycle, technical users, partner authorization, approval workflows, and governance. Provides centralized partner context and authorization for external platform integrations. For more details, see Partner Service.

---

Business Registry Service

Maintains core business entities including issuers, investors, companies, wallets, and marketplace master data. Exposes secured APIs for partner and administrative operations.

---

Core Payment Service

Central payment orchestration service integrating external Payment Service Providers (PSP). Coordinates payment initiation, status tracking, and settlement workflows.

---

Blockchain Indexer

Consumes blockchain data and events, synchronizes on-chain state with off-chain services, and publishes blockchain events for downstream processing.

---

Eventer

On-chain event handling (Kafka), enrichment, and propagation.
Executes asynchronous workflow orchestration, manages chain operation lifecycle, background processing, retries, reconciliation, and manual intervention workflows.

---

Analytics & Reporting

Provides reporting, analytics, operational dashboards, and event-driven reporting based on blockchain and operational data.

---

Debezium

Publishes database change events (CDC) into Kafka for reporting, synchronization, and downstream integrations.

2.1.3 Broker Platform

The Broker Platform represents the broker-facing business domain used by issuers, investors, and broker operators. It provides business applications for onboarding, company management, bond issuance, investment operations, notifications, and user identity management while consuming the shared services exposed by the DEUSS Core. The current implementation (Broker Platform) serves as the reference implementation for broker integrations. It demonstrates the recommended architecture, service decomposition, identity model, and integration patterns for broker applications. The platform is intentionally designed to support multiple independent broker implementations operating in parallel. Future broker platforms may be developed either by DEUSS partners or third parties while following the same integration contracts with the DEUSS Core. Each broker deployment remains operationally independent and may be hosted on-premise or in a preferred cloud environment, while sharing the common exchange infrastructure provided by the DEUSS Core and the EBSI blockchain.

The DEUSS platform follows a layered operating model separating the centralized exchange platform from independently operated broker platforms while leveraging a common blockchain infrastructure. This operating model is designed around:

• operational separation
• business ownership separation
• namespace isolation
• standardized API-based integration
• independent scalability
• future infrastructure separation if required Initially, the DEUSS Core and the reference Broker Platform are deployed within the same Kubernetes cluster, each running in a dedicated namespace to provide logical isolation, independent deployment, and operational scalability. If required by regulatory, operational, or scalability needs, both domains may later be deployed into separate Kubernetes clusters or infrastructure environments.

Benefits

• logical isolation of business domains
• independent deployment and scaling
• controlled resource allocation
• clear ownership boundaries
• future cluster-level separation

Operational Responsibilities

The DEUSS platform operator is responsible for the shared technical platform, including:

• Kubernetes cluster operations
• infrastructure management
• namespace governance
• security policies
• monitoring and observability
• CI/CD and GitOps deployment
• disaster recovery
• operational resilience
• technical support for regulatory compliance

This architecture enables ecosystem growth by allowing multiple broker platforms to coexist while maintaining a single trusted exchange backend and a common blockchain infrastructure. Broker platforms are designed as scalable stateless Kubernetes applications supporting:

• horizontal scaling
• multi-data-center deployment
• traffic distribution and load balancing Each deployment may be operated independently by its owner either:
• on-premise
• or within a preferred cloud environment.

2.1.4 Broker Platform Application components

Broker Platform Frontend

User-facing portal for issuers and investors supporting onboarding, portfolio management, bond subscription, and marketplace operations.

Payment Service

Broker-side payment initiation and payment status presentation integrated with the DEUSS Core Payment service.

Company Service

Manages company lifecycle, issuer information, and company-related business operations.

Bond Issuance Service

Manages bond lifecycle, issuance workflows, publication, and investment operations.

User Profile Service

Stores application-specific user profile data extending the identity information maintained in Keycloak.

Keycloak

Central Identity Provider implementing OIDC/OAuth2 authentication, Passkeys, RBAC, and token issuance.

Blockchain Indexer

Builds broker-specific blockchain read models and synchronizes on-chain information required by business services.

Eventer

Processes asynchronous business events and local workflow execution within the broker platform.

Notification Service

Sends end-user notifications including onboarding updates, bond lifecycle events, and operational messages.

2.1.5 Validator Platform

The validator application is a separate operational part of Broker / Distributor application focused on validation, compliance-supporting workflows, and validator-side backoffice operations.

Main responsibilities:

• backoffice-facing validation workflows
• KYC / AML related operational support
• controlled handling of sensitive validation artifacts
• validator-side administration and review

Data ownership:

• the validator application owns its own relational schema
• the validator application owns its own S3-compatible document storage
• sensitive validator data remains isolated from the Broker Platform except through explicit service interfaces

Validator Service

The service acts as the backend component of the Validator Application, which is used by compliance and validation operators through a dedicated Backoffice UI.
Responsible for executing validation workflows related to issuer, investor, and transaction compliance within the platform. It supports operational validation processes such as KYC/AML checks, document verification, regulatory eligibility checks, and manual validation decisions performed by authorized operators.
Ensures that validation results are traceable, auditable, and linked to the corresponding business entities (issuer, investor, transaction, or document).

2.1.6 Domain Integration Model

DEUSS Core and Broker Platform are integrated, but not coupled through shared persistence.

Integration rules:

• all inter-domain communication is done via REST APIs
• communication is performed in a B2B service mesh style
• direct access from one domain to another domain’s database is not allowed
• direct unmanaged access from one domain to another domain’s S3 storage is not allowed
• each domain remains independently deployable and governable

This model ensures that the initial single-cluster deployment does not create unwanted data coupling and keeps future physical separation straightforward.

2.1.7 Indexing and Event Processing

Indexing and event processing are present in both main domains where needed, but with different responsibilities.

General principles:

• blockchain-originated events are first consumed by the indexing layer
• event processing is split between indexing responsibilities and backend business/event orchestration responsibilities
• Indexer is responsible for canonical event acquisition and technical transformation of on-chain signals
• Eventer is responsible for backend-side event handling, enrichment, and propagation into application workflows

The detailed event-processing sequence is described in the dedicated architecture article covering Indexer / Eventer integration and event flow design.

---

2.2 Frontend Components

2.2.1 DEUSS Frontend

Governance FE application

A secured administrative UI for management of technical users, service principals, and governance-related operational tasks. Management of originating entities, governance actions, and operational oversight.

2.2.2 Broker Frontends

Company Registration & Onboarding (React)

User-facing registration portal for corporate issuers. Supports identity verification, onboarding workflows, submission of company documents, and communication with Company Service through authenticated REST calls.

User Registration & Onboarding (React)

Frontend for investor onboarding, identity verification (KYC/AML), wallet creation, and regulatory checks. Communicates with Identity Provider and User/Wallet Service. Propagates trace context (OpenTelemetry) to backend.

Broker UI (React)

Investor-facing frontend providing browsing of bond offerings, bond details, termsheets, investor documentation, and subscription workflows. Reads indexed bond data through backend APIs and displays real-time settlement status.

Validator Backoffice FE

Validator-side operational frontend for validation and compliance workflows.

Marketplace & Trading (React)

Frontend for trading functionality performed under the DLT Pilot Regime. Supports displaying market data, placing orders, order book visualisation, and interacting with the trading backend. Integrates WebSocket feeds for near-real-time updates.

2.2.3 Infra Frontends

Monitoring App (Grafana)

Administrative UI for displaying system health dashboards, APM metrics, application logs, and performance indicators based on Prometheus and Loki data sources.

Reporting App (Airflow)

Pre-configured business reporting interface using dashboards connected to PostgreSQL and data warehouse queries (The Graph / subgraphs).

CI/CD Apps

ArgoCD, Nexus.

---

2.3 Storage Components

Document Storage – S3 (Ceph)

Stores bond documents, issuer documentation, KYC materials, and other unstructured or binary data. Accessed via pre-signed S3 URLs. Integrated with compliance and retention policies. Typical content includes:

• issuer documents
• onboarding and validation documents
• bond-related documentation
• sensitive compliance artifacts
• generated or imported platform documents Rules:
• document storage is logically separated per module/application area (DEUSS Core, Broker Platform) - each module will have own bucket.
• bucket design must reflect ownership and sensitivity boundaries
• Broker Platform Validator storage must support stricter segregation for sensitive validation materials
• applications access documents through controlled backend services and signed access patterns
• direct unmanaged cross-domain document access is not allowed

Relational Storage – PostgreSQL

Primary relational database for all off-chain services. Stores structured business objects—users, bonds, companies, transactions. Each service uses its own schema. PostgreSQL operator ensures HA and automatic failover. Architecture principles:

• each major domain area owns its own schema or database boundary, according to operational deployment design
• DEUSS Core Backoffice, DEUSS Core, Broker Platform, and Broker Platform Validator must be treated as separate persistence domains - each component must have own DB schema (or own DB instance).
• relational storage is used for structured business entities, operational metadata, workflow state, identities, and integration state
• direct cross-domain reads from another domain’s relational store are not allowed
• cross-domain data consumption must happen through published service APIs For PostgreSQL topology, HA, backup, and operational design, see the dedicated storage article.

Data Warehouse – The Graph

Data analytics layer using subgraphs. Stores indexed on-chain data optimised for reporting, analytics dashboards, and regulatory exports.

Indexing Layer – Subgraph / Subsquid

Provides structured, versioned, queryable datasets derived from blockchain events. Serves analytical and reporting backends.

Monitoring Storage (Prometheus, Loki, Grafana)

Time-series database (Prometheus) for metrics, log aggregation storage (Loki), and dashboards (Grafana). Provides APM, alerting, and audit trails.

---

2.4 Communication and Traffic Control with Istio

Istio is used as the primary control plane for secure east-west and ingress-related traffic management. At a high level, Istio supports:

• Ingress Gateway for platform entry traffic
• API Gateway style routing for controlled exposure of APIs
• service mesh policies for service-to-service communication
• traffic governance, routing, and security enforcement between workloads Design principles:
• external traffic enters through controlled ingress
• internal service calls are policy-driven
• cross-domain REST communication is secured and observable
• namespace boundaries are reinforced by traffic and authorization policies
• Detailed Istio topology, gateway placement, routing, and policy configuration are described in the dedicated article on Istio, API Gateway, Service Mesh, and Ingress Gateway.

2.4.1 External Integrations

The ecosystem integrates with:

• Payment Service Provider
• Validator/KYC providers
• Broker/Operator App
• EBSI Blockchain (Escrow, Identity Registry, Bond Registry)