Soci (Soczó Zsolt) szakmai blogja

2017.09.22.

Debugolás Visual Studio 2017-ben

Filed under: .NET,C#,Debugging,Szakmai élet,Visual Studio — Soczó Zsolt @ 16:02

.NET Core és VS 2017 alatt van egy újfajta debug symbol kezelési módszer, a source link.
Itt egy egyszerű leírás, hogyan kell használni.

Tök szépen lehet a core kódokat így debugolni, csak szokás szerint a lokális változók nem látszanak.

2017.09.04.

IIS lassulás probléma – help needed

Filed under: Szakmai élet — Soczó Zsolt @ 20:44

Kivételesen nem megoldást írok le, hanem kérdést teszek fel.

Egyik ügyfelemnél vagy egy eset, amit egyelőre nem sikerült visszafejteni. Adott 3 IIS publikus web láb NLBS-sel összenyalábolva, és 3 belső IIS alatt futó WS szintén NLBS mögött, ezeket hívják a külső webappok. A Windowsok VmWare alatt vannak virtualizálva.

A hiba az, hogy random időpontban belassulnak a webszerverek webszervizek irányába mutató hívásai. Normál esetben egy gyors ws metódus hívása 2-5ms, amikor beáll ez az állapotváltás a webszerver worker process belsejében, akkor felmegy kb. 200 ms-re.

Azért írok állapotváltást, mert nem azért lassulnak be a dolgok, mert nap közben nagyobb a terhelés, hanem egyszer csak “elborul” a webapp, és belassul. Dynatrace alapján a ws hívások mélyén a recv windows hívás válaszol lassan. Ilyenkor a ws iis logjában is lassú a hívás, vélhetően mert a webapp mint kliens lassan viszi el az adatot.
Hamarosan lesz DotTrace lenyomat és FREB log is, illetve System.NET trace is (csak ez nagyon sok adatot termel).

IIS App reset megoldja a problémát egy ideig. Ha egy app beteg, akkor egy console appból ugyanaz a ws hívás ugyanezen a gépről a wsek felé gyors, tehát nem valószínű, hogy a wsek lassulnak be.

Nehézkes megfogni az estet, mert pl. egy config módosítás a trace-ek kedvéért azonnal appol resetet csinál, így elillan a hiba, aztán lehet megint egy napot várni rá.

A .NET perf counterek nem mutatnak kiugró értékeket, minden normálisnak tűnik. A web processben kb. 500 szál fut 1-3 kérés/sec esetén, ez mondjuk kicsit soknak tűnik, de a procmon nem mutatta meg a managed stacket (debug symbolokkal se), majd csak dottrace-ből látszik, mit csinálnak. A procik 10%-ig vannak kiterhelve. A diszk terhelés minimális, paging nincs, van 0.5G szabad memória, más proceszek nem eszik el az erőforrásokat. A resource monitorban a wsek irányába futó kérések jelentős része 200ms körüli latency-t mutat, ez egybevág más megfigyelésekkel.

Látott már ilyet valaki? Mit lehetne még mérni, amire nem gondoltam?

2017.09.02.

.NET optimalizálási praktikák

Filed under: .NET,Optimalizálás,Szakmai élet — Soczó Zsolt @ 10:25

Akik olyanok mint én, hogy az utolsó órajelet is meg akarják sprórolni, azoknak érdekes .NET optimalizálási cikk.

(Nitpickerek kedvéért: nyilván akinek minden ns számít, az nem .NET-ben programoz.)

2017.08.18.

Protobuf.net

Filed under: .NET,Szakmai élet — Soczó Zsolt @ 13:24

Eszement gyorsan serializál!
https://code.google.com/archive/p/protobuf-net/wikis/GettingStarted.wiki

2017.08.17.

Forceseek delete-hez

Filed under: Adatbázisok,SQL Server,Szakmai élet — Soczó Zsolt @ 18:02

Volt egy delete-em, ami nem akart rendesen index mentén lefutni. A delete-et kicserélve select-re ugyanez volt a helyzet, de select esetén egy oszlopokkal kikényszerített forceseek segített.
Viszont delete-et nem lehet hintelni. A megoldás CTE volt, így indirekten mégiscsak lehet hintelni. A lekérdezés pár százszor gyorsabb lett. :)

Érdemes megjegyezni három trükköt tanulságul:
1. CTE kimenetén lehet futtatni DDL-eket
2. Így indirekten lehet hintelni
3. Néha jó index esetén se seekel a szerver, ilyenkor csakis az oszlopokkal megsegített forceseek segít.

;with B
as
(
select * from dbo.Bar with(forceseek(IX_Natural_Key(TickerId, BDT)))
where TickerId = @tickerId and BDT in 
    (select DATEADD(day, DATEDIFF(day,'19000101',DATEADD(DAY, 1, cast(StartDate as datetime))), CAST(ClosingTime AS DATETIME2(7)))
    from TradingHours where TickerId = @timeTemplateTickerId and StartDate is not null and EndDate is null and IsEnabled = 1 and Priority > 10)
)
delete from B;

2017.05.31.

Kell nekem a Microservices architektúra?

Filed under: Szakmai élet — Soczó Zsolt @ 08:22

https://aadrake.com/posts/2017-05-20-enough-with-the-microservices.html

2017.05.12.

Google Mock Test Adapter for VS 2017

Filed under: Szakmai élet — Soczó Zsolt @ 07:45

Az MS mögé állt, eddig külsősök írták. Végre kényelmesedik a C++ tesztelési irány is. Hát még, ha NCrunch is menne…

2017.01.17.

Nagy táblák join-olása eredmények

Filed under: Adatbázisok,SQL Server,SQL Server 2016,Szakmai élet — Soczó Zsolt @ 19:26

Korábbi bejegyzésemben írtam, hogy demó környezetben a columnstore indexek nagyon jelentős gyorsulást okoznak.

Élő adatbázisban azt tapasztaltuk, hogy integer kulcsokon végzett join-okon 5-10-szeres gyorsulást okozott a normál indexekhez képest.

Azonban GUID-os oszlopokkal nem okozott értékelhető gyorsulást, annak ellenére, hogy batch módúak voltak a műveletek. Erre úgy látszik nem gyúrtak még rá, vagy a guid randomsága miatt nem tud érdelmes teljesítményt elérni.

2016.11.22.

Nagy táblák joinolása

