At 10:02, a trader can point to an execution and say the trade exists. Risk can point to an amended position and say the exposure has changed. Operations can point to an unmatched allocation and say the trade is not ready to settle. Finance can point to yesterday’s booking and say nothing new has reached the official ledger.
Nobody is necessarily wrong. That is the problem.
Each application is answering a different question, at a different point in the lifecycle, using a different clock. The trader’s blotter records what was filled. The risk platform measures the exposure it currently understands. The operations platform tracks whether the allocation has matched. The ledger reports what passed a controlled posting boundary by the previous close.
Ask the firm what happened, however, and it may not have an answer. It has four extracts, several timestamps, a reconciliation queue and, eventually, a meeting.
This is not simply bad data quality. It is the predictable result of an architecture that makes applications authoritative for isolated stages and asks reconciliation to assemble enterprise meaning afterward. The alternative is not another master table. It is a governed live lifecycle: persistent identities connect related business objects, semantic events preserve what changed, bitemporal state distinguishes economic effect from firm-recorded time, and materialized views give each function the answer it needs.
The target is not one application—or one physical database—containing all truth. It is a logically governed history from which authorized functions can produce timely, explainable views.
Continue reading “Four Correct Records. No Common Answer”