Building a Deal Lifecycle Platform: Document Versioning, Export Packs and Multi-Portal Access

Structured finance deals involve multiple parties, hundreds of documents, and strict compliance requirements. We built a platform that manages the entire lifecycle: deal creation, multi-party document collection, version-controlled storage, and time-limited export distribution to lenders.

This article covers the architecture, the document identity model, the export system, and the multi-portal access layer. Everything described here is deployed and operational.

The Problem: Deals Across Multiple Parties

A structured finance deal typically involves a deal originator, one or more sponsors providing documentation, brokers managing relationships, and lenders who need to review a complete document package before making a decision.

Before this system, the process ran on email, shared drives, and manual checklists. Someone would email a sponsor requesting three documents. The sponsor would send two, forget the third, then send an updated version of the first one a week later. The deal team would track progress in a spreadsheet. When a lender requested the full package, someone would manually assemble a ZIP file, hoping they included the right versions.

The problems are obvious: no version control, no audit trail, no structured way to track what's missing, and no secure distribution mechanism.

Seven Runtime Pillars

The platform runs across seven interconnected systems, each with a defined responsibility:

1. PostgreSQL (Supabase). The single source of truth. 38 tables, 500+ columns, 73+ RPC functions, and 135+ row-level security policies. Every piece of operational data lives here.
2. n8n (self-hosted). 33 webhook-driven automation workflows handling deal provisioning, document processing, notifications, index generation, and CRM updates.
3. Google Apps Script. Generates the Google Drive folder tree for each deal (7 sections, roughly 20 subfolders), creates template documents, and renders HTML indexes and gap lists.
4. AWS S3. The canonical document vault. Every approved document is stored here with deterministic keying. A separate bucket holds export packs.
5. CloudFront. CDN delivery for all client-facing applications and public document access.
6. Supabase Edge Function. Handles transactional email through Resend. 14 templates, brand-routed rendering, idempotency checks on correlation IDs.
7. Export-Zipper. A Node.js background worker that builds ZIP packages on demand using a database-backed lease model to prevent duplicate processing.

The principle is separation of responsibility. Each pillar does one thing. PostgreSQL is the authority. n8n is the orchestrator. S3 is the vault. Nothing crosses boundaries without a defined interface.

The Document Identity Contract

Document management in regulated environments fails when identity is ambiguous. If two people upload a file called valuation_report.pdf, which one is authoritative? If someone uploads a new version, how do you know which version it replaces?

We solved this with a formal document identity contract. The rules are precise:

• One logical document = one doc_key per deal. Identity is never based on filename. A document's identity is its doc_key, assigned when the checklist is seeded.
• Exactly one current version. For every combination of (deal_id, doc_key, sibling_key), exactly one row has is_current = true. When a new version arrives, the prior version is marked superseded, and the new row carries an incremented version_seq and a supersedes_id pointing to its predecessor.
• Multiupload support. 14 document keys support multiple concurrent files via a sibling_key (for example, director_a, director_b). Each sibling maintains its own independent version chain.
• Deduplication by checksum. If the same file is uploaded twice (matched by SHA-256 checksum), the system updates metadata in place rather than creating a duplicate version.
• Folder binding. Each document is bound to a folder_key referencing the deal's folder structure. The binding always targets the deepest semantic folder, not the parent.

This contract is enforced at the database level through constraints, triggers, and RPC functions. It's not a guideline. It's a structural guarantee.

Six Deal Modes

Not every deal requires the same documents. A full lifecycle deal has different compliance requirements than a bridge loan.

The system supports six deal modes, each with a distinct checklist profile:

MODE	MANDATORY ITEMS	CONDITIONAL
Full	56	0
Bridge	13	4
Development	53	3
Refinance	17	2
Small Bridge	18	0
Standard Bridge	28	4

When a deal is created, the system seeds upload requests based on the selected mode. The checklist drives the entire collection process: what's required, what's received, what's missing. Completion percentage and readiness status are computed in real time.

Multi-Portal Access

Different parties need different levels of access. A deal originator needs full control. A sponsor needs to upload specific documents. A broker needs to view the data room. A lender needs to download the export pack.

The platform runs six distinct applications, each with its own authentication model:

• Admin Console. Email/password login with an additional is_admin() RPC check. Full deal management, approvals, invoicing, and export controls.
• Owner Portal. Magic link authentication (implicit OAuth). Data room view, checklist tracking, and export requests.
• Broker Portal. PKCE authentication flow. Data room view and export requests.
• Sponsor Gateway. Portal token authentication (bcrypt-hashed UUID). Document upload scoped to the specific checklist items assigned to that sponsor.
• Inbound Gateway. Portal token authentication. Third-party document upload for external parties not classified as sponsors.
• Share Route. Token-based access for time-limited ZIP downloads. Expiry and revoke controls with access logging.

Access boundaries are enforced by a can_access_deal() function at the database level. A sponsor can't see another sponsor's uploads. A broker can't approve documents. The permissions are structural, not presentational.

Export Pack Lifecycle

When a deal is ready for lender review, the deal team needs to send a clean, complete document package. Manually assembling this is error-prone. The system automates it.

The export lifecycle works in five steps:

1. Request. An admin triggers an export pack through the console. A row is created in export_packs with status queued.
2. Claim. The Export-Zipper worker polls the database for queued jobs. It claims a job using FOR UPDATE SKIP LOCKED to prevent duplicate processing. A lease expiry timestamp prevents orphaned claims.
3. Build. The worker downloads every is_current = true document from S3, organises them into an institutional folder structure, and generates a manifest.
4. Complete. The finished ZIP is uploaded to a dedicated export bucket. The job status is updated to complete.
5. Distribute. The admin creates share links with bcrypt-hashed tokens, configurable expiry dates, and revoke capability. Every access is logged.

The lease model is important. If the worker crashes mid-build, the lease expires and the job becomes claimable again. There's no manual intervention required to recover from a failure.

System Integrity

A platform this complex needs monitoring. We built a canary workflow that runs on a schedule and performs 21 webhook connectivity checks and 4 business logic checks. Every run is recorded in an automation_runs table that serves as the system's durable audit log. If a webhook endpoint goes down or a business rule starts producing unexpected results, the canary catches it.

The audit layer runs four deep: an activity log for event tracking, an audit log for triage classification changes, an audit events table for function-level tracking, and the automation runs table for workflow execution records. Between them, nothing happens in the system without a trace.

This is what a custom command suite looks like for structured finance. Seven pillars, six deal modes, five portal types, one database as the source of truth.