Egyik folyó munkámban több tízmilló soros táblákon végzett joinokat kellett optimalizálni. Általában ez nem kihívás, mert szinte mindig vannak szűrési feltételek, amelyeket kellő közelségbe víve a táblákhoz és rendes indexekat alápakolva már csak pár ezer joint kell végrehajtani, ami gyors lesz.
De most tényleg össze kellett joinolni sok millió sort, szűrés nélkül.
Mit lehet ezzel kezdeni? Sajnos itt már eléggé behatárolt területen mozgunk. A normál indexelős megoldások nem segítenek, mivel minden táblát teljes egészében be kell járni (nincs where).
Ráadásul ha *-os a select, akkor a cover NC index se játszik, hogy legalább az IO csökkenne.
Merge joinra lehet játszani clu indexekkel, de azért ez korlátos terület sok tábla esetén, illetve párhuzamos tervek esetén magától nem fog merge joint használni (itt írnak egy trace flagről, amivel mégis rá lehet venni).
Mit lehet tenni. Egyik lehetőség előre elkészíteni a join indexelt view-ban. Erre ügyesen ráharap az optimizer, ha van olyan join amit aztán többször futtatunk, akkor megéri ez a denormalizálás.
Ha viszont van újabb szerverünk (2016), akkor van sokkal durvább lehetőség: Columnstore index.
Az a baj ugye a nagy joinnal, hogy akárhogy is trükközünk, ez nagy meló a prociknak és az IO alrendszernek (vinkóknak). Az indexed view ezt úgy oldja meg, hogy egyszer kell megcsinálni, aztán sokszor élvezni az előre összepakolt adatokat.
A columnstore viszont (dióhéjban) azért piszok gyors mert:
1. 5-10-szeresen tömörítve tárolja az adatokat, kevesebb IO, illetve a memóriában a buffer cache-t is jobban ki tudja használni (mintha több RAM-unk lenne)
2. Képes az adatok csak egy részét felolvasni, ha csak kevés oszlop kell (select *-on ez nem segít persze)
3. Képes batch módban belülről párhuzamosan végrehajtani a műveletek egy részét (ez nagyon durván megdobja)
4. Képes a sorok egy részét felolvasni where feltétel alapján, mivel minden 1m sorhoz (szegmens) nyilván tarja az adott oszlop min és max értékét
5. Le tud nyomni operátorokat (pl. sum) a storage engine-be, így nem kell adatokat passzolgatni a rétegek között.

No, lássuk a medvét. Létrehoztam két másolatot egy 100 millió soros táblából. A tesztgép egy két éves laptop 2 core-ral és 8G RAM-mal, SSD-vel. Nem egy szerver.
A két táblát a kulcsai mentés join-olom, így mind a 100 millió sort végig kell néznie, és ennyi találat is lesz.

Először sima Clu index:
create clustered index IX_Clu1 on B1(Id)
create clustered index IX_Clu2 on B2(Id)

select count(*) from B1 join B2 on B1.Id = B2.Id

SQL Server parse and compile time:
CPU time = 15 ms, elapsed time = 18 ms.

(1 row(s) affected)
Table ‘B1’. Scan count 5, logical reads 1141262, physical reads 6,
read-ahead reads 1138814, lob logical reads 0, lob physical reads 0,
lob read-ahead reads 0.
Table ‘B2’. Scan count 5, logical reads 1140956, physical reads 4,
read-ahead reads 1138821, lob logical reads 0, lob physical reads 0,
lob read-ahead reads 0.
Table ‘Workfile’. Scan count 896, logical reads 480256, physical reads
2688, read-ahead reads 477568, lob logical reads 0, lob physical reads
0, lob read-ahead reads 0.
Table ‘Worktable’. Scan count 0, logical reads 0, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0.

SQL Server Execution Times:
CPU time = 477262 ms, elapsed time = 377318 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 1 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

377 másodperc.

Jöhet a columnstore index:
create clustered columnstore index IX_CStore1 on B1
create clustered columnstore index IX_CStore2 on B2

select count(*) from B1 join B2 on B1.Id = B2.Id

SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 6 ms.

(1 row(s) affected)
Table ‘B2’. Scan count 4, logical reads 0, physical reads 0,
read-ahead reads 0, lob logical reads 105018, lob physical reads 0,
lob read-ahead reads 0.
Table ‘B2’. Segment reads 103, segment skipped 0.
Table ‘B1’. Scan count 4, logical reads 0, physical reads 0,
read-ahead reads 0, lob logical reads 104998, lob physical reads 0,
lob read-ahead reads 0.
Table ‘B1’. Segment reads 102, segment skipped 0.
Table ‘Worktable’. Scan count 0, logical reads 0, physical reads 0,
read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0.

SQL Server Execution Times:
CPU time = 79920 ms, elapsed time = 27834 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.

377 sec vs. 28 sec. Azért ez masszív különbség. :)

Érdekességképpen megnéztem NC Columnstore index-szel is, úgy 60 sec jön ki. Ez se rossz.

A jövő héten lehet ki tudjuk próbálni egy nagyobb géppel is, kíváncsi vagyok, ott mit tudunk vele kihozni.

Ha esetleg valakinek vannak már gyakorlati sikerei, érdekelnek a számok.

2016.11.04.

Mit is jelent pontosan, hogy Accent Insensitive?

Filed under: Adatbázisok,SQL Server,Szakmai élet — Soczó Zsolt @ 12:18

Bólyai magyar verseny kapcsán gondolkodtam a magyar nyelv rendezési szabályain.

string[] words = new string[] { "írógép", "írat", "irkál", "irodalom", "író", "írás" };
Array.Sort(words, StringComparer.Create(new System.Globalization.CultureInfo("hu-hu"), false));
foreach (var w in words)
{
    Console.WriteLine(w);
}

Kimenet:

írás
írat
irkál
író
irodalom
írógép

Ezek szerint az alap magyar kultúra szerint a C# (valójában a Windows) accent insensitive módon rendez. A gyerekek is azt mondták, így tanulják az iskolában. Az én fejemben ez nem így volt. Vagy bugos a fejem, vagy mi még nem így tanultuk, nem tudom.

Nézzük SQL Serverben!

CREATE TABLE [dbo].[A](
	[Nev] [nvarchar](50) NOT NULL
) ON [PRIMARY]

select * from A
order by Nev collate hungarian_CS_AI

Azaz Accent Insensitive a rendezés, így joggal azonos a C#-pos kimenettel:

írás
írat
irkál
író
irodalom
írógép

Ami viszont bizarr:

select * from A
order by Nev collate hungarian_CS_AS

Kimenet:

írás
írat
irkál
író
irodalom
írógép

Ugyanaz! Magyar nyelv esetén nem számít az ékezet érzékenység, akkor se vesszük figyelembe az ékezeteket, ha kifejezetten kérjük. Ez nekem furcsa, de nem én írom a magyar nyelvi szabályokat.

Van egy másik collation is, annál meg mindig accent insensitive a rendezés, függetlenül a beállítástól:

select * from A
order by Nev collate Hungarian_Technical_CI_AS
select * from A
order by Nev collate Hungarian_Technical_CI_AI

Mindét esetben ez a kimenet:

