What an Investor Portal for an Emerging Fund Manager Actually Needs

Emerging managers often start investor relations with email, PDFs and a shared drive. It works for the first handful of investors, then breaks: statements go to the wrong address, a subscription form sits unsigned for a week, and nobody can say for certain which investor saw which version of the offering documents. An investor portal for fund managers fixes this, but only if it is scoped around what investors and operations actually need. This article sets out those needs, how the data should flow, and the order in which to build.

One principle runs throughout. Regulatory obligations (investor classification, KYC and AML, financial promotion rules, valuation and reporting) remain with the manager and its fund administrator. The portal supports those processes and records evidence of them. It does not discharge them.

The core jobs of an investor portal

Strip away the marketing and a portal does six jobs:

1. Let prospective investors in, but only once they are eligible to see the material.
2. Move investors through onboarding and subscription without email chains.
3. Give each investor a private, correct view of their holdings and performance.
4. Deliver documents reliably and prove they were delivered.
5. Give the operations team tools to run all of the above without engineering help.
6. Record every material action in an audit trail.

Onboarding and the KYC/AML hand-off

Onboarding is a workflow, not a form. A typical sequence:

• Registration with email verification and multi-factor authentication.
• Investor type: individual, joint, company, trust, pension or fund of funds. Each type drives different questions and document requirements.
• Eligibility self-certification (see the next section).
• KYC and AML checks, usually carried out by the administrator or a specialist identity verification provider. The portal collects data and documents, passes them across and records the outcome. It should not try to make the AML decision itself.
• Subscription documents signed electronically, with the signed version stored immutably.
• Status tracking so the investor and the operations team can both see what is outstanding.

The hand-off is where most portals fail. Agree the data format, the transfer method (API, secure file transfer or the provider's own portal) and the status values with the administrator before any screens are designed.

Eligibility gating

Private fund material is usually restricted to investors who meet specific criteria. The labels differ by jurisdiction: professional clients and certified high net worth or sophisticated investors in the UK, accredited investors in the United States, wholesale investors in Australia. The manager and its legal advisers decide which categories apply and what evidence is required.

The software's job is to enforce that decision consistently:

• Public pages show only material that may be shown to anyone.
• Restricted content (strategy detail, performance, offering documents) sits behind a gate that requires the correct certification or approval.
• Certifications are versioned, time-stamped and stored against the investor, with the wording they agreed to.
• Approval can require a manual review step by compliance before access is granted.
• Re-certification dates are tracked where the rules require it.

The document vault

Investors expect a single place for everything. A good vault has:

• Fund-wide documents: offering memorandum, supplements, constitutional documents, annual reports and audited accounts.
• Investor-specific documents: contract notes, capital account statements, tax documents and correspondence.
• Versioning, so a superseded document is retained and the current one is obvious.
• Read receipts recording when each investor first opened each document.
• Notifications by email when a new document is published, without attaching the document itself.

Store files in private object storage and serve them through short-lived signed URLs. A shared link that never expires is a data breach waiting to happen.

Capital accounts, NAV and performance reporting

This is the part investors check most often and the part most likely to be wrong if it is not designed carefully.

Where the numbers come from

The fund administrator is normally the source of truth for NAV, investor holdings and capital account balances. The portal should import the administrator's official figures, not recalculate them. Recalculating creates two versions of the truth and a reconciliation problem every month.

Typical inputs from the administrator, delivered by API or scheduled file:

Every import should be validated (totals reconcile, no negative units, class codes recognised), staged, and published by an operations user rather than going live automatically.

Getting the performance figures right

• Net of fees by default. Investors care about what they actually earned. Show gross figures only alongside net, and label both clearly.
• Share classes and series. Different classes can carry different fees, currencies and launch dates, so performance must be reported per class. Where a fund uses series accounting or equalisation to apply performance fees fairly, the portal must reflect the administrator's treatment rather than inventing its own.
• High-water mark. Show it where it affects the investor, for example the level a class or series must exceed before a performance fee accrues.
• Consistent periods. Month-to-date, year-to-date and since-inception figures should follow a documented methodology and match the factsheet exactly.
• Disclaimers. Past performance warnings and the basis of preparation belong next to the numbers, not in a footer.

Subscriptions and redemptions

Dealing workflows replace the most error-prone emails in fund operations:

• Subscriptions: the investor submits an amount and class, the portal shows the dealing day, cut-off time and settlement instructions, and the request moves through pending, received, accepted and settled states as the administrator confirms.
• Redemptions: the portal applies the fund's notice period, lock-up and any gate provisions as displayed rules, and routes the request to operations and the administrator.
• Confirmations: contract notes from the administrator are published to the investor's vault and linked to the original request.

The portal records requests and status. The administrator processes the dealing. Keep that boundary clear in both the interface and the terms of use.

Audit trail

An append-only audit log is non-negotiable. Record at least:

• Logins, MFA events and failed attempts.
• Eligibility certifications and approvals.
• Document uploads, publications and first views.
• Dealing requests and every status change.
• Data imports, who approved them and when they went live.
• Every administrative change to an investor record.

Write audit events from the server side, never from the browser, and make the table insert-only for application roles.

Row-level security

An investor seeing another investor's holdings is the worst failure a portal can have. Enforce isolation in the database, not only in application code. In PostgreSQL (and therefore Supabase), row-level security policies tie every row to the investor entities a user is entitled to see:

alter table holdings enable row level security;

create policy "investors read own holdings"
on holdings for select
using (
  investor_id in (
    select investor_id
    from investor_users
    where user_id = auth.uid()
  )
);

The mapping table matters because one person may act for several investors (a director of two investing companies, an adviser with delegated access), and one investor may have several users. Model that relationship explicitly from the start.

Admin tooling

The operations team should be able to run the portal without a developer. Minimum tooling:

• Investor and user management, including delegated access.
• Eligibility review queue.
• Import staging with validation results and a publish button.
• Document publishing, to one investor, a class or the whole fund.
• Dealing request queue with status updates.
• Exportable reports for the administrator, auditors and compliance.

Factsheet automation

Monthly factsheets are a reliable time sink. Once NAV and performance data live in the portal's database, the factsheet can be generated from the same published figures: performance table, chart, exposure breakdown and commentary written by the manager. Generate a PDF, route it for sign-off and publish it to the vault. The figures match the portal because they come from the same records.

A phased build order

Build in phases so investors get value early and the riskiest data work is done carefully.

Key takeaways

• An investor portal for fund managers supports regulatory processes; the obligations stay with the manager and its administrator.
• Treat the administrator as the source of truth and import their figures rather than recalculating NAV.
• Report net of fees, per share class, with high-water marks and methodology shown clearly.
• Enforce data isolation with row-level security and keep an append-only audit trail from day one.
• Give operations proper admin tooling, including staged and approved data imports.
• Ship an MVP of vault, gating and audit first, then add reporting, onboarding, dealing and automation.

How we apply this

Aurion Labs builds fund and investor technology on PostgreSQL with row-level security, server-side audit logging and administrator data pipelines, using Supabase, edge functions and Stripe where a project calls for them. We design around the manager's existing administrator and legal advisers rather than around our own assumptions. Our fund technology services page sets out the scope we typically cover.

For managers who want the portal under their own brand with no third-party logos, we deliver it as white-label development, and can host and operate it after launch. Examples of the systems we have built are on our work page.

This article is for information and education only and is not investment advice. See our risk disclaimer.