Apers_

ESSAY

REDI: The Most Promising Real Estate Data Standard I've Seen, and Why It Deserves Your Attention

June 18, 2026 · 8 min

Introduction

Every few years, someone in institutional real estate tries to standardize how GPs report data to LPs. The Real Estate Data Initiative (REDI) is the most promising attempt I've seen, and what makes it different is who's driving it.

REDI is LP-led. The people writing the spec are the people who suffer most from the current mess of bespoke templates, PDF reports, and fragmented reporting standards. That single fact changes the odds.

I want to talk about what REDI is, what it means for allocators and GPs today, and what I think the honest path forward looks like. Full disclosure: I've spoken with members of the committee behind the scenes. Jen Allard and Michael McGowan, in particular, have been driving this with what I can only describe as love of the game. A small team, working nights and weekends, trying to fix something that has frustrated the industry for two decades. That context matters when you evaluate what they've shipped.

What REDI Actually Is

REDI is a data dictionary and a set of collection templates. It standardizes about 80% of the fund-, asset-, and loan-level fields that LPs commonly request for quarterly reporting and ongoing monitoring, with explicit crosswalks to NCREIF and INREV definitions. It ships as five Excel template variants (Open-End Funds for North America, Europe, and APAC; Closed-End Funds; Separately Managed Accounts) sharing one underlying schema.

REDI's v1 scope is quarterly reporting and monitoring, the kind of recurring data exchange typically agreed in LPA side letters. DDQs and onboarding documentation may follow in future versions, but they aren't in scope today. Knowing this matters. It tells GPs and allocators exactly which workflow REDI is asking to standardize first.

REDI is an additive structured export that sits alongside traditional PDF investor reporting. It does not replace NCREIF, INREV, or any existing reporting workflow. It gives LPs a clean, structured, comparable dataset they can load into their systems. That positioning lowers the switching cost for GPs and avoids the multi-year standards war that has killed similar efforts.

A Moment of Aligning Incentives

Real estate data standardization has come a long way. NCREIF built the foundation for US core fund reporting. INREV did the same in Europe, ANREV in APAC. PREA's Reporting Standards have shaped GP disclosure for over a decade. Each of these efforts moved the industry forward, and each reflected what was achievable given the constituencies driving them.

What's different about REDI is the seat at the head of the table. The committee is LP-led, with investors and consultants writing the spec directly. It's a natural next step. The earlier work established that standardization is possible and valuable; REDI is taking the baton and pushing it one layer deeper, with the data consumers driving field-level decisions. Incentives are getting more aligned, not less.

Real estate reporting standards by governance type, 1982 to 2025 LINEAGE Real estate reporting standards by governance type TIME 1982 NCREIF US fund benchmark Industry-led 2002 INREV European fund reporting Member association-led 2007 ANREV / PREA APAC + GP disclosure Industry-led 2025 REDI Fund + asset + loan LP-led committee First time data consumers write the spec. Apers_
Figure 1. Forty-three years of real estate reporting standards. Each prior effort moved the industry forward within the constituency that drove it. REDI is the first where the data consumer holds the pen.

A note worth saying out loud: the committee has done remarkable work for a small group operating on nights and weekends. A 374-field data dictionary. Immutable UIDs. Scope flags for five vehicle types. Full NCREIF/INREV crosswalk. Five working templates with built-in reconciliation. A glossary that defines terms unambiguously. Most well-funded vendor projects don't ship this much in their first year.

Implication for Allocators: Adopt Now

If you're an LP or consultant, my view is direct. Get on board.

The pioneers have absorbed the hardest part of the work. The field definitions are negotiated, the crosswalks to existing standards are in place, the templates exist, the governance is starting to form. Your marginal cost to join is low. Your marginal benefit is high, and it compounds, because every additional allocator requesting REDI applies pressure on shared GPs to deliver it. That's how the flywheel turns.

What to do is concrete: in your next side-letter cycle, request REDI as the format for quarterly reporting and monitoring, alongside (not in place of) your existing PDF report. You don't have to retire your bespoke template on day one. You just have to ask. The more LPs who do, the faster GPs build the pipe once and serve everyone.

That ask is the lever that flips REDI from a +1 burden into a -N consolidation for GPs. Only allocators can pull it. The committee can build the best schema in the world, but without LPs requesting it in side letters, it stays a PDF on a website.

Implication for GPs: Honest Assessment

I want to be straight with the GP side, because there's no point pretending the math is something it isn't.

Today, REDI is +1, not -N. No major LP has yet retired their bespoke template in exchange for a REDI submission. Adopting today means producing a REDI export in addition to everything you already do. The hours add up. I'm not going to dress that up.

The picture is changing faster than you might think. Several major institutional consultants have already committed to transitioning their quarterly reporting and monitoring templates to REDI in 2026. If your investors work with these consultants, and most institutional LPs do, the request is effectively already in motion. It will arrive through your next side-letter reporting cycle, not through a discrete LP-by-LP ask.

The trajectory matters. The schema is stable. The UIDs are immutable by design. The ETL mapping work you do now carries forward to v1.1, v1.2, and v2.0. The committee has been explicit that this is a multi-year adoption ramp, targeting 60-75% LP adoption within roughly three years.

Pragmatic posture for a GP CFO:

  1. Start mapping now. Map your internal data model to REDI fields. The exercise alone is valuable. It surfaces inconsistencies in your own reporting before anyone outside sees them.
  2. Run a pilot. Push one fund through the appropriate template end-to-end. You'll learn more in two weeks of doing than two months of debating.
  3. Engage the committee. The spec is still evolving. The committee is open to feedback, and I can attest to this personally. If something doesn't fit your fund structure, say so now while v1.x is being scoped.
  4. Plan to commit at your next reporting cycle. Don't wait for a particular LP to ask. With consultants already moving, the request is coming through side letters sooner than a wait-and-see posture anticipates. The CFOs who move first will look prepared when the calls come in. The ones who wait will be doing the mapping work under deadline pressure.

