Designing a Virtual Ledger for the Way Asset Managers Actually Work

The issue isn't that banking infrastructure doesn't work – it's that it might satisfy the bank’s internal needs, but may not always work well for the customers of the bank.

Asset managers juggle multiple funds, each with distinct investor commitments. Within each fund, there are properties with their own capital stacks: senior debt, mezzanine financing, equity positions. Money flows in from rent rolls, out to debt service, sideways for capital improvements. Every dollar needs to map back to an investor's capital account and tax reporting.

Every month, their finance teams export transaction CSVs from the bank, map them manually to properties and funds in spreadsheets, reconcile discrepancies, then regenerate investor statements. One property acquisition throws off the whole model. A simple question like "what's our actual cash position across all New York properties?" requires pulling data from six different accounts and hoping nothing got miscategorized.

Banks aren't thrilled about this either. Their relationship managers watch clients struggle, then lose deals to competitors promising "better technology" (usually just a slightly less clunky version of the same thing). But their core banking systems would take years and millions to overhaul.

So both sides are stuck.

The Virtual Account Approach

The big banks have been working on this. J.P. Morgan, Bank of America, and others offer Virtual Account Management (VAM) solutions—sub-ledger accounts linked to traditional physical accounts. Each virtual account gets a unique identifier, letting corporate clients assign them to subsidiaries, departments, or projects for tracking and reconciliation.

The appeal is clear: rationalize dozens of physical accounts into one VAM network, get better cash visibility, automate reconciliation. For treasury teams managing receivables and payables across multiple entities, it's a real improvement.

But there's a gap between what VAM solves and what asset managers need.

VAM is built for corporate treasury—think multinational companies coordinating cash across subsidiaries, or platforms handling payments on behalf of clients. The structure is still fundamentally account-based. You can create virtual accounts faster (Bank of America promises 24-hour setup), but you're still organizing around accounts, just more of them.

Asset managers don't need more accounts. They need a ledger that mirrors their mental model: properties rolling up to funds, funds rolling up to portfolios, with each level having its own capital structure, investor classes, and distribution waterfalls.

The Real Estate Software Layer

On the other side, there's specialized software for real estate fund management—Yardi, AppFolio, LemonEdge, Fundwave, Agora. These platforms understand asset management workflows. They automate waterfall calculations, capital calls, distributions, and investor reporting. They speak the same language that investors speak – carried interest, promote structures, IRR tracking, etc.

One firm cut their quarterly distribution process from seven weeks to two by moving to Yardi. Another company reduced reconciliation time by 73% after integrating their expense management with automated banking.

But these platforms sit on top of traditional banking infrastructure. They solve the accounting and reporting problems by building sophisticated middleware that translates between how asset managers think and how banks operate. The actual movement of money—the wires, the ACH transfers, the holds—still happens in the banking layer, where accounts are accounts and complexity lives in Excel.

What's Missing

Here's the thing neither approach fully solves: real-time, automated fund flows based on the asset manager's actual rules.

When rent comes in for a property, it should automatically flow through the predefined waterfall—debt service first, then reserves, then distributions according to each investor's priority and ownership percentage. Not as a scheduled batch process that runs overnight and might fail if something's misconfigured. Not as a manual review where someone checks 47 transactions before approving distributions. Just... automatically, because that's what the fund documents say should happen.

The virtual account systems give you better visibility, but you're still manually orchestrating the flows. The real estate software calculates what should happen, but you're still executing it through traditional banking rails.

A true solution would combine both: a programmable ledger that speaks the language of investors, understands projects, properties, and fund structures natively (not as a layer on top of accounts), with direct control over the banking infrastructure underneath. Define your hierarchy once—these properties belong to this fund, these investors have these priority levels—then let the system handle it.

At Hudson, we've been building toward this—virtual subledgers that sit between the banking layer and the asset manager's mental model, with rules engines that automate the conditional flows. The goal is to let banks offer this infrastructure to their commercial clients without requiring them to rip out their existing systems.

The Awkward Middle Ground

Most asset managers are stuck in an awkward middle: powerful accounting software that automates calculations, sitting on top of banking infrastructure that still requires manual intervention.

