Support for account hierarchies

How can we support allocation of assets into account hierarchies, either internal or external ones?

Two example use cases:

An institution holds a certain asset at a custodian, say 10mm USD. This balance is internally "allocated" to three different funds / desks / strategies.
A custodian holds assets on behalf of an asset manager at the CSD. They have one omnibus account for the asset manager, and sub-accounts for each of the funds they manage (which are legal entities themselves, and are the legal owner of the securities). I'm not sure this is actually a realistic scenario, but I do think CSDs can support sub-accounts

This scenario is quite common in the industry so we should think how we can support it.

One approach that I think already works in the current implementation is the following:

The party representing the legal entity holding the aggregate funds at the custodian is the owner of the holding at the custodian
This party essentially acts as an "internal custodian" to the firm
Internal departments / teams / entities / desks would just be owners of holdings at this "internal custodian" party

Some issues with this approach:

We don't have a way to "preserve quantity", ie. to ensure that internal holdings sum up to the external one. This is not specific to this use case, we generally don't guarantee this (eg. to support central bank and commercial bank cash scenarios, where we need it). But it would still be great (not just for this use case) if we have a way to selectively enforce this
We generally cannot settle atomically from an internal account to an external counterparty, as this would reveal internal accounts to the counterparty. Unless we use an internal party as the settler of the batch, but this would mean the external party would have to reveal their account structure to us. A third party settlement agent would also require internal account visibility, which is probably prohibitive.

Another approach I could imagine:

A custom Holding implementation that has an additional account key that points to the internal account
The account id would be a random id that is meaningless to the custodian
The owner would split up their asset at the custodian into the allocated chunks, and set the internal account accordingly

Drawback:

The custodian would still learn about the allocation structure (ie. how many sub-accounts an asset is allocated to)
I don't see how we could support hierarchical internal accounts with this

I wonder if there are other, better approaches to this. Something to think about.

@johan-da

I have been thinking about the atomic settlement across an account hierarchy in "zero-knowledge" (i.e., without revealing any information about internal accounts and settlement routes to say an agent). Assume Alice buys an asset from Bob over the counter (OTC), and that we have the following routes for the asset and cash, respectively:

    Depository
       /  \
     C1    C2                  (Asset)
    /        \
 Alice       Bob 
    \        /
     B1    B2                  (Cash)
       \  /
    CentralBank

Thereby note that the parties in the routes only need to know about their neighbours (except for the trading parties Alice and Bob which here also knows of each other). In particular, Alice does not need to know whether C1 has a direct link with the Depository or if there is some other intermediary in between.

I think the following would work. The trick would be to use

a hash-time lock, and
build routes to a common root custodian (here the Depository and CentralBank, respectively) in a specific order The protocol would work as follows:
Preparation phase: 0.1 Alice chooses a random secret x and computes a hash h = sha256(x). 0.2 She sends h to Bob.
Asset debit route to depository: 1.1Alice contacts her custodian C1, shows h, and prepares a hash lock of her asset to C1 (i.e., C1 can solely claim ownership of her asset upon showing a pre-image of h such as x within some time bound). Alice is willing to do so, as she is in control of the pre-image x (and the assumption is that it is not possible to compute an x' fulfilling h(x'). 1.2. C1 contacts the Depository, shows h, and prepares a hash lock of its asset to the Depository (as C1 then is net zero).
Asset credit route to depository: 2.1.Bob contacts her custodian C2, shows h, and asks to get a hash lock h for an asset provided by C2. 2.2. Before C2 provides the lock, C2 contacts the Depository, shows h, and asks to get a has lock h for an asset provided by the Depository. 2.3. Before the Depository provides the lock, the Depository waits for a corresponding hash lock claim (provided by some of its custodians, here C1). The Depository then provide a hash lock h to C2 (as the Depository is net zero). 2.4. Once C2 notices its hash lock h provided by the Depository, it provides the hash lock for Bob (as C2 then is net zero).
Cash debit route to central bank: 3.1. Bob now contacts B2, shows h, and prepares a hash lock h for his cash. Bob is willing to do so, as Bob is guaranteed (from 2.4) to get the asset in case someone claims his cash. 3.2. B2 contacts CB, shows h, and prepares a hash lock h for the cash to CB (as B2 then is net zero).
Cash credit route to central bank: 4.1 Alice contacts B1, shows h, and asks for a hash lock h for cash. 4.2 Before B1 provides the hash lock, B1 contacts the CentralBank, shows h, and asks for a hash lock h for cash. 4.3 Before the CentralBank provides the hash lock, it waits until it has a corresponding hash lock claim from one of its banks, here B2. Then the CentralBank provides a hash lock h for B1 (as the CentralBank is net zero) 4.4 B1 then provides a hash lock h for the cash to Alice (as B1 then is net zero).
Settlement 5.1. Alice claims the cash from B1 by revealing x to B1. 5.2 B1 claims the cash from the CentralBank by revealing x to Centralbank 5.3 ... CentralBank -> B2 5.4 ... B2 -> Bob 5.5 Bob claims the asset from C2 by revealing x to C2. 5.6. ... C2 -> Depository 5.7. ... Depository -> C1 5.8 Finally C1 claims the asset from Alice by revealing x to Alice

Note that if Alice would release x too early, the only party that would suffer from it would be Alice herself. Obviously, we need to assume that the parties play ball and adheres to the protocol (also the Canton protocol), but these are typically regulated entities (c.f. in a sense we can't guarantee that a party to a Dvp settles either) so it should be fine.

@lucianojoublanc-da

There's a class of problems that can be solved by multiparty computation. In the wiki it's described informally as:

suppose we have three parties Alice, Bob and Charlie, with respective inputs x, y and z denoting their salaries. They want to find out the highest of the three salaries, without revealing to each other how much each of them makes. Mathematically, this translates to them computing:

F(x, y, z) = max(x, y, z) If there were some trusted outside party (say, they had a mutual friend Tony who they knew could keep a secret), they could each tell their salary to Tony, he could compute the maximum, and tell that number to all of them. The goal of MPC is to design a protocol, where, by exchanging messages only with each other, Alice, Bob, and Charlie can still learn F(x, y, z) without revealing who makes what and without having to rely on Tony. They should learn no more by engaging in their protocol than they would learn by interacting with an incorruptible, perfectly trustworthy Tony.

And I think our problem falls under this category.

There's a textbook on this "Secure Multiparty computation and secret sharing" which goes into this in depth.

@lucianojoublanc-da secure function evaluation (SFE) is a way to let n players with individual inputs x1, x2, ..., xn compute a function f(x1, x2, ..., xn) without revealing any information about eachother's inputs. Such a task could easily be solved with a third trusted party, but the idea is to simulate such a behaviour between the players (in zero knowledge). MPC is more general in the sense that the function can be stateful (and give multiple outputs). Both SFE and MPC typically tolerate (depending on assumptions) that a certain threshold of parties act maliciously (i.e., collude, divert from the protocol, etc.), and still guarantee zero knowledge.

Indeed we would ideally want to simulate a trusted settlement agent, the question is under what assumptions. At least in our use case, the parties are typically regulated and not malicious. If Alice colludes with the Depository in the ^^ hash lock protocol, and thereby learns that there is a single intermediary between them C1, I guess it is fine. I also think we can assume that parties act rationally. If Bob does not play ball, we sue him in court;-)

digital-asset / daml-finance

Support for account hierarchies #556