"Itt a bejelentés: ekkor indul az azonnali átutalás Magyarországon"

( trey | 2020. 01. 28., k - 13:14 )
HUP cikkturkáló

Minden hazai bank felkészült az azonnali átutalási rendszer startjára - hangzott el a Magyar Bankszövetség évindító sajtóbeszélgetésén. A rendszer március másodikán startol, mindenki számára elérhető lesz, akinek hazai számlacsomagja van.

[...]

A GIRO egy új rendszert épített ki, az MNB szabályozza, felügyeli és összefogja a projektet, a bankszektor pedig 30-40 milliárd forintért fejlesztett, a kormányzat pedig támogatja a projektet.

2020. március másodikán indul el az új rendszer, amelyre valamennyi tag felkészült.

[...]

Az azonnali fizetési rendszerről az elnok elmondta, hogy több százezer munkaórát fordítanak a bankszektor munkatársai arra, hogy működjön a rendszer.

Ez a magyar bankrendszer valaha volt legnagyobb beruházása

- jelentette ki Becsei András. Hozzátette, a fejlesztések kapcsán több bank is előrehozta a rendszerfejlesztéseit is, ami mindenképp mutatja a bankszektor elköteleződését az azonnali fizetési rendszer mellett.

Részletek itt.

( mauzi v | 2020. 01. 28., k - 15:49 )

Szerkesztve: 2020. 01. 28., k - 15:50

Whoa!

Remélem a tranzakció SMS értesítésbe belefejlesztették azt a fícsört, hogy "ne zavarj" megadott intervallumban, pl. 18:00 - 07:00 között. (A telefonom nem tud feladó szerint differenciáltan jelezni.)

Pedig ez pont rossz lenne - hiszen ebben az időpontban, ha valaki kezdeményez az ellopott kártyaadataiddal egy vásárlást, nem kapsz róla értesítést, hogy hoppá, le kéne tiltani a kártyádat, mert gond van vele....kontraproduktív, ha egy 2FA-t be lehet úgy állítani, hogy "ne zavarjon".

Pici statisztika: az SMS-ek kézbesítési aránya 98% körüli, a mobil push notification-ok kézbesítési aránya 99.9% feletti volt egy (egyébként nem magyar, de ez nagyjából mindegy) banknál. Más kérdés, hogy az ügyfeleknek közel 100%-a kért SMS-est ott, és csak ~15%-a push notification-t.

Hát igen, ez szerintem elég jó arány. Főleg úgy, hogy a sikeresen kézbesített sms-ekről kapnak visszajelzést az alkalmazások, ha kérnek. Tehát, aki megkapta, arról tutira tudnak. Ez egy nagy előny, főleg ilyen nagy sikeres kézbesítési aránynál. Ráadásul nem kell hozzá se net, se semmi. A külföld az tényleg problémás lehet.

Én rosszul vagyok az SMS-es ökörködésektől. Nézzük az alap felállást: az interneten csinálsz valamit, amihez második faktoros azonosításként SMS-t kérnek.

Gondoljuk csak ezt végig? Internet van, hiszen azon veszed igénybe a szolgáltatást. Mobilhálózat van? Az SMS-ek megjönnek? Teljesen feleslegesen hoz be egy olyan függőséget, amivel csak szophatsz.

Például egy OTP megoldással (Google authenticator és tsai)? Egyébként ezt biztonsági szempontból sem feltétlenül tudom elfogadni. Ha az internetes titkosított csatornáidat kontrollálják, milyen jelentőséggel bír, hogy SMS üzenet után tudsz csak belépni?

Sokkal sűrűbben fordul elő, hogy az SMS nem (időben) érkezik meg, minthogy a TLS-t feltörjék.

En jelenleg nem tudok olyan magyarorszagi bankot mondani, ahol csak az SMS lenne az egyetlen 2FA opcio, es ne lenne valami QR kod olvasgatos vagy OTP-s megoldas. 

Illetve de, a draga jo Erste, de azzal a netbankkal ez a legkisebb baj.

Ha az internetes titkosított csatornáidat kontrollálják, milyen jelentőséggel bír, hogy SMS üzenet után tudsz csak belépni?

A belepes nem erdekes, de az nem art, hogy tranzakcio elott ala kell irni. Az egyenlegem illetektelen kezekbe kerulesetol kevesbe felek , mint attol, hogy ezt az egyenleget valaki atutalja maganak. :)

Ersténél sms, push vagy qr-kód van - az más, hogy a push khm. nem mindenkinek/minden esetben érkezik meg. Per tranzakció is van valami, ha jól rémlik, de mostanában nem csináltam olyan tranzakciót a netbankban, ami "kifelé" küldéssel járt volna, úgyhogy ezt csak emlékezetből írtam :-)

+1, én sem tudtam az Ödönbanknál push-ra váltani - bezzeg nálunk természetesen megy a push is, mindenféle extra hókamóka nélkül.  (jó, rögzíteni kellett a telefonszámomat a netbankos felületen a psd2 élesedése előtt, de erre a mobilapp is meg a netbankunk is minden belépésnél felhívta a figyelmet...)

Nálam az OTP-féle sms-ekkel nincs soha semmi problémám. Bár észrevettem hogy priorizálnak: kártya- és számlakontrollos sms rögtön megjön, ha terhelés, ha jóváírás, illetve a PSD2-es SMS-es is rögtön megérkezik, de van olyan tranzakció amiről utólag értesülök (pl. ha kártyás pénzküldéssel kapok pénzt, ha én küldök a terhelésről rögtön jön). De ez a különbség nem amiatt van, mert SMS-ről van szó, hanem amiatt hogy a kevésbé kritikus típusúakat tömbösítve adják fel.

A TCP nem garantálja azt, hogy biztosan megkapja a másik fél és erről biztosan tud az egyik fél, és nem is garantálhat, lásd a két hadsereg-problémát. A TCP csak csökkenteni tudja egy elviselhető, de még mindig pozitív értékre a nem teljesítés valószínűségét.

És azt meg tudjuk, hogy a gyakorlat és az elmélet között elméletileg nincs különbség, gyakorlatilag van... :)

A TCP-szerű protokollokban az a jó, hogy még katasztrofálisan nagy csomagvesztés esetén is tudja követni mind a két fél, hogy a másik mit kapott meg biztosan, véges idő alatt átmennek a csomagok; ami meg nem megy át, arról tudják, hogy még mindig nem ment át, ezért újra és újra próbálkoznak, mert egyszerűen a küldő addig próbálkozik a csomag küldésével, amíg az adott csomagról nem kap egy ACK-ot, nyilván ez sokáig is eltarthat, de még mielőtt ez a nagy csomagvesztés bekövetkezne, már kimegy egy technikus és felgyújtja a picsába az egész hálózatnak nevezett tyúkbelet.

https://iotguru.cloud

Az, hogy van ACK meg van újrapróbálás nem oldja meg a problémát, mert továbbra is nullánál nagyobb valószínűséggel veszik el az összes ACK. A timeout sem oldja meg a problémát, mert előfordulhat, hogy elment a csomag, elküldésre került az ACK, a küldő fél timeout-ol, a fogadó fél még nem timeout-ol, és ekkor átmegy az ACK ismétlése, viszont az ACK ismétlésére adott ACK már ismét nem megy át. Nyilván ez csak elméleti probléma...

Nincs ACK-ra adott ACK.

Nullánál nagyobb valószínűsége van annak is, hogy egy méretes kisbolygó telibe kapja a Földet, és akkor se csomag, se ACK nem lesz.

Szóval a gyakorlatban értelmetlen az ilyen marginálisan alacsony valószínűségekkel a faszt méregetni, hogy ki tud nagyobbat mondani. Ha 1000 elküldött csomagból pont mindegyik elveszik, akkor az az adatátviteli csatorna fos, de még akkor is ott az 1001.  próbálkozás, amikor átmehet a csomag és mind a két oldal tudja, hogy átment vagy mind a két oldal tudja, hogy ez se ment át.

https://iotguru.cloud

Értem én, de onnan indultunk, hogy az SMS-hez képest a push notification mennyivel megbízhatóbb, mert egyrészt TCP-n megy, másrészt meg ezen felül is van egy visszaigazolási hurok, hogy megkapta és aztán megnézte. Ha én valamit kiküldök TCP csatornán, akkor vagy

1, a másik oldal megkapta és ezt mind a ketten tudjuk
2, timeout jön vissza és tudom, hogy a másik oldal vagy nem kapta meg vagy megkapta, de nem tudja, hogy én megkaptam-e a visszaigazolását, tehát újra kell próbálkoznom, amíg az 1) eset be nem következik.

A kutyát nem érdekli, hogy az esetek 0,0000000000001 vagy 0,00000000000000000001 százalékában mindig pont ez az egy csomag veszik el és nem garantált, mivel elméleti bla-bla-bla, mert mielőtt bekövetkezne ez a helyzet, a parasztok már rég kiegyenesítik a kaszát és felkoncolják a szolgáltató ügyfélszolgálatát, mert nem jön be a Face vagy az Insta.

https://iotguru.cloud

Teljesen nyugodt voltam és vagyok, csak leírtam, hogy mennyire nagy faszságnak gondolom, hogy amikor technikai és műszaki szinten arról beszélünk, hogy a TCP egy garantált protokoll, akkor mindig jön egy-két díszfasz, hogy dehátkéthadseregprobléma.

https://iotguru.cloud

Nem (csak) TCP layer-ről van szó, hanem application-ről.
A szerver tudja, hogy elküldte neked és várja, hogy visszaigazold. Ha nem teszed meg, akkor újraküldi, majd, ha erre sem jön válasz, akkor jó esetben log-olva lesz és legalább észreveszik (ha tömeges).

Hát persze, hogy nem, én nem tudok olyanról ami az lenne és ennyi ügyfelet lehet vele elérni. Ellenben mindenféle egyéb varázslás nélkül tudja a feladó, hogy a címzett megkapta az üzenetet. És a legprimitívebb készülékekkel is működik. Jelenleg még van létjogosultsága szertintem szolgáltatói szinten, főleg az árat figyelembe véve....

Ennek a világon semmi köze nincsa az azonnali fizetési rendszerhez... 

Egy kis érdekesség: https://bian.org/wp-content/uploads/2019/09/BIAN-M4-Value-Chain-V8_0.pdf

Ezt a feltűnően rémisztő ábra tartalmazza azokat a területeket, amelyekkel egy bank általában foglalkozik. Viszonyításként az azonnali fizetések az Operations/Clearing and Settlement/Payment Execution dobozba tartozik, az értesítések meg a Channels/Cross Channel/Channel Activity History részbe. (Az egy teljesen más kérdés, hogy van olyan banki szoftver, ami speciel mindkettőt önállóan csinálja - dehát a banki architektúrákat általában nem a domain-ek szép elkülönítése alakítja, hanem a "melyik már meglévő szoftverbe/haverom szoftverébe lehetne legolcsóbban belerakni/úgy belerakni, hogy mindenki jól járjon a feature-t" vezérelv.)

( peta v | 2020. 01. 28., k - 15:56 )

Jó drágán kommentelték ki a delay, és sleep sorokat az utalások scriptjeiből.

Igazad van, péntek 16:30-tól hétfő reggel 07:00-ig nem lenne éppen hatékony sleep/delay-ozni... Mielőtt túlragoznánk: valahol van egy csodakapcsoló, ami azt jelzi, hogy munkaidő van-e, mert ha nem, akkor még az OTP egyik számlájáról sem megy át a pénz az OTP másik számlájára, hanem csak bekerül a 'feldolgozandók' fájlba.

Gyk: talán nem kellene UFO-energia ahhoz, hogy a mostani éjszakai/hétvégi működést lecseréljék a mostani nappali működésre. (De értem, hogy most nem ez történik, erre nehezebb lett volna  10000 emberév munkát ráírni.)

Gyk: talán nem kellene UFO-energia ahhoz, hogy a mostani éjszakai/hétvégi működést lecseréljék a mostani nappali működésre.

Gyk: ejszaka nem uresjarat van, hanem egy csomo stuff akkor fut ami nappal nem tud. Voltam olyan projektben (nem bank), ahol akkora volt a tranzakciok mennyisege, hogy 24 ora kezdett nem eleg lenni a 24 ora alatt osszegyult tranzakciok feldolgozasara (obviously sorban, mert olyan tema volt) es a napi allapot konzisztens backupjara.

Ezt megoldani baromira nem trivialis, mert hiaba pakolsz ala ~infinite hardvert, ha pl. nem parhuzamosithato a feldolgozas, es a queue-ba gyorsabban toltik a cuccot, mint ahogy ki tudod venni belole. 

A feladat persze megoldhato, ugy nez ki, itt is sikerult, de messze nem olyan egyszeru, mint odabofogni egy forumra, hogy "csak ki kell venni a sleepet". lol

Az ilyen jellegű problémák akkor kezdenek igazán fájdalmasak lenni, amikor nincs 12 óra, mert csak a napi kereskedés zárása után kezdheted (mert akkor keletkezik az input adat), viszont amíg a feldolgozás el nem készül, addig a délutáni/esti műszak nem mehet haza.

De, ehhez _nagyon_ sok energia kell. Nem azért, mert nehéz megoldani, nulláról felépíteni egy, az azonnali fizetési rendszerhez kapcsolódó rendszert... ha nem is könnyű, de nem is nagyon nehéz. Azt mondanám, hogy ~100 embernap fejlesztés, és ugyanannyi tesztelés/hibajavítás. Ez egy közepes feladat, könnyen megugorható.

Na, akkor most ezt az új rendszert illeszd a bank meglévő 811 db egyéb rendszeréhez. Ez jelentősen megdobja a projekt költségeit és idejét, még akkor is, ha minden tökéletesen flottul megy, és minden korábbi rendszer az integrálhatóság magasiskoláját képviselni.

Valahogy így. És a rendszereken felül amelyekből van kismillió, ötven féle platformon 200 féle nyelven és logika mentén megvalósítva, ott van a jogszabályi háttér, ami mindent figyelembe vesz, csak azt nem, hogy manapság már nem kockás füzetben vezetünk számlát. És amikor ezekkel már kibékültél, úgy, ahogy megy a cucc, akkor jön, hogy versenyezz a konkurenciával. :) Jó kaland!

"mert ha nem, akkor még az OTP egyik számlájáról sem megy át a pénz az OTP másik számlájár"

Ez egész biztosan nem igaz. OTP számlák között éjjel nappal lehet utalni, mindegy, hogy a kedvezményezett számla a tiéd-e vagy Marika nénié Mucsajröcsögén. Emellett van egy külön funkció, ha tudod a kedvezményezett bankkártya számát, akkor kártya-kártya küldés is van, ami szinte azonnal teljesül, szintén éjjel nappal. Szoktunk egymásnak pénzt dobálgatni a nejemmel elég gyakran így.

Hát, ennél azért bonyolultabb egy kicsit a dolog. Mondok egy példát, hogy milyen messzire vezető következményei vannak a bankok oldalán ennek az átalakításnak...

Tegyük fel, hogy a kedvesügyfélnek van egy hitele a banknál. A termék definíciója szerint a naptári hónapban kell megérkeznie a törlesztőrészletnek. Korábban ez azt jelentette, hogy a hónap utolsó napján az utolsó napközbeni IG2 csomagban kellett a pénznek megjönnie, ami még a csúszásokkal együtt is azt jelentette, hogy este 20:00 környékén megérkezett a bankba a pénz. A termék definíciója szerint a hónap fordulóján ki kell számolni az ügyfél tartozása kapcsán egy csomó mindent, pl. hogy mennyi a kamattartozása meg a tőketartozása - ami nyilván függ attól, hogy törlesztett-e az ügyfél az adott hónapban. Erre a banknak korábban 20:00-24:00 között volt 4 órája, halleluja, kiszámolták.

Az új rendszer segítségével az ügyfél akár 23:59:59.999-kor is törleszthet elvileg. Hát, eh...

A fentinél nyilván bonyolultabb a helyzet (olyan fogalmak kerülnek elő, mint könyvelési nap és hasonlók), de amiatt, hogy este és reggel között is működik a rendszer, sok banknak át kellett alakítania a saját belső működését, ami millió meg egy helyen épített arra, hogy éjjel nem interaktálnak az ügyféllel sehogysem. Mindezt átgondolva és kivitelezve bankonként párszáz-párezer termékre, lehetőleg úgy, hogy kevés panaszos ügyfél legyen.

Ebben a melóban sajnos elég sok tényleg bonyolult rész is van, meg egészen egyszerűen a mennyisége olyan, amit csak sok munkával lehet megoldani.

Vannak olyan folyamatok, amik az előző napi tranzakciókon mennek végig, és azt dolgozzák fel. Eddig ez mondjuk fixen hajanl 2-kor indult, és mondjuk 4-ig végzett is. Nem kellett szűrnie, mert hajnal 2-kor aznapi tranzakció még nem lehetett a rendszerben. Most, ha csak ennyi lett volna a fejlesztés, ez a script akkor is bedolgozná az aznap 0:00 és 1:59 közötti tranzakciókat is, ami már nem jó. Hamarabb pedig nem indíthatod, mert akkor még más folyamat fut.