irkál
irodalom
írat
írás
író
írógép

Tehát a magyar az egy olyan állatfajta, amiben nem az AI/AS szabályozza az Accent Sensitivity-t, hanem, hogy melyik collationt használjuk.

Ami viszont végképp fura, hogy a Latin1_General_100_CI_AS vs Latin1_General_100_CI_AI sem változtatja meg a sorrendet. Hogy van ez?

A mi aá, stb. variánsaink nem tartoznak az accentek közé?

Itt és itt érdekeseket írnak a témáról.

2016.08.19.

Windows Internals cikkeim

Filed under: Szakmai élet,Windows,Winternals — Soczó Zsolt @ 11:22

Annak idején írtam pár cikket a Windows belső működéséről, utóbbi időben többen kerestétek, mivel eltűntek az ms oldalairól.

Ezért most kiraktam ide őket, hogy bárki elérhesse.

2016.06.19.

SQL Server memória hiány miatti lassú lekérdezés

Érdekes hibába futottam bele mostanában. A lapotopomban csak 8G RAM van, így az azon futó SQL servernek nem sok marad, amikor a Chrome, a Visual Studio 2015 és más memóriazabáló alkalmazások elkezdenek terjeszkedni.
A probléma az volt, hogy egy olyan lekérdezés, amely Sortot tartalmazott a szokásos 2-3 mp helyett fél-egy percig futott. A végrehajtási tervben volt egy figyelmeztetés, hogy a sort operátor kénytelen kipakolni a rendezést a tempdb-be (spill). De ettől még nem kellett volna ilyen lassúnak lennie. Csak 3500 sorról volt szó, ez azért belefért volna memóriába.

A select * from sys.dm_exec_query_memory_grants lekérdezésből kiderült, hogy a lekérdezés sortjának kellett volna 10M memória, de nem tudott annyit kapni, ezért várakozott, és aztán 20 másodperc múlva egyszer csak timeout lett, és kényszeredetten csak nekifogott végrehajtani a sortot a tempdbben.

Azaz egy egy nem szokványos lassú lekérdezés volt, nem sok lapolvasással járt, mint a tipikus rosszul optimalizált lekérdezések, hanem a memory grantre várt.
A megoldás az lett, hogy beállítottam 1G min memory-t az SQL Servernek, így már kiszámíthatóan jól érzi magát.

Egy rendes szerveren valószínűleg ritkább az ilyen memória kényszer, de azért jó tudni róla.

2016.02.28.

Ha a Visual Studio (2015) üresjáratban megeszik 1-2 procit…

Filed under: Szakmai élet,Visual Studio — Soczó Zsolt @ 20:11

akkor kapcsold ki a Git Source Control típust, mint default providert. Piszok idegesítő volt ez a hiba.

2015.12.29.

Szuper befektetés 2016-ra

Filed under: Élet,Tőzsde — Soczó Zsolt @ 10:39

Ajánlok neked egy szenzációs üzletet. Olyan story van mögötte, hogy elájulsz. Szerény költségekkel dolgozok, és maximálisan a te érdekeidet tartom szem előtt.
Minden évben adsz nekünk egy milliót, 2008-tól 10 éven keresztül. Így 10 év után, most figyelj! lesz 9,990,379 Ft-od. Hát nem csodálatos? 10m Ft waze, ha mi nem lettünk volna, elittad volna az egészet. Most, amikor semmi kamatot nem adnak a bankok, hát nem nagyszerű ez?

Ja, hogy 10M-t adtál nekünk, és 10 év után is 10 milliód van? De kicsinyes vagy ember, ha mi nem vigyáztunk volna a pénzedre már nem lenne abból semmi.

Ja, hogy közben mi kerestünk rajtad 4,496,184 Ft-ot? Ember, most jobb lett volna, ha otthon tartod a cihában a pénzed? Most komolyan, sajnálod tőlünk azt a szaros négy és fél milliót? Egy vacak Opel Astra K ára, hogy lehetsz ilyen zsugori.

Ja, hogy a statisztikák alapján valójában tudjuk, hogy átlagban 6-7 év múlva megszünteted velünk a szerződésed, de mi elvisszük mind a 10-15 év díját előre. Ez a te érdekedben van, mert felelőtlen disznó vagy, ha nincs kényszer, még hamarabb megszüntetnéd a befektetésedet. Jó, valójában előre tudjuk, hogy meg fogod szüntetni, mert előbb-utóbb olvasol róla, hogy alaposan átvertek? Akkor is te vagy a fegyelmezetlen disznó, megérdemled a büntetést.

Ja, hogy elfelejtettük mondani, hogy ha nyitnál egy TBSZ-t, arra raknád be a pénzed ugyanarra a befektetésre, akkor a tiéd lenne az az új Open Astra is? Igen, erről nem szóltunk, mert akkor miből élnénk meg ilyen állat jól?

Ha neked nem kell egy új kocsi ára, akkor fektess be unit linked biztosításba. Ha kell, akkor meg nyiss minden évben egy TBSZ-t, és fektess be, ahogy leírtam.
Még van pár nap az évből, nem késő lépni.

Számítások a mellékelt Hozam és költség kalkuláció excelben. Az első lapon konstans évi 8% hozammal van számítva, a második 12%-kal. Utóbbi esetben már 6 milliót “csípnek” le, nyilván a te érdekedben, ezért óriási értékeket kapsz.

Ps. miért írok ezekről a dolgokról? Mi érdekem fűződik ehhez? A düh hajt. Annyira mérges vagyok, hogy ennyire lenyúltak a biztosítók, legutoljára a CIG, hogy ha módomban állna, sóval hinteném be őket. De egyelőre nem áll módomban, így marad az, hogy adok némi pénzügyi iránymutatást ezekkel az írásokkal, így ha sokan nem égetik el a pénzüket náluk, akkor azt hosszú távon megérzik. Olyan ez, mint a DDOS, ha elég sokan élnek vele. Ezért kérlek, hogy egy megosztással támogasd a törekvésemet (és segítsd a barátaikat, hogy ne verjék őket is át). Köszönöm.

2015.12.22.

Egy példa mitől fordul le állandóan egy .NET project

Filed under: .NET,Szakmai élet — Soczó Zsolt @ 19:02

Bosszantó, amikor semmit nem változtatsz, mégis újrafordul pár project egy nagyobb solutionben. Ha bekapcsolod a diagnostic build loglevelt, akkor egyből kiderül az ok. Pl. most nálam:

Project ‘Basics’ is not up to date. Project item ‘C:\ATS\Basics\x64\lz4X64.dll’ has ‘Copy to Output Directory’ attribute set to ‘Copy always’.

Update: egyéb okok: felesleges referenciák illetve Resource-ként megjelölt file, ami nem is resource, csak sima xml, ki kell másolni a kimenetbe.

