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

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.

  • 8410 megtekintés

( 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

Igazából nincs ilyen láncolat, ennyi a lényeg:

Küldő: A! <elveszett>

Küldő: B!

Fogadó: Megkaptam B! <elveszett>

Küldő: A!

Fogadó: Megkaptam A! <elveszett>

Küldő: B!

Fogadó: Megkaptam B!

Küldő: A!

Fogadó: Megkaptam A!

Küldő: C!

...

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.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

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).

( p2pking | 2020. 01. 28., k – 17:47 )

egyuttal varhato a dijak emelese is mert igy is tul olcso a magyar bankolas.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

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.

( uid_395 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.

Web, Domain, Tárhely

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).

Web, Domain, Tárhely

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.

"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 :-)

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ó...

Ma délelőtt nem tudtunk utalni, mert az OTP netbank meghalt. Mármint kiírta a szokásos szöveget, hogy ha 5 másodpercen belül nem változik az oldal, frissítsünk. Frissítettünk, majd közölte, hogy kétszer indítottuk el a tranzakciót, hívjuk az ügyfélszolgálatot. Köszi...

Én nem az indulástól félnék, hanem az ÁFA fizetéstől. Amikor majd 1 nap alatt 1 millió+ darab ÁFA-fizetés érkezik azonnali fizetési rendszeren. Ha ez 8 órába sűrűsödik, akkor ~36 TPS-sel fognak érkezni az üzenetek a NAV számlájára...

Azt hiszem, én is másnapra fogom rögzíteni az ÁFA fizetést :-)

Nem az, a 36 TPS általánosságban kimondottan kevés.

Ami árnyalja a helyzetet az az, hogy rá kell mondani a tranzakcióra, hogy "oké!" vagy "nem oké!", ehhez pedig figyelembe kell venni bizonyos szabályokat. A kedvenc példám erre a mentes rész kezelése, aminek ez a szabálya:

"A természetes személy esetében a pénzforgalmi szolgáltató által kezelt pénzösszegek együttes összegére történő végrehajtás:
▸ 114 000 forint feletti rész korlátlanul végrehajtás alá vonható,
▸ 28 501 – 114 000 forint közötti rész 50 százaléka végrehajtás alá vonható,
▸ 28 500 forintig terjedő rész mentes a végrehajtás alól, kivéve gyermektartásdíj vagy szüléssel járó költség behajtása esetén ennek 50 százaléka is végrehajtás alá vonható."

Na, ilyen jellegű szabályokból van párszáz darab, amit minden egyes tranzakció esetében meg kell vizsgálni. Nincs benne semmi bonyolult, de azért tudja enni a millisecundumokat rendesen, mire a megfelelő adatbázisokból előásod a megfelelő adatokat, hogy a feltételvizsgálatokat el tudd végezni.

Ez még mindig nyilván csak vas kérdése, a vas meg majdhogynem ingyen van. Kivéve, ha be akarod tartani a bankokra vonatkozó (nagyrészt értelmetlen) előírásokat, és nem vehetsz otthoni PC-ket meg felhőt, hanem klasszikus szervervasakat kell venned a HP/Dell/Cisco/Lenovo vonalról, amiknek az ár/érték aránya finoman szólva gyenge.

Ez az egész banki IT dolog egy elcseszett történet minden szinten...

Jajj, már megint ez, hogy mennyire komplex és nagyon sok tranzakció és és és világvége, merthogy bank. Olyanoknak próbáld beadni, akik nem láttak még bankot belülről és mindent elhisznek, jó?

Na, ilyen jellegű szabályokból van párszáz darab, amit minden egyes tranzakció esetében meg kell vizsgálni. Nincs benne semmi bonyolult, de azért tudja enni a millisecundumokat rendesen, mire a megfelelő adatbázisokból előásod a megfelelő adatokat, hogy a feltételvizsgálatokat el tudd végezni.

Oszt? Ki kell baszni az egész IT-t, ha nem képes a feladatát normálisan elvégezni. Mindig csak a kifogások, a kifogások és a kifogások, hogy miért nem lehet megcsinálni.

Ez az egész banki IT dolog egy elcseszett történet minden szinten...

Ezt tudom. Szerinted mi kell hozzá, hogy megváltozzon? Ugyanazon a jogszabályi és üzleti környezetben miért vannak mégis nagyságrendekkel jobb megoldások?

https://iotguru.cloud

"Mindig csak a kifogások, a kifogások és a kifogások, hogy miért nem lehet megcsinálni." - Nem azt írta, hogy nem _lehet_,hanem azt, hogy bár a 36TPS nem sok, de vannak olyan körülmények, jogi és egyéb kötelezettségek, amik miatt egy tranzakció feldolgozása jóval bonyolultabb lesz, mint első ránézésre gondolná bárki is.

Mondjál egy 100-szor jobb (az ugye csak két nagyságrend, ami épp kielégíti a "nagyságrendek"-et) megoldást a hazai jogszabályi és technológiai környezetnek (giro) megfelelve. Ja, és a kialakítás/üzemvitel költsége se szálljon el.
 

Mondd már meg, melyek azok a hazai jogszabályok, amelyek miatt nem képesek a bankok nagy forgalom kiszolgálására és technikai bravúrnak kell tekinteni 36 darab nyomorult tranzakciót másodpercenként országos szinten? Mindig szeretsz ilyenekkel előhozakodni, de még arra se tudtál válaszolni, hogy "milyen megőrzési időkkel működhet egy banki számlavezető rendszer", csak felböfögni tudsz ilyen általános dolgokat, hátha elriad az ember, ha meg visszakérdez, akkor többé nem válaszolsz, mert gondolom vagy te se tudod a választ vagy pontosan tudod, hogy hülyeséget beszéltél.

Amúgy tavaly 1 milliárdnál több elektronikus tranzakció ment le a magyarországi banki rendszerekben, ha ezt egyenletesen elterítjük, akkor az 8 óra alatt több mint 900 ezer tranzakció, 24 óra alatt 2,7 millió tranzakció, aminek a harmada átutalás, kétharmada kártyás tranzakció, és ez amúgy több mit 30 tranzakció másodpercenként, aztán mégsem omlik össze a világ végén a bankrendszer be a szakadékba... és persze nem egyenletes a tranzakciószám és ennek ellenére se omlik össze. Hozzátenném, hogy azokat a nyomorult ÁFA átutalásokat tavaly is, idén is és jövőre is meg fogják ejteni az ügyfelek, a többség többé-kevésbé ugyanazon a napon, semmivel se kell se többet , se kevesebbet vizsgálgatni azokon a tranzakciókon.

Áruld már el, hogy melyik banknál húzod az igát, mert szeretném ezek után elkerülni messzire.

https://iotguru.cloud

Nagy arcot eddig tőled láttunk, úgyhogy inkább én szeretném tudni, kiket célszerű elkerülni úgy ügyféként, mint megrendelőként. Senki, ismétlem senki nem mondta, hogy technikai bravúr a 36tps, csak azt, hogy vannakolyan peremfeltételek, amik miatt nem annyira egyszerű, mint gondolnák sokan.

Az ÁFA-utalásokat meg fogják csinálni - igen,megh fogják csinálni, csak az nem mindegy, hogy szokás szerint az utolsó pillanatban teszik ezt meg, vagy időben eltolva. Az IG2-vel nagyjából egyidőben feladott tranzakciók a következő körben mentek át, és kvázi "majd ott lesz a számlán, a megfelelő könyvelési nappal" alapon kerültek jóváírásra a túloldalon. Az afr eseténmeg valamennyi (értékhatáron belüli) utalásnak 5(+5)s után elérhetőnek kell lenni a célszámlán, ami - gondolom te is érzed - más jellegű terhelést jelent.
Nem mindegy, hogy az étteremben egymás után megkapod a megrendelt menüt (IG2), vagy falatonként tolják az orcádba úgy, hogy még épp le tudod nyelni, meg tudod rágni (afr), vagy odaborítják az egész tányérral a szádba, hogy nyeljed, rágjad, és van falatonként 5s-ed, hogy a gyomrodba kerüljön a rendesen megrágott étel. (tömegesen rövid idő alatt betolt azonnali utalások).
 

Senki, ismétlem senki nem mondta, hogy technikai bravúr a 36tps, csak azt, hogy vannakolyan peremfeltételek, amik miatt nem annyira egyszerű, mint gondolnák sokan.

Aham, persze, senki. Magyarázatképp jött fel, hogy az idézett bank miért tereli az értéknapos átutalás felé a népet, mint egy nagynak gondolt szám.

Nagy arcot eddig tőled láttunk, úgyhogy inkább én szeretném tudni, kiket célszerű elkerülni úgy ügyféként, mint megrendelőként.

Aham, szóval akkor kérlek citáld elő azokat a dolgokat, amiket felböfögtél és már többször kértem, mert egyelőre úgy tűnik, hogy téged is megfertőzött az a fajta minden alap nélküli arcnagyobbító és bullshit generáló vírus, hogy bankban dolgozol.

Az IG2-vel nagyjából egyidőben feladott tranzakciók a következő körben mentek át, és kvázi "majd ott lesz a számlán, a megfelelő könyvelési nappal" alapon kerültek jóváírásra a túloldalon. Az afr eseténmeg valamennyi (értékhatáron belüli) utalásnak 5(+5)s után elérhetőnek kell lenni a célszámlán, ami - gondolom te is érzed - más jellegű terhelést jelent.

Hogyne érezném, hogy kisebb terhelési csúcsot okoz az óránként beöntött szarhoz képest az egyrészt órán belül elkent szar, illetve a banki nyitva tartáson kívül elkent maradék szar. Összefoglalnád szakmailag, hogy szerinted miért rosszabb üzemeltetési és üzemviteli szempontból a közel real time működés? Bőven van a nagyvilágban már erre a működésre precedens, ne tegyél már úgy, mintha a magyarországi molyfing bankokban találták volna fel az egészet és több éves K+F eredménye az, hogy végre azonnal lehet utalni... immunis vagyok ezekre a faszságokra, ne fárassz már.

Nem mindegy, hogy az étteremben egymás után megkapod a megrendelt menüt (IG2), vagy falatonként tolják az orcádba úgy, hogy még épp le tudod nyelni, meg tudod rágni (afr), vagy odaborítják az egész tányérral a szádba, hogy nyeljed, rágjad, és van falatonként 5s-ed, hogy a gyomrodba kerüljön a rendesen megrágott étel. (tömegesen rövid idő alatt betolt azonnali utalások).

Vannak még ilyen hülye hasonlataid? Erre már nincs elég facepalm...

Na, és ismét a kérdés, előbb-utóbb csak válaszolsz: "milyen megőrzési időkkel működhet egy banki számlavezető rendszer"?

https://iotguru.cloud

Az érdemi szakmai részre (batch vs. real-time) reagálnék egy kis eszmefuttatással. Lehet, hogy jobban jársz, ha nem olvasod el :-)

Tegyük fel, hogy van az "egyenlegek" nevű táblád a hagyományos SQL adatbázisodban. A sorokban egy-egy "számlaszám", és a rajta lévő "egyenleg" szerepel.

A batch feldolgozást általában úgy csinálják, hogy: 

UPDATE egyenlegek SET egyenleg = egyenleg + valamennyi1 WHERE szamlaszam = 'NAV ÁFA számlaszám'
UPDATE egyenlegek SET egyenleg = egyenleg + valamennyi2 WHERE szamlaszam = 'NAV ÁFA számlaszám'
UPDATE egyenlegek SET egyenleg = egyenleg + valamennyi3 WHERE szamlaszam = 'NAV ÁFA számlaszám'
...
COMMIT

Tök gyorsan lefut, juhéj.

Real-time pedig optimális esetben több szálon, egymással párhuzamosan megy az, hogy:

UPDATE egyenlegek SET egyenleg = egyenleg + valamennyiN WHERE szamlaszam = 'NAV ÁFA számlaszám'
COMMIT

UPDATE egyenlegek SET egyenleg = egyenleg + valamennyiM WHERE szamlaszam = 'NAV ÁFA számlaszám'
COMMIT
...

itt bizony előfordulhat, hogy a sok párhuzamos szál ugyanarra a sorra vonatkozó lockért versenyzik egymással, emiatt az áteresztőképesség sokkal kisebb.

Nem kell elmondanod, hogy ez az egész úgy vacak, ahogy van, én is tudom - de legalább 5 magyar bankról tudom, hogy belefutott ebbe a problémakörbe, úgyhogy nem teljesen világtól elrugaszkodott a dolog.

Azt sem kell elmondanod, hogy pl. egy lehetséges megoldás az, hogy a fentebbi helyett:

  • csinálsz még egy egyenleg_delták táblát
  • abba INSERT-elgetsz, mert akkor nem kell a lockokért versenyezni
  • másik folyamatban, pl. batch jelleggel ( :-) ) UPDATE-elgeted az egyenlegek táblát
  • ...és az elmúlt tizen-huszon évben írt összes lekérdezésedet, amelyben volt "JOIN egyenlegek" rész átírod, hogy inkább valami tárolt eljárással visszaadott egyenleggel (ami az egyenlegek és az egyenleg delták ismeretében kiszámolható) dolgozzon... - ööö, ez az utolsó lépés azért tud időigényes lenni.

Remélem ezzel demonstráltam, hogy számos bankokkal dolgozó kolléga képes ám megoldásokat szállítani - de nem képes időigényes problémákat rövid idő alatt megoldani. És ez bizony szerintem nem az ő hibájuk, és nem kell kirúgni őket, mint alkalmatlan alkalmazottakat...

Azért én nagyon szomorú lennék, ha ez 2020-ban jelentősen befolyásolná másodpercenként mindössze 36 tranzakciónál a futásidőt, még akkor is, ha több fázisú commit van, ahogy szokott lenni. A nagy félelem nem attól van, hogy fogja-e bírni a rendszerük, hanem attól, hogy milyen súlyos bugot hagytak benne és mit felejtettek el lefejleszteni, amivel napokat és heteket kell majd szopni, hogy helyrehozzák.

Elég sok probléma van a bankokkal, de ezek között nincs olyan, hogy valamit technikailag nem lehet vagy túl drága lenne megcsinálni, kis ország ez, kis fogalommal, ami csak nagynak tűnik, ha az ember nem látott még nagyobb rendszereket. Szóval lesztek szívesek nem olyan érvekkel jönni, hogy országos szinten két számjegyű tranzakció másodpercenként sok, se olyannal, hogy több száz millió tételt online lekérdezhetően tartani már mekkora lehetetlen feladat.

