Skip to main content

Document Management

Document management​

1. DEUSS Core – Central Marketing Repository (for All Broker Platform Applications)​

What Belongs in DEUSS Core (Marketing / Public Content)​

  • Issuance materials: term sheet, pitch deck, factsheet, investor presentation
  • Marketing images/icons/logos, banners
  • Public bond-related documents (provided they are not legally or AML-sensitive)
  • Versioned documents for a specific bond / issuer / campaign
  • Multi-language document variants

What Does NOT Belong in DEUSS Core (to Be Managed by the Distributor)​

  • Contracts and signed agreements
  • KYC/AML attachments
  • Personal data
  • Audit trail evidence
  • Transaction confirmations and statements
  • Internal regulatory reporting
  • Any content subject to “right to be forgotten”, retention requirements, legal hold, or regulatory preservation obligations

Documentation Rule DEUSS Core stores public/marketing content, while the Distributor stores regulated/legal/transactional evidence.

2. Implementation of DEUSS Core Document Storage​

Storage Pattern​

DEUSS Core document storage uses S3-compatible object storage (see Object Storage for infrastructure details). Metadata is stored in a relational database alongside the binary objects.

Example object key structure for marketing content:

marketing/{issuerId}/{bondId}/{locale}/{docType}/{version}/{filename}

API (minimal set)​

  • POST /documents – Upload file + metadata
  • GET /documents/{id} – Download or generate pre-signed URL
  • GET /documents?bondId=&locale=&type= – Listing endpoint for frontend
  • PUT /documents/{id}/metadata – Update tags, locale, visibility
  • POST /documents/{id}/publish – Workflow transition (draft → published → archived)

Cache & CDN​

Since marketing content (including icons, thumbnails, and listing visuals) will generate high traffic from marketplace applications, it is recommended to use a CDN (e.g., Cloudflare).

  • Public documents may be served as static content via CDN
  • Non-public documents should only be accessible via authorized API calls

Security & Access Control (Will Be Required?)​

At minimum, document visibility levels should distinguish between:

  • Public
  • Partner-only
  • Internal Access from Broker Platform frontend applications should be performed via OAuth2 token-based authentication, optionally combined with short-lived signed URLs. Audit logging should focus on administrative actions (upload, publish, delete), rather than logging every individual download (unless regulatory requirements demand it).

3. Broker Platform Application – Temporary Storage Only​

Draft Application Data​

Draft application data should:

  • Be stored as draft state in the database
  • Store binary files preferably in S3-compatible storage Implementation recommendations:
  • Use a temporary bucket (or namespace) with TTL lifecycle policy (e.g., 72 hours)
  • Mark files with attributes such as draft=true and expiresAt
  • Implement automatic cleanup After completion of the application process:
  • The draft is either transferred to the Distributor repository (where it becomes a regulated/legal document),
  • Or it is discarded. Since this storage is strictly temporary, TTL enforcement and automated cleanup should be implemented to prevent unintended long-term persistence.

4. Distributor Application – Legal / Transactional Documents​

Purpose​

The Distributor Application is responsible for storing legally binding, regulatory, AML, and transaction-related documents. This repository represents the legally relevant system of record for documentation associated with:

  • Issuer onboarding
  • Investor onboarding
  • Transaction execution
  • Regulatory compliance
  • Audit evidence Distributor bears responsibility for retention, compliance, and evidentiary integrity of stored documents.

Scope of Stored Documents​

Distributor stores:

  • Signed contracts (issuer agreements, investor agreements)
  • KYC/KYB documentation
  • AML reports and risk assessments
  • Subscription agreements Optionally:
  • Transaction confirmations
  • Payment confirmations
  • Regulatory reporting artifacts
  • Audit trail exports
  • Any document requiring retention under financial regulation These documents may contain personal data and regulated information.

Architecture​

Storage Model​

Distributor document storage uses S3-compatible object storage (see Object Storage). Metadata is stored in a relational database alongside binary objects.

  • Document hash (SHA-256) stored for integrity verification
  • Immutable audit log for:
    • Upload
    • Download
    • Modification
    • Access attempts Optional:
  • Legal hold mechanism
  • Retention period enforcement per jurisdiction

Security Requirements​

Legal document storage must support:

  • Encryption in transit (TLS)
  • Encryption at rest (KMS or Vault-managed keys)
  • Strict RBAC access control
  • Segregation by jurisdiction (if required)
  • Full audit logging
  • Tamper-evident storage
  • Backup & disaster recovery Access is never public. Downloads must be authenticated and authorized. Deletion must be auditable.

Integration: Responsibilities and Data Flow​

DEUSS Core → Broker Platform Frontend​

  • CORE provides marketing content (document listing and download), CDN on Cloudflare should be enabled for that content.
  • The Broker Platform application does not handle retention policies, legal hold, or AML-related document management.

Broker Platform → Distributor​

  • Submission of applications along with legal and transactional documents.
  • Files should be uploaded directly to the Distributor’s storage (via pre-signed upload URLs).
  • The Broker Platform application acts solely as an orchestration layer and does not persist regulated documents.

Document Governance & Classification “licence-ready” Model​

To ensure regulatory clarity and operational separation of responsibilities, the DEUSS platform applies a formal document classification and governance framework.

  • Retention Policy:
    • DEUSS Core: marketing data - no retention obligation
    • Broker Platform: Short-term retention only, documents stored solely during onboarding or bond creation processes.
    • Distributor: Retention enforced according to applicable jurisdiction and regulatory framework.
  • Versioning:
    • Formal document versioning (DMS-style version control) is not initially implemented due to implementation complexity
  • Access model:
    • Access control is implemented according to document classification:
    • DEUSS Core
      • Public access for marketing content.
      • Optionally served via CDN.
      • Administrative actions (upload, publish, delete) are logged.
    • Distributor
      • Partner-only access.
      • Strict authentication and authorization required.
      • Administrative actions are audit-logged.
      • Access to regulated documents is restricted to authorized roles only.

Business licence-ready Classification of Document model

AreaDEUSS CoreDistributor
Marketing content✔—
Legal contracts—✔
AML documents—✔
Investor agreements—✔
Temporary draft uploads—(via Whitelabel → Distributor)
Retention enforcement—✔
Public document distribution✔—