How to automate capital call and distribution notices

The problem: one notice, many portals

A family office, fund-of-funds team, pension fund or insurer with commitments to dozens of funds rarely deals with one portal. Each GP chooses its own investor portal, and many administrators run their own. The same software is often deployed per GP or per administrator, so an LP can hold separate logins for several instances of one product. The registry currently lists 33 portals that deliver capital call information to investors.

The work that follows is familiar. A notice arrives by email, usually with a link rather than the document. Someone logs in, completes a second factor, finds the notice, downloads the PDF, renames it, files it by entity and fund, and keys the amount, due date and wire details into the accounting system or a treasury workflow. The same happens for distribution notices, capital account statements and quarterly reports, on a quarterly cycle that bunches the load into a few weeks.

The cost is not only time. Capital calls have short funding windows, so a missed email or an expired session is an operational risk. And the people doing the work hold a growing set of credentials and authenticator entries that are hard to audit or hand over.

There are five routes to reducing this work. They are listed below in order of preference: the earlier routes are sanctioned by the portal or the GP, need less maintenance and carry less risk.

A common payload: the ILPA Capital Call & Distribution Template v2.0

Whatever the route, decide first what the data should look like when it arrives. In 2025 ILPA released version 2.0 of its Capital Call & Distribution Template, replacing the 2011 version. It covers the accounting detail and transaction components of notices, and ILPA's adoption timeline refers to Q1 2026 and Q1 2027. ILPA publishes it as a document package. The research behind this registry found no machine-readable schema or API on ILPA's template hub.

Mapping every source to the template's transaction types and definitions lets you compare notices from different GPs field by field, and makes a later change of route invisible to downstream systems. In the registry, 1 portal declares support for the ILPA capital call template in its standards field. Others may support it without the entry saying so, so ask your GPs which version they will deliver.

Route 1: a documented API or MCP server you are allowed to use

The cleanest route is an API or MCP server that the vendor documents and makes available to investors, not only to the GP. Many portals have an API, but it is often built for the GP, the administrator or integration partners. Of the portals in the table below, the registry records 19 APIs as partner only. Of the 33 portals with capital call data, the assessments record investor-side programmatic access for 3. The difference matters, and the guide partner-only portal access explained covers what it means in practice.

In the registry, those entries are Arch, Chronograph LP and MSCI Private i (Burgiss). All of them are reporting platforms where the LP is the customer, rather than a GP's own portal. The guide to investor portals with an API or MCP server compares these options in more detail. Check three things before you build: that the access is for your organisation and not only for the GP, which resources it exposes (capital calls and documents, not only holdings), and whether the vendor's terms allow use by an agent acting for you.

Route 2: ask the GP or administrator to deliver to you

When the portal has no investor API, the next best route is often a request rather than software. GPs and administrators already send notices. Ask whether they can also attach documents to emails sent to a nominated address, push files to an SFTP server or provide a data feed. Only 3 portals in the table record an SFTP channel, all of them partner only, so this is usually an arrangement with the GP or administrator rather than a portal feature you switch on. Delivery the GP sets up for you is plainly within the terms, and it tells the GP and its vendor that investors want direct access.

A short request is enough. Adapt this text to your entity names and destinations:

Keep a record of what each GP agreed. The registry has fields for the channels a portal supports, and corrections from LPs and vendors are welcome by pull request.

Route 3: parse the email notifications

Many portals email investors when something new is posted. 16 portals in the table record email notifications as available, 17 unknown and 0 not offered. Notifications arrive in your own mailbox, so processing them is within your control and does not touch the portal.

A workable setup routes all fund notices to one shared mailbox, classifies each message by sender and subject, extracts attachments where present, and creates a task when the message only contains a link. Check what each sender actually includes. For example, the Carta entry notes: "Capital call notices emailed from investor-notices@carta.com with a link into the portal." In that case email parsing tells you a notice exists and when it arrived, which is still useful for deadlines and reconciliation, but someone or something still has to fetch the document.

Treat the parsed mailbox as a trigger and a control, not as the system of record. Reconcile notices against your commitment list each quarter, so a filtered or missing email shows up as a gap.