Ilyenkor már egy delay kivétele is összedöntené a rendszert, ezért már ez sem lenne ilyen egyszerű.

(Én persze tudom, hogy itt nem ennyi volt, ez egy sokkal összetettebb átalakítás volt. Csak jó tisztába lenni vele, hogy ha egy delay lett volna, annak a kiszedése is hónapok munkája lett volna.)

Nagy Péter

( Charybdis | 2020. 01. 28., k - 17:02 )

SEPA utalásoknál már megvan ez a rendszer, de úgy tudom nem minden országban. De pl. Észtországban már van euró, meg azonnali euró átutalás is. Inkább euróra kellett volna már áttérni és csatlakozni a meglévő azonnali SEPA átutalási rendszerhez, mint fejleszteni egy teljesen újat. De ez is ilyen Hungarikum ezek szerint, hogy találjuk fel a spanyolviaszt sok pénzért. Bulgáriában, Romániában is előbb lesz euró, mint nálunk :(

A SEPA Instant CTS opcionális, csatlakoztunk mi is.

Az hogy van euró vagy nincs az teljesen mindegy a tranzakciók szempontjából, bitfolyam mindegyik.

Itt az MNB tette kötelezővé, ami szemben a SEPA Instant CTS-sel nem opcionális. A fejlesztéseket pedig a bankoknak kell elvégezni, amit a saját költségvetésükből gazdálkodnak ki.
Nem sírok miattuk, van ott pénz bőven.

...úgyis jönnek...

Hozzátenném, hogy (szerintem) a rendszer egyik elbaltázott része pont az, hogy tökre _hasonlít_ a SEPAInst-hez, de nem _azonos_ a SEPAInst-tel.

https://www.giro.hu/letoltes/hct-inst-szabalykonyv

35. oldal, Magyar sajátosságok, pl.:

"A HCT Inst üzenet text típusú mezőiben (ha azok nem azonosítók) az UTF-8 szerinti összes
alapkarakteren (a 32-126 közötti tartományban) kívül kizárólag a (128 fölötti „extended” ASCII
tartományban található) magyar ékezetes karakterek használhatók."

Sok sikert az Őrnagy utcában lakóknak a nagy Ő betűvel. Hogy ez mitől lett jobb, mintha meghagyták volna UTF-8-nak, nos, azt nem tudom.

Nem rossz... Ennyire fogalmatlanul az államigazgatásban  szoktak megnyilatkozni... Hagyján, hogy az 'UTF8'-at 'Unicode' értelemben használja, de honnan tudjam, hogy mi nála az 'extended Ascii' -- 850, 852, cwi1, cwi2, iso8859-1, iso8859-2, 1250, 1252, egyéb? És ha ezt meg is mondja, akkor ténylegesen mi menjen az üzenetben: utf8 vagy a valamilyen singlebyte encoding?

Ez engem arra emlékeztet, amikor a névben lehet magyar ékezet, a jelszóban pedig nem lehet ékezet jellegű specifikációt úgy sikerült implementálni, hogy a névben csak magyar ékezet lehet, a  jelszóban mindenféle ékezet lehet, csak magyar nem...

https://iotguru.cloud

Ennél sokkal nagyobb probléma is van ebben a mondatban. Az Ő betű az legalább magyar ékezetes betű, attól még hogy nem 32-126.  De pl. egy umlautos a már nem magyar ékezetes betű, de attól még nevekben (nem csak magyar személy nyithat számlát) és valószínűleg címekben is megtalálható lehet.

Azert nincs euro, mert akkor az egybites is latna, hogy itt 500 a fizetes osztrakoknal 2000 nemeteknel meg 3000 ugyanazert a kuliert.

Nem mellekesen ha rontod a forintot, akkor a munkas nagyon olcso lesz, ez jo is, csak a rabszolga mar nincs roghozkotve svajci frank hitellel meg a sajat ostobasagaval ami a legnagyobb.

Vagy esetunkben fejlesztoi teruleten 2500 korul, meg a legrosszabb osztrak ajanlat ami beesett az 8400.

http://karikasostor.hu - Az autentikus zajforrás.

Hát ja, csak közben meg ha lenne euró, külföldi cégek is talán könnyebben jönnének.

Pl. Stripe még mindig nincs Magyarországon, viszont Észtországban már van. Gondolom azért, mert ott euró van.

Ez csak egy példa volt, de az tuti, hogy sok cégnek (mint most pl. a bankoknak ugye) túl sok felesleges kiadást jelent, hogy még mindig ez a gyenge kis forintunk van. 

> Ez csak egy példa volt, de az tuti, hogy sok cégnek (mint most pl. a bankoknak ugye) túl sok felesleges kiadást jelent, hogy még mindig ez a gyenge kis forintunk van. 

Nem nehéz összehozni, mivel 5000Ft-os SEPA átutalásra 2610Ft-os díj-at számol fel az OTP (0,35% min. 2 610 Ft/ max. 15 000 Ft).

Ez különösen kellemetlen volt, amikor külföldi payment processor hetente automatikusan utalta a kifizetett összegeket. A megoldás egy külföldi bankszámla nyitás, majd onnan TW-al hazajuttatni az összeget, de macera + további költségek.

Van az az elmélet, amely szerint a 350+ os euró is feltétele volt, hogy a BMW debrecenben telepedjen meg :) Ezt euróval ugye nem lehetett megtenni.

Miért jó a 350-es euró a bmw-nek? Mert ő euróban számolja a fizetést.

Ha a magyar belekerül neki (adókkal) 300 000 Ft-ba. Az 300-as eurónál 1000, 350-esnél meg 857 euró. 15%. Induláskor 1000, később 2500 fő kulis lesz ott rabszolgáztatva.

Éves szinten ez bizony 1,7 millió euró.. hát, ezt még át kell számolni, mert egy BMW-nek ez kerekítési hiba.

( toMpEr | 2020. 01. 28., k - 17:22 )

40 milliárd / 100 000 munkaóra = 400ezer / óra nem rossz...

A Bitcoin 8000 programsorból megvolt, bár ez biztos sokkal bonyolultabb rendszer, de azért a többszázezer munkaórát kicsit túlzásnak érzem.

A 30-40 milliárd csak becslés lehet, mivel a bankok nem fogják megmondani a teljes költségét az MNB-nek, mivel nem kötelező.

A fenti összegbe pedig beletartozik minden (infrastruktúra csere/frissítés; új megoldások, szolgáltatások bevezetése/vásárlása; konzultáció; oktatás, stb...).
A munkaórát meg ne egy emberre osszuk el, hanem sok-sok emberre. Így kicsit másképp jön ki a matek.

Ha 400ezer / óráért eladnának a kereskedő kollegák, akkor fényesre lenne nyalva mindenük, nemtől függetlenül. :)
 

...úgyis jönnek...

Ezt ebben a formában nem tudod jól, de majdnem.

Sokféle teszt van, és a jellemző, hogy a bankok csoportokba vannak szervezve, és egymással tesztelhetnek, úgy, ahogy megbeszélik + vannak kötelező formamutatványok, amiket be kell mutatni, pl. a napi átlagos tranzakcióforgalom felét át kell tolni adott napon a rendszeren meg hasonlók. A részletek (csoportok, pontos követelmények stb.) a szereplőkön kívül mások számára azt hiszem nem publikusak (pedig nagy titok nincs bennük).

Hát attól függ, hogy mennyire nem olvastad el a lehetőségeidet. Nekem ingyenes bankszámlám van, ingyenes dombornyomott kártyával, ingyen netbankkal. Elég egyszerű feltétele van ennek, oda kell érkeznie a fizetésemnek, és használni a kártyát. Ami nem abból áll, hogy fizetésnapon leballagok és kp-ra konvertálom az egészet, hanem teljesen kp. mentesen élek, mindenhol csak kártya. Emiatt van egy extrám is, a bankszámlámon lévő pénz IS kamatozik, nem csak az amúgy bármilyen számlavezetés nélkül igénybe vett megtakarítási számla. 

Aktív bankkártya mellett van egy digitális kártyám, ami évi pár száz ft.

Van egy hitelkártya, ami bárhol használható azonnal 0THM-es áruhitelre, ennek havi díja van, ami magát a számlát, a kártyát, a netbankot, és egy fedezeti biztosítást tartalmaz, hogy ha ellopják és felhasználják a kártyát, akkor a teljes összeget, amit elloptak, bizony visszaadja a biztosító. 

openSUSE Leap 15

Emiatt van egy extrám is, a bankszámlámon lévő pénz IS kamatozik, nem csak az amúgy bármilyen számlavezetés nélkül igénybe vett megtakarítási számla. 

Mennyit is? A bank nem jotekonysagi intezmeny - ha 0.15% "premium" kamatra ott tartod a penzed, akkor az ingyen szamlavezetes nem akkora deal.

Amikor utoljara bankot valtottam, dragabb lett a szamlavezetes X forinttal, viszont Y>X forinttal csokkent az ertekpapir szamlavezetes es -tranzakciok koltsege, es Z>>>>>X forinttal csokkent a lakashitel torleszto. Nem olyan bonyolult ez. Mire vagy pontosan kivancsi?

Ha azt mondta volna, hogy X forintrol Y forintra csokkent az osszes banki koltseg, azt elhiszem, es egy pillanatig nem firtattam volna a kerdest. Ha azt mondta volna, hogy neki A bank szimpatikusabb mint B bank, azt megertem, az ember nem robot, ez is lehet egy szempont.

Viszont. Azert nevezem marketingnek, mert olyanokat irt, hogy "Amíg nem akar lehúzni, mint egyes más bankocska, addig nem sajnálom tőle azt a pár %-ot". Ebbol ket dologra tudok kovetkeztetni (es fixme, ha tevednek):

  • igazabol ki sem szamolta a pontos osszeget ("par" szazalek? az eppenseggel eleg sok is lehet), vagy
  • mukodik a marketing: kemenyen dolgozik a bank, az en erdekeimet nezi, nyugodtan lehet nekik csopogtetni egy kis extra zsetont a munkajukert

A bank egy for-profit intezmeny. Nincs olyan, hogy ingyen van. 

Jaja, mindent megértesz, csak azt nem, hogy jó így neki. Találgatás helyett legalább megkérdezhetnéd, hogy mi van, és akkor talán elmondaná, hogy miért elégedett. De nem, te mint valami cápává változott ügynök próbálod a farkaddal beleverni a fejébe, hogy szar neki.

:)

Egy konkret, szamszeru ertekre kerdeztem ra. Nem olyan bonyolult ez.

Sosem dolgoztam olyan banknal, ami Magyarorszagon vegez penzugyi tevekenyseget, ugyhogy oszinten nem erdekel, ki hol tartja a penzet. Az ideologia viszont erdekel mogotte, mert amig az atlagember 5% kulonbsegert az arukereson mar egybol kattint az eloreutalos kamu webshopra (itt a hupon is szoktak neha sirni, hogy beszoptak), addig penzugyi teruleten ugy dobaloznak 5%-okkal, hogy orom nezni.

Bár a korábbi hozzászóló csomagját nem ismerem, de nekem nincs sem számlavezetési díjam, se az utalásnak díja 100.000 huf/tétel alatt (bármennyiszer egy hónapban). 30 tételben akár 3 millió forintot is el tudok utalni belföldön bárhová ingyenesen. A készpénzfelvétel Havi 150 ezer forinting nyilatkozat nélkül is ingyenes, mint ahogyan a készpénz befizetés is.

Továbbá:

  • NetBank használat díjmentes
  • SMS értesítés a Netbankba történő - sikeres / sikertelen - belépésről (belföldi számra) díjmentes
  • Aláíró / Megerősítő Kódszó igénylése SMS-ben (belföldi számra) díjmentes
  • Napi egyenlegértesítő SMS (belföldi számra) díjmentes 
  • Push üzenet a NetBankba történő - sikeres / sikertelen - belépésről díjmentes 
  • Aláíró / Megerősítő Kódszó igénylése Push üzenetben díjmentes 

A Dombornyomott MasterCard bankkártya 315 Ft.

Ja, és Forgalmi kivonat postai kiküldéssel: 0 Ft/kivonat (de nem kérem, jó nekem a netbankban)

Mindemellett kb 5 éve egy hitel miatt kellett hiteles igazolást kérnem a számlatörténetemről. Bementem, elmondtam, hogy mit szeretnék. Nyomtattak vagy 40 oldalt, lepecsételték, aláírták mind. Azért sem kellett egy forintot sem fizetnem.

Szóval az nem igaz, hogy biztosan mindenkinek csak ügyes marketingesei vannak, és közben meg lehúzzák az embert. Lehet olyan számlacsomagja valakinek, ami megéri neki, és mondható rá joggal, hogy ingyenes.

Nagy Péter

Óh, egyszer érteném meg: miért kell nekem RAGASZKODNOM ahhoz, hogy amit meg lehet keresni az én pénzemmel, az feltétlenül az enyém legyen? Csücskösített példa: ha a család számára vásárolt zsírosbödönt nem töröljük ki kenyérrel, hanem kinyalja a kutya a felületén maradt zsírt, akkor pazarolok?

Lehet, hogy vannak emberek, akiknek fontos, hogy ne kelljen figyelni a költségek mértékét (mert nincsenek), ugyanakkor őt sem érdekli, mennyi LEHETNE MÉG a haszna.

Én momentán megértem a kedves hozzászólót (no offense).

miért kell nekem RAGASZKODNOM ahhoz, hogy amit meg lehet keresni az én pénzemmel, az feltétlenül az enyém legyen?

Ha te dolgoztal meg azert a penzert, akkor ez nem olyan elvetemult elvaras. En is szoktam adakozni, altalaban havonta egy fix osszeget mindig mashova, de meg soha nem adakoztam banknak. 

Meg az is, hogy a magyarok bankolása ne abból álljon, hogy amint megérkezik a fizu, kirántja egy ATM-ből KP-ben...mert onnantól ellenőrizhetetlen, hogy Béla számla nélkül olcsóbban dolgozik nekem. :D Az is igaz, hogy a kancsal unortodox óta nem nagyon érdemes megtakarítani, mert a megtakarítás rosszabb esetben több pénzbe kerül, mint amennyit hoz. De ez a kancsal előtt nem így volt. Csak akkor mindenki olvasás nélkül deviza hitelért rohangált, mer'olcsó. Szumma szummárum, a magyarok pü-i kultúrája van a béka segge alatt és ez az alapvető baj szerintem. Én egy átlagos kis faluban élek 2000 óta. Ha a helyi információs tőzsdén - kocsma - a beszélgetés erre fordul és kimondom a "lekötött betét", "rulirozó", "kamat", kamatos kamat", "sávos kamat" vagy arra vetemedek, hogy az "értékpapír" szót használom, akkor arra mindig az a reakció "Mer'a zsidók...", "Mér'a zsidóknak...", "Zsidók vezetik a világot.", "Egy zsidó felülről irányít mindent". Szóval ezt pü-i kultúrának hívni, hát lehet, csak akkor a pü-i kultúrára kéne egy új kifejezés.

( krix v | 2020. 01. 28., k - 18:37 )

"- jelentette ki Becsei András. Hozzátette, a fejlesztések kapcsán több bank is előrehozta a rendszerfejlesztéseit is, ami mindenképp mutatja a bankszektor elköteleződését az azonnali fizetési rendszer mellett."

btw ezt csak én érzem úgy, hogy több bank itt == a hazai nagyobb bankok -> már réges rég fel vannak készülve erre (értsd, 0 érték 1-re állítása a konfigban kb) , de azért kellett valami szöveg ehhez hogy "eladható" legyen PRilag is ?

Vagy csak kicsit naív vagyok? :) 

Keresed a kakán a csomót rendesen. Elkészült. Én háromról is tudom. De nem ülnek ölbe tett kézzel, azt az egyszeri ember gondolja. Az elkészült itt azt jelenti - mint minden szoftvernél - hogy márciusban el fognak tudni indulni vele. A használata meg majd megmutatja, ki mire nem gondolt, ide értve az MNB-t, a törvényhozót, a GIRO-t és persze az adott bankot.

Na, akkor pattogjon a labda nálad. Egy példát mondjál kész szoftverre, ami az általad itt feszegetett módon készen van, soha többé egy bit nem változik benne, mer'kész van he! (Hajbazer mondaná, hogy a ZIKSZPÉ, de azt is csak abbahagyták.)

"Kész szoftver nincs, csak használatba vehető/használatba vett", mondtam korábban. És pont emiatt nem tudok olyat mondani, ami készen van :-P És a "márciusban el fognak tudni indulni vele" az pontosan annyit jelent, hogy "használatba vehető/használatba vett" (hiszen mennek az éles tesztek ugye...).
Hogy márciustól ki fog tudni elindulni, azt csak az égiek meg az MNB (de ebben nem vagyok biztos...) tudják :-D Most megyek vissza gályázni, mert ugyan elindulni el fogunk tudni mi is, de addig még van teendőnk, hogy jobban, üzembiztosabban, gördülékenyebben menjen az indulás és az afr éles üzeme. (Mert nem elindulni nehéz, hanem az sla-nak megfelelően működni/üzemel(tet)ni hosszabb távon).