https://iotguru.cloud

Az elvárásokkal és a körülményekkel együtt akár sok is lehet - pl. az egyidejű nyitott kapcsolatok korlátozott száma a bank és a giro között (ne, ne nekem mondd, hogy baromság, én is tudom, sőt van más is az egész rendszerben, amire énis azt mondom, hogy aki ezt így találta ki, az inkább kapálni menjen.)
 

afaik 50 a default korlát a gh-n, ami sokkal több, mint amennyire a bankok 95%ának valaha is szüksége lesz ebben az országban. viszont ha valamelyik bank (megint) egy olyan szoftverrel próbál meg üzenni, ami nem zárja maga után a kapcsolatokat, nem fogja leddosolni a saját végpontját, mert már a gh visszautasítja a csatorna megnyitását.

Az a baj h itt az ördög megint a részletekben van elesve. Nem mennék bele a részletekbe mert hosszú (meg talán nem is szabad) de a feltételrendszer úgy egészében khm khm nem túl szerencsés khm...

Nem önmagában ezzel az egy szemponttal van a baj.

Gábriel Ákos

Láttunk Giro oldalról is érdekes dolgokat ezzel kapcsolatban, maradjunk ennyiben. Ja, és vesd össze az 50 egyidejű kapcsolatot a 36tps-sel úgy, hogy egy session nem biztos, hogy 1s-en belül lebontásra kerül.
Egyébiránt egy példának hoztam - ha a teljes feltételrendszert nézed, akkor bizony kellően szűk az a zsák, amibe bekötözve futni, rollerezni és belettozni is kell - egyszerre.

Láttunk Giro oldalról is érdekes dolgokat ezzel kapcsolatban, maradjunk ennyiben.

Igen. És? Hogy jön ez ide?

Ja, és vesd össze az 50 egyidejű kapcsolatot a 36tps-sel úgy, hogy egy session nem biztos, hogy 1s-en belül lebontásra kerül.

Mert egyetlen egy bankból adják fel ugye az összes ÁFA befizetést a határidő napján és nem lehet újrafelhasználni egy felépített kapcsolatot sem, ugye? Szerintem most hagyd abba ezt a világvége hangulatot a 36 tps kapcsán. Méréseid szerint például üzemszerű működés közben a kapcsolatok hány százaléka nem bomlik le 1 másodpercen belül? Egyáltalán mérted te ezt vagy ismét csak felböfögtél valamit, aminek semmi valós alapja nincs?

Amúgy elgondolkodtál már azon, hogy miért van neked ilyen erős kényszered arra, hogy dafke ilyen légből kapott faszságokat mondj, hogy aztán meg ne válaszolj a konkrét kérdésekre?

https://iotguru.cloud

Nem egy bankból adják fel az ÁFA befizetéseket, de egy "bankba" futnak be.

Nekem egyébként van mérési adatom arról, hogy a kapcsolatok hány százaléka nem bomlik 1 másodpercen belül: mivel HTTP keepalive van, 100%-a nem bomlik. Jobb kérdés, hogy a kérések hány százaléka nem kap választ 1 másodpercen belül, de erről nem adhatok statisztikát, mert titok. Az MNB nyilatkozata publikus a témában, amely szerint a tranzakciók jelentős része kevesebb, mint 5 másodperc alatt megtörténik, ennél többet publikusan nem lehet tudni.

Szerintem a default korlát 10 volt a HCTInst esetében, amikor ezzel foglalkoztam + pénzért lehetett kérni a korlát emelését a GIRO-tól. Lehet, hogy azóta megváltozott a korlát, ezt nem tudom.

Az egyik kihívás egyébként ezzel kapcsolatban az, hogy ezen a 10 TCP kapcsolaton, HTTP pipelinig nélkül (amit nem támogatott a GIRO rendszere) egyszerre legfeljebb 10 HTTP kérésed lehetett folyamatban a GIRO irányában. Ha a GIRO válaszideje 50-100 ms között volt (ami a 10-20 ms hálózati késleltetésből és a digitális aláírás 50-100 ms-éből simán összejön), akkor 100-200 HTTP kérésnél többet nem tudsz átzavarni ezeken a "csatornákon", tehát nem tudsz 100-200 TPS-nél többet forgalmazni, még optimális esetben sem. Pedig bizonyos peak-eknél ennél többre szükség lehet.

A másik kihívás pedig a konkrét implementációban van - tök nagy szívás az, hogy egy olyan HTTP klienst csinálj, ami 1) tud HTTPS-t beszélni client certificate küldésével együtt 2) tud HTTP Keep-Alive-ot 3) garantálja, hogy egy szerver felé 10-nél több TCP kapcsolatot nem nyit. Megoldható, de... :/ Ha épp 11 HTTP kérést van kedvem küldeni, akkor hadd küldjem már el...

de ha jön a MÁV vagy a Mol fizetéseket utalni, akkor pár másodpercre tök jó lenne tudni sokkal több TPS-sel küldeni

Létezik a kliens oldali throttling jelensége, ami pont arra van, hogy egy ügyfél ne döntsön be egy halom kérést, amikor semmi szükség rá, hogy tényleg azonnal átmenjen.

https://iotguru.cloud

Az a baj, hogy ez megint nem olyan egyszerű. Mármint megcsinálni nyilván egyszerű, de:

  • sok sikert ahhoz, hogy 30 bankot rábeszélj, hogy ezt megcsinálják, úgy, hogy erre nem készültek, és egyébként is utálják az egészet
  • az ügyfeleket megkérdezve ez tök gáz, miért ér oda egy órával később a Jóska fizetése mint a Pistié, hát hol azonnali ez?

Egyik sem informatikai probléma, megértem, ha nem akarsz foglalkozni velük.

Az a baj, hogy ez megint nem olyan egyszerű.

Hogy is lenne egyszerű? De le kell ülni és átbeszélni, attól sok minden megoldódik.

sok sikert ahhoz, hogy 30 bankot rábeszélj, hogy ezt megcsinálják, úgy, hogy erre nem készültek, és egyébként is utálják az egészet

Rá vannak beszélve a AFR-re is. Ráadásul vannak limitációk a protokollban, pont azért, hogy védeni lehessen túlterhelés ellen a résztvevők rendszereit. Jelenleg is védettek a bankok a túlterhelés ellen, mindenhol be vannak építve az elektronikus csatornákba a megfelelő throttling megoldások.

az ügyfeleket megkérdezve ez tök gáz, miért ér oda egy órával később a Jóska fizetése mint a Pistié, hát hol azonnali ez?

Másodpercekről beszélünk, nem órákról, nem olyan nagy ország ez... miért kellene arra méretezni egy azonnali fizetési rendszert, hogy havonta 20-50 ezer dolgozó fizetését egyetlen 5 másodperces ablakban adják fel? Nyilván lesz throttling, ha kötegelt átutalások belekerülnek egy közel real-time rendszerbe, nem fog másképp a gyakorlatban működni, ahol van évek óta azonnali átutalás, ott a kötegelt átutalásoknál van throttling.

Komolyan, mire jó ez az elméleti eltartott kisujjas baszkolódás az irreálisan szélsőséges esetekkel?

Egyik sem informatikai probléma, megértem, ha nem akarsz foglalkozni velük.

Szoktam én foglalkozni nem informatikai problémákkal is, általában könnyebb meggyőzni az ügyfelet, ha az álmai kergetése helyett két lábbal a földre állítjuk, hogy a pénzéből mi a realitás.

https://iotguru.cloud

Az nem tudom, hogy megvan-e, hogy az MNB erre a problémakörre azt írta elő, hogy a bankok legyenek oly kedvesek és 1 TPS-sel küldjék az ilyen kötegeket. 20 ezer dolgozó az így 20 ezer másodperc, az 5+ óra. 50 ezer meg 10+ óra. Ennél jobb IG2-n hagyni az utalásokat - csak vannak bankok, akik úgy voltak vele, hogy ha már van azonnali, akkor ami csak lehet, menjen azon, olcsóbb lesz kivezetni a többi megoldást.

Azt egyébként nem tudom, hogy észrevetted-e, de ebben a kérdéskörben ügyesen "átterelődtél" a másik oldalra, aki szerint a legjobb lenne mondjuk nem megoldani a problémát. :-D

Az nem tudom, hogy megvan-e, hogy az MNB erre a problémakörre azt írta elő, hogy a bankok legyenek oly kedvesek és 1 TPS-sel küldjék az ilyen kötegeket. 20 ezer dolgozó az így 20 ezer másodperc, az 5+ óra. 50 ezer meg 10+ óra. Ennél jobb IG2-n hagyni az utalásokat - csak vannak bankok, akik úgy voltak vele, hogy ha már van azonnali, akkor ami csak lehet, menjen azon, olcsóbb lesz kivezetni a többi megoldást.

Megvan, hogyne lenne, ezt hívják úgy, hogy kliens oldali throttling, mintha innen indultunk volna... :/

Azt egyébként nem tudom, hogy észrevetted-e, de ebben a kérdéskörben ügyesen "átterelődtél" a másik oldalra, aki szerint a legjobb lenne mondjuk nem megoldani a problémát. :-D

Nem terelődtem sehova, továbbra is azt mondom, hogy országos szinten 36 tranzakció másodpercenként lófasz se, illetve azt is, hogy havonta egyszer 20 vagy 50 ezer tranzakció egy másodpercig egy elméletieskedő baszkolódás, színtiszta értelmetlen kötözködés, nem pedig az architektúra tervezési alapja... nem kell megoldani azt a problémát, hogy egy másodperc alatt átérjen 50 ezer kötegelt átutalás, ez egy álprobléma, ezt egyszerűen csak te hoztad fel, mindenféle reális alap nélkül.

https://iotguru.cloud

Oszt? Többet tudnak azért a banki rendszerek ennél a "bűvös" számnál, nyilván nem másodpercenként 20.000 vagy 800.000 tranzakcióra vannak tervezve, de ne gondoljuk, hogy a 36 tranzakció másodpercenként gondot okoz országos szinten, innen indultunk.

https://iotguru.cloud

A "nem olyan nagy ország ez" felvetesre reagaltam, megpedig azzal, hogy a "nem olyan nagy ország" kozigazgatasa kb. feleannyi embert alkalmaz, mint a McDonalds vilagszerte, ami azert nem keves. Te dobtad fel a temat, sajnalom, ha nem illik a szal kontextusaba. :(

A közigazgatás február elején is megkapta a fizetését. Ismét leírom: nem limit országos szinten a 36 tps, ne vedd alapul a számolásaidnak. És azt is hozzátenném, hogy nem az AFR lesz amúgy se a szűk keresztmetszet, pedig onnan indultunk.

https://iotguru.cloud

Nyilván van értelme a korlátnak: a szerveroldal védelme a túlterhelés ellen. Csak a konkrét implementáció nem sikerült itt túl jól.

Egy ilyen védelmet egy HTTP szerver esetében (amennyiben nem DDoS-től akarod védeni, ami itt nem játszik) úgy célszerű megcsinálni, hogy bizonyos mennyiségű kapcsolat felett HTTP 503 Service Unavailable válaszokat ad a szerver HTTP szinten. Nem pedig úgy, hogy ha 10-nél több nyitott TCP kapcsolatod van a szerver felé, akkor TCP timeout-ot kapsz "válaszként", mint ahogy először volt (azóta változott a dolog, most picit jobb).

Amúgy de, elvi szintű probléma van a monolitikus RDBMS-ekkel, elértük azt a sebességet ahol már elvileg sem tudja sem az RDBMS sem az alatta levő storage kiszolgálni a szükséges mennyiségű egyidejű írási műveletet. Itt nem a 10-20-100 "üzleti" TPS-ről van szó hanem az ehhez szükséges technikai tranzakciók összességéről.

Azt látni kell h a "monolitikus RDBMS"-ekről leszállni nem megy egyik napról a másikra.

Gábriel Ákos

Amúgy de, elvi szintű probléma van a monolitikus RDBMS-ekkel, elértük azt a sebességet ahol már elvileg sem tudja sem az RDBMS sem az alatta levő storage kiszolgálni a szükséges mennyiségű egyidejű írási műveletet. Itt nem a 10-20-100 "üzleti" TPS-ről van szó hanem az ehhez szükséges technikai tranzakciók összességéről.

Tudom nagyjából, hogy mennyi és milyen tranzakció szükséges banki rendszerekben.

Azt látni kell h a "monolitikus RDBMS"-ekről leszállni nem megy egyik napról a másikra.

Egyrészt ne tegyünk úgy, mintha tegnap este derült volna ki, hogy milyen jellegű terheléseket fognak kapni a banki rendszerek.

Másrészt ezek a dolgok egyenes következményei annak, hogy az üzlet és a bank többi része általában a történelem ködébe vesző kezdetek óta nem beszél értő módon egymással, ha mégis, akkor eltúlzott végletekben képesek csak beszélni ("ha nem csináljátok meg azonnal, akkor naponta csilliárd pénztől esünk el" vs "ha megcsináljuk, akkor összeomlik a picsába az egész"), ami nem lendíti előre a helyzetet, pláne, hogy ha veszed a bátorságot és megkérdezed, hogy mégis mire alapozzák ezt a kijelentést, akkor kiderül, hogy valójában semmire, se korrekt üzleti terv nincs a módosítási igény mögött, se korrekt mérési jegyzőkönyv vagy hatástanulmány nincs a másik oldalon.

Az üzleti terület legtöbbször tényleg olyan módosításokkal jön, amire ha megkérdezem, hogy erre adnátok hitelt lenn a fiókban, akkor szemlesütve sertepertélnek, pontosan tudják, hogy vaktában tapogatóznak, ahhoz értenek, hogy kitalálnak valamit, aztán csilliárd pénzből nyomnak egy marketing kampányt, majd lesz valahogy. Közelében nincsenek olyan mérési metodikáknak, amelyeket egy molyfing startup használ a felhasználói monitorozására. Ott ülnek csilliárdnyi adaton és képtelenek belőle bányászni.

Az IT meg általában olyan, mint zeller és SchTamas, hogy minden változáson teljesen kétségbe van esve, reflexből fekszenek keresztbe és hisztiznek mindenek, hogy mivel lehet majd kiszolgálni ezt a hatalmas igényt, meg nem egyszerű, meg a csillagok állása és a napfolttevékenység és kockázat és bla-bla-bla, de nem tudnak előkapni semmilyen mérést vagy tervet, hogy ez ezt fogja okozni, ha aláteszünk fél csilliárd pénzt és felveszünk nyolc embert, akkor viszont menni fog.

Ezek a problémák nem technikai problémák, technikailag a magyarországi bankrendszer bármelyik bankjánál van lényegesen nagyobb terhelésű telepítés, bármilyen rendszert is használnak, el kell menni tanulmányútra, körülnézni a nagyvilágban, hogy mi a helyzet, tanulni soha nem árt...

https://iotguru.cloud

Ehhez két adalék: 

- az egyéni tanulás meg a szervezeti tanulás az nagyon nem ugyanaz. Hiába vagy te egyedül (vagy én) baromi okos ha a többiek akik ott dolgoznak nem azok. Nem lehetsz próféta a saját hazádban (sokáig). Ezért jó konzultánsnak menni :)

