Reporting Pipeline
This document outlines the technical architecture and data pipeline responsible for aggregating and generating data for regulatory reporting.
1. Architecture & Data Pipeline
Potential Deployment Schema:
Potential Data Flow:
outbox → Debezium → Kafka → Ingestor → Compliance DB
Source Services (Runtime Plane)
- Registry Service — Companies, users, bonds, LEIs, wallet addresses, AML state
- Core Payment Service — Marketplace payments, settlement, DVP orchestration
- Indexer — On-chain state (bonds, offers, deals, transfers, token ownership)
- Eventer — Business logic triggers from canonical Kafka event stream
- Partner Service — Broker registry, LEIs, country codes, permissions
- Blockchain Event Service — Raw chain event capture
Compliance Plane (Reporting Infrastructure)
- Kafka — Event streaming backbone (operational, Strimzi-managed)
- Outbox Pattern — Domain writes + outbox row in same transaction for at-least-once delivery
- Compliance Ingestor — Kafka consumer that UPSERTs into
compliance.*schema with idempotency tracking - Compliance Database — Relational schema covering: companies, bonds, market orders, trades, settlements, chain transactions, governance actions, snapshots, cases, and submissions
- Report Generators — Produce XML/ZIP artifacts per report type, record submission metadata
2. Data Availability Matrix
| Data Domain | Source Service | Status |
|---|---|---|
| Company identity (LEI, name, registration) | Registry Service | Available |
| User identity & wallet | Registry Service | Available |
| Bond metadata (ISIN, issuer, maturity, coupon) | Registry Service + Indexer | Available |
| Bond lifecycle events (publish, issue, suspend, redeem) | Indexer (BondHistory) | Available |
| Marketplace trades (price, quantity, timestamp) | Core Payment Service + Indexer | Available |
| OTC transfers | Indexer (TransferEvent) | Available |
| Order book (offers, deals, status changes) | Indexer (MarketOffer, MarketDeal) | Available |
| Token ownership & supply | Indexer (TokenOwner) | Available |
| Broker/Distributor data (country, LEI) | Partner Service | Available |
| CFI code, FISN | Registry Service | Available |
| Platform configuration (venue MIC, Deuss LEI) | Configuration file | Available |
| Auth context (non-repudiation) | Audit logging | Available |
3. Operator Implementation Scope
The following items are the technical responsibility of the operating entity to implement and manage:
- Report scheduling & orchestration — Deploy cron/scheduler for daily (FIRDS), per-event (transaction reports), monthly (DLT), and semi-annual reports
- Submission channel configuration — Establish connections to ARM (for transaction reporting to NCA), ESMA FIRDS portal, APA, CPT data feeds, FIU (e-STR)
- Jurisdiction configuration — Set venue MIC, entity LEI, country codes, and jurisdiction-specific routing rules
- Compliance staffing — STOR/STR case management requires trained compliance officers
- Backoffice operation — Manage report corrections (CANC + re-submit), monitor reporting status, handle regulator queries
- Retention & archival — Ensure minimum 5-year retention of all order records, trade reports, and compliance evidence
- Tax engine — Withholding tax calculation, investor tax statements, FATCA/CRS (if applicable) are separate from regulatory reporting and must be implemented per jurisdiction