Hogy az MNB, GIRO, meg a paragrafushuszárok mire gondoltak az egy (de lehet,hogy három vagy több) dolog, és vagy kiderül, vagy nem - a másik oldalon viszont tudom, hogy néhanapján mire gondolnak/gondolunk velük (és szűkebb környezetükkel) kapcsolatban :-D

Elég ránézni a webes jelenlétére ezeknek a bankoknak. 3 bankszámlám van, így csak ezekről tudok nyilatkozni:

 - OTP: Ez a legnormálisabb, de gyakran van, hogy 30+mp-ig teker a mobil app, a max 1 hónapos visszanézhetőség a számlatörténetben egy vicc. Tegnap a mobil app órákig nem működött, a webes felület meg hibás jelszó hibát dobott (ma ugyanazokkal az adatokkal belépett)

 - Raiffeisen: Elavult design, max 1 évig lehet visszanézni az utalásokat, sms-es küldözgetés mindenhol, próbáltak rámbeszélni értékpapír befektetést, de kiderült, hogy csak egy telefonszámot tárcsázva lehet a tranzakciókat intézni

 - Gránit bank: Ugyancsak 10évvel ezelőtti design, mobil app megbízhatatlan, utalásokat új partnernek csak a web-es felületen keresztül lehet intézni

Az elmúlt 1 évben mindhárom banknál volt szerencsém személyes ügyéntézést igénybe venni: mindhárom helyről egy mappányi papírral távoztam 1 órás ügyéntézés után. (weben keresztül 5 perc alatt elintézhető lett volna, ha lett volna ilyen opció) 

Elavult design ... 10évvel ezelőtti design

Én visszasírom az erste netbank régi, kőkorszaki felületét, mert ez az új netbank egy kalap szar. Most tekintsünk el a "modern", gyávaszkriptes megoldásoktól, mert nem elsősorban attól szar, hanem ahogy megcsinálták.

Pl. a kártyaforgalomnál a megjelenített dátum a tranzakció könyvelésének dátuma, ami helyett én nyilván azt szeretném látni, amikor az a kurva fizetés történt. Aztán a korábbi 15 perces timeout-ot levették 5 percre, ami önmagában is faszkorbácsdíjas mutatvány, de tudják fokozni! Egyrészt ez úgy 5 perc, hogy 3 perc után jön egy figyelmeztetés, hogy akarod-e folytatni amit csinálsz, és ha ezt választod, akkor sallangmentesen újratölti a felületet, minden addig bevitt adatnak annyi. (Ha nemet nyomsz, vagy letelik még 2 perc, akkor kivág, ez OK). Ja, és a rendelkezésedre álló - valójában - 3 percben hiába pötyögsz be dolgokat pl. az átutalásnál, az 5 perces visszaszámlálás simán megy mellette, csak akkor "nullázódik vissza" 5 percre, ha valami új lapot tölt be. Nem tudom, hogy szándékosan tudnék-e ekkora szemetet összehozni...

Detto minden fentebb leírt szóval egyetértek. Régen csodálkoztam h. másnak (pl. az istenveréses fosadék unicredit) milyen netbank nyűgjei vannak, mikor erste-nél villámgyorsan és egyszerűen ment minden hosszú éveken keresztül. Aztán 2018 októberében jól szétbaszták az egészet.

Kedvencem h. az időt a sajátgép órájáról veszi a GUI. Beállítom az időzáras kártyalimitet X óra Y perc. Letelt az idő a netbankon látszódó óra alapján, már mennie kell a fizetésnek, erre elutasítja. Vagy 2x rápróbáltam, de továbbra is reject. Ekkor nézem meg jobban a telefonom óráját: b+ még mindig van 2 perc a limit tényleges aktiválódásáig. Kiderült h. a gép órája vagy 7-8 perccel sietett. No comment, szerintem azóta is szar.

Aztán a korábbi 15 perces timeout-ot levették 5 percre, ami önmagában is faszkorbácsdíjas mutatvány, de tudják fokozni! Egyrészt ez úgy 5 perc, hogy 3 perc után jön egy figyelmeztetés, hogy akarod-e folytatni amit csinálsz, és ha ezt választod, akkor sallangmentesen újratölti a felületet, minden addig bevitt adatnak annyi. (Ha nemet nyomsz, vagy letelik még 2 perc, akkor kivág, ez OK). Ja, és a rendelkezésedre álló - valójában - 3 percben hiába pötyögsz be dolgokat pl. az átutalásnál, az 5 perces visszaszámlálás simán megy mellette, csak akkor "nullázódik vissza" 5 percre, ha valami új lapot tölt be. Nem tudom, hogy szándékosan tudnék-e ekkora szemetet összehozni...

Es amikor irtam nekik bugreportot, hogy az 5 perc az valojaban 3 es egy felkesz atutalas adatainak figyelmeztetes nelkuli kukazasa csak kellemetlen, de egy fogalmazas alatt allo reklamalo levelet kitorolni igazan nem szep dolog, akkor meg valaszoltak is, hogy "igen, a rendszer 3 perc utan alaphelyzetbe all, vagy kileptet."

/O\

Azota gondolom valakinel leeshetett a papirtantusz, mert nem reg feljebb vettek 3 percrol. Azt nem probaltam, hogy tovabbra is kirantja-e a szonyeget a labad alol.

Mennyi időtartomány az, amíg vissza akarod nézni a tranzakcióidat? Egyébként online addig tudod visszanézni, amíg a bank rendszere tárolja a live rendszerben. Az archív lekérdezés menüpontot keresed, de az nincs. Amikor te csak bankon belül utalsz, akkor is több számlamozgás van, mint egy terhelés és egy jóváírás. Az összes statisztika, technikai számla, ami az adott tranzakcióban érintett, kap terhelést és jóváírást.

Kicsit számoljunk: HUP Banknak van 400.000 magánszemély és 30.000 üzleti ügyfele.

Az üzletiek átlag napi két tranzakcióval bírnak, egy utalás, egy utalás fogadás.

A lakosságiak havonta egy utalás fogadás és öt utalást generálnak havonta.

Legyen ez egy egyszerű bank, ami csak forintban és csak utalni tud és egy tranzakció csak négy számlamozgással jár. 

Üzleti ügyfelek tehát napi nyolc számlamozgást generálnak, ami 8*365=2920 számlamozgás/év/ügyfél. 30.000 ügyfél tehát évente 87.600.000 számlamozgást termel a tranzakciós file-ba.

Lakossági ügyfelek 24 számlamozgást generálnak havonta, tehát 24*12=288 számlamozgás/év/ügyfél. 400.000 ügyfél tehát évente 115.200.000 számlamozgást termel a tranzakciós file-ba.

A bank rendszerében tehát egy évben átlagosan 202.800.000 rekord van, amiből te a saját számláidhoz tartozókat lekérdezheted egy évre visszamenőleg. Ebből kiderül, kinek, mikor, honnan és mennyit utaltál, milyen közleménnyel, milyen tranzakciótípussal, illetve ugyanez az ellenkező irányból. Ez CSAK a tranzakciós file!

Ehhez hozzáadódnak normál bank esetében a kártya tranzakciók, konverziós ügyletek, betétek, hitelek amelyek sokkal bonyolultabbak a technikai számlamozgások tekintetében, azután a könyveléstechnikai számlák, amelyeken megjelennek napi, havi stb. összegzett forgalmak - vannak jelentési kötelezettségek is ugye - a deviza ügyletek - konverziós számlák, devizaszámlák és statisztikai számláik - értékpapír számlák, és még hosszan sorolható mi minden.

Minezt úgy kell tudni, hogy egy banknál a tv-i keretek között van előre és vissza dátumozott tranzakció is, így ez a file, érdekes struktúrákat tud produkálni. Arról a pár ezer járulékos file-ról nem beszélek, ami minden tranzakciónál megmozdul. Szóval ezen az adatmennyiségen kell minden nap rendszert zárni, úgy, hogy egy másolatán te éjfélkor is tudj a pizzádért fizetni online, de az reggel már a live rendszerben látszódjon. Riportok állnak elő a zárásban, ügyletek járnak le és könyvelődnek automatikusan, ügyfélértesítők készülnek, kivonatok és társai. A 24 órás ügyféligény miatt folyamatosan naprakészen rendelkezésre áll egy árnyék rendszer, hogy crash esetén egy eljárással erre átálljanak, mert ha ez a kis file, amit itt tranzakciós file-nak nevezünk, megsérül akár egy diszkhiba miatt, akármi más miatt, nos ennek a visszatöltése sem triviális önmagában, az indexeinek a felépítése órákig is tarthat, de belátható, hogy ebben az esetben a rendszer egy konzisztens állapotára van szükség, nem elég a sérült file helyreállítására - audit - hanem az egész adatbázist kell előkapni valahonnan. De te közben rendelhetsz pizzát, mert működni fog a bank. 

Te mennyi időre adnál lekérdezési lehetőséget? Felelősséggel, 24 órás rendelkezésre állás biztosítása mellett és olyan, a pü-i élet terén "felkészült" ügyfelekkel, mint amilyen te is vagy. Az elmúlt harminc évben hány olyan esetről tudsz beszámolni, amikor egy bank úgy robbant le, hogy az ügyfelei csal kamillázni tudtak? Ebből hányat produkált az otp, a postabank és társai?

> Mennyi időtartomány az, amíg vissza akarod nézni a tranzakcióidat?

legalább jelenlegi + előző év (pl. adóbevalláshoz kellhet)

> A bank rendszerében tehát egy évben átlagosan 202.800.000 rekord van 

Ez nem egy nagy szám, de ha az éles banki adatbázisban tárolás és keresés lassú, akkor a régebbi adatok lekérdezését egy külön rendszer is tudja biztosítani.

Azért ne tegyünk úgy, mintha ez olyan irdatlan nagy adatbázis lenne, másrészt pedig a legtöbb ügyfélnek elég lenne, ha a havi kivonatok elérhetőek lennének a számlanyitástól kezdve, ami szintén nem egy olyan nagy feladat, ki kell toszni szalagra a bármilyen formátumba kiexportált havi kivonat adatait.

https://iotguru.cloud

Az ilyen "nem olyan nagy feladat"-okból van párszáz, olyanokis,amikre álmodban sem gondolsz. Az, hogy szerinted elég lenne minden üf.-nek a pdf kivonatot elrakni a bank részéről az érdekes felvetés, van nekije GDPR-es és egyéb vonzata is (ki férhet, ki fért hozzá, kinek a kivonatait lehet tárolni ésmeddig, hogyan mented, illetve archiválod, satöbbi), a workflow-ba belerakni, hogy rakja el a rendszer, a legkisebb probléma vagy feladat.
 

> ki férhet, ki fért hozzá,

Ugyanaz aki a tegnapi adatokhoz. Miért lenne ez más? (otp aszf szerint 5 évig visszakérhető bármi, még a telefonos felvétel is)

> kinek a kivonatait lehet tárolni ésmeddig, hogyan mented, illetve archiválod, satöbbi

Ezzel azt akarod mondani, hogy jelenleg nincs nincsenek tárolva az 1 évnél régebbi átutalások, mert túl bonyolult lenne? 

otp aszf szerint 5 évig visszakérhető bármi, még a telefonos felvétel is

Jo, de ha az ot evvel ezelotti kivonat kell, akkor rachetelsz az Ugyfelszolgalatos Alexara (nekem amugy mindig Alexandra van, ez veletlen, vagy hardcoded a nev? :D), es elkuldi neked viszonylag gyorsan. Szerintem ez boven jo, nekem nem feltetlen kell, hogy a netbankban dinamikusan lehessen query-zni ot evre visszamenoleg, ott eleg a PDF. Sot, altalaban ilyen idotavra mar nem a tranzakciok listaja kell, hanem a hivatalos kivonat NAV-hoz, stb.

Általában az van, hogy úgyis meg kell oldani, ha nem te kéred el ügyfélként, akkor egy front office és/vagy back office ügyintéző fog szopni a dologgal, az meg több pénzbe kerül, mintha ügyfélként magad meg tudod oldani. Sőt, könnyen lehet azt mondani, hogy tessék letölteni az internet banki felületen, mert ott ingyen van.

https://iotguru.cloud

Én nem a kivonatról beszélek (az gondolom alap, hogy le tudjam tölteni visszamenőleg mindet), hanem konkrétan tranzakciót tudok keresni 5 évvel ezelőtt is (annél régebben azért nem, mert 5 éve nyitottam a számlát). Szóval, az felesleges picsogás, hogy nem LEHET megoldani. Maximum azt lehet mondani, hogy nem akarják megoldani, vagy nem kell.

Jó, de akkor jövőre már hat évre akarsz keresni és ha húsz év múlva nézed, akkor már negyed századra...ne akard. Vagy keress olyan bankot, aki ezt bevállalja. Az ügyfelek zöme megelégedik az egy évvel, régebbit pedig kikér e-mail vagy telefonos üf útján és kész.

Vagy elmegy más szolgáltatóhoz, akik ki tudják szolgálni ezt az "irreális" igényt.

A Transferwise esetén például nincs limit erre, pedig több mint 6 millió havi szinten aktív ügyfelük és több mint 4 milliárd GBP a forgalmuk, ismétlem, havonta. A Revolut esetén is simán egy suhintással visszamegyek három évet, mobilon, pedig nekik is 4 millió felett van a havi szinten aktív ügyfelük és nekik és 4 milliárd GBP felett van a forgalmuk, ismétlem, havonta.

Tudom, balfaszok, bezzeg a nagy múltú patinás bankok a talicskányi öltönyös pogácsazabálóval, azok aztán tudják, hogy ez lehetetlen dolog, meg se próbálkoznak ilyesmivel.

Nem tudom miért van az, hogy aki nagybankban dolgozik, rögtön úgy gondolja, hogy az a szakma csúcsa. Lófaszt.

https://iotguru.cloud

A Revolut több mint egy éve bank. A Transferwise nem bank, hanem Electronic Money Institution, a két dolog között az alapvető működési szabályokat tekintve semmi különbség nincs, üzleti szabályokban van különbség, hogy például nincs lehetőségük betétgyűjtésre és nem hitelezhetnek, meg ilyesmi, de semmilyen egyéb szempontból nem működhetnek lazábban, mint a bankok.

A véleményed szerint amúgy mikortól lesz IT szempontból bank egy pénzintézet, amikortól nem fogják tudni kiszolgálni egy éven túl a számlatörténetet? Vagy mi nálad a vízválasztó? Szerintem most belementél egy olyan csőbe, amiből nem tudsz jól kijönni...

https://iotguru.cloud

" nincs lehetőségük betétgyűjtésre és nem hitelezhetnek, meg ilyesmi, " na ennek a szabályozási,  IT és üzleti vonzatai nem terhelik őket... Bőven elég, hogy olcsóbban működjenek.
 

A bank nem IT-szempontból bank, hanem attól, hogy banki tevékenységre a felügyelettől engedélyt kap, és ennek birtokában a banki/bankszerű működéshez szükséges funkciókat, illetve azok jelentős részét megvalósítja. talán Zizi linkelte ezt a doksit - javaslom tanulmányozásra - ezt "csinája" egy bank...

na ennek a szabályozási,  IT és üzleti vonzatai nem terhelik őket... Bőven elég, hogy olcsóbban működjenek.

És pusztán ettől képesek lesznek kiszolgálni évekre visszamenőleg a tranzakciótörténetet, míg egy bank nem? Szerintem ezt te se gondolod komolyan, holnap szégyellni fogod ezeket a mondatokat.

A bank nem IT-szempontból bank, hanem attól, hogy banki tevékenységre a felügyelettől engedélyt kap, és ennek birtokában a banki/bankszerű működéshez szükséges funkciókat, illetve azok jelentős részét megvalósítja.

Képzeld, egy EMI is pont ilyen. A Revolut viszont bank, ott mi az érved? Amúgy a helyzet az, hogy még mindig az a téma, hogy mitől is annyira kurvára nehéz egy olyan tranzakciótörténetet implementálni, aminél évekre visszamenőleg meg lehet nézni online, azonnal, hogy mi történt és ezzel kapcsolatban teljesen irreleváns ez a mondatod, szóval ismét a bullshit megy...

https://iotguru.cloud

" És pusztán ettől képesek lesznek kiszolgálni évekre visszamenőleg a tranzakciótörténetet " - meglehet. Meg attól, hogy nem a magyar jogrendnek kell megfelelni - ezt se felejtsd el. És a revolut, ha megnézed alaposan, a banki funkcióknak csak egy elég szűk körét fedi le, úgy a szolgáltatásai,mint a működése tekintetében.
És mégegyszer, sokadszor: nem technológiailag kurvára nehéz implementálni, hanem az erre vonatkozó szabályoknak megfelelően implementálni és üzemeltetni nem egyszerű - és nem olcsó. És ha nincs rá tömeges igény valahol, akkor nem fognak beletolni egy rakat pénzt, hogy legyen. (Igen, egy rakat pénz kell hozzá, mert sem a vas, sem az üzemeltető nincs ingyen - nem, a tegyék ki egy teszklóspécére sata diszkekkel nem megoldás a vasra)

