menu_bookGuide

Putting AI into regulated financial workflows

A step-by-step walkthrough for adding AI to capital calls, NAV, investor onboarding, KYC/AML and reporting without losing control of the process or failing an audit.

The tension, and why it is solvable

Fund administrators, asset managers and wealth platforms want the speed AI offers: fewer hours spent recalculating drawdowns, chasing custodian breaks, re-keying onboarding data and drafting the same investor correspondence every quarter. What they cannot accept is a process where nobody can explain, months later, how a figure was produced, who approved it and what the model was allowed to decide on its own.

Those two things are only in conflict when AI is bolted onto an ungoverned process. When the process already has named accountability, defined approval points and evidence captured as it runs, AI becomes another actor inside that structure - one that drafts, calculates, reconciles and flags, while people continue to approve the things that carry consequence. That is the approach this guide walks through, in the order you would actually implement it.

Scope: regulated financial operations specifically - fund administration, asset management, wealth and wealthtech. Every example below is drawn from that domain.

1. Start with what "regulated" actually requires

Before any AI is introduced, the process itself has to be governed. If a capital call today lives in a spreadsheet, three inboxes and one person's memory, adding a model to it produces a faster ungoverned process. Governance first, AI second.

Three things have to be true of the process as it stands:

  • Accountability per step. Every step has a named owner and a named role, not a shared mailbox. When a NAV is signed off, the record must show which individual signed it, in what capacity.
  • Defined approvals. The points that cannot proceed without a human decision are written down before automation is designed: issuing a capital call, finalising a NAV, approving a KYC decision, releasing a payment, publishing an investor report.
  • Evidence a regulator would expect. For each of those decisions: what data was used, at what version, what the calculation was, who approved, when, and what happened to anything that was overridden. Under AIFMD, UCITS depositary oversight, 6AMLD, GDPR and the operational resilience expectations of the CSSF, BaFin and the FCA, this evidence is the deliverable - not the automation.

Practical test: pick one completed case from last quarter. If you cannot produce the full decision record for it in an afternoon without asking a colleague what they remember, the process is not yet ready for AI. Fix that first - see governance and audit.

2. Decide what AI does alone, and what always needs a human

The operating principle is narrow and it does not vary by process: AI drafts, calculates, summarises, reconciles and flags. A person approves anything with a consequence outside the firm. Consequence means money moves, a figure is published, a relationship is accepted or refused, or a regulator would hold someone accountable for the outcome.

Drawing that line abstractly is easy and useless. Draw it per process, per step, in writing. Two worked examples:

Capital calls

Compute the per-LP call from the commitment schedule

Pro-rata amounts, prior drawdowns, remaining undrawn, excuse and exclusion provisions, side-letter terms. Deterministic, checkable against source records, and safe for an agent to produce in full.

AI agent

Reconcile against the ledger and investor register, and flag breaks

Commitment totals that do not tie out, bank details changed since the last call, mid-period transfers, rounding above tolerance. The agent raises these as exceptions with both source values attached; it does not correct them.

AI agent

Resolve each exception

A named reviewer accepts, amends or rejects the agent's proposed resolution. Silent correction is the failure mode to design out.

Human decision

Approve issuance of the notices

Nothing reaches an LP until a second person - never the preparer, never the agent - approves the schedule and the drafted notices. This is the consequence point: money is being requested from investors.

Human approval - required

KYC and AML onboarding

Collect, extract and validate documentation

Pull entity documents, extract registered details, ownership percentages and director lists, check completeness and expiry, and normalise the data into the format your KYC provider and register expect.

AI agent

Build the ownership structure and screen

Resolve the UBO chain through intermediate entities, run sanctions, PEP and adverse media screening through the provider you already use, and summarise each hit against the underlying source for a reviewer.

AI agent

Adjudicate screening hits

A compliance reviewer clears or escalates each hit with a stated reason. A model may rank and summarise; it does not dismiss a potential match.

Human decision

Approve the risk rating and the onboarding decision

Assigning a risk classification, applying enhanced due diligence and accepting the relationship are decisions the firm is accountable for under 6AMLD. The agent prepares the file and the recommendation; a person owns the outcome.

Human approval - required

The pattern holds for NAV (agent reconciles positions, prices and accruals; a person signs off the final figure before publication) and for investor reporting (agent assembles and drafts; a person approves before distribution). Deeper on the boundary: automating manual workflows without compliance risk.

3. Keep AI inside the systems you already run

The second common failure is treating AI adoption as a platform migration. It is not. The ledger stays the ledger. The custodian, the transfer agency system, the KYC provider, the CRM, the data room and the investor portal all stay where they are, and remain the systems of record.

