The engagement
A fund taking on 200+ investors, with four stated requirements. Share confidential strategy and track-record material with prospects. Collect investor information and documents. Generate agreements from varying templates and execute them electronically. And build an institutional process for managing KYC information on an ongoing basis — not just through the raise.
Those read as four projects. They are one, because each stage is only as good as what the previous stage handed it.
This fund raised under a regime that requires more than a US raise does: alongside the subscription agreement, tax form and accredited-investor representation, it needed a government identity-registry lookup, a category classification validated against the regulator's own taxonomy, and a stamped instrument — for two hundred investors, most of whom were never in the same room as the fund. Everything below therefore had to survive the harder version of the problem.
The question worth asking of any onboarding system is not whether it knows your regulator. It is whether your regulator is hard-coded. Here it is a tag on a field.
Stage one — the data room, before anyone is an investor
Strategy documents and track record go into a permission-controlled Data Room, organised into sub-folders. Access is granted per investor firm, per sub-folder, and each investor sees only what has been explicitly shared with them — nothing above it, nothing beside it.
Access can cascade to every file and folder underneath, or stop at one folder. Revoking is the same action in reverse. Individual documents can also be shared by link, which is what most prospect conversations actually need.
A data room is not a folder with a password. It is a record of who was shown what, which is a different thing entirely when someone asks eighteen months later.
Stage two — collecting information the system can act on
Each investor receives a secure link and completes their own KYC — no CapHive account required. What they see is not a fixed form. It is built from a form type: the standard field set plus whatever custom fields the fund has defined, grouped into wizard steps.
That matters because the same investor type needs different questions in different regulatory contexts. Every field can carry a regulatory environment tag, and switching an environment on adds its fields to the form rather than forking it. A tagged form picks up that regime's extra questions — investor category and sub-category, say, with sub-categories validated against the category chosen, or an additional declaration set. Packs ship for the regimes we have been asked for; a regime without one is a set of custom fields defined once and reused, which is what most regimes are once you stop treating each as a separate product.
Non-individual investors — trusts, LLCs, LLPs, corporates — get their own field set entirely: beneficial ownership, authorised signatories, FATCA/CRS classification, because non-individual KYC is a separate record type rather than a checkbox on the individual form. That last field is the one every jurisdiction on the list has in common, for the obvious reason: it is the one the US exported to all of them.
Where a form needs more than three pages, extra steps are switched on and given real names — Beneficial Ownership, FATCA Declarations. A step with no fields assigned to it is never rendered, so the trust form is longer than the individual form without anyone maintaining two wizards.
Two details did more work than they should have:
- Interim saves don't validate. An investor can stop halfway through a nine-step trust form and come back tomorrow. Validation is enforced on submit, not on save — which removed most abandoned forms.
- Documents can fill the form. With the document-first wizard on, the investor uploads their ID and address proof first; extraction reads them and opens the form pre-filled, so their job is checking rather than typing. Anyone who prefers to type still can.
Stage three — verification that isn't a person reading a scan
Verification means one thing whatever the country: the value is checked against an authoritative source that is not the investor, and the whole response is stored rather than a summary — a pass/fail badge for the operator, an auditable record underneath. A name mismatch becomes a flag on day one instead of a discovery in month six when a distribution bounces.
Which authoritative sources exist is regional. Where a national tax-identifier registry can be called, verification runs automatically in the background whenever the identifier, full name or date of birth changes, confirming the number exists and that the registered name and date of birth match what is on file. Bank verification runs the same way on account number, routing code or name, confirming the beneficiary name at the bank. Where a central KYC registry exists, a lookup returns the registry record — an identifier search, a one-time passcode to the investor's registered mobile, then the downloaded record shown side by side with the current values before anything is copied across; where the investor cannot be reached for a passcode, a secondary route answers from identifier and date of birth alone. Each lands as its own dated KYC Data record and is kept permanently, so "where did this address come from" always has an answer.
Three of the checks in this stage are not regional at all, and they are the ones that carry the most weight wherever there is no national KYC registry to call — the US included. Extraction reads the uploaded identity and address documents. Cross-checking compares the value read out of a document against the value typed into the form. AML screening runs sanctions, PEP, warnings and adverse-media lists, which are international by construction — a sanctions list does not care where your fund is domiciled. A US fund gets all three on day one, without a registry connector existing.
Stage four — documents generated once, signed electronically
Agreements are generated from templates against the investor's own record — one touch per investor, or one action for a folder. Every generated document must be explicitly approved before it goes anywhere, then signatories are added with a label and a signing order.
Signers get an email link and sign from a phone. The signing provider is a setting on the fund, not a fixture of the product — DocuSign or a regional equivalent, with the same generated document, the same labelled signatories, the same signing order and the same filing behaviour behind either. This fund signed through its own regional provider, using a government-backed digital signature credential; a fund in Boston sends the identical envelope through DocuSign and never encounters that credential at all. Sequential order means signer two is only notified once signer one is done; parallel means everyone at once. When the last signature lands, the executed copy is filed back automatically against the investor, locked and approved. Requests expire after 90 days if they stall, which is a feature — a signature request with no expiry is just an open loop.
Where execution carries a statutory attachment, the attachment travels with the template. For this fund that attachment was duty-stamped paper: a document template carries its own stamping configuration — the stamp values by tag, which page the signature sits on, and the note and its placement — and every document generated from that template inherits it. When the document is sent, the stamping request goes to the provider alongside the signature request, so the executed copy comes back stamped rather than stamped afterwards by someone with a courier. In a jurisdiction with nothing to attach — the US among them — that configuration is simply absent and everything around it is unchanged.
A whole folder can go out at once with Send All for eSign, which picks up every generated, approved, unsent document and queues them with a small random delay between each so the signing provider isn't hammered.
| Requirement | What it runs on |
|---|---|
| Share confidential strategy material | Data Room sub-folders, access per investor firm, cascading or not |
| Collect investor information | Form types with custom fields and named wizard steps; regulatory packs added by tag, not by forking the form; secure link, no login |
| Collect documents | Required-document checklist per KYC type; investor sees the same checklist you do |
| Verify identity | Extraction, cross-check and AML screening everywhere; national registry connectors where they exist — here automatic tax-identifier and bank checks, plus a central KYC registry lookup |
| Generate agreements | Template-based generation per investor, individually approved |
| Execute electronically | E-signature through DocuSign or a regional equivalent, with labelled signatories and signing order; statutory stamping carried on the template where the jurisdiction has any; executed copy filed automatically |
| Manage KYC on an ongoing basis | Verified flag with who and when; expiry dates with 60/30/15-day warnings |
⚙️ Under the hood: the checklist that runs before a human does
When an investor marks their form complete, the KYC Onboarding Agent works through a fixed sequence before anyone opens the record.
It checks that every required field — standard and custom — actually holds a value, and that the value isn't a placeholder like "N/A", "TEST" or "--". It checks that every document-upload field has a file behind it. It shows the AI each uploaded file together with the label it was filed under, and asks whether the file is in fact that document. For fields configured for cross-checking, it reads the value out of the document and compares it to what was typed in the form. Then it checks the expiry date against the warning windows the team configured.
The result is a report marked ready or blocked. If nothing blocking came up, AML screening starts on its own.
None of that is judgement work. All of it was previously costing judgement time.
The compliance officer's scarcest asset is attention on the hard cases. Every mechanical check you automate is attention returned to them.
And the "ongoing" part, which is where most onboarding projects quietly fail
Onboarding is usually scoped as a raise-period activity. It isn't. A Docs Completed flag maintains itself as files land against the checklist. Expiry dates carry 60-, 30- and 15-day warning windows that email the team before a record lapses. Verification records who signed off and when.
That last one is load-bearing. A verified KYC is the precondition for generating an investor's capital call notices and their investor statement — the statement run will refuse a commitment whose KYC isn't verified and report it by name rather than skipping it silently. Onboarding debt is drawdown debt with a delay.
🌍 What travels, and what is configuration
This engagement ran under one particular regime. Almost none of what made it work belongs to that regime. Here is the split, stated plainly enough to argue with.
| Stage | Identical in every jurisdiction | What actually changes |
|---|---|---|
| Data room | Per-firm, per-folder access; cascade or stop; record of who saw what | Nothing |
| Form definition | Form types, custom fields, named wizard steps, interim saves, document-first entry | Which regulatory pack is switched on — or none, and the fields are simply defined |
| Verification | Extraction, form-to-document cross-check, AML screening, full-response storage | Whether a national identity registry exists to call, and which one |
| Document generation | Template-based, per-investor, individually approved before it moves | The template text — which was always going to be yours |
| Execution | Envelope, signatory labels, signing order, auto-filing, 90-day expiry | Provider (DocuSign, or a regional equivalent) and the signing credential behind it |
| Statutory attachment | — | Only where a regime requires a stamped instrument; in the US there is nothing to attach and the configuration is simply absent |
| Ongoing KYC | Verified flag with who and when; 60/30/15-day expiry warnings; the block on unverified commitments | What expires, and after how long |
One clarification we would rather make than let a table imply otherwise: there is no US regulatory pack today, in the way packs ship for the regimes we have been asked for so far. Nothing about a US raise needs one — a Reg D subscription pack is a field set, a document checklist and a DocuSign envelope, all of which are configuration on the day you start. But if a US fund wants its own tagged, validated field set with sub-category rules enforced, that is something we would build with you, and we would rather say so here than have you find out on the call.
📊 The impact
200+ limited partners onboarded through one digitised process — strategy material shared under access control, information and documents collected through customised forms, agreements generated in one touch and executed electronically, and a KYC repository that later capital events read from directly.
The operational point isn't that each step got faster, though it did. It is that no step re-keys the previous one. The name that came back verified from the identity registry is the name on the generated agreement, is the name on the call notice, is the name on the statement.
What to take from this
- Count round trips, not review time. If review takes twenty minutes and onboarding takes two weeks, the review is not your problem.
- Ask for the document before the form. An investor will photograph an ID card in ten seconds and mistype the number in thirty.
- Keep jurisdiction differences in the form definition — not in a folder of Word files someone has to remember to update in three places. A regime you enter in year three should cost you a field set, not a second onboarding system.
- Make every generated document individually approvable. Bulk generation without per-document approval is how the wrong figure reaches an investor.
- Scope onboarding past the close. Expiry, re-verification and document completeness are the part that decides whether year three is calm.
Where this goes next
The same verified records are what a drawdown runs against — see capital drawdowns across 100+ LPs, or investor statements for 500+ LPs. If you want to talk through your own onboarding, book a walkthrough.
Client name withheld. The workflow, platform mechanics and behaviour described are exactly as CapHive runs them; supporting detail is illustrative of how engagements of this shape run. What travels, and what is configuration marks which parts of it are regional settings rather than platform behaviour.