Route 4: browser automation, only where the terms permit it

Automating the portal's web interface with the investor's own login can fill the gap for portals with no other channel. It is also where most of the risk lies, so it comes after the sanctioned routes. Some portal terms forbid robots, scraping or automated queries outright. For example, the Juniper Square entry records: "End User Terms and Website Terms prohibit scraping, robots and other automated queries without prior written permission, and sharing passwords with advisers."

The registry records each portal's position in the terms.automation_policy field: permitted where the terms or vendor explicitly allow consented automation, tolerated where the terms do not address it, prohibited where they forbid it, and unknown where nobody has checked. Among the portals in the table, 7 are recorded as prohibited, 1 as permitted and 25 as unknown. Unknown is not permission: read the terms, or ask the vendor, before you automate.

Where automation is allowed, the registry's connector rules are a reasonable baseline: run on your own infrastructure with your own credentials, keep a human in the loop for second factors, stay read-only, pace requests like one careful user, identify the client in the user agent, log every fetch, and stop if the portal blocks. Never solve CAPTCHAs, spoof fingerprints or share sessions. Where the policy is prohibited, use one of the other routes and ask the vendor to offer investor access.

Route 5: managed collection

Some teams prefer to hand the work to a service. Commercial aggregators collect documents from GP portals and inboxes on an LP's behalf, extract the data and deliver it to portfolio and accounting systems. They differ in how they reach portals, where credentials are held, and which downstream systems they support. The guide to Canoe alternatives compares the options neutrally.

Questions to ask any provider: which portals it reaches by API, by consented automation and by manual collection; how it handles portals whose terms prohibit automation; where credentials and second factors are held, and who can access them; whether output is mapped to the ILPA templates; and what happens to your data and credentials when you leave.

Disclosure. The publisher of this registry also sells a managed service, Managed Portal Vaults. It is one option among several, it is a custody service, and it states that it uses manual collection where a portal's terms do not allow automation. Nothing in the registry data or this guide depends on it.

Portals with capital call data: channels and terms

The table lists every registry entry with the capital_calls capability, sorted by difficulty, which runs from 1 (documented self-serve api an investor can use) to 5 (web login only with mfa, view only). Status labels: Available, Beta, Partner only, Planned, Not offered, Unknown. Entries are community research and mostly unverified. Vendors and users can correct them by pull request.

Difficulty across these portals: 2 portals rated 2 of 5, 6 portals rated 3 of 5, 25 portals rated 4 of 5.

How the open protocol turns this into one integration

Each route above is a separate integration per portal or per GP. The Open Investor Portal Protocol (OIPP) is designed to replace that with one. An investor registers once and gets a cryptographic identity, then links it to each portal account from inside the portal, where the portal stays in control and can revoke the link. From then on the investor's own client signs every request with its key, and reaches each linked portal through the same small REST surface, mirrored as MCP tools: accounts, documents, capital calls, distributions, capital account statements and a notifications feed that replaces email alerts.

Capital call and distribution payloads in OIPP are aligned with the ILPA templates, so a capital call from one portal looks the same as one from another. In the default mode no portal password or token is held by the platform, and portal data flows directly from the portal to the investor's client. Today 0 portals in the table implement OIPP, so for now the protocol sits alongside the routes above. Each LP request to a vendor to support it moves a portal from routes 3 to 5 towards route 1. How the protocol works has the details.

Frequently asked questions

Sources

Portal channels, difficulty ratings and automation policies come from the open registry and its research assessments, as of the date above. Each portal page lists its own sources.

• ILPA Capital Call & Distribution Template: https://ilpa.org/industry-guidance/templates-standards-model-documents/ilpa-templates-hub/ilpa-capital-call-distribution-template/
• ILPA templates hub: https://ilpa.org/industry-guidance/templates-standards-model-documents/updated-ilpa-templates-hub/
• Juniper Square end user terms of use: https://www.junipersquare.com/terms-and-policies/end-user-terms-of-use
• Carta connector listing: https://claude.com/connectors/carta
• Chronograph MCP connectors: https://www.chronograph.pe/mcp-connectors/
• Arch Client API documentation: https://arch.co/client-api/api-docs/