Rules

​

enc_U2FsdGVkX19++OTkCLQwCnXPNf1hB5TwIIQzZeBRhyJGmLCHKyNOoqhIUaYJKP+oypuPmaJWxw3iKEn99Bbpcg==_enc

Number	Need Help	Description
0		Montant > 100 000 € alors delayed
1	X	Condition éléments à risque ? QUID ?
2		Si 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
3		Si 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
4		Si ticket avec tag “KYT” non fermé alors transaction delayed
5		Si première transaction date de moins de N jours, ou c’est la première transaction alors delayed
6		Si virement entrant avec non match nom titulaire - Si de type IP et si risque est LOW -> alors allowed Sinon alors delayed
7		Virement entrant dont la contrepartie est dans une black list alors delayed
8		Risque de solde y compris en caspooling
9		Virement sortant et compte non autorisé alors blocked
10		Compte innactif alors blocked
11	X	Volume avec cette contrepartie sur les 30 derniers jours dépasse un seuil (fixe ?) alors blocked
12	X	Canal compte actif ?
13		Si 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
14		Destinataire blacklisté alors blocked (matrice de risque)
15		Contrepartie DS = true ou matrice de risque sur les IBANs
16		IBAN suspect (matrice de risque)
17		Virements entrant bloqués alors delayed
18		BIC institution possède une alerte ouverte ou true hit ou présent dans matrice de risque
19		Mots clés détectés dans XML sur jusque 4 champs et dépendant du type de transaction, semble matcher avec matrice de risque
20		Si customer HIGH RISK - 1er flux entrant ayant lieu à +45 jours après une date custom (signature CGU)

​

enc_U2FsdGVkX1/5u0BEAMzANIC8GT6fkiH9pqOHhtIEW0NhxSqaphlFjV3+B1lDRejF_enc

​

enc_U2FsdGVkX19gnG+hOWkXlFgpkW/TC6Bl7Izloo/7JeE=_enc

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

​

enc_U2FsdGVkX1/T+ktGJZhbdZglQTKit/iAC5fhlEY/JpI5UCpsEogWha1bh6txZSjn_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_U2FsdGVkX19sD3N4e1GgY5aKzXn+ZiuthrT3gEmBdoI=_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_U2FsdGVkX1/OILc8LzDg7SccZttuNGBIl9By1XTu1mI=_enc

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

​

enc_U2FsdGVkX19aa3gJA3fSpZi7e/E72TZoMt1JnsgsBRCAFoiFepsY1TKxEyEFPlth_enc

​

enc_U2FsdGVkX1+2T7eUrMRLtvjO0bw17CzjR1nQcuQTKtYSaWj5Cz6Br0uTMKmwiOz8Nq5GU8aLZuBHiVPhgw8VSqo+HcqaVf62trIt6Up3M3I=_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_U2FsdGVkX18c9g+PY6tDertu+Cn8yMRKlwx3wKqvrnE=_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