Building an audit-ready fund operations process

The concrete mechanics of governance, maker-checker approval, exception handling and evidence that regulators, depositaries and internal audit actually expect to see - and how to build them into the process rather than reconstruct them afterwards.

The gap that actually fails audits

Almost every fund administrator, asset manager and wealth platform can describe its processes. There is a procedure document for capital calls, a NAV checklist, an onboarding policy, an approval matrix. What most cannot do is reconstruct, on demand, exactly what happened in one specific case: this LP's drawdown last September, this share class's NAV on that valuation date, this investor's KYC file and the reasoning behind its risk rating.

That is the gap. Auditors, depositaries and regulators do not test the procedure document; they pick cases and ask what happened. When the answer requires someone to search mailboxes, open three spreadsheet versions, ask a colleague what they remember and assemble a pack over several days, the finding is not that the process was wrong. The finding is that the firm cannot evidence its own controls.

This guide is the end-to-end walkthrough of closing that gap: what audit-ready means operationally, why governance has to be structural, how maker-checker and exception handling produce evidence as a by-product of running the work, what regulators are measuring against today, and a checklist you can apply to any process this week.

1. What "audit-ready" actually means in practice

Audit-ready is not a policy, a certification or an intention. It is a capability with a precise definition: for any case, chosen at random by someone else, you can produce a complete and accurate record of what happened, without preparing it first.

That record has six components. If any one is missing, the process is not audit-ready:

• What data was used - which source systems were read, which values were returned, and at what version and timestamp. "The ledger said so" is not evidence; the ledger as at 14:02 on the valuation date is.
• Who did what - each action attributed to a named identity and role, including actions performed by an automation or AI agent, which are labelled as such.
• When - timestamps on every step, not on the case as a whole, so sequence and duration can be tested.
• Who approved - the named approver at each control point, what they saw when approving, and their decision.
• What was exceptional - every break, mismatch or escalation raised, who it was routed to, how it was resolved and the reason given.
• What was overridden - any deviation from the standard path, attributed, reasoned and held in the same record as everything else.

2. Governance has to be built in, not layered on

The instinct after an audit finding is to add logging to the existing process. It rarely works, for structural reasons rather than effort:

• Logging bolted on captures only what passes through the logged system. Fund operations span the ledger, custodian, transfer agency, KYC provider, CRM, data room and email. A log per system produces several partial trails with gaps exactly where the process crosses a boundary - which is where the risk sits.
• Retro-fitted evidence depends on people remembering to produce it. Anything that relies on someone attaching a screenshot, saving a version or copying an approval email will be complete on ordinary cases and missing on the difficult ones.
• Inconsistent records cannot be tested at population level. If each case is evidenced slightly differently, an auditor cannot sample; they escalate to a full review.

Governance built in means the opposite: the workflow is the control. Steps cannot be skipped because the next one is not available until the prior completes. Approvals are gates rather than reminders. Every read, action, decision and approval is recorded because recording is how the engine executes, not an additional task. Nobody has to remember anything, so the difficult cases are evidenced exactly as well as the easy ones.

Practically, that means one orchestration layer across the systems you already run - the ledger stays the ledger, the custodian stays the custodian - with the process, its roles, its gates and its record held in one place. See governance and audit for the mechanics.

3. Maker-checker as a structural control

Four-eyes approval is the single control most often documented and least often enforced. Written as a policy, it degrades under deadline pressure: the checker approves in bulk at 18:00 on the last day of the cycle, or the maker approves their own work because the checker is on leave. Enforced by the platform, it cannot.

How it runs operationally

Deeper: enforcing four-eyes and maker-checker approvals.

4. Exception and break handling is part of the audit story

Exceptions are where manual audit trails are weakest and where auditors look hardest, because an exception is by definition a case where the standard control did not apply cleanly. In a spreadsheet-and-email process, a break is discussed in a thread, fixed in a file and never recorded as having existed. The clean final NAV hides the fact that four positions did not reconcile and someone decided why.

Treated structurally, exception handling produces some of the strongest evidence you have. The lifecycle:

Because every break is captured the same way, exception rates by type, by system and by period become measurable - which is separately useful for operational resilience reporting. Deeper: managing exceptions and breaks in fund operations.

5. What regulators and depositaries look for

The specifics differ by framework, but the underlying tests are consistent. Evidence must be:

• Complete - covering the whole process, including the steps that crossed system boundaries and the cases that went wrong.
• Timestamped - per action, so sequence, duration and timeliness of controls can be tested.
• Versioned - the data as read at the time, and the process and configuration as they stood at the time, so a run from two years ago can still be explained on its own terms.
• Attributable - named identities and roles, with automated and AI actions labelled as such rather than presented as human ones.
• Exportable on demand - produced by the system, not assembled specially for the audit. Evidence prepared for an audit invites the question of what a normal day looks like.

Two concrete examples of what this is measured against

The EU AI Act is built on human oversight, transparency and record-keeping. Where AI supports a regulated operational process, you need to show that a person remained accountable for consequential decisions, that it was disclosed where AI was used, and that records exist of what the system did and on what inputs. A process with enforced approval gates and per-action logging satisfies this by construction. More: using AI in fund operations under the EU AI Act.

UK operational resilience (PS21/3) requires important business services to be identified and mapped, impact tolerances set, and the firm to evidence that it monitors and controls those services in practice - not only that it has documented them. NAV production, capital call processing and client onboarding are typically in scope. Real-time visibility of where each case sits, which are breaching their tolerance and what the control record shows is the evidence being asked for. More: UK operational resilience under PS21/3.

Depositaries and internal audit apply the same tests case by case: show me this NAV, this call, this onboarding, and everything behind it.

6. The practical checklist

Apply this to one process at a time - capital calls, NAV, onboarding, KYC. For a specific case chosen by someone else, can you answer each of these now, without preparation?

• What data was used? Every source system read, the values returned, and the version and timestamp of each.
• Who did each step? Named identities and roles, with automated and AI actions labelled as such.
• Who approved, and what did they see? The approver at each gate, their decision, the timestamp, and the basis presented to them.
• Was maker-checker separation enforced? By the system, with no bypass, and any configuration change to the gate recorded.
• Was there an exception? Every break raised, with its context, owner and escalation history.
• Was it resolved, and on what reasoning? The resolution, the resolver and the stated reason, not just the corrected figure.
• Was anything overridden? Attributed, reasoned and visible in the same record - no untracked side channel, no shared accounts, no verbal approvals.
• Can you produce all of it in minutes? Exported by the system for a case picked at random, without anyone assembling it.
• Does it hold across system boundaries? One continuous record spanning ledger, custodian, KYC provider and outbound channel, rather than several partial ones.
• Can you reconstruct a run from two years ago? On the data, process version and configuration that applied at the time.
• Can operations change the process when a requirement changes? In days, by the people accountable for it, with the change itself versioned.

Running in production today

These controls are in live use in regulated environments, at scale. Next Matter runs fund and client operations at Ocorian, where 300+ fund specialists work in the platform daily, at Trade Republic across high-volume client operations, at b2venture across a portfolio of around 800M EUR AUM, and at Swan in embedded finance operations. The platform is SOC 2 Type II and ISO 27001 certified, with SSO/SCIM and data residency you control.

Test this against one of your own processes

Bring a real capital call, NAV cycle or onboarding case and we will walk through the record it would produce, gate by gate.