Skip to main content

​
enc_U2FsdGVkX19kLf5sjcDqT/e/Ba0m88ldIml2wGMwO27fQ4VxxN126oxbiqImEisPfFDz/WY20Af8mQKg2tVTxg==_enc

​
enc_U2FsdGVkX1/ciIGIRVQlhDJHEMpnCu+V2d6mFG1aZrSEzY9dRXMSRKexhjKxseFa_enc

​
enc_U2FsdGVkX1+81H3RPS6pjvZp3pvjBQNCakdkfpLeGzM=_enc

  • (13, 8) solde après transaction (utilise un champ personnalisé)

​
enc_U2FsdGVkX1+FxmiBrpv1XSoNNIQPnKoAsIxowWsQ0AosUdIiPzA0uCgc5de0BkmR_enc

  • (6) Données “non match noms” entre nom titulaire et virement reçu -> ajouté à la transaction lorsque ingérée
  • (4) présence de ticket avec un certains status et tag -> nouveau computed field
  • (2, 20, 13, 6) Utilisation du niveau de risque du customer (global ou pour une selection de règles) -> nouveau computed field
  • (2, 3, 13) Volume (entrant, sortant, tout, mais aussi par couples A->B, et par moyen de paiement) moyen, somme, nombre, fréquence sur N jours, on peut mettre N à 1, 3, 5, 7, 15, 30, 45, 60, 90, 120, 180, 270, 365, all, stocker une liste [in, to_abc, card, 1225] mise en cache
  • (18) Alerte ouverte sur une institution (ajout external_id sur les instututions ?)

​
enc_U2FsdGVkX1+II+V8+Zud88b0/OK5QuHZMhot2FDMyVI=_enc

  • (19, 16, 14, 7, 18) Matrice de regexes utilisées comme whitelist, blacklist et autre
  • (20) Opérations entre variables ex. 45 + date > today

​
enc_U2FsdGVkX18Au4CN3Kh3XA7LgxjHBpi5o4fcZSo8uRE=_enc

  • ❌ (20) Modification de valeurs internes suite à l’évaluation d’une règle (ex. première transaction post 45 jours faite)

​
enc_U2FsdGVkX19OMMmWuVXTvgsJVuKJFl+CTi3bbOg2/uYEZDaDWeQSSHB7cJcXN6qb_enc

​
enc_U2FsdGVkX18aPzpD0oicunqMNmK2jogNB9cDaPTE8Acai7+r5E14n7VMTOlkbRYil4wjdvZZlUkRIaH0aihMmoP/awKVRbDGptQDgdOJJuQ=_enc

  • key: edge
  • type: in, out, both
  • period of time: 30, 60, 90, all (4 fields)
  • aggregation: sum, max, min, count
  • key: node
  • type: in, out, both
  • period of time: 1, 3, 7, 15, 30, 45, 60, 90, 180, 365, all (12 fields)
    • 1 to 7 days and “all”: updated in realtime (cache transactions, up to 1M transactions total in memory ~ 10mb * replication as transaction has multiple participants)
    • 15 to 365 days: updated daily (cron process to read db and compute the values)
  • aggregation: sum, max, min, count
180 doubles fields ~ 2kb per node/edge Operations when receiving a transactions, we must be under 200ms:
  • Perform authentication (stateless ok)
  • Run a compare names
  • Run the rules themselves
  • Get currencies values (-> on redis)
  • Get list of rules to execute (-> could be on redis with a fallback to db)
  • Get matrices (-> could be on redis with a fallback to db)
  • Save transaction (send it to a queue)
Questions are on:
  • Get up to 4 customers with all data available (heavy json and can’t be on redis, high perf key-value db ? RocksDb ?)
  • Get rolling values
    • Computation is slow, big dataset -> cannot be on redis, both high-perf key-value and timeseries to compute mising values ? -> Timeseries will be too slow too probably

​
enc_U2FsdGVkX19xBwAx6o0df9pyMHtZd69mGaC069PiiWg=_enc

  • 900mb RAM for 11M transactions over 100 000 customers
  • Format [timestamp, amount, …10 random ints] et temps d’importation 60s environ
  • Ex of retrieving a customer transactions (~20K transactions): Number of elements for customer customer_uuid122: 19808 Time redis: 25 ms Time json: 36 ms Sum, avg, max, min, standard déviation for customer customer_uuid122: 99345.02429868079 5.0153990457734645 9.99943153101794 0.0006231945074009 2.8921330350568666 Time: 55 ms