3. Legajo digital¶

El legajo digital es el recurso principal de Trak.e. Su objetivo es consolidar toda la información del cliente para realizar el proceso KYC: riesgo, perfil transaccional, datos de contacto, información impositiva, etc. Además todos los recursos son extensibles para manejar información específica del cliente no contemplado en el modelo de Trak.e. Un legajo puede representar información de una persona de existencia física, o de personas de existencia ideal (personas jurídicas y otras organizaciones).

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 Atributos del legajo¶

3.1.1 Información básica¶

Un legajo contiene la siguiente información básica:

• Un identificador único id se utiliza internamente siempre que se quiera hacer referencia a este legajo.
• Fecha y hora de creación del legajo: created_at.
• Fecha y hora de la última modificación del legajo: modified_at.
• Nombre de usuario del operador o aplicación que creo el legajo: created_by.
• Nombre de usuario del operador o aplicación que modificó por última vez el legajo: modified_by.
• Número de versión del legajo: version. Todos los cambios que se hagan al legajo se guardan para su posterior consulta y auditoría. Para más información ver Historia.
• Número de identifiación tributaria: tax_payer_id. Para tributantes en Argentina, este es el número de CUIT.
• Nombre completo de la persona (física o jurídica): name.
• Tipo de persona: person_type. Como se mencionó anteriormente, los legajos en trak.e pueden representar información de una persona físca o de una persona jurídica. Por lo tanto, los valores posibles para este atributo son natural_person y legal_person.
• Nivel de riesgo asociado al legajo: risk. Trak.e adopta el enfoque basado en riesgos en materia de Prevención de Lavado de Activos y Financiamiento del terrorismo (PLA/FT) recomendado por reguladores internacionales y nacionales. El espiritú de este enfoque es abordar las practicas de PLA/FT de manera proporcional al riesgo de cada cliente de participar en estas actividades. Así, se clasifica la cartera de clientes en tres clases (riesgo alto, medio y bajo) y se aplican medidas de diligencia continua más o menos estrictas según el riesgo específico de cada cliente. Este riesgo puede ser inyectado desde un sistema externo, o puede ser evaluado por Trak.e a partir de una parametrización dada. Para más información ver Matriz de Riesgo.
• Perfil transaccional asociado al legajo: transactional_profile_amount. Este monto representa el comportamiento estimado de la transaccionalidad del cliente con respecto a la entidad. Puede estar expresado anualmente o mensualmente. Este perfil transaccional puede ser inyectado desde un sistema externo, o puede ser determinado por Trak.e a partir de una parametrización dada. Para más información ver Perfil Transaccional.
• Fecha y hora de la último evaluación de riesgo realizada por Trak.e: risk_calculated_at
• Fecha y hora del último cálculo de perfil transaccional_ transactional_profile_calculated_at.
• Fecha y hora del último control del legajo contra las listas de PLA/FT que se hayan definido: blacklists_checked_at.
• Fecha y hora de la ultima diligencia continua aplicada al legajo, si aplica: last_due_diligence_at.`
• Una referencia externa opcional, permite almacenar el identificador único del legajo en otros sistemas externos a Trak.e: external_ref.
• El estado del legajo: state. El estado de cada legajo permite definir flujos de trabajo e interactuar con el mismo. Para más información ver Workflows.
• Declaración de ingresos: declared_income. Un número que representa la declaración de ingresos del legajo, si corresponde.

3.1.1.1 Para personas físicas¶

• Nombre: Para las personas físicas se soporta agregar el nombre utilizando sus partes: first, middle y last. El nombre general, utilizado para el monitoreo en listas, se formará concatenando estas partes.
• Fecha de nacimiento: birth_date.
• Lugar de nacimiento: birth_place.
• Número de identificación: id_number. En Argentina corresponde al número de DNI o identificación equivalente.
• Tipo de identificación: id_type.
• País de identificación: id_country. Siguiendo el estándar ISO 3166-1 Alpha-2.
• Nacionalidad: nationality.
• Genero: gender. Uno de los siguientes: male, female, other.
• Estado civil: civil_state. Uno de los siguientes: single,married,widowed,divorced,separated,civil_union,domestic_partnership o other.
• Clasificación impositiva: classification. Monotributista, empleado en relación de dependencia, jubilado, etc.
• Adicionalmente, se puede marcar al legajo como un empleado utilizando el atributo is_employee. Esto permite realizar diligencias especiales a los legajos de aquellas personas físicas que además de ser clientes en la entidad, trabajen en la misma.

{
"created_at":1624649377044,
"modified_at":1624649377290,
"created_by":"smart_operador",
"modified_by":"smart_operador",
"name":"Juan Doe",
"tax_payer_id":"20-39499655-9",
"person_type":"natural_person",
"natural_person":{
    "name":{
      "first":"Juan",
      "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 Para personas jurídicas¶

• Forma jurídica: constitution. Sociedad anónima, Sociedad de Responsabilidad Limitada, cooperativa, etc.
• Fecha de fundación: foundation_date.
• Lugar de fundación: foundation_place.
• Adicionalmente se puede marcar si la entidad cotiza en alguna bolsa de valores utilizando el atributo 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 Información declarada¶

El legajo contiene un atributo declaration donde se puede informar un resumen de la declaración jurada obligatoria de cada legajo. Este objeto admite 4 claves:

• PEP (pep). Debería ser true si el usuario informó que es una persona expuesta politicamente durante el onboarding o en otro momento, false si informó que no es una persona expuesta politicamente. También admite el valor null que indica que no se conoce la información.
• Sujeto Obligado (obligated_subject). Debería ser true si el usuario informó que es un sujeto obligado durante el onboarding o en otro momento, false si informó que no es un sujeto obligado. También admite el valor null que indica que no se conoce la información.
• FATCA (fatca): Indica si el usuario es residente estadounidense que tenga inversiones fuera de ese país (aplica Ley FATCA). Al igual que en los casos anteriores acepta un booleano o un valor nulo para indicar que no se conoce la información.
• OCDE (oecd): Sin uso el uso actualmente - reemplazada por FATCA.

Adicionalmente, se permite informar:

• Tipo de PEP (pep_type): Tipo de Persona Expuesta Politicamente. Este campo permite strings arbitrarios pero se recomienda fuertemente definir un enumerado durante la integración para limitar los valores posibles.
• Tipo de Sujeto Obligado (obligated_subject_type): Tipo de Sujeto Obligado. Este campo permite strings arbitrarios pero se recomienda fuertemente definir un enumerado durante la integración para limitar los valores posibles.
• Fecha de registración del sujeto obligado (obligated_subject_date): Fecha de registración del sujeto obligado - si aplica. Este debería ser un entero representando una fecha en milisegundos desde el epoch¹.
• oecd_main_country: País principal o jurisdicción de residencia principal a los efectos de aplicar la ley FATCA/OCDE, si aplica.
• oecd_main_tax_payer_id: Número de contribuyente en el país principal si aplica.
• oecd_secondary_country: País secundario o o jurisdicción de residencia adicional a los efectos de aplicar la ley FATCA/OCDE, si aplica.
• oecd_secondary_tax_payer_id: Número de contribuyente en el país secundario si aplica.
• fatca_ssn: Número de seguridad social estadounidense para ciudadanos bajo ley FATCA/OCDE.

Cabe aclarar que estos atributos están en el top-level del legajo y no dentro del objeto declarations.

3.1.1.4 Información en listas.¶

Trak.e puede almacenar en el legajo un resumen del análisis del chequeo en listas (para más información ver Listas). Si se desea que esta información se actualice automáticamente siguiendo las resoluciones de los casos de alertas de listas puede configurarse una regla de automatización de procesos para lograrlo. El objeto blacklist_found tiene una clave por tipo de lista admitida en el servicio (pep, obligated_subject, sanctioned, wanted, terrorism, etc.) y cada clave mapea a un objeto con dos claves:

• hit: Que marca si tuvo hit en alguna lista de este tipo o no.
• confirmed: Que marca si el hit fue confirmado o no por un analista de PLD.

3.1.2 Información de contacto¶

Cada legajo puede tener uno o varios contactos asociados. Los tipos de contacto válido son correo electrónico, teléfono móvil o teléfono fijo. Además del valor del contacto se puede guardar una descripción del mismo si fuera necesario. Dentro de los contactos asociados a un legajo, se puede determinar uno de cada tipo como contacto principal. Es decir, se puede tener un correo electrónico principal y un teléfono móvil principal, pero no se puede tener dos correos electrónicos principales. Además se puede marcar en el contacto si este ha sido verificado.

...
"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 Información de domicilio¶

Cada legajo puede tener uno o varios domicilios asociados. A lo sumo uno puede ser definido como domicilio principal. Un domicilio puede ser:

• Domicilio personal: El lugar donde habita una persona física. (address_type=personal)
• Domicilio fiscal o tributario: La sede de una persona jurídica. (address_type=fiscal)
• Domicilio legal: El lugar donde el regulador presume que reside una persona (física o jurídica) de manera permanente para el ejercicio de sus derechos y el cumplimiento de sus obligaciones, independientemente de que realmente se encuentre allí o no. (address_type=legal)

Los campos de la dirección se encuentran estructurados en componentes:

Adicionalmente, puede guardarse la dirección ya formateada utilizando algún método de normalización utilizando el par de atributos formatted_address y normalization_method. Información adicional relevante puede ser guardada en formato clave-valor en el atributo extra.

...
"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 Actividad económica¶

Un legajo puede tener asociada una o varias actividades económicas. Cada actividad económica se especifica con el nombre de la organización reguladora, el código de actividad económica y una descripción de la misma. La lista de actividades económicas es configurable por cliente. Se puede destacar una actividad económica como la principal.

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

3.1.5 Información impositiva¶

Un legajo puede estar asociado a uno o más impuestos. Cada impuesto se especifica con el nombre de la organización reguladora, el código del impuesto y una descripción del mismo. Adicionalmente, si corresponde, puede guardarse a que jurisdicción corresponde (nacional, provincial, municipal) y la fecha de inscripción. La lista de impuestos a utilizar es configurable por cada cliente.

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

3.1.6 Documentación asociada¶

Ver el capítulo sobre Manejo de Documentación

3.1.7 Legajos relacionados¶

Un legajo puede estar relacionado con otros legajos. Si se quiere relacionar legajos, se guarda dentro del arreglo relations un objeto que defina en el atributo profile_id el identificador único del legajo (como un string). Esto es útil para vincular entre sí legajos que compartan cierta transaccionalidad, legajos de familiares de una persona expuestamente políticamente, etc.

El tipo de la relación debe ser un tipo de relación válido. Trak.e tiene de manera predefinida los siguientes tipos de relación:

• Socio de negocio: Utilizado para relacionar los legajos de una persona jurídica con los legajos de las personas físicas que tengan una participación economica en la misma.
• Garante: Utilizado para relacionar un legajo con los legajos de las personas que hayan aportado garantías al mismo (normalmente utilizado en la concesión de préstamos.)
• Representante legal: Utilizado para relacionar los legajos de una persona jurídica con los legajos de las personas que pueden operar en su representación.

El servicio ofrece la posibilidad de ampliar esta enumeración con los tipos que cada entidad considere necesarios para representar su negocio.

Además, se ofrece la posibilidad de guardar información adicional (en formato clave-valor) para cada relación.

3.1.8 Etiquetas¶

Se puede marcar el legajo utilizando strings arbitrarios como etiquetas. Una etiqueta tiene un a longitud mínima de 2 carácteres y máxima de 20 carácteres.

3.1.9 Información adicional¶

Se puede guardar en el legajo toda la información adicional que se desee en formato clave-valor. Trak.e permite a cada cliente configurar en un json schema² la estructura de esta información adicional. Esta especificación permitirá validar y normalizar la información adicional.

Por ejemplo si queremos tener en un legajo información de las cuentas comitentes de una persona podemos definir:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/product.schema.json",
  "title": "ACME",
  "description": "Información adicional legajo ACME",
  "type": "object",
  "properties": {
    "cuentas": {
      "description": "Cuentas comitentes del cliente",
      "type": "array",
      "items": {
        "type": "string"
      },
      "minItems": 1,
      "uniqueItems": true
    }
  }
}

Luego de definir el schema, podemos guardar y acceder a la información en el legajo utilizando el atributo metadata.cuentas. Cabe aclarar que ante la ausencia de un schema, igualmente se puede guardar la información adicional en el legajo, pero no se realizará ninguna validación ni tendrá soporte para el ingreso manual.

3.2 Importacion¶

3.2.1 Validaciones¶

• Se eliminan los caracteres unicode presentes en el nombre del archivo
• Se valida que el archivo posea solo una extension
• Se valida que la longitud del nombre del archivo sea menor a 255 caracteres
• Se valida que la extension del archivo este permitida (.csv, .txt)
• Se valida que el tamaño del archivo no exceda los 50gb
• Se infiere el tipo de MIME en base a la deteccion de numeros magicos y se valida contra los tipos MIME esperados ("text/plain", "text/csv")

3.3 Historia¶

Todos los cambios que se realicen sobre el legajo se guardan junto con el momento y el usuario o la aplicación que generó el cambio. Las versiones del legajo se pueden reconstruir en base a estos cambios. Las versiones están numeradas y comienzan desde 1. Cada cambio es un objeto donde se referencia el legajo por su identificador único (orig_id), el número de versión inmediatamente anterior y un arreglo de cambios. Cada cambio en este arreglo es, a su vez, un arreglo de 3 componentes:

• Operación: change, add, remove.
• Path del atributo modificado: Cuando el atributo modificado se encuentre en el top-level del objeto, es simplemente el string que identifica a la clave. Para objetos más anidados, es una lista de strings y enteros, especificando el path hasta el atributo. Los strings deben ser representados como claves en (sub)objetos, y los enteros como indices en arreglos.
• Valores: Cuando la operación es un cambio, es un arreglo de dos valores (el valor antiguo primero y luego el valor nuevo). En el caso de la operacion add y la operación remove se muestra primero la clave del objeto que se agregó o removió y luego el valor que se removió.

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

3.4 Workflows¶

Los legajos llevan un atributo que especifica en que estado se encuentra. Los estados predefinidos por Trak.e, y su semántica sugerida son:

• En creación (creating): El legajo se encuentra en proceso de creación y todavía no esta disponible toda la información requerida.
• Activo (active): El legajo está completo y forma parte de la cartera de clientes de la entidad.
• Bloqueado (banned): El legajo fue bloqueado por un operador o supervisor.
• Inactivo (inactive): El legajo dejó de operar con la entidad.
• Pendiente (pending): El legajo necesita ser revisado por un operador.
• Bajo revisión (under_review): El legajo está siendo revisado por un operador o un supervisor.

Se pueden definir adicionalmente todos los estados que la entidad considere necesarios. La semántica de cada estado es sugerida porque cada entidad puede implementar el workflow entre estados que mas se adecue a sus necesidades.

3.4.1 Workflows Default¶

Trak.e tiene un workflow de estados de legajos default que puede ser configurado a medida para las necesidades de cada cliente.

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

El workflow anterior se logra con la siguiente configuración.

[
  { "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" }
]

Cada transición tiene un source y destination que son el estado actual y destino respectivamente. Adicionalmente puede tener una condición la cual debe cumplirse para poder pasar de un estado a otro condition. Los estados disponibles en un estado dado depende de las transiciones que existen y las condiciones que se evalúan en el momento.

Las condiciones tienen dos argumentos, el legajo actual y el contexto de seguridad de quien está operando. La condición debe ser una expresión Python válida.³

Los dict pueden ser accedidos con dot syntax como un objeto Javascript, en caso de no existir el campo retorna None.

El legajo contiene toda la información discutida más arriba.

Por ejemplo:

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

Permite pasar un legajo de under_review a active si tiene el chequeo de listas ejecutado, riesgo evaluado y no tiene alertas abiertas.

El contexto de seguridad contiene el atributo scope, que es una lista de los roles del usuario o aplicación que está operando. Así, podríamos definir que sólo los usuarios con rol Supervisor de PLD puedan pasar de under_review a banned utilizando la siguiente condición

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

3.4.2 Ejemplo: Maker & Checker¶

Por ejemplo si queremos implementar un esquema de maker & checker si el riesgo es alto o no cumple alguna de las otras condiciones, podemos armar un workflow como el siguiente.

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

La siguiente es la configuración del workflow de maker & checker.

[
  { "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.5 Comentarios¶

Cada usuario de Trak.e Web puede agregar al legajo los comentarios que considere pertinentes. Dichos comentarios son en formato de texto enriquecido. Los comentarios quedan vinculados al usario que los agrego. Se guarda además la fecha y hora en la que fueron hechos. Un usuario puede editar o eliminar los comentarios que haya hecho, pero solo puede ver los comentarios hechos por otros usuarios. Los usuarios con rol Observador pueden ver todos los comentarios, pero no pueden agregar nuevos comentarios.

3.6 Búsqueda en la Web¶

A partir de los datos del legajo se pueden generar consultas en buscadores que ayuden al proceso de Conozca a su Cliente.

3.7 Recursos¶

3.8 Documentación API¶

API