Programmé en UVINT170
Présentation :
1) Détection de saisonnalité
Améliorer la connaissance client permet aux entreprises de proposer des services adaptés à leurs besoins mais permet également, dans le domaine bancaire, de mesurer certains risques afin d’adapter le panel d’offres accessibles aux clients. Dans ce contexte, nous souhaitons mieux connaitre le profil de dépenses/revenus de nos clients en analysant le solde quotidien de leurs comptes, afin notamment d’identifier leurs dépenses exceptionnelles.
Le sujet proposé consiste à détecter la saisonnalité du solde des comptes bancaires afin d’identifier les dépenses/revenus dits « courants/habituels » (salaires, primes, CAF…) puisque cela nous permettra d’isoler des dépenses/revenus « exceptionnels » (achat d’une voiture, d’un vélo, recevoir de l’argent d’un héritage, pour un anniversaire…). La détection de saisonnalité peut donc être vue comme une détection de pattern, de récurrence que l’on essayera d’isoler par la suit.
Le Crédit Mutuel Arkea ayant des millions de clients, tous n’auront pas le même type de saisonnalité (prime trimestriel, payement hebdomadaire …), comment peut-on détecter de façon automatique la ou les périodicités de ces comptes?
Ex : Mme JEAN reçoit un salaire mensuel et paie sa facture d’électricité mensuellement mais sa facture de Gaz trimestriellement => Cette personne aura donc 2 saisonnalités : mensuelle et trimestrielle
Problématiques connues :
- Les mois ne comportant pas toujours le même nombre de jours, comment gérer les décalages de période ?
- Quelles sont les périodes (nombre de jours) à prendre en compte ? (La vision hebdomadaire est-elle une maille trop fine ?)
- La série est-elle saisonnière
2) Profilage statistique des contrôles
L'architecture de notre système d'information impose une publication des données par métier afin d'alimenter les traitements des autres métiers.
Nous avons donc un bus de données (solution interne CIA) permettant :
- de définir les données,
- de les publier sous forme de CRE
- de les router entre le producteur et le consommateur.
Il est aujourd’hui possible de publier des données en COBOL, en JAVA et en PIG
A chaque publication d’un CRE, nous calculons un ensemble d’indicateur générique (fonction du format de la variable) et spécifique (règles métier).
Ces indicateurs sont aujourd’hui restitués sous un IHM « go/rfdp » pour consultation par les métiers et ils servent à qualifier la justesse de la publication.
Objectifs (obsolète):
1)
Identifier au mieux les différentes saisonnalités, et inversement, les exceptions.
Une approche de clusterisation pourra également être proposée pour catégoriser les comportements, et ainsi, affiner les actions retours.
Certaines techniques de traitement du signal pourraient être intéressante…
2)
Nous cherchons à mettre en place une solution pour identifier et qualifier une non qualité (ponctuelle ou progressive) de façon automatique, sans sollicitation du producteur (sans positionnement de règles ou de jalon).
Une alerte sera alors envoyée aux interlocuteurs correspondant, elle permettra d’interrompre le processus de publication si besoin.
Une critique des indicateurs en place est à envisager.
Pré-requis :
1)
Présentation par ARKEA de :
- L’approche big data du groupe
- Formation et première approche PIG / et statistique R
Maitriser le socle technologique :
- Peu de préquis technique, bonne culture générale informatique / algorithmie.
Esprit disruptif, ne pas avoir peur de proposer une démarche différentiante et innovante.
2)
Présentation par ARKEA de :
- la solution interne de publication go/rfdp
- la mécanique des indicateurs
- du MCD de la base des indicateurs
Maitriser le socle technologique :
- MySql stockage des indicateurs
- PIG, JAVA sous HDFS pour l’implémentation des indicateurs
- TOMCAT, JAVA GWT pour la restitution des indicateurs
Liens :
2)
Liens interne non consultable de l’extérieur : go/doccia, go/rfdp, go/methodes, go/codelabs, …
Volume horaire :
h
Année 2016/2017
Dernière mise à jour le 24-OCT-16
Validation par le responsable de programme le
|