- én pont "el vagyok menve" külföldre tanulni. Itt természetesen kolbászból van a kerítés. Mit kolbászból, würstchenből :)

Gábriel Ákos

Nem lehetsz próféta a saját hazádban (sokáig). Ezért jó konzultánsnak menni :)

Ezt pontosan tudom.

Itt természetesen kolbászból van a kerítés. Mit kolbászból, würstchenből :)

Általában lófaszt van kolbászból, mindenhol vannak balfaszok, csak ott meg lehet nézni, hogy ugyanazt a rendszert 10-20-50x nagyobb tranzakciószámú környezetben hogyan üzemeltetik.

https://iotguru.cloud

" Az üzleti terület legtöbbször tényleg olyan módosításokkal jön, amire ha megkérdezem, hogy erre adnátok hitelt lenn a fiókban, akkor szemlesütve sertepertélnek, " - ezt fogom használni, ha megengeded :-)

Nem vagyok kétségbe esve minden változáson (sőt), csak igyekszem a lehetséges kockázatok felderítése felől megközelíteni a dolgot. A "miért lesz jó" részt hozza az ötletgazda, és az ő látómezőjében ennyi van, nem több - nekem viszont, akinek ki kell találni, hogy hogyan fog ténylegesen működni, az a fontos, hogy lássuk, milyen problémákat okozhat a módosítás. Nem a problémákat keresem, hanem a rájuk adhatómegoldásokat - de ezekhez előbb a problémát kell látni.

Fejlesztői vénával/szemmel a "big picture"-ben nem látszik egy race condition, amit meg kell oldani, nem látszik, hogy hálózat/storage/mentés/hozzáférések/stb. terén milyen buktatók jöhetnek szembe (példa: IDM motyó, AD van mögötte - viszont egymásba ágyazott csoportokkal nem tud mit kezdeni. Opsz, ezt nem látták jönni, de használják - adott munkakör esetében nem elég az új mancikát egy, a munkájához szükséges, ezt a csodát használó rendszeren kívüli jogot lefedő csoportba berakni, hanem további n+1-be is be kell pakolni. Vagy az előzetes kalkulációk hiánya... Oracle XE "elég lesz". Nem lett elég - az alkalmazás viszont -ha már volt- használt bitmap indexet, particionált táblákat... ha jól tudom, sikeresen migráltak standard verzióra - a partícionálásra ténylegesen nem volt szükség, a bitmap indexet meg megoldották másképp. Viszont a migrálás pont emiatt nem volt triviális. (Az Enterprise kb. egy nagyságrenddel magasabb ára miatt meg nem volt opció).

És sorolhatnék még az elmúlt huszonsok évből hasonló példákat, amikor a változtatás/új rendszer/új megoldás bevezetésével kapcsolatban khm. nem történt meg a várható kockázatok és problémák részletes feltérképezése, nem volt előre gondolkodás. (Amit egyébként -joggal- hiányolsz a banki/pénzintézeti működésből - tisztelet a kevés kivételnek, ahol van.)

Ja, és a kockázatok, várható problémák felvetésével kapcsolatban nekem alapelvem, hogy ha valami ilyet látok, akkor megpróbálok rá megoldást javasolni, merthogy az is a feladatomhoz tartozik. A "nem jó" meg a "nem lesz jó" önmagában semmit sem jelent, ilyet csak akkor fogadok el bárkitől, ha mellé teszi, hogy szerinte miért nem, és hogy aa saját területét tekintve hogyan lehetne megoldani.

" Az üzleti terület legtöbbször tényleg olyan módosításokkal jön, amire ha megkérdezem, hogy erre adnátok hitelt lenn a fiókban, akkor szemlesütve sertepertélnek, " - ezt fogom használni, ha megengeded :-)

Használhatod, feltéve, ha abbahagyod az ész nélküli "de mi van akkor, ha" jellegű kifogáskeresést, amit ma is több bekezdésen át műveltél, mindenféle valós alap nélkül.

https://iotguru.cloud

Dehogynem kifogáskeresés, leírod, hogy:

Ja, és vesd össze az 50 egyidejű kapcsolatot a 36tps-sel úgy, hogy egy session nem biztos, hogy 1s-en belül lebontásra kerül.

Miközben, ha minimális szinten is utánanéztél volna, akkor tudnád, hogy nem kerül lebontásra egy session. Ezekről beszélek, amikor mindenféle alap nélkül hozol valami random faszságot. Ez nem várható kockázat vagy problémák felvetése, hanem nettó faszság, mintha erős késztetésed lenne arra, hogy valamit kell mondanod.

Pont mint az, amikor visszakérdeztél, hogy tudom-e, hogy "milyen megőrzési időkkel működhet egy banki számlavezető rendszer". Azóta se válaszoltál a kérdésre, gondolom már a kérdés megírásakor tudtad, hogy faszság.

Szóval ezeket legyél szíves abbahagyni.

https://iotguru.cloud

igen, pontosan. csak amíg nem bont le, és elérte a max. számot, addig

Oké, haladunk a konkrétumok felé. Egészen pontosan hány tranzakció után bont le?

Szóval milyen távolságból láttál afr-es speckókat?

Kezdem úgy érzeni, hogy lényegesen közelebbről, mint te... tényleg nem értem, hogy miért jó az neked, hogy random hülyeségeket behozol, aztán nem tudod a részleteket megválaszolni. Ezt például még hányszor kell megkérdeznem, hogy végre válaszolj: "milyen megőrzési időkkel működhet egy banki számlavezető rendszer"?

https://iotguru.cloud

Az egyik baj a bankokkal, hogy nem akarnak komolyabb változtatásokat, van "a" banki rendszer, és minden feladatot ennek a rendszernek a további pofozgatásaival akarnak megoldani, mert végtelenül félnek a nagyobb cseréktől - joggal, mert ezek a cserék drágák. Nameg "minden új rendszer bevezetése megszeretteti a felhasználókkal a korábbi rendszert" :-)

Amúgy zeller tök nyitott szokott lenni a nagyobb változtatásokra is... Nem tudom mi bajod van vele, csinált már ilyesmit, láttam :-)

Abszolút nem banki oldalról, szerencsére..., annyit tennék hozzá, hogy a változás/upgrade vagy bármi felé itthon rendszeres elvárás, hogy "csak egy gombnyomás". A megrendelőt (vagya "bizniszdepartmentet") semmi sem érdekli, csk a "dehátaztmondtad menni fog", az eleje, hogy igen, akkor hogyha minden teszt jó a beszállító sem nem csúszik ésatöbbi. Ezek után végigerőszakolják hanyatthomlok félbehagyott részekkel a dolgokat, majd ha tényleg gáz van (előtte persze jön a minden vészmadárkodni duma, meg az energiavámpírozás), akkor pedig jön a "hát ez miért ilyen?", "miért nem 5 perc". Erre abszolút megértem, hogy sokan minimum rágörcsölnek, pláne amellett, hogy látványosan több idő vagy bármilyen erőforrás (akár emberi) kéne hozzá a napi ügymenet mellé, de erre fentről magasról tesznek, esetleg jó esetben minimálisan próbálkoznak. A seggvédő és bizonyítvány magyarázó emailekbe pedig marhára bele lehet ám fáradni.

Természetesen tisztelet a kivételnek, mert létezik. Meg lehet értelmesen beszélni, hogy mi merre, mennyire akarják, vannak veszélyek és készüljünk fel mindenféle tervekkel. Ha gáz van üvöltözés sincs, hanem "ja látom csináljátok, oké" és ha tudod, hogy ez a hozzáállás, akkor nem görcsölsz rá.

(Azt sem gondolom, hogy ultra nagy újdonságot mondtam, de ezt valahogy mindenki elfelejti.)

Ja, amikor az üzlet jön ilyenekkel, hogy "de hát ez csak egy újabb mező, fel kell venni az adatbázisban, ez miért több nap?", akkor szoktam visszakérdezni, hogy egy lakáshitel miért több nap, csak át kell tenni a pénzt egyik számláról a másikra, nem?

Azt sem gondolom, hogy ultra nagy újdonságot mondtam, de ezt valahogy mindenki elfelejti.

Igazából tényleg az a baj, hogy nem beszélnek egymással értő módon. Olyan régről vannak olyan konfliktusaik, hogy nehéz értelmesen beszélni. És persze mind a két oldalnak megvannak a maga kis trükközései, ami nem segít:

- az üzlet jogszabályi változásba csomagol egy csomó normál üzleti igényt
- a fejlesztés a módosításba csomagol egy csomó refactor és clean code munkaórát
- az üzemeltetés hardvercserét vagy upgrade-et csomagol a változáshoz

És ezt azért teszik, mert különben nem lesz meg se a normál üzleti igény, se a refactor, se a hardver-szoftver upgrade. De mindez mérgezi a működést.

https://iotguru.cloud

Pontosan. Sajnos azt is láttam, hogy néha elsőre értelmesnek tűnik a beszélgetés és akkor télleg egyhúron mindenki, majd jönnek a projekt elemek lehúzkodása, hogy jajj az izé, az drága, legyen másik. Egyrészt a tökölés a "jajjlegyenmásik" vonalon idő, másrészt úgy igazából olcsóra gondolnak, nem biztos, hogy jó lesz... ez a backstab szerű rész a leggörcsösebb oldal.

A trükkök már sajnos nem trükkök, hanem egyfajta túlélési taktikás bevett szokások. Ezek is a görcsökből jönnek, hogy mikor tudok hw cserét elsütni, hogy lehetőleg ne a fejemre omoljon az egész történet.

Azért abba sem árt belegondolni, hogy jön az egyik oldal a "biztos megint változott valami és fos minden" c. eposszal, persze közben a purhabtól nem látszik még a szerver sem, ha megáll akkor szintén idegsokk. Amikor N év (itthon jellemző 5+) után hw csere merül fel, akkor az rosszabb, mint a foghúzás, senkinek se bemutatni a köröket. Majd elsütik a legyél együttműködő eposzt, ami valójában a kussolj és csináld meget jelenti.

Ez nem sokat segít a késleltetésen, amit igen nehéz 1 ms alá leszorítani, 0.1 ms alá meg majdnem lehetetlen. És egy halom ("rosszul" megtervezett, ahol a rosszult értsd pl. úgy, hogy 40 éve tervezték, amikor még minden más volt) rendszer mondjuk egy szálon akar csinálni dolgokat, így 1000-10000 IOPS-nál többet nem hoz ki a csoda-storage-ból.

Egyik kollégám mondta erre mindig, hogy "rakjuk itt az autópályát az ökrös szekerek alá"...

azt irta a kollega fent, hogy nem birja a storage. en erre mondtam, hogy de, birja. az amirol te beszelsz az mar nem storage limitacio, hanem app oldali elbaszas.

amugy az 1ms az mar nagyon regen volt meno, azota kozepesen dragan mar le lehet menni ~80-90 mikroig. ha pedig van penz, ugy ertem _sok_, akkor johet az 1 mikrosec (1050 nanosec iras, 350ns olvasas)

de altalaban egyetertunk: nem a storage lesz a szuk keresztmetszet manapsag, hanem a szar szoftver.

Hát, pl. ilyen a mentes részről szóló jogszabály. Meg még egy példa az, ami az ÁFA-törvényben (! mi a francot keres ez ott?) szerepel, hogy a TBSZ számlára érkező első befizetésnek legalább 25 ezer Ft értékűnek kell lennie. Külön-külön az összes ilyen szabály jó ötletnek tűnik, de sok van belőlük, így sok időt-energiát igényel a kezelésük - többet, mint amennyit elsőre legtöbben éreznek.

Tudom, hogy nem engem kérdeztél, de egy ideje már nem banknál dolgozom, úgyhogy emiatt aztán szenvedhetsz bármelyikkel :-)

Hát, pl. ilyen a mentes részről szóló jogszabály. Meg még egy példa az, ami az ÁFA-törvényben (! mi a francot keres ez ott?) szerepel, hogy a TBSZ számlára érkező első befizetésnek legalább 25 ezer Ft értékűnek kell lennie. Külön-külön az összes ilyen szabály jó ötletnek tűnik, de sok van belőlük, így sok időt-energiát igényel a kezelésük - többet, mint amennyit elsőre legtöbben éreznek.

Oszt? Szabály az szabály, a nagy részük úgyis bank-specifikus saját faszság aminek már rég el- vagy kimúlt történelmi okai vannak, de ápolják, mint a néphagyományokat. De ettől még nem fogok hanyatt esni, mert 36 tranzakció kell másodpercenként, a szabálymotorok nagyobb része utalás oldali, a kisebb része a fogadó oldalon van, de csukjon be az a bank, amelyik normál üzletmenet során nem képes ezeket 5 másodperc alatt megoldani... és amúgy sincs világvége, ha nem sikerül 5 másodpercen belül, 20 másodpercen túl sikertelennek lesz könyvelve, aztán csóközön.

A legszűkebb keresztmetszetet amúgy is a netbankban egyszerre benntartózkodni képes ügyfelek jelentik (másképp fogalmazva a netbank lesz a szűk keresztmetszet), szóval nem fognak tudni tömegesen hirtelen egyszerre azonnal átutalni, ráadásul szinte minden bankban lehetőség van korlátozni az egyidejű belépések számát, pont azért, hogy stabilan tudják tartani a rendszerek terhelését, ha azt valamilyen hirtelen roham indokolja. Ez meg nem tilos továbbra sem.

https://iotguru.cloud

