Używasz mobilnego safari w trybie prywatnym

Aby uruchomić naszą stronę wyjdź z trybu prywatnego, gdyż nie wspiera on funkcji, które są wymagane do poprawnego działania strony.

Twoja przeglądarka nie wspiera HTML5

Nasza strona używa local storage oraz cookies (ciasteczka) w celu poprawnego działania. Aby uruchomić naszą stronę, włącz local storage lub cookies w swojej przeglądarce.

Połączenie z serwerem zostało zerwane

Działanie serwisu zostanie wznowione po ponownym połączeniu



Ładowanie. Prosimy czekać...


Nie możesz się zalogować?
Resetuj hasło
Wyślij ponownie wiadomość aktywacyjną

Polityka prywatności

Polityka prywatności giełdy BTCDuke


I)  Dla okresu przed wejściem w życie ustawy będącej implementacją dyrektywy AML V (w Polsce Ustawa z dnia 1 marca 2018 r., o przeciwdziałaniu praniu pieniędzy oraz finansowaniu terroryzmu. W zakresie opisywanych tutaj procedur Ustawa ta wchodzi w życie w dniu 13-go października 2018 roku).

Kontom przypisujemy dane osobowe ich posiadaczy, ale nie weryfikujemy tych danych (chyba, że ktoś bardzo chce, wtedy niech ma zweryfikowane). Wymagamy jedynie, aby dane te się nie zmieniały oraz żeby wszystkie wpłaty/wypłaty FIAT realizowane były z/na konta bankowe posiadacza o takiej dokładnie nazwie jak rachunki u nas. Historia transakcji każdego klienta wraz z historią wpłat/wypłat przechowywana jest u nas na serwerze w sposób zaszyfrowany hasłem klienta. Każdy klient w dowolnym momencie może dodatkowo skasować całą listę swoich transakcji oraz listę wpłat/wypłat w FIAT oraz w krypto. Skasowanie takich danych nie powoduje zamknięcia konta.


II)  Dla okresu od dnia wejścia w życie ustawy będącej implementacją dyrektywy AML V ( w Polsce począwszy od 13-go października 2018 roku). Obok niniejszego dokumentu zostanie stworzony jeszcze wewnętrzny wypełniający kryteria tzw. „wewnętrznej procedury przeciwdziałania praniu brudnych pieniędzy”.

Konta dzielimy na dwa rodzaje: zweryfikowane oraz niezweryfikowane. Zweryfikowane to takie, gdzie klient przesłał skany jakiś dokumentów poświadczających jego tożsamość. Konta niezweryfikowane to takie, gdzie są przypisane dane osobowe posiadacza, ale nie zostały potwierdzone żadnym dokumentem.

Dla obu powyższych rodzajów rachunków, wpłaty i wypłaty FIAT przyjmujemy tylko z kont identyfikowanych przez takiego samego nadawce/adresata jak zadeklarowany przy otwieraniu rachunku i z żadnych innych.

Można będzie usunąć rekordy z zarówno konta zweryfikowanego jak i niezweryfikowanego. Wiązało się to będzie z jednoczesnym ZAMKNIĘCIEM RACHUNKU klienta na giełdzie, które to zamknięcie nastąpi tuż po wypłaceniu środków użytkownikowi.
Warunkiem skasowania rekordów oraz zamknięcia rachunków będzie:

niech X będzie sumą w walutach FIAT wydaną na zakup krypto począwszy od dnia wejścia w życie ustawy (w przeliczeniu wszystkich walut FIAT na EUR po kursie w momencie liczenia). Podobnie niech Y będzie sumą w walutach FIAT pozyskaną ze sprzedaży krypto począwszy od dnia wejścia w życie ustawy (przy przeliczeniu na EUR po kursie pomiędzy FIAT z momentu liczenia).

Konto można zamknąć jeżeli wartość bezwzględna z X-Y jest mniejsza niż 15 tys EUR.

Dla konta, którego nie da się zamknąć wg. klucza jak wyżej, nie da się wypłacić środków, jeżeli właściciel konta wpierw go nie zweryfikuje. Opcje wypłaty dla kont nie dających się zamknąć, a niezweryfikowanych są nieaktywne.
Klient chcąc w takiej sytuacji wypłacić środki może albo zweryfikować konta albo doprowadzić powyżej opisaną wartość bezwzględną różnicy X i Y do stanu przy którym weryfikacja do wypłaty nie jest konieczna.

Uwaga:

