--- title: "Integrating Investor Onboarding, KYC and NAV After a Merger" description: "A practical guide to integrating investor onboarding, KYC/AML and NAV production after an asset management merger: orchestrating across the systems that survive, standardising KYC evidence, a three-phase onboarding-to-NAV pipeline, maker-checker approvals, and unified interfaces for investors, analysts and managers." lang: en json-ld: | { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://nextmatter.com/#organization", "name": "Next Matter", "legalName": "Daizy NM Limited", "url": "https://nextmatter.com", "logo": "https://nextmatter.com/__l5e/assets-v1/aab354c2-e169-46fe-8e9b-0e78438471d3/nextmatter-logo.svg", "description": "Next Matter is the orchestration platform for regulated financial operations - purpose-built for asset managers, fund administrators, and wealth and wealthtech firms, not a generic workflow tool - combining AI agents, your existing systems and human approvals with governance and a complete audit trail.", "sameAs": [ "https://www.linkedin.com/company/nextmatter", "https://www.daizy.com" ] }, { "@type": "WebSite", "@id": "https://nextmatter.com/#website", "url": "https://nextmatter.com", "name": "Next Matter", "publisher": { "@id": "https://nextmatter.com/#organization" }, "inLanguage": "en" } ] } --- [![Next Matter Logo](/__l5e/assets-v1/aab354c2-e169-46fe-8e9b-0e78438471d3/nextmatter-logo.svg)](/) - [Solutions](/solutions) [ grid\_view Solutions Overview Personas, capabilities, and proof ](/solutions)[ smart\_toy AI Orchestration Coordinate agents across your stack ](/solutions/ai-orchestration)[ library\_books Workflow Library Remix production-ready workflows ](/remix) Case Studies [ ![Ocorian](https://cdn.prod.website-files.com/69a7f71677d8045f0f2d982a/69a7f71677d8045f0f2da4e8_Ocorian_trustbar.svg) Ocorian 1,800 Employees • Fund Administrator ](/case-studies/ocorian)[ ![Trade Republic](https://cdn.prod.website-files.com/69a7f71677d8045f0f2d982a/69a7f71677d8045f0f2da4e9_traderpublic_trustbar.svg) Trade Republic 10M Customers • Online Trading Platform ](/case-studies/trade-republic)[ ![b2Venture](/__l5e/assets-v1/40232f5e-b66d-45f6-8d04-8be40304d172/b2venture-logo.png) b2Venture $800mn AUM • Venture Capital Firm ](/case-studies/b2venture)[ ![Swan](/__l5e/assets-v1/ef4919d4-3042-430f-b1a2-10b7da14c889/swan-logo.webp#lh=1500x401) Swan BaaS leader • Embedded Banking Platform ](/case-studies/swan) - [Platform](/platform) [ hub Platform Overview Built for Fund Operations ](/platform)[ build Workflow Builder Build long-running orchestrations ](/workflow-builder)[ smart\_toy AI & Automation Agents, models and guardrails ](/ai-and-automation)[ extension Integrations Core Ledger & Ecosystem Connectivity ](/integrations)[ verified\_user Governance & Audit Approvals and a full audit trail ](/governance-and-audit)[ shield Security SOC 2, ISO 27001, data residency ](/security) - Resources [ forum Ask a Technical Question Chat with the docs AI assistant ](https://help.nextmatter.com/docs/integrate-across-tools?assistant)[ campaign Opinions Perspectives from our team ](/opinions) [Sign in](https://app.nextmatter.com/login) [Talk to us](/book-a-demo) menu\_book Guide # Integrating investor onboarding, KYC and NAV after a merger How to bring two firms' onboarding, KYC/AML and NAV processes into one governed way of working - across the systems that survive the deal, with maker-checker approvals and a timestamped audit trail from day one of the combined process. ## Start with the process, not the platform The day a deal closes, the combined firm has two of everything operationally: two onboarding paths, two KYC standards, two NAV cycles, two approval matrices, two audit trails. The instinct is to fix that by choosing one core platform and migrating the other side onto it. That is a multi-quarter programme, and for the whole of it the operations teams keep running two processes by hand while the target operating model is still being decided. The practical alternative is to leave the surviving systems where they are and standardise the _process_ that runs across them first. One governed workflow for onboarding, one for KYC/AML, one for the NAV cycle - each reading from and writing to whichever ledger, CRM, KYC provider or data room applies to that fund, entity or client segment. Consolidation of the underlying systems can then happen on its own timeline, without the combined firm running two uncontrolled processes in the meantime. We make the full case for that sequencing elsewhere, so this guide will not re-argue it: see [Migration isn't the fix](/opinions/legacy-platform-trap). What follows is the mechanics. ## 1\. The orchestration layer, concretely One process layer sits above both estates. Nothing is ripped out; each side's systems remain the system of record for what they already hold. Post-merger orchestration Acquirer Fund accounting / ledger Acquirer CRM and investor register Target Second ledger and NAV pack Target KYC provider and data room ↓  ↓  ↓  ↓ Orchestration layer One governed process across both estates Data pulled from each source at a known version and timestamp, checks run once against a single standard, exceptions routed with context, approvals enforced before anything is issued or booked. Single onboarding path One KYC standard Maker-checker gates Timestamped audit trail ↓  ↓  ↓ Investors One onboarding and document experience Operations One queue across both books Oversight One control and evidence record The test of the design: an investor onboarded into a legacy target fund and one onboarded into an acquirer fund should follow the same steps, meet the same evidence standard and leave the same shape of record - even though the systems behind them differ. ## 2\. Where the friction actually shows up Four failure points account for most post-merger operational pain in onboarding, KYC and NAV. Name them explicitly before designing the target process. rule #### Two evidence standards The same investor type is verified to different depths on each side. Until one standard is written down and enforced, every file is arguable at the next inspection. difference #### Duplicate investors The same LP appears in both registers under different identifiers, with different documents and refresh dates. Deduplication is an operational process, not a data migration task. schedule #### Divergent NAV calendars Different valuation days, cut-offs, sign-off roles and pack formats. Consolidated reporting inherits the slowest and least evidenced of the two. groups #### Unclear accountability During integration, roles move. Approval matrices that name individuals rather than roles break immediately and quietly. mail #### Email as the join Wherever the two estates meet, work falls into mailboxes and spreadsheets. That gap is exactly where the audit trail stops. gavel #### Two regulatory footprints Different jurisdictions, depositaries and reporting obligations now sit in one firm. The combined process has to satisfy the strictest of them, per fund. ## 3\. Standardising KYC and AML verification Pick one standard for the combined firm, per investor type, and make the workflow enforce it. The point is not that the two sides were wrong; it is that a single, written, system-enforced standard is the only way to answer "how do you verify this investor type" with one sentence. Investor type Identity and ownership Screening Refresh cycle Approval Individual / HNW Government ID, proof of address, source of wealth where thresholds apply Sanctions, PEP and adverse media at onboarding and on change Risk-based: standard vs enhanced Analyst prepares, compliance approves Corporate / institutional Incorporation documents, ownership structure, UBO identification and verification Entity and UBO screening, jurisdiction risk Risk-based, plus on material structure change Analyst prepares, compliance approves; enhanced cases escalate Fund of funds / nominee Regulatory status, reliance and intermediary arrangements evidenced Entity screening plus periodic assurance on the intermediary Aligned to the intermediary's own cycle, evidenced Compliance approves the reliance basis, not only the file Trust / partnership Constitutive documents, controlling parties, beneficiaries in scope Controlling party and beneficiary screening Risk-based, typically enhanced Compliance approves with documented rationale High-risk / enhanced Full enhanced due diligence pack, source of funds and wealth Enhanced screening plus ongoing monitoring Shortest cycle applied by the combined policy Second-line sign-off in addition to compliance Three rules make this survive contact with an integration. First, express the standard as workflow steps and required evidence, not as a policy PDF, so an incomplete file cannot advance. Second, hold the risk rating and its rationale in the record, not in someone's head. Third, apply the standard prospectively to all new business immediately, and remediate the inherited back book on a risk-ranked schedule rather than all at once. Ongoing refresh mechanics are covered in [automating periodic KYC/AML refresh](/answers/automate-periodic-kyc-aml-refresh). ## 4\. The onboarding-to-NAV pipeline in three phases One pipeline, from the investor's first submission to the figure landing in the ledger and the NAV cycle. Each phase has a defined output and a defined control point. 1 #### Portal ingestion The investor or their adviser submits once, into one interface, regardless of which legacy entity the fund came from. - Subscription documents, entity details and supporting evidence captured in structured form - Completeness and format validated at the point of submission - Duplicate check against both legacy registers before a new record is created - Chase and re-submission handled in the same thread, not by email Automated 2 #### Compliance and AI engine Checks run once, against the single combined standard, whichever side the investor came from. - Document extraction and cross-checking against submitted data - Sanctions, PEP and adverse media screening; ownership and UBO resolution - Risk rating proposed with its reasoning attached - Anything ambiguous raised as an exception with full context, not left to a queue - Compliance approves the file and the rating before it can proceed Automated Human approval 3 #### Ledger and NAV sync The approved investor is written into the correct surviving system and joins the NAV cycle on its published calendar. - Register and ledger updated in the system that owns that fund - Commitment, share class and fee terms reconciled against the subscription pack - Position feeds into the NAV cycle; breaks raised as exceptions with context - NAV sign-off gated by maker-checker before publication or distribution Automated Human approval The mechanics of the NAV side, including reconciliation and sign-off, are covered in [AI agents for capital calls and NAV reporting](/guides/ai-agents-capital-calls-nav-reporting) and [speeding up NAV production and oversight](/answers/speed-up-nav-production-and-oversight). ## 5\. Choosing the right layer: CLM, VDR and orchestration Most combined firms already own tools in two adjacent categories, and inherit a second copy of each in the deal. They solve different problems, and neither category is designed to be the process layer across both estates. Category What it is built for Typical post-merger role What it does not resolve on its own Client lifecycle management (CLM) Structured client and investor data, KYC case management and regulatory rule sets within its own model Remains the KYC system of record on one or both sides; a source and destination for the orchestrated process Two instances with different configurations still produce two standards until one process governs both Virtual data room (VDR) Secure document exchange, permissions and access records with counterparties and investors Continues to hold and share documents; referenced by the process rather than replaced Document access history is not a record of who checked what, who approved it, or why Orchestration layer Running the end-to-end process across systems: sequencing, checks, exceptions, approvals and evidence The single governed path over both estates while consolidation happens underneath It is not a ledger, a KYC data vault or a document repository, and should not try to be Evaluate the specific products in your combined estate on their current documentation and your own configuration, not on category assumptions - implementations of the same product vary widely between two firms. What is fixed is the architectural point: whichever CLM and VDR survive, something has to own the process that runs across them, and the audit trail that comes out of it. ## 6\. Maker-checker and the combined audit trail Integration periods are when control records are weakest: people change roles, temporary workarounds appear, and approvals move to email "just for now". Enforce separation of duties in the system so that it cannot degrade while the org chart is in motion. Control point Maker Checker Recorded Investor file and risk rating Onboarding analyst, supported by automated checks Compliance, distinct identity, cannot be the maker Who, what was presented, when, decision and rationale Enhanced due diligence cases Compliance analyst Second-line or MLRO sign-off Escalation reason, evidence reviewed, outcome Register and ledger booking Operations analyst Team lead in the surviving entity Source values, target system, timestamp, approver NAV sign-off Fund accountant Oversight or fund controller Inputs as read, breaks and resolutions, approval before publication Process change during integration Operations owner making the change Named approver for that process Version, change made, reason, effective date ### What the record has to answer - **Who** - a named identity and role for every action, with automated and AI steps labelled as such rather than presented as human ones. - **What** - the data read from each legacy system, at the version and timestamp it was read. - **When** - per action, so sequence and timeliness can be tested across the integration period. - **Why** - the reason for each approval, exception resolution and override, held in the same record as the action. Applied consistently, this means a case from either legacy book, before or after cutover, can be reconstructed in the same way. Full detail in [building an audit-ready fund operations process](/guides/audit-ready-fund-operations) and [governance and audit](/governance-and-audit). ## 7\. Unified interfaces for three audiences Integration is judged by what each audience sees. Three interfaces, one process behind them. person #### Investor portal One place to submit, one set of requests, one status. The investor should not be able to tell which legacy firm administers their fund, and should never be asked twice for the same document. list\_alt #### Analyst queue One work queue across both books, with each item carrying its context, the checks already run and what is required next. No switching between two legacy tools to progress a single case. monitoring #### Manager dashboard Live view of volumes, ageing, exceptions and approvals across the combined firm, with the evidence one click behind each case rather than a reporting exercise. See [guest interfaces](/guest-interfaces), [team interfaces](/team-interfaces) and the [manager dashboard](/manager-dashboard) for how these are built. ## 8\. Target operating model checklist Work through this per process - onboarding, KYC/AML, NAV - during the first hundred days. - **One written standard per investor type**, agreed across both compliance functions and enforced by the workflow rather than by memory. - **A named role, not a person, at every approval gate**, so that role changes during integration do not break the control. - **A single intake for new business** from day one, even while the back book remains split. - **Duplicate investor detection** across both registers before any new record is created. - **A published NAV calendar per fund**, with cut-offs and sign-off roles explicit, and a plan for converging formats. - **Exceptions routed with context and owners**, never parked in a shared mailbox during the transition. - **Maker-checker enforced in the system**, with no bypass and every configuration change to a gate recorded. - **One evidence record per case**, spanning both estates, exportable on demand rather than assembled for an audit. - **Risk-ranked remediation plan** for the inherited back book, with progress visible to compliance. - **Change ownership with operations**, so the process can be adjusted in days as the target model settles, with each version recorded. - **The strictest applicable obligation applied per fund**, given the combined firm's wider regulatory footprint. If the combined firm can pass an inspection on a case from either legacy book, chosen at random, without preparing anything first, the integration is working - regardless of how much system consolidation remains. ## Where to go next Next Matter runs regulated fund and client operations in production at [Ocorian](/case-studies/ocorian), [Trade Republic](/case-studies/trade-republic), [b2venture](/case-studies/b2venture) and [Swan](/case-studies/swan), and is [SOC 2 Type II](https://app.drata.com/trust/d62cb1a1-96df-4741-8058-97ecbc4ff345/) and ISO 27001 certified. [ Building an audit-ready fund operations process Governance, maker-checker and evidence by default Read ](/guides/audit-ready-fund-operations)[ Putting AI into regulated financial workflows Where AI acts, where humans approve, what gets logged Read ](/guides/ai-in-regulated-financial-workflows)[ Migration isn't the fix Why replacing the core system rarely resolves the bottleneck Read ](/opinions/legacy-platform-trap)[ Automating investor and LP onboarding The short answer version of the onboarding mechanics Read ](/answers/automate-investor-lp-onboarding)[ Integrating operations after a merger The concise answer to this guide's question Read ](/answers/integrate-operations-after-merger-acquisition)[ Integrations Connecting ledgers, CRMs, KYC providers and data rooms Read ](/integrations) ## Walk through your own integration Bring one process from each side of the deal - an onboarding path, a KYC standard, a NAV cycle - and we will map the single governed version across both estates. [Book a demo](/book-a-demo) ![Next Matter](/__l5e/assets-v1/aab354c2-e169-46fe-8e9b-0e78438471d3/nextmatter-logo.svg) The agentic operating system for modern financial services. A Daizy company. [](https://www.linkedin.com/company/nextmatter) Case studies - [Ocorian](/case-studies/ocorian) - [Trade Republic](/case-studies/trade-republic) - [Swan](/case-studies/swan) - [b2Venture](/case-studies/b2venture) - [All case studies](/case-studies) Solutions - [Solutions overview](/solutions) - [AI Orchestration](/solutions/ai-orchestration) - [Workflow library](/remix) Platform - [Platform overview](/platform) - [Workflow Builder](/workflow-builder) - [AI & Automation](/ai-and-automation) - [Integrations](/integrations) - [Governance & Audit](/governance-and-audit) - [Security](/security) - [System status](https://status.nextmatter.com/) Capabilities - [AI Financial Reporting](/ai-financial-reporting) - [Operational Intelligence](/operational-intelligence) - [Exception Handling](/exception-handling) - [Team Interfaces](/team-interfaces) - [Guest Interfaces](/guest-interfaces) - [Manager Dashboard](/manager-dashboard) - [Builder Toolbox](/builder-toolbox) Company - [About](/about) - [Careers](/careers) - [Opinions](/opinions) - [Answers](/answers) - [Documentation](https://help.nextmatter.com/docs/integrate-across-tools) - [Ask a Technical Question](https://help.nextmatter.com/docs/integrate-across-tools?assistant) Certified Secure [![AICPA SOC 2 for Service Organizations](https://cdn.prod.website-files.com/69a7f71677d8045f0f2d982a/69a7f71677d8045f0f2da55f_logo_SOC2.svg)](https://app.drata.com/trust/d62cb1a1-96df-4741-8058-97ecbc4ff345/) [![GDPR compliant](https://cdn.prod.website-files.com/69a7f71677d8045f0f2d982a/69a7f71677d8045f0f2da561_logo_GDPR.svg)](https://app.drata.com/trust/d62cb1a1-96df-4741-8058-97ecbc4ff345/) [![SOC 2 Type 2 compliant 2025](https://cdn.prod.website-files.com/69a7f71677d8045f0f2d982a/69eb389eff4de1586e1d2f14_Daizy%20SOC%202%20Type%202.png)](https://app.drata.com/trust/d62cb1a1-96df-4741-8058-97ecbc4ff345/) © 2026 Daizy NM Ltd. All rights reserved. A Daizy company [Terms of Service](/terms-of-service) [Privacy Policy](/privacy-policy) [Data Processing Agreement](/data-processing-agreement) Solutions - [Solutions Overview](/solutions) - [AI Orchestration](/solutions/ai-orchestration) - [Workflow Library](/remix) Case Studies - [Ocorian](/case-studies/ocorian) - [Trade Republic](/case-studies/trade-republic) - [b2Venture](/case-studies/b2venture) - [Swan](/case-studies/swan) Platform - [Platform Overview](/platform) - [Workflow Builder](/workflow-builder) - [AI & Automation](/ai-and-automation) - [Integrations](/integrations) - [Governance & Audit](/governance-and-audit) - [Security](/security) Resources - [Ask a Technical Question](https://help.nextmatter.com/docs/integrate-across-tools?assistant) - [Opinions](/opinions) [Sign in](https://app.nextmatter.com/login) [Talk to us](/book-a-demo)