" amúgy sincs világvége, ha nem sikerül 5 másodpercen belül, " - Világvége valóban nincs, ahogy nem világvége az sem, amikor a kevésszavú Joe lelővi a lovát, és a felesége kérdésére, hogy ezt most miért, annyit válaszol, hogy "Egy.".

A netbank lehet(ne) szűk keresztmetszet, de mivel pont az, ami 7x24 "nyitva van", így adódik az, hogy egyen "némi köze" a bejövő IG3-as tranzakciók fogadásához is, főleg akkor, amikor a számlavezető rendszer napot zár. És bizony nem egy helyen pont a netbank az, amit most kell megerősíteni, magas(abb) rendelkezésre állásúvá tenni. És ez bizony sokszor a kód khm. "összetettsége" (értsd gánykupac mivolta) miatt bizony bőven van mit átdolgozni/újragondolni - akár szoftveresen, akár infrastruktúra terén. nem részletezném, milyen infrastruktúrális dolgok "akadnak meg" a fejlesztők torkán... De azért legyen a motyó az elvárt magas rendelkezésre állású...

Világvége valóban nincs, ahogy nem világvége az sem, amikor a kevésszavú Joe lelővi a lovát, és a felesége kérdésére, hogy ezt most miért, annyit válaszol, hogy "Egy.".

Mondd már, mi történik egészen konkrétan, ha nem sikerül 5 másodpercen belül a napi 1-1,5 millió átutalásból mondjuk 100-150? Vagy 1000-1500?

És bizony nem egy helyen pont a netbank az, amit most kell megerősíteni, magas(abb) rendelkezésre állásúvá tenni.

Egészen pontosan melyik az a sok hely, ahol most jött el ez az idő? Annyira bírom, hogy felböfögsz ilyen tök általános faszságokat, mint egy jósnő, amikor meg konkrétumot kérdezek, akkor mintha semmi nem történt volna, arra se válaszolsz már sokadjára, hogy "milyen megőrzési időkkel működhet egy banki számlavezető rendszer"? Pedig már sokadjára kérdezem, legalább annyit válaszolj, hogy csípőből hülyeséget írtál.

És ez bizony sokszor a kód khm. "összetettsége" (értsd gánykupac mivolta) miatt bizony bőven van mit átdolgozni/újragondolni - akár szoftveresen, akár infrastruktúra terén. nem részletezném, milyen infrastruktúrális dolgok "akadnak meg" a fejlesztők torkán... De azért legyen a motyó az elvárt magas rendelkezésre állású...

Hogyne tudnám, hogy mi a helyzet, sok a balfasz, és minél több a balfasz, annál nehezebb változtatni a helyzeten, mert jönnek mindig a balfaszok a kifogásokkal, hogy mit miért nem lehet megváltoztatni. Pont, mint te is.

https://iotguru.cloud

Ezekkel a banki témákkal kapcsolatban a személyes tapasztalatokra alapozott személyes véleményemet szoktam megosztani. Nem muszáj elhinni amit írok (mert tévedhetek és hazudhatok is), pláne nem muszáj szeretni (sokszor én sem szeretem azt, ahogy a dolgok vannak). Viszont úgy gondolom, hogy van némi ismeretem a témában, úgyhogy hiszek benne, hogy hasznos lehet, amit írok.

Ezzel szemben úgy érzem, hogy Te csak fröcsögsz a banki témákkal kapcsolatban. Vannak jó ötleteid (amolyan "nem rosszul kéne csinálni a dolgokat, hanem jól!" stílusban) meg néhány kiforratlanabb elképzelésed (pl. "Ki kell baszni az egész IT-t" - oké, és mi legyen _utána_?), de itt részedről vége a történetnek egyelőre sajnos. Pedig én pl. őszintén kíváncsi lennék a többi elképzelésedre és tapasztalatodra.

 

Azon már sokat gondolkodtam, és őszintén nem tudom, hogy mi kellene ahhoz, hogy ez az elcseszett történet a bankszektorban megváltozzon. Két dolog biztosan kellene hozzá: 1) a jogszabályi környezet jelentős megváltoztatása 2) más gondolkodásmódú banki IT-val foglalkozó személyek. Szerintem egyik sem reális, hogy bekövetkezzen.

Ezekkel a banki témákkal kapcsolatban a személyes tapasztalatokra alapozott személyes véleményemet szoktam megosztani.

Képzeld, én is.

Ezzel szemben úgy érzem, hogy Te csak fröcsögsz a banki témákkal kapcsolatban.

Mindössze 8 évet húztam le bankban és biztosítóban core fejlesztőként, illetve később ennek a felét IT architect pozícióban, azóta meg tanácsadóként jártam itt-ott, de valóban, csak fröcsögök.

Pedig én pl. őszintén kíváncsi lennék a többi elképzelésedre és tapasztalatodra.

Elegendő pénzért bármit, addig meg had legyen meg a személyes véleményem arról, ha valaki próbál egy nagynak kinéző számot mondani, összekötve azzal, hogy bankról van szó.

Két dolog biztosan kellene hozzá: 1) a jogszabályi környezet jelentős megváltoztatása

Én a jogszabályi környezettel nem látok különösebb problémát, érdeklődve hallgatom, hogy szerinted konkrétan mi az a jogszabály, ami jelentősen köti a bankok kezét abban, hogy normális körülmények legyenek belül.

2)  más gondolkodásmódú banki IT-val foglalkozó személyek.

Ezzel a második ponttal viszont kijutottunk oda, hogy ki kell baszni az egész IT-t (illetve az üzletet is). A bankok ugyanis tele vannak 30-40 éve ott gályázó megkövesedett életművész balfaszokkal, akik mindennek keresztbe fekszenek, ami kicsit is komfortzónán kívül van, képtelenek az innovatív gondolkodásra, a feladatok nagy része pedig kényszerűségből elvégzett munka, mintsem reális üzleti fejlesztés. Akárhány új ember kerül be, azok vagy elmenekülnek 1-3 év alatt vagy felveszik ugyanezt a ritmust és stílust: bemész egy megbeszélésre és a közepén már úgy érzed, hogy hosszában fel kellene vágnod az ereidet, annyi a negatív hozzáállású ember, akik mind úgy gondolják, hogy a változás rossz és hosszú listával jönnek, hogy mit miért nem lehet megcsinálni. Ezen akkor se változtatnak, ha megmutatod, hogy a konkurencia megcsinálta, mert akkor azzal jönnek, hogy ott lehet, de nálunk nem lehet.

Ezt súlyosbítja a mindent átszövő korrupció, ahol minden divíziónak megvan a maga kiskakasa, a királyi beszállítója, és a csókos ügyfelei, ezer csatornán szivárog el a pénz, ami miatt egy ügyfélre vetítve többszörös költsége van egy banknak.

Szerintem egyik sem reális, hogy bekövetkezzen.

A reális az lesz, hogy a fintech cégek ugyanezen jogszabályi környezetben más gondolkodású emberekkel letarolják a piacot, mert nem arra megy el a munkaidejük nagy része, hogy mit miért nem lehet megcsinálni, hanem arra, hogy miképpen lehet megcsinálni.

https://iotguru.cloud

Szerintem nincs egyetlen olyan jogszabály, amivel baj lenne (IT szempontból nézve legalábbis). A problémát a betartandó szabályok mennyisége okozza, valamint az, hogy a betartást nem nagyon lehet költséghatékonyan csinálni.

Erre is egy példa: elvileg nem tilos ám felhőbe vinni a banki rendszereket - csak ha megteszed, akkor a nyakadba rántod, hogy ennek: https://www.mnb.hu/letoltes/4-2019-felho.pdf meg kell felelned. Amikor jön az MNB Felügyelet, akkor meg be kell mutatnod azt a dokumentumot, amivel bizonyítod, hogy ezt:

"- meghatározza a szolgáltatás bevezetéséhez kapcsolódó fejlesztések, tesztelések, migrációk és az átállás követelményeit, továbbá az éles bevezetés és a szolgáltatás elfogadási kritériumait, és mindezt ellenőrizhető módon dokumentálja;"

elvégezted, különben jön a pénzbüntetés. (Egyébként sok esetben a pénzbüntetés olcsóbb, mint kifizetni ennek a doksinak az elkészítését...) Csak ebben az egy ajánlásban van 15 oldalnyi felsorolás arról, hogy milyen dokumentumokat és egyéb formamutatványokat kell elkészítened és elvégezned ahhoz, hogy megfelelő legyél. Ez egyrészt sok (ahogy írtam) másrészt egyáltalán nem költséghatékony (ahogy írtam).

A fintech cégek a jelenlegi jogszabályi környezetben előnyben vannak a bankokkal szemben, mert számos jogszabály nem vonatkozik rájuk. Aminek egyébként én tökre örülök :-)

A fintech cégek nagy többségére ugyanazok a jogszabályok igazak, csak ők nem fossák le a bokájukat előre, ha jön egy audit és vannak tökös jogászaik is, akik nem abban élik ki magukat, hogy az ügyfelek életét keserítik hatszáz oldalas szerződésekkel, hanem a cég érdekeit veszik figyelembe az ilyen auditok során. Banki jogászok eddigi tapasztalatom szerint a "szopjunk mindennel, abból nem lehet baj" elv mentén dolgoztak, a fintech cégek meg elmentek a határig és az "elnézést kérj, ne engedélyt" elvek mentén szolgáltattak.

Ezt súlyosbítja az, hogy a bankbiztonsági pocakosok nagy része kivénhedt rendőr, akik nagyon otthonosan mozognak a fizikai védelemmel kapcsolatban, de halvány fogalmuk nincs a hálózati biztonságról, ők is "szopassunk minden dolgozót, abból baj nem lehet" elvek mentén dolgoznak, nem pedig azt nézik, hogy egy-egy támadási vektornak mi a kockázata és mennyire befolyásolja az ellene való védekezés az üzletmenet költségét. A fintech cégeknek meg nincs túl sok fizikailag védendő objektumuk, vannak hálózatbiztonsághoz értő embereik, akik nem kergetik a halálba az egy egyszeri melóst azzal, hogy minden is letiltanak a gépükön.

A többit meg már elmondtam, hogy a bekövesedett balfaszok amúgy se akarnak dolgozni, nekik ez pont jó így, amíg fizetgetnek, addig dolgozgatnak.

https://iotguru.cloud

Ilyen stílussal nem tudom, hol tudtál hosszabb ideig megmaradni - nekem egyébként úgy tűnik, hogy ezzel a nagy adag sértődöttségedet próbálod leplezni, mert valahol nagyon az érzékeny teszrészedere léphettek ebben a szektorban. (Egyébként 10+ évet húztam le IT-s területen banki/pénzintézeti területen, úgyhogy a 8 éveddel nem mondtál nagyot - és a többi időmben is jellemzően magas rendelkezsére állást igénylő, nagy forgalmú rendszerekkel foglalkoztam...)

Ilyen stílussal nem tudom, hol tudtál hosszabb ideig megmaradni - nekem egyébként úgy tűnik, hogy ezzel a nagy adag sértődöttségedet próbálod leplezni, mert valahol nagyon az érzékeny teszrészedere léphettek ebben a szektorban.

Nem, nem léptek. Csak nem fásultam be és nem kezdtem én is azt a fajta munkamorált, amit te.

Egyébként 10+ évet húztam le IT-s területen banki/pénzintézeti területen, úgyhogy a 8 éveddel nem mondtál nagyot - és a többi időmben is jellemzően magas rendelkezsére állást igénylő, nagy forgalmú rendszerekkel foglalkoztam...

Nem nagyotmondásként írtam, hanem egyszerű puszta tényként, hogy voltam bank közelében és nem csak a büféig jutottam el, mert ugye már sokadszorra felmerült, hogy én nem érthetek hozzá, mert biztos nem láttam még bankot belülről vagy közelről. Pedig dehogynem, sőt.

Amúgy szerintem te csak hiszed, hogy magas rendelkezésre állású és nagy forgalmú rendszerekkel foglalkoztál, amilyen tranzakciószámokról és problémákról szoktál itt nagy melldöngetéssel litániát tartani... most is másodpercenként 36 tranzakcióról van szó, ez nálad már nagy forgalmúnak számít vagy ez még nem az? Mondd már meg, melyik bank, kíváncsi vagyok a metrikákra, hogy mennyi az a rendelkezésre állás és az a nagy forgalom.

https://iotguru.cloud

Ezt a "nem lehet a felhőbe vinni" mantrát nem kéne erőltetni. Egy kellően nagy méretű IT-val rendelkező bank on-prem üzemeltetése sem kerül sokkal többe, mint a felhőbe vinni ezeket a dolgokat. Azaz nem a felhőtlenség miatt drága az üzemeltetés, hanem attól függetlenül. Viszont az is igaz, hogy ahhoz, hogy jó és költséghatékony legyen, ahhoz a saját üzemeltetést bizony pont úgy kell csinálni, mint ahogy a felhőcégek csinálják. Na amelyik bank ezt nem érti/értette meg, ott lesznek gondok.
 

Vagy olyan a banki jogászcsapat, hogy szerintük nem éri meg. Mások pedig másképp gondolják és nekik megéri.

Tudod, ez olyan, mint amikor bemegyek egy bankba, hogy kellene az angliai cégemhez egy devizakülföldi bankszámla, akkor - megtörtént eset - elém csapnak egy 13 oldalas kérdőívet, a kockázatokról, egy majdnem 10 oldalas kitöltendő papírt, a céges és egyéb adatokról, a kettő között kb. 60 százalékos átfedéssel, mindezt jogszabályi előírásokkal magyarázva. Felálltam, megköszöntem, bementem a szomszédos bankba, ahol online megnyitották a számlát és csak alá kellett írnom egy két oldalas szerződést.

Mind a kettő magyarországi területen működő bank volt, eltérően értelmezték ugyanazt a jogszabályt. Ezért van az, hogy néha az se mindegy, hogy melyik fiókba mész be, mert másképp értelmezik a szabályzatot is. Amikor a megszüntetett számlámról akartam kérni egy igazolást, hogy átutaltam a lóvét visszavonhatatlanul, akkor három fiókban háromféle magyarázattal ráztak le, felhívtam a call centert, hogy akkor most mi van, mondták, hogy ezt bármelyik fiókban tudják, mondtam, hogy lófaszt, háromban nem tudták, mondjon egyet, ahogy biztos megy, na, mondott, ott se tudták, negyedik indokkal ráztak le (ez ilyen banki betegség, nem mondja azt, hogy bocsánat, nem tudom, megkérdezem a BO-t, hanem mond valami random faszságot, mint te is), az ötödik fiókban ingyen megcsinálták azonnal.

