# Parent-Children relations

Hierarchical relations can exist between Users (with a maximum depth of 2).

Parent-children relations can be used in multiple scenarios. It is mandatory for:

It can optionally be used for other types of hierarchical relations related to your own business activity.

Thumbs icon

Best practice – Make sure you create relevant hierarchical relations

Always abide by the rules Treezor sets out for you. Otherwise, you may have technical or legal issues.

# Key attributes

The hierarchical relation to a parent User is defined by the following attributes:

Attribute Type Description
parentUserId integer The unique identifier of the User who is the parent of the current one.
controllingPersonType integer The type of relation with the parent, used with Shareholders and Legal representatives. see list of values
parentType string The type of relationship between the parent and the current user. See list of values
effectiveBeneficiary integer Percentage of ownership for an Effective Beneficiary, if applicable (25 for 25%, 100 for 100%, etc.)
employeeType integer The type of employee. See list of values.

# Parent Types (parentType)

The following parent types are available. They may take different meanings depending on your implementation.

  • shareholder
  • leader
  • employee
Info icon

Information – parentType can't be updated

Once this value is set upon creating a user, it cannot be changed later on.

# Controlling Person Types (controllingPersonType)

# Employee Types (employeeType)

  • 0 None (not an employee)
  • 1 Leader (legal representative)
  • 2 Employee (employee)

# How to use parent relations

It is recommended that you create your users from the top of the hierarchical tree (starting with the top-most parent) and take a look at use cases.

The following example illustrates the creation of a company and one of its employees.

We first create "Example Company", a Legal Entity that will act as the parent.

Returns a User, with its id (111222333).

We then create "Alex", a Physical User,

  • associate it to the parent company (parentUserId),
  • define the relation as an employee relation (parentType).

All in one step.

Returns a User, with parentUserId and parentType populated as specified above.

# Use Cases

The most reliable way to identify how to implement your parent-children relation is to find a suitable Use Case below.

# Company and Employee

This use case describes a parent company (Legal Entity) and an employee (Physical User) of the parent company.

# Parent

{
	"userTypeId":2,
	"parentType":null,
	"parentUserId":null
}
1
2
3
4
5

# Children

{
	"userTypeId":1,
	"parentType":"employee",
	"parentUserId":{idOfTheParentUser},
}
1
2
3
4
5

This use case describes a parent company (Legal Entity) and a legal representative (Physical User) of the parent company.

# Parent

{
	"userTypeId":2,
	"controllingPersonType":null,
	"parentUserId":null
}
1
2
3
4
5

# Children

{
	"userTypeId":1,
	"controllingPersonType":3,
	"parentType": "leader",
	"parentUserId":{idOfTheParentUser}
}
1
2
3
4
5
6

# Company and Shareholder

This use case describes a parent company (Legal Entity) and a shareholder (Physical User) of the parent company.

# Parent

{
	"userTypeId":2,
	"controllingPersonType":null,
	"parentUserId":null
}
1
2
3
4
5

# Children

{
	"userTypeId":1,
	"controllingPersonType":1,
	"parentType": "shareholder",
	"parentUserId":{idOfTheParentUser},
	"effectiveBeneficiary": 30 // shares (%)
}
1
2
3
4
5
6
7

This use case describes a parent company (Legal Entity) and a Physical User who is both the legal representative and a shareholder of the parent company.

In such cases:

  • The Physical User is created as a Legal Representative and,
  • The effectiveBeneficiary field must include the shares of the company.

# Parent

{
	"userTypeId":2,
	"controllingPersonType":null,
	"parentUserId":null
}
1
2
3
4
5

# Children

{
	"userTypeId":1,
	"controllingPersonType":3,
	"parentType": "leader",
	"parentUserId":{idOfTheParentUser},
	"effectiveBeneficiary": 30 // shares (%)
}
1
2
3
4
5
6
7

# Natural Parent and Minor (using Electronic Money)

This use case describes a natural parent (Physical User) and their natural minor children (Physical User).

# Key aspects of this Use Case

  • It it used with Electronic Money Wallets.
  • The Wallets are associated (Wallet.userId) to the natural parents.
  • When the Electronic Money threshold of €150 is reached, a KYC is required on the natural parent exclusively.

# Parent

{
	"userTypeId":1,
	"parentType":null,
	"parentUserId":null
}
1
2
3
4
5

# Children

{
	"userTypeId":1,
	"parentType":"Leader",
	"parentUserId":{idOfTheParentUser}
}
1
2
3
4
5

# Natural Parent and Minor (using Payment Account)

This use case describes a natural parent (Physical User) and their natural minor children (Physical User).

# Key aspects of this Use Case

  • It is used with Payment Account Wallets.
  • The Wallets are associated (Wallet.userId) to the minor children.
  • A KYC is required on both the natural parent and the minor children.

# Parent

{
	"userTypeId":1,
	"parentType":null,
	"parentUserId":null
}
1
2
3
4
5

# Children

{
	"userTypeId":1,
	"parentType":"Shareholder",
	"parentUserId":{idOfTheParentUser}
}
1
2
3
4
5

# Individual and Assisted Individual

This use case describes a parent individual (Physical User) and an assisted individual (Physical User) under their legal responsability (such as under guardianship).

# Key aspects of this Use Case

  • It is used with Payment Account Wallets.
  • The Wallets are associated (Wallet.userId) to the assisted individuals.
  • A KYC is required on both the parent individual and the assisted individual.
  • The parent is required to produce an additional KYC Document (form of proxy) allowing them access to the children's Wallet.

# Parent

{
	"userTypeId":1,
	"parentType":null,
	"parentUserId":null
}
1
2
3
4
5

# Children

{
	"userTypeId":1,
	"parentType":"Leader",
	"parentUserId":{idOfTheParentUser}
}
1
2
3
4
5
Updated on: 4/23/2024, 8:29:09 AM