Yes, this is what we had in mind: And so TB exposes a set of primitives designed around debit/credit (not only a record of debit/credits). For example, you ca

Yes, this is what we had in mind: And so TB exposes a set of primitives designed around debit/credit (not only a record of debit/credits). For example, you can express something like: - Do a transfer between accounts, but only on condition that the resulting debits would not exceed credits (or vice versa, or some threshold amount compared to this net balance), and while taking other authorized (but not yet captured) inflight transfers (i.e. to other third party systems using two-phase commit protocol) into account also in that net balance calculation. - Then, if this transfer succeeds, immediately also do another 7000 transfers, all linked atomically together. But if any of these would fail, then the whole chain, including the net debit cap transfer, should not be executed. - But only do all the above, if both volume and velocity limits (expressed not in a currency but in a quantity) in an isolated risk ledger would also be satisfied. - And finally, if all this does succeed, then do another set of transfers in a separate USD reporting ledger. You can do the above, atomically, in a single round-trip to TigerBeetle. It would be a nightmare in SQL. But the other advantage to having the transaction DBMS speak debit/credit accounting primitives is that your multiple products can then build around a transaction processing core with strict controls, while keeping the accounting policy in the product layer above—because while every business/product may have different accounting policy, the primitives are the same. This keeps the core of your transaction DBMS simple and in control, while allowing flexibility for product evolution.