They've eliminated some spreadsheets. They've automated some reports. But they're still spending hours each month on the connective tissue between systems—making sure the capital call that their software calculated actually gets wired correctly, confirming that distributions match what the waterfall said should happen, explaining to investors why something took three days longer than expected.

The real opportunity isn't just in building better virtual accounts or better fund accounting software. It's in collapsing the gap between them—creating infrastructure where the accounting logic and the money movement happen in one place, with the asset manager's organizational model as the starting point, not an afterthought.

Banks that figure this out won't just retain clients. They'll become genuinely useful infrastructure for how modern capital actually moves. Asset managers who push for it won't just save their finance teams 40% of their time. They'll get real-time visibility into their entire capital structure without manual reconciliation.

The question isn't whether someone will build this. It's whether banks will build it, or whether they'll keep losing sophisticated clients to whoever does.

A $2 million rent payment comes in. The software calculates the split in seconds. Then three people spend hours actually moving the money.

Splits, Fees & Flows: How a Rules Engine Can Reshape Asset Manager Operations

Here's what happens at most asset management firms when money hits an account:

The fund accounting software immediately knows what to do with it. Yardi or Juniper Square or whatever platform they're using calculates the waterfall: debt service gets $800K, operating reserves need $300K, investor distributions total $900K split across twelve different accounts according to ownership percentages and priority levels.

But the actual money movement isn’t automated.

So someone exports the distribution schedule. Someone else logs into the bank's wire platform and manually keys in twelve separate transfers. A third person reviews and approves each one. If it's month-end and there are 500 properties, this process might involve hundreds of manual transfers. The finance team works late. Distributions go out three days later than planned. Investors email asking where their money is.

This isn't incompetence. It's just a gap in the infrastructure—the software that knows what to do can't talk to the infrastructure that can actually do it.

Why the Gap Exists

The fundamental problem isn't calculation—fund accounting software has solved that. The problem is that banking infrastructure and fund accounting software live in separate worlds.

Your Yardi system knows exactly how a property's waterfall works: debt service first (fixed monthly amount), then operating expenses up to budget, then reserves if below threshold, then preferred equity holders getting their 8% return, then remaining cash split 70/30 between GP and LP based on whether hurdle rates have been hit.

It can model this perfectly. Run scenarios. Generate reports. Show you exactly what should happen when that $2 million rent payment comes in.

But it can't initiate the wire to the debt servicer. Can't trigger the ACH to investors. Can't even automatically move money between accounts at the same bank.

So someone has to bridge the gap manually. They export the distribution schedule from the accounting system, then recreate those same transactions in the banking system. It's double entry in the worst way—not for accounting purposes, but because two systems that should seamlessly communicate, simply don't.

When something changes—a loan refinances, an investor structure shifts, a new property gets added— someone still needs to manually execute every transaction the new structure requires. The logic and the execution stay disconnected.

What Rules Engines Actually Solve

A rules engine, in this context, isn't about calculating what should happen—fund accounting software already does that well. It's about connecting that calculation directly to the banking infrastructure so the execution happens automatically.

The closest thing most firms have to this is their fund accounting software with banking integrations. Yardi has payment features. Juniper Square added distribution automation. Carta offers some payment capabilities. But these integrations are typically limited: they can initiate transfers, but often with constraints around timing, approval workflows, or which banks they work with. The sophistication varies dramatically.

Some firms have built custom automation. Python scripts that read from their accounting system and make API calls to their bank. Zapier workflows that trigger transfers based on system notifications. It works, until it doesn't—someone leaves and takes the institutional knowledge with them, or an API changes and breaks the integration, or the bank's rate limits cause a transfer to fail silently and nobody notices for a week.

What's missing is a durable bridge that sits between the accounting logic and the banking infrastructure. Something that can take the distribution schedule that Yardi calculated and automatically execute every transfer, with proper error handling, audit trails, and exception management built in.

The Enterprise Approach

Large family offices and institutional investors sometimes solve this with Treasury Management Systems (TMS). These are heavyweight platforms—Oracle, SAP, ION—that integrate with banks and provide workflow automation for cash management. They can handle complex payment routing, automate reconciliation, and maintain detailed audit trails.

