In business cooperation, our Sto issuance platform needs to integrate with some traditional financial network, I will call it DX in this article. DX provides financial service to financial intermediaries such as family office (single or multi) like product catalog, asset portfolio analysis, etc. These above services do not have any investment transactions in them and can be easily modified to support Sto assets. But DX also receives securities buying orders from those intermediaries and execute them. This order execution happens in a traditional financial context, but now, it needs to evolve into STO context. There are activities as API interaction between DX and our issuance platform, an on-chain issuance (Sto side) and off-chain settlement scenario, the token is manually issued in a step of this order execution process by UI functions used by issuer：We ignore all these aspects but focus on one big question: DX is a B2B network linking financial intermediaries — family offices, for example. The clients of those family offices are the real investors.
Now Sto comes to fit into this world of intermediaries. Let’s figure out how.
Difficulties
Some difficult, even painful (at first sight) points to consider:
1. The real investor is or should be viewed as, invisible to DX. Even if DX knows something about clients of its client (family office), this is a negative knowledge, it is the family office that is positive who has some custody responsibility for real investors. From the architectural viewpoint, DX face and interact with the family office and know nothing beyond that.
2. Sto platform is farther away from the investor on this chain of intermediaries.
3. In Sto, a) Normally， the Token holder is an investor instead of anything else. b) on-chain Compliance logic is based on knowing real investors instead of anything else.
4. Simply put, Concern of investor identity and a lot more penetrate across borders between everyone. This will contradict the design principles and complexity will roar up. Something must figure out to cope with it.
Solution
Give out the solution directly:
1. Intermediaries also have an identity and claim; they also can be security token holders in their custodian role.
2. In doing business, intermediaries may hold security token for their clients, but this can be temporary or long-term.
3. Intermediary transfer ownership of tokens to its clients, the real investor, and in the meantime a custodian relationship be set up between them.
Some explanations of this solution:
1. A family office’s holding of the token is temporary or long-term is a question the same as that when they do the registration work on Central Security Depository. If intermediaries’ token holding, temporary or long term, has anything with cap table, this is for the family office itself to consider if this is required by anything including regulation. Sto just provides enough support for this work. No need to grapple with this.
2. Of course, the STO platform will manage claim (license) for intermediaries and in its on-chain compliance logic will permit them to receive tokens. Not only compliance logic, percentage\maximum amount\lock period logic also needs intermediary claim to differentiate.
3. Sto on-chain logic and technology just support the work of intermediaries, or from a negative viewpoint do not make any obstacles for it. Such a requirement as “family office must register asset ownership for their clients” is out of business with Sto.
4. The relationship between a family office and their client is a kind of “custodian ownership” in which investors retain all the beneficiary rights (voting, dividend) to himself but delegate transfer right to the family office. As I write in another article[1], this does not need a custodianship structure in smart contracts design, ERC20 allowance management is enough. Keeping the design of core smart contracts straightforward, pure, and simple worth everything. They do support everything in intermediaries’ function but need not be a direct reflection of it. Stuff them into the core level may be disastrous.
5. Cap table needs the support of off-chain Identity Information Service [2], and some kind of authorization is necessary. Using this service, the cap table will display investor information, including intermediaries token holders.
Scenarios of this solution
So, in the Sto context, the application scenarios:
1. The family office still is responsible for its clients: Guide them to set up their identity and claim: downloading of identity wallet, QR code scanning to transform account to identify and claim, etc. A lot of modifications to their own business platform to make it support Sto mode. But all this is its internal business without any essential effect on DX. This division of concern that existed in the traditional system is kept untouched.
2. The family office itself setup its identity and claim and this identity and claim will sign the order when the family office makes orders to DX. Investors served by the family office are invisible to DX in principle. The methods or process to setup identity and claim of the family office is not difficult.
3. In the Sto platform, when issuing a token to a family office, compliance logic will find its claim and treat it as a family office.
4. The family office gets tokens issued to its wallet and now a) it distributes the token to investors- they can do this because on-chain locking logic is differentiated. This token distribution makes the cap table correctly updated. B) investors approve allowance to a family office, partially or completely.
Some other thoughts
1. In the integration of STO platform the traditional financial platform, DX, or in general any financial intermediaries, has the task of making themselves identity-enabled and Sto-enabled, instead of only integration by API.
2. Solutions in this article is applicable to other kind of intermediaries, not just family office.
References
[1] Decentralization in Sto Compliance and Claim Provider Mesh
[2] How STO Fit into the World of Current Intermediaries — Custodian, Broker Dealer and Investment Manager