Aham, szóval szerinted egy-két nagyságrenddel több ügyféllel, havi tranzakcióval és forgalommal azért könnyebb megvalósítani évekre visszamenőleges online számlatörténetet, mert nem kell a magyar jogrendnek megfelelni vagy mert nincs például lakáshitel workflow? Áruld el már legyél oly kedves, mi az a különleges dolog a magyar jogrendben, ami miatt magyarországi bankok egy része erre képtelen? Vagy mi köze a hitelezésnek ahhoz, hogy mennyi tranzakciót lehet online megmutatni az ügyfélnek?

Szerintem aludj erre a dologra, mert egyre nagyobb faszságokat beszélsz és meg fogod bánni, ha visszaolvasod. Never go full retard...

https://iotguru.cloud

Te fejlesztő-only üzemmódban vagy, én meg nem. És a fejlesztők általában nemlátnak messzebb a kódjuknál. Egyébként nema zt mondtam, hogy azért, hanem lehet az is az egyik ok. A másikmeg az, hogy nem egy n+sok fejlesztő által összelapátolt bughal... akarom mondani (nem)integrált banki rendszerhez kellett hozzádrótozni egy funklciót, hanem alapból így lett kialakítva a számlavezető rendszer.

Egyébként meg az egy ilyen "szolgáltatás" elég cinkes is lehet - gondold végig: ha a szolgáltatáshoz tárolni kell a régi számlatörténetet, akkor az az adatkezelést - minden ügyfél tekintetében - jogszerűvé teszi. És senki nem ellenőrzi, hogy ezen histroikus adatokat a majdnembank csak az adott szolgáltatáshoz, vagy épp adatbányászatra is használja.

Szerintem nézd át a lineklt pdf-et, gondold végig, hogy az abban lévő elemekből mennyi szükséges, és mennyi "jó ha van" például a revolut működéséhez. Annak a revolut-nak a működéséhez, amely tetszőleges üf. beérkező utalását zárolhatja indoklás nélkül, és saját belátása alapján, vitatható adatkérések után "majd valamikor" oldja fel a zárolást.

Ja, olvass utána, milyen megőrzési időkkel működhet egy banki számlavezető rendszer - ez az egyik, a másik meg próbáld végiggondolni, hogy egy, az élessel azonos védelmet igénylő, egyre nagyobb adatmennyiséget kezelő archív rendszer menniybe kerülne, és mennyi hasznot hozna, majd hasonlítsd össze a két becsült értéket, és számold ki,hogy hányszorosa az egyik a másiknak, és hogy az így kijött időtávban megtérülő rendszert érdemes- e megcsinálni.

Ha figyelmesen olvastál volna, akkor láthattad volna, hogy több projektem is volt bankban, de ezek közül egy olyan is volt, ahol az éves 202.800.000 rekordos - vastagon kiemelt - tranzakciószámodat nagyjából 15-20 perc alatt érte el a rendszer. És persze 7/24 üzemű volt.

Komolyan, tényleg ott tartunk, hogy a magyar banki szakma krémje szerint szinte a lehetetlennel határos küldetés online lekérdezni egy évnél korábbi számlatörténetet? Tényleg?!

https://iotguru.cloud

Hol lett leírva, hogy lehetetlen? Értő olvasás...? Az lett leírva, hogy picit összetettebb annál, hogy "írok egy-két select-et, a kimenetet meg odaadom egy pdf-generátornak, és kész". Úgy szoftverben, mint infrastruktúrában, illetve szabályozási dolgokban több/összetettebb. Ja, és van olyan is, hogy üzletileg megéri/nem éri meg.

Hol lett leírva, hogy lehetetlen? Értő olvasás...?

Hol írtam, hogy lehetetlen? Azt írtam, hogy "a lehetetlennel határos küldetés". Értő olvasás...?

"írok egy-két select-et, a kimenetet meg odaadom egy pdf-generátornak, és kész"

Hát, baszki, de, sarkítva nagyjából ennyiből áll és működik is ilyen rendszer. Tényleg nem értem, hogy mi ezen annyira összetett, lehoztam egy éves tranzakciótörténetemet, 50 kB nyers adat, hatfelé replikálva 300 kB egy évem története, tegyük fel, hogy átlagos ügyfél vagyok az éves 846 darab tranzakciómmal, 10 év 3 MB és 8460 darab tranzakció, 300 ezer ügyfél esetén ez 1 TB adatmennyiség, és 2,5 milliárd rekord, számlaszámra és time-range indexelve. Még egyszer mondom, 10 év adata. Mi a retkes lófasz van ott nálatok hozzáértő informatika helyett, hogy ezt az adatmennyiséget nem tudjátok se letárolni, se kiszolgálni? Mondom ismét: van olyan bank, ahol ez működik.

Tegnap óta folyamatosan azzal jöttök, hogy

- több százmillió rekord, világvége
- magyar jogszabályok és banki előírások
- GDPR és MNB
- nem szabad (!) a számlavezető rendszerben tartani (megőrzési idők)
- komplex, meg külön rendszer kell
- drága, nem éri meg
- nem bank, úgy könnyű
- bla-bla-bla, bullshit, nem gyűjtöm ki a faszságaitokat, amire ráadásul válaszolni se vagyok hajlandóak

Mindezt úgy, hogy több magyarországi bank is tudja, világszerte pedig még több, jóval nagyobb forgalmú pénzügyi cég is képes erre a bravúrra. Valószínűleg nincs zellerük, aki megmondaná nekik, hogy miért nem lehet megcsinálni, ezért egyszerűen csak végiggondolták és megcsinálták.

https://iotguru.cloud

"Hát, baszki, de, sarkítva nagyjából ennyiből áll és működik is ilyen rendszer. " - Vagy nem. Láttál már olyat, ahol számlavezető rendszert cseréltek? Mondjuk kétszer. És archív környezetből is van mondjuk 2-3, az aktuálistól teljesen eltérő DB-t használva. Na ott azért elég tornázós lenne egy-két selecttel összehozni a teljes számlatörténetet, pláne úgy, hogy az archív rendszerek hálózatilag elkülönítve működnek az élestől. Nos, ekkor is "csak egy-két select?" Mondjuk Progress az egyik, Firebird a másik, és mondjuk Oracle a harmadik adatbázisod... :-) Szóval...?

Láttál már olyat, ahol számlavezető rendszert cseréltek? Mondjuk kétszer.

Láttam.

És archív környezetből is van mondjuk 2-3, az aktuálistól teljesen eltérő DB-t használva.

Ilyet is láttam. Sőt, olyat is, hogy az adattárház három különböző rendszer volt, évjárat alapján particionálva, mégis meg lehetett oldani a dátumvonalon túlnyúló report generálást.

Na ott azért elég tornázós lenne egy-két selecttel összehozni a teljes számlatörténetet, pláne úgy, hogy az archív rendszerek hálózatilag elkülönítve működnek az élestől. Nos, ekkor is "csak egy-két select?" Mondjuk Progress az egyik, Firebird a másik, és mondjuk Oracle a harmadik adatbázisod... :-) Szóval...?

A magyarországi bankok közül melyikben cseréltek az utóbbi 5 évben kétszer számlavezető rendszert? Aham, maximum egy bankban, de ott se történt két teljes csere. A többinek mi a mentsége arra, hogy nem tud 5 évre visszamenőleg online számlatörténetet adni? Befejeznéd végre ezt az ámokfutást, hogy miért nem lehet megcsinálni és egymás után hozni a balfasz példákat?

https://iotguru.cloud

Mások minősítése helyett válaszolnál arra a mellékes kérdésemre, hogy mi az a banki termék, ami egy bankban 15-20 perc alatt 200.000.000 rekordot termel?

Ja, azt szimplán elírtam mobilról. Kétszer is említettem, hogy napi 16-20 millió rekordról volt szó, szóval értelemszerűen nem 15-20 perc, hanem 15-20 nap alatt termelt 200 millió rekordot, mert hétvégén jóval kisebb a tranzakciószám becsukott fiókok miatt. De szerintem erre te is rájöhettél volna, hogy elírás.

Dobd már le a kártyádat az asztalra vagy a nagy arcodat a sutba!

Szerintem meg te vegyél egy kicsit vissza az arcodból, próbáltál nagyot mondani magas lóról, hogy mennyire hihetetlenül problémás lenne a több évre visszamenőleges tranzakciótörténet, aztán nagyon nem jött be, mert egyrészt több magyarországi bank is képes erre a dologra, még több külföldi,  ráadásul nem olyan nagy az adatmennyiség sem.

Nagyon sok dolgot el tudok fogadni azzal kapcsolatban, hogy miért nem lehet egy banknál több évre visszamenőleg tranzakciótörténetet online az ügyfelek felé kiszolgálni, de azt, hogy technikailag bonyolult vagy drága, illetve azt, hogy jogszabályok miatt nem lehet, azt kurvára nem. Aki IT ember pedig ezen okok mellett kardoskodik, azt bizony körberöhögöm és beteszem a "nagyarcú bankos balfasz" dobozkába.

https://iotguru.cloud

Ja, azt szimplán elírtam mobilról. Kétszer is említettem, hogy napi 16-20 millió rekordról volt szó, szóval értelemszerűen nem 15-20 perc, hanem 15-20 nap alatt termelt 200 millió rekordot, mert hétvégén jóval kisebb a tranzakciószám becsukott fiókok miatt. De szerintem erre te is rájöhettél volna, hogy elírás.

 

Na most menj a picsába! :D Aki akkora balfasz, hogy rá kell jönni mit is akart írni az hallgasson! :D Figyelj te királyfasz! Világosan leírták - jó, neked ez kihívás - hogy amire nincs egy bizonyos tömegű igény, azt nem fogják kiszolgálni, hogy ha te magadat kritikus tömegnek érzed, akkor is te vagy kénytelen elmenni oda, ahol megütöd az ingerküszöböt! Emellett kaptál némi rálátást valamire, amiről lila fingod nincsen, ez kiderült azért azoknak, akik belülről láttak már ilyesmit. No, semmilyen dobozkába nem férsz be! :D Akkora durung vagy, hogy cölöpöt lehet veled leverni! 

Na most menj a picsába! :D Aki akkora balfasz, hogy rá kell jönni mit is akart írni az hallgasson! :D

Nézd, én eddig úgy tudtam, hogy tévedhet az ember, sőt, be is ismerheti, hogy tévedett, ráadásul itt egy mobilról írt elgépelésről van szó.

Világosan leírták - jó, neked ez kihívás - hogy amire nincs egy bizonyos tömegű igény, azt nem fogják kiszolgálni, hogy ha te magadat kritikus tömegnek érzed, akkor is te vagy kénytelen elmenni oda, ahol megütöd az ingerküszöböt!

Bocsánat, de nem úgy kezdted, hogy ha nincs rá igény, akkor nem szolgálják ki, hanem elkezdted kiszámolni, hogy mekkora mennyiségű adatról van szó és próbáltál mindenki elborzasztani a százmilliós rekordszámmal, aztán pedig végig kiálltál amellett, hogy rettentő sok adatról lenne szó és kérdezgetted, hogy melyik bankok képesek ezt kiszolgálni. Amikor megírtuk, hogy melyik bankokról van szó, akkor azt szó nélkül hagytad többször is. Idézzelek vissza? Biztos erre van szükséged?

És persze kurvára nem válaszoltál a kényelmetlen kérdésekre, de ahhoz van arcod, hogy egy elgépelés miatt nekem támadj.

Emellett kaptál némi rálátást valamire, amiről lila fingod nincsen, ez kiderült azért azoknak, akik belülről láttak már ilyesmit.

Nyilván így van, a büfébe jártam be évekig, nem pedig banki architektúrát érintő döntéseket előkészíteni és meghozni.

https://iotguru.cloud

Átsiklottál. Mi lenne, ha végigkövetnéd, hogy melyik hozzászólásodban kérdezted és megnéznéd, hogy jött-e rá válasz? Több ilyen is van.

Egyébként miért kell magyarországi bankra szűkíteni? Külföldön más mennyiségű adatot könnyebb kiszolgálni? Vagy hogy jön ez ahhoz, hogy mennyire sok több száz millió rekord évente?

https://iotguru.cloud

Nem találom, melyik az a magyarországi, aki évekre visszamenőleg onli8ne lekérdezést ad.

Többet is írtunk már, többször, de mintha vakfoltod lenne rá.

A magyar jogszabályi környezet miatt. Ezért érdekel. [...] Azt mindegyik tudja, hogy kérésre a kezdetekig visszamenőleg kiad ilyet. 

Ne már, ismét a bullshit? Nincs konkrét ismereted a témában, de ezért beböfögsz valami hülyeséget, hátha ettől megáll az élet, vagy mi ennek az értelme?

Mondd már meg, melyik magyar jogszabály tiltja meg, hogy online és közel real time lekérdezhető legyen a számlatörténet évekre visszamenőleg? Nem érzed ilyenkor, hogy mekkora ökörségeket jelentesz ki?

https://iotguru.cloud

Én csak felhoztam azokat a nehézségeket, amik szembejöhetnek, te viszont nagy arccal tartod azt, hogy egy-két select oszt' jó'van. Egyébként meg a "mi a mentség" kapcsán mondjuk az, hogy az erre vonatkozó ügyféligény nem indokolja a fejlesztést? Erre nem gondoltál? Meg arra sem, hogy folzamatosan jogszabálycsavargatások miatt kell a fejlesztőknek tornázni, n+1 jelentés után n+23-at is megoldani... Legutóbb pl. a PAD volt ilyen feladat...
Tényleg, látott már valaki kész, kiküldött PAD kivonatot? Ha igen, melyik banktól?

Én csak felhoztam azokat a nehézségeket, amik szembejöhetnek, te viszont nagy arccal tartod azt, hogy egy-két select oszt' jó'van.

Hogyne, tudom, egy álló napon át folyamatosan hordtad be kintről a mindenféle válogatott faszságot, hogy miért nem lehet megcsinálni, aminek a fele szánalmas hülyeség volt (GDPR, MNB, jogszabályok, szabályok, számlavezető rendszer szabályai és a többi), egy része IT faszság volt, hogy mennyire sokba kerül meg mennyire nehéz üzemeltetni, a többi meg maximum kicsit növeli a komplexitást, de nincs olyan bank, ahol a 6-8 ilyen nehézséged közül kettőnél több egyszerre fennállna.

Minden más esetben is az abszolút worst case scenario az, amire a TCO-t tervezed? Vagy csak akkor, amikor így elgurul a gyógyszered?

Egyébként meg a "mi a mentség" kapcsán mondjuk az, hogy az erre vonatkozó ügyféligény nem indokolja a fejlesztést?

Ügyféligény biztos van rá, tele vannak sírva a bankos fórumok, hogy lehessen. A kérdés az, hogy az üzlet mit akar. Ha akarja, meg lehet oldani. Ha nem akarja, akkor meg mindegy, hogy meg lehet-e oldani, nem lesz megoldva.

Tényleg, látott már valaki kész, kiküldött PAD kivonatot? Ha igen, melyik banktól?

Inkább arra válaszolj, hogy "milyen megőrzési időkkel működhet egy banki számlavezető rendszer", ha már egyszer nekem szegezted ezt a kérdést...

https://iotguru.cloud

Én a helyedben elkezdeném megérteni, hogy problematikus is, de amire nincs akkora igény, hogy megérje a kiszolgálása, azt nem fogják kiszolgálni. 

Egyébként érdekelne, hogy mi az a banki termék, ami olyan népszerű, hogy 15-20 perc alatt keletkeztet 200 millió tranzakciót egy bankban. Ez tényleg érdekelne...

Te fejlesztő-only üzemmódban vagy, én meg nem.

Nem, én általában architect módban vagyok és egyformán balfasznak tartok mindenkit, aki csak a saját kis szemétdombján akar kiskakas lenni.

És a fejlesztők általában nemlátnak messzebb a kódjuknál.

Igen, pont olyan balfaszok, mint az üzemeltetők, akik csak üzemeltetési szempontokat tudnak figyelembe venni.

A másikmeg az, hogy nem egy n+sok fejlesztő által összelapátolt bughal... akarom mondani (nem)integrált banki rendszerhez kellett hozzádrótozni egy funklciót, hanem alapból így lett kialakítva a számlavezető rendszer.

Már megint kifogások és bullshit halmok, hogy miért nem lehet megoldani a feladatot.

Egyébként meg az egy ilyen "szolgáltatás" elég cinkes is lehet - gondold végig: ha a szolgáltatáshoz tárolni kell a régi számlatörténetet, akkor az az adatkezelést - minden ügyfél tekintetében - jogszerűvé teszi. És senki nem ellenőrzi, hogy ezen histroikus adatokat a majdnembank csak az adott szolgáltatáshoz, vagy épp adatbányászatra is használja.

