A custom cloud document management system for a Big Four consultancy's investment-firm client

Cloud Document Management Systems for Investment Firms

Industry
Investment, Consulting, BFSI, Professional Services
Technologies
.NET, Java, Angular, TypeScript, Microsoft SQL Server, Azure, AWS, Terraform, Docker, Kubernetes

Summary

We build cloud document management systems for investment and professional services organizations, where documents are a system of record rather than a file share. Work of this kind covers the document and entity data model, security-trimmed search, entitlements and information barriers, retention and audit, ingestion and workflow orchestration, integration with surrounding systems, and migration from an incumbent platform with its metadata, versions and permissions intact.

The Challenge

Such a system holds subscription and redemption paperwork, fund formation documents, side letters, investment committee papers, due diligence packs, valuation reports, custodian statements, board minutes and correspondence. Each document is bound to entities that matter operationally: a fund, a vehicle, a mandate, a counterparty, a deal, a reporting period. The value comes from that binding, because retrieval is driven by relationships and metadata rather than folder position, and the same document frequently belongs to several contexts at once.

Access control is the defining constraint. Investment organizations need information barriers between deal teams, restriction lists that suppress even the existence of a document from certain users, and entitlements derived from fund and mandate relationships rather than assigned per folder. Retention schedules vary by document class and jurisdiction and must support both minimum retention and defensible disposal, with legal hold overriding scheduled deletion. The recurring failures follow from ignoring this early: treating search as a late feature rather than an indexing and security design decision, using folder hierarchies as the permission model so barriers cannot be proven, underestimating full-text extraction over large archives, and postponing retention rules until after go-live.

The Solution

Four separated concerns

  • Content storage holds immutable object versions in encrypted cloud object storage, addressed by content hash, with legal hold and write-once retention where records rules require it
  • A metadata service holds the typed document model, taxonomies, entity relationships and version lineage in a relational store
  • A search service provides full-text and faceted retrieval over extracted text, with optical character recognition for scanned material and language detection for multilingual estates
  • An orchestration layer runs ingestion, classification, review and approval workflows as asynchronous, resumable processes

Services are containerized and deployed through infrastructure as code so environments are reproducible, and ingestion is event-driven so a large upload burst queues rather than degrading interactive use.

Entitlements, retention and audit

Authorization is attribute-based and evaluated at query time, with the search index security-trimmed so restricted material never appears in results. Entitlements derive from fund and mandate relationships, and restriction lists are enforced at the index as well as at the object. Every read, export, permission change and deletion is recorded in a tamper-evident audit log, because supervisory review depends on showing who saw what and when.

Integration and migration

The system sits among portfolio accounting, relationship management, e-signature, email archiving and reporting tools, so it needs stable APIs, webhook notifications on lifecycle events and identity federation through single sign-on with group and attribute mapping. Migration from an existing platform is usually the largest workstream: mapping the legacy metadata schema to the new model, resolving documents that carry no usable metadata, de-duplicating by content hash, preserving version chains and original timestamps, translating permissions rather than reapplying defaults, and verifying every transferred object by checksum.

Deciding between remediation and rebuild

Before proposing an architecture we run a structured discovery. Consultants analyse the functional specification of the current system, rank capabilities by defect severity and business criticality, and separate features that must be preserved from those that exist only because the old platform demanded them. Architects assess the incumbent stack, its coupling and its accumulated technical debt, then model several viable paths, including targeted remediation and clean-slate construction, each costed with its operational profile: deployment topology, disaster recovery targets, data residency and run cost. The comparison is often counter-intuitive, because undoing entrenched debt can carry more cost and more risk than building alongside it and migrating.

What This Delivers

Documents are found by what they relate to rather than by where someone filed them, and restricted material stays invisible to users outside the barrier, including in search. Retention and disposal become a policy the system executes instead of a manual routine, and supervisory questions about access are answered from the audit log.

Technologies and Tools

.NET and Java services behind typed APIs, Angular front ends, MS SQL Server for the metadata and relationship model, encrypted cloud object storage with a full-text and faceted search service, and deployment on AWS or Azure using containers, infrastructure as code and automated build, test and release pipelines.