Institutional clients and their end-users

Questions
1

Hello,
For institutional clients, who might have many end-users, is it expected that:

  1. They have a single party, representing the institution.
    The end user information must be encoded in the contract template, and they cannot receive contracts that are not equipped to include this info.

  2. They create one party per end user?

In case of 1. are there example contracts that account for this?
In case of 2. is there a limit on the number of parties hosted on a single participant?

2

I’m personally a fan of this approach:

  • Define a party for the institution.
  • Define a party for each role within the institution.
  • Define a “user management” user per end user, configuring the users to readAs and actAs the appropriate roles.
  • At system setup, the institution party is used to create Daml contracts with the various choices that the roles can exercise on behalf of the institution (a “role delegation pattern.”)

The end result is very nice. Logged-in end users can read and act on contracts based on their assigned roles. (Roles can even be changed dynamically.) Daml contracts are ultimately signed by the institution, as users with the appropriate roles act on the institution’s behalf.

Hopefully that is clear. It’s on my TODO list to write up a post with an example about this. I’ll prioritize that.

2 Likes
3

I’m not sure I understand things correctly… End users should have extremely limited roles, pertaining only to their accounts.
As a client of a bank, I’m not allowed to read/act on any other accounts than my own. So you can’t have say “CanTransfer” as a role/party, since that would impact all acounts. You could have “CanTransferFromBob”, but this essentially means one/multiple roles/party per end-user.

Let’s take the example of two institutions BankA and BankB, where BankA is in charge of issuing token A, and BankB is in charge of issuing token B.
Suppose that Bob is a client of BankA, how can he receive some token B?

  • If BankA is a party, and hides its end-users behind an abstraction layer, then the contract for token B needs to “know” this, for instance, by having an additional “account” field to store additional data. Unless there are standards in place, this might not hold. Tokens then need to be transfered directly to BankA, but how does it know which account to actually credit?

  • If Bob is a standalone party, token B doesn’t need to understand implementation details, which sounds like it makes things easier, but then it becomes a matter of provisioning/deprovisioning parties dynamically depending on end-users registration, and you might end with millions of parties on a single participant.

4

I think we were simply talking about two different use cases. I should have asked more questions. :smile:

What I described was for modeling the workflows carried out by employees within an institution.

You are talking about a large number of the institution’s customers each with their own accounts. :thinking:

Let’s see what other responses we get.

5

Ahh right that makes a lot more sense then!
Here’s hoping some people have thought about this use case and have some opinions :slight_smile:

6

I would think each relationship that client has with institution is described in the contract and then contract can be expired/archived based on the change in relationship or relationship attributes to new contract.