AML - Listy Sankcyjne

AML (Anti-Money Laundering), zwane potocznie przeciwdziałaniem praniu brudnych pieniędzy, ale... również i wspieraniu terroryzmu, są to działania, mające na celu wykrycie i odpowiednie zaraportowanie podejrzanych transakcji, a nast. ich zablokowanie, włącznie z zamrożeniem konta osob podejrzanych.

Wymogi stosowania AML w spółkach finansowych nakładają stosowne organy, takie jak np. KNF, Komisja Europejska czy Departament Skarbu USA.

Te podmioty, publikują m.in. listy os. podejrzanych. Na takich listach znajduja się znani dyktatorzy, organizacje terrorystyczne, ale ost., po aneksji Krymu również przedstawiciele Rosjiego parlamentu zaangażowani w wojnę na Ukrainie.

Te listy, zwane listami sankcyjnymi, publikowane są w różnych formatach, np. XML. W związku z powyższym, zrobiłem jednolity parser kilku list do postaci obiektowej, przy okazji udostępniając część kodów źródłowych na githubie, aby ułatwić innym walkę z terroryzmem.

Listy sankcyjne, które zostały ograne w aplikacji to:

• Consolidated list of persons, groups and entities subject to EU financial sanctions
• Specially Designated Nationals List (SDN)
• Foreign Sanctions Evaders (FSE)
• Palestinian Legislative Council (PLC) List 

Projekt postanowiłem umieścić na githubie, zarówno pod moim profilem (link), jak i pod egidą .Net Developers Poland. Jeżeli ktoś ma ochotę do rozwijania tego projektu, to zdecydowanie zapraszam.

Linki:

• Link do projektu
• Departament Skarbu 
• Strona Komisjii Europejskiej

Simple.Data - rok później

Ponad rok temu, tj. w grudniu 2013 roku miałem okazję poznać nową bibliotekę, Simple.Data. Nawet zrobiłem nt. post na bloku w styczniu 2014 roku link. Teraz, po ponad roku komercyjnego używania tej biblioteki, mam na jej temat pewne przemyślenia, którymi chciałbym się podzielić.

Czym jest Simple.Data? Jest to jeden, z coraz popularniejszych "microORM", który łączy ze sobą zalety ORM, przy okazji nie narzucając zbyt dużo konfiguracji oraz "dodatkowych bajerów", które oferują tradycyjne ORM takie jak EF lub nHibernate.

Reklamowane zalety:
- szybkość aplikacji (szybszy dostęp do aplikacji)
- brak dodatkowej konfiguracji (biblioteka sama rozpoznaje nazwy tabel)
- mniejsza ilość kodu
- nowa, fajna składnia, wykorzystująca dynamic (np. db.highscores.FindAllByScore(2); )
- identyczna obsługa, dla wielu typów baz danych (włączając w to zarówno SQL jak i NoSQL)

Potencjalne wady:
- brak intellisense
- ewentualne problemy występuja dopiero w runtime

