Co to jest monetyzacja danych ?
Monetyzacja danych oznacza wykorzystywanie zgromadzonych informacji i danych klientów w celu generowania przychodów lub zysków. Jest to praktyka, która staje się coraz bardziej popularna w erze cyfrowej, gdzie przedsiębiorstwa gromadzą ogromne ilości danych o swoich klientach i ich transakcjach. Oto kilka produktów, dla których można ‘monetyzować’ dane na przykładzie branży bankowej:
- Personalizacja ofert i usług: Banki mogą wykorzystywać dane o zachowaniach finansowych klientów, aby dostosować oferty i usługi do ich indywidualnych potrzeb
- Analiza ryzyka i ocena kredytowa: Dane klientów pozwalają bankom na dokładniejszą analizę ryzyka i ocenę kredytową. Dzięki temu mogą one podejmować bardziej trafne decyzje dotyczące udzielania kredytów i innych produktów finansowych
- Sprzedaż danych: Banki mogą zdecydować się na sprzedaż anonimizowanych lub agregowanych danych klientów innym firmom, takim jak firmy badawcze, agencje marketingowe lub instytucje rządowe
- Programy partnerskie i marketing: Banki mogą nawiązywać współpracę z firmami zewnętrznymi i oferować im dostęp do swojej bazy klientów w zamian za udział w przychodach lub opłaty za reklamę.
- Rozwój nowych produktów i usług: Dostęp do danych klientów może pomóc bankom w identyfikowaniu nowych trendów i potrzeb rynkowych
- Zwiększona retencja klientów: Banki mogą wykorzystywać dane do analizy zachowań klientów i identyfikowania tych, którzy są zagrożeni odejściem do konkurencyjnych instytucji finansowych
Warto zaznaczyć, że monetyzacja danych musi być przeprowadzana z uwzględnieniem przepisów dotyczących ochrony danych osobowych, takich jak RODO / GDPR w Europie, aby zapewnić prywatność i bezpieczeństwo klientów.
Zanim przejedziemy dalej wyjaśnienia wymaga jeszcze pojęcie ‘Data Product’ (ang.) użytego na potrzeby tego artykułu. ‘Produkt Danych’ to rodzaj produktu lub usługi zbudowanej wokół wykorzystania danych i analiz w celu zapewnienia wartości użytkownikom lub klientom. Na ‘Data Product’ mogą się składać się takie elementy jak: dane, procesy biznesowe, właścicielstwo danych, metryki jakościowe, raporty, modele danych, systemy, interfejsy, powiązane metadata, definicje i słowniki danych itp., a więc wszystko co łączy się bezpośrednio, lub bezpośrednio z ‘DAMA Wheel’
Przykład analizy Ryzyka i Ocena Kredytowa
1. Wprowadzenie
W niniejszym artykule skupimy się na przykładzie ‘Produktu Danych’ dot. Ryzyka Kredytowego i Oceny Zdolności Kredytowej Dla Klienta Biznesowego, ale w analogiczny sposób można przeprowadzić analizę dla każdego innego produktu, klienta lub segmentu zarówno z obszaru danych branży finansowej jak i nie finansowej, jednak należy zaznaczyć, iż kluczem do sukcesu jest zrozumienia wszystkich elementów związanych z danym produktem.
2. Business Case
W ramach omawianego przykładu bierzemy pod uwagę proces kalkulacji ratingu klienta biznesowego w oparciu o dane pochodzące z systemów źródłowych Banku i wpływu tej kalkulacji na inne modele takie jak Risk Weight Asset (RWA) oraz Economic Capital (EC) przy uwzględnieniu procesów agregacji i transformacji danych wykorzystujących tzw. ‘Critical Data Elements’ (CDE) – w naszym przypadku ‘Typ Księgowości’ (Accouting Type), gdzie błąd w danych prowadzi do zniekształcenia danych, a co za tym idzie dalszych błędnych wyników końcowych. Warto nadmienić, iż CDEs powinny zostać skatalogowane w dedykowanym Katalogu Danych
Poniżej znajduje się uproszczony diagram (diagram nr 1) pokazujący wpływ ww. błędu w polu ‘Accouting Type’ (3) (Typ Księgowości) na poszczególne modele, a w następstwie na wyliczanie parametrów RWA i Economic Capital Demand (EC) – oczywiście jest to wersja ‘bardzo’ uproszczona 🙂
W praktyce każda zmienna tzw. ‘Input Variable’, która wpływa na jakikolwiek model danych (LGD, PD, EL etc.) włączając w to modele ML/AI niesie za sobą ryzyko błędnej kalkulacji modelu i wzrostu ponoszonych kosztów np. rezerwy, wymogi kapitałowe itp. lub błędnych decyzji podjętych przez człowieka lub… komputer w oparciu o te dane 
.
Aby uniknąć takich ‘błędów’ oraz pomyłek, które mogą generować straty finansowe, Regulator w ramach m.in regulacji BCBS239 ustalił 3 główne obszary , które winny być monitorowane wraz z określonymi wymogami (BCBS239 Priniciples from 1 to 11).
Obszary te możemy podzielić na:
Warto nadmienić, iż przy wprowadzeniu powyższych wymogów pomoże nam DAMA jako, że zawiera wszystkie elementy potrzebne do wypełnienia postanowień BCBS 239 po stworzeniu odpowiedniego ‘Planu i Konceptu Wdrożenia BCBS 239’
W dalszej kolejności DAMA może nam pomóc zaadresować inne wymogi regulacyjne np. BCBC239, GDPR , Target Review Internal Model (TRIM) , IFRS9 requirements, Capital Requirements Regulation (CRR) lub wiele innych, które można znaleźć na poniższej stronie: Interactive Single Rulebook
3. Analiza i działania
3.1 Analiza Przyczyny Błędu (Root Cause Analysis):
Brak wprowadzonego we właściwy sposób ‘Typu Księgowości’ przez pracownika banku (1 minute task) dla jednego klienta w systemie operacyjnym, którego ekspozycja wynosi 1 mln EUR skutkuje brakiem możliwości użycia ‘technik redukcji ryzyka’ i zgodnie z wymogami BASEL dotworzeniem rezerw, a przez to dodatkowych Wymogów Kapitałowych również na poziomie 1 mln EUR .
3.2 Wniosek pokontrolny:
Jeżeli w Banku byłoby takich 100 klientów, dla których brak jest wprowadzonej poprawnej wartości tylko w jednym polu to Bank musi dotworzyć z dnia na dzień o ca 95% więcej rezerw i wymogów kapitałowych niż to jest wymagane przez regulatora dla danej ekspozycji, jeżeli błąd nie istnieje .
3.3 Rekomendowane Działania:
- Zbudowanie ‘Przepływu Procesu Danych’ dla każdego modelu (Data Lineage)
- Identyfikacja zmiennych wpływających na model i zaszeregowanie ich jako tzw. ‘Critical Data Elements’ (CDE) (patrz również drugi diagram – część Model Owner)
- Identyfikacja i dokumentacja sposobów agragacji, transofrmacji i właścicielstwa danych przy pomocy ‘Procesu Przypływu Danych’ (Data Lineage) i Katalogu Danych (Data Katalog)
- Określenie wymogów na potrzeby ‘Monitorowania Jakości Danych’ (Data Observability) np. Business DQ Rules, Technical DQ Rules, Integgration DQ Rules i wdrożenie w narzędziu do ‘Monitorowania Jakości Danych’ na poszczególnych etapach ‘Lineage’ (patrz również drugi diagram – część DQ Ownership & Issue)
- Porównując dane (przed błędem vs po błędzie) możemy określić wpływ, a więc dokonać ‘monetyzacji’ oraz wyliczyć ROI dla Data Governance*
*Należy pamiętać, żę aby wyliczyć ROI dla Data Governance, warto wdrożyć wszystkie wymagane elementy #DAMA (Data Governance, Data Quality & Data Operation), gdyż trudno jest wyliczyć ROI i tylko dla jednego z nich
Załączniki
Wykres 1 – Mapa Danych / Model Koncepcyjny:
Wykres 2 – Przykład Przepływu Danych (Data Lineage Topic):
