See it in action
Apex Yield Fund: from formation to first close.
One complete fund lifecycle, told the way it is lived. Apex Yield is a Luxembourg RAIF structured as an SCSp with a €250M target, run by Vertex AIFM Sàrl with four service providers alongside them. The fund and the firms are illustrative; the sequence is the one Artery runs.
Formation
The board of Vertex AIFM Sàrl has approved a new alternative fund — the Apex Yield Fund, a Luxembourg RAIF structured as an SCSp, targeting €250M.
Sophie, conducting officer at Vertex, opens Artery and creates the fund. She picks the regime and the vehicle, names the fund, and sets the target size and intended first close. Nothing here is a document to be circulated later — the fund's identity is captured once and every party engaged from this point works from the same facts.
As soon as the fund is created, the launch workflow lays itself out: eighteen steps across five phases, each with an expected output and a party who owns it.
- Select regime (RAIF) and vehicle (SCSp)
- Name the fund, set the €250M target and intended first close
- Create — the launch workflow is generated with its owners
Illustrative interface — sample data, not a live fund.
Engaging the providers
Apex Yield needs five parties: an AIFM (Vertex themselves), a depositary (Meridian Depositary Bank), an administrator (Northstar Fund Services), an auditor (Ardent Audit Sàrl), and legal counsel (Beacon Legal Counsel).
The stakeholders panel shows five roles, four of them empty. For each one Sophie either picks an organisation she already works with or invites a new one by email. The engagement she sends carries the fund, the role and the scope of access it grants — the counterparty can see exactly what they are being asked to accept before they accept it.
Each provider receives a secure link. There is no account to create, no procurement exercise, no separate portal credential to chase.
- Open the role, choose an organisation or invite a new one
- Review the locked context — fund, role, scope — and send
- Watch each role move from empty to proposed to accepted
Illustrative interface — sample data, not a live fund.
The provider accepts
Meridian's depositary operations team receives the magic link. They review the engagement — which fund, which role, what's expected — and accept with one click.
On Meridian's side the screen is deliberately plain: the fund, the role being offered, the operator offering it, and what accepting will give them access to. They can accept or decline, and either answer is part of the record.
The moment they accept, the binding is created and the launch step that was waiting on the depositary appointment resolves itself. Nobody has to go back and tick anything.
- Open the secure link — no account setup required
- Read the engagement: fund, role, operator, scope
- Accept — access opens and the launch step resolves
Illustrative interface — sample data, not a live fund.
Coordinating the launch
With providers engaged, the fund launch workflow begins. Eighteen steps across five phases — formation, operating model, certification, operational readiness, launch. Each step unlocks in sequence, each has an expected output, each is assigned to a responsible party.
The timeline is where the launch is actually run. The active step pulses; completed steps carry their outputs; blocked steps state plainly what they are waiting on and from whom. Sophie can see, without asking anyone, that the fund is on phase three and that two of the five parties currently hold something.
Every party sees the same fund from their own side. Northstar sees the steps they own; Ardent sees theirs. Nobody sees more than their engagement grants.
- Follow the spine: phases, active step, blocking reasons
- Open any step for its owner, expected outputs and history
- Advance when the outputs are in — or record why you are closing it anyway
- Formation
- Fund identity & structure
- Appoint management company / AIFM
- Appointments
- Appoint fund administrator
- Appoint depositary
- Evidence
- Constitutional document pack
- Appoint auditor
Illustrative interface — sample data, not a live fund.
Requesting documents
Step 7 needs the offering document from legal counsel. The operator clicks 'Request from counterparty' — the modal is pre-filled with the step, the role and the expected document. Beacon receives a secure link and uploads the LPA directly against the step.
The request is not an email. It has a named recipient organisation, a due date, an expected output and a state. While it is open, the step shows exactly what it is waiting for. When Beacon uploads, the document lands against the step that asked for it, versioned in place, and the request closes itself.
Neither side has to reconcile anything afterwards. The ask, the answer and the timing are one record.
- Request from counterparty — step, role and expected output pre-filled
- Counterparty uploads against the step by secure link
- The request moves from pending to fulfilled, visibly on the timeline
Illustrative interface — sample data, not a live fund.
An operator override
Step 5 — operating model lock-in — is overdue. Legal counsel hasn't responded. The conducting officer decides to close it directly, recording the reason: 'Operating model agreed with counsel by email outside the platform.' The step closes with an audit-significant marker and the mandatory reason quoted in full.
Real launches do not run cleanly, and a system that pretends otherwise gets worked around. Sophie has the authority to close a step on her own fund — but she cannot do it silently. The reason field is mandatory, the decision is marked audit-significant, and the marker stays visible on the timeline for the life of the fund.
The exception is as legible as the happy path. That is the point.
- Close the step directly, as the operator with standing on the fund
- Enter the mandatory reason — free text, quoted in full afterwards
- The step closes carrying an audit-significant marker
- Formation
- Fund identity & structure
- Appoint management company / AIFM
- Appointments
- Appoint fund administrator
- Appoint depositary
- Evidence
- Constitutional document pack
- Appoint auditor
Illustrative interface — sample data, not a live fund.
The audit trail
Three months later, evidence of the fund's launch governance is requested. Every decision — who approved what, when, how and why — is available in one place. SHA-256 evidence hashes show that no record has been altered, and the conducting officer's override is clearly marked and explained.
Nobody rebuilds anything. The trail was written as the work happened: each action sequenced, timestamped and attributed to a named person at a named organisation, each decision carrying a content hash. Records are appended, never quietly rewritten, so a correction reads as a correction rather than as a gap.
The file can be exported for internal review, board reporting or provider oversight — as a record of how the fund was actually launched, not a reconstruction of it.
- Open the fund history: eighteen steps, every actor, every timestamp
- Check any decision against its SHA-256 evidence hash
- Export the trail for the review file
9f2c4a…b71e08VerifiedIllustrative interface — sample data, not a live fund.
This is what fund coordination looks like when it works
Apex Yield is illustrative, but the sequence is not. Bring a structure you are standing up now and we will walk it through the system with you.