[inopinatus]

I read an article from Modern Treasury that advocated for mutable pending transactions to vary entry amounts by replacing entries¹, which is just about the worst idea I ever heard in the design of a DE system, and their reasoning boiled down to: if you're running a settlement system but are too lazy to implement a clearinghouse layer separately, no worries, just violate the entire DE covenant instead. So I'd take anything they write with a pinch of salt.

[1] https://www.moderntreasury.com/journal/how-to-scale-a-ledger...

[btown]

Out of curiosity, how would a clearinghouse layer plug into this in practice? Thinking aloud, would you have an event stream of, say, EntryCreatedEvent, and the clearinghouse would provide streams of of EntryClearedEvent and EntryRejectedEvent - would you join those streams together to derive EffectiveEntry, EffectiveTransaction, PendingEntry, PendingTransaction based on whether all clearing is done on both sides?

[inopinatus]

I would strongly advise against additional event types because the double-entry model is already an append-only journal. At most, I’d encapsulate the creation of a transaction as a structural formality for whatever event stream/bus is in use. The clearance events produced by the clearinghouse need to be more purposeful and work at a domain level for the logic to have any chance of coherent implementation. So it’s a PaymentsCleared event, note the plural because in many systems this is a batch. This is probably followed by events for the creation of records for the aggregate settlement transfers and their subsequent approvals/lodgement/lifecycle with financial institutions/treasury systems.

The most interesting projections from such an event stream are usually just Balance and PendingBalance. I wouldn’t type entries based on status, it’s just a flag (or more likely a timestamp and reason code), and transaction is not distinguished at all, its status is nominally cleared simply when all the linked entries are cleared.