Projet 4 : UBO DataBase

Cuni Frédéric-A14
Université de Technologie de Compiègne - Département Génie Informatique 1/13
Projet 4 : UBO DataBase
1 Genèse du projet
1.1 Définition
Pragma : application en ligne où les potentiels clients acceptent une offre proposée par
Alter Domus (services pour les sociétés ou les fonds),
CAC : le Client Acceptance est un processus selon lequel tous les nouveaux clients sont
identifiés jusqu’à l’ultime bénéficiaire et formellement acceptés par le Comité d’Acceptation
Client avant le début de la prestation de services.
Phytagoras : base de données mondiale permettant de connaître les personnes à risque ou à
risque potentiel.
AD Connect : portail de stockage de documents d’Alter Domus (GED) : gestion électronique
des documents
MDM : Master Data est une base de données de Alter Domus qui récence les clients, les
employés et les personnes rattachés aux clients ou investisseuses,
eFront : est une DB qui permet de gérer les investisseurs associés à des fonds, et de gérer les
fonds eux-mêmes.
1.2 Explications
Alter Domus propose des offres de gestion de fond, comme évoqué dans la présentation de
l’entreprise. Cela signifie qu’un fond peut être levé et par conséquent que des investisseurs
participeront à ce fond, qu’ils soient une personne physique ou morale (entreprises).
Dans le cas d’une personne morale, il existe un ou plusieurs UBO rattachés. Un UBO
(Ultimate Beneficial Owner) est la personne physique qui est le propriétaire le plus haut des
bénéfices. C’est lui qui touche l’argent en bout de chaîne.

Cuni Frédéric-A14
Université de Technologie de Compiègne - Département Génie Informatique 2/13
Il est primordiale de connaître ces UBO car il se peut qu’ils soient des terroristes ou
participent à du blanchiment d’argent. Dans ce cas Alter Domus doit les dénoncer aux
autorités compétentes et donc doivent disposer d’un outil permettant d’investiguer ces UBO et
de les référencer (d’où le nom de UBO database).
Actuellement, lorsqu’une offre est acceptée dans Pragma, elle est envoyée au CAC qui se
charge de l’acceptation client.
Le CAC fait un examen manuel du client dans Pythagoras, qui leur fournit un rapport en
retour qui sera injecté dans AD Connect.
Le client, une fois accepté, est créé dans la base de données MDM.
Lorsqu’un nouvel investisseur est associé à un fond, les employés envoient les informations le
concernant au business qui le rentre dans un fichier Excel.
Ce fichier est ensuite injecté dans Pythagoras une fois par mois par l’équipe Delivery.
Les UBO sont donc répertoriés dans un fichier Excel ce qui pose des problèmes de sécurité,
de maintenance et de lisibilité du fichier.
2 Spécifications
Lorsque j’ai commencé ce projet, les spécifications de ce dernier n’étaient pas réalisées. C’est
pourquoi de nombreux meeting furent organisés avec l’équipe business pour comprendre les
attentes et le travail à réaliser.
D’où le nom du projet, Alter Domus souhaitait avoir une base de données UBO qui référencie
les différents fonds gérés par la société, tous les investisseurs ainsi que les personnes
physiques ou morales au-dessus de ceux-ci, avec, en haut de la chaine, les UBO. La
conception de la base de données étant la première partie du travail.
Dans un second temps, il m’a été demandé de charger les UBO existants du fichier Excel dans
la base de données à l’aide d’un ETL, et de charger des données de la base de données MDM
vers UBO toujours à l’aide d’un ETL.
3 Réalisation

