The standard explanation for why month-end close takes so long at funds that hold real-world assets is that the assets are illiquid, complex, or require special handling. Those things are true. They are not, however, why the close takes eleven days. The close takes eleven days because the ownership data is not in the right shape when the closing process starts, and getting it into shape takes most of that time.
We spent a year talking with back-office and fund administration teams before building OpenAssets. The pattern we heard consistently was: the actual close work, the NAV calculation, the allocations, the reports, takes a day or two once the data is reconciled. The ten days before that are spent getting the data into a state where the close can happen. That distinction is important because it changes where the automation effort should be focused.
What Is Actually Happening During Those Ten Days
A typical pre-close timeline at a mid-size asset manager holding a mix of tokenized real estate positions, private credit, and infrastructure assets looks roughly like this.
Days 1 through 3: custodian data collection and initial reconciliation. The operations team pulls position reports from each custodian. For larger managers, this means pulling from three to eight separate custodian relationships, each with its own export format, timing, and identifier convention. The position data from each source gets loaded into a spreadsheet or a portfolio management system and compared against the internal ledger. This is mostly manual work even when there are downstream systems involved, because each custodian's export has to be massaged into a form the comparison can process.
Days 3 through 6: break investigation. The initial comparison produces a list of discrepancies. Most of them are explainable: timing breaks where a trade settled after the custodian's snapshot, identifier mismatches where the same instrument appears under different codes, corporate action adjustments that one custodian has applied and another has not. The operations team works through these one by one, categorizing them, reaching out to custodians for confirmation where needed, and updating records.
Days 6 through 9: exception escalation and management sign-off. Breaks that could not be resolved in the investigation phase get escalated. Some go to the custodian. Some go to the fund's legal or compliance team if there is a question about how an ownership transfer should be recorded. Management sign-off on the reconciled position record requires someone with oversight authority to review the open items and formally approve the close. This review cannot happen until the break list is mostly clear, which means it waits until the investigation phase is complete.
Days 9 through 11: final calculations and reporting. With reconciled positions, the close calculations run. This is generally the fastest phase, and it is the one that most automation investment has historically targeted. It is also the phase that benefits least from more automation, because it was already mostly automated.
Where a Canonical Data Layer Changes the Timeline
The time compression that a canonical data layer enables is almost entirely in days 1 through 6, not days 9 through 11. The specific changes are:
Custodian data collection becomes continuous rather than month-end batch. When feeds are normalized into a canonical schema at ingest, positions from each custodian are available in a comparable format throughout the month rather than requiring a manual assembly exercise at close. The reconciliation gap between the canonical view and the internal ledger is visible daily, which means surprises at month-end are smaller and the resolution work is distributed rather than concentrated.
Break investigation time falls because breaks are classified at detection rather than at investigation. When the reconciliation engine knows the difference between a timing break, an identifier break, and a quantity discrepancy, it routes each break type differently. Timing breaks that resolve within the expected settlement window do not need to enter the investigation queue at all. Identifier breaks that have a known resolution rule get resolved automatically. The investigation queue that reaches a human is smaller, and each item in it has enough context attached to support investigation rather than requiring the analyst to reconstruct what happened.
Management sign-off can be decoupled from the close cycle. When the reconciled position view is continuously maintained rather than produced as a month-end artifact, management review of specific items can happen throughout the month rather than being concentrated in a single sign-off window. High-value positions, complex instruments, or items that exceeded exception thresholds can be reviewed as they arise. By the time the formal month-end close happens, most items have already been reviewed.
The Realistic Outcome: Compression, Not Elimination
We want to be honest about what a canonical data layer can and cannot deliver. The commonly cited benchmarks from back-office automation vendors describe close cycles of two to three days. Those benchmarks are achievable, but they reflect implementations where the canonical data layer was in place before the first month-end close ran, where the operations team adapted their workflows to use continuous reconciliation rather than batch, and where exception handling procedures were redesigned alongside the technology.
Dropping a canonical reconciliation layer into an existing back-office operation without changing the surrounding workflows produces a smaller gain. The data assembly phase gets faster. But if the operations team still does most of its break investigation in the week before close, and management sign-off still happens in a concentrated window at end of month, the close cycle compresses by a few days rather than by a factor of four or five.
The full compression requires three things in combination: a canonical data layer that provides continuous reconciliation, a team workflow that distributes exception investigation across the month rather than batching it, and a governance process that allows ongoing management review rather than requiring a single formal close event. Technology is one of the three. The process changes are at least as important.
Specific Scenarios Where This Matters Most
The case for compressing the close cycle is strongest in two specific situations that are increasingly common as real-world asset managers grow their portfolios.
The first is when the portfolio spans multiple asset classes with different custody arrangements. A fund that holds infrastructure assets held directly, tokenized real estate positions held through a digital asset custodian, and private credit positions held through a traditional prime broker has three separate reconciliation processes that need to complete before the close can start. Each of these is on a slightly different timeline and uses different data formats. The month-end bottleneck compounds across each custody relationship.
The second is when the fund has regulatory reporting obligations tied to period-end positions. SEC and CFTC reporting requirements often attach to positions as of specific dates. If the close cycle takes eleven days and the regulatory reporting deadline is five days after period end, the reporting deadline is being met by submitting preliminary data and then amending later. Compressing the close cycle converts what is currently an amendment-heavy process into one that produces accurate first submissions.
Starting Points That Are Not Overwhelming
The initial lift for continuous reconciliation does not have to be a full-scale data infrastructure project. The highest-value starting point is almost always getting custodian data into a single comparable format before the month-end reconciliation process begins. This can be done at the feed ingestion layer without touching the internal ledger or the portfolio management system. The result is that the data assembly phase at month-end goes from three days to hours, which buys the team time for the investigation phase and does not require changing any downstream systems.
That first step is also the foundation for everything else. Once custodian data is flowing in a normalized format continuously, the break detection logic, the classification engine, and the continuous review workflow can be built incrementally rather than requiring a single large implementation project. The eleven-day close cycle did not develop overnight, and it does not have to be fixed overnight either.
See OpenAssets in practice
Request early access to see how the platform handles your specific custody structure and reconciliation workflow.
Request Early Access