3. Digital Profile¶

The digital profile is the main trak.e resource. Its goal is to consolidate all customer information to perform the KYC process: risk, transactional profile, contact details, tax information, etc.

In addition, its an extensible resource to handle customer-specific information not covered in trak.e model. A digital profile may represent information about a person of physical existence, or of people of ideal existence (legal persons and other organizations).

erDiagram
    DigitalProfile ||--o{ Relation: has
    DigitalProfile ||--o{ ContactInfo: has
    DigitalProfile ||--o{ Tax: has
    DigitalProfile ||--o{ Address: has
    DigitalProfile ||--o{ EconomicActivity: has
    DigitalProfile |o--o| TypePerson: is_one_of
    TypePerson     |o--o| NaturalPerson: is_one_of
    TypePerson     |o--o| LegalPerson: is_one_of
    NaturalPerson  |o--o| Name: has

    DigitalProfile {
      string id
      int created_at
      int modified_at
      string created_by
      string modified_by
      int version
      string tax_payer_id
      string name
      string person_type
      string risk
      int risk_calculated_at
      string external_ref
      string state
      int transactional_profile_amount
      int transactional_profile_calculated_at
      int blacklists_checked_at
      int last_due_diligence_at
      int declared_income

    }

    NaturalPerson {
      int birth_date
      string birth_place
      string id_number
      string id_type
      string id_country
      string nationality
      string civil_state
      string classification
      bool is_employee
    }

    Name {
      string first
      string middle
      string last
    }

    LegalPerson {
      string constitution
      bool is_listed_on_stock_exchange
      int foundation_date
      string foundation_place
    }

    ContactInfo {
      string contact_type
      string value
      string description
      bool main
      bool is_verified
    }

    Relation {
        string profile_id
        string relationship
    }

    Tax {
      string code
      string description
      string inscription_date
      string jurisdiction
      string organization
    }

    Address {
      string address_type
      bool main
      string country
      string state
      string city
      string department
      string zip_code
      string street_name
      string number
      string building_name
      string building_floor_number
      string building_room_number
      string formatted_address
      string normalization_method
    }

      EconomicActivity {
      string code
      string description
      bool main
      string organization
    }

3.1 Digital Profile Properties¶

3.1.1 Basic Information¶

A digital profile contains the following basic information:

• A unique identifier id which is used to reference this digital profile.
• Timestamp of the profile creation: created_at.
• Timestamp of the last update to the profile: modified_at.
• Name of the user or application that created the profile: created_by.
• Name of the user or application that last modified the profile: modified_by.
• Profile version number: version. All changes made to the profile are saved for latter consultation and audit. For more information see History.
• Tax payer id: tax_payer_id. For example, for Argentinian tax payer, this is the CUIT number.
• Full name of the (physical or legal) person: name.
• Person type: person_type. As mentioned above, the profiles can represent information of a natural or a legal person. Therefore, the posible values for this attribute are: natural_person and legal_person.
• Risk level associated with this profile: risk. Trak.e addopts a risk-based approach to Anti-Money Laundering and Combating the Financing of Terrorism (PLA/CFT), as recommended by national and international regulators. The spirit of this approach is to address the practices of AML/CFT on a proportional way to the risk of each customer of engaging on those activities. Therefore, the client portfolio is classified in three classes (high, medium and low risk) and more or less strict continuous due diligence measures are applied depending of the specific risk of each customer. This risk may be injected by an external system, or can be assessed by trak.e from a given parametrization. For more information, see Risk Matrix.
• Transactional profile associated with the profile: transactional_profile_amount. This amount represents the estimated behavior of the customer with the entity. It may be expressed annualy or monthly. This transactional profile may be injected by an external system or assessed by trak.e from a given parametrization. For more information, see Transactional Profile.
• Timestamp of the last risk assessment made by trak.e: risk_calculated_at.
• Timestamp of the last transactional profile assessment made by trak.e: transactional_profile_calculated_at.
• Timestamp of the last Watchlists check against the predefined set of checks: blacklists_checked_at.
• Timestamp of the last continuous due diligence conducted on the profile, if it applies: last_due_diligence_at.
• An optional external reference, which allows to keep in trak.e the unique identifier of this customer in external systems: external_ref.
• The state of the profile: state. The state of each profile allows defining workflows and interact with it. For more information, see Workflows.
• Declared Income: declared_income. A number that represents the declared income, if it applies.

3.1.1.1 For natural persons¶

• Name: For natural persons, it is supported to add the name using its parts first, middle and last. The general name, used for watchlist monitoring, will be formed by concatenating these parts.
• Birth date: birth_date.
• Birth place: birth_place.
• Identification number: id_number. For example, in Argentina this is the National Document of Identity, but this vary greatly from country to country.
• Identification type: id_type.
• Identification country: id_country. Following ISO 3166-1 Alpha-2 standard.
• Nationality: nationality.
• Gender: The gender of the customer. Must be one of the following values: male, female, other.
• Civil State: civil_state. Must be one of the following values: single,married,widowed,divorced,separated,civil_union,domestic_partnership or other.
• Impositive Classification: classification. Classification for federal taxes. For example, "Sole Propietorship", "Employee", "Retired", etc.
• In addition, a profile can be marked as an employee of the entity using is_employee. This allows taking special due diligence measures on customers that are also employees of the company.

{
"created_at":1624649377044,
"modified_at":1624649377290,
"created_by":"smart_operador",
"modified_by":"smart_operador",
"name":"John Doe",
"tax_payer_id":"20-39499655-9",
"person_type":"natural_person",
"natural_person":{
    "name":{
      "first":"John",
      "middle":"",
      "last":"Doe"
    },
    "birth_date":865987200000,
    "birth_place":"Vicente López, Provincia de Buenos Aires, Argentina",
    "id_number":"39499655",
    "id_type":"national_identity_card",
    "id_country":"ar",
    "nationality":"Argentina",
    "civil_state":"single",
    "classification":"monotributista",
    "gender":"male",
    "is_employee":false
},
"version":2,
"state":"creating",
"blacklists_checked_at":1624649377278,
"last_due_diligence_at":1624573651797,
"id":"60d62ea15857d9d371b6d4d3"
}

3.1.1.2 For legal persons¶

• Constitution: constitution. For example, single owner, LLC, etc.
• Foundation date: foundation_date.
• Foundation Place: foundation_place.
• Additionaly, it can be marked if the entity is listed on a stock exchange using the property: is_listed_on_stock_exchange.

{
  "created_at":1624650046220,
  "modified_at":1624650046220,
  "created_by":"smart_operador",
  "modified_by":"smart_operador",
  "name":"Araoz S.R.L.",
  "tax_payer_id":"33-96669665-8",
  "person_type":"legal_person",
  "legal_person":{
      "constitution":"society_limited_liability",
      "is_listed_on_stock_exchange":false,
      "foundation_date":1276041600000,
  },
  "version":1,
  "state":"creating",
  "last_due_diligence_at":1624573651797,
  "id":"60d6313e5857d9d371b6d4fa"
}

3.1.1.3 Declared information¶

The digital profile contains a declaration attribute where a summary of the mandatory sworn statement of each customer can be reported. This object supports 4 keys:

• PEP (pep). It should be true if the user reported that he is a politically exposed person during onboarding or at another time, false if he reported that he is not a politically exposed person. It also supports the value null which indicates that the information is not known.
• Obligated Subject (obligated_subject). It should be true if the user reported that he is a supervised entity during onboarding or at another time, false if he reported that he is not a reporter. It also supports the value null which indicates that the information is not known.
• FATCA (fatca): Indicates if the customer is a US resident who has investments outside that country (FATCA Law applies). As in the previous cases, it accepts a boolean or a null value to indicate that the information is not known.
• OECD (oecd): No use currently - replaced by FATCA.

Additionally, it is allowed to report:

• Type of PEP (pep_type): Type of Politically Exposed Person. This field allows arbitrary strings but it is strongly recommended to define an enum during integration to limit the possible values.
• Supervised Entity Type (obligated_subject_type): Type of Supervised Entity. This field allows arbitrary strings but it is strongly recommended to define an enum during integration to limit the possible values.
• Date of registration of the supervised entity (obligated_subject_date): Date of registration of the supervised entity - if applicable. This should be an integer representing a date in milliseconds since epoch¹.
• oecd_main_country: Main country or jurisdiction of main residence for the purposes of applying the FATCA/OECD law, if applicable.
• oecd_main_tax_payer_id: Taxpayer number in the main country if applicable.
• oecd_secondary_country: Secondary country or additional jurisdiction of residence for the purposes of applying the FATCA/OECD law, if applicable.
• oecd_secondary_tax_payer_id: Taxpayer number in the secondary country if applicable.
• fatca_ssn: US social security number for citizens under FATCA/OECD law.

It should be noted that these attributes are at the top-level of the file and not within the declarations object.

3.1.1.4 Information in lists.¶

Trak.e can store in the digital profile a summary of the watchlists monitoring (for more information see Lists). If you want this information to be updated automatically following the resolutions of list alert cases, you can configure a process automation rule to achieve this. The blacklist_found object has one key per type of list supported in the service (pep, obligated_subject, sanctioned, wanted, terrorism, etc.) and each key maps to an object with two keys :

• hit: It marks if it had a hit in any list of this type or not.
• confirmed: Which marks if the hit was confirmed or not by a PLD analyst.

3.1.2 Contact details¶

Each profile can have one or several associated contacts. Valid contact types are email, mobile phone or landline. In addition to the value of the contact, a description of the contact can be saved if necessary.

Within the contacts associated with a profile, one of each type can be determined as the main contact. That is, you can have one primary email and one primary mobile phone, but you cannot have two primary emails. You can also mark if the contact has been verified.

...
"contacts": [
  {
      "contact_type":"email",
      "value":"administracion@araoz.com.ar",
      "description":"Casilla de correo de administración de Araoz S.R.L.",
      "main":true,
      "is_verified":true
  }
]
...

3.1.3 Address details¶

Each profile can have one or several associated addresses. At most one can be defined as the main address. An address can be:

• A personal address: The place where a natural person lives. (address_type=personal)
• Fiscal or tax domicile: The headquarters of a legal entity. (address_type=fiscal)
• Legal domicile: The place where the regulator presumes that a (natural or legal) person resides permanently to exercise their rights and fulfill their obligations, regardless of whether they are actually there or not. (address_type=legal)

The properties of each address are structured as follows:

Additionally, the address can be saved already formatted using some normalization method using the formatted_address and normalization_method pair of attributes. Additional relevant information can be stored in key-value format in the extra attribute.

...
"addresses": [
  {
      "address_type":"legal",
      "main":true,
      "building_name":"",
      "building_floor_number":"",
      "building_room_number":"",
      "formatted_address":"",
      "normalization_method":"",
      "country":"Argentina",
      "state":"Santa Fe",
      "city":"Rosario",
      "department":"Rosario",
      "zip_code":"S2000",
      "street_name":"Córdoba",
      "number":"1748"
  }
]
...

3.1.4 Economic Activity¶

A profile can be associated with one or more economic activities. Each economic activity is specified with the name of the regulatory organization, the economic activity code, and a description of the economic activity. The list of economic activities is configurable by tenant. An economic activity can be highlighted as the main one.

...
"activities": [
  {
      "code":"11501",
      "organization":"AFIP",
      "main":true,
      "description":"Cultivo de algodón"
  }
]
...

3.1.5 Tax information.¶

A profile can be associated with one or more taxes. Each tax is specified with the name of the regulatory organization, the tax code, and a description of the tax. Additionally, if applicable, the jurisdiction and the date of registration can be saved. The jurisdiction may be federal, non-federal, or local. The list of taxes to be used is configurable by each tenant.

...
"taxes": [
    {
        "code":"20",
        "jurisdiction":"country",
        "organization":"AFIP",
        "description":"MONOTRIBUTO",
        "inscription_date":1529020800000
    }
  ]
...

3.1.6 Associated documentation¶

See the chapter on Documentation Handling

3.1.7 Linked profiles¶

A profile can be linked to other profiles. To relate two profiles, an array of relations is saved under the property relations. Each member of the array is an object with a profile_id property, set to the unique identifier of the profile (as a string). This is useful for linking profiles that share certain transactionality, profiles of relatives of a politically exposed person, etc.

The type of the relation must be a valid relation type. Trak.e offers the following default relation types:

• Bussiness partner: Used to relate profiles of a legal person with the profiles of the natural personas who have an economic participation in it.
• Guarantor: Used to relate a profile with the profiles of people who have provided guarantees to it (normally used in the granting of loans).
• Legal representative: Used relate the profiles of a legal persons with the profiles of the eople who can operate on their behalf.

Trak.e services offers the possibility of expanding this enumeration with the types that each entity considers necessary to represent its bussiness.

In addition, the possibility of saving additional information (in key-value format) for each relation is offered.

3.1.8 Labels/Tags¶

A profile can be marked using arbitrary strings as tags. A label has a minumum length of 2 characters and a maximum of 20 characters.

3.1.9 Additional Information¶

All the additional information you want can be saved in the profile in key-value format. Trak.e allows each client to configure in a json schema² the structure of this additional information. This specification will allow validation and standardization of the additional information.

For example, if we want to have information on a person's accounts we can define:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/product.schema.json",
  "title": "ACME",
  "description": "Additional Information for the profiles of ACME",
  "type": "object",
  "properties": {
    "accounts": {
      "description": "Customer's accounts",
      "type": "array",
      "items": {
        "type": "string"
      },
      "minItems": 1,
      "uniqueItems": true
    }
  }
}

After defining the schema, we can save and access the information on the profile using the property metadata.accounts.

It should be noted that in the absence of a schema, the additional information can also be saved in the file, but no validation will be carried out nor will there be support for manual entry.

3.2 History¶

All the changes made to the profile are saved along with the moment and the user or application that made the change. The versions of the profile are numbered and start from 1. Each change is an object where the profile is referenced by its unique identifier (orig_id), the version number immediately previous, and an array of changes. Each change in the profile is, in turn, an array of three components:

• Operation: change, add, remove.
• Path of the modified property: When the modified property is at the top-level of the object, this is simply the string that identifies that key. For nested objects, it is a list of strings and integers, specifying the path to the property. The string must be represented as keys in (sub)objects, and the integers are indexes in arrays.
• Values: When the operation is a change, it is an array of two values (the old value first, and then the new value). In case of add and remove operation, it shows first the key that was inserted or removed and then the value that was added/removed.

...
"changes": [
    [
      "change",
      "modified_at",
      [
        1624648537726,
        1624648551709
      ]
    ],
    [
      "change",
      "modified_by",
      [
        "admin",
        "operador"
      ]
    ],
    [
      "add",
      "legal_person",
      [
        [
          "constitution",
          "horizontal_property_consortium"
        ]
      ]
    ],
    [
      "change",
      "version",
      [
        1,
        2
      ]
    ]
  ]
...

3.3 Workflows¶

The profiles have an attribute that specifies in which state they are in. The default states of trak.e, and their suggested semantics are:

• Creating (creating): The digital profile is in process of creating and the required information is not yet available.
• Active (active): The digital profile has been completed y is an active customer of the entity.
• Banned (banned): The digital profile has been banned by an operator or supervisor.
• Inactive (inactive): The digital profile is an inactive customer of the entity.
• Pending (pending): The profile needs to be reviewed by an operator.
• Under review (under_review): The digital profile is being reviewed by an operator or supervisor.

You can additionally define all the states that the entity considers necessary. The semantics of each state are suggested because each entity can implement the workflow that best suits their needs.

3.3.1 Default Workflow¶

Trak.e has a default profile status workflow that can be tailored to the needs of each client.

graph TD
  creating --> pending

  pending --> under_review

  under_review -- blacklist checked &<br> risk calculatded &<br> no open incidents --> active
  under_review --> banned
  under_review --> inactive
  under_review --> creating

  active --> pending
  banned --> pending
  inactive --> pending

This workflow can be achieved with the following parameters:

[
  { "source": "creating", "dest": "pending" },
  { "source": "pending", "dest": "under_review" },
  {
    "source": "under_review",
    "dest": "active",
    "condition": "dprofile.blacklists_checked_at != None and dprofile.risk != None and dprofile.open_cases == 0"
  },
  { "source": "under_review", "dest": "banned" },
  { "source": "under_review", "dest": "inactive" },
  { "source": "under_review", "dest": "creating" },
  { "source": "active", "dest": "pending" },
  { "source": "banned", "dest": "pending" },
  { "source": "inactive", "dest": "pending" }
]

Each transition has a source and destination nodes representing the current state and the desired states respectively. In addition, it may have a condition that has to be met in orden to execute the transition (condition). The available states after a given states depends on the transitions and the conditions that are assessed in that moment.

The conditions have two arguments, the current profile and the security context of the current operator. The condition must be a valid Python expression.³

Python dict objects may be accessed with Javascript dot syntax, in case of missing key the field None value would be returned.

The profile contains all the information discussed above.

For example:

  ...
  {
    "source": "under_review",
    "dest": "active",
    "condition": "dprofile.blacklists_checked_at != None and dprofile.risk != None and dprofile.open_cases == 0"
  }
  ...

This transitions allows you to pass a profile from under_review to active if you have run the watchlists screening, assesed their risk and have no open alerts.

The security context includes the property scope, that is a list of the scopes of the user/application that is using trak.e. In that way, we can define that only users with scope AML Supervisor can transition from under_review to banned using the following condition:

  ...
  { "source": "under_review", "dest": "banned", "condition": "'tenant_aml_operator' in context.scope"},
  ...

3.3.2 Example: Maker & Checker Workflow¶

For example, if we aim to implement a maker & checker schema if the risk is high o does not met some other condition, we can use the following workflow

graph TD
  creating --> pending

  pending --> under_review

  pending -- blacklist checked &<br> risk calculated &<br> no open incidents &<br> risk not high --> active
  under_review -- high risk or open cases --> pending_approval

  pending_approval -- user is supervisor --> active
  pending_approval -- user is supervisor --> banned
  pending_approval -- user is supervisor --> inactive
  pending_approval -- user is supervisor --> creating

  active --> pending
  banned --> pending
  inactive --> pending

The following is the configuration for the maker & checker workflow

[
  { "source": "creating", "dest": "pending" },
  { "source": "pending", "dest": "under_review" },
  {
    "source": "under_review",
    "dest": "active",
    "condition": "dprofile.blacklists_checked_at != None and dprofile.risk != None and dprofile.risk != 'high' and dprofile.open_cases == 0"
  },
  { "source": "under_review", "dest": "pending_approval" },
  {
    "source": "pending_approval",
    "dest": "active",
    "condition": "'tenant_backoffice_supervisor' in context.scope"
  },
  {
    "source": "pending_approval",
    "dest": "banned",
    "condition": "'tenant_backoffice_supervisor' in context.scope"
  },
  {
    "source": "pending_approval",
    "dest": "inactive",
    "condition": "'tenant_backoffice_supervisor' in context.scope"
  },
  {
    "source": "pending_approval",
    "dest": "creating",
    "condition": "'tenant_backoffice_supervisor' in context.scope"
  },
  { "source": "active", "dest": "pending" },
  { "source": "banned", "dest": "pending" },
  { "source": "inactive", "dest": "pending" }
]

3.4 Comments¶

Each user of Trak.e Web can add comments to the profile that you consider relevant. These comments are in rich text format. The comments are linked to the user who made them. In addition, the date and hour of the comment is saved. A user may edit or delete the comment that they have made, but can only see comments made by other people. The uses with the "Watcher" scope can see all the comments, but can't add new comments.

3.5 Web Research¶

From the data in the profile, web queries can be generated in search engines that help the KYC process.

3.6 Resources¶

3.7 API Documentation¶

API