Po dniu wejścia w życie ustawy szyfrowanie oraz kasowanie rekordów nie będzie odnosiło skutku do tych transakcji, które zostały zrealizowane na podstawie pojedyńczego zlecenia, gdzie zawarto transakcję na co najmniej równowartość 15 tys EUR w którejkolwiek chwili realizacji tego zlecenia. Obecność takiego zbioru transakcji wraz z odpowiadającym mu zleceniem powoduje niemożność wypłacenia jakichkolwiek środków do czasu zweryfikowania rachunku. Niezależnie od wartości bezwzględnej X-Y oraz wynikającego z tego szyfrowania danych oraz możliwości kasowania rachunku, transakcje wynikające z takiego zlecenia nie są nigdy ani szyfrowane ani kasowane. W związku z tym również są odpowiednio oznaczane w historii transakcji klienta.


System informatyczny po wejściu w życie ustawy


Każdemu serwerowi przypisana jest w bazie lista transakcji oraz lista wpłat/wypłat. W przypadku gdy rachunek jest rachunkiem dającym się zamknąć, wówczas dane te przechowywane są w sposób zaszyfrowany hasłem klienta.

Jeżeli klient jest właścicielem rachunku nie dającego się zamknąć, to dane te nie są zaszyfrowane. Jeżeli rachunek da się zamknąć, wówczas są.

Jeżeli klient właśnie jest zalogowany, to na serwerze przechowujemy w programie (nie w bazie danych ale w programie) jego hasło i jeżeli wydaje on dyspozycje, która może zmienić status jego konta z zamykanego na niezamykane, to przy takim zleceniu informujemy go, że od tej pory dane będą odszyfrowane i w tym danym momencie odszyfrowujemy je hasłem. Każdorazowe spowodowanie, że stan konta staje się z powrotem kasowalny i klient nie posiada żadnych zleceń, które mogłyby to zmienić powoduje ponowne zaszyfrowanie danych, o czym klient jest informowany komunikatem.

Jeżeli zlecenie jest generalnie tak duże, że jego realizacja przekracza w chwili składania poziom 15 tys EUR, to również jest informowany o tym, że skutkiem takiego zlecenia, jeżeli przewyższa oczekiwaną skale, nie dawało się będzie ani zaszyfrować ani usunąć.

Za każdym razem o fakcie, czy dane klienta są zaszyfrowane czy nie, klient informowany jest statusem kłódki na stronie www oraz przy poszczególnych transakcjach.

Ponadto baza na serwerze giełdy znajduje się cała w katalogu, który również zaszyfrowany jest programem truecrypt. Administrator strony zanim uruchomi aplikacje serwera ręcznie poprzez remote desktop connection odszyfrowuje plik i dopiero potem uruchamia najpierw bazę, a potem aplikację serwera.


Uwagi końcowe w związku z pewnymi wątpliwościami


a)  Jeżeli dane są zaszyfrowane i klient zmieni hasło, to przecież zmieniając je jest online. Nie możemy więc jego danych odszyfrować i zaszyfrować nowym hasłem;
b)  Celem obliczenia X i Y nie są brane kwoty wpłat czy wypłat, ale jak łatwo zauważyć wyłącznie TRANSAKCJE;
c)  Uściśnienia wymaga jeszcze następująca sytuacja: klient składa zlecenie, po czym wylogowywuje się. Co zrobić, jeżeli realizacja tego zlecenia przewyższy równowartość 15 tys EUR lub zmieni różnice X-Y na taką, że konto nie może być już szyfrowane? Otóż, w tym wypadku hasło klienta winno być przechowywane w programie również po jego wylogowaniu się, ale aż do ew. crashu aplikacji serwera, tzn. w przypadku wyłączenia się aplikacji serwera na skutek jakiejś awarii (lub nawet przemyślanego restartu!). Hasła w niezaszyfrowanej formie są tracone, ale jednocześnie zalecam, żeby programista usuwał informacje o zleceniach tych, których wykonanie albo spowodowałoby realizację zlecenia o kwocie przekraczającej 15 tys EUR lub tych, które zmieniają X-Y w opisany powyżej sposób, tzn., wszystkie zlecenia tego klienta, którego taka sytuacja może dotyczyć. Chodzi tutaj o to,iż zachowywanie niezaszyfrowanych haseł w trakcie restartowania serwera celem ich użycia po jego uruchomieniu, uważamy za nazbyt ryzykowne z punktu widzenia ochrony prywatności userów. Anulowanie zleceń niektórych klientów w takim przypadku uważamy, że jest niskim kosztem zwiększenia ochrony prywatności tych userów.



Adam Gramowski