I am trying to understand some of the original design, and this is one area I'm unsure about. As far as I can tell, this originates in some other plugin when some transaction happens like a trade in the market. But is it really a good idea to separate notification of a position update or a tariff subscription or a unit of power consumption from the associated cash transaction? I would be more comfortable if all cash transactions were bundled with the events that justify them, rather than separated out. That way, we can be sure they have been routed through the accounting service before the broker sees them, for example.
So here's an idea. We create a superclass of all cash transactions, and make position updates and the various kinds of tariff transactions be kinds of cash transaction, which basically means they contain the relativeChange field. Everything else in CashDoUpdateCmd seems to be redundant information that's already contained in the event that leads to the transaction. Even inside AccountingService we are creating new CashDoUpdateCmd objects just to call the method that does cash transactions.
A major benefit of this approach is that it improves cohesion by a big factor. No longer would any module other than Accounting need to decide that a cash transaction is needed in addition to their own domain events.