Kurvára függ egy ilyen projekt attól, hogy akik csinálják, azok amúgy tényleg meg akarják jól csinálni, vagy csak húzni akarják az időt és közben a lehető legkisebb munkát elvégezni. Tudok több bankról, akik egyre több dologgal kimentek felhőbe és több olyan bankról, akik ettől teljes mértékben elzárkóztak, mert komfortzónán kívül van és egyébként is állandóan lefossák a bokájukat az audit hírére.

https://iotguru.cloud

Egyrészt a jogászok agymenései, igen,másrészt meg a döntéshozatalban a khm. "fontolva haladás" elve... Aztán a fejlesztők meg az üzemeltetők közösen rágják a rúdaszpirint ilyenkor. És hiába akarja az ember jól megcsinálni, ha szembe jönnek olyan dolgok, amiről nem az üzemetető vagy épp a fejlesztő tehet, de neki viszi el az idejét. (Volt, hogy határidős projekt kellős közepébe rondított bele az, hogy "dejönazauditésfrissítenikellmindent"...)

A bokalefosás audit hírére ismerős dolog - volt szerencsém mindkét oldalhoz, szintén szervezete/cége válogatja, hogy milyen módon állnak hozzá. És ez igaz az auditot végzőkre is, bár ott inkább anaprakész ismeretek azok,amik néha hiányoznak...

Részben jogi, részben pedig gazdasági megfontolásokból  is. Tudod ha benne vagy, és azt mondják, hogy adott feladatot kell megoldani, meghatározott, sokszor szuboptimális erőforrásokból (ami jellemzően az idő), akkor vagy sikerül meggyőzni a vezetőket és az üzleti területet, hogy nem lesz jó, vagy belefásulva "itt van, nesze..:" alapon megoldani valahogy, és utána meg szívni a mellékhatások miatt. És a legtöbb ilyen "mellékhatás" nem az IT butasága, hozzá nem értése, hanem a sok helyen tapasztalt "mindegy, csak induljon el valahogy a dolog" elvárások miatt van.

ja, hogy mákos számla az is. nekik nincs túl sok problémájuk, eleve csak fogadni akarnak tranzakciókat. nem igazán látok ezzel kapcsolatban problémát. a mák nem egy lakossági bank, őket nem fogják az ügyfelek hívogatni, hogy miért nincs a számlán a pénz, pedig már eltelt 2 perc az utalás megerősítése óta. :)

Biztos lesznek ilyenek, lehet, hogy ketten is, de tömegegével nem lesznek, hogy erre kellene méretezni az infrastruktúrát. Ráadásul a NAV baszik arra, ha másnap jön be a lé, maximum legrosszabb esetben odatesz mellé pár másodperces késedelmi kamatot.

https://iotguru.cloud

" lesznek ilyenek, lehet, hogy ketten is, " - nagyon jól ismered a magyar vállalkozásokat, illetve a nekik dolgozó könyvelőket. (Ja, nem.)
" a NAV baszik arra, ha másnap jön be a lé " - nem, ahogy írod is késedelembe esik az adózó, annak minden jogkövetkezményével.
" pár másodperces késedelmi kamat " - Banki/pénzügyi terülten járatos emberként ezt ugye viccból írtad? Vagy te láttál már olyan számlavezető rendszert, ami a könyvelési nap helyett a könyvelési másodperc alapján számolt kamatot?

nagyon jól ismered a magyar vállalkozásokat, illetve a nekik dolgozó könyvelőket. (Ja, nem.)

Rábasztál, mert véletlenül ismerem, a könyvelőm például az MKOE elnökségi tagja és anno rajta keresztül ment például az a fejlesztés kitaposása az akkori NAV-ból és NISZ-ből, hogy az ÁNYK-ból közvetlenül fel lehessen tölteni a nyomtatványokat. A szerver oldali fejlesztést, bevezetést, üzemeltetés betanítását és a kliens oldali tanácsadást én csináltam, vannak még emlékeim is, hogy bevallási határnapon hogy alakult a forgalom, gondolom neked nincs ilyen. Segítek: kurvára nem éjfél előtt pár perccel volt a csúcs, sőt, akkorra már erőteljesen lecsengett a forgalom.

nem, ahogy írod is késedelembe esik az adózó, annak minden jogkövetkezményével.

Jelenleg a több napos késésnek sincs következménye, tényleg baszik rá a NAV.

Banki/pénzügyi terülten járatos emberként ezt ugye viccból írtad? Vagy te láttál már olyan számlavezető rendszert, ami a könyvelési nap helyett a könyvelési másodperc alapján számolt kamatot?

Hogyne létezne ilyen, ahol nem értéknapja van a tranzakciónak, hanem beérkezési időpontja ezred másodpercre, ott ez létező fogalom (more information: intraday interest rate), semmivel se komplexebb számolás, mint az értéknapos, csak más a mértékegysége a számoknak, amikkel műveleteket végeznek.

Tényleg kezd komolyan érdekelni, hogy miért jó neked, hogy felteszel ilyen hülye költői kérdéseket és alap nélküli állításokat... és persze az is, hogy melyik bankban húzod az igát, utána kellene kérdezzek, hogy tényleg ez a színvonal ott vagy csak az átlagnál nagyobb az arcod.

https://iotguru.cloud

Az, hogy a könyvelőd kicsoda, kiféle-miféle, az irreleváns, azt a hozzáállást nem ismered, hogy ha fizetni kell,akkor az minél később történjen meg. De a bevallásokkal is ugyanez van: az utolsó napon "készül el" az ilyen "kötelező" dolgok döntő többsége.

" Jelenleg a több napos késésnek sincs következménye " - lehet, de ettől még jogilag ott a késedelem, ami után bizony napi kamat és bünti jár - merthogy a jogalkotó napi kamatszámítást írt elö. Ez nem tőzsde, hanem a MÁK, illetve olyan pénzforgalom, amire _napi_ kamatszámítás vonatkozik. Az a "semmivel sem komplexebb" az meg csak részben igaz, mert a "mikor" nem vitatható megállapítása ezredmásodperces pontossággal azért picit összetettebb dolog, mint az  értéknapé.

Az, hogy a könyvelőd kicsoda, kiféle-miféle, az irreleváns, azt a hozzáállást nem ismered, hogy ha fizetni kell,akkor az minél később történjen meg.

Te feltételezted, hogy nem ismerem a könyvelőket, én csak megállapítottam egy tényt, hogy ki a könyvelőm.

De a bevallásokkal is ugyanez van: az utolsó napon "készül el" az ilyen "kötelező" dolgok döntő többsége.

De itt az utolsó pár másodpercről van szó. És szerintem kettőnk közül nekem több közöm van ahhoz, hogy a bevallásokat mikor szokták feltölteni, merthogy a munkám része volt például statisztikázni és annak megfelelően változtatni a rendszer architektúrán.

lehet, de ettől még jogilag ott a késedelem, ami után bizony napi kamat és bünti jár - merthogy a jogalkotó napi kamatszámítást írt elö.

Nem a jogalkotóról volt szó, hanem arról, hogy idézem "Banki/pénzügyi terülten járatos emberként ezt ugye viccból írtad? Vagy te láttál már olyan számlavezető rendszert, ami a könyvelési nap helyett a könyvelési másodperc alapján számolt kamatot?", szóval ma is tanultál valamit a banküzemről ezek szerint, csak mert túl nagy arcod volt. Mire jó ez neked amúgy?

Az a "semmivel sem komplexebb" az meg csak részben igaz, mert a "mikor" nem vitatható megállapítása ezredmásodperces pontossággal azért picit összetettebb dolog, mint az  értéknapé.

Miért is? Megmutatnád a két számítást, ami szerint egy adott éves kamatnál mennyivel komplexebb két időpont között az ezredmásodperc pontosságú kamatszámítás, mint a napi? Kíváncsi vagyok a dologra, hogy mennyivel összetettebb. De szerintem megint belementél egy pofonba, erre se fogsz válaszolni, ahogy annyi más kérdésemre is, ahol a konkrétumok miatt forró lett a talaj. Gyűjtsem össze ezeket?

https://iotguru.cloud