Ismét leírom: ezek az adatok megvannak bármelyik bank esetén, mert meg kell lenniük. Írjam lassabban?

És bizony a bankok is használják adatbányászatra, erről szól szinte mindenhol az adattárház projekt, nyilván bányásznak benne, hogy az üzlet elé csinos kis grafikonokat és prezentációkat tudjanak tenni. Kérdezd már meg ott az adatbányászokat, legyél oly kedves, lehet, hogy sokat tanulnál a bank működéséről.

Szerintem nézd át a lineklt pdf-et, gondold végig, hogy az abban lévő elemekből mennyi szükséges, és mennyi "jó ha van" például a revolut működéséhez. Annak a revolut-nak a működéséhez, amely tetszőleges üf. beérkező utalását zárolhatja indoklás nélkül, és saját belátása alapján, vitatható adatkérések után "majd valamikor" oldja fel a zárolást.

Megnéztem. Nem estem hanyatt. Kinőttem már abból a korból.

Ja, olvass utána, milyen megőrzési időkkel működhet egy banki számlavezető rendszer - ez az egyik

Világosíts fel, véleményed szerint milyen megőrzési időkkel működhet egy banki számlavezető rendszer? Bár ilyen konkrét kérdésekre eddig se válaszoltál, szerintem erre se fogsz. Feldobsz ilyen hülye kifogásokat, aztán nem reagálsz.

a másik meg próbáld végiggondolni, hogy egy, az élessel azonos védelmet igénylő, egyre nagyobb adatmennyiséget kezelő archív rendszer menniybe kerülne, és mennyi hasznot hozna, majd hasonlítsd össze a két becsült értéket, és számold ki,hogy hányszorosa az egyik a másiknak, és hogy az így kijött időtávban megtérülő rendszert érdemes- e megcsinálni.

Ez az adatmennyiség jelenleg is minden bank esetén megvan, kezelni kell, satöbbi, mert nagyrészt törvényi kötelezettség, kisebb részt üzleti kötelezettség. Szerinted honnan vakarják elő az adatokat, ha bemegyek az OTP-be, hogy kellene a 2016-10-12 és 2016-12-15 közötti tranzakciótörténetem? Mondjuk a MagnetBank esetén pont balfaszok, de ott ez az időintervallum egy 301 ms ideig tartó lekérdezés...

https://iotguru.cloud

Mert nincs nekik zellerük, azért.

Vannak bankok, ahol dugig vannak ilyen emberekkel, akikhez beülsz, mint szakértő és azt hallgatod egy-két-három órán át, hogy mit nem próbáltak még ki, mert úgyse működne; illetve sorolják, hogy az ezt megelőző meetingek során milyen indokokkal vetették el a felmerülő ötleteket. Tele vannak negatív és sértett emberekkel, akik minden változásba befeszülnek, minden plusz munkának keresztbe fekszenek, ja, és nem beszélnek egymással. Sok esetben annyi volt a munkám oroszlánrésze, hogy egy asztalhoz kellett ülniük olyanoknak, akik évek óta nem beszéltek egymással, de mivel ott voltam, mint külsős, moderálniuk kellett magukat és mind a kettőjük munkájára szükség volt.

Ilyen helyeken nem megy már keresztül az, hogy egy üzleti változás miatt több munka lesz és fel kell még venni embereket. Az ilyen helyeken az a mentalitás, hogy az embereket ki kell rúgni, nem még több léhűtőt felvenni. A változás akkor mehet keresztül, ha nem jár több munkával vagy költséggel, mint a megelőző állapot. Kivéve a törvényi kötelezettségek és a kényszerű munkák (upgrade, licenc váltás, arculat váltás, satöbbi), amivel manapság nagyjából 80 százalékban foglalkoznak a bankok. A maradék 20 százalék meg apró cseprő kis változtatások.

https://iotguru.cloud

"mit nem próbáltak még ki, mert úgyse működne" - vagy inkább azt szedik össze, hogy mi az, ami problémát okozhatna, illetve a teszteken problémát okozott - ugyanis így is lehet. A lehetséges problémák _és_ arra megoldási javaslat felvetése nem keresztbefekvés, bár a fejlesztők, meg a fejlesztőből lett "szagértők" mindazt, ami nem egyezik a saját elképzelésükkel, keresztbefekvésnek tekintik - tisztelet a kivételnek.

"ott voltam, mint külsős" - De sok ilyen "Pilatus a credo-ban" megszakértést láttam már...

"üzleti változás miatt több munka lesz és fel kell még venni embereket" - kifejezetten nem architect kérdés, onnan maximum az input jön, hogy adott erőforrásokkal vélhetően nem oldható meg, de ez is inkább a terület vezetőjének a kompetenciája eldönteni.

"a törvényi kötelezettségek és a kényszerű munkák [...] amivel manapság nagyjából 80 százalékban foglalkoznak a bankok" - na ezt talán a törvényalkotóknak meg a jogszabályokat sűrűn átértelmező/átalakító jogalkotóknak és jogalkalmazóknak kellene az orruk alá dörgölni. És itt visszakanyarodhatunk az elejéhez: ha egy szervezetet a jogszabályoknak csak egy része köt, akkor az rugalmasabban tud működni, mint az, amelyet egy rakat másik is terhel.

És itt visszakanyarodhatunk az elejéhez: ha egy szervezetet a jogszabályoknak csak egy része köt, akkor az rugalmasabban tud működni, mint az, amelyet egy rakat másik is terhel.

Ugyanannyi szabály köti, ne kezdjed már megint, hogy egy másik magyarországi bank más szabályok szerint működhet vagy egy másik európai bank más szabályok szerint működhet. Azért tud rugalmasabban működni, mert kibaszták már idejekorán azokat, akik a tipikus negatív hozzáállású emberek, akik az energiájuk nagy részét arra pazarolják, hogy olyan kifogásokat hozzanak mindennel kapcsolatban, mint amit te is műveltél a hozzászólásaidban. 

Például, megválaszolnád, hogy "milyen megőrzési időkkel működhet egy banki számlavezető rendszer"?

https://iotguru.cloud

Melyik banknál tudom online lekérdezni - még mindig ez volt a kiindulási pont - a számlatörténetemet 2000.01.01 és 2020.02.11 között? Érdekelne. Érted, leülök, lekérdezem és kitolom Excelbe mert csak. Ezt melyik csinálja meg?

Ja, úgy mindegyik, hogy írsz nekik és "elővakarják" hogy frankó idézettel válaszoljak. De itt arról volt szó a startvonalon, hogy a delikvens klikkel, hogy aszondja ide a tranzakciós listámat izibe és az jön ész nélkül azonnal évekre visszamenőleg. Na. Ezt melyik tudja? Nem kivonat, nem batchmajdegyszerjöneredmény, hanem klikk, jé itt van! módon.

Sopronbanknál tudok keresni tranzakciók között, vagy le tudom listázni akármelyiket, amióta a számlám ott van (előtte értelemszerűen azért nem, mert nem volt számla), a netbankon keresztül, bármiféle emberi közreműködés nélkül. Természetesen ez mellett van a PDF / XML kivonat letöltés, természetesen az is örökké visszamenőleg. (amúgy a nagy összeröffenés előtt a saját, helyi takarék régi netbankja is tudta ezt, ott 2002-ben nyitott számlám adatai között tudtam keresni).

Számlakivonat != számlatörténet. A számlakivonat a havi ciklus lezárása után keletkezett "hiteles" dokumentum logóval meg mindenfélével, amit el lehet rakni a pincébe megőrzésre. A történet meg egy sima szöveges lista az elmúlt időszakról, de nem olyan formátumban, ami bármelyik harmadik fél számára hiteles lenne.

És pusztán ettől képesek lesznek kiszolgálni évekre visszamenőleg a tranzakciótörténetet, míg egy bank nem?

A fent felsorolt cegek osszesen nem leteznek annyi ideje, mint amilyen hosszu szamlamultam van egyik masik magyar penztemetonel, azert ez egy hatarozott konnyebbseg. :)

A fent felsorolt cegek osszesen nem leteznek annyi ideje, mint amilyen hosszu szamlamultam van egyik masik magyar penztemetonel, azert ez egy hatarozott konnyebbseg. :)

Cserébe egy-két nagyságrenddel több ügyfelük és forgalmuk van, ami azért határozott nehézség, nem?

https://iotguru.cloud

Amit a "csak egy-két select" hozzáállású fejlesztőknek is lehet köszönni :-) Bár van olyan, ahol komplett számlavezető rendszer cserélődött (akár többször), természetesen az alatta lévő adatbáziskezelővel együtt úgy, hogy historikus adatok migrálása nem történt meg. (Látott már ilyet a világ...)

Hol írtam, hogy nem _lehet_? Azt írtam, hogy rengeteg olyan dolog van, ami miatt nem egyszerű - amiket írtam az korábban szembe jött, most jellemzően ilyenek nem jönnek szembe - van más, amit ki kell reszelni, át kell alakítani (vagy egyszerűen csak el kell magyarázni, hogy a fejlesztő leegyszerűsített elképzelése miért ptoblémás...), hogy a nagybanki működésre szabott előírásokat maradéktalanul lehessen teljesíteni, de csináljuk :-D

Kurvára nem érdekel, hogy mekkora kupac szart álmodtál éjjel, amikor saját bevallásod szerint is az a helyzet, hogy a töredéke nem létezik a valóságban.

Ja, nincsenek nagybanki működésre külön szabályok, egyáltalán, mi az, hogy nagybank? Megint faszságokat beszélsz.

https://iotguru.cloud

A hitelintézeti törvény ismer olyat, hogy "közérdeklődésre számot tartó hitelintézet", de az igazából minden hitelintézet kivéve az állami tulajdonban lévő bankok (MNB, MFB Magyar Fejlesztési Bank, Magyar Export-Import Bank ). 

Meg ismer olyat, hogy "rendszerszinten jelentős hitelintézet", amelyek listáját az MNB hirdeti ki. 

Egyik esetben sem érinti a szabályok a számlavezetéssel kapcsolatos szolgáltatásokat és itt most csak arról van szó.

De, vannak külön szabályok a rendszerszinten jelentős hitelintézetekre, tőkemegfelelés és hasonló témában, de az nem érinti a betétszámla-kezeléseket, a fizetési-számla kezeléseket. De attól még tényleg létezik olyan, hogy "nagybank", pongyolán fogalmazva.

Vagy elmegy más szolgáltatóhoz, akik ki tudják szolgálni ezt az "irreális" igényt.

Mindekozben volt munkahelyeden a csodas uj netbankbol nemhogy az 5 evvel ezelotti kivonatot nem lehet letolteni, hanem a 2019 decemberit sem, sot egyiket sem. Nem tudja. Nincs ilyen feature, hogy szamlakivonat. A telefonos kisasszony megigerte, hogy 2-3 munkanapon belul elkuldik emailben. Errol tudsz valamit? :D

Mindekozben volt munkahelyeden a csodas uj netbankbol nemhogy az 5 evvel ezelotti kivonatot nem lehet letolteni, hanem a 2019 decemberit sem, sot egyiket sem.

Ja, én projekt-szakérteni szoktam ilyen helyeken, ráadásul legutoljára a Simple-nél, ami teljesen külön entitás, az ilyeneket nem tekintem munkahelynek, olyan nekem 6 éve nincs.

Röviden? Balfaszok, azért.

Hosszan? Van hatszázféle rendszerük, amit beolvasztottak a mamut zsíros seggébe; egy elbaszott adatmodelljük, ahol a számlavezető fiók a legfontosabb paraméter; de legfőképpen azért, mert a fejlesztés, az üzlet és az üzemeltetés három - egymástól igen távol lévő - épületben van és a minimálisnál kevesebbet beszélnek egymással. Többek között itt voltam mondhatni párterapeuta három éve és próbáltam kihozni, hogy a fejlesztésnek és az üzemeltetésnek össze kellene azért kicsit dolgoznia az ügy érdekében és nem keresztbe tenni direkt egymásnak.

https://iotguru.cloud

Na varjal, ha jol ertem a CV-det, majdnem 5 evig voltal Senior Java Developer illetve Senior IT Architect a szoban forgo banknal. Mi volt az oka, hogy ilyen szar lett a rendszer? (Ez most nem kotekedes. :))

Ez volt az a bank, aholarrol beszeltel, hogy keresztbefekudtek az emberek? Miert nem lettek kibaszva? Akkoriban meg boven futottak az AS/400-as cuccok, pl. a K****i. De ha tippelnem kene bizonyos netbankban megjeleno adatokbol, meg ma is, tehat onmagaban messze nem eleg megoldaskent, hogy kell egy architekt.

Az ilyeneknek mar mindegy utolag, ezert baromi sok penz implementalni azt, amit a Revolut fillerekbol megold.

Ja, hogy te a CIB-re gondolsz?

Ott leginkább azért, mert az olaszok hozták az olasz (vagy néha horvát) cuccokat, mert ugye bankcsoport-szinergia. Ennek voltak vicces mellékhatásai, volt olyan eset, hogy nem sikerült megtudni az olaszoktól, hogy mi az IBM Queue Manager neve, ami kellett volna a kapcsolódáshoz, aztán addig eszkalálódott a probléma főnökről-főnökre, amíg valami nagyfőnök visszaírt mindenkinek, hogy jöjjön be hozzá másnap a menedzser és ő kirúgja, mert valamelyik szinttől a Queue Manager neve már nem egy technikai név volt, hanem egy ember neve. Szóval remek kapcsolat volt az olaszokkal.

Volt, amit sikerült ennek ellenére partizánkodni és volt, amit nem. Egyáltalán nem technikai, jogi és/vagy szabályozási okai voltak és vannak annak, hogy nem csináltak és csinálnak meg dolgokat a bankok.

https://iotguru.cloud

Az amúgy elég vicces, hogy a 2001 óta működő Java alapú CIB Internet Bank funkcióit nem bírják/akarják átpakolni az "új" felületre. És nem extra funkciókról van szó, hanem szerintem alap kategóriásakról: számlakivonatok letöltése, rendszeres átutalások/átvezetések kezelése, devizaműveletek. Az azonban igaz (és a bankok jelenlegi gyakorlatát taglaló mellékszálhoz kapcsolódik is), hogy számlakivonatból az utolsó 6 havi elérhető, azaz időben ki kell menteni.

(amúgy lejjebb a Kapiti miért lett kicsillagozva?)

De banyek, nehogy már ezt annyira komoly feladatnak tekintsük. A jogi / szabályozói része bullshit (a bank amúgy is tárolja ezeket az adatokat, és meg is mutatja az üffélnek ha ezt kéri), a hozzáférés is bs, technikailag pedig picsafüst.

Az ügyfél a következőket akarja tudni a tranzakcióiról: dátum (amikor csinálta, opcionálisan amikor a bank lekönyvelte), tranzakció típus (utalás ki/be, pos, atm) összeg, másik számla és közlemény (ha van), egyenleg előtte, egyenleg utána, tranzakció díja, és kb. ennyi. Ez nagyon max 1 kB adat per tranzakció. Ezek az adatok nyugodtan mehetnek ki "archívba", miután az éles rendszerben már nincs rájuk szükség (30/60/90 nap), aztán innen meg lehet mutatni a kedves ügyfélnek, ha igénye van rá. Maga a cucc 99,9%-ban readonly, minden nap hajnal 4-kor kell rá tenni egy lock-ot és beletolni 1 perc alatt az előre előkészített, aznap archiválandó cuccot.

Most ez tényleg akkora kihívás?

Mert azt megértem, ha azt mondja valaki, hogy nincs erre tömeges ügyféligény (ami van azt olcsóbb FO/BO munkatársak basztatásával megoldani), vagy hogy az erőforrásokat más, nagyobb hasznot hozó dolgokra lövik inkább el. De hogy ezt technikailag problémát okozzon, hát bocsánat, de hadd röhögjek már ki mindenkit, aki ilyesmit állít.

Csak 10 évet húztam le bankokban és biztosítókban senior fejlesztőként és hármat architect pozícióban, mesélj még, hogy mire nem gondolok álmomban.

Amit például írtam a kivonatokról, az konkrét projekt volt egy bankban, a kivonatnak csak a nyers adatai mentek CM-be, mentéssel, archiválással, toronyórával és lánccal, ha meg kellett az ügyfélnek, akkor egy template engine elállította a PDF-et. Semmi komplexitás nincs benne, nem űrtechnika, nem kell visszahozni szinkronban a rakéták első fokozatát és párban letalpalni velük egy platformra...

https://iotguru.cloud

Neked is azt tudom írni, hogy ez egy töredék szám. Végig kell olvasni, amit írtam és rájössz, hogy ez egy TÖREDÉK. A szalagról hogy kérdezi le az ügyfél a cuccait? Ha szalagon van a tranzakciók adatbázisa, hogy dolgozol visszavalutázott dolgokkal? Ejnye no, megint azt hisszük mindenki hülye mi meg bezzeg helikoffer!

Neked is azt tudom írni, hogy ez egy töredék szám. Végig kell olvasni, amit írtam és rájössz, hogy ez egy TÖREDÉK.