.NET fejtörő

Filed under: .NET,Szakmai élet — Soczó Zsolt @ 15:29

Élő kódból. Az első megoldás jól működik, a második nem, mi lehet az oka? A hibajelenség, hogy az első beállítja a TickerId-t az objektumon belül, a második nem.

Parallel.For(0, tickOhlcs.Count, i => tickOhlcs[i].SetTickerId(key.TickerId));

Parallel.ForEach(tickOhlcs, tickOhlc => tickOhlc.SetTickerId(key.TickerId));

2015.11.16.

TDD következő alkalom early bird

Filed under: .NET,Felhívás,Szakmai élet,Test Driven Development,Testing — Soczó Zsolt @ 23:19

Jövő januárban újra lesz TDD tanfolyam, most ősszel már nem volt időm betervezni egyet.

Aki december 1-ig jelentkezik, azt most 150e-ért csatlakozhat.

2015.10.26.

Befektetésről programozóknak 5.

Filed under: Élet,Tőzsde — Soczó Zsolt @ 00:44

Első rész.
Második rész.
Harmadik rész.
Negyedik rész.

Adózás. Ez számomra a legtávolabbi téma, de fontos értenünk, hogy ez mennyit számít.
Adózni akkor kell, amikor profitot realizálunk, vagy veszteséget könyvelünk el. Azaz nem a benn lévő összeg után adózunk, hanem a “csinált” pénz után. Ha rendszeres befektetésben gondolkodunk, amiben nem váltogatunk befektetett eszközök között, akkor csak akkor fogunk realizálni profitot, amikor nyugdíjas korunkban elkezdjük felélni a megtermelt pénzt. Hogy akkor, 20-30 év múlva milyen adótörvények lesznek, azt senki nem tudja. Ezért csak a jelen törvényekből tudok kiindulni.
Most a profit után 16% szja-t kell fizetni, illetve 2013-tól 6% eho-t. Az ehot azonban normál adózóként is fizetünk, és annak maximuma évi 450,000 Ft, ezért azt nem tudom egyszerűen beszámítani. Más kérdés, amikor már nyugdíjasok leszünk, és nem akarunk dolgozni, akkor nem is fizetünk ehot.

Az egyszerűség kedvéért 16% adóval számolok a továbbiakban.

Ha harminc évig fizetnénk a mostani feltételek mellett a KBC-s árakkal, 1%-os devizaváltási veszteséggel (lást előző rész) évi 400e Ft-ot SPY-ba fektetve, feltéve az évi 8.75%-os hozamot, akkor 30 év után 54,657,547 Ft-unk lenne (sok a ha, de nem tudunk jobbat).

Ha ezt egy összegben ki akarnánk venni, akkor a profit után kellene 16% adót fizetni. 30 év alatt 30*400,000 ment be, azaz 12m. A profit 54m-12m=42m. Ennek 16%-a 42m*0.16=6.72m. Ez sok. Marad 54m-6.72m = kb. 47m. Nem rossz ez se, de azért lehet ez jobb is.

2012 óta van olyan tartós befektetési számla, TBSZ, amin ha 5 évig nem bántjuk a befektetett pénzt, akkor nincs utána adó. Nem tudjuk milyen adótörvények lesznek a jövőben, de eszement ökörség lenne kihagyni ezt a lehetőséget.

A KBC-n most csináltam egy 2015-ös TBSZ-t, 2 perc volt weben megnyitni a főszámlára belépés után. Aki erre nem tud időt szánni, az fizessen adót. :)

TBSZ-t miden évben kellett és kell majd nyitni, rá kell szánni pár percet évente. Aztán mehet rá a pénz, váltás a webes felülten (spreadre figyelni!), majd mehet a pénz a kiválasztott ETF-be vagy részvénybe. Utána egy évig megint semmi teendő.

Van Nyugdíj előtakarékossági számla is, de nekem nem tetszenek annak kötöttségei, annak ellenére, hogy ott még lehet max. évi 130,000 Ft állami szjat is rátolni.

A méregdrága Unit Linked biztosításoknál a fő érv az szokott lenni, hogy drága, de cserébe élhetsz a 20% max. 130,000 adóvisszatérítéssel, és nem kell 10 év után szja-t fizetni.

1. Ha van szabad szja-d. Nekem a 3 gyerek miatt nincs maradék szja-m, az egészet visszakapom.
2. TBSZ-nél sincs adó, ráadásul már 5 év után.
3. 2010 és 2013 között 4 évig nem volt ilyen. Aki emiatt kötött UL-t, az beszopta sajnos.
4. Még támogatással is elviszi a gatyádat az UL a különös költségei miatt.

Nézzünk a körmére ezen utóbbi állításomnak. A konkrét példa a CIG Signum nevű csoda. Ebben a következő költségek vannak:
Számlavezetési díj: 5400/év
Alapkezelési díj: max. 1.95%
Befektetett összegre commission: 3%.
És itt a poén, a különös költség:
“Az első 3 év rendszeres díjaiból vásárol kezdeti egységet a CIG Pannónia, amelyek számát évi 8,5%-kal csökkenti 10 éven keresztül”
Az első 3 éves díjadból vásárolt egységekből (részvényszerű izé) MIDEN ÉVBEN 8,5%-ot elvisznek. Így 10 év alatt ha az első 3 évben vettél 100, 100, 100 egységet, akkor marad belőle 135 (számítások: CIG2.xls, MisteriousCost sheet). Azaz több mint felét elvitték!!! Ráadásul én ezeket 2008, 2009, 2010-ben vettem, fasza nyomott áron, ami most a dupláját éri. Finom kis profitlehetőség ez.

A CIG biztosítások teljes költségmutatója egyébként itt van.

Ez alapján az én UL-em TKM-je: 7,62% – 12,00%, 10 éves befektetés estén. A S&P meg hoz 8.75%-ot. Mennyi marad nekem? (Itt most elmondtam az a hosszú átkot, amit illendőségből nem vetek papírra).

Akinél van hányózacskó olvassa el ezt a marketing dumát:
“A SIGNUM PRO a BROKERNET és a CIG Pannónia egybecsengő várakozása szerint újabb robbanást idéz elő a magyar
és a szlovák piacainkon, mivel Ügyfeleink számára olyan magas hozzáadott-értéket képes teremteni, mint eddig még
soha egyetlen megoldás sem a befektetéssel kombinált életbiztosítások közül. A SIGNUM PRO fejlesztése kapcsán
azt kértük stratégiai partnerünktől, hogy olyan hosszú távú befektetési és életbiztosítási eszközt hozzanak létre
hűséges ügyfeleink számára, amely a BROKERNET kizárólagos közvetítésében még a SIGNUM frenetikus sikerét is
képes túlszárnyalni.”