But TMS platforms are expensive (seven figures or more in licensing and implementation) and built for corporate treasury operations—multinational companies managing liquidity across dozens of entities and currencies. They're optimized for forecasting, FX hedging, and working capital management.

Asset managers need something different. They don't need to forecast intraday liquidity or hedge currency positions across 40 countries. They need to automatically execute fund-specific logic every time money moves: this property's rent goes to these entities in this order, with these conditions, tracked at this level of detail.

A few specialized platforms have emerged. Juniper Square added payment automation features. Carta offers some distribution automation for private equity. But these still primarily sit in the fund accounting layer, with banking integrations that vary in sophistication.

What Good Implementation Looks Like

Imagine instead that the rules lived inside the banking infrastructure itself. Or more precisely, in a layer so tightly integrated with banking that it could act on transactions in real time.

Here's what that changes:

When rent comes in for a property, the system already knows the waterfall. It automatically allocates funds according to the predefined rules—debt service first (wire initiated), then reserves (if below threshold, transfer to reserve account), then distributions (calculated per investor ownership and priority, ACH initiated to each investor's account). No manual review needed unless something exceptional happens.

When a property closes and a large capital event occurs, the system executes the entire distribution waterfall in one atomic operation. Every investor gets exactly what the fund documents say they should get, simultaneously, with a complete audit trail showing exactly how each amount was calculated.

When fund documents change—say, an investor converts from preferred to common equity—the rules get updated once in the system. Every subsequent transaction automatically reflects the new structure. No spreadsheet updates across multiple tabs, no risk that someone executes a distribution using old logic.

At Hudson, this is what we've been building—rules engines that integrate directly with banking infrastructure, letting banks offer this capability to their asset management clients. The goal is to make the conditional logic as durable and reliable as the banking operations themselves.

But the technical capability is only part of it. The harder work is in implementation: translating fund documents into programmatic rules (by the way, we’ve automated this), integrating with existing accounting systems (we’ve partially automated this), and training teams to trust automated execution instead of manual review (we’re great at this).

Why This Hasn't Happened Faster

The technology exists. The pain is real. So why aren't more asset managers using rules engines?

Partly it's inertia. If your current process works—even if it's inefficient—there's risk in changing it. Finance teams are understandably conservative about automating something as critical as investor distributions.

Partly it's integration complexity. Asset managers use many systems: property management software, fund accounting platforms, investor portals, banking relationships with multiple institutions. Any automation solution needs to plug into all of this, and there's no standard architecture.

Partly it's the banks themselves. Most banking platforms weren't designed for programmable logic. They have APIs, sure, but those APIs are primitive: create transfer, check balance, get transaction history. Building a rules engine on top of those primitives is possible but fragile. What asset managers need is for the rules engine to be part of the banking infrastructure, not a layer they build on top.

Some banks are starting to get it. They see that winning sophisticated asset management clients means offering more than accounts and wires. It means offering infrastructure that works the way those clients think, with automation that reduces operational burden rather than just digitizing manual processes.

The Operational Leverage

Here's what changes when you have a proper rules engine integrated with banking:

Your finance team stops spending three days each month executing distributions. They spend an hour reviewing the automated execution and handling exceptions.

Your audit trail becomes bulletproof. Every distribution links back to the specific fund document clause and the exact calculation that produced it. Investor questions get answered in minutes, not hours of spreadsheet archaeology.

Your risk profile improves. Manual errors in splits or fee calculations don't happen because humans aren't doing the math. Regulatory reporting gets easier because the system already tracks everything at the level of detail you need.

And maybe most importantly, you can scale. Adding another property or another fund doesn't linearly increase your finance team's workload. The rules get configured once, then they just run.

This is the operational leverage that modern asset managers need. Not better spreadsheets. Not another dashboard. But infrastructure that executes their business logic automatically, reliably, and auditability.

Banks that build this will differentiate on capability, not just relationship. Asset managers who demand it will spend less time on operational plumbing and more time actually managing assets.