Tokenized Real Estate Portfolio Management
A unified data architecture and reporting framework for a multi-SPV tokenized real estate vehicle: aggregating performance across dozens of legally separate entities without losing the SPV-level detail investors actually need.
| Asset class | UK and US residential real estate, tokenized via NFT/SPV structure |
| Portfolio scope | Multi-site, multi-SPV structure across several US and UK regions |
| Engagement type | Portfolio data architecture, performance analytics, reporting framework |
Engagement context
The client operated a tokenized real estate investment vehicle structured around individual Special Purpose Vehicles (one per property or property cluster) with ownership represented by blockchain-based tokens (NFTs). Investors held tokens corresponding to fractional or full ownership of specific SPVs. The portfolio spanned multiple US and UK regions, multiple property types (terraced houses, flats, HMOs, single-family homes), and a range of acquisition vintages.
The engagement addressed a core operational challenge of this structure: while the SPV/token model creates clean legal and ownership boundaries, it also fragments performance data across dozens of separate entities. The client needed a unified portfolio view that could aggregate performance across all SPVs, surface underperformers and maintenance liabilities at the property level, track rental yield against acquisition cost and current valuation, and produce investor-facing reporting that respected the SPV-level ownership structure while still enabling portfolio-level insight.
Data architecture
SPV-level data layer. The foundation of the model was a per-SPV data record capturing: acquisition date and cost; property type and bedroom count; current estimated value, updated on a defined cadence; monthly rental income; occupancy status; outstanding maintenance liability; and mortgage or financing structure where applicable.
Each SPV record was tagged with region, property type, acquisition vintage, and token issuance data; enabling filtering and aggregation across any combination of these dimensions without restructuring the underlying data.
Portfolio aggregation layer. This layer combined SPV-level records into a portfolio summary view: total portfolio value, total monthly rental income, gross yield by region/property type/vintage, occupancy rate across the portfolio, and capital deployment versus current value by cohort.
The aggregation model was specifically designed to handle the structural heterogeneity of the portfolio (properties acquired at different times, in different markets, under different financing structures) without obscuring the SPV-level detail individual investors actually needed for their own holdings.
Performance metrics
The core metrics tracked at both SPV and portfolio level (among many others):
- Gross yield — annual rental income as a percentage of acquisition cost
- Net yield — gross yield adjusted for management fees, maintenance reserves, and financing costs
- Capital growth — current estimated value versus acquisition cost, tracked by vintage cohort
- Cash-on-cash return — net annual cash flow as a percentage of equity deployed
- Occupancy rate — percentage of units generating rental income in any given period
Reporting framework
Portfolio-level reporting, built for the management team, included: a snapshot of total portfolio performance against target metrics; regional performance breakdowns; identification of underperforming assets against peer comparisons within the portfolio; and cash flow projections based on current occupancy, rental rates, and property expenses.
Investor-level reporting was structured around individual token holdings: the performance of each SPV in which the investor held tokens; rental income attributable to their specific token position; estimated current value of that position; and distributions received or accrued. Investor reporting respected the SPV ownership structure precisely — each investor’s view scoped strictly to their actual holdings — while still providing enough portfolio context for investors with positions across multiple SPVs to understand their relative performance.
Asset management flags. The model included a flag layer identifying assets requiring attention: properties with occupancy gaps exceeding a defined threshold, properties with maintenance costs running above budget, SPVs with yield below the portfolio mean by more than a defined margin, and properties approaching refinancing or tax events.
Technical implementation
The model was implemented in shared Google Sheets, cross-structured to Tableau with structured data tables, charts, and maps enabling pivot-based reporting across every dimension. The SPV register served as the master data source — every aggregation and reporting tab pulled directly from this register, ensuring a single source of truth for all figures across the entire portfolio.