Tudom, egyik projektem napi 16-20 millió tranzakciót kezelt bankban, online egy évvel és szalagos archiválással 5 évre. Öreg vagyok én már ahhoz, hogy milliós tranzakciószámtól hasra kellene essem...

A szalagról hogy kérdezi le az ügyfél a cuccait?

Simán, aszinkron tranzakcióval. Kimegy az adatbázisba a kérés, az adatbázis rájön, hogy ez nincs meg online, visszamegy a válasz, hogy nyugi, majd lesz, illetve szól a szalagos egységnek, hogy ugyan már húzza be valamikor ezt az adatbázis részletet, nem sürgős, de legyen meg valamikor. Az ügyfél meg majd kap egy értesítést, hogy itt a kivonata és örül neki.

De amúgy 5 év egymillió ügyféllel és csak 60 millió 1-5 kB tömörített XML, az meg 5 kB és hármas replikáció esetén is csak 1 TB adat, mint worst case, az meg lófasz manapság, már ne is haragudjál.

Ha szalagon van a tranzakciók adatbázisa, hogy dolgozol visszavalutázott dolgokkal?

Miért, a papíron kiküldött havi számlakivonaton hogy történik ez meg?

Ejnye no, megint azt hisszük mindenki hülye mi meg bezzeg helikoffer!

Az bizony. Unom kicsit, hogy jönnek azzal, hogy "ez bank, itt komplexek a dolgok". Lófaszt komplex, sokszor csak túl van fújva, kevesebbszer meg túl van bonyolítva, aztán pillognak, ha egy másik bank tized költségből megoldja ugyanazt.

https://iotguru.cloud

Lófaszt komplex, sokszor csak túl van fújva, kevesebbszer meg túl van bonyolítva, aztán pillognak, ha egy másik bank tized költségből megoldja ugyanazt.

Nullarol sokszor olcsobb/gyorsabb egy rendszert felhuzni, mint a 40 eve foltozott szarra radrotozni meg egy reteg szart. Ettol meg igazad van, a 20 millio tranzakcio nem kunszt, kiveve ha ezt a meglevo AS/400-as megoldasra kell felepiteni, ami mar igy is ott tart, hogy 24 oranyi tranzakcio feldolgozasa idoben 24 ora 30 perc. (Igaz tortenet alapjan.)

Persze ki lehet dobni a kukaba, ez egy egesz jo megoldas, de akkor meg is erkeztunk az eredeti kerdeshez, hogy "miert kerul ennyibe a sleep kikommentelese". Ezert.

Nullarol sokszor olcsobb/gyorsabb egy rendszert felhuzni, mint a 40 eve foltozott szarra radrotozni meg egy reteg szart.

A havi kivonatok eltárolása tipikusan olyan dolog, ami könnyedén hozzádrótozható a 40 éve foltozott szarhoz, független rendszerként, ahova egyszer ki kell tolni indulás előtt az összes korábbi havi számlakivonatot, nyers adatként, aztán minden hónapzárás után az aktuálisat, visszafelé meg át kell kergetni az adatokat egy template engine szolgáltatáson és tényleg mindenki boldog, olcsón meg van oldva a probléma, ami nem terheli az adatbázisokat. Csak vannak helyek, ahol nem megoldani akarják a problémákat, ott minden megbeszélés 80 százalékban arról szól, hogy miért nem lehet megoldani, a maradék 20 százalék meg poénkodás és a következő megbeszélés időpontjának egyeztetése...

https://iotguru.cloud

"könnyedén hozzádrótozható a 40 éve foltozott szarhoz" - amiben vagy benne van minden, vagy nincs, ergo az archiv rendszerekhez is hozzá kell kötni, legalább ideiglenesen. Arról nem is beszélve, hogy az a "40 éve foltozott sz@r" már így is 1024-számra tartalmaz ilyen "csakhozzá kell drótozni" megoldásokat,amik mindegyike "csak kevés erőforrást és fejlesztést igényel" - együttesen meg elviszik a kapacitásokdöntő hányadát...

Tehát a kisujjukból kirázzák a plusz 1025. hozzádrótozást. Semmi bajuk nem lesz tőle, hiszen vagy az előző 1024-et sem gondolták újra, vagy megtették, és megérte megtartani. Most már csak az a kérdés, hogy a XXI. században szánalmas-e, hogy az ügyfél nem fér hozzá online az adataihoz.

:)

Te meg az a fejlesztő vagy, aki a saját dolgán túl nem nagyontud vagy akar látni. Nekem az is a dolgom, hogy az ilyen "ezt még drótozzuk hozzá, mert nem sok" dolgoknak a hatását minél jobban átlássam, az ezekből adódó kockázatokat segítsek meglátni - és azokra megoldást adni. A megoldás lehet a hozzádrótozás átalakításától, az elvetéséig, vagy épp a kockázatok vállalásáig sokminden.  fejlesztői oldal a "ha már működik, akkor jó" mentalitást képviseli (ha elhasal, majd pecseljük), üzemeltetőként viszont a "lehetőleg ne rohadjon le" a fontosabb.

Te meg az a fejlesztő vagy, aki a saját dolgán túl nem nagyontud vagy akar látni.

Nem, voltam architect is.

Nekem az is a dolgom, hogy az ilyen "ezt még drótozzuk hozzá, mert nem sok" dolgoknak a hatását minél jobban átlássam, az ezekből adódó kockázatokat segítsek meglátni - és azokra megoldást adni. A megoldás lehet a hozzádrótozás átalakításától, az elvetéséig, vagy épp a kockázatok vállalásáig sokminden.  fejlesztői oldal a "ha már működik, akkor jó" mentalitást képviseli (ha elhasal, majd pecseljük), üzemeltetőként viszont a "lehetőleg ne rohadjon le" a fontosabb.

Ez tömény bullshit.

https://iotguru.cloud

Szerinted bullshit, szerintem meg általános megfogalmazása annak, hogy én hogyan állok hozzá a feladatokhoz, amikor üzemeltetői oldalról architect sapkát húzva kerül elém egy feladat. Nekem, mint üzemeltetőnek az a fontos, hogy hosszú távon lehetőség szerint stabil és átlátható maradjon a rendszer, és az entrópia elszabadulását minél jobban késleltessem, illetve csökkentsem. A fejlesztőnek mez az a célja, hogy az általa kitalált/összerakott motyó mielőbb production-be menjen, mert utána már első körben nekem (üzemeltető), illetve a sw-es támogatóknak lesz vele dolga :-P

Attól ez még bullshit. Az üzemeltetők alap hozzáállása valóban az, amit most is hozol: a változás rossz. Az ügyfél és különösen az üzlet viszont szereti a változásokat, főleg, ha abból bevétel keletkezik és pláne akkor, ha ebből a bevételből nyereség is marad hosszú távon. Akkor is jó üzletileg a változás, ha nagyon szar lesz üzemeltetni, de nyereség jön belőle még akkor is ha ezért fel kell még venni száz üzemeltetőt, akik vért hugyoznak, hogy életben tartsák a tákolmányt.

Tudod, az "üzemeltetőként felhúzom az architect sapkát" az nagyjából annyiból áll, hogy keresztülfekszel minden változásnak, amitől vélhetően több dolgod lesz, de nem nézed meg és nem is érdekel, hogy mennyi plusz bevétel jár azzal, hogy több dolgod van. Ennek a "fejlesztőként felhúzom az architect sapkát" megfelelője a kódminőség, a tesztlefedettség meg a clean code fétis, amikor addig nem megy élesbe a cucc, amíg végletekig nincs polírozva és nem zöld minden önkényesen megválasztott határértékű metrika.

És igazából az a szerencse, hogy a többi nagy bank is dugig van ilyen balfaszokkal, ezért mindegyik banki IT kurva rossz hatásfokkal dolgozik kurva drágán, kurva drága eszközökkel, a feltörekvő fintech cégek viszont rühellik az ilyen hozzáállást és előbb-utóbb letarolják a piacot. Aztán mehetsz kukoricát kapálni ezzel a fajta hozzáállással.

https://iotguru.cloud

" Tudod, az "üzemeltetőként felhúzom az architect sapkát" az nagyjából annyiból áll, hogy keresztülfekszel minden változásnak " - nagyon nem, bár sok fejlesztő, akinek halovány lövése nincs arról, hogy az ő csodálatos tákolmánya mennyi extra probléma forrása lehet - egészen addig, amíg valaki ezt a számára és az üzlet számára is érthető módon el nem magyarázza. És ami fontos, hogy a miért nem/miért hibás az elképzelés mellé minden esetben odarakom, hogy milyen módon lehetne a várható hátrányokat, problémákat kezelni/elkerülni/megoldani.

A feltörekvő babzsákfoteles fin(g)tech cégek törekszenek, de apró probléma, hogy a banki működéshez szükséges elemekből elenyészően keveset valósítanak meg, és a háttérben egy bank/pénzintézet nélkül mehetnének kapálni.

" mindegyik banki IT kurva rossz hatásfokkal dolgozik kurva drágán " - gondolom, van rá módszered, megoldásod, hogy hatékonyabban, olcsóbban, de az összes vonatkozó előírásnak megfelelően működjön egy banki IT. Ha van, akkor szerintem bármelyik általad ilyenmértékben lesajnált bank tárt karokkal fogad, hiszen a költségek csökkentése mindegyiknél kifejezetten fontos tényező. Megsúgom, mi lenne a legfontosabb a hatékony működéshez: Az új megoldások, szoftverek felhasználásának felmerültekor bevonni az üzemeltetést, illetve ahol van, a belső fejlesztőket is.
Láttál már oylan rendszerbevezetést, amikor az üzemeltetés kvázi akkor tudta meg,hogy mit kap a nyakába, amikor már eldöntötték, megvették, lefejlesztették az n+1 alkalmazást az adott cégnél addig nem használt komponensekkel, például DB-szerver, vagy épp alkalmazásszerver?
Na az ilyenek is erősen szuboptimálissá tudják tenni az üzemeltetés működését. Igen, ilyen esetben, amikor a meglévő tudásbázistól jelentősen eltérő komponenseket akarnak valahova bevinni, ott muß valamilyen mértékben keresztbefeküdni, és más megoldást szorgalmazni - vagy kompormisszumos megoldásként, ha van kellő számú ember, akkor képzést intézni a munkatársaknak - a projekt költsgkeretére. Ha ez nem megy, akkor szépen ott kell legyen írásban, hogy üzemeltetési oldalról milyen kockázatai vannak a bevezetésnek.
 

A feltörekvő babzsákfoteles fin(g)tech cégek törekszenek, de apró probléma, hogy a banki működéshez szükséges elemekből elenyészően keveset valósítanak meg, és a háttérben egy bank/pénzintézet nélkül mehetnének kapálni.

Mondod ezt egy mekkora ügyfélszámú bank dolgozójaként? Ember, nézz már körül kicsit a piacon, be vagy zárva egy magyar bank kis buborékjába és azt hiszed, hogy elértél mindent, amit lehet...

gondolom, van rá módszered, megoldásod, hogy hatékonyabban, olcsóbban, de az összes vonatkozó előírásnak megfelelően működjön egy banki IT

Hogyne, elég sok ötletem volt. Volt, amelyiket keresztül tudtam nyomni, aztán mindenki csodálkozott, hogy ez tényleg egyszerű és olcsó; meg van több, amit nem, mert eléggé komoly vesztegetési pénzeket sértett volna a dolog. Aztán belefáradtam, hogy a korrupcióval szemben próbáljam tolni a hatékonyabb IT-t, nem érte meg a befektetett munkát, ha jött egy olasz, megveregette a vállunkat, hogy jót szoptatok két hónapon át, látom, hogy olcsó, de a haverom cége fogja szállítani a szoftvert.

Megsúgom, mi lenne a legfontosabb a hatékony működéshez: Az új megoldások, szoftverek felhasználásának felmerültekor bevonni az üzemeltetést, illetve ahol van, a belső fejlesztőket is.

Persze... :D

Láttál már oylan rendszerbevezetést, amikor az üzemeltetés kvázi akkor tudta meg,hogy mit kap a nyakába, amikor már eldöntötték, megvették, lefejlesztették az n+1 alkalmazást az adott cégnél addig nem használt komponensekkel, például DB-szerver, vagy épp alkalmazásszerver?

Hogyne, többet is.

Na az ilyenek is erősen szuboptimálissá tudják tenni az üzemeltetés működését.

Az üzletet kurvára nem érdeklik azok a dolgok, hogy szuboptimális meg nem hatékony, meg a többi sírás. Két dolog érdekli őket: vagy legyen megtömve a magánzsebük vagy hozzon annyi pénzt a dolog, hogy magasabb üzemeltetési költségekkel is megérje bevezetni. A többi bullshit, ráadásul szerintem még naiv is vagy mindezek mellé...

https://iotguru.cloud

kiveve ha ezt a meglevo AS/400-as megoldasra kell felepiteni, ami mar igy is ott tart, hogy 24 oranyi tranzakcio feldolgozasa idoben 24 ora 30 perc. (Igaz tortenet alapjan.)

Akkor ki kell baszni végre azt a huszonéves rendszert, és olyat csinálni, ami megfelel a XXI. század informatikai standardjainak (segítek: elosztott, párhuzamos, skálázódni képes). És amilyen áron ezek az AS/400-as cuccok üzemelődnek, még csak nem is lesz drágább...

hogy "miert kerul ennyibe a sleep kikommentelese"

Nem a sleep kikommentelése kerül ennyibe, hanem az x évnyi hibás műszaki döntések meg az y évnyi technical debt. Ahol ezt meglépték régesrég, vagy ahol nem hozták meg ezeket a hibás döntéseket éveken át, ott nem kell a sleepet kikommentelni, és mindjárt nem is kerül ennyibe a dolog.

Akkor ki kell baszni végre azt a huszonéves rendszert, és olyat csinálni, ami megfelel a XXI. század informatikai standardjainak

Nem a sleep kikommentelése kerül ennyibe, hanem az x évnyi hibás műszaki döntések meg az y évnyi technical debt.

Nyitott kapukat dongetsz szerntem. :) Onnan indult a thread, hogy eleg-e kikommentelni a sleep utasitasokat. Nem eleg. Ki kell bsazni hozza a huszoneves rendszert, ami nem ket filler. Megcsinalhato siman, de nem ingyen, es nem tegnapra.

Jártam már olyan helyen, ahol az ottani (nem AS/400 hanem HP-UX, de majdnem mindegy) szervereken futó alkalmazást már tényleg nem ismerte élő ember olyan szinten, hogy el tudja mondani, hogy mit csinál. Boldog időskorban, 80-90 évesen haltak meg a hozzáértők (legalábbis azt szeretném hinni). Forráskód se volt.

Ennél picit jobb szokott lenni a helyzet, abban igazad van.

Már csak azért is, mert az as/400 tartotta a tempót, így ma is korszerű platform szerintem. Igaz, szűk szakmai közösség műveli, de nem lehetetlen felhajtani szakit hozzá. Az viszont valós veszély, hogy eltűnik forrás a huszon éves program alól...de ez azért van, mert huszon éve mindenki megelégedésére megírt kódok is vannak, amelyeket még nem írt felül az élet, viszont a sok ide-oda állás, egyéb divatmatatás közben eltűnt a forrás. Nekem volt 18 éves programom, amit tényleg senki nem értett már - szerintem én sem - és a végén, bár baj nem volt vele, működött jól, de kockázatnak értékeltek pont azért, mert mindenki kerülgette, senki nem mert körülötte semmit csinálni, mert nem értették. Ja igen, a forrását egyszer valaki kitörölte és a backupok során kihullott a rotációból is, nagyon régi streamer kazettákon ott lehet még, csak azokhoz meg drive nincs már :) Újra tervezték a rendszer érintett kis szegmensét és megírták újra. Azóta nyugi van. Azért jót vigyorogtam, amikor ex kolléga hívott, hogy mondjam már el konkrétan mi történik benne, mert nincs meg a forrása. Nem is értettem miért gondolják, hogy pont erre az egyre emlékszem közel húsz év távlatából részletesen.

Haver mesélte nyár végén, hogy Cobol fejlesztőket kellett volna projektre rohadt gyorsan találnia de nem talált.

A harmadik sör után azon röhögtünk, hogy először a nyugdíjasotthonok környékén kell próbálkozni, de ha az nem hoz eredményt, akkor kell bérelni egy nekromantát és a helyi temetőben mehet tovább a recruiting.

Végül szereztek 2-3 tényleg öreg arcot, azok meg egész nap ültek a konyhában, kávéztak és 30+ éves sztorikon röhögtek, kb úgy, hogy "És emlékeztek, amikor '83-ban a Laca azt mondta a Bélának ..." :D

Hát...én is egy ilyen öreg arc vagyok. :D És igen, én is kimegyek a konyhába naponta többször. Skandallum. :) És még a cobol-hoz is értek. A vicc az ezekben a nyelvekről szóló vitákban, hogy semmi értelmük nincsen. Ma ezen a platformon rpg-ben nyomják a korszerű arcok a melót...de aki a platformot ismeri, az tudja, hogy hogyan működik és azt is tudja, hogy akár C-ben is nyomhatná, a végeredmény ugyanaz lesz. Akármelyik nyelven ugyanazt meg tudom valósítani így vagy úgy. Ez igaz az AS/400 vagy iSeries platformra.