Eddig mi volt? Banki felületen még a befogadási idő lejárata előtt betolták az utalásokat, aztán az szépen, kényelmesen átcsorgott IG2-n, megfelelő értéknappal. Ha elsőre netán gond volt egyik-másik tétellel,vagy akár a teljes köteggel, az nem pattant vissza, hanem szépen át lett szuszakolva.
Ha megszokásból most is a korábban megszokott időszakban tolják be az utalásokat, akkor azok abban a rövid időszakban fognak a MÁK-ra rázuhanni. ha sikerül, és átmegy (MÁK visszajelez, hogy rendben), akkor jó, ha nem, akkor a küldö megkapja a "sikertelen" nyugtáját, és küldheti újra. (Eddig a befizetési határnap utolso (néhány) meg a következő nap első IG2-es csomagja volt "erős", most ez az időszak vélhetőleg szétkenődik adott nap délutánjára/estéjére - egészen 23:59:59-ig. Hogy ez a csúcs mennyire lesz lefedve erőforrásilag a MÁK felőli oldalon, az jó kérdés...

" Vagy te láttál már olyan számlavezető rendszert, " - a topic témája az afr, úgyhogy itt a számlavezető rendszert is ebben a körben tessék értelmezni.

Azt írtam, hogy a "mikor" egzakt megállapítása annál bonyolultabb, minél kisebb időegységeket kell megkülönböztetned. És ahogy ez a lépésköz tart az adatátvitel, illetve feldolgozás egyes elemeinek a nagyságrendjéhez, úgy lesz egyre szigorúbb feltételekhez kötve annak pontos és egzakt megállapítása, hogy az adott esemény mikor következett be.

Eddig mi volt? Banki felületen még a befogadási idő lejárata előtt betolták az utalásokat, aztán az szépen, kényelmesen átcsorgott IG2-n, megfelelő értéknappal.

Oszt?

Ha megszokásból most is a korábban megszokott időszakban tolják be az utalásokat, akkor azok abban a rövid időszakban fognak a MÁK-ra rázuhanni. ha sikerül, és átmegy (MÁK visszajelez, hogy rendben), akkor jó, ha nem, akkor a küldö megkapja a "sikertelen" nyugtáját, és küldheti újra. (Eddig a befizetési határnap utolso (néhány) meg a következő nap első IG2-es csomagja volt "erős", most ez az időszak vélhetőleg szétkenődik adott nap délutánjára/estéjére - egészen 23:59:59-ig. Hogy ez a csúcs mennyire lesz lefedve erőforrásilag a MÁK felőli oldalon, az jó kérdés...

Aham, most akkor áttértünk oda, hogy akkor nap közben fognak átutalni, arról, hogy az utolsó öt másodpercben? Te is olyan vagy, mint az olaszok, átállnak egy pillanat alatt az ellenfélhez. És amúgy ismét feleslegesen gondolkodsz olyan problémákon, amiken mások más gondolkodtak és megoldották.

a topic témája az afr, úgyhogy itt a számlavezető rendszert is ebben a körben tessék értelmezni.

Á, szóval amiket eddig írtál, az AFR kapcsán kell érteni? Vagy most speciálisan AFR kapcsán kell érteni ebben az egy esetben? Vagy hogy megy ez nálad?

Azt írtam, hogy a "mikor" egzakt megállapítása annál bonyolultabb, minél kisebb időegységeket kell megkülönböztetned. És ahogy ez a lépésköz tart az adatátvitel, illetve feldolgozás egyes elemeinek a nagyságrendjéhez, úgy lesz egyre szigorúbb feltételekhez kötve annak pontos és egzakt megállapítása, hogy az adott esemény mikor következett be.

Oszt? Elég sok tőzsdei példa van rá a banki világból, ahol ezredmásodperceken múlnak dolgok, esetleg tegyél arra kitérőt hazafelé, ha bizonytalan vagy a témában. Amúgy szerinted mikortól kellene számolni a pénz megérkezését, ha nem azzal az időbélyeggel, amikor megérkezett? Az AFR ugyanis jelenleg ezredmásodperces pontosságú időbélyeget használ, ez miért nem jó szerény véleményed szerint?

https://iotguru.cloud

Szoroz. Nem oszt. Na mindegy, nem érdemli meg a stílusod, hogy érdemben reagáljak, de a legutolsó oszt-oddal kivételt teszek: Az, hogy ms-os felbontású az időbélyeg, az előregondolkodás - egyelőre kamatszámítás alapja az értéknap, nem pedig a ms felbontású időbélyeg. Anno az y2k okán pont a fordítottja miatt szívtunk elég sokat...

Na mindegy, nem érdemli meg a stílusod, hogy érdemben reagáljak

Ja, a stílusom miatt. Véletlenül se azért, mert hülyeségeket állítasz, amire magad se tudod a választ... :)

Az, hogy ms-os felbontású az időbélyeg, az előregondolkodás - egyelőre kamatszámítás alapja az értéknap, nem pedig a ms felbontású időbélyeg.

Nagyon jó, akkor tehát szerinted is van ezredmásodperces időbélyeg, üzleti szempontból pontos és reális, korábban még ezzel is problémád volt. Akkor lépjünk tovább: mennyivel bonyolítja ez meg a kamatszámítási képletet?

Anno az y2k okán pont a fordítottja miatt szívtunk elég sokat...

Mert ezzel a pontos időbélyeggel miképpen is lehet szívni? Mindig meglepsz ezekkel az állításokkal.

https://iotguru.cloud

"üzleti szempontból pontos" - definiáld a "pontos" fogalmát. De tedd mellé azt is, hogy a ezeknek a de facto független rendszerekből érkező időadatoknak az összehasonlíthatósága csak akkor teljesül teljes mértékben, ha a tranzakció ugyanazon lépésének ugyanazon pontján generálódnak, miközben az ehhez használt órák ideje közötti eltérés nagyságrendje ms-nál kisebb.

"az y2k okán pont a fordítottja miatt szívtunk " - azaz akkor az egyik szívás az volt, hogy az időadatot "nagyvonalúan" rövidebb formában tárolta nagyon sok eszköz, illetve alkalmazás - mert amikor készültek, nem számoltak azzal, hogy 1999 után is használatban lesznek. Anno szívás volt, mert valamit _nem_ tároltak el, fölöslegesnek tartva.
A ms-os időbélyeg a kamatszámítás miatt fölösleges, viszont több egyéb okból hasznos, előrelátó döntés - úgyhogy a kitalálóját pont, hogy dícsértem :-D

"üzleti szempontból pontos" - definiáld a "pontos" fogalmát. De tedd mellé azt is, hogy a ezeknek a de facto független rendszerekből érkező időadatoknak az összehasonlíthatósága csak akkor teljesül teljes mértékben, ha a tranzakció ugyanazon lépésének ugyanazon pontján generálódnak, miközben az ehhez használt órák ideje közötti eltérés nagyságrendje ms-nál kisebb.

Szerinted, amikor az beérkező pénz időbélyege ezredmásodpercre pontos és egyezik azzal az időponttal, amikortól az ügyfél rendelkezhet a pénz felett, akkor az milyen pontosságú időbélyeg? Mivel kell összehasonlítani még? Egészen pontosan melyik rendszerek órája tér el egy vagy több nagyságrenddel az ezredmásodperctől?

A ms-os időbélyeg a kamatszámítás miatt fölösleges, viszont több egyéb okból hasznos, előrelátó döntés - úgyhogy a kitalálóját pont, hogy dícsértem :-D

A "fordítottja miatt szívtunk" kifejezés nálam implikálja azt, hogy most a ló másik oldalán szívunk, holott nem véletlen tervezési szempont az, hogy ennyire pontos, egy tőzsdei műveletnél egyenesen létfontosságú a tranzakció pontos idejének ismerete. A kamatszámítás pedig egyelőre történelmi okokból napi záráshoz van kötve, de külföldi példákból be fog gyűrűzni az intraday interest rate is, mert a banknak azért nem mindegy, hogy a nap 24 órájából konkrétan mikor érkezett és mennyi időt volt a pénz a számlán és mikortól-meddig tudja intraday felhasználni más célokra. Van élet az országhatáron kívül is, néha körül kell nézni.

https://iotguru.cloud

Rábasztál, mert véletlenül ismerem, a könyvelőm például az MKOE elnökségi tagja

Emlekeztet egy sztori egy volt kollegamra, amikor egy ebed mellett vitatkoztunk a nagy tobbseg bizonyos kulturafogyasztasi (nem-)szokasairol, akkor o bedobta ellenpeldanak a norveg operaigazgatot.

Igen, a te konyvelod fasza. Ettol meg gazdagon lehet talalni olyan konyvelot is, aki az Excelbe irt szamsorokat zsebszamologeppel adta ossze. (Igaz tortenet alapjan.)

Igen, a te konyvelod fasza. Ettol meg gazdagon lehet talalni olyan konyvelot is, aki az Excelbe irt szamsorokat zsebszamologeppel adta ossze. (Igaz tortenet alapjan.)

Ez hogy jön oda, hogy a könyvelők többsége mikor szokta feladni a bevallásokat és a könyvelők/ügyintézők/vállalkozók mikor utalják a pénzt? A többség nem fog határnapon éjszakába nyúlóan bevallásokat és pénzt küldeni, főleg nem éjfél előtt 5 másodperccel, hogy szopassa az AFR-t, ezeket nagyrészt munkaidőben teszik, esetleg pár órát túlóráznak, ha csúszás van; nyilván vannak balfaszok is, akik éjjelig fognak szopni, de ezek tényleg egy nagyon kis rész, de a bevallási roham nap közben van, délután 3-4 körül van csúcsa, aztán van egy kis csúcs este nyolc körül, amikor hazaérnek a könyvelők és a fusi munkát is elvégzik, aztán szépen elcsendesedik.

Én már tényleg kezdem nem követni, hogy ki mire akar célozni és anekdotázni. Ez volt a folyam:

Zizi: "Én bíznék a "kreatív" emberekben, akik 20-án 23:59:54-kor indítják el az ÁFA-utalást"

Franko: "Biztos lesznek ilyenek, lehet, hogy ketten is, de tömegegével nem lesznek, hogy erre kellene méretezni az infrastruktúrát."

zeller:  "nagyon jól ismered a magyar vállalkozásokat, illetve a nekik dolgozó könyvelőket. (Ja, nem.)"

Franko: "a könyvelőm például az MKOE elnökségi tagja és anno rajta keresztül ment például az a fejlesztés kitaposása az akkori NAV-ból és NISZ-ből, hogy az ÁNYK-ból közvetlenül fel lehessen tölteni a nyomtatványokat. A szerver oldali fejlesztést, bevezetést, üzemeltetés betanítását és a kliens oldali tanácsadást én csináltam, vannak még emlékeim is, hogy bevallási határnapon hogy alakult a forgalom, gondolom neked nincs ilyen."

gelei: "lehet talalni olyan konyvelot is, aki az Excelbe irt szamsorokat zsebszamologeppel adta ossze"

Most tényleg arról akarunk vitázni, hogy a rendszert arra kellene méretezni, hogy hátha egymillió vállalkozó és/vagy a könyvelőjük 23:59:55 másodperckor fogja átutalni az adóját?!

https://iotguru.cloud

gelei: "lehet talalni olyan konyvelot is, aki az Excelbe irt szamsorokat zsebszamologeppel adta ossze"

Ha kiragadsz egy fel mondatot a kommentbol, azzal nehez kezdeni barmit is.

tl;dr a te konyvelod a kivetel, tele van a konyvelopiac (is) hulyekkel

Most tényleg arról akarunk vitázni, hogy a rendszert arra kellene méretezni, hogy hátha egymillió vállalkozó és/vagy a könyvelőjük 23:59:55 másodperckor fogja átutalni az adóját?!

Dehogy akarok errol vitatkozni, en csak szova tettem, hogy ne a top 1% konyvelobol induljunk ki.

Dehogy akarok errol vitatkozni, en csak szova tettem, hogy ne a top 1% konyvelobol induljunk ki.

Nem azt akartam sugallni, hogy minden könyvelő olyan, hogy akár az elnökségi tagja is lehetne az MKOE-nek, hanem azt, hogy eljutnak hozzám könyvelők problémái és viselkedése, lévén az MKOE összefogja őket.

Ezért említettem meg például, hogy 10 éve azért került bele az ÁNYK-ba a közvetlen beküldés lehetősége, mert a könyvelők egyesületében téma volt, hogy mennyire szívás mo.hu portálon a Java applet használatával egyesével feltölteni a bevallásokat és beszéltünk erről, mert tudta, hogy az akkori NISZ-nél dolgozom, szóval elmondtam neki, hogy az egyesületnek mit kellene nyomnia az akkori NAV felé, hogy legyen ilyen.

tl;dr a te konyvelod a kivetel, tele van a konyvelopiac (is) hulyekkel

Tele van hülyékkel, de a kontextusban maradva ők sem fognak direkt várni 23:59:55-ig, hogy aztán akkor adják fel a bevallást, pedig az ügyfélkapun erre aztán több mint 10 éve lehetőségük van, hogy amit inkluzíve 23:59:59 előtt adnak fel az még aznapi feladás. A többségük alkalmazott, akik nagyrészt héttől négyig dolgozik és nem fog remegő kézzel várni az utolsó pillanatig.

https://iotguru.cloud

Szerintem néha el kellene vinnetek az irónia detektorotokat szervizbe, mert látszólag elromlott és véresen komolyan tudtok gondolni dolgokat, másrészt az erős válaszigyekezetben viccesen nagy faszságokat tudtok írni, amire ha visszakérdezek konkrétumot, akkor egy még nagyobb faszsággal tudtok válaszolni.

Te már amúgy megtaláltad már azoknak a magyarországi bankoknak a listáját, amelyek tudnak akár 5 éves online adni számlatörténetet?

https://iotguru.cloud

Oké.

Összefoglalva: írtál valami nagy számot, hogy mennyire nehéz online tartani több százmillió adatsort; kaptál rá reakciókat, hogy ezt több bank is meg tudja tenni; szépen szorultál vissza, mert minden kétségedre volt válasz; végül odáig szorultál, hogy visszakérdeztél, hogy melyik magyarországi bank tudja; kaptál arra is válaszokat, de mivel nem tudtál már hova hátrálni, ezért figyelmen kívül hagytad ezeket a válaszokat. De nyilván te értesz hozzá. Szerintem gondolkodj el egy kicsit, hogy jó bankban dolgozol-e vagy tényleg átlátod-e ezt a területet vagy nem a múltban élsz 10-15-20 évvel...

https://iotguru.cloud

Egyébként a jogszabály csak azt írja elő, hogy 5 (20) másodpercen belül meg kell érkeznie a pénznek, azt nem, hogy hogyan. Ha a bankok úgy döntenének, hogy hagyják a GIRO-t és mondjuk SEPAInst utalásokon küldenék egymás között a pénzt, azt is lehetne. (Ami viszont vicces és érdemes megnézni, hogy milyen feltételekkel lehetne GIRO2-t, mint céget csinálni Magyarországon. Nem IT, hanem jogi kérdés, és... nos, nem könnyű, és nagyon nem olcsó...)

( trey | 2020. 02. 28., p – 15:39 )

Szerkesztve: 2020. 02. 28., p – 15:44

Tájékoztató az azonnali fizetési rendszer indulásáról

Tisztelt Ügyfelünk!

2020.03.02-án elindul Magyarországon az azonnali fizetési szolgáltatás, amelynek köszönhetően ügyfeleink néhány másodperc alatt elintézhetik 10 millió forint alatti elektronikus úton indított belföldi utalásaikat a nap 24 órájában, a hét minden napján.
Az azonnali fizetési szolgáltatásról részletesen ITT olvashat.
A rendkívül összetett szolgáltatás indulását több hónapos előkészítés előzte meg. Az átfogó és alapos tesztelés ellenére, indulás után előfordulhat, hogy technikai problémák léphetnek fel a szolgáltatás működésében. Ezek nem feltétlenül az OTP Bank rendszereiben fellépő hibák lehetnek, de az eredményük az, hogy Önök nem tudnak azonnali utalást indítani vagy fogadni.
Milyen problémák lehetnek ezek? Az utalás mégsem teljesül rövid idő alatt, a számla egyenlege esetleg nem mutatja azonnal az elutalt és beérkező tételeket, esetleg nem kap értesítést az utalásról.
Szakembereinkkel és a pénzügyi tranzakcióban résztvevő szereplőkkel együtt mindent megteszünk, hogy ezek az esetleges technikai problémák mielőbb megoldódjanak majd. Ha azt tapasztalja, hogy több perc elteltével sem kap visszajelzést az utalásáról, kérjük, jelezze a +36 1/20/30/70 3666666 telefonszámon vagy írjon az informacio@otpbank.hu  e-mail címre.
Mit tehet, ha kiemelten fontos, hogy az utalása egy adott napon megérkezzen?
-Ha utalását egy adott értéknap (egy aznapi dátumnál későbbi nap) megjelölésével indítja, akkor az utalás nem az azonnali fizetési szolgáltatáson keresztül történik meg, hanem hagyományos módon.
-Ha utalását telefonos ügyfélszolgálatunkon vagy bankfiókjainkban indítja, utalása az eddig megszokott módon teljesül. A telefonos utaláshoz OTPdirekt telefonos ügyintézői szolgáltatási szerződéssel kell rendelkeznie.
A 2020.03.01. 23:59-ig benyújtott megbízások az eddig megszokott módon teljesülnek.
Megértését és együttműködését előre is köszönjük.

OTP Bank

trey @ gépház

-Ha utalását egy adott értéknap (egy aznapi dátumnál későbbi nap) megjelölésével indítja, akkor az utalás nem az azonnali fizetési szolgáltatáson keresztül történik meg, hanem hagyományos módon.
ez nem tudom, mennyire legit, elvileg az mnb kiadta, hogy ami 10 millió alatti, azt az afr-en keresztül KELL küldeni. mondjuk az sem lep meg, hogy pont az otp szarik az egészre.

( szilard_ v | 2020. 03. 01., v – 20:39 )

Szerkesztve: 2020. 03. 01., v – 20:41

Nálam (OTP) a mobilos kliens fele akkora egyenleget mutatott, mint belépve (vagy belépve kétszer annyi a pénzem :))

upd: Sajnos mostanra elmúlt.

( uid_4656 v | 2020. 03. 02., h – 01:06 )

Jelen pillanatban:

- lehet OTP --> Magnet irányban azonnali utalást csinálni számlaszámra, és meg is érkezik a pénz

- nem lehet Magnet --> OTP irányban azonnali utalást csinálni, már a Magnetnél megakad a dolog "feldolgozásra váró" státuszba kerül a tranzakció

- az OTP rendszerében nem lehet másodlagos azonosítót regisztrálni, mert "Pillanatnyilag a banki rendszer nem elérhető"

- az OTP rendszerében nem lehet másodlagos azonosítóra átutalást indítani, mert "Pillanatnyilag a banki rendszer nem elérhető" (a helyes válasz a "nincs ilyen másodlagos azonosító" lenne helyette)

- a Magnet rendszeréből elvileg lehet másodlagos azonosítóra utalást indítani, de nem tudok, mert nem ismerek egyetlen helyesen regisztrált másodlagos azonosítót sem (ez mondjuk az én hibám, nem a Magneté)

- (a Magnetnél csak fiókban lehet másodlagos azonosítót regisztrálni)

Gyorstesztünket olvasták.

Akkor saját tesztekkel jövök én is:

Erste-ből/be megy, mobilappot frissíteni kellett hozzá.

MagNetbe megy, magNetből netbankon megy, mobilapp-ról nem - de ahogy tudom, ott is várható a mobilapp-ból úl/javított verzió.

Update: közben a magnet weboldalára is kikerült a pontosabb infó.

MAZ-t nem próbáltam (még) sehol.

Nem, magyarázd el kérlek részletesen, hogy egy március elsejei 12:30-as átutalási megbízás, amelyik március elsején 17:30-kor végrehajtódott és rendelkezhetek a pénzzel, annak az esedékessége és értéknapja hogy lett március másodika, mert tudtommal "Az azonnali fizetési műveletek szempontjából minden naptári nap munkanap és egyben a kamatszámítás szempontjából irányadó értéknap lesz."

Szerintem ez AFR előtt azért nem oké, mert nem mehetett volna át a pénz AFR időbélyeggel vasárnap délután, hétfői értéknappal. Se AFR után nem oké, mert akkor az értéknapnak és esedékességnek vasárnapnak kellene lennie, de hallgatlak.

