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:

• Family relations between Physical Users (actual parent and children)
• Hierarchical relations between Legal Entities (employer, parent) and Physical Users (employee, children)
• Ownership relations between Legal Entities (company, parent) and Physical Users (shareholders/legal representatives, children)

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

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

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)

• 0 None
• 1 Shareholder of a Legal Entity
• 2 Other_relationship
• 3 Legal representative of a Legal Entity

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.

CURL

curl -X POST {baseUrl}/v1/users \
		--header 'Authorization: Bearer {accessToken}' \
		--header 'Content-Type: application/json' \
		-d '{
			"userTypeId":2,
			"specifiedUSPerson":0,
			"legalName":"An Awesome Company"
			# [...]
		}'

Returns a User, with its id (111222333).

JSON

{
	"userId": 111222333,
	"userTypeId": 2,				// 2 corresponds to Business Users
	"parentUserId": null,			// this User does not have a parent
	"parentType": null,				// as it does not have a parent, it cannot have a parent type either
	"legalName": "Example Company",
	// [...] some attributes are hidden for clarity
}

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.

CURL

curl -X POST {baseUrl}/v1/users \
		--header 'Authorization: Bearer {accessToken}' \
		--header 'Content-Type: application/json' \
		-d '{
			"userTypeId":1,					# 1 = physical user (human being)
			"specifiedUSPerson":0,			# 0 = Non-US citizen
			"firstname":"Alex",	
			"parentUserId":111222333,		# <--- associate to the parent companys ID created above
			"parentType":"employee"			# <--- define the type of relation		
			# [...]
		}'

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

JSON

{
	"userId": 444555666,
	"userTypeId": 1,
	"parentUserId": 111222333,
	"parentType": "employee",
	"firstname": "Alex"
	// [...] some attributes are hidden for clarity
}

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
}

Children

{
	"userTypeId":1,
	"parentType":"employee",
	"parentUserId":{idOfTheParentUser},
}

---

Company and Legal Representative

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
}

Children

{
	"userTypeId":1,
	"controllingPersonType":3,
	"parentType": "leader",
	"parentUserId":{idOfTheParentUser}
}

---

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
}

Children

{
	"userTypeId":1,
	"controllingPersonType":1,
	"parentType": "shareholder",
	"parentUserId":{idOfTheParentUser},
	"effectiveBeneficiary": 30 // shares (%)
}

---

Company and Legal Representative who is also a Shareholder

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
}

Children

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

---

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 is 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
}

Children

{
	"userTypeId":1,
	"parentType":"leader",
	"parentUserId":{idOfTheParentUser}
}

---

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
}

Children

{
	"userTypeId":1,
	"parentType":"shareholder",
	"parentUserId":{idOfTheParentUser}
}

---

Individual and Assisted Individual

This use case describes a parent individual (Physical User) and an assisted individual (Physical User) under their legal responsibility (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
}

Children

{
	"userTypeId":1,
	"parentType":"leader",
	"parentUserId":{idOfTheParentUser}
}