Lássuk ezeket a világsikerű (vég)termékeket (CIG2.xls)!

Nehéz modellezni a valódi költségeket, mivel az első 3 évben 3 különböző áron veszünk befektetési egységeket. Melyiknek viszik el a 8.5%-át?
Tegyük fel minden évben befektettem 105 Ft-ot. Az első éven vettem 3 Ft-ért 35 db-t, második évben 5 Ft-ért 21 db-ot, a harmadikban 7 Ft-ért 15 db-ot. Ma 10 Ft-ot ér a részvény. Az első értéke (10-3) * 35 = 245 Ft. A második évi pakk értéke: (10-5)*21 = 105 Ft, a harmadiké (10-7)*15 = 45Ft.

Ha profit maximalizálásra törekednél (melyik vállalkozás nem?), és nincs pontosan definiálva, melyik pakkból vegyél le 8.5%-ot, melyikből vinnél el először?

Összesen van 35+21+15 = 71db egységünk az első három évből. Ebből elmehet 8.5% évente. Az 71*0.085=6.035 egység. Ha ezt elviszem a 3 Ft-ért vásároltakból, akkor elvettem az ügyféltől 6.035*(10-3)=42.245 Ft-ot.
Ha a harmadik, rosszabb áron vett pakkból fogyasztanak, akkor 6.035*(10-7) = 18.105 Ft-ot visznek el tőled. Na, most jön a nagy kérdés. Ha te lennél a biztosító, és a különös feltételekben különös módon nincs precízen definiálva, mely egységeket viszik el az első három évből, te melyiket vinnéd el, tudva, hogy a szerződésnek megfelelően jársz el? 42 forintot, vagy 18 forintot? Nem tudom, hogyan működik az elvonási logikájuk, de ez a játéktér megvan nekik.

A modellembe behelyettesítve a fenti költségeket és logikát (CIG2.xls, CIG Actual Perf sheet) a befektetett 2.8M-ból 3.5M jön ki, ami egybevág a biztosító által riportolt értékkel (ennyivel persze még nem lehet kilépni, mert a 10 éves költségüket mindenképpen elvonják, most 3.2-ért adnák vissza, amire még jönne a fél szja).

A nagy adó-visszatérítés hatása: ha 2008-ban, 2009-ben és 2014-ben, amikor élt a 20% adóvisszatérítés, és lett volna szjam, akkor minden évben 400000 helyett 480000 ment volna be. Erre ma 3.5M helyett 3.75M-t érne a biztosítás. Ez a nagy adó-visszatérítés hatása. Nem lehet ólomcipőben futóversenyre menni.

És mekkora lenne a biztosítás valódi értéke? Saját számításaim szerint 5.6M!!! 3.5 vs. 5.6M, lehet ízlelgetni.

Hogy nézett volna ez ki, ha sima befektetési számlán játszom el ugyanezt, a KBC-s költségekkel, és 1%-os deviza váltással kalkulálva, közvetlenül befektetve a BRK-B részvénybe?

Mivel kis pénzről van szó beleférünk a havi 500Ft-os számlavezetési díjba (nem akartam túloptimalizálni, lehetett volna egy start számlával indítani, az csak 99Ft havonta, az első két év elment volna vele). Ami érdekes, hogy az induló költségek levonása után itt 388,075 Ft-ot tudunk befektetni (M oszlop), a CIG-nál 382,200-at, nincs nagy különbség, csak itt nincs alapkezelési díj, és különös költségek. Ennek meg is van a hatása: a számla végösszege 5,569,522 Ft lesz!!! Azt a leborult szivarvégit? Tetszik érteni végre, miért rablás az UL?
Megelőzendő az ügynök lármát, adózzunk 1 percet az adónak. Vonjunk le 16%-ot a profitból. Bement 2.8, kijött 5.56, azaz a profit 5.56-2.8=2.76M. Ennek 16%-a: 2.76M * 0.16 = 441e Ft. Azaz marad 5.56-0.441 = 5.119. Kontra 3.5M a biztosításnál (ami valójában 3.2 + kevés adó, ha most kiveszem).
Ha mindhárom évben, amikor volt igénybe vettem volna a 20% szja kedvezményt, akkor 3.74M lenne a biztosítás értéke 3.5 helyett. Hol van ez az adózott, rettenetes 5.119M-hoz képest? És akkor nem vagyok minimum 10 évre lekötelezve, ha hirtelen mégis kell a pénz. Normális világban a könnyű feltörhetőségért kell fizetni, de nálunk fordítva ülnek az urak a lovon, és pont fordítva csinálják.
Ééss, nem használtuk ki még a TBSZ-t? Jaj, szegény ügynökök, ez lehet a rémük.
2012-től lehet részvényeket is venni TBSZ mögött. Azaz a 2012 utáni 3 befizetés már adó nélkül fog kijönni a cső végén. 2012 őszén (excelben U6 cella) 91e adóval likvidálhattam volna a pozíciómat, majd átrakhattam volna a befektetést TBSZ-be, minden évben utána már csak újat nyitva, és pakolva bele a pénzeket. Így az előbb kiszámított 441e adó valójában csak 91e, nekem maradna 5,56-0.091 = 5.469M Ft.

Egy kis charton is összefoglalom, hogy vizuálisan is látsszon, hogy működik ez a lopó-ipar (klikk a nagy képért):

CIG Warren vs. KBC

A hülyének megéri a Unit Linked biztosítás. Nagyon elszomorít, hogy Magyarországon így működik a pénzügyi szabadrablás. Remélem, a cikksorozattal elgondolkodtattalak, és segítettem elindulni azon az úton, ahol vérszívók nélkül meg tudod teremteni a saját pénzügyi jövődet.

Sok sikert hozzá. :)
soci

Ps. a számítások során nyilván tévedhettem. Annyit tudtam tenni ennek kiküszöbölésére, hogy nyilvánossá tettem az összes számítást, így bárki utánanézhet, ha tévedtem. Ha találtok ilyet, szóljatok, javítom.

Befektetésről programozóknak 4.

Filed under: Élet,Tőzsde — Soczó Zsolt @ 00:30

Első rész.
Második rész.
Harmadik rész.

Nézzük meg, mennyibe kerül átutalni a pénzünket a kívánt befektetési számlára? Ezt igen nehéz lesz összehasonlítani, mivel eléggé szór még egy bankon belül is az átutalások díja számlafajtától függően, illetve ebben nem vagyok annyira otthon, csak összeszedek pár adatot a netről.

CIB-nél például ezt láttam most:
GIRO magyar: 0,43%, min. 122 Ft, max. 41000 Ft

Erste Egyszámla: 0,43%, min. 122 Ft, max. 41000 Ft

Unicredit: 0,33%, min. 255 Ft, max. 6 900 Ft

