High Level Entities in Eclipse

High-level Entity Description

A Tenant is the contracting partner with Ukheshe and is responsible for the management of their wallet programs and taking a fintech proposition to market. Depending on the scenario, a company could set up multiple tenants on Eclipse if they have different propositions with different goals and target markets.

• A Tenant has to be created before any other entity can be created or edited. It is the cornerstone of data segregation. A tenant can only access things within the tenant. This is enforced at multiple layers by Eclipse.
• A Tenant can have multiple customers and organisations under itself.
• A tenant can have admin users who can manage/administer Eclipse for the tenant.
• Customers and Organisations have addresses and documentation attributes to be used for KYC and reporting purposes.
• Tenants, Customers and Organisations can have wallets. Depending on the Wallet Type, a wallet can have an associated card (Physical and/or Virtual) and/or QR Code.

Data Segregation

The data in Eclipse is stored in a geographically redundant distributed database where granular authorisation rules ensure that the API caller can only CREATE/READ/UPDATE/DELETE data accessible to the caller. A fundamental rule that is checked at multiple layers ensures that a tenant's data is only visible to that tenant and/or global users such as Ukheshe administrators and support staff. This is all controlled via the granular access permissions configuration set up per tenant.

Here is an example of a part of the permissions configuration:

This data segregation allows not only for a tenant to ensure that their data is theirs, but also that within the tenant, they can control who can see/do what. This helps ensure that for example customer A on tenant 10 cannot see customer B’s data even if they are also on tenant 10.

If a tenant wishes, the permissions can be set so that not even Ukheshe staff can see their data (other than GLOBAL_ADMIN which is required for some severe operations tasks). This would however mean that Ukheshe cannot support the tenant with queries via the admin portal as they would not have access.

Ukheshe considers a tenant's data to belong to the tenant and does not distribute, share, extract or otherwise utilise the data for any other purpose other than to support the tenant in their business operations and billing the tenant for Eclipse usage.

Customer Data Protection

All data transferred between tenants and Eclipse APIs are encapsulated in a TLS1.2+ encrypted tunnel. This encryption terminates on an AWS load balancer that then re-encrypts it and passes it to private subnets for processing within Ukheshe applications. When data is stored, it is AES 256 bit encrypted at rest with keys only available to Ukheshe. This encryption-in-transit and encryption-at-rest apply to all customer personal data, documents and transactions. Very similar technology used for PCI/DSS compliance in card data security is mirrored in the security of customer data.