Skip to main content
Version: 2.31.00

Subject Entities on eXate Platform

Subject Entity Type

Subject Entity Type is the subsection of the Subject Entities which have to be selected by the User when trying to add a new Subject Entity.

For this example we will be setting up the following Subject Entity Types:

  1. Client

  2. VIP (Additional Approval Required)

  3. VIP Plus (Additional Approval Required)

  4. Sanctioned (Additional Approval Required)

Subject Entities

Subject entities are used to depict how Subject Entities and Applications are mapped together with their respective identifiers.

When we view a specific Subject Entity then the description is shown to us like this:

![alt text](image.png)

These are the General Details which are filled by the User while creating a Subject Entity:

  • Unique Username: It should have a Unique Name. Note: No duplicate Subject Entities are possible.

  • Subject Entity Type: This is one of the modules of the Static Data Management which were discussed above.

  • Country of Origin: The Country where the User belongs.

  • Nationality: The Nationality used by the User.

  • Domicile: The permanent country of the User.

  • Right to be Forgotten: The right to be forgotten is the right to have private information about a person be removed from Internet searches and other directories under some circumstances. This toggle can be “Yes” or “No”.

For this example we will be setting up the following Subject Entities:

  • Joe (Associated with Subject Entity Type: Client)

  • Smith (Associated with Subject Entity Type: Client and Country of Origin: Luxembourg)

  • Jeff B (Associated with Subject Entity Type: VIP)

  • Mac (Associated with Subject Entity Type: VIP Plus)

Users

For this example we will be setting up the following Users:

  1. Relationship Manager 1 (Access to Subject Entity 'VIP')

  2. Relationship Manger 2 (Access to Subject Entity ‘VIP Plus’)

  3. Compliance Manager B (Access to Subject Entity ‘VIP, VIP Plus and Sanctioned’)

Claims

You can add ‘Claim Packs’ to rules (what we call the “Boolean Engine”). The boolean engine finds claims based on matching rules. Anything that is passed through the eXate API can be called by our engine, which then checks if there is a match.

For this example we will be using the following claims:

[
{
"attributeName": "ADGroup",
"attributeValue": "Relationship Management"
},
{
"attributeName": "Device",
"attributeValue": "Corp Device"
},
{
"attributeName": "ValidWorkhours",
"attributeValue": "True"
}
]

![alt text](image.png)

Rule Pack

To create a rule pack, navigate to the “+” button, this will provide you with a pop-up that requires you to input the “Name” and “Description” to get started. With the rule pack created, you can now create individual rules within that rule pack that you can customise to your needs.

In the rule pack you can add:

  • Attributes: A set/collection of many Attributes on which the rules are applied

  • Countries in Scope: Due to a variety of strict regulations limiting how data is shared, this tool will help you limit how data is accessed and processed for a particular country. This way, individual countries are put in a scope and you are able to limit where a country's data is stored and what other countries it can share data with.

  • Claims: Add relevant claim packs to your rule.

  • Purpose of Use: Select cases of data usage for your rule

For this example we will be adding:

Attributes:

  • Customer

  • Date of Birth

  • First Name

  • Last Name

Countries:

  • United Kingdom

  • Luxembourg

Claims:

  • Sensitive Client Data Claim Pack

Purpose of Use:

  • Legitimate Use

API Configuration

When a sample payload is created. You can click the checkboxes of the attribute to protect. This will set the attribute to be anonymised going forward. A modal will appear to determine what type of attribute the data is and if it is linked to a data asset map it to the subject entity identifier. This tags the data with what the data is and who it belongs to.

HTML tree that matches the sample payload. When a sample payload has been added, edited and saved it will render a HTML that matches the structure of the sample payload that has been added. The tree has nodes which can be selected, when a node is selected it is reflected below in a table called selected attributes

The first column “Attribute Name” also shows the JSON path expression to identify that particular attribute. It is a unique path to be able to protect the information. The second column ‘Attribute Type’ allows you to name the attribute with lookup from the available attribute types.

The third column ‘Subject Entities’. Which displays a drop down menu when an attribute has been starred as a ‘Subject Entity ID’. This is to show if there are any unique identifiers associated with the payload. For example, if someone exercises the right to be forgotten we can uniquely identify that record we can support that use case.

For this example we will be using the following sample payload:

  • RM1
{
"persons": {
"person": [
{
"entity": "GB",
"entityId": "Jeff B",
"firstName": "Jeff",
"lastName": "Bezos",
"fullName": "Jeff Bezos",
"ssn": "Restricted Access",
"dob": "18121965"
},
{
"entity": "GB",
"entityId": "Joe",
"firstName": "Joe",
"lastName": "Bloggs",
"fullName": "Joe Bloggs",
"ssn": "Restricted Access",
"dob": "08011970"
}
]
}
}
  • RM2
{
"persons": {
"person": [
{
"entity": "GB",
"entityId": "Mac",
"firstName": "MacKenzie",
"lastName": "Scott",
"fullName": "MacKenzie Scott",
"ssn": "Restricted Access",
"dob": "18121965"
},
{
"entity": "GB",
"entityId": "Joe",
"firstName": "Joe",
"lastName": "Bloggs",
"fullName": "Joe Bloggs",
"ssn": "Restricted Access",
"dob": "08011970"
}
]
}
}
  • CM1
{
"persons": {
"person": [
{
"entity": "GB",
"entityId": "Jeff B",
"firstName": "Jeff",
"lastName": "Bezos",
"fullName": "Jeff Bezos",
"ssn": "Restricted Access",
"dob": "18121965"
},
{
"entity": "GB",
"entityId": "Mac",
"firstName": "MacKenzie",
"lastName": "Scott",
"fullName": "MacKenzie Scott",
"ssn": "Restricted Access",
"dob": "18121965"
},
{
"entity": "GB",
"entityId": "Joe",
"firstName": "Joe",
"lastName": "Bloggs",
"fullName": "Joe Bloggs",
"ssn": "Restricted Access",
"dob": "08011970"
},
{
"entity": "GB",
"entityId": "Roman",
"firstName": "Roman",
"lastName": "Abramovich",
"fullName": "Roman Abramovich",
"ssn": "Restricted Access",
"dob": "09121955"
}
]
}
}

Right to be Forgotten