Most databases work in a very straightforward way—you have an entry or object and its associated values. If you update an entry, the system may keep track of when the values were changed, but typically there is no record of what the previous values were.

Beacon’s data model includes an additional feature that brings the concept of version control to time-based data. When data points with this feature areupdated, instead of overwriting the previous values we add a new entry with appropriate timestamps. All versions of the data remain accessible, making it possible to time travel through the data and observe the effects of data updates at any point in time. This type of structure with an extra version property is called “bi-temporal data”.

How Does Bi-Temporal Data Work?

In our database, each entry includes two timestamps: “as-of” and “entry”, hence the ‘bi-temporal” name.

• As-Of Time is the date and time that the data should be associated with
• Entry Time is the actual time the data was updated

For a simplified example, consider tracking “fixes” – published values which derivative contracts often pay out against. An interest rate swap might calculate its floating leg payoff based on LIBOR fixes published at the start of each coupon period. A not uncommon issue: a LIBOR fix is entered in the system today with an incorrect value; profit and loss (P&L) for the day is calculated from the incorrect fix; and then the next date the error is caught. In most systems, the LIBOR fix for the previous day is updated, but the old value is lost, and it becomes impossible to reproduce the previous day’s P&L calculation. With Beacon’s bi-temporal data, both values are saved, and you can reproduce prior behavior. In this example, the as-of date for both fixes (the initial incorrect value and the corrected value) is the fixing date, but the entry time is different. Beacon’s data model lets you roll the clock back and forward on either of those time axes to reproduce prior behavior, so you can reproduce the prior day’s P&L exactly, but also clearly isolate the P&L impact of correcting the fix.

At the core of Beacon’s object hierarchy are environment settings, including the as-of and entry time cutoffs. Users can readily adjust these settings to any earlier period, effectively time travelling through the data to run reports and observe the impact of any data changes, with full transparency into all updates.

Using Timed Data to Make Month-End Easier

One of Beacon’s clients manages inventories of oil and other commodities worldwide. The biggest pain point with their legacy system was running the month-end P&L and market exposure reports. These reports were run promptly at the end of each month, but actual inventories were not reported until 3 days later. They could not just update the inventory levels when they received them and re-close the month, because the system was designed to filter out any changes that happened after month end. As a workaround, they completed each report as usual on the last day of the month, and then exported the data to another system. Then they would spend several days collecting the revised data and updating their exported information manually, with the constant risk of human errors.

After implementing the Beacon Platform, the client is using the bi-temporal data capability to update inventory levels, prices, or other information as of the last day of the month, whenever that data becomes available. Reports can be run and re-run as necessary, easily comparing the effects of any changes and substantially reducing the number of errors and time spent massaging the data.

Other Uses of Bi-Temporal Data

Once you understand the value of bi-temporal data, you begin to see use cases for it in many different areas. Some other examples from Beacon:

• Trade events. Beacon’s deal model defines a chain of immutable trade events, each of which has its own as-of and entry timestamps. When a deal is amended or updated, or when it experiences a lifecycle event such as a coupon payment or exercise, a new trade event is added to the chain. No data are ever lost, and it becomes easy to audit and report on who did what and when.
• Bond contract details. The data that define a bond, such as issue date, coupon tenor, coupon amounts, rarely change – but when they do, there can be significant impact on risk as well as operational events such as coupon payments. Beacon uses a bi-temporal model for bond details that makes it easy to identify and isolate risk and operational changes.
• Holiday calendars. Valid dates for valid trading days, currency settlement, fix publishing, and so on are governed by the holiday calendars in your system, and these calendars are occasionally updated. Those updates can have a complicated impact on P&L and risk, and Beacon’s bi-temporal data model for holidays means that it’s easy to identify who changed a calendar and what impact it had.