Late trade adjustments
A typical trade flow will include the following steps:
- A trade is booked on a certain day at a certain time
- Later that same day, the trade is entered into a risk system
Whenever a trade arrives in our risk system we can set the valid-time (the business curated timeline) to the exact time of the trade. This backfilling of histoical data allows us to understand and report on the risk position of our trade portfolio as-of any point in the past.
For example, a set of trades entering our risk system may look something like this:
However sometimes a trade is booked right at the end of the day, after the standard End-of-Day reporting window has closed, and therefore isn’t available and processed by the system until sometime later.
Let’s say this trade was entered the next day:
We can re-run our final risk reports for yesterday to include the late-arriving trade:
Now our reports can be made consistent and reproducible whilst accounting for late-arriving data, great!
Can anyone see any potential problems with updating the past like this?
Let’s say instead of backfilling a trade to yesterday, someone adds a trade a month ago!
Now when the auditors come in, they check for changes since they last were here:
They can’t find the trade we sneaked into last month! Has someone just gotten away with fraud?
If we want to allow editing the timeline, how can we avoid this?
In XTDB we use system-time (a.k.a. wall-clock time), an immutable timeline that gets appended to with every change. This means our fraudulent/malicious/accidental edit from earlier gets caught easily:
In fact we can even scan the system for suspicious or unusual changes. For example, any retroactive changes to valid-time that go back further than 24 hours:
Conclusion: As an immutable database, XTDB keeps you safe from your own changes by making sure to record when they happened. Even when reaching into the past!