Ha euró lenne itt is egyszerűbb lenne a dolgunk, és az utalási költségek is normálisabbak lennének (persze adóval akkor is meg tudják majd fejelni).

Jobb híján 0.4%-kal fogok számolni. Ez pl. 400eFt-nál 1600 Ft. Ami érdekes, hogy az IB-hez is lehet utalni forintot, és az utalás célpontja is magyar bank, így nem több oda utalni pénzt, mint a magyar cégekhez.

Mivel ebben nincs különbség a különböző befektetési lehetőségek között, ezért ezt nem fogom bekalkulálni a számításaimba. Emlékeztetőül, a befektetési lehetőségek várható kilátásai érdekelnek, és ebbe ez nem szól bele az utalás, mivel minden felé azonos, de mint költség természetesen nagyon is valós.

Amit esetleg itt még meg lehet vizsgálni, hogy ha a bank és a bróker egy anyacéghez tartozik, akkor lehet, hogy a bankszámláról a befektetési számlára utalás olcsóbb vagy ingyenes, ebben nincs tapasztalatom, amit láttam a KBC-nél, hogy ha kifelé utalunk pénzt brókerszámláról K&H-s ügyfélszámlára, akkor az ingyenes. 25 év múlva visszatérünk erre, amikor nyögdíjas leszek (ha élek) :).

Következő költségünk a devizaváltás, az pl. forintot utaltunk be a befektetési számlára, de pl. USD alapú részvényt vagy ETF-et akarunk venni.

Ez egy forex tranzakciót jelent. A forex egy érdekes állatfajta, az egyik legjobb termék az amatőrök megkopasztására. De mi nem forexelni akarunk nagy tőkeáttétellel, egyszerűen csak pénzt váltani. Forexnél sokszor hallani, hogy nincs commission. Ez persze azonnal gyanús, mert akkor miből él a másik oldal? A spreadből, azaz az eladás és a vételi oldal árkülönbségéből.

Könnyű belátni a következőt. Mondjuk most (hétvégén) megnéznve a CIB honlapján az USD/HUF árfolyamokat ezt látjuk: 264 – 286. Mit jelent ez? Adok nekik 286 Ft-ot, ezért adnak nekem 1 USA dollárt. Aztán meggondolom magam, vissza akarom váltani. Akkor 1$-ért adnak nekem 264 forintot. Hoppá, hova tűnt 22 forint? Elvitte a spread! Erre nagyon oda kell figyelni, sokan nem realizálják, a spread miatt mekkora hatalmas százalékokat veszt az ember.

Nézzük, amikhez vannak adataim:
Biztosítók: itt a váltás a háttérben zajlik, erről nem tudok semmiféle számszerű összeget mutatni, a többi költség része.
KBC spread: egyszerűsítve: 1% napközben, 3% este, no commission. Én egyik hétköznap este megnéztem, az IB-hez képest pont 3%-kal volt eltolva az árfolyam felfelé. Akinek nincs referenciája, hogy megnézze mikor-mennyi a spread, annak egyelőre nem tudom megmondani, mikor tud tutira 1%-ért váltani (pedig ez fontos!). Aki tudja írja meg, de majd megnézem a jövő héten nap közben én is.
UPDATE: reggel 9-kor 1% volt, korrekt.
Tehát úgy működik a történet, hogy a KBC pontosan látja a háttérben a forexes árfolyamot (bid és ask), és annak közepétől mesterségesen eltolja 1 vagy 3%-kal az adási és a vételi árfolyamot. Ezt ők tisztán megkeresik a bizniszen. Így már érthetővé válik, miből finanszírozzák a hazai viszonylatban jó befektetési üzletüket. Ha megfordul náluk mondjuk évi 10 milliárd forint, akkor 2% spreaddel számolva csak ez az üzlet hoz nekik 200 millió forintot.
Erste: egyelőre nincs infóm, de megkérdeztem tőlük.
IB: 0.1-0.2 Ft. Hasonlítsuk csak össze a bankok 10-20 pontos spreadjével! 100x kisebb, leírom, százszor kisebb! Ez nagyon durva különbség. Ezért lehet náluk jól forexet tradelni, de most befektetünk. Viszont mivel ők nem húzzák szét a spreadet, nekik másképp kell keresni rajta, ezért az IB commissiont szed, 0,00002 * trade size értékben. Azaz 100000 dollárért 2$-t. Ha a KBC 1%-ával számolok, akkor ez a KBC-nél 1000$ (ezer!) lenne, durva különbség. Viszont megint bejön az IB ügyfélmérete, 2$ a legkisebb commission. 100 Ft-nál is. De ez a commission is lejön a 10$-os havi min költésből.

Mit jelentek ezek a számok a gyakorlatban? Ha pl. beutalok 1M Ft-ot a bróker számlára, és azt át akarom váltani USA dollárra, akkor:
CIB: (264, 286, feltételezve, hogy szimmetrikus a spread (lehetne nem az), akkor a valódi forex közép ((bid+ask)/2) 275 lenne), így a veszteségmentes váltásnál 1,000,0000/275=3636 dollárt kapnék.
A CIB spreadjével ez 1,000,0000/286=3496 dollár. 3636-3496=140 dollár a banké. Az kb. 140*275=38500 Ft. Minek is commission ilyen váltás mellett? :) Hétköznap egyébként asszem kisebb a bankoknál a spread, de hasonlóan elég tág. A spread is olyan, mint bármi más az életben, a szűket szeretjük. Szerintem ezen mondat után mindenki megjegyzi az alapelvet. :)

(Nem témánk, de sokan azt hiszik, ha pl. eurós országban magyar forintos számlához kapott kártyával fizetnek, akkor középárfolyamon történik a váltás. NEM. A CIB telebankon is megkérdeztem nyaralás előtt, megerősítették. Ha EUR vagy USD számlád van, és a megfelelő céghez tartozó kártyát (pl. VISA euro, Mastercard USD), akkor azonos devizában fizetve nem lesz költséged, pont mint Magyarországon, a bolttól veszik le a sápot. De ha pl. Horvátországban fizetsz, akkor egy pl. EUR-HRK konverziót csinál a kártyacég. Azok sokkal jobban váltnak, mint a bankok. Ha forintos kártyával fizetsz, először a magyar bankok váltanak pocsék spreaddel a kártyacég natív devizájára, majd a kártyacég vált kunára, még egy spreaddel.)

KBC: 275 közepet feltételezve az 1%-os időszakban ők mindkét irányban tolnak 1%-ot, azaz belövik a két oldalt 275*1.01=277.5-re, a másik oldalt 275*0.99=272.25-re (ez valójában 2%-os spread a szó eredeti értelmében, mivel valódi közép nincs forexen). (Az alját nem néztem meg élőben, az lehet nem * 0.99, hanem lehet / 1.01, a nitpickerek kedvéért.) Ha valaki nem tudja melyik árat kell használni valamelyik irányba váltáskor, a szabály igen egyszerű: amelyik számmal a kevesebbet kapod. :)

