Hm.

How about this:

I'm A, I want to pay one btc to B with fast validation.   I have a preexisting relationship with C, and B has a pre-existing relationship with B.

I give C a signed transaction with an nlocktime somewhat in the future, covering the the amount, any fees C is charging me, and any BTC txn fees.  C gives a similar open transaction to B.    

If there are more exchanges between any of the parties we replace the transactions with updated versions that reflect the new outstanding balances. All of the is hidden from the blockchain until the locktime runs out.  After some time has passed without any changes, the lock time arises and the latest version of the transactions are published, settling the accounts.

A<->C can settle independently of B<->C.

Parties are vulnerable to double spending of the committed funds, but thats why they have a pre-existing trust relationship. They are assured that their activities are backed by funds their trusted peer has— at least fractionally (in the case of double spending).

This obviously works when C is a chain of parties too.

Now the fun part is working out the bitcoin script commitment so that the bitcoin transactions are only valid when an IOU exists, so that if C tries to cheat A by reducing the reducing A's balance via an IOU payment, but then settles using the old open transaction instead of an updated one, that A can prove C cheated by presenting the sequence of IOUs.