enc_U2FsdGVkX181SijNEhWCknpt2VpIKmHs5Jm7VIxQWeATbJzhvI1R5QGvGbzoLzdqYlPvf+AIXPiB1CCZ6zDONA==_enc

NumberNeed HelpDescription
0Montant > 100 000 € alors delayed
1XCondition éléments à risque ? QUID ?
2Si première transaction date de moins de N jours:
- Si le niveau de risque est HIGH
— Si moyenne sur les 30 derniers jours est > 75% de la moyenne depuis l’ouverture du compte alors delayed
- Si le niveau de risque est MEDIUM
— Si moyenne sur les 30 derniers jours est > 100% de la moyenne depuis l’ouverture du compte alors delayed
- Si le niveau de risque est LOW
— Si moyenne sur les 30 derniers jours est > 150% de la moyenne depuis l’ouverture du compte alors delayed
Sinon
— Si moyenne sur les 30 derniers jours est > 30% de la moyenne sur les 120 derniers jours alors delayed
3Si l’opération n’est pas dans l’intervale de confiance ([0 ; 2*moyenne]) de la moyenne des opérations sur les 30 jours précédents alors delayed
4Si ticket avec tag “KYT” non fermé alors transaction delayed
5Si première transaction date de moins de N jours, ou c’est la première transaction alors delayed
6Si virement entrant avec non match nom titulaire
- Si de type IP et si risque est LOW -> alors allowed
Sinon alors delayed
7Virement entrant dont la contrepartie est dans une black list alors delayed
8Risque de solde y compris en caspooling
9Virement sortant et compte non autorisé alors blocked
10Compte innactif alors blocked
11XVolume avec cette contrepartie sur les 30 derniers jours dépasse un seuil (fixe ?) alors blocked
12XCanal compte actif ?
13Si compte ouvert depuis moins de 60 jours ET risque client MEDIUM ou HIGH ET virement sortant
- Si solde final < 100€
— Si sur les 5 dernier jours (entrant - sortant) / entrant < 5% alors blocked
14Destinataire blacklisté alors blocked (matrice de risque)
15Contrepartie DS = true ou matrice de risque sur les IBANs
16IBAN suspect (matrice de risque)
17Virements entrant bloqués alors delayed
18BIC institution possède une alerte ouverte ou true hit ou présent dans matrice de risque
19Mots clés détectés dans XML sur jusque 4 champs et dépendant du type de transaction, semble matcher avec matrice de risque
20Si customer HIGH RISK
- 1er flux entrant ayant lieu à +45 jours après une date custom (signature CGU)

enc_U2FsdGVkX19MkTKd2pmJEOt46XRUU+wgcb+vJGVBgI/Ci1TzGmgG0IqJtp7X8rtM_enc

enc_U2FsdGVkX1/YkHxXUACIwACMoBb0xAe+exNQTVjITio=_enc

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

enc_U2FsdGVkX1+cQULlfzpeZJaTrwZQvOEMyf9c4Vx/7FXgKqna3nmP9DhtdtZE5LTO_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/cZRM6DVS25aYHrS5W2OE1hySHlkYBi5s=_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_U2FsdGVkX1831Ad8Ryytfgsy5ygYbwibWIo2F9ICusk=_enc

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

enc_U2FsdGVkX18AunpJONrnm4zsEXmTgUOBkhTkz4ItiZDagCm9bVmyIdfkaRcxNO5I_enc

enc_U2FsdGVkX19778k/UU2OlOYzkd0QDAtE50a/5MksSGBu+zHxzfCSz4ZCg0YnPaEFvmuVfXn65tnxXc+VqLs0w/m8s9nbZECxeIlZYM5yRqo=_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_U2FsdGVkX18Kyo3gBFPtpGm/F3BESFDuUj8TtMvsFGs=_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