A fund manager running a main fund, a co-investment vehicle, and a separately managed account for an institutional LP has three distinct sets of LPs, three distinct return profiles, and three distinct reporting obligations. They may share borrowers across all three vehicles, with the same credit representing different position sizes and economics in each.
The reconciliation challenge this creates is not the same as reconciling a single vehicle against a servicer tape. It's a different kind of problem: how do you maintain position-level accuracy for each vehicle in isolation, while also maintaining the ability to aggregate across vehicles for a manager-level view, without conflating the two in ways that produce errors in either direction?
Most reporting tools were built for one of those two use cases. They can do vehicle-level aggregation, or they can do position-level detail within a vehicle. Very few were designed from the ground up for a use case where both are required simultaneously and where the two can't be traded off against each other.
The shared borrower problem
When the same borrower appears in multiple vehicles, the position record for that borrower exists in two places with potentially different terms. Consider a scenario where Fund I holds a $20M first-lien term loan to a borrower, and Fund III holds a $5M participation in the same credit from a different tranche. The borrower is the same. The underlying credit is the same. But the positions are not the same: different tranches, different seniority, different payment terms, potentially different covenant packages.
A system that tracks positions at the borrower level, rather than at the facility and tranche level, will aggregate these into a single borrower record and lose the vehicle-level distinction. The reconciliation will show the correct total exposure, but it won't show the correct position for Fund I or for Fund III independently. When Fund I's LP asks for a position-level view of Fund I, the answer will be wrong by the amount of the Fund III participation, or vice versa.
This is not a hypothetical edge case. In any portfolio with pro-rata participations, co-investments, or participation arrangements across vehicles, shared borrower positions are the norm, not the exception. The reconciliation model has to start from the assumption that multiple vehicles can hold different positions in the same credit, and that those positions must remain isolated from each other in the data model.
How vehicle isolation interacts with servicer tape delivery
The servicer tape problem compounds this. Many servicers deliver a single tape that covers all positions they administer for a manager, without vehicle-level segmentation. The tape records for a manager running three vehicles come in a single file, with a vehicle identifier field that may or may not be populated consistently.
When the vehicle identifier field is missing or inconsistent, as happens with some file-based servicers, the ops team has to apply vehicle attribution manually before running the reconciliation. That manual step is both the most error-prone part of the workflow and the part that is hardest to audit: if a position gets attributed to the wrong vehicle during the normalization step, the error may not surface until an LP asks a vehicle-specific question that produces a mismatch.
A robust normalization layer needs an explicit vehicle attribution rule for each servicer configuration: what field or fields in the tape record define the vehicle, what the expected values are, and what should happen when the field is absent or unrecognized. Those rules need to be tested against historical tapes before going live, not discovered when a tape delivers with a vehicle field that doesn't match the configured values.
The SPV and managed account case
The isolation problem becomes more acute when the vehicles include SPVs or separately managed accounts with their own fund administrator relationship. An SPV that uses a different fund administrator than the main fund may have its position records coming from an entirely different system, in a different format, on a different delivery schedule.
Reconciling across these vehicles requires normalizing the positions from different sources into a common schema, then running the cross-vehicle reconciliation against the normalized data. The normalization step is the same as for a multi-servicer problem; the additional complexity is that the cross-vehicle comparison has to respect vehicle-level isolation throughout.
A common mistake in building this workflow is to normalize all positions into a single pool first, then try to re-segregate by vehicle for reporting purposes. That approach loses the isolation guarantee. If the normalization step introduces any ambiguity about vehicle attribution, the re-segregation step will propagate that ambiguity into the reporting outputs. The correct approach is to normalize each vehicle's positions independently, then bring them together only at the aggregation layer, where the vehicle tag is preserved on every record.
What position-level isolation actually requires in the data model
Position-level isolation, in the data modeling sense, means that every position record carries a vehicle identifier that is set at ingestion and propagated through every downstream operation. The vehicle identifier is not a filter applied at the reporting layer. It's a structural property of the position record that is present in the normalized schema, in the reconciliation run output, in the exception flags, and in the stored position history.
This means that a reconciliation break affecting a position in Fund I is categorized as a Fund I break, not as a generic portfolio break. The exception workflow for that break is triggered for Fund I operations, not for a combined portfolio operations queue. When the break is resolved, the resolution is recorded against the Fund I position, and it doesn't affect the Fund III record for the same borrower.
The aggregation view, the manager-level exposure report that shows total exposure to each borrower across vehicles, is built by querying the isolated position records and summing across vehicles. That aggregation can only produce correct results if the underlying vehicle-level records are accurate. If the vehicle-level reconciliation was accurate, the aggregation is accurate. If it wasn't, the aggregation is wrong in ways that can be hard to detect because the aggregate number may be plausible even when the vehicle-level breakdown is not.
The IC reporting implication
For a manager running multiple vehicles with different LP bases, the IC reporting implication of position-level isolation is direct: each vehicle needs an IC report that reflects only that vehicle's positions, reconciled at the position level, not a slice of an aggregated manager-level view.
If the manager-level position pool is the primary data store and vehicle-level reports are produced by filtering it, then the quality of each vehicle's report depends entirely on how clean the vehicle attribution was in the initial normalization. A misattributed position will appear in the wrong vehicle's IC report, or appear in both, or not appear in either. Any of those outcomes is an IC data quality failure with real consequences for LP confidence.
The right design has each vehicle's reconciled position record as the primary data store, with the manager-level view computed from it rather than the other way around. That design may require more storage and more computation, because you're maintaining redundant data about shared borrowers across vehicles. The redundancy is the point: it is what preserves the isolation guarantee.
We built Atrium with vehicle-level isolation as a core structural property of the position model, not as a reporting filter, because the funds we work with all have this problem to some degree. Even a single-vehicle fund often has a co-investment vehicle or a managed account alongside it. The isolation model is not a constraint on the reporting layer; it's what makes the reporting layer trustworthy across vehicle boundaries.