Glossary, Terms & Concepts
This serves to provide a common understanding of the terms and states used on the API.
General Terms
| Term | Definition |
|---|---|
| rental-collateral | The element representing the deposit which a tenant places for safekeeping for security for the owner of the rental unit. Sometimes referred to as rental deposit. |
| manager | The entity that the owner of the rental unit hires to manage all day-to-day affairs with the tenant. The manager acts on behalf of the owner. For the financial partners, the collateral is usually associated with the manager/management and not the owner. |
| tenant | The person which which is renting the unit and pays the deposit. The account at the financial provider is always in the name of the tenant. |
| product | Possible means of placing the collateral. All products are provided by third-parties (banks, insurers etc) and not by Zinsli. |
| owner | The person or entity which owns the rental unit. |
| management | The person or entity which is hired by the owner to manage tenants and day-to-day items of rental units. |
| user | An account on the Zinsli platform. A user can have both roles: a tenant or a landlord. |
| prename | First name |
| surname | Family name |
| landlord | The owner or the manager of the rental unit. They send an invitation to the tenant for a collateral. |
| financial partner | Provider of the products. Usually a bank, insurance provider or broker for precious metals. |
Collateral States
| Status / State | Meaning |
|---|---|
| initial | Collateral has been created, but no tenant has been invited yet |
| tenant-invited | The tenant has been invited to the collateral, but has not yet made a decision to accept or reject the invite |
| tenant-rejected | The tenant has rejected the invite to the collateral, with the rejection, the tenant should provide a reason why the invite was rejected. The manager can adjust collateral and invite as required. |
| tenant-accepted | The tenant has accepted the invitation to the collateral, but has not yet picked a product. |
| tenant-waiting-for-secondary-tenants | The primary tenant has chosen a product and invitations have been sent to the secondary tenant(s) to approve the choice. |
| tenant-onboarded | The tenant has chosen a product and has completed the onboarding with the provider. The provider is now completing the necessary steps for a new account on their end. |
| ready-for-payment | The provider has opened the account and has provided the required details for the tenant to pay the deposit. |
| partner-account-creation-rejected | In case the provider does not accept the tenant as a customer, they provide a reason on why the requested account could not be opened. Zinsli will inform the tenant and they will be asked to choose a different product. |
| locked | The tenant has made the full payment into the account and the collateral is now locked. It can only be released with the agreement of both parties. |
| closing-initiated-by-landlord | At the end of the lease, the manager initiates the release of the collateral. |
| closing-conditions-rejected-by-tenant | The tenant has rejected the terms of closure which the manager suggested. They reject the closure and provide a reason. The manager can now adjust the terms and resend the closure request. |
| closed | Once both parties agree on the terms of closure, the collateral is closed. |
Critical Fields
Most fields are self explanatory, all fields are documented in the swagger documentation schema. Some critical fields, especially in the collateral context, which may need further explanations, are listed here:
| Field | Context | Explanation |
|---|---|---|
| acceptedAt | collateral | The timestamp at which the primary tenant has accepted the invitation from the landlord to manage the collateral via Zinsli. From this point forward, the collateral is linked with the user account of the tenant. (This is the collateral state change: tenant-invited -> tenant-accepted) |
| submittedAt | collateral | The timestamp at which the tenant has agreed to the product and the request was submitted to the product provider. (This is the collateral state change: tenant-accepted -> tenant-waiting-for-secondary-tenants (iff secondary tenants) OR tenant-accepted -> tenant-onboarded (if no secondary tenants)) |
| confirmed | collateral > secondaryTenant | Boolean. Indication (per secondary tenant), if the secondary tenant has given their agreement to the proposed collateral. |
| confirmedAt | collateral > secondaryTenant | Timestamp of agreement given by secondary tenant (recorded per secondary tenant). (For the last secondary-tenant to confirm, this is the collateral state change: waiting-for-secondary-tenants -> tenant-onboarded ) |
System Roles
There are currently three user system roles available.
| Role name | Description |
|---|---|
| owner | - This is the primary account holder of the organization. - This user can do everything in the context of the Organization - There must be at least one user with the owner role assigned |
| admin | - This user can do almost everything within the context of the organization - This user cannot manage other team members (add/modify/delete) further restrictions will be added over time |
| member | - This user has restricted permissions within the organization. - This user cannot manage other team members (add/modify/delete) further restrictions will be added over time |