Tyle teorii, a teraz trochę praktyki:
- jak pokazuje prosty przykład (https://bitbucket.org/zchpit/sqlitesamples) Biblioteka Simple.Data jest ok 10 razy szybsza od EF (2500 ms vs 304 ms) jednak nadal ok 10 razy wolniejsza od klasycznego Data Reader (304 ms vs 17 ms).
- zaleta, w postaci automatycznego mapowania nazw tabel na nazwy obiektów nie zawsze się sprawdza, ponieważ często w istniejących bazach danych spotykałem się z polskimi nazwami tabel, a nazwy wszystkich zmiennych, klas, metod itp. w aplikacji wolę mieć po ang. więc... w pracy z istniejącymi rozwiązaniami i tak trzeba było wykonywać mapowanie
- inna składnia, która nie jest LINQ (fajny bajer, ale jednak wolał bym mieć również do dyspozycji również klasycznego LINQ)
- problem z aktualizacją modelu po zmianie na bazie danych, przez kogoś innego (np. administrator bazy danych)
- fajne, dla małych 1-2 os. aplikacji typu CRUD, które operują na małych bazach danych (np. 5-8 tabel)
- można zastosować dla baz, co do których mamy wątpliwości, czy zostaną obsłużone przez nHibernate lub EF.

Podsumowując, kiedy stosować, a kiedy nie stosować?


Nie stosować gdy:
- tworzymy duże rozwiązanie, przy którym będą niezależnie od siebie pracować programiści oraz BI. Brak możliwości automatycznego "update" modeli po stronie kodu, mocno utrudnia taką współpracę (choć oczywiście można się dogadać, co do używania procedur składowanych o niezmiennych parametrach).
- gdy najważniejszym parametrem jest szybkość działania aplikacji (nawet kosztem dłuższego czasu wytwarzania). W takich przypadkach lepszym rozwiązaniem będzie klasyczny Data Reader
- gdy pracujemy na istniejącej bazie danych, która w dodatku posiada polskie nazwy tabel, proc. składowanych itp. -> nieaktualne (patrz komentarz na końcu)
- gdy pracujemy na istniejącej, dużej bazie danych i spodziewamy się mnóstwa złączeń itp. W takich przypadkach jednak osobiście wolę wygenerować sobie Model automatycznie, mieć Intelii Sense oraz używać klasycznego LINQ a nie co chwila googlować jak to połączyć w nowej składni.

Kiedy stosować microORM
- gdy dostajemy do zrobienia od zera nową, stosunkowo małą aplikację typu CRUD, która ma pobrać dane z jednego źródła, przetworzyć je i zapisać gdzieś indziej np. z bazy X pobieramy naszych gości naszej super konferencji, z publicznego API pobieramy listę sankcyjną ludzi publicznie objętych zakazem wjazdu do UE, matchujemy obie listy, a wynik tego machowania zapisujemy do osobnej bazy danych.


Edit: od napisania tego posta, minął niecały tydź., ale miałem okazję bywać w kilku miejscach, więc mały update
a) O kwestie związane z aktualną bazą danych, na której mamy polskie nazwy tabel, a zmienne w aplikacji (viewModel), czyli "gdy chcemy mieć po ang. to czy musimy robić ręczne mapowanie?" zapytałem Maćka Aniserowicza (link do bloga) podczas spotkania Wrocławskiej grupy .NET i Maciek mi odpowiedział mega banalną odpowiedź (kurde, jak na to nie wpadłem, to sam nie wiem), tj.: pobierać dane z bazy za pomocą widoków, a w widokach nadawać zwracanym kolumnom ALIASY
b) Pod tym postem znalazłem komentarz Maćka Jędrzejewskiego, z ciekawości wszedłem na jego bloga i... znalazłem tam fajny "auto.mapper" o nazwie Slapper, za pomocą którego można automatycznie mapować typy "dynamic" zwracane przez Simple.Data na klasy naszego ViewModel -> link do posta na blogu Maćka

 Linki:
- Test wydajności mojego autorstwa
- Podst. solucję, którą wykorzystałem w moim teście pobrałem z bloga Tigran Gasparian
- Kody źródłowe Simple.Data na Github
- Porównanie kilku innych microSQL
- Link do bloga Maćka Jedrzejewskiego (automatyczne mapowanie obiektów do ViewModelu)

Git

Czym jest Git, mam nadzieję, że każdy szanujący się programista doskonale wie, a pozostałym przypomnę, że jest to rozproszony system kontroli wersji. Git powszechnie uważany jest, za najlepszy, dostępny na rynku system kontroli wersji. Porównanie Git-a z TFS, jakiś czas temu napisał mój ulubiony bloger .NET, czyli Maciej Aniserowicz -> 'w-czym-git-jest-lepszy-od-tfs'

Pomijając już wszelkie 'ohy i ahy' Maćka, które wygłasza za każdym razem, gdy tylko ktoś pozwoli mu się odezwać, Git ma kilka zalet, które na chwilę obecną bardzo mi się podobają:
- możliwość pracy off-line -> niestety w przeszłości, zdarzyła nam się syt., w której padł nam dysk na serwerze, na którym mieliśmy nasz serwer SVN. Dysk, a dokładniej dane dało się w końcu odzyskać, jednak te kilka dni programowania bez kontroli wersji do najprzyjemniejszych, a przynajmniej do najbardziej komfortowych nie należały. Wrzucając kod na git-a, można pracować 'off-line', a po podłączeniu się 'on-line' mamy pewność, że serwery będą działały tak jak należy i nie musimy się martwić o "spalenie się dysku"
- możliwość umieszczenia mojego kodu źródłowego w bardziej przyjaznej programiście formie, niż wklejanie go tutaj, co delikatnie mówiąc było lekko "wieśniackie".

Jako hosting, na pierwszy ogień poszedł GitHub ponieważ dla publicznych repozytoriów, jest darmowy link. Owszem, Github nie jest monopolistą i  istnieje konkurencja w postaci Bitbucket, który w dodatku pozwala na kilka prywatnych repozytoriów, ale od czegoś trzeba zacząć. Zawsze najpierw trzeba zrobić ten pierwszy krok.

Możliwe, że kiedyś się przeniosę na Bitbucket, albo inne podobne rozwiązanie, ale puki co, zapraszam na moje konto na github, gdzie w miarę możliwości będę się starał wrzucać moje programistyczne wypociny.