Cuni Frédéric-A14
Université de Technologie de Compiègne - Département Génie Informatique 3/13
3.1 Base de données UBO
La base de données UBO comprend donc deux types de personnes : les entités, elles peuvent
être des fonds, des entités réglementées,… ; et les individus.
Il existera des relations entre ces personnes par exemple investisseur, promoteur, UBO,
directeur, … et un statut qui définit cette relation (active, inactive,…).
Des documents seront également présents au niveau d’une personne (carte d’identité,
passeport,…) et un statut qui définit les documents référencés (conforme, non conforme, pas
reçu,…).
Dans un premier temps, une base de données indépendante UBO fut créée en respectant les
spécialités ci-dessus. Cependant, un problème est survenu : la duplication des données. En
effet, la base de données MDM (Master Data) recense les clients, les employés et les
personnes rattachés aux clients ou investisseurs, ce qui signifie que de nombreuses données
seront dupliquées entre Master Data et UBO si celle-ci est une base de données indépendante.
Il a donc été décidé de créer un schéma SQL UBO dans Master Data pour éviter de dupliquer
des informations, ce qui signifie que les nouveaux investisseurs par exemple seront créés dans
Master Data et dans UBO, lié par un ID (identifiant), et les relations seront donc faites dans le
schéma SQL UBO.
On peut voir dans la figure du schéma SQL UBO ci-dessous, qu’un Record peut être de type
Individu ou Entité, qui sont tous deux liés à la table Country en ce qui concerne le lieu
d’activité, le lieu de naissance,…
Une table RiskRating est liée à cette table pour spécifier le risque lié au Record en question.
La table Record est liée à la table PERSONS de Master Date, car comme expliqué
précédemment, une personne peut être physique (individus) ou morale (entité). C’est donc
une table de lien avec Master Data.
Les clients d’Alter Domus ne sont que des entités, c’est pourquoi la table LegalEntityInfo est
liée à la table CLIENTS de Master Data. Cette donnée peut être nulle lorsqu’une nouvelle
entité est ajoutée à un fond mais que celle-ci n’est pas client chez Alter Domus, juste
investisseur.
On peut voir la table Relationships, qui correspond aux relations entre les Record, c’est
pourquoi il y a un double lien entre la table Relationships et Record, avec une table Status

Cuni Frédéric-A14
Université de Technologie de Compiègne - Département Génie Informatique 4/13
pour spécifier le statut de la relation, et une table RelationType pour spécifier le type de
relation.
Un Record peut avoir plusieurs documents, c’est pourquoi une table intermédiaire
RecordDocuments est créée entre la table Record et la table Documents, pour eviter une
relation n -> n entre ces tables. Une table DocumentType est liée à la table Document pour
spécifier le type de document, ainsi que le statut avec la table DocumentStatus.
Une table IndividualFatcaInfo est également ajoutée pour pouvoir envoyer les informations
nécessaires au Fisc américain comme expliqué dans la partie projet web.
FIGURE 45 : Schéma SQL UBO dans Master Data
3.2 Migrations des données existantes

Cuni Frédéric-A14
Université de Technologie de Compiègne - Département Génie Informatique 5/13
3.2.1 Présentation du fichier Excel actuel
Les données existantes sont dans un fichier Excel et il faut les intégrer dans le schéma SQL
avec les relations appropriées.
Pour des raisons de confidentialité, je ne peux exposer le fichier Excel.
La syntaxe du fichier est visible sur la figure ci-dessous.
Lorsque la colonne « Investor ID » n’est pas nulle cela signifie que l’entité ou l’individu en
question à un lien directement avec le fond.
Au contraire, lorsque cette colonne est nulle mais que la colonne « Link ID » ne l’est pas, cela
signifie que l’entité ou l’individu en question à un lien avec l’identifiant de cette colonne.
Ces liens sont définis par la colonne « Partner Role ».
Dans les exemples créés de ma propre initiative sur la figure, on peut constater :
- une entité factice appelé « Fred Corporation » qui est investisseuse dans le fond
« Fond Test » avec un « Investor ID » de 10,
- un individu « CUNI Frédéric » qui est UBO de l’entité « Fred Corporation » comme
on peut le voir dans la colonne « Link ID » qui vaut 10,
- un autre individu « Durant Claude » qui est investisseur direct du fond « Fond Test »
avec un « Investor ID » de 2.
FIGURE 46 : Exemple du fichier Excel des UBO actuel
3.2.2 ETL de migration des données du fichier Excel
Pour charger ces données dans le schéma SQL UBO, un ETL a été réalisé. Comme pour le
projet RiskMetrix Conversion, un SSIS fut utilisé, à la seule différence que pour ce projet, ce
SSIS n’est à lancer qu’une seule fois.
Le SSIS comporte les étapes suivantes :