Rules
Configure scoring rules for the transactions
enc_U2FsdGVkX181SijNEhWCknpt2VpIKmHs5Jm7VIxQWeATbJzhvI1R5QGvGbzoLzdqYlPvf+AIXPiB1CCZ6zDONA==_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_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