Analýza vazeb věřitelů a dlužníků

Vypracovaly: Andrea Daněčková & Iva Křečková

Existují podezřelé či rizikové vztahy mezi dlužníky a věřiteli? Pokud ano,
je možné takové vztahy zachytit a identifikovat skrze grafovou databázi? Dokážeme díky NoSQL databázi odhalit nepoctivé a závadné jednání
i v případě, že se nejedná o přímý vztah mezi účastníky insolvenčního řízení? Existují lokality, kde je insolvenční řízení častějším jevem?

Abychom mohly ověřit výše definované hypotézy, rozhodly jsme se použit open source kepler.gl pro zpracování mapy na podkladě lokálních dat.
Pro stěžejní zpracování projektu jsme zvolily neo4j. Jde o typ databáze, který je navržený speciálně pro ukládání a správu grafových dat.
Grafy se zde ukládají jako struktury skládající se z uzlů (vrcholů) a hran, které definované uzly propojují. Potenciál antifraud systémů můžeme vidět právě u grafových databází, což je obzvláště užitečné v případech,
kdy je potřeba modelovat komplexní vztahy mezi daty.

Náš datový model

Zdrojem dat našeho projektu je Insolvenční rejstřík (dále jen “ISIR”)
a Administrativní registr ekonomických subjektů (dále jen “ARES”). Připravit raw data nám pomohl náš mentor, Vít Baisa, za což mu patří velké díky. Od vytvořeného datového modelu, se následně odvíjela veškerá naše práce s daty.

Statistika našich dat z Neo4j

Na základě rodného čísla (dále jen “RC”) a identifikačního čísla (dále jen “IC”) bylo definováno pět vstupních uzlů: ADRESA, OSOBA, OSVC, FIRMA, SPRAVCE a příslušný ISIR_PRIPAD (pro potřeby kódu jsou názvy uvedeny
bez diakritiky). Bohužel se během čistění a transformace dat ukázalo,
že největší problém bude záznam adres u jednotlivých účastníků insolvenčního řízení. Neexistuje zřejmě žádný jednotný template,
podle kterého by byly adresy do obou použitých rejstříků zadávány.
Adresa nám měla dále posloužit jako jeden z podstatných rozlišovacích atributů, abychom mohly propojit vazbu na úrovni OSOBA a FIRMA, protože přes RC to nebylo možné. Tahle nekompatibilita dat však byla zřejmá již při prvním seznámení s raw daty. Bohužel se ukázalo, že na této úrovni nebude možné velké množství případů propojit ani tímto způsobem, právě kvůli nevyplnění příslušné adresy.

Adresa je rovněž významným nositelem informace, např. pro mapování DLUZNIKů, aby bylo možné lokalizovat vyloučené oblasti. Plán sociálního začleňování statutárního města Brna pro období 2022–2027 uvádí, že počet osob v exekuci k 31.12. 2021 činil 24 968 osob a jejich podíl na počtu obyvatel 6,6 %. Celkem bylo vedeno 204 538 exekucí, celkový dluh dosahoval 11,4 mld. Kč. V příloze k analýze sociálního vyloučení je uveden výčet ulic města Brna, které determinují sociálně vyloučené lokality, což jsme chtěly skrze naše data rovněž určit. Aby to bylo možné, musely jsme převést adresy díky kódu v Pythonu na souřadnice, které byly nezbytné
pro následné zanesení bodů do mapy kepler.gl:

import pandas as pd
from geopy.geocoders import Nominatim

df = pd.read_csv('dluznici_firmy_id.csv')

geolocator = Nominatim(user_agent='my_app')

def get_coordinates(row):
    address = f"{row['psc']} {row['mesto']} {row['ulice']}"
    location = geolocator.geocode(address)
    if location:
        row['latitude'] = location.latitude
        row['longitude'] = location.longitude
    return row

df = df.apply(get_coordinates, axis=1)
df.to_csv('kepler_dluznici_firmy.csv', index=False)

Jelikož jsme si i toto chtěly vyzkoušet, nenechaly jsme se odradit ani neúplností adresních bodů.

Vizualizace — adresy OSOB v oddlužení

Pokud bychom měly k dispozice více informací o účastnících vstupujících do konkrétního insolvenčního případu, bylo by možné provést křížové ověření u shodné adresy, např. SPRAVCE i VERITELe. Jak například hodnotit vztah, když dva VERITELé sdílí stejnou adresu? Nebo případ,
kdy na stejné adrese je evidován jak DLUZNIK, tak VERITEL? Znamená to, že se skutečně znají, nebo je to jen náhoda?