Szóval, 1M HUF, USA dollárra váltanánk. 1,000,000/277.75=3600$, 3636-3600=36$ esik le, 10000Ft (ugyanezen árfolyam mellett visszaszámolva).

3%-os időszakban az egyirányú spread 3%, azaz 275-3%, 275+3% a valós váltási szám, 266.75 és 283.25. Ez már gázos, marhára nem mindegy, mikor váltunk (10000 vs. 30000 Ft).

Az IB-nél tökéletesen látszik, mikor mennyi a spread, mivel itt eredeti valójában látjuk a forex piacot sokféle bank mint liquidity provider egybegyúrt árfolyaminfóival. Itt a középhez képest simán lehet 0.1Ft spreaddel váltani. Azaz 1M Ft esetén kapunk 1,000,000 / (275+0.1) = 3635$-t. A rendkívül szűk spread miatt csak 1$ veszik el! Durva. Ez a világ legjobb pénzváltója. Viszont írtam, van min 2$ commission, ami lejön a havi 10$-os account díjból, így a váltásnak praktikusan nincs költsége, csak az 1$-nyi a spread miatt.
Egyébként az IB-s számlán bármennyi deviza lehet egyszerre, nem kötelező átváltani a forintot dollárra. Azonban ha veszünk egy dollár alapú részvényt, akkor annak az ára mint negatív dollár egyenleg jelenik meg a számlán, ami miatt kamatot (interest) kell fizetni. Mivel befektetésben évekig élnek a pozícióink, ez a veszteség jelentős lenne, ezért érdemes átváltani a forintot befektetés előtt.

A spread hatása tehát összegezve a következő. 400e Ft befektetésekor 1%-kal eltolt ár (2% spread) esetén 4000 Ft veszteség keletkezik. Ez hozzájön a korábbi vételi és eladási tranzakciós költséghez, így évi 8.75%-os hozam és a korábbi bróker költségekhez még a váltást hozzávéve ennyi pénzünk lenne 10 év múlva a számlán:

Veszteség nélkül: 6,485,094 Ft
A következők a KBC egyéb költségeivel számolva, csak a spreadet variálva:
1% félspreaddel: 6,293,444 Ft
2% félspreaddel: 6,228,733 Ft
3% félspreaddel: 6,164,012 Ft

30 évre előre tekintve:
Költségek nélkül: 56,997,156
1% félspreaddel: 54,657,547
2% félspreaddel: 54,094,775
3% félspreaddel: 53,532,017

Biztos van, aki szarrágónak tart, de nekem számít az az 1 millió forint különbség a végén, és ha ehhez csak annyit kell tennem, hogy akkor váltsak, amikor kicsi a spread, akkor megteszem. 1 millióból sok farhát kijön majd akkor is – remélem. :)

Az IB a pici spreadje miatt is alulmarad sajnos, a 10$-os minimum számlavezetési díj miatt: 5,966,490 Ft. Az IB egy professzionális tradingre szakosodott bróker, nem egy befektetőkre kiélezett cég.

Csak érdekességképpen, ha 3M Ft-tal indulunk, és évi 4M Ft-ot tolunk be, akkor viszont az IB már leveri az összes többi alternatívát.
10 év után:
IB: 71,525,130
KBC 1%: 70,583,468
KBC 2%: 69,935,974
KBC 3%: 69,288,480

Szóval az IB nagyon olcsó, csak amerikai fizetésekhez van méretezve. :(

Maradt még az adózás és a “különös” költségek.

2015.10.25.

Befektetésről programozóknak 3.

Filed under: Élet,Tőzsde — Soczó Zsolt @ 13:26

Első rész.
Második rész.

Az előző részben az alapkezelési költségét néztük meg.

A következő költség a vételkor és eladáskor kifizetendő tranzakciós költség. Ezt szokták commissionnek hívni.
Ez a költség minden alkalommal, de csak egyszer vonódik le, amikor a pénzünkből veszünk valamilyen értékpapírt, vagy eladjuk azt, azaz nem hat az eddig befektetett pénzre.
Értéke óriási szórást mutat. A biztosítók általában 5% körüli vételi, és 0% eladási költséggel számolnak.
Az brókercégek mindkét irányban számolnak fel költséget, csak sokkal kisebbet. A bankoknál is lehet direktben venni ETF-et és részvényeket, de ezt nem “bátorítják”.

Pár kiragadott példa, amerikai ETF vételre (pl. SPY, ARCA tőzsde).

Unicredit: 2%, min. 150 EUR
CIB: max. 1,5%, min. 100 EUR
Erste NetBroker: 0.3%, min 15 USD (el lehet itt elérni az amerikai tőzsdéket?).
KBC külföld csomag:0.30%, min 7 USD
Interactive Brokers: 0.005 per részvény, de min. 1$, max. 0,5%

Az Este NetBroker és a KBC csak kiragadott példa, nincs időm végignézni az összes magyar brókert, ha valaki tud jót, szóljon, szívesen venném.

Lássuk a számítást, hogy össze tudjuk hasonlítani a költségeket. A kiinduló adatok:
EUR/HUF: 311
USD/HUF: 275

A megvenni kívánt amerikai ETF ára 200$ (pl. az SPY most kb. ezen az áron tradel).
Egyszerre befektetett összeg, 200$-os ETF-be. A biztosítós példát kivéve mindenhol 2x vettem a költségeket, vétel-eladás miatt. A biztosítónál eladási oldalra ezt használtam: “A kivont összeg 2 ezreléke, minimum 200Ft, maximum 2000 Ft.”, a vételire 5%-ot.
(Katt a képre nagyobb mérethez.)

TranCost

Látható, hogy az Interactive Brokers verhetetlen (még amerikai viszonylatban is az élvonalban van), de a magyar piacot nézve e KBC a legkedvezőbb árú. A bankok nem szeretnék, ha náluk ETF-eket vennénk, ők az alapjaikat akarják eladni (az előző részben részletezett okokból, az alapkezelési költségen minden évben stabilan keresnek rajta).
A biztosítók 5%-os díja az összegtől függő, mivel nincsenek minimális és maximális értékek a képletben.

A következő költség maga az értékpapírszámla fenntartási költsége.
Ez egyes cégeknél arányos a számlán található pénzzel, másoknál fix összegű vagy ingyenes. A továbbiakban a bankokat kihagyom, ha közvetlenül a cél részvényt vagy ETF-et akarunk megvenni, arra nem jók a bankok, láthattuk az előző részben. Maradnak a brókerek.

Havi számlavezetési díjak:
Biztosítás: 5400 Ft fix éves költséggel számoltam.

Erste NetBroker: 0,01%, Minimum: 125 Ft., 50M felett részre havi 0.005%

KBC: 0,01%, Minimum: 99 Ft, Maximum: 2 500 Ft. Ez csak a legkisebb csomagra, itt a commission 0,35%, a külföldi csomagban Minimum: 499 Ft, de ott a commission 0,25-0.3, én 0.3-mal számoltam az előző szakaszban. Azaz a számlán található pénzt mérete alapján érdemes csomagot választani vagy váltani.

Interactive Brokers: 10$, de teljes egészében commission-re használható. 100e $ felett ingyenes. :) Ez most még nevetségesen hangzik sokaknak, de aki komolyan gyűjt nyugdíjra (és közben nem lopják el költségekkel), annak simán lesz ennyi 20 év után.
Nem költség, de fontos tudni, hogy az IB-nél a minimum számlaméret 10,000$, így aki itt akar befektetni, annak első alkalommal ki kell tolni 3 misit.