Mondjuk pl. Linuxon én abszolút C párti vagyok, de ennek az oka az, hogy abban otthon vagyok, azonnal hadra fogható. És hát nem látom be, hogy ha egy környezetben nekem hosszan le kell ülnöm, miért hasznosabb a C++ vagy tásai, mint a C. Vagy akár a cobol. De ez lehet, hogy a koromból adódik. :)

Nem azon volt a hangsúly, hogy kávézni mernek, hanem hogy annyira kicsi (maradt) a szakma ezen ága, hogy mára közismert mítoszok és legendák alakultak ki, amiket elég kb. a sorszámukon említeni, mint a törpés viccben és máris röhög mindenki :)

 

Mondjuk pl. Linuxon én abszolút C párti vagyok,

 

Ez messzire visz. :)

 

es nem tegnapra

Nem is kell "tegnapra"!

A "kedvenc" bankomnál 18 évvel ezelőtt (2002-t írtunk) is már ment gyakorlatilag éjjel-nappal a tranzakció feldolgozás és a netbank. Szombat hajnal cca. négykor úgy döntött a cégünk, hogy az ugyanazon banknál vezetett magánszámlámra át kéne utalni egy kis lóvét. Netbank fellő, átutalás, következő percben pittyeg az SMS, megjött a zsé, ha kedvem lett volna lemenni egy ATM-hez, ki is vehettem volna az egészet.

Semmi nem akadályozta meg a konkurenciát, hogy észlelje, mit tud a másik bank, és lemásolja. 18 komplett éve lett volna rá! Nem "tegnapra"...

De erted, a vita nem onnan indult, hogy ki mekkora tech debt-et tudott osszehordani rossz dontesek miatt, hanem hogy "ki kell kommentelni a sleepet". :D Senki nem mondta, hogy a mostani helyzet jo, csak mar 20-40 eve gorgetik mar meguk elott a ganajt a bankok, es most utolag rohadtul nem trivialis eltakaritani.

"ugyanazon banknál vezetett magánszámlámra át kéne utalni egy kis lóvét" - bankon belüli átvezetés nem fordul meg a GIRO-nál, ezért elvileg (szinte) bármikor megtörténhet. Számlanyitás (meghatalmazottként lettem felvéve hozzá), még a papírok zörögnek kifelé a nyomtatóból, de a mobilbankon már látom, átvezetés, készen van, és a számlatulajdonosnak már jött is az sms, hogy jóváírás érkezett a számlájára.

Te tudod. Olvassad el az eredetit. Csak a sima alaulbecsült forint utalásos "hup bank" esetében volt évi 300 millió rekord. És után írtam még, hogy ehhez mi jön hozzá...becsüld meg, mekkora a végeredmény. Az igény nem aszinkron tranzakció volt. És nem kivonatot akart kapni. Én tényleg elolvasnám a helyedben azt, amire válaszolok, pláne ha ilyen tahó stílusban le akarod teremtenia másik felet.

De amúgy 5 év egymillió ügyféllel és csak 60 millió 1-5 kB tömörített XML, az meg 5 kB és hármas replikáció esetén is csak 1 TB adat, mint worst case, az meg lófasz manapság, már ne is haragudjál.

Hidd el, nem haragszom, de ez a mondat nem passzol a szövegkörnyezetbe tartalmilag sem. Hogy pék farkába jött ide xml?! Meg mi ez a 60 millió 1-5 kb izé?! 

Miért, a papíron kiküldött havi számlakivonaton hogy történik ez meg?

Tényleg analfabéta vagy? Az adatokon feldolgozás fut, a kivonatot meg elolvassuk. A visszavalutázott tétel az aktuális kivonaton jelenik meg múltba mutató valautanappal. De a futások során a tétel valójában a valutanap által mutatott naphoz tartozik. Ha nem érted a nem kis difit, kérlek ne válaszolj!

Az bizony. Unom kicsit, hogy jönnek azzal, hogy "ez bank, itt komplexek a dolgok". Lófaszt komplex, sokszor csak túl van fújva, kevesebbszer meg túl van bonyolítva, aztán pillognak, ha egy másik bank tized költségből megoldja ugyanazt.

Ezután a mondat után vannak kétségeim, hogy te valah bármi fajsúlyosat csináltál-e bankban. Egyetlen piaci szereplőt sem szabályoz annyi jogszabály, mint a bankokat és ez így van jól. De ettől azért tényleg kicsit bonyolult lesz. ÉS persze túl is fújnak dolgokat, ahogy mindenhol máshol is. Szépen nyugodjál meg, mert ha az az ér elpattan a homlokodon, akár el is vérezhetsz hupozás közben!

Te tudod. Olvassad el az eredetit. Csak a sima alaulbecsült forint utalásos "hup bank" esetében volt évi 300 millió rekord.

Miért kellene ettől nekem hanyatt esnem? Mondom, volt banki projektem, napi 16-20 millió tranzakcióval, egy év online, 5 év szalagon, az 6-7 milliárd rekord volt online, és 25-30 milliárd szalagon. Tényleg nem értelek, hogy mi ezen a nagy dolog...

Egy éve hobbiból gyűjtögetem a MÁV valós idejű adatforrásából az adatokat, ott már 100 millió rekord van... ásít, ennyi rekord manapság lófasz sem.

És után írtam még, hogy ehhez mi jön hozzá...becsüld meg, mekkora a végeredmény. Az igény nem aszinkron tranzakció volt. És nem kivonatot akart kapni. Én tényleg elolvasnám a helyedben azt, amire válaszolok, pláne ha ilyen tahó stílusban le akarod teremtenia másik felet.

Ja, és? Csak mondottam volt egy megoldást, amiben részt vettem. De egyáltalán nem komplexebb az, hogy konkrét tranzakciótörténet is lekérdezhető legyen.

Tényleg analfabéta vagy? Az adatokon feldolgozás fut, a kivonatot meg elolvassuk. A visszavalutázott tétel az aktuális kivonaton jelenik meg múltba mutató valautanappal. De a futások során a tétel valójában a valutanap által mutatott naphoz tartozik. Ha nem érted a nem kis difit, kérlek ne válaszolj!

Oszt? Nem látom a lehetetlenséget a dologban.

Ezután a mondat után vannak kétségeim, hogy te valah bármi fajsúlyosat csináltál-e bankban.

Kételkedj. Attól nekem nem lesz rosszabb. Én viszont azt látom, hogy próbálod valami nagy dolognak beállítani, hogy egy kis hangyafasznyi magyar banknál szopsz évek óta, meg százmilliós tranzakciószámot felhozni, hátha attól majd hanyatt esnek...

https://iotguru.cloud

Tehát kell egy archív rendszer, amibe Ádám-Éva és az öreg diófa óta minden ott van - ja, nem, mert van "néhány" jogszabály, ami ezt korlátozza, ergo kell belőle gyakorlatilag folyamatosan takarítani egyrészt a "meddig tárolhatod" miatt, másrészt meg a GDPR okán is ugyebár...
Kell az éles rendszerből az idővonal "másik végén" etetni - sajnos az nem megy, hogy "x napnál régebbik oda, annál frissebbek ide", úgyhogy ez is bonyolítja a visszakereséshez az adatok áttöltését, mint ahogy az is, hogy az éles számlavezetőben változhat sokminden, ergo az archiv rendszerbe történő adatátadást is folyamatosan utána kell húzni (n+1. éleshez hozzádrótozott dolog ugye...)...
Aztán kell üzemeltetni adott SLA-val, éles üf.adatok miatt a hozzáférés szabályozása és naplózása az élessel megegyező szinten kell, hogy legyen, satöbbi.
Meg _lehet_ csinálni. Szoftverfejlesztői oldalról valóban nem nagy kunszt - viszont a teljes IT-rendszerbe beilleszteni, fenntartani már pirinyót bonyolultabb - és nem olcsó. Igen, tudom, az üzlet részéről, pláne, ha élesbe ment a szolgáltatsá senki nem fogja kimondani,hogy baszics, ez a szolgáltatás qrvára nem éri meg... Vagy ha igen, akkor is n+1 év és egy rakat elköltött zseton után - és nem úgy, hogy eredetileg is baromság volt, hanem "változtak az ügyféligények"...

meg a GDPR okán is ugyebár

Persze, ultimate érv, ha valami nem akarunk megcsinálni, akkor GDPR... csak tudod, hibás érv itt, mert jogos üzleti érdeknél és jogszabály által előírt adatmegőrzés esetén pont nem számít, ez meg az, ráadásul semmiben nem különbözik attól az adattól, amit amúgy is elő kell bányásznod valahonnan, ha kell az ügyfélnek, tehát tárolod amúgy is, csak valami elbaszott rendszerben, horrible dictu, papíron. Ne akarjál már hasba akasztani ilyen faszságokkal, kérlek. Az is szégyen, ha komolyan gondolod és az is, ha nem.

Meg _lehet_ csinálni. 

Hogyne lehetne, elég sok banknak sikerült is, gondolom nem tudták, hogy mekkora szívás lenne, ha egy zeller lenne náluk az üzemeltető architect sapkában. A többi mondatod meg bullshit, tartogasd a banki megbeszélésekre, hogy mit miért nem lehet megcsinálni.

https://iotguru.cloud

ezek a szamok atlagpistinek hangzanak soknak. :)

megneztem, az elmult egy napban (hetvege van ugye, tehat pentek estetol szamolva) az egyik belso ingestion rendszerunk (ami adatot mozgat A es B kozott, hogy B-ben [a mi rendszerunkben] lehessen queryzni) 10 milliard soron ragta at magat, volt olyan forrastablank amiben ~204 millio sor volt.

ez csak a raw adat, nem queryk eredmenye vagy ilyesmi...

A történelmi hűsék kedvéért mondjuk el, hogy amikor a GIRO indult, a franciák - akiket de utáltam akkor! - real time rendszert terveztek. Utalsz, az beszalad a giro-ba, könyvelődik a bankodnál és az mnb-nél és megérkezik a célbankhoz, ahol könyvelődik. Csak ezt nem merték bevezetni, nem emlékszem miért, így lett egy kiherélt és kötegelt feldolgozást erőltető vacak. Az OTP ezt sem tudta megugrani, a finisben kapott két hét laufot, mert sehogy nem állt. Csak mert ugye a magyar bank az otp, ahol ma sem tudok nyíregyházán - nem falu - úgy rendelkezni a budapesti V. kerületben nyitott számlám felett, mint egy rendes banknál.

Na ja... Azért az utalás lépéseit erősen leegyszerűsítetted :-) Bőven van pacsizás :-) a kuldő - giro - fogadó útvonalon oda-vissza néhányszor, mire minden a helyére kerül, és a fogadó oldal el tudja küldeni a beérkezett összeget :)

OTP... Anno volt szerencsém Miskolcon nyitott számlával rendelkezni, és Bp.-en szerettem volna készpénzt felvenni a számlámról. Érdekes volt a párbeszéd:
-Hol vezetik a számláját?
-Miskolcon.
-Az melyik megye?
-...
Oké, megmondtam neki, hozzátéve, hogy ezt azért illene tudni.

Két-három héttel később hasonló kör, csak most egy idős ügyintéző volt az ablak túloldalán, a múltkori fiatal leányzó hátul csinált valamit. Beszélgetés az "Az melyik megye"-ig azonos, a múltkori fiatal leányzó ekkor nézett fel, és kezdett kuncogni, mire az idősebb megkérdezte tőle, hogy "Te mit nevetsz?" Mire a lány: Majd a fiatalember elmondja :-) Elmondtam...

 

Tőlem meg azt akarták megtudni, hogy melyik fiók legyen a számlavezető. Megkérdeztem, hogy van-e bármilyen praktikus jelentősége. Azt mondták, nincs. Erre megkértem hogy válasszon egyet. Mondta, hogy csak én dönthetek. Közöltem, hogy képtelen vagyok alap nélkül dönteni. Végül megkért (szinte könyörögve) hogy válassszak már egyet, majd a választásom a munkahelyemhez közeli fiók lett. De ma sem tudom, hogy minek.

(de a kedvenc ügyintézős beszélgetésem az volt, hogy az ügyintéző sosem hallott card fraud detectionről, és fogalma sem volt hogy pontosan milyen és mikori árfolyam(ok) váltódnak majd ha magyar forintos bankkártyával fizetek az EU területén).

Több oka is volt. Az eredeti Giro rendszer elosztott rendszer lett volna, gyakorlatilag nem az egyes bankok, hanem akár bankiókok is rácsatlakozhattak volna (valamikor 1991-92-ben tervezték a rendszert, nagyon sok banknak nem volt országos hálózata, így könnyebb lett volna, ha több helyen csatlakozhatnak az országos rendszerre), az elszámolás pedig nettó elszámolási rendszer lett volna, nap végén szépen kiszámolták volna, hogy ki kinek mennyivel tartozik, amit aztán majd rendeznek. Aztán pár év alatt megváltozott a rendszer, a bankok kiépítették az országos hálózatukat, és nagyobb kontrollt akartak a saját pénzforgalmuk felett, így a sokpontos csatlakozás helyett egypontost akart mindenki (nesze neked hálózati adatforgalom méretezés), természetesen a technológia is váltott - eredetileg X.25 volt tervben, ezt pár év alatt rohamléptekben váltotta le a TCP/IP -, ráadásul időközben volt egy-két bankcsőd (Agrobank, stb), és a bankok azt mondták, hogy inkább bruttó elszámolás legyen.

A hálózati gondok miatt első körben a BZSR floppyk továbbításával zajlott, utána lett aztán online, szóval elég érdekesen alakult a GIRO története :)

+1

A legtöbb bank meg tudta volna ugrani, hogy a ciklust lerövidíti 1 percre, vagy 30 másodpercre vagy ilyesmi. Viszont azt, hogy ez menjen 7x24-ben, meg azt, hogy ez menjen 5 másodperces ciklusokban, nos, azt nem tudták könnyen megugrani a jelenlegi rendszernek adott +1 pofonnal. Ezért kellett egy csomó helyen új rendszert (vagy rendszereket) bevezetni, meg ezeket a többi rendszerhez illeszteni.

( neuron | 2020. 01. 28., k - 20:40 )

Kb. 1 éve azt olvastam, hogy tavaly nyáron indul.

„Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat.”

"Az eredeti tervben szereplő július 1-től már élesben ment volna a rendszer, de ezt 8 hónappal elhalasztják, hogy minden bank megfelelően fel tudjon készülni. […] A piaci szereplők oldalán azonosított kockázatok miatt a Pénzügyi Stabilitási Tanács 2019. május 28-i ülésén úgy döntött, hogy a pénzügyi stabilitás fenntartása, az elektronikus fizetésbe vetett bizalom megőrzése és a szolgáltatással tervezett ügyfélélmény elérése érdekében az ügyfelek számára az azonnali fizetés 2020. március 2-ától lesz elérhető." - https://www.portfolio.hu/uzlet/20190531/breking-elhalasztottak-az-azonn…

( NevemTeve | 2020. 01. 28., k - 21:39 )

Azért érdekes, hogy funkció nélküli várakoztatások kikapcsolása ennyire sok fejlesztést igényel.

nem az 5 masodperces SLA a nehez ebben az egesz "azonnali atutalas" tortenetben, hanem a 7/24 rendelkezesre allas az ugyfelek fele. a banki szamlavezeto rendszerek nagy resze by design alkalmatlan erre (napi, havi zarason kell ragodnia, stb-stb.), ezert mindenfele workaround-oakt kellett takolni korejuk a legtobb helyen.
a bankkartyas fizetes valoban megy ejjel-nappal, csak az altalaban a core szamlavezetestol fuggetlen rendszer.

_m.

Igen, azt észreveszem a furcsábbnál furcsább egyenlegekből, amikor hétfőn aztán összefésülik a kettőt... De megértem, mert bankkártyák még csak harminc éve vannak Magyarországon, szóval még nem egészen tudtunk alkalmazkodni ehhez az újdonsághoz.

Jaja, azert mondom kar fikazni a magyar helyzetet, amikor az USA-ban siman van kolaautomata, ami stripe-only, raadasul ha egyszer lehuztad a kartyat, akarhany kolat kerhetsz akarmeddig, amig meg nem nyomod a finish gombot. Vagy meg nem nyomja egy becsuletes jarokelo a finish gombot, miutan a kevesbe becsuletes jarokelok mar elvertek parszaz dollart kolara a kartyadrol. :D

Egy csomó helyen úgy működik a bankkártyás fizetés, hogy:

- a fizetés előtt egy T1 időben a bank elárulja a kártyatársaságnak, hogy mennyi pénz van az ügyfél számláján az adott pillanatban

- fizetsz T2 időben, a kártyatársaságnál meglévő pénzed lecsökken, de a banknál meglévő pénzed érintetlen marad