Lze předpokládat, že v následujících letech budou sociální sítě nápomocny při zodpovězení otevřených otázek podobného druhu, stejně jako nabídnou součinnost mezi účastníky řízení. Možná tomu jednou bude tak, že zamítavé stanovisko bude na základě vazby na podvodníka, který bude figurovat mezi přáteli na sociálních sítích, a tato vazba bude detekována skrze grafové databáze.

Právě díky projektu jsme zjišťovaly, zda to skutečně může fungovat? Jakým způsobem je možné získat informace o vztahu OSOBA a FIRMA, FIRMA
a FIRMA, když se nejedná o přímý vztah.
Předpokládáme totiž, že podezření sílí s četností funkcí, které jedna OSOBA zaujímá v uzlu FIRMA. Obdobně předpokládáme, že četnost vazeb subjektu FIRMA k (dalším) subjektům FIRMA, může ukazovat na jiné než běžné chování. Nejlépe je to patrné na konkrétním případě, viz níže:

Vytvoření uzlů bylo v našem projektu asi to nejjednodušší. Ačkoliv se zdálo, že uzlů a vazeb není mnoho, při vytváření jednotlivých propojení se ukázalo, že je mnohdy obtížné neztratit hlavu v množství IC, aby se vztah znázornil žádoucím způsobem a poskytl správné informace o účastnících jedinečného případu. Je nutné počítat s duplicitami. Proto je potřeba průběžně prověřovat, zda se v konkrétní fázi jedná o jedinečnost účastníka či případ. Nebo nikoliv.

import pandas as pd

df = pd.read_csv(‘OSOBA(fosoby)(all).csv’, dtype=str)
print(len(df))
firmy = pd.read_csv(‘FIRMA(ALL).csv’, dtype=str)

# Propojeni pres ico
merged_df = pd.merge(df, firmy, on=‘ico’, how=‘left’)
merged_df = merged_df[merged_df[‘ico’].notnull() & (merged_df[‘ico’].astype(str) != ‘’)]
merged_df[‘id’] = range(1, 1 + len(merged_df))
merged_df = merged_df.loc[:, [‘id’, ‘id_x’, ‘id_y’, ‘nazev_funkce’]]
merged_df.rename(columns = {‘id_x’:‘id_osoba’}, inplace = True)
merged_df.rename(columns = {‘id_y’:‘id_firma’}, inplace = True)
merged_df = merged_df[merged_df[‘id_firma’].notnull() & (merged_df[‘id_firma’].astype(str) != ‘’)]

merged_df.to_csv(‘VAZBA-OSOBA(fosoby)-FIRMA(ALL).csv’, index=False)

Jeden insolvenční případ má minimálně dva subjekty. Status jednotlivých účastníků insolvence se může lišit případ od případu. Insolvenční řízení může vzniknout opakovaně. Různé variace a opakovatelnost nám neubírala rozsah dat, ale naopak. To nám několikrát vystavilo na čas stopku, protože kapacita počítače byla pro některé úkony na hranici proveditelnosti. Vytváření vazeb probíhalo často v noci a následné ráno se ne vždy ukázalo jako dobré. Ne všechny nalezené rady na internetu zafungovaly, ale i přes množství zádrhelů, bylo nakonec vše v neo4j zobrazeno. První pokusy
o vkládání skrze využití knihovny py2neo se ukázaly jako neefektivní. Úspěšnější byl import dat přes cypher:

CREATE CONSTRAINT isirIdConstraint FOR (isir:ISIR) REQUIRE isir.id IS UNIQUE
:auto LOAD CSV WITH HEADERS FROM ‘file:///ISIR.csv’ AS csvLine
CALL {
WITH csvLine
CREATE (i:ISIR {id: toString(csvLine.id), soud:csvLine.soud, senat:csvLine.senat, state:csvLine.state, www:csvLine.www})
} IN TRANSACTIONS OF 2 ROWS

S každým náhodně rozbaleným uzlem vzrůstala zvědavost, protože právě vazby mezi uzly, které jsou neviditelné na první pohled, jsme chtěly nalézt. Široké a složité větvení přes několik navazujících uzlů. To vše tam bylo, ale nelze hledat jehlu v kupce sena. Takže následovalo sepsání několika dotazů, které např. odselektovaly přímé vazby a nízké četnosti.

Vazby náměstka ministerstva vnitra — na případ upozornil kverulant.org (odkaz)