https://iotguru.cloud

IG2 tételként sztem ez rendben van.

De nem IG2 tétel.

2-n éjfélkor indult az AFR, nem?

Aha, ezen viszont vasárnap délutáni időbélyeg van.

AFR átállás határnapi faszság, tranziens jelenség, gondolom minden bank más stratégiával oldotta meg azt, hogy nem értéknapos átutalással akart az ügyfél pénzt áttolni hétvégén, amikor hétfőn 00:00 órakor meg indul az AFR, nem lesz rendszeres gondolom. Itt szerintem vasárnap este beesett az AFR-be, nem a hétfő reggeli IG-be tették.

https://iotguru.cloud

Biztos nem AFR mert AFR tételként vagy megérkezik 5 mp-n belül vagy kuka a tranzakció. Itt meg van 5 óra különbség.

Megérkezett 5 másodpercen belül szerintem, amint bejutott az AFR-be, csak ezt még előtte adtam fel.

Amúgy is bankon belüli tétel, nem sok értelme van AFR felé kiküldeni. 

Ez a dolog a MagnetBank esetén furán működött eddig, mert bankon belül azonnal átment a pénz, de csak az IG2 ciklusok közötti időben. Ha 7:30 előtt vagy 17:00 óra után akartál pénzt áttenni bankon belül, akkor az következő banki napon az első IG2 ciklussal ment át. Hétvégén beszoptad, péntek 17:00 és hétfő 7:30 között nem tudtál se saját, se bankon belüli számlák között pénzt áttenni. Na, ez a működési logika és az AFR bekapcsolása okozott némi hullámzást az erőben... :)

https://iotguru.cloud

Láttam közelről ilyen számlavezető rendszert, ami így működött/működik, de tudod mit? Ha annyira tudod, hogy nem jó, akkor jelezd a bank felé, hogy szerinted hibásan működtek (ők is, meg az összes olyan bank, amelyik ilyen módon dolgozott hét végén), illetve működnek most is.  Aztán kéretik a válaszról beszámolni.

Láttam közelről ilyen számlavezető rendszert, ami így működött/működik, de tudod mit? 

Nagyon jó, hogy láttad közelről, sok minden láttál már közelről ebben a témában, aztán meg kiderült, hogy nem úgy működik, ahogy gondolod, soroljam, hogy mennyi mindent állítottál eddig, amiről kiderült, hogy hülyeség? Ja, nem sorolom, mert azokra a stílusom miatt nem válaszolsz, véletlenül se azért, mert hülyeséget sikerült mondanod.

Ha annyira tudod, hogy nem jó, akkor jelezd a bank felé, hogy szerinted hibásan működtek (ők is, meg az összes olyan bank, amelyik ilyen módon dolgozott hét végén), illetve működnek most is.

Egészen pontosan még melyik bank dolgozott még így vasárnap? Mutatnál egy példát?

Aztán kéretik a válaszról beszámolni.

Rákérdezhetek, de szerintem a legkisebb bajuk is nagyobb ma annál, hogy miért tettek át azonnal pénzt AFR időbélyeggel vasárnap és miért hétfő az esedékesség és az értéknap. A normál pre-AFR működésük az, hogy ez az átutalás hétfőn reggel 7:30-kor történt volna meg, a normál működésű AFR meg az lenne, hogy vasárnapi értéknappal és esedékességgel történt volna, de ugye vasárnap még nem lehetett volna AFR. Ez így mind a két működésmódban kakukktojás.

https://iotguru.cloud

"Egészen pontosan még melyik bank dolgozott még így vasárnap? Mutatnál egy példát?" Neked sokkal nagyobbtudásod, tapasztalatod és ismereteid vannak ebben a szektorban mindenkinél (is), úgyhogy rádhagyom, hiszen te mindent is jobban tudsz még azoknál is, akik adott rendszerrel napi szinten foglalkoztak/foglalkoznak.

"Rákérdezhetek, de szerintem a legkisebb bajuk is nagyobb ma annál" - ügyfélként azt látom, hogy nincsenek ilyen jellegű gondjaik, n+1 ismerőssel teszteltünk keresztül-kasul azokat a bankokat, ahol számláink vannak, és a MagNet-tel kapcsolatban csak a mobilos, nem sablonból történő utalás volt (ismétlem volt!) problémás.  Úgyhogy hajrá, kérdezz rá, és légyszives oszd meg a kérdést és a választ is - mindenki okulására.

Neked sokkal nagyobbtudásod, tapasztalatod és ismereteid vannak ebben a szektorban mindenkinél (is), úgyhogy rádhagyom, hiszen te mindent is jobban tudsz még azoknál is, akik adott rendszerrel napi szinten foglalkoztak/foglalkoznak.

Na, ismét a szokásos séma: mondasz valami nagy általános faszságot, amikor meg a konkrétumra kérdezek, akkor meg semmi válasz, vagy ez a sértődött primadonna. Nem lenne egyszerűbb megelőzni az egészet azzal, hogy nem írsz reflexből hülyeséget?

Nincs mindenkinél több tapasztalatom a bankszektorban, viszont azt ebben a témában adott reakcióidra egyértelműen ki tudom mondani, hogy a tiednél bizony több tapasztalatom van és könnyedén felismerem, ha hülyeséget írsz. Gyűjtsem ki egyesével, hogy milyen faszságokat hordtál össze, amire aztán nem reagáltál, amikor kiderült, hogy faszság?

ügyfélként azt látom, hogy nincsenek ilyen jellegű gondjaik, n+1 ismerőssel teszteltünk keresztül-kasul azokat a bankokat, ahol számláink vannak, és a MagNet-tel kapcsolatban csak a mobilos, nem sablonból történő utalás volt (ismétlem volt!) problémás.

Milyen gondra gondolsz? Átment a pénz, előbb, mint szokott, csak bármelyik rendszerből nézve rossz értéknappal. Gondolom a tesztjeidben ez a use case kimaradt. Utaltál hétvégén pénzt bankon belüli számlák között MagnetBank-nál? Mutasd kérlek, hogy mi lett az eredménye.

Egyébként MagnetBank esetén az új Android klienssel sem lehet számlák között átutalni 17:00 után... :)

https://iotguru.cloud

Biztos forrásból tudom, hogy a hét végén, hózárás után hétfőre nyitva volt a számlavezető rendszer, maradjunk ennyiben. (Az ember ilyenkor kérdez ugye...). Ez egyébként 99.99%, hogy változni fog. Hét végén még az afr _előtt_ voltunk, az afr átállás után teszteltem csak.

" az új Android klienssel sem lehet számlák között átutalni 17:00 után" - a cut-off utáni utalást ügyfélként -érthető módon- nem lehetett korábban tesztelni - tényleg nem megy, jeleztem, meg mások is jelezték: ha nagyon kellene ilyenkor azonnal utalni, akkor a -mobilos böngészőben is korrekten működő- netbankot venném elő. Direkt kipróbáltam: teljesen jól megy, a push-ból megy a kopipaszta, úgyhogy a mobil app problémáját szerintem egészen jól kezelő megoldást adott a bank.
Oké, persze, lehez keresni bármelyik bank működésében a hibá(ka)t, de úgy gondolom, hogy azok a bankok, ahol ügyfélként vagyok érintett (MAgNet és Erste), egészen jól állnak az átlaghoz képest. Sőt...

Biztos forrásból tudom, hogy a hét végén, hózárás után hétfőre nyitva volt a számlavezető rendszer, maradjunk ennyiben. 

Na, a végén még kiderül, hogy a Magnetbank az a bank, amit kerülnöm kell? Vagy a Takinfo közvetve. :)

Akkor már csak azt kellene megmagyaráznod, hogy miképpen lett AFR időbélyegem vasárnap egy olyan tranzakcióra, ami normál esetben hétfő reggel 7:30-kor teljesül... :)

Ez egyébként 99.99%, hogy változni fog. Hét végén még az afr _előtt_ voltunk, az afr átállás után teszteltem csak.

Nagyon jó, én meg előtte és utána is. Szóval nem teszteltél olyan use-case-t, amit én, de a teljes körű tesztjeid szerint amúgy minden működik.

Direkt kipróbáltam: teljesen jól megy, a push-ból megy a kopipaszta, úgyhogy a mobil app problémáját szerintem egészen jól kezelő megoldást adott a bank.

Hát ugye a régi alkalmazás nem is tudott aznapra dátumot ajánlani, az új tudott, de azzal nem ment az azonnali, te meg most mosdatod a szerecsent, hogy ott a weboldal, használjam azt, aham. Ha Magnetben dolgozol, akkor kezdem érteni, hogy miért tűnnek ilyen molyfing dolgok elefántnak, mint pár tíz tranzakció másodpercenként...

https://iotguru.cloud

Ügyfélként teszteltem két bank mobil és webes felületét, illetve ismerősi körben teszteltünk egymás közötti forgalmakat, ennyi, nem több. Ami ennek a körnek "must have", az döntően működött - a cutoff utáni tranzakciót cutoff előtt nem lehet tesztelni, ergo az akkor kimaradt - délután meg hamarabbolvastam, minthogy időm/kedvem lett volna tesztelni. (Bónuszként egyelőre nemlátok olyan kritikus use-case-t a saját pénzforgalmam tekintetében, aminél a mobilapp-ból azonnali utalás kritikus jelentőségű lenne, úgyhogy maximum technikai oldalról érdekelne, hogy működik-e vagy sem.

"Hát ugye a régi alkalmazás nem is tudott aznapra dátumot ajánlani, az új tudott, de azzal nem ment az azonnali, te meg most mosdatod a szerecsent, hogy ott a weboldal, használjam azt, aham. " - érdeklődtem, és ezt a választ/javaslatot kaptam, ami workaroundnak teljesen korrekt - végleges megoldásnak persze nem, de gondolom a fejlesztők nem ülnek karba tett kézzel, hanem rajta vannak a javításon - de majd utánakérdezek ennek is valamikor, hogy hogyan áll a dolog - bár mint mondtam, nekem, mint ügyfélnek nem fáj, úgyhogy megint csak azt mondom, hogy ha neked igen, akkor kérdezz te.
 

Egyrészt a kérdés nem onnan indult, hogy fáj-e vagy sem, hanem onnan, hogy olyan tranzakciós adatok kerültek bejegyzésre a tranzakcióhoz, ami se a régi, se az új átutalási rendszerben tisztán nem áll elő, érdekesség, semmi több, te akartad nagyon erősen megmagyarázni, hogy minden rendben, csak nem jött össze...

Másrészt a hiba az hiba, és ezeknek a tesztrendszeren ki kellett volna jönnie, ha lett volna korrekt és teljes körű teszt. Nem volt.

Harmadrészt a kutyát nem érdekli, hogy szerinted más bankoknál milyen problémák voltak.

https://iotguru.cloud

( uid_10547 | 2020. 03. 02., h – 08:19 )

Szerkesztve: 2020. 03. 02., h – 08:25

rafi-nál másodlagos azonosítók felvétele megy szépen, rafi->erste utalás is működik gyorsan. 

Már csak a lakcímre kellene ilyen.

Amúgy 10 éve próbáltam nyomi a Kopint-ban, hogy legyen két feature a mo.hu-n:

1, Szabványos OAuth 2.0, OpenID és SSO szolgáltatás, amihez bárki tud integrálódni különösebb fejlesztés nélkül és így azonosítottnak tekinthető az így belépett felhasználó, ahova csak belép ezzel a credential használatával.

2, legyen egy olyan lakcím nyilvántartó modul interfész, amiben tudok token-eket generálni, a generált tokent oda tudom adni egyesével a szolgáltatóknak és ha levelet akarnak küldeni, akkor a tokenjük lekérdezésével mindig tudják az aktuális lakcímemet és/vagy értesítési címemet. A tokent pedig vissza tudom vonni, ha megszűnik a szolgáltatóval a szerződésem.

Hát nem ment át, mert éppen indult valami sok milliárdos közbelopás, amiben konkrétan ez nem volt benne, de végül hosszas vajúdás után a KAÜ született meg, mint egyes pont, a lakcímes dolog meg elfelejtődött.

https://iotguru.cloud

Ellenben nem válthatsz telefonszámot:) De az amúgyis macera, most eggyel több helyen kell azt is módosítani.

Igazából csak számhordozás kéne a bankszámlákhoz és nem lenne próbléma:) (Oké, hogy adott formátuma van a számlaszámnak és megvan, de a telefonszámnál is ez volt... ma meg ha meg akarja tudni az ember hogy melyik szolgáltatóhoz tartozik egy szám kérdezheti le)

Ez implicite azt mondja mintha a belső ember által végzett módosítás ingyen lenne. Pedig nyilván nincs. 

Úgy is ott van más dolga nincs ugye... :)

A banki product managementet és controllingot ismerve abszolút hihető magyarázat - attól függetlenül borzasztóan kőkori és tragikus.

Vagy ami valószínűbb: valamiből kell pénzt is beszedni, ez pont olyan, amiből lehet és nem okoz még akkora lemorzsolódást, hogy csökkentsék vagy megszüntessék a költségét, nyilván sírni fog miatta az ügyfelek egy része, de a nagy többsége ez miatt nem megy más bankhoz. Árazás kapcsán pedig vannak bankok, ahol beletesznek mindent a számlavezetési díjba és vannak bankok, ahol ingyenes a számlavezetés, de minden apróságért felszámítanak pénzt, meg bankok a kettő véglet között.

Sok bank például sokáig nem számolt fel pénzt az SMS küldés után, pedig egy közepes banknál ennek a költsége évente 500 millió körül lehetett, de beleépítették a működési költségekbe, szétterítették 250 ezer ügyfélen, kicsit kevesebb látra szóló kamatot adtak, kicsit több pénzt szedtek be havonta, kicsit rosszabb árfolyamon váltották a devizát és mindenki boldog volt.

https://iotguru.cloud

nem mondom, hogy belehal az ember, de a 0 forintos számlavezetéshez képest sok:)

Ismerős érzés. Annyira nem szeretem, amikor szinte magyarázkodni kell, amikor igyekszem megszabadulni egy feleslegesnek ítélt kiadási tételtől. Mint amikor bementem a bankba számlacsomagot váltani, és kérdezte az ügyintéző, hogy miért. Mondom, mert a kívánt új csomagnak nincs számlavezetési díja, de most levonnak havi ~200 forintot, erre ő: "de hát az nem sok". És akkor "magyarázhattam" neki, hogy hát minek fizessek érte, ha ingyen is megkaphatom. Szörnyű, hogy milyen hülyének nézik az embert.

