When A pays C using its credit relation with B, this creates a chain of transactions/obligations A → B → C.
Sometimes this will be ‘final’: A pays something to B, B pays something to C (these need not be the exact same amounts, nor even currencies), and that’s it. A becomes completely detached from the B → C transaction, A → B → C has been split into two completely independent transactions A → B and B → C.
But sometimes there will be some ongoing fees resulting from the B → C transaction, for which A will need to compensate B on an ongoing basis - until the debt is repaid or the transaction is reversed via a clearing event. A remains attached to the B → C obligation. The Sikoba system must be able to keep track of such ‘non-final’ or ‘dependent’ transactions during their entire life-cycle.
Another feature of Sikoba is that an A → B → C chain of dependent obligations is not necessarily static. As the system state changes, it may be replaced automatically by another less ‘expensive’ chain of obligations, for example, A → D → E → C, which again may not be ‘final’.
From what we know, such features are not (or not yet?) available in Ripple.