What v1 Didn't Get To

Every v1.0 ships with conscious scope decisions. A few I'd flag, in the spirit of constructive feedback:

  • Tenant-level rent roll data. REDI v1 captures fund- and asset-level lease metrics (occupancy, percent leased, weighted-average lease term) but not tenant-by-tenant rent rolls, lease expiry schedules, or top-tenant concentration. That deeper layer matters most for office and retail underwriting, and it's a natural extension for a future version.
  • Loan modeling. Equity-side loans are repeated in column blocks (Loan #1, Loan #2, etc.) within Asset Data, while standalone loan investments live in a properly normalized tab. Unifying those into a single child-table pattern would simplify both data entry and downstream ingestion.
  • FX snapshot. A single reporting-currency cell drives all translations via a hidden lookup. Adding a per-period FX snapshot would lock historical comparatives and prevent retroactive drift.
  • Override audit trail. The Review tab allows manual overrides of derived diversification figures, which is the right escape hatch. Pairing each override with a reason code and a timestamp would let LP data teams distinguish clean submissions from papered-over ones.

These are technical, well-understood, and squarely in the path of v1.1 and v1.2. None of them undermine the schema's foundation.

The Excel Question

The current delivery format is Excel: five workbooks with hidden lookup sheets and embedded formulas. It works. It also has real limits. Heavy files. Version sensitivity. Formulas that can break silently. A spec that effectively lives inside the artifact it's supposed to govern.

The natural evolution, and I suspect the committee already knows this, is to publish the schema as JSON or YAML as the source of truth, auto-generate the Excel templates from it, and ship a free server-side validator. That converts REDI from "another template" into "a standard with reference tooling." It's a known pattern in other data-standard worlds (FIBO, ISO 20022, FpML), and it's the inflection point between adoption among committee members and adoption across the industry. The current Excel is the v1 delivery vehicle, not the long-term answer.

The Harder, Longer-Term Questions

The technical issues will get solved. Two others won't, at least not automatically.

Governance durability. Committees are great at v1.0. They're harder at v3.0, when membership rotates, original conviction fades, and disagreements emerge about scope. What is the sustaining institution behind REDI five years from now? Does it become a foundation? Does it sit inside an existing body? Does it remain an independent committee with rotating chairs? Each has tradeoffs. NCREIF and INREV figured this out the hard way over decades. REDI will need to articulate its long-term home before adoption matures.

Licensing model. This is the most consequential decision the committee hasn't yet publicly resolved, as far as I can tell. The genuine tradeoff:

Model Pros Cons
Fully open-source (CC0, Apache, MIT) Maximum adoption velocity; vendors and GPs can build automation without legal review; fastest path to ecosystem tooling Fork risk. Multiple slightly different REDI dialects defeat the standardization premise
Permissive license with attribution Middle ground; common in data standards (FIBO, ISO 20022 derivatives) Mild adoption friction; needs an enforcement mechanism for "official" version
Paid license / membership-funded Funds a dedicated full-time team; prevents fragmentation; provides governance teeth Caps adoption rate; reintroduces the dynamic that slowed prior standards

Table 2. Licensing tradeoffs for a data standard at the critical-mass threshold.

My instinct: for a standard like REDI that lives or dies on hitting critical mass, open licensing is probably the right call, paired with a lightweight stewardship body that controls the "official" version and certifies conformance. That gives you adoption velocity without fork chaos. But this is the committee's decision to make, and the tradeoffs are real.

The deeper issue is that REDI has a threshold problem. Below ~60-75% LP adoption, it's +1 for GPs forever, a perpetual extra reporting burden. Above the threshold, it's the standard. There is no comfortable middle ground. Allocators are the only constituency who can push it across the line.

REDI adoption threshold: where +1 reporting burden flips to N-template consolidation ADOPTION DYNAMICS Per-GP reporting burden as a function of LP adoption THRESHOLD 60-75% 1.0× 1.5× 0 REPORTING BURDEN 0% 25% 50% 75% 100% LP ADOPTION today's bespoke template baseline TIPPING POINT Burden flips from +1 export to N-template consolidation +1 BURDEN REDI in addition to bespoke -N CONSOLIDATION REDI replaces bespoke templates Apers_
Figure 2. The threshold problem. Below ~60-75% LP adoption, REDI sits on top of every GP's existing bespoke reporting stack as an extra export. Above the threshold, the bespoke templates start to retire and REDI becomes the consolidating layer. There is no comfortable middle ground.

Bottom Line

REDI is the most promising real estate data standardization effort I've seen. The schema is good work. The LP-led governance, with consultants now actively transitioning their templates, fixes the structural problem that has slowed every prior attempt. The crosswalks to existing standards lower switching costs. The reconciliation built into the templates is more rigorous than what's typically caught at submission today. And the team behind it is doing this with a fraction of the resources a vendor or association would have thrown at it.

What's left is execution and adoption. The technical roadmap is tractable. The governance and licensing questions are real but solvable. The adoption flywheel is the hard part, and it's already starting to spin.

If you're an LP, go look at this. If you're a GP, start mapping. If you're a vendor in this space, the structured layer of institutional real estate reporting is being built right now, and you should be paying attention.

You can learn more, see the framework, and download the templates directly at the REDI project website.


Thanks to Jen Allard, Michael McGowan, Nicholas Russell, Tucker McCrabb, and the broader REDI committee for the work and for the conversations that informed this piece. Special thanks to Geoff Dohrmann. All views and any errors are my own.

Ready to try Apers?

Start using Apers today. No credit card required.

Start for Free