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. 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
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.
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.
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.
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.
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.
Unclear accountability
During integration, roles move. Approval matrices that name individuals rather than roles break immediately and quietly.
Email as the join
Wherever the two estates meet, work falls into mailboxes and spreadsheets. That gap is exactly where the audit trail stops.
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.
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.
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
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
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
The mechanics of the NAV side, including reconciliation and sign-off, are covered in AI agents for capital calls and NAV reporting and speeding 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 and governance and audit.
7. Unified interfaces for three audiences
Integration is judged by what each audience sees. Three interfaces, one process behind them.
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.
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.
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, team interfaces and the 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, Trade Republic, b2venture and Swan, and is SOC 2 Type II and ISO 27001 certified.
Building an audit-ready fund operations process
Governance, maker-checker and evidence by default
Putting AI into regulated financial workflows
Where AI acts, where humans approve, what gets logged
Migration isn't the fix
Why replacing the core system rarely resolves the bottleneck
Automating investor and LP onboarding
The short answer version of the onboarding mechanics
Integrating operations after a merger
The concise answer to this guide's question
Integrations
Connecting ledgers, CRMs, KYC providers and data rooms
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