Almost every piece of enterprise software logs something. A CRM records field changes. An accounting system records entries. Every serious workflow or orchestration engine records each run, each step, each retry, each payload. "We have an audit trail" is therefore true of nearly everyone, which is precisely why it tells a buyer in regulated financial operations almost nothing.
The claim survives because it sounds like a control. It is not a control. It is a recording device.
A log answers "what happened". Governance answers "who was allowed to make it happen, and was that enforced before it did".
Everyone logs. That is the problem with the claim.
Comprehensive logging is a solved engineering problem, and general-purpose orchestration engines are genuinely good at it. They will tell you which step ran, when, with which inputs, under which version, and what it returned. That is valuable operational telemetry.
But telemetry is descriptive. It records the world as it turned out. It has no opinion on whether the action should have been permitted, and no mechanism to stop it. If a step executes at 02:14 without the approval it required, a complete audit trail records exactly that: an unauthorised action, faithfully preserved, with a timestamp.
An auditor reading that log now has excellent evidence of a control failure. That is not the outcome anybody bought the platform for.
The same action, in two systems
Take a concrete case: a capital call notice going out to limited partners, and the NAV figure that supports it being finalised. Same fund, same team, same calendar pressure. Two different platforms underneath.
The analyst finalises the NAV and triggers the notice. The platform records the run: inputs, calculation, the outbound send, the timestamp, the user ID.
Approval happened by convention - a message, a nod in a stand-up, a reviewer who was on leave and whose sign-off was picked up by the person who prepared the figure.
Somewhere later, a reconciliation shows the figure was wrong. The log tells you precisely when the wrong number went to investors, and that nothing prevented it.
Result: perfect evidence of an uncontrolled process.
The same analyst finalises the NAV. The platform will not release the figure or issue the notice: the step is defined as requiring a checker who is not the maker.
Self-approval is blocked structurally, not discouraged. Delegation and out-of-hours cover are named in advance, so the control does not quietly dissolve at 18:00 on a quarter end.
A discrepancy raises an exception that routes to a named owner with the case attached, before anything reaches an investor.
Result: the wrong thing could not proceed, and the record proves the control operated.
The two platforms produce logs of comparable richness. Only one of them produces a different outcome.
"What happened" is the easy question
Auditors, depositaries and supervisors have always asked what happened. Increasingly they ask something harder: show that the process was designed so the wrong thing could not have happened. Demonstrate the separation of duties. Demonstrate that the control was operating on the day, not merely documented in a policy.
A log cannot answer that. It is, by construction, a description of outcomes, and a system that can be driven around its own controls will faithfully log the drive-around. Design effectiveness and operating effectiveness are different tests, and only enforcement evidences the first.
Ask your platform to let one person prepare and approve the same NAV release. If it lets them and simply records it, you have logging. If it refuses, you have governance.
Governance you have to build yourself is governance you have to maintain forever
Any sufficiently flexible orchestration engine can be made to enforce approvals. Teams do it: a role table, a conditional branch, a guard on the transition, a scheduled check for self-approval. It works, on the workflows where somebody remembered to add it, until the person who built it moves on and the next workflow ships without it.
That is the real distinction. Governance assembled on top of a general-purpose engine is a feature of a particular workflow. Governance built into the platform is a property of every workflow, including the one an operations team builds next Tuesday afternoon without asking anyone.
This also determines what AI can safely do. An agent inside a governed workflow can extract, reconcile, classify and draft, because the consequential step still cannot proceed without a named human. An agent inside a logged workflow can act, and you will have an excellent record of it.
What a structural default looks like in production
More than 300 fund specialists at Ocorian run global fund and investor operations on Next Matter, with approvals and a complete audit trail applied by default rather than rebuilt per workflow. Trade Republic runs bank-grade client operations at consumer scale, b2venture runs venture operations to roughly 800M EUR AUM, and Swan runs embedded-finance operations on the same pattern. In each, governance is a structural property of the platform, not a claim about its logging. Read the Ocorian case study
Scale is what exposes the difference. One carefully governed workflow proves a team is diligent. Hundreds of workflows carrying the same controls, built by operations people rather than engineers, proves the platform is.
Logging tells you what happened. Governance decides what is allowed to happen. Only one of those is a control.
For the mechanics, see governance and audit and our guide to building an audit-ready fund operations process.