What you add is an orchestration layer that reads from and writes to them, runs the AI steps between them, enforces the approval gates and records everything. Concretely, for the processes above that means connections to:

  • The fund accounting ledger and custodian feeds for positions, cash, trial balances and prices.
  • The investor register and commitment schedules for LP terms, drawdown history and contact records.
  • The KYC/AML provider for screening, with hits returned into the workflow rather than into a separate console.
  • The CRM, data room and document store for supporting evidence, attached to the case rather than referenced from it.
  • Email, portal and e-signature channels for outbound investor communication.

This is why these processes go live in days rather than after a multi-quarter replatform, and why the audit trail spans the whole process instead of stopping at the boundary of one system. More: adding AI without replacing existing systems and integrations.

4. Build maker-checker and the audit trail in from the start

Audit readiness is either a property of the engine or a project you run twice a year. Retro-fitting evidence onto an AI process is where most pilots quietly fail: the automation works, and then nobody can prove what it did.

Two mechanisms, both structural rather than procedural:

Maker-checker (four eyes), enforced by the system

The approver must be a different identity from the preparer, and the system - not a policy document - enforces it. The approver sees what they are approving: the calculation basis, the data versions behind it, every exception raised and how each was resolved. Refusal returns the case with comments rather than deleting the trail. Where AI prepared the work, the record states that plainly, including which model and which prompt or configuration version produced it.

An audit trail produced by the run, not assembled afterwards

Every run captures, automatically and with timestamps:

  • Inputs and versions - each source system read, the values returned, and when they were read.
  • AI actions - what the agent calculated, drafted, matched or flagged, with the inputs it used and the model version behind it.
  • Exceptions - every break raised, who it went to, how it was resolved, and the reason given.
  • Approvals - named identity, role, decision and timestamp at each gate.
  • Overrides - possible, attributed, reasoned and visible in the same record as everything else. Overrides that leave no trace are the single clearest audit failure.
  • Outputs - the exact document, figure or message that left the firm, and where it went.

The standard to hold yourself to: for any case an auditor picks at random, you can export the complete timestamped record - AI actions, human decisions, approvals and overrides - without anyone preparing it first. Deeper on this: adopting AI without failing a compliance audit.

5. Moving from pilot to production

A pilot proves the AI can do the work. Production is a different question: whether the process around the AI meets the same standard as every other regulated process you run. Nothing about the governance gets lighter because the use case started as an experiment.

What has to change on the way in:

Ownership moves from the project to the line

A named operations owner, not the innovation team, is accountable for the process running correctly, with an escalation path when it does not.

Approval gates become mandatory, not advisory

Anything that was "reviewed informally" in the pilot is enforced by the system, with maker-checker separation and no bypass for urgency.

The audit trail becomes complete and exportable

Pilot logging is usually partial. Production requires the full record described above, retained under your policy, with data residency and access controls applied.

Failure behaviour is defined

What happens when a source system is unavailable, a model output is malformed, or a deadline passes with exceptions unresolved. Each case routes to a person rather than failing silently or proceeding on a default.

Change control applies to the workflow and to the AI configuration

Prompt, model and threshold changes are versioned and reviewed like any other change to a regulated process, so a run from six months ago can still be explained on the configuration that produced it.

Volume and monitoring are proven before cutover

Run in parallel with the existing process for a full cycle - a whole quarter-end, a whole call - and compare outputs and exception rates before switching off the old path.

Deeper: moving an AI pilot into production.

6. The pre-rollout checklist

Concrete and scannable. If any of these is a no, fix it before the process goes live.

  • Is every AI action logged? Each calculation, draft, match and flag, with its inputs, the source versions read and the model version used.
  • Is there a clear human approval point before every consequential action? Issuing a call, finalising a NAV, accepting a KYC decision, releasing a payment, publishing a report.
  • Is maker-checker enforced by the system? The approver cannot be the preparer, and no one can configure the gate away without it being recorded.
  • Can you produce a complete audit trail for any case on demand? Exportable without preparation, covering inputs, AI actions, exceptions, approvals and overrides.
  • Are overrides attributed and reasoned? No untracked side channel, no shared account, no verbal approvals.
  • Does it work across the systems you already run? No migration required, no partial trail that stops at a system boundary.
  • Does every step have a named accountable owner? Roles and individuals, with escalation defined for unresolved exceptions.
  • Is failure behaviour defined? Source outages, malformed outputs and missed deadlines route to a person.
  • Is AI configuration under change control? Prompts, models and thresholds versioned, reviewed and reconstructable for past runs.
  • Can your operations team change the process? Regulatory and structural changes should be implementable in days by the people who run the process, not queued for engineering.

Running in production today

These patterns are in live use, not pilots. Next Matter runs regulated 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.

Put AI into one of your own processes

Bring a real capital call, NAV cycle or onboarding process and we will walk through how it runs with AI agents, maker-checker approvals and a complete audit trail.

Book a demo