- a kártyatársaság szól T3 időben a banknak, hogy az ügyfélnek mennyivel van kevesebb pénze.

Egy rakás banki működés arra épített korábban, hogy T1 és T3 között (tipikusan este és reggel között) az ügyfél úgyse tud csinálni semmit a bankkal, nem tud pénz kivenni a bankkártyán kívül más csatornán, szóval ez így pont jó, ha T1 mondjuk tényleg este van T3 meg másnap hajnalban (meg bonyolultabb a könyvelések miatt a helyzet meg ilyenek, de azt most mindegy).

Na, ezt kell átalakítani úgy, hogy _mégis_ változhat mindkét helyen a kedvesügyfél egyenlege éjszaka is. És ha volt 100 ezer Ft-ja, akkor ne tudja a bankkártyájával és az azonnali átutalással is elkölteni. Ezt nem tudod csak úgy egyszerűen belepatkolni a rendszerbe (különösen, ha a kártyatársaság és a bank között mondjuk FTP-n megy a kommunikáció (nem, nem SFTP-n, és igen, láttam már ilyet)).

Egy rakás banki működés arra épített korábban, hogy T1 és T3 között (tipikusan este és reggel között) az ügyfél úgyse tud csinálni semmit a bankkal, nem tud pénz kivenni a bankkártyán kívül más csatornán

Nade ez a bank sara. Ők álmodták meg ezt a zseniális rendszert, most akkor visszanyalt a fagyi.

Tegyük hozzá, hogy más bankoknak már 15+ éve sikerült jó rendszert álmodni (ami lehet, hogy más sebekből vérzik, de legalább nem architekturálisan van elbaszva): az én egyik bankom már 2003 körül tudta azt, hogy éjjel-nappal lehet bankon belül átutalni, és a frissen megérkezett zsetont a címzett akár rögtön ki is vehette az ATM-ből.

Sehogy, itt minden kártyának saját számlája van, azt tudod kivenni/elhasználni a kártyával aznap, ami reggel is megvolt azon a számlán. Emlékszem ilyen fos rendszerekre az ezredforduló korából, jellemzően a limiteket sem tudtad variálni napközben (esetleg sehogyan se, majd a bank megmondja, hogy mennyit költhetsz egy nap)... hát valahogy inkább másmilyen bankot választottam :)

Nem tudom ezt honnan veszed, de az tény, hogy az én számlám egyenlege azonnal megérzi ha vásárolok. Ezt SMS üzenetben bizonyítja is. Mi több, ha reggel az egyenlegem 1 HUF, de délelőtt 10-kor jön pénzem valahonnan, mondjuk 500.000 HUF, akkor én simán tudok vásárolni 500.001 HUF-ért. Ha hitelkártyám van, akkor 500.001+hitelkeret összege HUF-ért.

"a limiteket sem tudtad variálni napközben" - tippre nem a bank, hanem harmadik fél authorizált, és a limit a partnernél került beállításra/módosításra, amit a bank és az authorizálást végző harmadik fél közötti megállapodás szerinti sűrűséggel és költség mellett volt módosítható.

( KoGa v | 2020. 01. 29., sze - 15:32 )

Sikerült a cronból futó átutalás.sh-t berakni backgroundba? :)

( gelei v | 2020. 01. 29., sze - 15:44 )

Amugy az ertetlenkedo kommentek gazdaitol megkerdeznem:

  • dolgoztak mar olyan rendszeren, ami ekkora volumenben kezel tranzakciokat, es kb. folyamatos (nem 99%) uptime kell neki?
  • lattak mar banki atutalast kozelrol? (technikai szempontbol)

Nem, de egy megbízható tranzakciós rendszer nem a világ legbonyolultabb dolga. Persze lehet úgy csinálni, hogy az legyen de valahogy nehezen hiszem el úgy, hogy a telefonomon a (magyarországi) banki alkalmazások egyértelműen a legmegbízhatatlanabban működő programok.

Persze, tudom ez csak az app hibája, a háttérben minden szuper. Az otp hálózaton nyitottan lógó piwik, rdp csak véletlen és hsts-t meg csak kalandvágyból nem használnak...

Nem tudom, nekem ami mobilos app fent vana telefonomon, az teljesen jól működik. Bár csak az egyik olyan, hogy a futó feladatok at lapozgatva nemmutatja meg az ablak eredeti tartalmát, hanem kitakarja egy fehér téglalappal...

Az, hogy mi "lóg ki" egyik vagy másik bank hálózatából a nagyvilág felé olyan, aminek nem (biztos hogy) kéne, annak a banküzemhez relative kevés köze van.

Lehet, hogy a háttérben jól működik, de én csak abból tudok ítélni, amit látok/tapasztalok: jelenleg 8mp-be telik az utolsó 10 tranzakció betöltése, max 1 hónapot lehet lekérdezni, pár napja órákig "hibás jelszó" üzenetet dobott weben, appban meg internet kapcsolat hibát, átláthatatlan még a banki dolgozók számára is nehezen értelmezhető számlakonstrukciók. Az egész számomra jó példázata annak, hogy mi történik, ha egy iparágban hiányzik a valódi verseny az ügyfelekért.

Ha látok egy éttermet ami előtt koszos ruhában cigizik a szakács, akkor szerintem jogosan feltételezem, hogy a konyhai tisztaság sem tökéletes.

>Nem, de egy megbízható tranzakciós rendszer nem a világ legbonyolultabb dolga.

Valóban nem, nem véletlenül rántotta össze nulláról röhögve a sajátját a Revolut vagy bármely más hasonló fintech cég.

A gond itt inkább azzal lesz, hogy összetett, kiterjedt céges struktúrákról, munkafolyamatokról van szó csomó legacy örökséggel ami egyszerűen nem kidobható. Hiába írsz te meg faszán egy tranzakciókezelő rendszert ami a GiroInstanthoz csatlakozik, annak még tartania kell a kapcsolatot a Bank n+1 szutyvadék belső rendszerével amire a birobotok be vannak tanítva, valahogy hozzá kell igazítani a bank könyvelési folyamataihoz, kezelni kell tudni a cashflow-t rendesen éjszaka is, mindeközben meg kell felelni mindenféle szabályozásnak, mert bokáig ott van a felügyelet lába a seggedben folyamatosan. Ja és közben persze mennie kell a régi rendszereknek párhuzamosan, magas rendelkezésre állással.

A fintechek azért "szárnyalnak" úgy, azért nyújtanak apróból sokszor jobb szolgáltatást, mert nekik sokkal kevesebb mindennek kell megfelelniük, illetve nincs meg a sok legacy örökség cégstruktúrában, egyebekben.

A rendelkezésre állásról tudnék mesélni CIB ügyfélként. Volt hogy a kártyámat sem tudtam használni órákig, ráadásul külföldön. Szerencsére volt nálam egy másik kártya (Erste), pont ilyen eshetőségre. Egyszer az is előfordult, hogy nem fogadta el kódomat. Bementem bankba, előadtam a problémámat, mondták fizetnem kell érte, mert biztos elfelejtettem. Erre adom meg a gépnek (bent a bankban) az új kódot: sikertelen módosítás, ez a jelenlegi kód. Kiküldtek bank elé kártyával, hogy próbáljam meg újra. Nem ment. Utána elnézést kértek és ingyen cserélték. Ugyanígy egyszer megadtam kártyának valami 50e Ft limitet, ki akartam venni 50e Ft-ot és nem tudtam. Bank ügyfélszolgálata azt mondja adjak meg legalább 5-10e Ft-al nagyobb összeget limitnek, mert ez ismert hiba a rendszerben. Ezek után elképzelem milyen tákolmány rendszerük van (amivel valószínűleg nincsenek egyedül, legalábbis amit hallottam olyantól, aki fejlesztett ilyen rendszert másik banknak)

Ja és ha valaki megkérdezné miért nem hagyom ott ezt a szerencsétlent: államnak is végzek munkát és a bürokrácián keresztül átvinni egy számlaváltozást szinte lehetetlen. Címemet kb 3 év alatt tudták megváltoztatni sokadig próbálkozásra, de szerintem még egyes szervezeti egységektől még mindig megy régi címemre levél.

Ja és ez a delay comment annyira nem vicces dolog, mindenki találkozhatott vele ha volt BME-s Neptun gyűjtője régen és nem ahhoz a bankhoz szegődött, akinek a papírját beletették az indexbe az egyetemen az első tájékoztatáskor. Valamint hozzátették, hogy igen ajánlott annál a banknál számlát nyitni, mert BME nála van és más banktól, akár 1 hét is lehet míg jóváírják az utalást..

Én azért megpróbálnám a számlamódosítást - ezeket a copásokat elkerülni bőven megéri 2-3 hónapig két számlával élni.

Az, hogy a BME-s nemtpun össze volt drótozva a számlavezető bank elektronikus felületével, de a máshonnan érkező jóváírásokat nem tudta kezelni (és kézzel csinálták), ez a neptun-számlavezető rendszer közötti kapcsolatot kezelő komponens hibája. (IG2-vel már sok-sok éve legfeljebb a következő banki napon ott van a kedvezményezett számláján felhasználhatóan az átutalt összeg - az, hogy onnan a BME-s könyvelés mikor és hogyan emeli át a tranzakciókat, és könyveli le a megfelelő helyre, az nem a bankközi adatcsere sara.

Csak azért nem akartam kiírni, mert nekik is voltam ügyfelük később és meglepően korrektek voltak. Például mikor volt az a botrány, hogy egyes bankok díjat kértek (valami 5e Ft-ot) a számla megszüntetéséért, akkor ők nagyon gyorsan, korrekten, mindenféle díj nélkül megszüntették a bank és bróker számlámat is.

Attól még tény marad, hogy az egyetemi bankszámlánál kilobbizták h. a felvételi tájékoztató borítékban az ő brossúrájuk legyen ott, ne a többieké. Direkt szürke maradjon az a kérdés h. másnál is bankolhatok-e vagy muszáj náluk nyitni h. ne legyen fennakadás a szeptemberi évkezdéskor? Főleg mikor az embernek vidékiként albérletet és minden mást kellett intéznie még, pont ezt rizikózza be a kezdéskor.

> ...ki akartam venni 50e Ft-ot és nem tudtam. Bank ügyfélszolgálata azt mondja adjak meg legalább 5-10e Ft-al nagyobb összeget limitnek...

OFF

Volt egy film, amelyikben úgy indult a bonyodalom, hogy a srácnak 20.12 $ pénze volt a számláján, ki akart venni egy huszast, de a 20 $ + tranzakciós díj több volt, szóval az ATM elutasította, ekkor bement, persze egy rablás kellős közepébe.

/OFF, csak eszembe jutott, jó film volt amúgy.

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

( Smokey2k | 2020. 01. 30., cs - 14:13 )

Szerkesztve: 2020. 01. 30., cs - 14:15

Amíg nincs a Marsnak mágneses mezeje addig fölös erről beszélni.

ps.: lol ezt most nem értem, eléggé 100%  hogy nálam van a gubanc de nem ebbe a topicba szántam az írást, mégis ide került.

( p.zoltan | 2020. 01. 30., cs - 18:46 )

Na ez zsír! Soha többet nem akarok olyat, mint most karácsony környékén... 6 napig nem lehetett utalni. Rothadt ideges voltam. Szerintem ennek a 6 napnak konkrétan GPD-n százalékban mérhető hatása volt.

( szilard_ v | 2020. 01. 30., cs - 21:56 )

Akkor most végre kiderül, hogy MÁK mikor utal ténylegesen és ki ült eddig hétvégén még a pénzemen?

(péntek esete elküldi a MÁK vagy csak hétfőn reggel?)

Ezt kell nézni:

https://www.giro.hu/letoltes/bkr-uzletszabalyzata-2019-01-01

A mellékleteket nézd a 98. oldal környékétől, abban vannak az időzítések. Az egész abból a korból származik, amikor még minden egyes banki átutalással emberek foglalkoztak gépek helyett, az időzítéseket is így nézd...

A pénzed egyébként ilyenkor részben még a MÁK saját számláján, részben a saját bankod MNB-nél vezetett számláján, és részben a Te számládon van (de olyan állapotban, hogy még úgyse férsz hozzá). Nyugi, ilyenkor nem kamatozik senkinek sem, az elszámolási számlák tipikusan kamatmentesek (ami akkor igazán érdekes helyzet, amikor egyébként negatív a kamat :D).

( hnsz2002 v | 2020. 01. 31., p - 07:01 )

Szerkesztve: 2020. 01. 31., p - 07:02

Én ettől azt várom, hogy március 2-án, 3-án egyáltalán nem fog működni sem az átutalás, sem a netbank, sem a mobilapp, majd 4-én, 5-én talán infót tudsz lekérni, ha nem timeoutol el, 6-7-én nyomokban mennek majd a tranzakciók és belépni is be lehet esetleg normálisan, és majd 2-3 hét múlva talán már tényleg működni fog.

Az utóbbi időben akármilyen change volt a bankoknál bármilyen téren, az tuti hogy szarul sült el.

"Sose a gép a hülye."

Nem tud ilyet tenni.

Egyrészt mert nincs Sárisápi Takarékpénztár (meg hasonló nevű sem, tavaly a takarékszövetkezetek egyesültek a Takarékbankban, lásd: https://www.takarekbank.hu/ertesites-osszintegracios-egyesulesrl). A Takarékbank a GIRO-tag, TAKBHUHB BIC-kóddal, nézd meg a korábban linkelt hitelesítő táblában.

Másrészt a rollout ütemezése nyilván nem olyan, hogy ezek 1-2 nappal az indulás előtt derüljenek ki. Egyrészt a rendszer tesztelése zajlik már tök rég óta (legalább másfél éve), másrészt az indulás előtt ~1 hónappal kiadott hitelesítő táblába bele kell kerülniük azoknak, akik ténylegesen indulnak, mint azonnali-fizetés-képes entitásnak, úgyhogy legkésőbb február elején ki fog ez derülni.

Gondolom már egy ideje párhuzamosan fut a most meglévő rendszer, és a még nem élesített azonnali átutalásos rendszer. És egy ideje minden jól működik, azért élesítik. Legalábbis remélem :) Aztán csak annyit kell majd tenni, hogy átállnak az azonnali utalásos rendszerre, a másikat meg lekapcsolják.

jelenleg egyszerre fut az éjszakai átutalás, a napközbeni átutalás, és az azonnali átutalás is. utóbbit ugyan próbaüzemnek hívják, de igazi pénz megy rajta, szóval ez nem csak egy sima párhuzamos tesztüzem. annyi megkötés van, hogy az ügyfelek pénzét a bankok jelenleg nem az azonnalin keresztül küldik. ehhez nem kell túl sok pénznek forognia a rendszerben, de ebből a szempontból mindegy, hogy egy tranzakció egy forintot, vagy háromszázmilliót fog átvinni.

de ahogy már ügyfélpénz is megy majd az azonnalin, nem fogják lekapcsolni a másik kettőt.

Ez akkor lenne igazán jól kivitelezhető, ha a cél az lenne, hogy az azonnali átutalások eredménye minden esetben ugyanaz legyen, mint a jelenlegi IG2-es átutalások eredménye. Ez nem így van, így a párhuzamos-futtatós + összehasonlítós módszer nem működik.

Amúgy jó régóta fut élesben, az éles infrastruktúrán, éles pénzekkel az azonnali átutalási rendszer, és az egyes szereplők nézik, hogy az elvárásoknak megfelelően működik-e. Teljes piaci képem nekem is csak annyi van, amennyit az MNB és a GIRO kommunikál erről, aszerint minden rendben van, mindenki jól működik. Úgy legyen :-)

( csardij v | 2020. 02. 12., sze - 16:07 )

Amúgy azzal, hogy a sima utalás is azonnali lesz, a VIBER megszűnik, vagy attól még van létjogosultsága?

Nem szűnik meg.

Jogszabályi előírás alapján, ha a megbízás az azonnali átutalás kritériumainak megfelel, akkor azonnali forint átutalásként kell teljesíteni, nem kérhető VIBER teljesítés.

VIBER-be küldhetők:

  • 10 millió forint feletti Forint megbízások,
  • az értéknaposan benyújtott megbízások,
  • papír alapon és telefonon megadott átutalások,
  • üzleti ügyfelek kötegelten benyújtott Forint megbízásai (azaz amikor a megbízási csomag több tételt tartalmaz).

( treczker | 2020. 02. 24., h - 18:41 )

Napok óta "zaklat" a bankom ilyen tartalmú levelekkel és sms-ekkel:

 

"Mivel az Azonnali Fizetési Rendszer bevezetése összetett, a teljes bankszektort érintő változást jelent, amely megnövekedett pénzforgalommal is jár, ezért a március 2-i indulást követő napokban bizonyos szolgáltatások esetében átmeneti kieséseket tapasztalhatnak, valamint a számlaegyenleg átmenetileg a valóstól eltérő értéket mutathat. Javasoljuk, hogy halaszthatatlan utalásait lehetőség szerint időzítse az új fizetési rendszer március 2-i indulását megelőző hétre."

 

Azért ez nem túl biztató...