Az meg külön mókás, hogy sokszor azok néznek csórónak az ilyen esetekben, akik máskor meg osztják az észt, hogy ne költs annyit cigire/nasira/autóra stb. és akkor több pénzed marad. (És ez igaz is.) De ha véletlenül magadtól takarékoskodsz valamivel, akkor rögtön csicska leszel. :D

Lusta vagyok újra előkeresni a leírásokat, de a ~200 forintos csomag egy ősrégi csomag volt, egy ideje már nem is igényelhető, csak a korábban igényeltek maradtak meg azoknál, akik még nem váltottak. Az új mindenképpen jobb -- nekem legalábbis. Minden, amit használtam a régiből (egy betéti kártya, havidíj nélküli netbank, elektronikus számla) az van ebben is, de ennél csak 2 ezrelék az utalási díj (a réginél arra emlékszem, hogy ott egy 3000-4000 forintos átutalásnál is 100-200 forint környékén volt a díj), és itt ugye nincs havidíj, ill. az új csomag részeként a betéti kártya is olcsóbb egy kicsivel (+ az első éves kártyadíjat elengedték). Elvileg az új csomaghoz jár két ingyenes takarék-alszámla, bár azt még nem használtam.

Egyebekben ugyanúgy használom a netbankomat, mint eddig, csak kevesebb költséggel.

( seferbt v | 2020. 03. 02., h – 09:35 )

reggel 6:39-kor még működött. Asszony számlájára utaltam át 123Ft-ot (többet nem mertem :D), és átment. És még az SMS is megjött róla.

( denton | 2020. 03. 02., h – 09:52 )

CIB:

 

Fontos, hogy a másodlagos számlaazonosítót először regisztrálni kell ahhoz, hogy használni lehessen.

Ezt megteheti bármely bankfiókunkban.  

 

anyád.......

OTP:

Lakossági ügyfeleink 2020. március 2-ától bankfiókban vagy az internetbankon keresztül a Beállítások/Másodlagos számlaazonosítók menüpont használatával tudnak másodlagos számlaazonosítót regisztrálni a számlájukhoz. Az internetbanki funkcióval e-mail cím és mobiltelefonszám rögzítésére nyílik lehetőség. Adóazonosító jel regisztrációját a bankfiókokban lehet kezdeményezni.

Az érintett vállalati ügyfelek a másodlagos számlaazonosítókat a számlavezető bankfiókban tudják regisztrálni.

Aztán lehet évente megerősíteni

A regisztráció után egy évvel a számlatulajdonosnak meg kell erősítenie, hogy használja a másodlagos számlaazonosítóját.

Az OTP biztos. Egy másik városban akartam a cégemmel kapcsolatban ügyintézni. Azt mondta az ügyintéző, hogy nem látja az aláírásomat a rendszerben(!) ezért nem tehet semmit, a számlavezetőben kell kérnem, hogy az aláírásom az összes fiókban elérhető legyen. (alairas.jpg)

Amikor ezzel találkoztam 10-12 évvel ezelőtt, akkor az volt a válaszuk, hogy a céges papírjaimat és az aláírásomat a számlavezető fiókban őrzik. Bementem, rögtön tudták mit akarok, nem egy eldugott menüpontot kellett ezek szerint keresniük.

Digitális táblán alá kellett írnom, ami marhára nem sikerült, mert közben eltelt 30 év és papíron aláírni nem ugyanaz, mint egy műanyag felületen. :)

Ha már ott voltam, akkor elintéztem, ami miatt ez kellett, így évekre elfeledtük egymást.

Amikor limitet akartam módosítani, akkor is a számlavezetőhöz küldenek. Mondtam, hogy azért csináltattam meg az aláírás macerát, hogy mindenhol tudjak ügyet intézni. Hát a nagy túróst intézik el bármelyik céges fiókban.

Szerencsére tényleg csak akkor kell bemennem, ha a törvényi dolog miatt erre köteleztek.

( csardij v | 2020. 03. 02., h – 10:31 )

Beléptem a netbankba, aztán már fogadott is a bullshit üzenet, hogyaszondja:

Az AFR kiépítése mellett annak a többi rendszerhez való illesztése, és azok összehangolása az igazán nagy volumenű, bonyolult feladat.

Meghogy:

átállás óriási informatikai kihívást jelent

Hát mondom, miért irnak ilyet. Aztán a második oldalon, sorolják, hogy:

Átmenetileg nem elérhető szolgáltatások

  • Munkanapokon az éjszakai órákban és hétvégeken AFR terhelések és jóváírások a számlatörténetben nem láthatók a következő nap reggeli napnyitásig.
  • Sárga csekk befizetés funkció nem elérhető
  • Deviza számlájáról nem tud kimenő forint utalást kezdeményezni.
  • SMS szolgáltatatás:
    • előfordulhat, hogy nem minden esetben tartalmaz számlaegyenleget az Ön számára megküldött tranzakciós SMS üzenet, a kártyaforgalmi SMS-ek kivételével.
    • bankon belüli átutalásról SMS értesítés nem kerül kiküldésre.

Legalábbis ezek amiket bevallanak ugye.

Aztán ugye persze elnézést kérnek, és:

Elnézést kérünk az okozott kellemetlenségekért, a szolgáltatások fejlesztésén kollégáink folyamatosan dolgoznak

Takarékbank, csak tudnám akkor, hogy az elmúlt egy évben mit csináltak.

Web, Domain, Tárhely

Mielőtt a lölö rátette volna a mancsát, itt elég jó volt a helyi takarék a többi nagybankhoz képest.

Most kb. elvesznek a helyi, kis méretből adódó előnyök (hát, ez pesten intézi, hát ezt nem látok rá, mert pesten döntik el, stb)... 

Web, Domain, Tárhely

( solt87 | 2020. 03. 02., h – 11:04 )

Szerkesztve: 2020. 03. 02., h – 11:14

Jelenleg az azonnali utalások teljesüléséről ügyfeleink egy része csak késve kap értesítést, de az utalás sikeresen végbemegy [...]

A fene tudja, hány hónapos csúszás után, csilliárdnyi pénzt lenyelve, kiterjedt tesztelést (LoL) követően a professzionális(tm) pénzügyi(tm) fejlesztés(tm) mégsem akar zökkenőmentesen működni. Gratulálok. (Azért remélem, az illetékesek milliós bónuszai nem maradnak el...)

kép

( Finrod | 2020. 03. 02., h – 15:14 )

Szerkesztve: 2020. 03. 02., h – 15:20

Gránitbank netbank akadozik, a login page timeoutol, a 4-ik OTP sms-re kaptam egyáltalán egy input mezőt ahova be tudnám írni a kapott OTP kódot.

Egy 2500 forintos átutalás státusza percekkel a kezdeményezés után "... még nem dolgozta fel"... a számlatörténet lekérdezésére "a számlavezető rendszer nem érhető el..." újabb pár perccel később a tranzakció megnevezése Könyvelésre váró azonnali utalás, azonosítója 999999997, ami alakilag kissé gyanús hogy valamit jelent, vagy ha nem, akkor pedig valamit eltoltak és ennek pár értékkel nagyobbnak kellene lennie. Újabb pár perccel később még mindig Könyvelésre váró azonnali utalás... az az 5 másodperc egyre elérhetetlenebb :-)

( csardij v | 2020. 03. 02., h – 16:13 )

Takaréknál és K&H-nál is azt vettem észre, hogy rafkós módon a netbankon nem az azonnali átutalás az alapértelmezett, hanem az értéknapos. Ezzel csökkentik sunyi módon a terhelést?

Web, Domain, Tárhely

( chx | 2020. 03. 02., h – 18:04 )

Budapest Bank: kartyas vasarlas bo egy oraja, az SMS-ben nincs egyenleg. Netbankon a pontos egyenleg van. Erdekesseg, hogy a HH:MM:SS utan 2 darab space van. Ugy nez ki hogy az "E: egyenleged_HUF-ban" helyett van a masodik space.

Eddig jo, nem aggodom.

echo crash > /dev/kmem

( mark7 | 2020. 03. 02., h – 18:33 )

" elektronikus úton indított belföldi utalásaikat a nap 24 órájában"

25 perce utaltam, mégse érkezett meg.

A régi rendszer szerint ~16h utáni utalás csak másnap reggel, a Giro nyitásakor teljesül, de hát itt éppen arról van szó hogy 24 órás lett.

( zotya62 v | 2020. 03. 02., h – 19:00 )

A szolgáltatók számlájára történő utalások lekönyvelését ez mennyiben fogja gyorsítani?

( csardij v | 2020. 03. 02., h – 19:17 )

K&H:

Ezúton szeretnénk tájékoztatni, hogy egyes kkv ügyfeleink esetében technikai okok miatt a mai napon beküldött átutalások nem teljesültek. 

Web, Domain, Tárhely

( answ | 2020. 03. 02., h – 20:17 )

Szerkesztve: 2020. 03. 02., h – 20:32

CIB bank appja csak teker, nem jelentkezik be (akár 4G-n, akár wifi-n). 2 órája is tekert, de akkor kb fél perc után azért beengedett.

Elektronikus csatornáink a megszokottnál lassabbak, melyért elnézést kérünk ügyfeleinktől. A probléma megoldása folyamatban van.

Hát igen, nem volt elég idő felkészülni és performance teszteket végezni, elvégre a múlt héten jelentették csak be mit kell csinálni.. oh wait.. 

( _Franko_ v | 2020. 04. 05., v – 16:02 )

Szerkesztve: 2020. 04. 05., v – 19:49

MagnetBank-nál azért a hétvégi üzem még problémás... :)

Átutaltam két saját bankos számla között, a számlatörténetben ott van a pénzmozgás, a számla egyenlegén nem jelenik meg.

 

Na, átment végre a pénz, laza 3 óra volt, bankon belül:

Számlavezetőbe való feladás időpontja: 2020.04.05. 15:46:58

Számlavezető könyvelési idő: 2020.04.05. 18:37:25

https://iotguru.cloud

Konyvelt egyenleg ebben az esetben nem relevans, extrem esetben akar napokkal kesobb is konyvelodhet a tetel. Az elerheto egyenlegnek viszont valtoznia kell.

Ill meg egy kerdes: ugye mindket szamla penzforgalmi volt, es nem pl tbsz vagy beteti. Mert azokra afaik nem vonatkozik a jogszabaly.

Nem változott a könyvelt egyenleg, nem tudtam kártyával fizetni, mert nem volt ott a pénz, csak 18:37 után. Egyszerű számla mind a kettő.

Most újra tettem át pénzt két számla között, most sem ment át:

Számlavezetőbe való feladás időpontja: 2020.04.05. 19:58:58
Könyvelés dátuma: 2020.04.05.
Esedékesség dátuma: 2020.04.05.
Státusz: teljesült
Tranzakció típusa: AFR jóváírás bankon belül

Szerintem akkor fog megjelenni felhasználható pénzként, amikor megjelenik a "Számlavezető könyvelési idő" is, ami most még nincs.

https://iotguru.cloud

( zeller | 2020. 04. 05., v – 19:44 )

Szerkesztve: 2020. 04. 05., v – 19:44

Erste-től a  push még mindig cseszik megérkezni úgy, hogy a friss mobilbankos alkalmatlanságuk, akarom mondani "de tényleg mindjárt készen vagyunk" alkalmazásuk stock andriodra van felrakva, semmilyen jogosultság nincs elvéve explicit módon az alkalmazástól.
Ugyanerre a készülékre random egyéb alkalmazásokba érkező push mind megérkezik.
Szóval Ödönéknél is van reszelni való még.

Xiaomi A2, mindenféle hákolás-tákolás nélkül. Mondjuk a psd2 táján is sikerült az Erste-nek "néhány" ügyfelet ideiglenesen úgy kizárolni a net/mobilbankból, hogy csak erősen tornázva, napokkal később bírták megoldani (netbankos login teljes trace-t küldtem nekik a végén...). Emiatt nem bátorkodom legyakni és újrarakni ezt a "de tényleg mindjárt készen vagyunk" alkalmazást...
 

BÁtorkodtam az alkalmazás összes adatét törölni, leszedni, majd újratelepíteni. Az előző telepítésnél nem tudom, melyik SIM volt SMS küldésre az aktív, most beállítottam, hogy a privát (1. SIM) legyen az - lehet, hogy erre volt szükség, lehet, hogy elég lett volna csak az újratelepítés: a lényeg, hogy működik, megérkezik a push, használható (...) az alkalmazás - igaz, a "Mindjárt készen vaygunk... De tényleg..." homokóra-helyettesítő szöveg az maradt :-P Lassú a backend, gondolom...

( kikepzo | 2020. 04. 05., v – 23:24 )

Azt megtapasztaltam, hogy hétvégén is nagyon gyorsan megtörténik az utalás, ám azt nem látom, hogy honnan érkezett a pénz a számlámra, ebben a pillanatban is csak az április 02-én érkezett összeget látom, hogy ki küldte, de a tegnapi napon érkezettet nem mutatja a banki rendszer, hogy honnan érkezett. Van erre szabály, hogy ezeket az infókat mikor kell rendelkezésemre bocsájtani?

"https://hunvagyok.hu "

Nincs. A jogszabály úgy fogalmaz, hogy az összeget rendelkezésére kell bocsájtani, tehát az előjegyzésnek meg kell érkeznie 5 másodpercen belül a számládra.

De szerintem a legtöbb bank előbb utóbb úgyis megoldja, hogy az előjegyzett tranzakció történtet is elérhető legyen netbankon keresztül, mert az ügyfeleknek nagyon zavaró ez az állapot. És mondanom sem kell, hogy emiatt terhelik is a Call Centert.

Nincs. A jogszabály úgy fogalmaz, hogy az összeget rendelkezésére kell bocsájtani, tehát az előjegyzésnek meg kell érkeznie 5 másodpercen belül a számládra.

De szerintem a legtöbb bank előbb utóbb úgyis megoldja, hogy az előjegyzett tranzakció történtet is elérhető legyen netbankon keresztül, mert az ügyfeleknek nagyon zavaró ez az állapot. És mondanom sem kell, hogy emiatt terhelik is a Call Centert.