V tuhle chvíli lze detekovat podezřelé případy. I když oba datasety pocházejí z veřejně přístupných dat, ale obsahují vysoce citlivé informace, bylo by žádoucí prokázat, že se opravdu jedná o nekalé praktiky, nebo naopak taková tvrzení vyvrátit ověřením z jiných zdrojů. Před pár dny byl zveřejněn na internetu článek upozorňující na vazby Radomíra Daňhela, což je rovněž doloženo výše znázorněnou vizualizací — graf četných vazeb souvisejících právě se jmenovaným náměstkem ministra spravedlnosti
na základě našich dat a zpracováním v neo4j.

Pro trh může být FIRMA nadále lukrativní i přes to, že je v konkurzu. Zde nedochází u oddlužení k přidělování SPRAVCE kolečkem, tedy náhodně. Našim doporučením by bylo propojit data s registrem uzavřených smluv, dotacemi a lobbisty. Ve státní správě by pak takový systém zjišťování vztahů a vazeb zpětně do minulosti, měl být použit všude tam, kde dochází k přerozdělování a platbám z veřejných financí. Hlídač státu je jednou z možností, kde lze konfrontovat “známé firmy”.

Závěr

Naše dvojice měla od začátku jasno, chtěly jsme pracovat na projektu, který bude svým tématem i použitými nástroji jedinečný, alespoň v rámci Czechitas. A to se snad podařilo, protože jsme si vyzkoušely, jak v praxi využit Jupiter Notebook, Python (a jeho knihovny: pandas, py2neo, geopy) Deepnote, arrows.app, neoDash, kepler.gl. Náš mentor nás rovněž podpořil v prvotní myšlence, vyzkoušet si na projektu zpracování a analýzu dat právě v neo4j. Děkujeme, že jsi byl ochoten s námi na projektu spolupracovat a potvrdit v úvodu definované hypotézy. Máme za to, že nás projekt konkrétně ukázal, že pomocí grafové databáze lze identifikovat a zachytit podezřelé a rizikové vztahy. A to i v případě, že se nejedná o přímý vztah mezi účastníky insolvenčního řízení.

Iva Křečková:

Práce na projektu vytváření grafové databáze mi poskytla tolik cenných zkušeností a dovedností, že mi je až líto, že to celé končí. Za největší přínos projektu vnímám hlavně zkušenost s čištěním a transformací dat, kde jsme
z počátku tápaly, ale postupně se naše dovednosti v tomto směru zlepšily — ruku v ruce i s analytickým a logickým myšlením v této obasti. Při práci
s daty se ukázal jako můj největší kamarád Python — a programování jako nová vášeň, které se rozhodně budu věnovat i nadále. Oceňuji i praktickou zkušenost s neo4j, kde jsme se postupně naučily jak i v tak složitých datech identifikovat klíčové entity, určit správné vztahy i pochopit celou strukturu grafové databáze. Velkou školou praxe byla i skvělá týmová spolupráce, rozdělování si úkolů, sdílení myšlenek a nápadů, koordinace celého projektu a time-management. Jsem ráda, že mi byla parťačkou právě Andrea, její nadšení pro projekt a ochota místo spánku v noci kontrolovat, jestli se nám správně nahrává a vytváří neo4j databáze, byli obdivuhodné.

Andrea Daněčková:

Na úplném začátku jsem se potřebovala zorientovat a pochopit, jak propojit tři soboury z ISIRu a tři soubory z ARESu, jež jsme měly k dispozici. To bylo určující pro sestavení datového modelu pro neo4j za použití nástroje arrows.app. Takto vytvořený model totiž posloužil jako průvodce všemi následujícími činnostmi. Jelikož jsme si toto sdíleli v Deepnote, mohla jsem se spolehnout na to, že mi Iva připraví data tak, abych je mohla zkusit implementovat do neo4j. Soubory byly ve formátu csv pro jednotlivé uzly a vazby. Čím více jsme se nořily do práce na projektu, sdílely si dílčí výsledky, posouvaly jsme se ku předu v představě, co bychom měly ještě udělat, zahrnout, vyzkoušet. Tím, že jsme vyslovily nahlas nějakou myšlenku, napadaly nás další a další souvislosti. Takže moje práce byla možná individuální jen při importu dat, což byla asi ta časově nejnáročnější část, protože žádná z nás neměla k dispozici počítač, který by byl vyloženě konfigurován pro přesun takového objemu dat, se kterým jsme nakonec pracovaly. Jsem ráda, že jsem na zpracování projektu nebyla sama, protože ve dvojici jsme mohly diskutovat problémy, které se vyskytly, probrat specifické případy, které se objevily v průběhu kontroly správnosti dat. Potvrdilo se, že čím více je jedinec ponořen do určité části projektu, může mu nechtíc uniknout celek, takže skvělá parťačka je rozhodně neopomenutelná. A když naše vlastní pokusy selhávaly, náš mentor nás dokázal navést opět správným směrem.