Re: Escrow Risk (was Interledger and Privacy)

Arie, rating each ledger for its escrow risk to help connectors price their
services makes a lot more sense than rating the connectors themselves. I
would still say this should not be a part of the core protocol since it is
not required for performing ILP transactions, but can easily be offered as
a third party service after the fact if there is demand for it.

In general I would think that connectors would need to be familiar enough
with the ledgers they connect to price their own offerings accurately
accounting for escrow risk on each ledger. Connectors have no need to know
about ledgers they do not connect/participate in.
On Oct 28, 2015 1:41 AM, "Arie Y LEVY COHEN" <arielevycohen@gmail.com>
wrote:

> Thank you Adrian, for both!
>
> Following that explanation, and pardon the harp on risk and the measure of
> it, would I be understanding well to think it is the escrow agent
> (connectorI then that might benefit from a rating (reputation) assigned to
> each of the ledgers?
>
> I reckon some rating standard might help these connectors determine what
> they will charge for being that connecting bridge between two ledgers.
>
> Now, it was pointed out to me that my question suggested ratings work,
> when that very system seems to have failed us (e.g. rating of CDO/CMO's).
> Perhaps, but maybe an opportunity to improve how we rate these ledgers?
>
> --
> Heritage & Legacy Advisory | Multi-Generational Wealth Preservation
>
> Arie Y. LEVY-COHEN
> FINANCIAL ADVISOR | INTERNATIONAL CLIENT ADVISOR
> PRIVATE WEALTH MANAGEMENT | NEW YORK
> ECONOMICS | FINANCE | BLOCKCHAIN
> P: 917.692.6999
>
> On Oct 28, 2015, at 1:40 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
>
> It was pointed out to me that my reference to the central bank is
> misleading. I put it in there because Arie asked about central banks but
> it's actually a poor example.
>
> So, to be clear, control of when to release or reverse the escrow sits
> with the ledger. In the case I was thinking of, the central bank is a
> "connector" between two retail banks, (a poor example because in this case
> the banks normally hold funds/obligations with the central bank as opposed
> to the central bank holding accounts at the retail banks). I was trying
> emphasize that the quality of the participants determines the risk.
>
> In reality, where the ledger has ultimate control over if and when to
> release or reverse the escrow funds the connectors are the only entities
> ever exposed to risk of not being settled. The assumption is that they will
> price this into their offers based on which two ledgers they are connecting
> and how much they trust those ledgers to execute the escrow properly.
>
>
>
> On 26 October 2015 at 17:39, Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
>
>> More Arie questions to scratch your head over:
>>
>> Given the connector ultimately holds the money for however long in
>> "escrow":
>>
>>    - is there counterparty risk relative to where the escrow money sits
>>       (call it escrow risk??)?
>>       - could central banks play a role here?
>>       - IMF / BIS?
>>
>> I'd only classify this as counter-party (settlement) risk if there is a
>> chance that the reserved funds are lost before they are released (i.e. they
>> weren't really in escrow).
>>
>> The risk of this happening will differ from ledger to ledger and
>> connector to connector (e.g. If the connector is the central bank I'd say
>> the risk is close to zero...) and this is another characteristic of the
>> ledgers and connectors that a user may consider in path-finding.
>>
>> If there is some way for the user to get a guarantee that the funds are
>> truly in escrow the risk is very low.
>>
>> Perhaps this would be through some independent certification of the
>> ledger system if it is a closed ledger?
>>
>> For a system like Ripple or Bitcoin it is almost non-existent because the
>> system is open and the user can verify that the funds are in escrow if they
>> want to.
>>
>> This topic feels like it has some more questions that are not immediately
>> apparent...
>>
>
>