Mit jelent ez egy folyamatosan növekvő befektetési számla esetén? Hogy egyszerűbb legyen a képlet most még fix évi 8.75%-os növekedést tételezek fel, a sorozat végén majd használok igazi adatokat.

A számítások a CostAccComm.xls-ben CostAccComm vannak, az AccountFee lapon (van több lap is benne!). A KBC-nél és az IB-nél nem egyszerű a helyzet, mivel a KBC-nél számla típustól függ a minimum, az IB-nél pedig commission-re fordítható a számla minimum költsége, így ezeknél a számlaköltség commission nélkül hamis számot ad, de majd finomítjuk a modellt (agile YAGNI :).

Tehát, 275 USD/HUF, 8.75%-os éves hozam, évi 400e Ft egyszeri befizetése mellett 10 év után a következő összegek lennének a számlákon (illetve ennyi veszteséget jelent), ha csak a számla költségét rakjuk be a képletbe:

Költségek nélkül: 6,930,585 (0%)
Biztosítás: 6,844,674 (-1.2%)
Erste: 6,878,906 (-0.74%)
KBC: 6,833,466 (-1.4%)
IB: 6,405,574 (-7.5%!)

Meglepő eredmények. Kis pénzről van még szó (befektetésekhez mérten). Az Erste 125Ft-os minimális díja miatt leverte a KBC-t, ahol 499-cel számoltam. Ha a KBC-nél a start csomagot nézem, ami 99Ft-os min havi díjú, akkor 6,880,287 jön ki, amivel egy hajszálnyival már jobb, mint az Erste. De ennél a csomagnál meg drágább a commission, azaz ezen komponens nélkül nincs értelme számolni a számlaköltségekkel.
A biztosítások évi fix 5400 Ft-os díja egy közepes költséget jelent, ha csak ezt néznénk, ki lennék békülve velük.
Ami igazán meglepő lehet, az az Interactive Brokers, 7.5% tűnne el az accountról a min költségek miatt! De természetesen nem eszik ilyen forrón a kását.
1. Okkal 10000$ a minimum számlaméret az IB-nél, másképp a költségek lemorzsolnák a számlát. Lássuk be, az IB nem akar kis traderekkel, befektetőkkel bajlódni. Ezen megsértődhet valaki, de ők nem a tipikus magyar méretekre vannak optimalizálva. 10k$ egy amerikai programozó 1-2 havi bére. Ez van.
2. Az IB traderekre van hangolva, akik simán ledolgozzák a havi 10$-t commissionnel, így nekik ez a költség 0. Mi most ritka, évi 1 tranzakcióról beszélünk, így a min. díj igen jelentős.

Hogy kicsit reálisabb számokat lássunk, tegyük fel induláskor betolunk 3M Ft-ot a számlákra, és évente befektetünk 1.2M Ft-ot (havi 100-at, magyar programozóként ez még reális, ha odafigyelünk a költéseinkre).

10 év után:
Költségek nélkül: 27,781,311
Biztosítás: 27,695,400 (-0.3%)
Erste: 27,552,500 (-0.8%)
KBC (499-cel számolva): 27,550,890 (-0.8%)
IB: 27,256,300 (-1.8%)

A biztosítók fix díja itt már alig vesz le a pénzből.
Az IB még így is sok, az elején amikor még relatíve kis pénz volt a számlán. 100e $ felett az IB ingyenessé válik, az előbbi befektetés pont a 10. év után csap ebbe a sávba.

Azonban fontos érteni, ez még csak a számla alapköltsége volt, hozzá kell venni a tranzakciós költségeket (commission) is.

A következő számítások a korábbi xlsben lesznek, csak az AccountFee+Comm lapon.
Ebben már a számlavezetési díj és a commission is benne van (van még egyéb költség is, így ez se a vége még), 10 év után, évente befektetve:

Költségek nélkül: 6,930,585 (0%)
Biztosítás: 6,498,144 (-6.2%)
Erste: 6,807,898 (-1.7%)
KBC: 6,800,186 (-1.8%)
IB: 6,405,574 (-7.5%!)

Kis pénznél nagy pofont kapnak a befektetett pénzek, főleg az IB-nél és a biztosítóknál.

3M Ft induló tőkével és évi 1,2M befektetéssel:
Költségek nélkül: 27,781,311
Biztosítás: 26,655,813 (-4.0%)
Erste: HUF 27,481,526 (-1.0%)
KBC (499-cel számolva): 27,488,898 (-1.0%)
IB: 27,256,300 (-1.8%)

Így már kiegyenlítettebb a helyzet, a hazai brókereknél a pénzünk 10 év alatt 1%-kel lesz kevesebb az ideális befektetésnél, ezt elfogadhatónak tartom. Az IB-nél így már normálisabb költségek jönnek ki, de még így is sok, mivel csak évente egyszer tradelünk, az IB pedig nagyobb pénzű és sokat kereskedő traderekre van optimalizálva (azért alacsony a commissionje). A biztosítóknál számolt 5% nagy pénzeknél is jelentős hatású, mivel nincs felülről korlátozva.

Összegezve, eddig ezeket a költségeket néztük meg:
1. Alapkezelési költség
2. Számlavezetési díj
3. Commission vagy tranzakciós költség

Mi maradt még hátra?
1. Át kell utalni a befektetni kívánt pénzt a brókerhez vagy biztosítóhoz, ennek van egy költsége.
2. Át kell váltani a Ft-ot valamilyen cél devizára, pl. USA dollárra. Ez jelentős tétel lehet, pedig erre kevesen figyelnek. Az IB itt nagyot hasíthat.
3. Adózás kivételkor. Magyar brókereknél TBSZ, biztosítónál 10 év után…
4. A biztosítóknak még vannak “különös” költségei, ezek durvák.

A következő részben ezen költségeket tekintem át.

Newer Posts »

Powered by WordPress