Immutability and FundGuard’s Data Model

“How does FundGuard maintain processed data?”

This is one of the frequent questions we get from prospective clients during discovery calls and RFP processes. The question relates to the critical data used to track changing values of portfolio, cash, and general ledger information.

The simple answer is this: FundGuard includes an immutable record-keeping methodology across all major accounting functions.

But what exactly does that mean? Once again, we turn to Peter Muldoon, FundGuard’s Product Strategy Director to explain.

Understanding Immutable Data and FundGuard’s Versioning Methodology

FG: First, just generally, what is immutable data? 

PM: Immutable data refers to data that cannot be changed once it is created. In the context of computing, immutability is a property assigned to data objects or values, indicating that they are unalterable. Once a value is assigned to an immutable object, it remains constant and cannot be modified. Instead of modifying an existing value, any operations or transformations performed on immutable data create new copies or derived versions of the data.

FG: What are the general benefits of immutability?

PM: Immutability offers several advantages in software development and data management:

• Predictability: Immutable data ensures that the value of an field remains constant throughout its lifetime. This predictability simplifies reasoning about the data and reduces the potential for unexpected changes or side effects.
• Consistency: Immutable data guarantees that the state of an field cannot be inadvertently modified, providing consistency across the different parts of the FundGuard data model.
• Versioning: Versioning refers to the practice of maintaining different versions of data (field values) over time. Immutable data simplifies versioning because each modification or transformation creates a new version of the data, while the previous versions remain intact and accessible – and delta records record the differences between each version.
• Concurrency and Parallelism: Immutable data is inherently thread-safe because multiple threads or processes can safely access and share immutable fields without the need for record locks or other data synchronization mechanisms. This property enables more efficient concurrency and parallelism in applications.

FG: So now that you have explained the concept of Immutability and its value to modern investment accounting processes, can you dive deeper into FundGuard’s real world data model versioning methodology?

PM: In one of my previous blogs, I compared the benefits of FundGuard’s NoSQL database approach compared to legacy systems’ use of SQL databases. This is important to note, because NoSQL databases are designed for immutability, which, as we’ve established, means that information stored within the database can be continuously versioned so that no balance value is ever overridden. 

In terms of how this translates to practical application, FundGuard maintains data in a series of large immutable data models, such as: security positions (holdings), security taxlots, trial balance accounts, and NAVs.  

Records in these tables contain balance values that track data such as: 

• Portfolio values like: Quantity, Cost, Market Value, Accrued Interest
• General ledger values like: Account opening and closing amounts
• NAV values like: Total assets and total shares outstanding 

Over time, these balances change as portfolio activities and events such as trades, corporate actions, interest accruals, maturities, coupons, etc. are applied to FundGuard.

To understand how FundGuard keeps track of these balance changes, there are two key principles worth noting:

1. Records in the data models are immutable (uneditable)
2. Each change to a record in a data model results in a new version of the record (added record)

FundGuard’s data models are optimized to add new records quickly.  When activities and events are applied to the data models, processing occurs to update records such as a security position, by only adding a new version of that record to the data model.  To track changes from one version to another, a delta record is also added, that shows the change to field values from the last version to the new version.  

Because the records are immutable, FundGuard’s data model updates never overwrite field values on existing records.     

FG: So, through the FundGuard lens, clearly immutable data in investment accounting software is invaluable due to its contribution to data integrity and auditability?

PM: Yes. Since being immutable means that a database can maintain an entire historical account of information such as portfolio balances, for each day and even more frequently – such as after each trade or corporate action event, etc., this gives users full investment accounting visibility for any point in time, without any processing overhead. This is what we mean when we talk about delivering a “single source of truth” across the enterprise.

Immutable data also aids in reducing the risk of errors and fraud, as each entry is time-stamped and linked to its creator, creating a reliable ledger of all activities. In the context of investment accounting, where transactions must be accurately tracked and reported, immutable records ensure that once data is entered, it cannot be altered or deleted, which is crucial for compliance with financial regulations and standards that demand a transparent and verifiable trail of all financial activities.

The Accounting Mindset

A Final Word from Peter Before You Go:

FundGuard applies an accounting mindset in all we do. Every decision we make about the FundGuard Investment Accounting solution is led by this mindset so that we can always deliver the best possible solution to our clients. So while you can have an investment accounting system without immutable records, we’ve made a very mindful decision to adopt immutability because it ensures that all data is always carefully chained together to “account” for every last detail.  Certainly there are “data” systems that do this well, but they do not inherently have to because they are not the system the auditor came to see, so to speak. 

True accounting systems – back office investment accounting systems – should have an auditor in the room of every system design conversation (figuratively speaking, of course). This approach – this accounting mindset – ensures success for those architecting the investment accounting system and its data framework. And by success we mean a single operating model that stretches across multiple dimensions – asset classes, regions, front/middle/back office to enable unparalleled scale and efficiency and significantly reduced costs of ownership. 

Your true path to digitalization starts from the back. Ready to get started? Contact us.